-
Notifications
You must be signed in to change notification settings - Fork 16
/
asymetric_crypto.theory.txt
151 lines (142 loc) · 9.91 KB
/
asymetric_crypto.theory.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
ASYMETRIC_CRYPTO
Par rapport à algo sym. :
- désavantages :
- clef plus longues
- bien moins efficient
- ne peut pas être utilisé comme primitive pour des hashs fonction, PRNG (pourquoi ???), et utilise elle-même un algo sym.
comme primitive
- avantages :
- key distribution dans un channel pas nécessairement secure
- par conséquent, pas besoin de modifier la clef fréquemment
Algo asymétrique :
- basé sur trapdoor function asymétrique :
- connaissant e mais ignorant d, tout le monde peut faire Eₑ (chiffrer), mais seule Alice (ayant d) peut faire Dᵈ (déchiffrer)
- d (trapdoor info) est private key
- e est publique key
- publique => peut être distribuée de manière non-secure (mais a toujours besoin d'etre authenticated, via key
authentication)
- confidentialité :
- Eₑ : M -> C, tout le monde peut chiffrer car e est public
- Dᵈ : C -> M, seule Alice peut déchiffrer
- digital signature :
- comme il s'agit d'une permutation, Dᵈ(Eₑ(m)) == x, mais aussi Eₑ(Dᵈ(m))
- on peut donc inverser rôle de D et E pour chiffrer/déchiffrer
- donc :
- Dᵈ : M -> C, seule Alice peut chiffrer
- Dᵈ est appelé aussi S₁, signing fonction
- C est appelé aussi S, signature space, avec des signatures {s₁,...,sₙ}
- Eₑ : S -> M, tout le monde peut déchiffrer car e est public
- ( Eₑ(s) == m ), et non Eₑ, est aussi appelé V₁, verification fonction
- d et e sont alors appelés les signature keys
- donc si e est prouvé être clef publique d'Alice (trust model), seule Alice a pu produire ciphertext (si forgery
impossible) => message chiffré ainsi a entity authentication + message authentication
- si D propage erreur de transmission (quasiment toujours le cas), donne aussi intégrité (contre corruption involontaire)
=> donc non-répudiation.
- Pourrait aussi utiliser aussi checksum pour cela :
- mais le fait que D propage erreur suffit théoriquement
- Cependant, checksum est signé au lieu du message entier :
- pour des raisons de performance, en utilisant algo sym. pour la transmission du message
- aussi semble protéger parfois contre des CCA, qui pourrait retrouver le ciphertext, et ici retrouverait que le hash
Digital signature, 3 éléments :
- key generation : création de d et e
- signature scheme : paire Dᵈ;Eₑ
- trust model : vérification que e appartient à Alice
Key authentication :
- clef publique peut être distribuée sur un channel insecure, mais toujours risque d'attaque man-in-the-middle
=> besoin de key authentication (fait de rattacher une clef à une entity)
- vérifier que Trent distribuant clef publique de Alice :
- il s'agit bien de clef publique d'Alice :
- Trent a fait les checks nécessaires ("trust")
- ne l'a pas modifié
- peut mener notamment à vérifier qu'il s'agisse bien de Trent
- si Trent == Alice (self-signed certificate) : on a soit même fait les checks nécessaires
Certificate :
- tous les certificates sont contenus dans un repositery/public file
- key authentication document, i.e. confirming link between Bob entity information and Bob public key
- first a CSR, i.e. plaintext entity info + signature by Bob private key of entity info + Bob public key
- among entity info:
- Common Name (CN): hostname, e.g. www.google.fr. Can use wilcard * from subdomains: *.google.fr
- Alternative names: can use for other hostnames, using IP instead of DNS name, etc.
- Email address: often must be same as email found on whois HOST. Can be checked by CA.
- Other info
- Trent takes CSR as input and issued a certificate:
- structure:
- CSR + signature by Trent private key of CSR + Trent public key + Trent certificate
- Can also include:
- Validity period, to limit certificate steal impact in time
- Some extensions fields
- Trent can be Bob, in which case it is a self-signed certificate
- Since Trent certificate must be verified itself against another Trent, at some points the chain stops to
a self-signed certificate, i.e. "root Trent"
- Trent certificate is contained inside Bob certificate, so verification can be done locally.
- root Trent: only need to store locally known root Trent certificates to verify any chain of trust they verify,
through other Trents
- CRL (Certificate Revocation List):
- List of certificates revoked by CA. Reasons: private key compromised, CSR was not coming from Bob, etc.
- Can also be hold, i.e. temporarily revoked
- Should always be checked
- Issued periodically (e.g. everyday) by CA. Are signed by CA. Are stored locally by client.
- .crl format is a list of SHA1 checksum of certificates???, includes revokation reason
- Alternative: OCSP (Online Certificate Staus Protocol):
- protocol to get revokation status of a specific certificate
- Is being preferred over CRL now. Is faster and better than fetching URL periodically.
- OCSP server usually owned by CA
- Problem: client disclose identity of server it wants to check (privacy concert).
OCSP stapling can be used to counter this.
- those files can come in different container formats:
- PEM (.pem), often used in open source software. Use base64 encoding on a certificate in DER format (binary).
- raw DER format (.crt, .cer, .der): not often used
- PKCS#7 (.p7c, .p7b)
- PKCS#12 (.p12, .pfx): contains both certificate and private key
- predecessor was PFX (.pfx)
- relies on two points:
- ability of Trent to verify CSR comes from Bob
- trust of Bob in root Trent (i.e. in locally stored root Trent certificates).
- Those two points depend on trust models:
- PKI (Public Key Infrastructure):
- Trent are CA. Non-root CA are intermediate CA.
- root CA are determined by client application, e.g. web browsers (but end-user can add its own ones)
- CA verification that CSR comes from Bob depends on CA:
- some free ones don't check
- paid ones check better
- a premium fee is charged for Extended Validation (EV), which will be shown in web browser with a green bar in the
omnibox
- Web of Trust:
- Trent are "endorsers", determined by client.
Client also choose whether to trust root CA/self-signed certificate itself.
- Trent verification can be anything, e.g. meeting the person in real life.
- cas où identité d'Alice peut se résumer à un id, peu importe personne réelle attaché à l'id :
- ex: personne utilisant pseudonymes/id précis et ne voulant être identifié que par lui
- alors pas de problème de trust
"Message recovery" :
- si certificate a une certaine structure, alors Dᵈ: M' -> S et Eₑ: S -> M', où M' restreint M vers les messages de cette
structure précise ("redundancy")
- M' doit être propre à d et e, et donc infeasible à atteindre via forgery
- deux intérêts :
- V₁ peut être non ( Eₑ(s) == m ) mais ( Eₑ(s)∈ M' ) :
- L'algo doit proposer une manière de deviner pour tout s si Eₑ(c)∈ M', pour un le bon M' (verification fonction)
- permettant de marcher pour tout m, et pas un cas précis
- donc pas besoin de transmettre m, mais seulement e
- rend plus difficile qu'une forgery soit non-suspecte.
En fait, ( Eₑ(s) == m ) pouvant être vu comme une autre manière de voir ( Eₑ(s)∈ M' ), que Eₑ(s) appartienne à un set
restreint de M est nécessaire (que la signature ait une apparence donnée), car sinon (si signature ressemblant à
du garbarge) toute s validerait V₁ rendant toute forgery possible
Le défi est dans le fait de :
- avoir confusion entre e et M', sinon on peut forger un e' avec le même M'
Attaque :
- man-in-the-middle attack :
- Mallory se fait passer pour Trent et donne à Alice non la clef publique de Bob, mais la sienne
- il intercepte message d'Alice, déchiffre avec sa clef publique, modifie ou seulement prend connaissance du message,
chiffre avec clef publique de Bob, et renvoie à Bob
- peut le faire pour Bob aussi
- autres attacks :
- toujours attaques plus rapides que brute-force (comme factoring attack sur RSA) sur tout algo asym. (un peu comme brithday attack sur collision-resistant hash function) => clef plus longue requise (1024 bits asym. ≃ 128 bits sym. ???)
Signature digitale :
- pour que non-répudiation :
- algo avec forgery infeasible
- e appartient bien à Alice (trust model), et E a été utilisé
- d est resté secure
- problème si Alice prétend que d a été volé
- Alice doit donc prendre responsabilité de d jusqu'à révocation (comme une carte bancaire)