Définition : de quoi parle-t-on ?

Une attaque par rejeu, ou replay attack, consiste à capturer un message valide et à le renvoyer à l’interacteur original ou à un tiers pour obtenir un avantage. Ce mécanisme exploite la non‑uniqueness des transactions ou des authentifications. Contrairement à la falsification, le message n’est pas modifié, il est simplement répété. L’objectif est de tromper le système en lui faisant croire que la transaction est nouvelle, entraînant ainsi des doubles dépenses, des accès non autorisés ou des actions malveillantes.

À quoi cela sert-il ?

Le but d’une attaque par rejeu est de dupliquer l’effet d’une transaction légitime sans autorisation supplémentaire. Dans les réseaux décentralisés, un attaquant peut capturer une signature ou un token d’accès et le retransmettre pour revendiquer deux fois le même droit, comme un double paiement ou un accès répété à un service. Cette technique vise à exploiter les délais de validation, les non‑marquages de transactions uniques ou l’absence de mécanismes anti‑replay.

Comment cela fonctionne, étape par étape

1. Capture du message original L’attaquant intercepte un échange légitime, par exemple une transaction signée ou un jeton d’accès, via un réseau non sécuritaire ou un point d’entrée vulnérable. Il stocke ce message sans le modifier, préservant ainsi la validité de la signature et les métadonnées nécessaires à l’authentification. Cette capture est la première étape indispensable pour pouvoir reproduire l’action initiale.
2. Envoi du message capturé Le pirate réinjecte le message stocké vers le destinataire original ou vers un service cible. Pour réussir, il doit s’assurer que le système accepte le message tel quel, sans vérifier son historique. L’envoi peut se faire via une requête HTTP, un appel de fonction dans un contrat intelligent ou un transfert de jeton, selon l’environnement cible.
3. Validation sans vérification d’unicité Le système cible traite le message comme nouveau car il n’a pas de mécanisme anti‑replay. Il vérifie uniquement la signature, le format et les droits d’accès, puis exécute l’action demandée. Ainsi, l’attaquant obtient un double paiement ou un accès répété sans autorisation supplémentaire, reproduisant l’effet de la transaction originale.
4. Détection et mitigation Pour contrer les attaques par rejeu, les systèmes intègrent souvent des jetons nonce, des horodatages ou des registres de transactions déjà traitées. Le nonce, par exemple, est une valeur unique assignée à chaque requête; le serveur refuse toute requête avec un nonce déjà vu. Ces mécanismes empêchent la répétition d’un même message et assurent l’intégrité des opérations.

Exemple concret (scénario fictif)

Dans un réseau de paiement décentralisé, Alice envoie un virement de 10 € à Bob. Le message est signé et broadcasté. Un pirate, interceptant la transmission, enregistre la signature et l’identifiant de transaction. Peu de temps après, il transmet le même paquet au réseau, ciblant un deuxième compte, Carol. Le réseau, n’étant pas équipé d’un mécanisme de séquence unique, accepte la seconde transaction. Bob reçoit son paiement, mais Carol reçoit également les 10 €. Alice, voyant son solde inchangé, ne se rend pas compte de la perte. L'attaque entraîne une double dépense, une perte de confiance dans la plateforme et des frais de remise en ordre. Le réseau doit alors mettre en œuvre des nonces ou des timestamps pour empêcher ce genre de duplicata.

Différences et cas d’utilisation

Réutilisation d’une même transaction

Dans une attaque par rejeu, l’attaquant intercepte une transaction authentifiée, la stocke et la renvoie plus tard. Le réseau accepte la même opération, pensant qu’elle est nouvelle, ce qui conduit à une double dépense ou à une double validation d’un droit.

Manque d’un identifiant unique ou de délai

Les protocoles qui ne protègent pas les messages avec un numéro de séquence, un horodatage ou un jeton jetable sont vulnérables. Sans ces marqueurs, un même message reste valable indéfiniment, permettant à un acteur malveillant de le reproduire sans détection.

Impact sur la sécurité des portefeuilles

