Échange de clés Diffie-Hellman

tbowan

23 Juillet 2017

L'échange de clé Diffie Hellman est un des nombreux classiques de la cryptographie moderne. Il permet à la fois d'établir un secrêt partagé sans nécessiter de canal de communication privé mais est également utilisé pour fournir une confidentialité persistante entre sessions.

Comment ça marche ? Comment on l'utilise ? Cet article répond à vos questions.

Établir des clés symétriques

L'intérêt des algorithmes symétriques est leur performance. Avec une sécurité équivalente, ils sont bien plus rapides à calculer et donc très utilisés lorsqu'il s'agit de chiffrer des messages longs ou même des flux.

Leur inconvénient est qu'ils nécessitent une méthode pour échanger la clé entre l'émetteur et le récepteur.

L'échange de clé Diffie-Hellman1, du nom de ses inventeurs2, est un protocole de communication permettant de résoudre ce problème : établir un secrêt partagé en utilisant un canal de communication public.

Procole d'échange de clés

Le but est donc de calculer une valeur commune sans qu'une oreille indiscrète ne puisse la deviner. Plutôt que de vous refaire la métaphore à base de peinture, je vous propose une version plus géométrique...

Principe de base

Établir une clé secrête, c'est un peu comme établir un point de rendez-vous. Le but, pour Alice et Bob qui veulent pouvoir parler tranquillement, est de se retrouver au même endroit sans que Eve, qui espionne leurs communications, ne sache où ils se trouvent.

Pour commencer Alice et Bob se rencontrent dans un lieu public, c'est le point de départ. Ils choisissent secrêtement le déplacement qu'ils veulent faire et partent chacun de leur côté. Une fois à leur point d'arrivée, ils s'envoient leur position respective, échangent de place et refont le même déplacement. Si tout va bien, ils se retrouvent au même endroit, mais pas Eve.

Pour que ce protocole fonctionne, il y a quelques petites contraites à respecter. On considère que Eve n'est pas capable de suivre les mouvements, elle ne peut qu'écouter les communications.

  1. l'ordre des déplacements ne change pas le point d'arrivée (ils sont commutatifs) ;
  2. Eve ne peut pas calculer un déplacement en observant un point de départ et d'arrivée.

Se déplacer à la boussole sur de courtes distances respecte la première contrainte3 mais pas la seconde. Vous arriverez au même endroit, mais pour Eve, les calculs sont faciles.

Pour respecter la deuxième contrainte, il faut un déplacement que Eve ne puisse pas inverser. Prenons, par exemple, une suite de mouvements aléatoires (avant, arrière, droite, gauche) et jouons là dans un labyrinthe, quitte à butter sur les murs. En observant le point de départ et d'arriver, Eve ne peut pas déduire la suite de mouvements.

Le problème, cette fois, c'est que rien ne garanti qu'Alice et Bob arrivent au même endroit dans le labyrinthe.

Il faut donc un espace et une opération qui soit associatif et difficile à inverser. Le hasard faisant bien les choses, c'est justement les caractéristiques du problème du logarithme discret, sujet d'un précédent article.

Définition formelle

Alice et Bob vont donc utiliser un groupe fini et un générateur. Le groupe fini est l'espace dans lequel ils vont se déplacer, le générateur est leur point de départ, le calcul de l'exponentiation est la façon de se déplacer et les exposants secrêts sont les déplacements d'Alice et Bob.

Le protocole d'échange de clé se déroule comme suit :

  1. Alice et Bob se mettent d'accord publiquement sur un groupe (G, ×) et un générateur g ;
  2. Ils choisissent chacun un nombre aléatoire (leur_ clé secrête_), a pour Alice et b pour Bob, ce sera leur déplacement ;
  3. Ils calculent leur première destination (leur clé publique) et se l'envoie l'un l'autre ; Alice envoie donc ga à Bob et reçoit gb en retour ;
  4. Ils calculent leur destination finale en appliquant de nouveau leur exposant ; Alice calcule gba et Bob calcule gab.

Première contrainte. L'équivalence des points d'arrivée est due à l'associativité de l'opération : gab = gab = gba = gba.

Deuxième contrainte. La sécurité de cet algorithme est basée sur le fait que Eve, connaissant g, ga et gb, n'est pas capable de calculer gab. Cette propriété est connue sous le nom de Problème de Diffie-Hellman et, en l'état des connaissances actuelles, semble être aussi difficile que celui du logarithme discrêt4.

On parle de protocole d'échange de clés car les couples (a, ga) et (b, gb) sont les paires de clés privées et publiques d'Alice et Bob. Ces clés permettent de calculer le secrêt partagé mais en aucun cas de chiffrer ou signer des messages.

Sécurité

Ce protocole, utilisé seul, n'a aucune utilité et sert donc en conjonction avec d'autres protocoles qui comblent ses lacunes et bénéficient de ses atouts.

