Après avoir abordé les différents protocoles constituant TLS dans la partie précédente, cet article va réaliser un focus sur le ClientHello/ServerHello du protocole handshake comme étant la partie fondamentale de TLS puisque permettant la négociation des algorithmes de chiffrement.
Le ClientHello contient un ensemble de suites cryptographiques que le client est prêt à utiliser au cours de la session. Il est attendu du serveur qu’il en sélectionne une parmi celles-ci, après comparaison avec celles qu’il prend en charge et accepterait d’utiliser. Cette sélection affecte la manière dont seront utilisées les clés cryptographiques pour protéger les paquets records échangés après le Handshake, qui transportent notamment les données applicatives. La procédure de négociation des clés est elle-même modifiée en fonction de la suite retenue. La forme générale d’une suite cryptographique est:
Protocole_Key Exchange Protocol_WITH_Symetric Encryption Algorithm_Encryption Mode_Hash Algorithm
Chaque suite constitue une combinaison des mécanismes cryptographiques suivants:
- Key Exchange Protocol: c’est le mécanisme d’échange de clés, qui précise un algorithme d’échange et éventuellement l’algorithme de signature utilisé pour authentifier les échanges: RSA, ECDHE\_RSA et PSK en sont quelques exemples ;
- Symetric Encryption Algorithm: Les mécanismes assurant la confidentialité des données échangées après le handshake, définis: soit comme la composition d’un algorithme de chiffrement et d’une fonction de hachage utilisée en mode HMAC, telle AES_256_CBC_SHA384, soit comme un mode de chiffrement intègre, aussi appelé mode combiné, offrant simultanément chiffrement et intégrité, tel AES_256_GCM;
- Encryption Mode: le mode de chiffrement par bloc utilisé avec l’algorithme choisie précédemment;
- Hash Algorithm: l’algorithme de hachage utilisé pour assurer l’intégrité des messages.
Par exemple, la suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 représente l’association du mécanisme d’échange de clés ECDHE_RSA avec le mode de chiffrement intègre AES_256_GCM complété de SHA384 pour la dérivation des secrets.
1. Key Exchange Protocol:
Tous les protocoles d’échange de clef ci-dessous permettent d’obtenir un pre_master_secret, le master_secret est généré par l’application de la fonction PRF, tel que: PRF(pre_master_secret; « mastersecret »; ClientHello.random + ServerHello.random) où PRF est la fonction itérative de hash définie par la suite cryptographique telle que :
où la somme indique la concaténation, A(0) = seed, A(i) = HMAC_hash(secret, A(i-1)) et n est fonction de la valeur de sortie nécessaire. Pour le master secret, la taille est de 48 octet soit deux itérations avec P_SHA-256. À partir de ce secret, la clef de session est générée par la formule:
PRF(master secret, « keyexpansion », ClientHello.random + ServerHello.random)
tel que le résultat obtenu soit la concaténation de key.mac.client, key.mac.server, key.encryption.client, key.encryption.server, IV.client et IV.server. Cette méthode est définie par la RFC 5246.
Il existe plusieurs méthodes d’échange de clés, dont certaines qui n’exigent pas l’authentification du serveur. Cependant, en l’absence de cette protection, l’échange de clés est exposé à des attaques par homme du milieu susceptibles de compromettre la sécurité de l’ensemble des échanges. Par conséquent, l’authentification du serveur est fortement recommandée.
Dans le cas général, l’échange de clés s’appuie, soit sur le chiffrement asymétrique d’un secret à l’aide de la clé publique du serveur (RSA par exemple), soit sur l’algorithme Diffie–Hellman dans les cas les plus courants.
Échange de clé avec Diffie-Hellman (DH):
L’échange des clés basé sur DH est définie par la RFC2631, il existe plusieurs variantes comme :
Diffire-Hellman Ephemeral (DHE), Elliptic Curve Diffie-Hellman (ECDH), Elliptic Curve Diffie-Hellman
Ephemeral (ECDHE), Anonymos Diffie-Hellman (ADH).
DHE fonctionne de la manière suivante: les paramètres publiques de DH sont échangés, ils peuvent varier d’une session à l’autre ce qui les rend plus dur à casser par force brute. Ici, pour éviter l’attaque de l’homme au milieu, le serveur et le client prouve que c’est eux qui ont bien généré les valeurs de DH. Pour ce faire, il existe différentes solutions:
- Signer les valeurs de DH avec sa clé privée (RSA, DSS, ECDSA).
- Authentifier l’échange DH avec une clé secrète partagée (PSK).
Échange de clé avec RSA:
L’algorithme sert alors à la fois dans l’étape KeyExchange ainsi que dans l’authentification. Le schéma ci-dessous représente l’échange des clés avec RSA.
La confidentialité persistante Perfect Forward Secrecy (PFS), est une propriété en cryptographie qui
garantit que la découverte par un adversaire de la clé privée d’un correspondant (secret à long terme) ne
compromet pas la confidentialité des communications passées. L’utilisation de RSA pour l’échange des
clés n’assure pas une protection PFS.
Échange de clé avec Pre-Shared Key (PSK):
PSK est un algorithme basé sur des clefs échangées à l’avance défini par la RFC 4279. Il souffre donc du problème de l’échange de ces clefs via un canal sécurisé. En pratique, il n’est que peu utilisable puisqu’il impose au client de connaître à l’avance ces clefs, ce qui n’est que très rarement possible. Quand on utilise PSK pour l’échange des clés le pre_master_key est formé de la façon suivante: Si le PSK est de N octets on commence par concaténer un uint16 avec la valeur de N, N zéro octets, un second uint16 avec la valeur de N et le PSK. Le schéma ci-dessous représente l’échange des clés avec PSK:
Recommandations:
Authentifier le serveur à l’échange de clés: Au cours d’un échange de clés, le serveur doit être authentifié par le client (afin d’éviter les attaques du type MITM).
La taille des clés recommandée pour l’utilisation de RSA est de 4096 bits.
Privilégier Diffie-Hellman Ephemeral qui permet l’utilisation des paramètres DH temporaires signés par la clef maître (DHE avec des tailles de groupe de 3072 bits ou ECDHE avec des courbes d’ordre P-256), pour éviter les attaques du type MITM et assurer la PFS.
2. Symetric Encryption Algorithm:
Le pre_master_key négocié à l’aide de l’échange précédent est dérivé de part et d’autre en un master secret, duquel est notamment dérivée la clé de chiffrement symétrique utilisée pour la protection en confidentialité des échanges qui suivent la phase de négociation.
Recommandations:
- Privilégier le chiffrement avec AES-256 ou AES-128.
- Utiliser les suites mettant en oeuvre les algorithmes de chiffrement par bloc comme Camellia.
- Triple DES ne devrait pas être maintenu. Cependant il est toléré, sous réserve que les clés de chiffrement associées soient renouvelées au minimum à chaque gigaoctet de données applicatives échangées.
- DES, IDEA et RC4 sont aujourd’hui des algorithmes trop faibles pour garantir une bonne sécurité.
3. Hash Algorithm:
C’est le mécanisme de protection des données, pour éviter qu’un attaquant puisse modifier les messages chiffrés. Une fois la session TLS établie, chaque paquet record envoyé est protégé en intégrité. On utilise pour cela HMAC avec comme fonction de hachage: SHA1 ou SHA2. Lorsque la suite cryptographique n’utilise pas de mode de chiffrement intègre, il s’agit d’un motif d’intégrité calculé par le mode HMAC, qui s’appuie sur une fonction de hachage.
La construction HMAC, proposée par Bellare, Canetti, et Krawczyk en 1996, est standardisée et utilisée dans de nombreux protocoles. On définit HMAC(m) par:
Ainsi, la sécurité garanties par les HMAC est équivalente à deux fois que celle garantie par une fonction de hachage hash.
Recommandations:
- Le HMAC permettant l’authentification doit être construit à l’aide d’un représentant de la famille SHA-2 : SHA-256 ou bien SHA-384.
- L’usage de HMAC construits à l’aide de SHA-1 est toléré. Par contre l’utilisation de SHA-1 seule est considéré comme désuet et ne devrait plus être utilisé.
4. Encryption Mode:
Il existe plusieurs mode de chiffrement pour les algorithmes symétriques :
CBC: défini par le schéma suivant:
CBC-HMAC: ce mode est une combinaison entre le mode CBC pour assurer le chiffrement et HMAC pour l’intégrité. Le calcul du HMAC porte sur les données chiffrées avec CBC afin d’éviter les fuites d’informations: Une telle extension est dite encrypt_then_mac.
GCM: Galois/Counter Mode est un mode de chiffrement par bloc qui utilise un hachage universel sur un champ binaire de Galois pour fournir un chiffrement authentifié. Il permet de garantir la confidentialité et l’authentification à la fois. L’opération de chiffrement authentifiée par GCM comporte quatre entrées: une clé secrète, un vecteur d’initialisation (IV), un texte en clair et une entrée pour des données authentifiées supplémentaires (AD). Il a deux sorties, un texte chiffré dont la longueur est identique au texte en clair, et une étiquette d’authentification (TAG). Le mode GCM est défini par le schéma suivant:
CCM (Counter-Mode/CBC-Mac): comme son nom l’indique, le mode CCM combine le CBC-HMAC avec un compteur. Ces deux primitives sont appliquées de manière «authentifiée puis chiffrée», c’est-à-dire que CBC-MAC est d’abord calculé sur le message pour obtenir une étiquette TAG. Le message et l’étiquette sont alors chiffrés en utilisant le mode compteur (CTR). Un point clé est que la même clé de chiffrement peut être utilisée pour les deux, à condition que les valeurs de compteur utilisées dans le chiffrement ne soient pas en collision avec le vecteur (IV) d’initialisation utilisé dans l’authentification.
Recommandations:
- Utiliser des modes qui garantissent le chiffrement et l’intégrité (authentification) comme GCM (seul supporté sur TLS), CCM, CBC-HMAC.
- Le mode de chiffrement CBC est systématiquement dégradé à Standard malgré une sécurité parfaite dans le cas d’une connexion effectuée depuis un navigateur moderne.
