Diffie-Hellman et son utilisation TLS / SSL
J'ai du mal à comprendre l'utilisation (non) de Diffie-Hellman (DH) dans TLS.
- DH existe depuis longtemps maintenant, pourquoi presque personne ne l'utilise encore?
- DH n'est utilisé que pour le "partage de clés", pourquoi personne n'utilise le secret DH pour tout crypter? Pourquoi avons-nous besoin d'une clé symétrique, alors que nous avons déjà un secret DH, qui est assez bon pour transporter encore un autre secret? Cela s'applique également à SSH (non?). Je pense qu'il y a une réponse simple à cela, mais je ne l'ai pas trouvée.
Diffie-Hellman est utilisé dans SSL/TLS, comme "Diffie-Hellman éphémère" (les suites de chiffrement avec "DHE" dans leur nom; voir la norme ). Ce qui est très rarement rencontré est "Diffie-Hellman statique" (suites de chiffrement avec "DH" dans leur nom, mais ni "DHE" ni "DH_anon"): ces suites de chiffrement nécessitent que le serveur possède un certificat contenant une clé publique DH, qui est rarement prise en charge pour diverses raisons historiques et économiques, parmi lesquelles la principale est la disponibilité d'une norme gratuite pour RSA ( PKCS # 1 ) tandis que la norme correspondante pour Diffie-Hellman ( x9.42 ) coûte une centaine de dollars, ce qui n'est pas beaucoup, mais suffisant pour dissuader la plupart des développeurs amateurs.
Diffie-Hellman est un protocole d'accord clé , ce qui signifie que si deux parties (par exemple, le client SSL et le serveur SSL) exécutent ce protocole, elles se retrouvent avec un secret partagé [~ # ~] k [~ # ~]. Cependant, ni le client ni le serveur ne parviennent à choisir la valeur de [~ # ~] k [~ # ~]; de leur point de vue, [~ # ~] k [~ # ~] semble généré de façon aléatoire. C'est secret (seuls eux savent [~ # ~] k [~ # ~]; les espions sur la ligne ne le font pas) et partagé (ils obtiennent tous les deux la même valeur [~ # ~] k [~ # ~]), mais pas = choisi. Ce n'est pas du cryptage. Un secret partagé [~ # ~] k [~ # ~] est cependant suffisant pour traiter des téraoctets de données avec un algorithme de cryptage symétrique (même [~ # ~] k [~ # ~] pour chiffrer d'un côté et déchiffrer de l'autre), et c'est ce qui se passe en SSL.
Il existe cependant un algorithme bien connu de chiffrement asymétrique appelé RSA. Avec RSA, l'expéditeur peut crypter un message [~ # ~] m [~ # ~] avec la clé publique du destinataire, et le destinataire peut le décrypter et récupérer [~ # ~] m [~ # ~] en utilisant sa clé privée. Cette fois, l'expéditeur peut choisir le contenu de [~ # ~] m [~ # ~].
Donc, votre question pourrait être: dans un monde RSA, pourquoi nous soucions-nous du AES? La réponse réside dans les points suivants:
Il existe des contraintes sur [~ # ~] m [~ # ~]. Si la clé publique du destinataire a la taille n (en octets, par exemple n = 256 pour une clé RSA de 2048 bits), alors la taille maximale de [~ # ~] m [~ # ~] est n-11 octets. Afin de crypter un message plus long, nous devons le diviser en blocs suffisamment petits et inclure un mécanisme de réassemblage. Personne ne sait vraiment comment faire cela en toute sécurité. Nous avons de bonnes raisons de croire que RSA sur un seul message est sûr, mais des faiblesses subtiles peuvent se cacher dans tout système de fractionnement et de réassemblage et nous ne sommes pas à l'aise avec cela. C'est déjà assez mauvais avec chiffres symétriques , où la situation mathématique est plus simple,
Même si nous pouvions gérer le fractionnement et le remontage, il y aurait une expansion de taille. Avec une clé RSA de 2048 bits, un bloc de message interne a la taille d'au plus 245 octets, mais lorsqu'il est chiffré, il donne une séquence de 256 octets. Cela gaspille notre énergie vitale, c'est-à-dire la bande passante du réseau. Le chiffrement symétrique n'entraîne qu'une surcharge limitée (enfin, SSL ajoute une légère surcharge proportionnelle à la taille des données, mais il est beaucoup plus petit que ce qui se produirait avec un protocole RSA uniquement),
Comparé à AES, RSA est lent comme l'enfer,
Nous aimons vraiment avoir la possibilité d'utiliser des protocoles d'accord clés comme DH au lieu de RSA. Dans les temps anciens (avant 2001), le RSA était breveté mais pas le DH, donc le gouvernement américain recommandait le DH. De nos jours, nous voulons pouvoir changer d'algorithme en cas de rupture. Afin de prendre en charge les protocoles d'accord clés, nous avons besoin d'un chiffrement symétrique, nous pouvons donc tout aussi bien l'utiliser avec RSA. Il simplifie la mise en œuvre et l'analyse des protocoles.
Voir cette réponse pour une description détaillée du fonctionnement de SSL.
Je pense que Security Now ep. 412 "SSL & Perfect Forward Secrecy" a ce que vous voulez.
Peut-être que vous devriez simplement chercher lire leur transcription pour 'Diffie', parce que ces podcasts ont beaucoup de nouvelles/de trucs divers avant d'arriver au point.
Citant:
Mais de nombreux navigateurs aujourd'hui, et de nombreux serveurs aujourd'hui, prennent en charge ce qu'on appelle Diffie-Hellman Ephemeral, DHE. Éphémère signifie spécifiquement "juste pour le moment". Il s'agit donc de DHE, Diffie-Hellman Ephemeral, est une technologie qui est découplée - et c'est la clé, "découplée" - de l'authentification du serveur. Et comme je viens de le dire avec Diffie-Hellman, un tiers observant l'échange n'a aucune connaissance. C'est exactement la protection que nous voulons dans nos connexions SSL contre l'archivage à long terme. L'archivage à long terme et la révélation subséquente de la clé privée du serveur ne donnent à personne d'aide pour casser la protection éphémère Diffie-Hellman. "
Ils expliquent spécifiquement pourquoi il n'est pas encore pleinement utilisé:
Mais Microsoft ne propose pas d'éphémère Diffie-Hellman [...] qui possède également RC4, qui est le chiffre [...]. Malheureusement, ils sont tous CBC, Cipher Block Chaining. Et c'est le protocole de chiffrement qui est vulnérable à l'attaque BEAST. "
Ici, ils se réfèrent aux tests SSLLabs qu'ils ont décrits dans ep. 395 (et 396).