Besoin de signature

Si Eve est en mesure d'intercepter et modifier les communications, ce qui est le cas de certains moyens de communications, la sécurité du protocole tombe. Eve peut choisir un nombre e et envoyer ge à Alice et à Bob. Aucun des deux n'étant capable de savoir que ce qu'il reçoit vient de Eve, Chaque moitié de communication sera sécurisée par une clé secrête : gae entre Alice et Eve et gbe entre Bob et Eve.

Pour éviter ce risque, les communications sont donc signées par Alice et Bob via des clés publiques préalablement échangées ou certifiées par un tiers de confiance.

Confidentialité persistante

Quel est l'intérêt d'utiliser un protocole d'échange de clés puisqu'il nécessite un système de chiffrement/signature asymétriques ? Plutôt que de calculer un secrêt partagé, Alice pourrait très bien choisir un nombre aléatoire, le chiffrer avec la clé publique de Bob et lui envoyer...

D'accord, mais que ce passerait-il si Eve stockait toutes les communications entre Alice et Bob et prennait son temps pour casser la clé privée de Bob ? Une fois la clé cassée, l'ensemble des communications passée et future serait alors compromis.

La confidentialité persistante (ou forward secrecy en anglais) est le fait d'empêcher Eve de pouvoir déchiffrer ces communications passées et futures.

L'échange de clé Diffie-Hellman apporte cette propriétés aux échanges entre Alice et Bob. Ils signent asymétriquement et établissent un secrêt paragé pour chiffrer le reste de la communication. Il faut donc que Eve casse le secrêt partagé (et non plus la clé privée) et ça ne lui permet de déchiffrer que les communications entre les deux victimes.

Si en plus, Alice et Bob utilisent des nombres aléatoires différents pour chaque session (on parle alors de clés éphémères), le secrêt paragé sera différent pour chaque session. Eve est alors obligée de casser individuellement chaque clé de session.

Utilisation dans SSL/TLS

Lorsqu'un client et un serveur mettent en place une connexion sécurisée par SSL/TLS, celle-ci est chiffrée via un algorithme symétrique et nécessite donc que le client et le serveur se mettent d'accord sur la clé à utiliser.

Sans rentrer dans les détails des messages échangés5, l'établissement d'une connexion suit les étapes et échanges de messages suivants :

  1. Hello Le client et le serveur se mettent d'accord sur les algorithmes qu'ils vont utiliser pour les opérations cryptographiques, les fameuses cipher suites.
  2. Certificates Le serveur envoie son certificat et peut demander au client de lui en envoyer un également. Chaque partie vérifie l'authenticité des certificats via leurs tiers de confiance (les CA).
  3. Key Exchange Messages Le serveur envoie les données nécessaires pour l'échange de clé, le client le fera également ensuite.

En fonction des algorithmes choisis dans les messages Hello, l'échange de clé se fait différement6.

RSA Dans ce mode, le client génère une clé partagée et l'envoie au serveur, après l'avoir chiffrée avec la clé privée du serveur. Casser la clé du serveur permet de déchiffrer toutes les communications.

DH - fixed Dans ce mode, le certificat (du cliet et/ou du serveur) contiennent déjà les paramètres et clés publiques. Les messages d'échange de clés sont donc vides (puisque la donnée est dans le certificat), les parties calculent le secrêt partagé grâce au contenu des certificats.

DHE - ephemeral Dans ce mode, les clés publiques sont générées pour chaque session et contenues dans les messages Key exchange messages.

Bien que la communication soit initiée par le client, c'est le serveur qui envoie le premier message pour l'échange de clé (et donc fixe le groupe et le générateur).

Les algorithmes ECDH et ECDHE pour l'échange de clés sont également des échanges de clé Diffie-Hellman mais utilisent les courbes elliptiques (EC) comme groupe pour leurs opérations. Le protocole est identique, seul les élements et l'opération changent.

Conclusion

On pourrait presque parler de protocole de rêve. Il est simple à implémenter, nécessite peut d'opérations, peut se dérouler publiquement tout en fournissant la confidentialité persistante à toutes vos sessions.

Vous connaissez maintenant son fonctionnement, les raisons de sa sécurité, ses limitations et surtout comment il peut être utilisé pour disposer de communications sûres.


  1. Échange de clés Diffie-Hellman, Wikipedia

  2. C'est à dire ceux qui ont déposé le brevet en 1977 car les premiers découvreur, travaillant dans les services de communication du gouvernement britaniques, n'ont pas pu publier leur découverte.

  3. Sur de très longues distances, la courbure de la Terre ne garanti plus l'associativité de ces déplacements.

  4. Problème de Diffie-Hellman, wikipedia.

  5. Pour les détails, vous pouvez lire la RFC-5246.

  6. Diffie Hellman, wiki.openssl.org.