TLS RSA
NULL
RC4
128
3DES-EDE
CBC
SHA
AES
128
CBC
SHA
SHA256
GCM
SHA256
AES
256
CBC
SHA
SHA256
GCM SHA384
CAMELLIA
128
CBC SHA
CAMELLIA
256
CBC
SHA
SEED
CBC
SHA
IDEA
DES
DH
RSA
DES
3DES
EDE
CBC
SHA
CAMELLIA
128 CBC SHA
CAMELLIA
256 CBC SHA
SEED
CBC SHA
AES
128
CBC
SHA
SHA256
GCM
SHA256
AES
256
CBC
SHA
SHA256
GCM
SHA384
DSS
RSA
EXPORT
Anon
DHE
PSK
RC4
128
NULL
3DES
EDE
CBC
SHA
AES
128
CBC
SHA
SHA256
GCM
SHA256
AES
256
CBC
SHA
SHA384
GCM
SHA384
ECDHE RSA AES
256
CBC
SHA SHA384
GCM
SHA384
NULL
CHACHA20
POLY1305
SHA256
ECDSA
3DES
EDE
CBC
SHA
AES
128
GCM
SHA256
CBC
SHA256
SHA
RC4
128
PSK
3DES
EDE
CBC
SHA
AES
128
CBC
SHA
SHA256
GCM
SHA256
AES
256
CBC
SHA
SHA384
GCM
SHA384
RC4
128
NULL
ECDH
Anon
PSK
3DES
EDE
CBC
SHA
AES
128
CBC
SHA
SHA256
GCM
SHA256
AES
256
CBC
SHA
SHA384
GCM
SHA384
CHACHA20
POLY1305
SHA256
RC4
128
NULL
SRP SHA
3DES
EDE
CBC
SHA
AES
128
CBC
SHA
AES
256
CBC
SHA
RSA
DSS
NULL KRB5
IDEA
3DES
EDE
CBC
SHA
DES
RC4
(ANY)
EXPORT
RSA
PSK
AES
128
CBC SHA
SHA256
GCM
SHA256
AES
256
CBC
SHA
SHA384
GCM SHA384
RC4
128
CHACHA20
POLY1305
SHA256
NULL
Protocole Key Exchange
Protocol
Authentication
Protocol
Symetric
Encryption
Algorithm
Encryption
Mode
Hash
Algorithm
Recommand´
eStandard D´
esuet Dangereux
Cartographie des suites
cryptographiques TLS
Cette mindmap repr´
esente l’´
etat de l’art en mati`
ere de suites
cryptographiques. Elle a ´
et´
e r´
ealis´
ee `
a des fins pratiques pour
permettre une lecture rapide des ´
el´
ements dangereux. Pour des
raisons de lisibilit´
e, les branches dites dangereuses telles que les
suites EXPORT ou NULL sont tronqu´
ees apr`
es l’´
el´
ement les
d´
eterminant comme dangereuses.
Cette carte repr´
esente les recommandations en accord avec les
RFC, le NIST et l’ANSSI, telles que:
Recommand´
ed´
esigne les algorithmes et les suites
cryptographiques consid´
er´
es comme sˆ
urs au vu de l’´
etat de
l’art.
Standard d´
esigne un algorithme ou une ciphersuite n’ ´
etant
sujet `
a aucune recommandation mais n’´
etant pas sujet `
a une
contre-indication majeure.
D´
esuet d´
esigne les algorithmes ´
etant consid´
er´
es aujourd’hui
comme faibles et expos ´
es `
a certaines attaques. Cependant, ou
qu’une mitigation existe cˆ
ot´
e client, ou que ce protocole soit
n´
ecessaire pour fonctionner avec d’anciens navigateurs, ils
restent possibles `
a utiliser en acceptant le risque induit.
Dangereux d´
esigne les ciphersuites ne permettant aucune
protection de la confidentialit´
e, de l’authenticit´
e ou de l’int´
egrit´
e.
Elles peuvent ˆ
etre class´
ees ainsi pour des principes de
fonctionnement (Anon et NULL), des faibles tailles de clef
(DES,IDEA,EXPORT), des faiblesses majeures dans le
m´
ecanisme de chiffrement (RC4).
De plus les algorithmes sont repr ´
esent´
es dans l’ordre de lecture de
la suite cryptographique, c’est `
a dire:
Protocole (Ici forc ´
ement TLS)
Key Exchange Protocol (en soulign´
e) est le protocole utilis´
e
pour l’´
echange de clef.
Authentication Protocol (en italique) est le protocole assurant
l’authenticit´
e de la connexion en ´
etant utilis´
e pour la signature
de la communication. Cette ´
etape peut ˆ
etre facultative et `
a la
charge de l’algorithme d’ ´
echange de clef.
Symetric Encryption Algorithm est l’algorithme utilis´
e pour
chiffrer la communication.
Encryption Mode est le mode de chiffrement par bloc utilis´
e
avec cet algorithme.
Hash algorithm est l’algorithme de hash utilis´
e pour le contrˆ
ole
d’int´
egrit´
e des messages.
Pour des raisons pratiques les algorithmes exp´
erimentaux n’ont pas
´
et´
e repr´
esent´
es, tel que CECPQ1 ECDSA, suites cryptographiques
test´
ees par Google dans son navigateur Chrome pour la
Cryptographie Post Quantique. De mˆ
eme, l’algorithme GOST
utilis´
e sous ses formes GOSTR341094 et GOSTR341001 n’a pas
´
et´
e repr´
esent´
e du fait du manque d’utilit´
e et de son danger. En effet
les attaques actuelles permettent de s’attaquer `
a l’algorithme de
chiffrement sym´
etrique GOST28147 en 2101 op ´
erations.
Les suites EXPORT sont toutes consid´
er´
ees
comme dangereuses depuis les ann´
ees 90,
date de leur mise en place.
Les suites KRB5 sont bas´
ees sur
l’impl´
ementation de Kerberos en TLS. `
A l’image
de l’authentification sur le domaine, le client
utilise un ticket pour s’authentifier. Le client
envoie ensuite un pre master secret de 48 bits
al´
eatoires chiffr´
e avec la clef de session
Kerberos encapsul´
ee dans le ticket de session.
L’algorithme 3DES-EDE ne doit
ˆ
etre maintenu qu’`
a des fins de
compatibilit´
e.
Les ´
echanges de clefs anonymes sont
facilement attaquables `
a l’aide d’une
interception, l’´
echange doit toujours ˆ
etre
sign´
e.
Les suites DH sont des algorithmes d’ ´
echanges
de clef reposant sur la difficult´
e de calculer des
factorisations dans des groupes finis. Les suites
DHE permettent en plus de garantir le Perfect
Forward Secrecy (PFS) c’est `
a dire la s´
ecurit ´
e
des communications ant´
erieures en cas de
compromission de la clef, en g´
en´
erant une clef
`
a chaque session.
Le mode de chiffrement CBC est
syst´
ematiquement d´
egrad´
e`
a Standard malgr´
e
une s´
ecurit ´
e parfaite dans le cas d’une
connexion effectu ´
ee depuis un navigateur
moderne. En effet, l’algorithme souffre d’une
attaque par padding qui n’est pas corrig ´
ee sur
les anciens navigateurs, cette attaque s’appelle
POODLE.
Dans le cas d’un DHE, DSS
incorpore ´
egalement RC4
128 bits comme algorithme
de chiffrement. RC4 est
dangereux et ne doit jamais
ˆ
etre utilis´
e.
L’algorithme RC4 est
vuln´
erable `
a un biais dans
son PRNG, cette attaque
s’appelle Bar-Mitzvah.
La combinaison
*DHE *SA WITH AES 256 GCM SHA384 est la
combinaison recommand´
ee du fait de ses propri´
et´
es
de PFS et de la solidit´
e actuelle de AES256. De plus
le mode de chiffrement GCM est un mode authentifi´
e
excluant les attaques par padding dont CBC a ´
et´
e
victime.
L’algorithme CHACHA20 est bas´
ee
sur la RFC7905 et d´
erive de
SALSA20, POLY1305 permet
d’assurer une probabilit´
e de
collision faible.
PSK est utilis´
e comme protocole
d’´
echange permettant ´
egalement de
g´
erer l’authentification du serveur. Il
repose sur le partage pr ´
ealable de la
clef sym´
etrique de communication en
accord avec la RFC 4279 - §2.
PSK est tr`
es utile dans un contexte de
syst`
emes embarqu´
es.
DES et IDEA sont aujourd’hui des
algorithmes trop faibles pour garantir
une bonne s´
ecurit ´
e.
SRP est utilis´
e comme algorithme pour
l’authentification et l’´
echange de clefs
comme sp´
ecifi´
e dans la RFC 2945 - §3.
Le serveur stocke un HMAC sal ´
e du
username et du password hash´
es,
l’´
echange repose sur les propri ´
et´
es du
groupe Z/pZ. Cette authentification est
g´
er´
ee par les extensions de TLS.
Le choix de classer SRP comme
deprecated est dˆ
u`
a l’utilisation
exclusive de SHA-1 dans les
m´
ecanismes de HMAC.
SRP peut fonctionner en
mode authentifi´
e avec DSS
ou RSA. Le SKE est alors
sign´
e par la clef priv ´
ee.
RSA est utilis´
e comme protocole
d’authentification du serveur et
d’´
echange de clefs tel que d´
efini par la
RFC 5246 - §8.1. Le protocole consiste
en la g´
en´
eration d’un pre master secret
par le client qui l’envoie chiffr´
e au
serveur. Dans le cas de RSA PSK, la
clef partag ´
ee consiste alors en la
longueur du bloc (par d´
efaut 48), la
version et 46 bits al´
eatoire concat´
en´
es
avec la longueur du PSK et le PSK (en
accord avec la RFC 4279 - §4).
SHA-1 est consid´
er´
e comme d´
esuet et
ne devrait plus ˆ
etre utilis´
e.
AES 128 bits est recommand´
e par
l’ANSSI, en revanche la CNSA
recommande AES 256 bits.
Ce document est un travail de Pierre d’Huy sous licence CC-by-sa
v1.3 – pierre.dhuy.net
1 / 1 100%
La catégorie de ce document est-elle correcte?
Merci pour votre participation!

Faire une suggestion

Avez-vous trouvé des erreurs dans linterface ou les textes ? Ou savez-vous comment améliorer linterface utilisateur de StudyLib ? Nhésitez pas à envoyer vos suggestions. Cest très important pour nous !