Pourquoi ne puis-je pas MitM un échange de clés Diffie-Hellman?
Après avoir lu la réponse choisie de "Diffie-Hellman Key Exchange" en anglais 5 fois je ne peux pas, pour la vie de moi, comprendre comment cela me protège contre une attaque MitM.
Étant donné l'extrait suivant (de réponse de tylerl ):
- Je trouve deux nombres premiers g et p et je vous dis ce que elles sont.
- Vous choisissez ensuite un numéro secret ( a ), mais vous ne le dites à personne. Au lieu de cela, vous calculez gune mod p et renvoyez-moi ce résultat. (Nous appellerons cela [~ # ~] a [~ # ~] car il provient de a ).
- Je fais la même chose, mais nous appellerons mon numéro secret b et le nombre calculé [~ # ~ ] b [~ # ~] . Je calcule donc gb mod p et vous envoie le résultat (appelé " [~ # ~] b [~ # ~] ")
- Maintenant, vous prenez le numéro que je vous ai envoyé et effectuez exactement la même opération avec it. C'est donc Bune mod p .
- Je fais la même opération avec le résultat que vous m'avez envoyé, donc: Ab mod p .
Voici les mêmes 5 étapes avec Alpha contrôlant le réseau:
- Vous essayez de m'envoyer
getp, mais Alpha intercepte et apprendgetp - Vous venez avec
aet essayez de m'envoyer le résultat dega mod p(A), mais Alpha intercepte et apprendA - Alpha arrive avec
bet vous envoie le résultat degb mod p(B) - Vous exécutez
Ba mod p - Alpha s'exécute
Ab mod p
Pendant tout ce processus, Alpha prétend être toi et crée un secret partagé avec moi en utilisant la même méthode.
Maintenant, vous et Alpha, et Alpha et moi avons chacun des paires de secrets partagés.
Vous pensez maintenant qu'il est prudent de me parler en secret, parce que lorsque vous m'envoyez des messages chiffrés avec votre secret Alpha les déchiffre en utilisant le secret créé par vous et Alpha, les crypte en utilisant le secret créé par Alpha et moi, puis me les envoie . Quand je vous réponds, Alpha fait la même chose à l'envers.
Est-ce que j'ai râté quelque chose?
Diffie-Hellman est un protocole d'échange de clés mais ne fait rien pour l'authentification.
Il existe une manière conceptuelle de haut niveau de voir cela. Dans le monde des réseaux informatiques et de la cryptographie, tout ce que vous pouvez voir, en réalité, ce sont des zéros et des uns envoyés sur des câbles. Les entités ne peuvent être distinguées les unes des autres que par les zéros et ceux qu'elles peuvent ou ne peuvent pas envoyer. Ainsi, l'utilisateur "Bob" n'est vraiment défini que par sa capacité à calculer des choses que les non-Bobs ne peuvent pas calculer. Puisque tout le monde peut acheter les mêmes ordinateurs, Bob ne peut être Bob que par sa connaissance d'une valeur que seul Bob connaît.
Dans l'échange Diffie-Hellman brut que vous présentez, vous parlez à une entité qui est censée générer une valeur secrète aléatoire à la volée, et utilisez-la. Tout le monde peut faire une telle génération aléatoire. À aucun endroit dans le protocole, il n'y a d'opération que seul un Bob spécifique peut effectuer. Ainsi, le protocole ne peut réaliser aucune sorte d'authentification - vous ne savez pas à qui vous parlez. Sans authentification, l'emprunt d'identité est possible, et cela comprend l'emprunt d'identité double simultané, mieux connu sous le nom de Man-in-the-Middle . Au mieux, Diffie-Hellman brut offre une fonctionnalité plus faible: bien que vous ne sachiez pas à qui vous parlez, vous savez toujours que vous parlez à la même entité tout au long de la session.
Un seul algorithme cryptographique ne vous mènera pas loin; tout protocole de communication significatif assemblera plusieurs algorithmes de sorte que certaines caractéristiques de sécurité définies soient atteintes. Un bon exemple est SSL/TLS ; un autre est SSH . Dans SSH, un échange de clés Diffie-Hellman est utilisé, mais la partie publique du serveur (son g b mod p ) est signé par le serveur. Le client sait qu'il parle au bon serveur car le client se souvient (d'une étape d'initialisation précédente) de la clé publique du serveur (généralement de type RSA ou DSA); dans le modèle expliqué ci-dessus, les serveurs légitimes se définissent et se distinguent des imitateurs par leur connaissance de la clé privée de signature correspondant à la clé publique mémorisée par le client. Cette signature fournit l'authentification; le Diffie-Hellman produit alors un secret partagé qui sera utilisé pour crypter et protéger tous les échanges de données pour cette connexion (en utilisant un cryptage symétrique et des algorithmes MAC).
Ainsi, alors que Diffie-Hellman ne fait pas tout ce dont vous avez besoin, il fournit toujours une fonctionnalité utile, à savoir un échange de clés , que vous n'obtiendrez pas à partir de signatures numériques, et qui fournit le secret partagé temporaire nécessaire pour crypter les données réellement échangées.
Tom a fourni une bonne explication pour expliquer pourquoi Diffie-Hellman ne peut pas être sûr contre l'homme dans le milieu. Maintenant, cela répond à la question initiale de l'OP mais laisse probablement à certains lecteurs la question de suivi (raisonnable): pourquoi n'utilisons-nous pas simplement la cryptographie à clé publique (asymétrique) pour garantir la confidentialité de nos messages et abandonnons-nous D-H? Il y a quelques raisons de ne pas le faire:
- Il existe des algorithmes qui prennent uniquement en charge la signature, mais pas le cryptage des messages (ECDSA, par exemple)
- Le chiffrement et le déchiffrement symétriques sont beaucoup plus rapides que de le faire de manière asymétrique
- Le plus important est probablement que nous voulons garantir secret à transmettre. Après tout, il n'est pas impossible que la clé privée de l'un de vos partenaires de communication soit compromise à un moment donné. Désormais, si vous ne vous appuyiez que sur le chiffrement asymétrique, tous les messages que vous avez envoyés à ce partenaire pourraient être déchiffrés rétrospectivement par l'attaquant. En revanche, si nous utilisons Diffie-Hellman - et pour être précis, éphémère Diffie-Hellman, nous générons une nouvelle paire de clés DH pour chaque session de communication et la jetons (= ne la stockons pas) après , ce qui signifie qu'il est impossible de décrypter nos messages ultérieurement.
Après un échange de clés DH, les deux parties savent quelle clé elles ont calculée. Si aucun homme du milieu n'a infiltré la connexion, les deux parties auront la même clé. Si la connexion a été rompue, ils auront des clés différentes. S'il existe un moyen par lequel une partie peut demander à l'autre quelle clé elle utilise, l'homme du milieu ne pourra rester non détecté que s'il est en mesure de répondre de la même manière que la partie légitime l'aurait fait. Bien que la question soit souvent répondue à l'aide d'une signature numérique, pour rendre l'usurpation d'identité difficile, la question peut également être posée/répondue via des choses comme la communication vocale. Si une application vocale montre aux participants la clé de cryptage actuelle et qu'un participant sélectionne arbitrairement une plage et une star de cinéma populaire (par exemple Marilyn Monroe), et demande à l'autre de lire les quinzième à vingt-cinquième chiffres dans leur meilleure voix Marilyn Monroe, un un véritable participant qui a les numéros devant lui pourrait le faire rapidement et couramment et, en l'absence d'une attaque MITM, les chiffres correspondraient à ceux vus par le premier correspondant. Un attaquant de niveau intermédiaire n'aurait aucun problème à détecter la question et, avec le temps, pourrait être en mesure de forger un fichier vocal de la communicante légitime faisant une mauvaise imitation de Marilyn Monroe disant les chiffres appropriés, mais ont du mal à le faire aussi rapidement que le vrai.
En bref, DH par lui-même peut être robuste contre les attaques MITM si chaque participant sait quelque chose que l'autre participant pourra faire avec un numéro plus efficacement qu'un attaquant. Cependant, d'autres protocoles sont généralement utilisés en conjonction avec DH, car il est utile que le processus d'authentification soit automatisé, et la plupart des formes d'authentification qui ne s'appuieraient pas sur le cryptage (des choses comme la voix, le phrasé, etc.) nécessitent une validation humaine. De plus, il est souvent nécessaire pour les entités de solliciter la communication d'étrangers. Si vous voulez parler à un représentant d'Acme Bank, un imposteur homme au milieu pourrait installer un faux bureau "Acme Bank" et répondre à mon appel, et demander à quelqu'un d'autre dans un faux salon de relayer tout ce que je dis au vrai Acme Bank, et personne ne serait plus sage. Si je n'ai aucune idée à quel point un vrai employé d'Acme Bank serait capable d'imiter Marilyn Monroe, je n'aurais aucun moyen de savoir que l'imitation d'un imposteur n'était pas la même.
Je dois préciser un point dans la réponse de Tom Leek: "En SSH, un échange de clés Diffie-Hellman est utilisé, mais la partie publique du serveur (son gb mod p) est signé par le serveur. "
En fait, tout l'échange de clés DH est signé. Signature seulement gb le mod p n'est pas suffisant: on pourrait usurper le serveur SSH en se connectant simplement à celui-ci et en rejouant le paquet [SSH-TRANS] plus tard. Cela ne prouve pas la connaissance des données de la session en cours; il omet gune mod p, les chaînes d'ID SSH et la négociation de protocole.
L'authentification est effectuée après que les deux parties ont échangé des chaînes d'ID SSH et des messages de négociation de protocole, et le client envoie un message d'échange de clé Diffie-Hellman contenant gune mod p.
Le serveur calcule gb mod p et hacha toutes les informations importantes: H = hachage (contexte || sig_pub || gune mod p || gb mod p || gun B mod p) avec context = chaînes ID SSH || messages de négociation de protocole.
Ensuite, il signe le hachage de la poignée de main: sig = signature (sig_priv, H) et renvoie (sig_pub, gb mod p, sig) au client.
De cette façon, personne ne peut usurper quoi que ce soit, sauf s'il a brisé l'algorithme de signature.
DH n'est généralement pas résistant aux attaques de Man in the Middle.
Si Alice et Bob (A <-> B) peuvent mettre en place un secret partagé. Ensuite, Frank peut configurer un secret partagé avec Alice (A <-> F). En même temps, Frank peut configurer un deuxième secret partagé (différent) avec Bob (F <-> B). Frank peut ensuite décrypter les messages A-> F et rechiffrer et envoyer à bob F-> B et vice versa.
* Vous avez donc besoin d'un moyen de vous assurer que le message provient bien (a été signé par) Alice. Soit avec un secret précédemment partagé (délivré via un autre canal) Ou en utilisant une autorité de certification (pour approuver le proxy). Ou une autre méthode.
Si vous ne faites confiance qu'à une autorité de certification, Alice peut configurer un secret partagé DH avec Bob, en signant le message avec le certificat de l'autorité de certification. Bob vérifie que les messages ont été signés par l'AC. Frank ne peut pas simuler les messages, car ils n'ont pas le certificat requis.
Maintenant, Alice et Bob ont un secret partagé. Frank ne pouvait pas se frayer un chemin au milieu. Cependant, l'AC n'a pas participé à la création du secret partagé (ne signant que les parties envoyées en cours de route). L'AC ne peut donc pas non plus jouer un mauvais acteur. Même si Frank les menace avec une clé à 5 $.
* Un peu simpliste mais c'est l'idée générale.
C'est ici que les capacités linguistiques descriptives de la langue anglaise échouent. Diffie helman est résistant aux mitm ssi une entité tierce hors bande est en mesure d'aider à distribuer les clés et/ou à vérifier l'identité. Vous trouverez dans la littérature ce qu'il définit principalement un réseau de confiance connecté entourant l'identité du destinataire ou dans la plupart des cas, la personne attachée à la clé ou au certificat.