DH : Diffie-Hellman
Cryptographie
DH, pour Diffie-Hellman, est une méthode permettant à deux parties de créer un secret commun sur un canal public, sans envoyer ce secret lui-même. Sa sécurité repose sur la difficulté de retrouver ce secret à partir des valeurs échangées.
Échange de clé : Chaque partie choisit un nombre secret, publie une valeur calculée à partir de ce nombre, puis combine la valeur reçue avec son propre secret. Les deux obtiennent alors la même valeur, qui peut servir à dériver une clé de chiffrement.
Ce que voit l'espion : Un observateur peut intercepter les paramètres publics et les deux valeurs échangées. Il ne doit pas pouvoir reconstituer efficacement le secret commun, même avec beaucoup de puissance de calcul.
Hypothèses de sécurité : CDH affirme qu'il est difficile de calculer le secret commun. DDH ajoute qu'il est difficile de distinguer ce secret d'une valeur aléatoire, ce qui fournit une garantie plus forte.
Limite importante : DH seul n'authentifie pas les interlocuteurs. Sans mécanisme d'authentification, une attaque de l'intercepteur peut s'installer entre les deux parties, tranquillement, comme si elle avait été invitée.
Ce qui arrive si on s'en passe
Un échange Diffie-Hellman ne protège que ce que sa configuration autorise. À l'entrée, le contrôle d'accès consiste à n'accepter que des groupes nommés et des tailles de clé minimales définies par la politique : refuser les paramètres arbitraires proposés par le pair, rejeter les suites d'export et vérifier que la clé publique reçue n'appartient pas à un sous-groupe trivial. La détection repose sur la journalisation des paramètres négociés : toute négociation en dessous du seuil doit déclencher une alerte, pas une simple ligne de log. La réponse s'organise en couches : rotation des clés éphémères, désactivation centralisée des suites obsolètes, puis nouvelle campagne d'inventaire des points terminaux pour vérifier que la contrainte s'applique partout, y compris aux services internes.
Comment le mettre en place
Pour constater la fragilité d'un échange Diffie-Hellman mal paramétré, monter un serveur TLS local configuré avec un groupe DH de 512 ou 768 bits et un générateur non vérifié. Capturer une poignée de main au format pcap, extraire les paramètres publics, puis tenter le calcul du logarithme discret avec un outil de calcul formel généraliste sur le petit module. Recommencer ensuite avec un groupe nommé de 2048 bits minimum : le même calcul devient hors de portée. L'exercice prouve que la sécurité ne tient pas au protocole mais à la taille et à la qualité du groupe, et que l'acceptation de paramètres faibles par une des deux parties suffit à annuler la confidentialité.
Explication de la marmotte
Deux personnes veulent fabriquer la même combinaison secrète sans jamais la dire à voix haute. Chacune choisit un nombre caché, mélange ce nombre avec une recette connue de tous, puis envoie le résultat à l'autre. En appliquant encore la recette avec son propre nombre, les deux obtiennent la même combinaison. Une personne qui écoute voit les recettes et les résultats envoyés, mais il lui manque les nombres cachés. Elle ne peut donc pas retrouver facilement la combinaison finale.
Où ce terme est utilisé
- Établir une clé : Diffie-Hellman, KEM et HPKE (4 occurrences)
- GRE, IPsec ou GRE dans IPsec pour un tunnel site à site (1 occurrence)
- Les problèmes difficiles qui rendent la clé publique possible (1 occurrence)
- Migrer TLS legacy sans casser les clients anciens (1 occurrence)