Un sérieux problème de sécurité dans le mécanisme de défi-réponse
2026-05-28T00:47:56+08:00
Une approche de défi-réponse consiste à envoyer une chaîne aléatoire (nonce) à la personne dont l’identité doit être vérifiée, puis à lui demander de signer cette chaîne à l’aide de sa clé privée. Cependant, cela pose un très sérieux problème de sécurité.
Par exemple, Alice veut vérifier Bob. Or Mallory s’interpose entre eux. Alors, ce qui suit se produit :
- Alice envoie le défi à 'Bob', qui est usurpé par Mallory.
- Mallory usurpe l’identité d’Alice pour transmettre ce défi à Bob et demander une réponse.
- Bob renvoie la réponse, puis Mallory la relaie.
Dans ce scénario, Mallory a réussi à usurper Bob auprès d’Alice et peut désormais mener des attaques MITM.
La solution consiste à éviter d’utiliser uniquement une chaîne aléatoire comme défi. Un bon défi devrait contenir au moins les éléments suivants :
- les informations d’identification concernant l’ancre de confiance du vérificateur et de la personne vérifiée (par exemple, une empreinte OpenPGP) ;
- les informations d’identification concernant le canal (par exemple, l’emplacement lors d’une vérification en face à face, le JID ainsi que les empreintes OMEMO lors d’une vérification sur XMPP, l’ID Matrix des deux parties et la salle lors d’une vérification sur Matrix) ;
- un horodatage ;
- le nonce, c’est-à-dire la chaîne aléatoire.
Autrement dit, le défi doit lier les identités du vérificateur et de la personne vérifiée, le contexte authentifié du canal ou de la session, un horodatage pour garantir la fraîcheur, ainsi qu’un nonce. Le vérificateur doit comparer les revendications d’identité signées avec les métadonnées de transport authentifiées.
Dans ce cas, Mallory devra modifier le contexte du canal pour tromper Bob (sinon Bob identifiera immédiatement le défi problématique et refusera de répondre), ce qui rendra la réponse invalide pour la vérification par Alice puisque le défi a été modifié.
Pour une sécurité encore plus forte, vérifiez-vous mutuellement.
