Quel est l'état de sécurité actuel de l'échange de clés Diffie-Hellman?
Il existe un site Web faiblessedh.org, dont le nom à lui seul provoquerait certainement un certain sentiment d'incertitude dans l'utilisation de la DH chez les personnes qui ne sont pas des experts à mon humble avis. Une personne bien informée pourrait-elle bien vouloir dire quelque chose sur l'état de sécurité actuel de DH, c'est-à-dire quelles sont les principales précautions, le cas échéant, dont on doit être conscient dans les applications de DH aujourd'hui?
Je suis particulièrement intéressé par la taille de clé minimale requise pour une utilisation en SSL, mais j'apprécierai des informations supplémentaires.
Le site Web faiblessedh.org concerne la attaque Logjam . Contrairement à ce que le nom du site Web peut suggérer aux imprudents, il ne s'agit pas de DH faible; il s'agit plutôt de faire les choses faiblement lors de l'utilisation de DH.
Diffie-Hellman fonctionne dans un sous-groupe multiplicatif d'entiers modulo un nombre premier p. Pour faire de la DH, vous utilisez des paramètres DH qui sont:
- p: un grand nombre premier, appelé "module"
- q: un diviseur de p - 1, appelé "ordre de sous-groupe"
- g: un module entier p de commande q (cela signifie que le plus petit entier k> 0 tel que g k = 1 mod p est k = q)
Pour que DH soit sûr, vous avez besoin des éléments suivants:
p doit vaincre la tentative de logarithme discret via Index Calculus . Cela signifie que p doit être suffisamment grand et ne doit pas non plus avoir de "structure spéciale", comme être très proche d'une puissance de 2, car ces structures permettent des améliorations dans le calcul d'index. Il se trouve que les exigences de taille pour DH sont à peu près les mêmes que celles de RSA, bien que la raison sous-jacente soit complexe et partiellement coïncidente. Donc, fondamentalement, utilisez un aléatoire p de 2048 bits, et tout ira bien.
q doit être premier ou avoir un diviseur premier dont la taille est suffisante pour vaincre les algorithmes génériques du logarithme discret. Si la taille (en bits) du plus grand diviseur premier de q est z, alors les algorithmes génériques ont un coût en 2 z/2. Pour de meilleurs résultats, faites en sorte que q soit un nombre premier de 256 bits ou plus.
Les systèmes qui utilisent les paramètres pour effectuer un échange de clé DH doivent générer un entier aléatoire entre 1 et q - 1 uniformément, en utilisant une source d'aléatoire cryptographiquement forte, bien sûr. Si q est premier et supérieur à 256 bits, il suffit de choisir une valeur aléatoire de 256 bits pour atteindre 128 bits de sécurité. Cependant, si q n'est pas premier, les choses sont plus complexes: si q a la taille r bits, et le plus grand diviseur premier de q a une taille e bits, et e ≥ 256, alors on peut choisir une valeur aléatoire x de taille r - ( e - 256) bits pour obtenir la "sécurité 128 bits" habituelle.
Lorsque p est un soi-disant "nombre premier sûr", alors p = 2 r + 1 pour un nombre premier r, donc pour tout générateur g qui n'est pas 1 ou p - 1, l'ordre de g sera soit r ou 2 r, il suffit donc de générer des clés secrètes DH x = comme des valeurs aléatoires de 257 bits. Les "nombres premiers sûrs" ne sont en fait pas plus sûrs que les autres nombres premiers, sauf pour ce point: ils tolèrent le choix de clés secrètes DH relativement petites pour n'importe quel générateur.
Last but not least, DH est un algorithme d'échange de clés qui ne fournit pas, par nature, d'authentification ou de confidentialité. DH n'est "sûr" que lorsqu'il est utilisé dans un protocole qui utilise DH et d'autres algorithmes avec une intégration appropriée pour atteindre des caractéristiques recherchées telles que la confidentialité et l'intégrité des données.
En parlant de cela, certaines (nombreuses) implémentations SSL/TLS ont mal agi, dans la mesure où elles ont accepté avec plaisir de faire de la DH avec des paramètres faibles, en particulier un module de 512 bits. Le protocole lui-même est sous-optimal dans sa gestion de DH car le message ServerKeyExchange permet au serveur d'envoyer les paramètres DH p et g au client, mais pas q, laissant le client un peu dans le noir. Ainsi, le client doit soit "jouer en toute sécurité" et générer sa clé dans la plage complète de 1 .. p - 1, soit essayer d'utiliser un exposant plus court (disons, 256 bits, pas 2048) pour un coût de calcul réduit, mais éventuellement à risque de faiblesse dans le cas où l'ordre des sous-groupes q n'est pas premier. Une meilleure conception aurait permis au serveur d'envoyer la valeur de q et la taille du plus grand diviseur premier de q. À cet égard, les suites de chiffrement ECDHE de SSL/TLS (DH traduites en courbes elliptiques) ont une meilleure conception.
Pour une réponse pratique si vous configurez votre serveur SSL/TLS: vous devez utiliser un module d'au moins 2048 bits et un générateur g tel que l'ordre de g est un nombre premier q d'au moins 256 bits; vous pouvez également utiliser un module p qui est un "nombre premier sûr" (l'ordre de g sera alors soit un très grand nombre premier, soit deux fois un très gros prime, ce qui est presque aussi bon). Certaines personnes se sentent plus en sécurité lorsqu'elles génèrent elles-mêmes leurs paramètres DH (*) au lieu de réutiliser des valeurs existantes; si c'est ce qu'il faut pour vous permettre de dormir la nuit, faites-le.
(*) Les gens ne génèrent jamais eux-mêmes leurs paramètres DH; ils utilisent un ordinateur. Mais nous parlons ici de psychologie de toute façon.
Tout d'abord, pas de panique, l'algorithme de Diffie-Hellman est tout à fait correct s'il est utilisé correctement (avec le bon ensemble de paramètres).
Laissez-moi vous expliquer quelques préliminaires:
- Quel est le protocole SSL/TLS?
C'est le protocole sous-jacent utilisé dans HTTPS qui empêche l'écoute et la falsification des données envoyées dans le canal. Il utilise le protocole diffie-hellman pour échanger des clés entre le client et le serveur.
- Que sont les suites de chiffrement?
Le protocole SSL/TLS a été conçu pour être extensible, il est capable d'utiliser plusieurs algorithmes pour crypter et signer les données, ces packages interchangeables sont appelés suites de chiffrement, vous pouvez avoir TLS_RSA_WITH_RC4_128_MD5 comme suite de chiffrement qui utilise RSA pour l'échange de clés, RC4 pour le vrac cryptage des données et MD5 pour la signature.
Quel est LogJam?
Maintenant, il existe certaines de ces suites de chiffrement appelées EXPORT-GRADE (par exemple TLS_RSA_EXPORT_WITH_RC4_40_MD5), elles sont intentionnellement faibles en raison de la réglementation des États-Unis en matière d'exportation sur les algorithmes cryptographiques. Ces suites de chiffrement ont une longueur de clé courte et peuvent facilement être brisées, si quelqu'un ne les désactive pas sur leur serveur et que le client les utilise, les clés partagées peuvent être divulguées et le cryptage peut être brisé par un attaquant. Il y a eu une attaque sur RSA nommée FREAK et une sur Diffie-Hellman nommée LogJam.
Maintenant, si le client peut être forcé d'utiliser des suites de chiffrement EXPORT-GRADE et si le serveur les prend en charge, un attaquant peut faire une attaque MITM en cassant l'algorithme diffie-hellman en raison de l'utilisation d'une longueur de clé courte. C'est à cela que sert LogJam.
Il y avait aussi une autre vulnérabilité où certains serveurs Web utilisaient des paramètres diffie-hellman par défaut de longueur 1024 qui est également cassé.
Remarque: tout dépend des paramètres utilisés dans les algorithmes, il n'y a rien de mal à l'algorithme Diffie-Hellman lui-même.
Que faire maintenant?
Si vous utilisez des navigateurs modernes et que vous les maintenez à jour, ils empêchent déjà cette attaque de se produire.
Si vous exécutez un serveur Web, assurez-vous que vous utilisez les meilleures pratiques pour configurer vos versions compatibles SSL/TLS et les suites de chiffrement sous-jacentes.
Quant à la taille de clé minimale, 1024 bits sont hors de portée des attaquants normaux, mais pas de l'État-nation. Le bit 2048 est sûr. Vous pouvez également utiliser ECDHE qui est diffie-hellman sur la courbe elliptique et vous offre essentiellement le même niveau de sécurité avec une longueur de clé plus courte.