Une attaque par rejeu (en anglais, replay attack ou playback attack) est une forme d'attaque réseau dans laquelle une transmission est malicieusement répétée par un attaquant qui a intercepté la transmission. Il s'agit d'un type d'usurpation d'identité.

Schéma d'attaque par rejeu d'un mot de passe intercepté

Exemple d'attaque par rejeu modifier

L'exemple suivant présente une attaque par rejeu où Ève usurpe l'identité d'Alice en volant son mot de passe. Supposons qu'Alice veuille communiquer avec Bob. Pour être certain de communiquer avec Alice, Bob lui demande son mot de passe, qu'Alice lui envoie (possiblement après l'avoir passé au travers d'une fonction de hachage cryptographique). Pendant ce temps, Ève écoute la conversation et enregistre le mot de passe (ou le résultat de l'application de la fonction de hachage sur le mot de passe, ce résultat est souvent appelé digest). Une fois l'échange terminé, Ève contacte Bob en prétendant qu'elle est Alice. Quand Bob lui demande son mot de passe pour vérifier son identité, Ève renvoie le mot de passe (ou son digest) qu'elle avait préalablement intercepté.

Les attaques par rejeu ne sont pas limitées au vol de mot de passe, ce genre d'attaque peut se faire dans d'autres situations. Une autre attaque permettant d'entrer dans un véhicule au moyen d'une attaque par rejeu est décrite plus bas dans cet article.

Prévention et contre-mesures modifier

Identifiant de session modifier

Les attaques par rejeu peuvent être contrées en utilisant un identifiant de session en plus du mot de passe pour identifier une personne. L'identifiant de session doit être aléatoire et différent pour chaque session. Un attaquant ne peut utiliser dans une nouvelle session les informations d'une session précédente parce que son identifiant de session est différent.

Fonctionnement de l'identifiant de session modifier

Voici comment pourrait fonctionner la gestion d'un identifiant de session dans une identification par mot de passe résistante aux attaques par rejeu :

  1. Lorsqu'Alice veut communiquer avec Bob, Bob envoie un identifiant de session à Alice. Alice applique une fonction de hachage cryptographique à la concaténation de cet identifiant et son mot de passe, puis envoie le résultat à Bob ;
  2. De son côté, Bob, qui connaît l'identifiant de session et le mot de passe d'Alice effectue le même calcul ;
  3. Si le résultat fourni par Alice et celui calculé par Bob sont identiques, il n'y a pas de rejeu et la connexion est réussie ;
  4. Supposons maintenant qu'un attaquant, Ève, a capturé la valeur transmise par Alice au cours d'une session précédente et tente de l'utiliser dans une autre session pour usurper l'identité d'Alice. Comme Bob a généré un nouvel identifiant de session pour la session avec Ève, lorsqu'il appliquera la fonction de hachage à la concaténation du nouvel identifiant et du mot de passe d'Alice, il obtiendra un résultat différent de celui fourni par Ève qui est basé sur l'identifiant d'une session antérieure. Bob saura qu'il y a un problème et il n'établira pas la communication.

Les identifiants de session doivent être choisis par un processus aléatoire. Sinon, Ève pourrait usurper l'identité de Bob, envoyer à Alice un identifiant de session qu'elle sait être un futur identifiant valide, obtenir d'Alice le résultat de la fonction de hachage appliquée à la concaténation de l'identifiant et du mot de passe d'Alice et rejouer ce résultat lorsque Bob lui présentera l'identifiant qu'elle a prédit. Bob croira alors être en contact avec Alice et il acceptera la communication.

Le protocole précédent permet à Bob de vérifier l'identité d'Alice, mais il ne permet pas à Alice de vérifier l'identité de Bob. Pour permettre à Alice de vérifier l'identité de Bob, il suffit d'ajouter les étapes suivantes après l'étape 3 :

  • Bob applique une fonction de hachage cryptographique à la concaténation de l'identifiant de session et du mot de passe d'Alice auquel il a fait une petite modification connue d'Alice (par exemple, il ajoute la lettre z à la fin du mot de passe), puis il envoie le résultat à Alice ;
  • Alice, qui connaît l'identifiant de session et son mot de passe effectue le même calcul ;
  • si le résultat fourni par Bob et celui calculé par Alice sont identiques, Alice sait que l'expéditeur connaît son mot de passe. Elle est donc certaine d'être en communication avec Bob.

Mot de passe à usage unique modifier

