Attaque par rejeu

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.

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.

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.

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.

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 implémente un mécanisme d'anti-rejeu basé sur l'utilisation d'un code d'authentification de message ou MAC (Message Authentication Code).