Accueil🇫🇷Chercher

Attaque de l'homme du milieu

L'attaque de l'homme du milieu (HDM) ou man-in-the-middle attack (MITM), parfois appelée attaque du monstre du milieu ou monster-in-the-middle attack[1] - [2] ou attaque de l'intercepteur, est une attaque qui a pour but d'intercepter les communications entre deux parties, sans que ni l'une ni l'autre puisse se douter que le canal de communication entre elles a été compromis. Le canal le plus courant est une connexion à Internet de l'internaute lambda. L'attaquant doit d'abord être capable d'observer et d'intercepter les messages d'une victime à l'autre. L'attaque « homme du milieu » est particulièrement applicable dans la méthode d'échange de clés Diffie-Hellman, quand cet échange est utilisé sans authentification. Avec authentification, Diffie-Hellman est en revanche invulnérable aux écoutes du canal, et est d'ailleurs conçu pour cela.

Schéma de l'attaque de l'homme du milieu : Mallory intercepte les communications entre Alice et Bob.

Le problème de l'échange des clés

Un des problèmes majeurs lorsque deux personnes veulent échanger des données chiffrées est celui de la transmission des clés : pour s'assurer d'être les seuls à connaître ces informations secrètes, les correspondants doivent pouvoir les échanger de façon confidentielle.

Dans le cadre de la cryptographie symétrique, il faut disposer d'un canal sécurisé pour l'échange de clés. La question de l'établissement de ce canal sécurisé se résout dans beaucoup de protocoles cryptographiques, comme SSL/TLS, par le biais de la cryptographie asymétrique.

Dans le cadre de la cryptographie asymétrique, les deux personnes possèdent chacune leur clé publique et leur clé privée. Si la clé publique a été utilisée pour chiffrer un message, seul celui qui possède la clé privée correspondante peut le déchiffrer. Une communication chiffrée peut donc être établie par échange des seules clés publiques, ce qui ne nécessite pas un canal sécurisé. Il suffit en fait qu'un seul des interlocuteurs communique sa clé publique, le second l'utilisant pour lui envoyer de façon sûre une clé de chiffrement symétrique qu'il a choisie.

Cependant, la cryptographie asymétrique ne résout que partiellement le problème. Reste la question de l'authentification : comment s'assurer que la clé publique est bien celle de la personne ou entité avec laquelle on souhaite communiquer ?

La résolution complète du problème nécessite une infrastructure à clés publiques. En effet, dans la cryptographie asymétrique, il serait possible à un tiers, l'homme du milieu, de remplacer les clés publiques échangées par ses propres clefs publiques, et ainsi de se faire passer auprès de chacun des deux interlocuteurs pour l'autre partie. Il lui serait alors possible d'intercepter tous les messages, de les déchiffrer avec ses clefs privées et de les re-signer aussi. Le rôle d'une infrastructure à clés publiques est donc de certifier qu'une clef publique correspond bien à une entité donnée.

Plus généralement, il y a attaque de l'homme du milieu quand, lors d'une communication, l'attaquant peut intercepter la communication en se faisant passer auprès de chacune des parties pour l'autre interlocuteur, sans nécessairement que l'authentification soit assurée par des méthodes de cryptographie asymétrique. On peut par exemple mettre en œuvre une attaque de l'homme de milieu sur le protocole de sécurité du GSM, qui n'utilise pas de cryptographie asymétrique, pour la communication entre un mobile et le central[3].

L'attaque de l'homme du milieu

Dans l'attaque de l'homme du milieu, l'attaquant a non seulement la possibilité de lire, mais aussi de modifier les messages.

Le but de l'attaquant est de se faire passer pour l'un des correspondants (voire les 2) en utilisant, par exemple :

  • l'imposture ARP (ARP Spoofing) : c'est probablement le cas le plus frĂ©quent. Si l'un des interlocuteurs et l'attaquant se trouvent sur le mĂŞme rĂ©seau local, il est possible, voire relativement aisĂ©, pour l'attaquant de forcer les communications Ă  transiter par son ordinateur en se faisant passer pour un « relais » (routeur, passerelle) indispensable. Il est alors assez simple de modifier ces communications ;
  • l'empoisonnement DNS (DNS Poisoning) : L'attaquant altère le ou les serveur(s) DNS des parties de façon Ă  rediriger vers lui leurs communications sans qu'elles s'en aperçoivent ;
  • l'analyse de trafic afin de visualiser d'Ă©ventuelles transmissions non chiffrĂ©es ;
  • le dĂ©ni de service : l'attaquant peut par exemple bloquer toutes les communications avant d'attaquer l'une des parties. L'ordinateur ne peut donc plus rĂ©pondre et l'attaquant a la possibilitĂ© de prendre sa place.