Un replay sur un portefeuille numérique peut entraîner la double dépense d’un même solde. Le système de synchronisation de l’état du portefeuille ne détecte pas toujours la réexécution, ce qui expose les utilisateurs à des pertes financières et à une confiance compromise.

Avantages et intérêts possibles

• L'utilisation de mécanismes anti-replay permet de renforcer la confiance des utilisateurs dans les transactions numériques, car elle empêche la duplication involontaire de messages valides et limite les tentatives de double-dépense, surtout dans les portefeuilles multi-signatures qui exigent une vérification stricte des identifiants.
• Les protocoles intégrant un champ de timestamp ou d’horodatage unique garantissent que chaque transaction est soumise dans une fenêtre temporelle limitée, ce qui réduit la surface d’attaque et rend plus difficile pour un adversaire de réinjecter un ancien message avant son expiration.
• En combinant un nonce aléatoire avec un mécanisme de revocation de clés, les développeurs peuvent créer des portefeuilles où chaque opération nécessite un identifiant unique, assurant ainsi que les requêtes réécrites sont immédiatement reconnues comme suspectes et rejetées.

Inconvénients et limites

• Malgré l'efficacité des anti-replay, ils introduisent un surcoût de performance, car chaque transaction doit être accompagnée d'un identifiant unique généré et vérifié, ce qui peut ralentir les chaînes à forte charge et augmenter la latence des confirmations.
• Les systèmes anti-replay reposent souvent sur des horodatages précis; une synchronisation incorrecte entre les nœuds peut entraîner des rejets légitimes, créant ainsi des blocages inutiles pour les utilisateurs et compliquant la maintenance des infrastructures.
• La mise en œuvre d'un mécanisme de nonce ou de timestamp peut augmenter la complexité du code, introduire des points de faille supplémentaires, et dans certains cas, rendre l’implémentation incompatible avec des protocoles existants ou des normes de conformité.

Risques réels à connaître

• Lorsque les protocoles ne intègrent pas de mécanisme d'unicité, un attaquant peut capturer une transaction de transfert de jetons et la renvoyer sans modification, ce qui conduit à une double dépense et à la détérioration de la confiance dans le portefeuille numérique.
• Dans un système où les identifiants de session ne sont pas temporaires, un acteur malveillant peut retransmettre un jeton d'authentification valide pour accéder à des services privés, entraînant une compromission de données sensibles et la perte de contrôle administratif sur le compte.
• Lorsque les réseaux de validation ne vérifient pas l'ordre chronologique des transactions, un replay d'une opération précédemment validée peut être accepté, ce qui provoque une inflation artificielle du jeton et un déséquilibre du marché, remettant en cause la stabilité économique du protocole.

Comment vérifier concrètement

• Vérifier l’existence d’un champ nonce unique et non réutilisable dans chaque message ; si le même nonce apparaît deux fois, le système doit rejeter la seconde tentative afin d’empêcher le replay de transactions déjà traitées.
• Mettre en œuvre un horodatage précis, accompagné d’une fenêtre temporelle stricte, permet de détecter les replays hors délai ; toute requête dont l’horodatage dépasse la limite prédéfinie doit être immédiatement invalidée par le serveur.
• Utiliser un identifiant de session persistant, revendu à chaque échange, empêche la réutilisation d’une même transaction dans un contexte différent ; cependant, la gestion des sessions doit être sécurisée pour éviter que le même identifiant ne soit compromis.
• Intégrer un mécanisme de « one‑time‑use » sur les jetons d’accès, où chaque jeton est invalidé après la première utilisation, limite les possibilités de replay même si le message est intercepté ; la mise en œuvre exige néanmoins un suivi précis des jetons expirés.

Pour aller plus loin

Ces références officielles permettent de recouper les règles et les mises en garde ; elles ne valident pas un projet particulier.

• AMF — informations et prévention pour les épargnants
• Débuter en crypto
• Checklist avant transfert
• Assistant anti-arnaque
• SOS crypto

FAQ