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 certains fils. Les entités ne peuvent être distinguées les unes des autres que par les zéros et les uns 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 brut Diffie-Hellman que vous présentez, vous parlez à une entité supposée pour 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 du protocole il n'y a d'opération que seul un Bob spécifique peut faire. Ainsi, le protocole ne peut réaliser aucun type d'authentification - vous ne savez pas à qui vous parlez. Sans authentification, l'usurpation d'identité est possible, et cela inclut une double usurpation d'identité simultanée, mieux connue 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 exemple typique est SSL / TLS; un autre est SSH. En 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 communique avec le 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, le serveur légitime est défini et distingué des imitateurs par sa 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 le fait pas tout ce dont vous avez besoin par lui-même, il fournit toujours une fonctionnalité utile, à savoir un échange de clés, que vous n'obtiendrez pas des signatures numériques, et qui fournit le secret partagé temporaire nécessaire pour chiffrer les données réellement échangées.

Tom a fourni une bonne explication sur les raisons pour lesquelles Diffie-Hellman ne peut pas être à l'abri de l'homme du milieu. Maintenant, cela répond à la question initiale du PO, mais laisse probablement certains lecteurs avec la question de suivi (raisonnable): pourquoi ne pas utiliser simplement la cryptographie à clé publique (asymétrique) pour assurer la confidentialité de nos messages, et abandonner complètement D-H? Il y a quelques raisons de ne pas faire cela:

• Il existe des algorithmes qui ne prennent en charge que la signature, mais pas le chiffrement des messages (ECDSA, par exemple)
• Le chiffrement et le déchiffrement symétriques est un beaucoup plus rapide que de le faire de manière asymétrique
• Le plus important est probablement que nous souhaitons garantir le secret de transmission . 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 fiez qu'au 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, Diffie-Hellman éphémère , nous générons une nouvelle paire de clés DH pour chaque session de communication et la jetons (= ne la stockez pas) par la suite , ce qui signifie qu'il est impossible de déchiffrer nos messages ultérieurement.

Après un échange de clé 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 capable de répondre de la même manière que l'aurait fait la partie légitime. 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 le quinzième à vingt-cinquième chiffres dans sa meilleure voix Marilyn Monroe, un un vrai participant qui a les numéros devant lui serait capable de le faire rapidement et couramment et, en l'absence d'attaque MITM, les chiffres correspondraient à ceux vus par la première partie. Un attaquant de type homme du milieu n'aurait aucun problème à détecter la question et, avec le temps, pourrait être en mesure de créer un fichier vocal du communiquant légitime faisant une mauvaise imitation de Marilyn Monroe en disant les chiffres appropriés, mais le ferait ont du mal à faire ça aussi vite que le vrai.

En bref, DH en lui-même peut être robuste contre les attaques MITM si là chaque participant sait quelque chose que l'autre participant sera capable de faire avec un nombre 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 reposent pas sur le cryptage (des choses comme la voix, la formulation, etc.) nécessitent une validation humaine. De plus, il est souvent nécessaire que les entités sollicitent la communication d'étrangers. Si vous voulez parler à un représentant de la Banque Acme, un imposteur de l'homme du milieu pourrait ouvrir un faux bureau «Acme Bank» et prendre 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 le plus sage. Si je n'ai aucune idée à quel point un véritable 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 chose.

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 second secret partagé (différent) avec Bob (F<-> B). Frank peut ensuite déchiffrer les messages A-> F et rechiffrer et envoyer à bob F-> B & vice versa.

* Vous avez donc besoin d'un moyen de vous assurer que le message provient réellement ) Alice. Soit avec un secret précédemment partagé (livré via un autre canal), soit en utilisant une autorité de certification (pour proxy trust). Ou une autre méthode.

Si vous ne faites que peu confiance à 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'autorité de certification. 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 simuler leur chemin vers le milieu. Cependant, l'AC n'a joué aucun rôle dans 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 le rôle d'un mauvais acteur. Même si Frank les menace avec une clé à 5 $.

* Légèrement simpliste mais c'est l'idée générale.

Je dois préciser un point dans la réponse de Tom Leek: "En SSH, un échange de clé Diffie-Hellman est utilisé, mais la partie publique du serveur (son g ^b mod p) est signée par le serveur. "

En fait, tout l'échange de clé DH est signé. Signer uniquement g ^b mod p n'est pas suffisant: on pourrait usurper le serveur SSH en s'y connectant simplement 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 g ^a mod p, les chaînes d'identification SSH et la négociation de protocole.

L'authentification est effectuée après que les deux parties ont échangé des chaînes d'identification SSH et des messages de négociation de protocole, et le client envoie un message d'échange de clé Diffie-Hellman contenant g ^a mod p.

Le serveur calcule g ^b mod p et hache toutes les informations importantes: H = hash (context || sig_pub || g ^a mod p || g ^b mod p || g ^ab mod p) avec context = SSH Chaînes d'identification || messages de négociation de protocole.

Ensuite, il signe que la poignée de main hash: sig = signature (sig_priv, H) et renvoie (sig_pub, g ^b 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.

C'est ici que les capacités descriptives linguistiques de la langue anglaise échouent. Diffie helman résiste au 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 est 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.