Aller au contenu
TortueTech
RubriquesGlossaire

échange de clés

Gestion des clés

Mécanisme par lequel deux parties établissent une clé secrète commune à travers un canal public, sans jamais la transmettre. C'est l'étape qui ouvre toute session chiffrée (TLS, SSH, VPN) avant le passage au chiffrement symétrique.

Schéma en séquence entre deux acteurs, Client et Serveur. 1. Le client envoie au serveur sa valeur publique A égale à g puissance a. 2. Le serveur répond avec sa valeur publique B égale à g puissance b, signée par le certificat. 3. Si la signature est valide, le client calcule le secret B puissance a. 4. Le serveur calcule de son côté le secret A puissance b, qui est identique. 5. Le client envoie ensuite au serveur des données chiffrées avec la clé dérivée de ce secret, qui n'a jamais circulé.

Principe Diffie-Hellman : Chaque partie combine sa valeur privée avec la valeur publique de l'autre. Les deux obtiennent le même secret, qu'un observateur du trafic ne peut pas recalculer ; la variante courante aujourd'hui est ECDH sur la courbe X25519.

Authentification obligatoire : Sans signature des valeurs échangées (certificat, clé d'hôte SSH), un attaquant placé au milieu négocie une clé distincte avec chaque côté. Un canal parfaitement chiffré avec la mauvaise personne reste parfaitement chiffré : les mathématiques n'ont jamais promis de vérifier l'identité du correspondant.

Clés éphémères : En générant des valeurs neuves à chaque session, on obtient la confidentialité persistante : voler plus tard la clé longue durée du serveur ne permet pas de déchiffrer les sessions passées. TLS 1.3 n'accepte que ce mode.

Après-quantique : Un ordinateur quantique suffisamment puissant casserait Diffie-Hellman. ML-KEM, un mécanisme d'encapsulation de clé, est déjà déployé en mode hybride avec X25519 dans les navigateurs et OpenSSH.

Voir aussi :Diffie-HellmanECDHTLSPerfect Forward SecrecyML-KEM

Ce qui arrive si on s'en passe

Sans échange de clés, deux parties qui veulent chiffrer leur communication n'ont que deux options : envoyer la clé symétrique sur le canal lui-même, ou la convenir à l'avance par un autre moyen. Dans le premier cas, quiconque observe le canal récupère la clé, déchiffre toute la session et peut fabriquer des messages qui passent pour légitimes. Dans le second, la même clé sert d'une session à l'autre : un trafic enregistré aujourd'hui devient lisible le jour où cette clé fuit, faute de clés éphémères pour assurer la confidentialité persistante. Changer la clé devient une opération manuelle, donc rarement faite, et chaque nouvel interlocuteur demande un partage préalable, ce qui ne tient pas à grande échelle. TLS, SSH ou un VPN ne peuvent alors pas ouvrir de session chiffrée avec un pair jamais rencontré.

Explication de la marmotte

Imagine que tu veux choisir avec une amie une couleur secrète, alors que tout le monde regarde vos échanges. Vous partez d'une peinture commune, connue de tous. Chacune y ajoute en cachette sa propre couleur secrète, puis vous vous échangez vos mélanges devant tout le monde. Ensuite, chacune rajoute sa couleur secrète au mélange reçu. Résultat : vous obtenez exactement la même teinte finale, alors qu'aucune couleur secrète n'a voyagé. Un espion qui a tout vu ne sait pas « démélanger » la peinture. Cette teinte commune sert ensuite de mot de passe pour brouiller vos messages.

Où ce terme est utilisé

← Tout le glossaire