Slide 1 : intro
« Bonjour à tous, nous sommes Hana et Amira.
Aujourd’hui, nous allons vous parler d’un protocole essentiel en cryptographie : Diffie–
Hellman, et de sa vulnérabilité face à l’attaque Man-in-the-Middle.
Nous allons voir comment il fonctionne, pourquoi il est utile, quelles sont les failles possibles
et comment s’en protéger. »
Slide 2 : plan
….
« Pour bien comprendre l’importance de Diffie–Hellman, commençons par voir pourquoi il
est nécessaire de partager une clé. »
Slide 3 : Pourquoi partager une clé ?
« Imaginons qu’Alice et Bob veulent communiquer en privé.
Le problème est le suivant : comment partager un secret si le canal entre eux n’est pas sûr ?
Si on l’envoie en clair, un attaquant peut l’intercepter et tout est compromis.
Diffie–Hellman (DH) propose une solution élégante : Alice et Bob obtiennent un secret
commun sans jamais transmettre leur secret privé en clair.
Autrement dit, ils construisent une clé partagée à partir d’échanges publics, ce qui évite de
“transmettre le secret” directement. »
« Maintenant que nous avons compris le problème, voyons comment Diffie–Hellman résout
ce problème. »
Slide 4 :Fonctionnement de Diffie-Hellman
Alors maintenant, regardons comment fonctionne Diffie–Hellman de manière intuitive.
L’objectif est que deux personnes, ici Alice et Bob, puissent créer une clé secrète commune,
sans jamais la transmettre.
D’abord, il existe deux valeurs publiques connues par tout le monde, même les attaquants :
un grand nombre premier p et une base g.
Ensuite, chacun choisit un secret personnel : Alice choisit a, Bob choisit b. Ces valeurs
restent privées.
Alice calcule alors une valeur qu’on appelle A, égale à g^amod p, et l’envoie à Bob.
Bob fait pareil avec B = g^bmod p et l'envoie à Alice.
Grâce à ces valeurs échangées, chacun peut calculer la même clé secrète, sans jamais avoir
envoyé son secret.
Alice calcule B^a, Bob calcule A^b, et mathématiquement, on obtient la même chose : g^(ab)
mod p.
Ce qui est important:
On n’a jamais envoyé a ou b sur le réseau — donc même si quelqu’un écoute, il ne peut pas
déduire la clé finale.
Slide 5 :Exemple Numérique :
« Prenons un exemple numérique très simple pour voir DH en action.
On choisit des petits paramètres publics pour comprendre : p = 23 et g = 5.
Alice choisit son secret a = 6 ; elle calcule
A=56 mod 23=8A = 5^{6} \bmod 23 = 8A=56mod23=8
et envoie A = 8 à Bob.
Bob choisit son secret b = 15 ; il calcule
B=515 mod 23=19B = 5^{15} \bmod 23 = 19B=515mod23=19
et envoie B = 19 à Alice.
Maintenant chacun utilise la valeur reçue et son propre secret pour obtenir la clé partagée :
Alice calcule
s=Ba mod 23=196 mod 23=2s = B^{a} \bmod 23 = 19^{6} \bmod 23 =
2s=Bamod23=196mod23=2
et Bob calcule
s=Ab mod 23=815 mod 23=2.s = A^{b} \bmod 23 = 8^{15} \bmod 23 =
2.s=Abmod23=815mod23=2.
Résultat : les deux trouvent la même clé s = 2 — sans jamais avoir transmis a ou b.
Important : ici on utilise des petits nombres pour illustrer ; en pratique on prend p très grand
(par exemple 2048 bits) afin que retrouver a ou b soit impossible pour un attaquant. »
« Cet exemple montre bien le principe, mais pourquoi DH est-il si utile et sûr ? »
Slide 6 : Pourquoi Diffie-Hellman est utile ?:
« Diffie–Hellman est très pratique car les secrets privés d’Alice et de Bob ne sont jamais
transmis sur le réseau. Même si quelqu’un intercepte les valeurs publiques, il ne peut pas
retrouver ces secrets facilement.
La sécurité repose sur ce qu’on appelle le logarithme discret : en termes simples, il est très
difficile de calculer le nombre secret à partir de la valeur publique, surtout quand les nombres
sont très grands. Pas besoin de rentrer dans les maths compliqués, l’important à retenir est que
cela rend l’attaque extrêmement difficile.
Grâce à cette propriété, DH est parfait pour établir une clé de session que les deux parties
peuvent utiliser pour chiffrer leurs communications de manière sûre. »
« Mais attention, même DH a ses limites. Voyons maintenant une attaque célèbre appelée
Man-in-the-Middle. »
Slide 7 :L’Attaque Man-in-the-Middle (MITM) :
Imaginons qu’un attaquant, qu’on appelle Mallory, se place entre Alice et Bob.
Quand Alice envoie une valeur à Bob, Mallory l’intercepte. Au lieu de transmettre telle
quelle, Mallory peut remplacer cette valeur par une valeur choisie par elle-même, puis
l’envoyer à Bob. Elle fait la même chose dans l’autre sens.
Le résultat est qu’Alice négocie une clé secrète avec Mallory, et Bob négocie une autre clé
avec Mallory. Alice et Bob croient communiquer ensemble, mais en réalité Mallory est le
relais : elle peut lire, modifier, ou rejouer les messages avant de les transmettre.
Important : l’attaquant n’a pas besoin de « casser » le chiffrement — il profite simplement
du manque d’authentification dans l’échange.
(Transition :) Maintenant que vous voyez la menace, nous allons montrer pourquoi, sans
authentification, DH peut être victime de cette attaque.
Slide 8 :Conséquences de l’attaque Man-in-the-Middle (MITM) :
Tout d’abord, la confidentialité est perdue : Mallory a accès au contenu des messages
d’Alice et de Bob, même si le chiffrement est utilisé — puisqu’elle possède les clés des deux
côtés.
Ensuite, l’intégrité est compromise : Mallory peut modifier un message avant de le renvoyer.
Par exemple, si Alice envoie “Transférez 50€”, Mallory peut changer cela en “Transférez
500€” sans que Bob ne s'en rende compte.
Enfin, l’authenticité n’existe plus. Alice pense parler à Bob, Bob pense parler à Alice, mais
en réalité ils parlent tous les deux à Mallory.
Pour éviter ces risques, il est essentiel de suivre certaines bonnes pratiques et limites lors de
l’utilisation de Diffie–Hellman. »
Slide 9 :Bonnes pratiques & limites de Diffie-Hellman :
D'abord, il faut toujours utiliser de bons paramètres Diffie–Hellman, avec des clés
suffisamment longues, et surtout des clés éphémères. C’est ce qu’on appelle DHE ou
ECDHE — et cela permet d’avoir une nouvelle clé à chaque session, donc même si une clé
est compromise, les sessions précédentes restent protégées.
Ensuite, la règle d'or : authentifier le handshake, par exemple avec un certificat numérique
ou une signature cryptographique. Sans authentification, Diffie–Hellman reste vulnérable.
Enfin, attention à la gestion des clés sur le long terme : stockage sécurisé, synchronisation et
surtout mises à jour de sécurité. Une cryptographie forte devient inutile si le système n’est
pas maintenu.
Slide 10 :Conclusion:
« Pour conclure, Diffie–Hellman est une méthode ingénieuse qui permet de partager un secret
sans jamais l’envoyer en clair.
Comme le dit notre citation : « Diffie–Hellman nous apprend qu’on peut partager un secret
sans jamais le dire… à condition de savoir à qui on parle. »
Cela signifie que l’échange de clés seul n’est pas suffisant : il faut authentifier les parties
pour éviter toute interception ou attaque de type Man-in-the-Middle.
En combinant Diffie–Hellman avec des mécanismes d’authentification fiables, on peut ainsi
établir une communication sécurisée et digne de confiance. »