DĂ©roulement

Alice et Bob veulent échanger des données confidentielles, et Carole, jalouse, veut les intercepter. Ils possèdent chacun une clé privée (respectivement As, Bs et Cs) et une clé publique (respectivement Ap, Bp et Cp).

Cas normal

Échange classique : Bob envoie un message à Alice.
  • Alice et Bob Ă©changent leur clĂ© publique. Carole peut les lire, elle connaĂ®t donc Ap et Bp.
  • Si Alice veut envoyer un message Ă  Bob, elle chiffre ce message avec Bp. Bob le dĂ©chiffre avec Bs.
  • Carole, qui ne possède que Cs, ne peut pas lire le message.

Attaque

Admettons maintenant que Carole soit en mesure de modifier les Ă©changes entre Alice et Bob.

  • Bob envoie sa clĂ© publique Ă  Alice. Carole l'intercepte, et renvoie Ă  Alice sa propre clĂ© publique (Cp) en se faisant passer pour Bob.
  • Lorsque Alice veut envoyer un message Ă  Bob, elle utilise donc, sans le savoir, la clĂ© publique de Carole.
  • Alice chiffre le message avec la clĂ© publique de Carole et l'envoie Ă  celui qu'elle croit ĂŞtre Bob.
  • Carole intercepte le message, le dĂ©chiffre avec sa clĂ© privĂ©e (Cs) et peut lire le message.
  • Puis elle chiffre Ă  nouveau le message avec la clĂ© publique de Bob (Bp), après l'avoir Ă©ventuellement modifiĂ©.
  • Bob dĂ©chiffre son message avec sa clĂ© privĂ©e, et ne se doute de rien puisque cela fonctionne.

Ainsi, Alice et Bob sont chacun persuadés d'utiliser la clé de l'autre, alors qu'ils utilisent en réalité tous les deux la clé de Carole.

Solutions

Il existe différents moyens pour se prémunir contre cette attaque :

  • obtenir la clĂ© publique de son interlocuteur par un tiers de confiance. Si les deux interlocuteurs possèdent un contact en commun (le tiers de confiance) alors ce dernier peut servir d'intermĂ©diaire pour transmettre les clĂ©s. Les infrastructures Ă  clĂ©s publiques sont des systèmes ou des organismes qui permettent de vĂ©rifier la validitĂ© des clĂ©s en se basant principalement sur des certificats. C'est notamment la mĂ©thode utilisĂ©e par le protocole HTTPS, oĂą le certificat d'authentification du site web consultĂ© est obtenu auprès d'une autoritĂ© de certification reconnue ;
  • Ă©changer les clĂ©s par un moyen qui ne permet pas cette attaque : en main propre, par tĂ©lĂ©phone, etc. ;
  • vĂ©rifier le niveau de confiance qui a Ă©tĂ© accordĂ© Ă  la clĂ© que l'on a en sa possession : certains logiciels comme GnuPG proposent de mettre la clĂ© publique en ligne sur un serveur. Sur ce serveur, d'autres utilisateurs peuvent faire connaĂ®tre le degrĂ© de confiance qu'ils accordent Ă  une clĂ©. On obtient ainsi un graphe qui relie les diffĂ©rents utilisateurs ;
  • authentification avec un mot de passe ou autre système avancĂ©, comme la reconnaissance vocale ou biologique.

Un « degré de certitude » est obtenu en appliquant des règles en fonction des valeurs présentes sur le chemin entre deux utilisateurs. Ce degré est informel, mais permet d'avoir une estimation de la pertinence d'une clé et l'identité qui lui est associée. Il ne doit toutefois pas être considéré comme une preuve de sécurité absolue.

Notes et références

  1. Gabbi Fisher et Luke Valenta, « Monsters in the Middleboxes: Introducing Two New Tools for Detecting HTTPS Interception »,
  2. Matthias Fassl, « Usable Authentication Ceremonies in Secure Instant Messaging »,
  3. (en) Elad Barkan, Eli Biham et Nathan Keller, « Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication », Technion - Computer Science department - Technical report 2006-7,‎ , p. 22-24 (section 7.3) (lire en ligne).

Voir aussi

Articles connexes

Liens externes

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.