Les mots de passe à usage unique préviennent évidemment les attaques par rejeu étant donné qu'un mot de passe ne peut être utilisé qu'une seule fois.

Horodatage modifier

L'horodatage est une autre façon d'empêcher une attaque par rejeu. En effet, l'horodate empêche de rejouer un message une seconde fois.

Fonctionnement de l'horodatage modifier

Voici comment pourrait fonctionner la gestion d'un horodate dans une identification par mot de passe résistante aux attaques par rejeu :

  1. Alice obtient l'horodate de son système d'exploitation. Ensuite, elle applique une fonction de hachage cryptographique à la concaténation de l'horodate et de son mot de passe, puis elle envoie l'horodate et le résultat de la fonction de hachage à Bob ;
  2. De son côté, Bob, qui connaît le mot de passe d'Alice effectue le même calcul en utilisant l'horodate fourni par Alice ;
  3. Si le résultat fourni par Alice et celui calculé par Bob sont identiques, il n'y a pas de rejeu et la connexion est réussie ;
  4. Supposons maintenant qu'un attaquant, Ève, a capturé l'horodate et le résultat de la fonction de hachage transis par Alice au cours d'une session précédente et tente de les utiliser dans une autre session pour usurper l'identité d'Alice. Bob refusera la communication parce que l'horodate ne sera pas dans un intervalle raisonnable, par exemple, il date de plus de deux secondes, ce qui indique qu'il provient probablement d'une session précédente. Si Ève rafraichit l'horodate par le temps actuel, Bob refusera la communication parce que son résultat de la fonction de hachage sera différent de celui fourni par Alice étant donné que deux horodates différents sont utilisés dans les deux calculs.

Le protocole précédent permet à Bob de vérifier l'identité d'Alice, mais il ne permet pas à Alice de vérifier l'identité de Bob. Pour permettre à Alice de vérifier l'identité de Bob, il suffit d'ajouter les étapes suivantes après l'étape 3 :

  • Bob applique une fonction de hachage cryptographique à la concaténation de l'horodate et du mot de passe d'Alice auquel il a fait une petite modification connue d'Alice (par exemple, il ajoute la lettre z à la fin du mot de passe), puis il envoie le résultat à Alice ;
  • Alice, qui connaît l'horodate et son mot de passe effectue le même calcul ;
  • si le résultat fourni par Bob et celui calculé par Alice sont identiques, Alice sait que l'expéditeur connaît son mot de passe. Elle est donc certaine d'être en communication avec Bob.

IPSec modifier

IPSec implémente un mécanisme d'anti-rejeu basé sur l'utilisation d'un code d'authentification de message ou MAC (Message Authentication Code).

Exemple d'attaque par rejeu : système d'entrée sans clé pour véhicules modifier

De nombreux véhicules possèdent un système d'entrée sans clé qui permet au propriétaire d'un véhicule d'entrer dans le véhicule sans avoir besoin d'une clé. Le véhicule détecte un signal RF émis par un petit dispositif électronique (par exemple un porte-clés) et ouvre la porte du véhicule lorsque le signal est détecté.

Les systèmes modernes résistent aux attaques par rejeu simples en changeant le mot de passe à chaque utilisation. Cependant, ils sont vulnérables aux attaques par rejeu utilisant une mémoire tampon.

Cette attaque est réalisée en plaçant un dispositif qui peut brouiller, recevoir et transmettre des ondes radio à portée du véhicule cible. Le dispositif bloque tout signal de déverrouillage du véhicule qui lui est envoyé, tout en le plaçant dans un tampon pour une utilisation ultérieure.

Lors d'une nouvelle tentative de déverrouillage du véhicule, le dispositif bloque le nouveau signal, émet le signal qui est dans le tampon et place le nouveau signal dans le tampon, créant un tampon roulant qui contient toujours le prochain signal attendu par le véhicule. Plus tard, l'attaquant peut utiliser le signal dans le tampon pour déverrouiller le véhicule[1],[2].

Notes et références modifier

  1. (en) S. van de Beek et F. Leferink, « Vulnerability of Remote Keyless-Entry Systems Against Pulsed Electromagnetic Interference and Possible Improvements », sur IEEE Transactions on Electromagnetic Compatibility, (DOI 10.1109/TEMC.2016.2570303, consulté le ), p. 1259–1265
  2. (en) Aurelien Francillon, « Attacks on Passive Keyless Entry and Start Systems in Modern Cars », sur eprint.iacr.org/ (consulté le )