En 1993, les cryptographes la qualifiaient d'« attaque la plus simple qui soit » : prendre un message valide, attendre, puis le renvoyer. Personne ne construit un coffre-fort en prévoyant que la clé sera réutilisée.
Mais c'est précisément ce qui s'est produit lors de la séparation d'Ethereum et d'Ethereum Classic : une même transaction signée, diffusée sur les deux chaînes, a transféré des fonds réels à deux reprises. Aucun piratage, aucun mot de passe volé, aucun lien d'hameçonnage.
Une attaque qui se répète, faisant ce qu'elle a toujours fait : utiliser la légitimité comme arme.
Rejoignez l'UEEx
Découvrez la plateforme de gestion de patrimoine numérique leader au monde
Qu'est-ce qu'une attaque par rejeu (Replaying Attack) ?
Une attaque par relecture est un type de violation de la sécurité du réseau dans lequel un attaquant intercepte des transmissions de données valides et les réutilise ou les renvoie de manière malveillante pour tromper un système.
Contrairement aux attaques qui modifient ou falsifient les données, une attaque par relecture retransmet simplement des informations précédemment capturées, telles que les informations de connexion, les jetons d'authentification ou les demandes de transaction, pour tromper un système en lui faisant croire qu'il reçoit une nouvelle commande légitime.
Note gentille: Une attaque par rejeu (attaque par rejeu) peut se produire sur la même chaîne ou sur une chaîne croisée.
Quelle est la différence entre une attaque par replay sur la même chaîne et une attaque par replay sur une chaîne différente ?
Une attaque par rejeu sur la même chaîne se produit au sein d'une même blockchain : la même transaction ou le même message signé est soumis plusieurs fois au même réseau.
Le mécanisme de nonce empêche cela pour les transactions Ethereum standard ; une fois qu’un nonce (numéro à usage unique) est consommé, la même transaction est rejetée.
Les attaques par rejeu inter-chaînes se produisent entre deux blockchains qui partagent des formats d'adresse et une logique de signature, le plus souvent après une bifurcation dure.
Le nonce (numéro à usage unique) est inutile ici, car les deux chaînes gèrent les nonces indépendamment. Une transaction avec le nonce 5 sur Ethereum et une autre avec le nonce 5 sur Ethereum Classic correspondent à des enregistrements différents sur des systèmes différents, mais les données de la transaction signée sont identiques.
L'identifiant de chaîne de l'EIP-155 corrige spécifiquement le problème de la relecture inter-chaînes. Pour la vérification de la signature des contrats intelligents, le séparateur de domaine de l'EIP-712 gère les variantes au sein d'une même chaîne et entre chaînes.
Rejoignez l'UEEx
Découvrez la plateforme de gestion de patrimoine numérique leader au monde
Quand les attaques par rejeu ont réellement eu lieu : trois cas documentés
Les attaques par rejeu dans la blockchain ne sont pas théoriques. Elles ont causé des pertes financières avérées à de multiples reprises.
Le fork Ethereum/Ethereum Classic — 2016
Lorsque le réseau Ethereum s'est divisé en Ethereum (ETH) et Ethereum Classic (ETC) suite au piratage de la DAO, chaque transaction signée avant la bifurcation était valide sur les deux chaînes.
Les deux chaînes partageaient des espaces d'adressage, des formats de transaction et une logique de vérification de signature identiques.
Une transaction signée par n'importe quel portefeuille était simultanément une transaction valide sur ETH et ETC.
Les plateformes d'échange qui détenaient des fonds d'utilisateurs d'ETH et d'ETC sont immédiatement devenues des cibles.
Des pirates ont intercepté des transactions de retrait d'ETH valides et les ont rejouées sur la chaîne ETC, vidant ainsi les soldes d'ETC que les utilisateurs n'avaient aucune intention de toucher.
Plus de 40 000 ETC ont été retirés des plateformes d'échange au cours de la période suivant la bifurcation, avant que la protection contre la relecture ne soit largement mise en œuvre.
Cet événement a directement conduit à la création de l'EIP-155.
La fusion Ethereum — 2022
Lors de la transition d'Ethereum de la preuve de travail à la preuve d'enjeu (la fusion), une chaîne dérivée appelée Ethereum a été créée. PoW (ETHW) a été créé.
En quelques jours, un attaquant a exploité le contrat inter-chaînes Omni Bridge, qui ne disposait d'aucune protection contre la relecture spécifique à ETHW, et a rejoué des transactions qui ont transféré 200 ETHW depuis le contrat de pont.
L'attaquant a utilisé les données de prix de l'oracle du réseau principal ETH sur la chaîne ETHW, où elles étaient obsolètes et manipulables, dans le cadre de l'exploitation.
Le vol de jetons Optimism OP — 2022
Lors d'un incident de relecture inter-chaînes, 20 millions de dollars en jetons OP ont été volés à Optimism au cours d'une séquence de transactions multisignatures contestée.
L'attaque a exploité la faille entre les contextes de chaîne L1 (Ethereum) et L2 (Optimism), où une relecture d'un message signé spécifique sur la mauvaise chaîne a déplacé des jetons sans autorisation.
Il ne s'agit pas d'incidents isolés. Ils représentent un schéma documenté : chaque fois qu'une nouvelle bifurcation ou un déploiement de couche 2 crée deux environnements qui partagent des formats d'adresse ou de signature sans liaison spécifique à la chaîne, un risque de rejeu existe.
Repensez à la dernière fois qu'une nouvelle chaîne a été lancée et partageait votre adresse Ethereum. Avez-vous vérifié la validité de vos autorisations signées existantes sur cette nouvelle chaîne ? Avez-vous vérifié que le schéma de signature de votre portefeuille incluait l'EIP-155 ? La plupart des gens ne l'ont pas fait. La plupart n'ont eu aucun problème. Mais ceux qui ont rencontré des difficultés ont perdu de l'argent réel, et aucun ne s'y attendait.
EIP-155 : La solution qui a suivi la bifurcation de 2016
L'EIP-155, introduite par le cofondateur d'Ethereum, Vitalik Buterin, en 2016, a été créée spécifiquement pour empêcher que les transactions ne soient rejouées sur des chaînes bifurquées.
La solution était simple en principe : intégrer l’identifiant unique de la chaîne (chainId) dans chaque signature de transaction.
Avant EIP-155, une signature de transaction couvrait six champs de données : nonce, prix du gaz, limite de gaz, adresse du destinataire, valeur et données.
La signature était valable sur toute chaîne compatible EVM utilisant la même logique de vérification, car aucun de ces champs n'identifiait la chaîne spécifique pour laquelle la transaction était destinée.
Après EIP-155, les transactions incluent trois champs supplémentaires dans le hachage de signature : chainId et deux valeurs d’espace réservé vides.
Une transaction signée pour Réseau principal Ethereum (chainId = 1) n'est pas une signature valide sur Optimism (chainId = 10), Polygon (chainId = 137) ou toute autre chaîne EVM.
Le nœud qui reçoit la transaction vérifie l'identifiant de la chaîne (chainId) par rapport au sien et rejette toute incohérence.
Cette simple modification a considérablement réduit les attaques par rejeu inter-chaînes pour les transactions standard.
La principale limitation : La norme EIP-155 protège uniquement les transactions Ethereum brutes.
Il ne protège pas les signatures au niveau de l'application, c'est-à-dire les messages signés que les contrats intelligents vérifient en interne à l'aide de la fonction ecrecover.
Un contrat qui valide des signatures hors chaîne sans vérifier l'identifiant de la chaîne (chainId) reste vulnérable aux attaques par rejeu, même si l'EIP-155 est pleinement implémentée au niveau de la transaction. C'est là qu'intervient l'EIP-712.
Le nonce — Comment il empêche la réutilisation au sein d'une même chaîne
Le nonce (numéro à usage unique) est le mécanisme qui empêche les attaques par rejeu au sein d'une même blockchain. Chaque compte Ethereum possède un compteur qui démarre à 0 et s'incrémente de 1 à chaque transaction.
Lorsque vous soumettez une transaction avec un nonce = 5, le réseau ne l'accepte que si le nonce de votre compte actuel est exactement égal à 5.
Une fois traité, le nonce de votre compte devient 6, et toute tentative de rejouer la transaction nonce-5 échoue car le réseau attend désormais le nonce 6.
C’est pourquoi il est impossible d’envoyer deux fois la même transaction Ethereum sur la même chaîne : le nonce l’empêche. L’analyse de Gate.io de mars 2026 a révélé que le nonce seul empêche la réexécution sur une même chaîne, mais pas la réexécution entre chaînes, car chaque chaîne conserve un nombre de nonces distinct.
Votre nonce de compte sur le réseau principal Ethereum et votre nonce de compte sur Ethereum Classic sont suivis indépendamment.
Une transaction avec un nonce de 5 sur Ethereum peut également avoir un nonce de 5 sur Ethereum Classic si le même nombre de transactions a été effectué sur les deux chaînes. L'EIP-155 comble cette lacune en intégrant l'identifiant de la chaîne (chainId) à la signature.
Rejoignez l'UEEx
Découvrez la plateforme de gestion de patrimoine numérique leader au monde
L'EIP-155 a résolu les attaques par rejeu au niveau des transactions. Elle n'apporte aucune solution à la vérification de la signature des contrats intelligents.
Lorsqu'un contrat intelligent utilise ecrecover pour valider une signature hors chaîne, il vérifie un message, et non une transaction. La protection chainId de l'EIP-155 s'applique à la transaction Ethereum qui transporte le message, et non au contenu du message lui-même.
Si un développeur crée un contrat qui valide les signatures sans inclure l'identifiant de la chaîne, l'adresse du contrat et le nonce dans les données signées, ces signatures peuvent être rejouées par quiconque les intercepte.
La norme EIP-712 (Signature de données structurées typées) répond à cette problématique. Elle définit une méthode standard pour structurer les messages signés, incluant un séparateur de domaine, un hachage intégrant l'identifiant de la chaîne, l'adresse du contrat de vérification, ainsi que le nom et la version du contrat.
Une signature créée sous EIP-712 est liée à un contrat spécifique à une adresse spécifique sur une chaîne spécifique.
Il est impossible de le rejouer sur une chaîne différente ou un contrat différent, même si le bytecode est identique.
Pour les développeurs : avant de déployer un contrat vérifiant des signatures hors chaîne, assurez-vous que votre schéma de signature inclut les trois éléments suivants : nonce (empêchant la réutilisation d’un même message), chainId (empêchant la relecture inter-chaînes) et adresse du contrat (empêchant la relecture inter-contrats). La bibliothèque ECDSA d’OpenZeppelin, à partir de la version 4.7.3, implémente correctement ces trois éléments.
Systèmes et protocoles vulnérables aux attaques par rejeu
Système cible / Protocole
Pourquoi est-il vulnérable
Exemples courants et défauts
Réseaux sans fil
La transmission en plein air facilite l'interception et la retransmission des données.
Wi-Fi obsolète (WEP/WPA faible) sans séquencement des paquets ; appareils Bluetooth sans validation de nonce ou sans appariement de session.
Protocoles cryptographiques
Repose sur des clés statiques ou ne comporte pas de contrôles de fraîcheur contextuels.
Kerberos ou OAuth lorsque les jetons de session ou les informations d'identification ne comportent pas d'horodatages stricts ni de règles d'expiration.
Internet des Objets (IoT)
Privilégie la faible consommation d'énergie et la facilité d'utilisation à une sécurité renforcée.
Serrures et caméras intelligentes utilisant des protocoles IoT (MQTT, CoAP) sans protection contre la relecture intégrée en raison d'une puissance de calcul limitée.
Systèmes de paiement
Vulnérable si les transactions ne comportent pas de codes d'authentification dynamiques à usage unique.
Cartes sans contact et terminaux de point de vente plus anciens dépourvus de cryptogrammes EMV ou de jetons par transaction.
1. Validation de l'horodatage et surveillance des journaux
Les attaques par rejeu réutilisent souvent des données sans modifier leur horodatage d'origine.
En surveillant et en validant les horodatages, les systèmes peuvent détecter les retards inattendus des messages ou leur arrivée en dehors d'une plage horaire acceptable.
Implémentez des contrôles de validité stricts basés sur le temps pour les jetons, les transactions et les appels d'API.
Signaler les messages qui semblent être retardés ou traités en dehors d'une durée de session normale.
Croisez les journaux système pour identifier les demandes avec des horodatages identiques qui apparaissent plus d'une fois.
2. Détection des messages en double
L'une des principales caractéristiques des attaques par rejeu est la répétition de messages ou de paquets identiques.
Les systèmes doivent surveiller ces schémas, notamment dans des domaines critiques tels que l'authentification, les transactions financières et la gestion des sessions.
Utilisez le hachage ou l’empreinte digitale pour détecter les paquets ou les requêtes en double.
Comparez les données entrantes aux entrées récemment traitées pour vérifier le contenu répété.
Enregistrez et examinez les jetons de session répétés, les appels d'API ou les charges utiles chiffrées.
3. Suivi du numéro de séquence et du nonce
Les systèmes sécurisés s'appuient souvent sur des numéros de séquence ou des nonces (numéros à usage unique) pour suivre et valider l'unicité des données.
Les messages rejoués réutilisent généralement le même nonce ou numéro de séquence, ce qui peut être signalé.
Conservez une mémoire à court terme (cache ou base de données) des nonces ou des numéros de séquence récemment utilisés.
Supprimer ou enregistrer les requêtes contenant des valeurs réutilisées.
Alerte sur les jetons de session ou les identifiants de demande qui ont déjà été traités.
4. Détection des anomalies comportementales
Les attaques par rejeu ne sont pas toujours des copies techniques ; parfois, le contexte comportemental peut révéler la menace.
Par exemple, un utilisateur effectuant exactement la même transaction deux fois en quelques secondes pourrait éveiller les soupçons.
Surveillez le comportement des utilisateurs et créez des profils de base pour une activité normale.
Signalez les modèles anormaux tels que les actions répétées à haute fréquence, les demandes identiques provenant d'adresses IP différentes ou les connexions multiples utilisant le même jeton.
Intégrer des systèmes de détection d’anomalies capables d’apprendre et de s’adapter aux schémas de trafic typiques.
5. Analyse du trafic réseau
Des outils de détection avancés peuvent analyser le trafic réseau en temps réel pour rechercher des modèles suspects, en particulier dans les environnements sans fil ou IoT où les attaques par relecture sont courantes.
Utilisez des systèmes de détection d’intrusion (IDS) ou des systèmes de prévention d’intrusion sans fil (WIPS) pour détecter les retransmissions de paquets suspects.
Analysez les en-têtes de paquets pour les identifiants, les nonces ou les paramètres de chiffrement réutilisés.
Faites attention aux charges utiles chiffrées répétitives qui ne varient pas entre les sessions.
6. Analyse des jetons de session et des journaux d'authentification
Les attaques par rejeu impliquent souvent la réutilisation de jetons d'authentification. Les systèmes doivent auditer et analyser les journaux d'émission et d'utilisation des jetons afin d'identifier les jetons qui semblent réutilisés ou mal utilisés.
Suivez la durée de vie des jetons de session et les informations IP/appareil associées.
Enregistrez les tentatives de réutilisation des informations d'identification d'authentification expirées ou déjà utilisées.
Enquêter sur les tentatives de connexion qui réutilisent les en-têtes, les métadonnées ou les détails de session.
Quelle est la différence entre une attaque par relecture et une attaque MITM ?
Une attaque par relecture consiste à capturer et à renvoyer des données valides pour tromper un système, tandis qu'une attaque de l'homme du milieu (MitM) intercepte et modifie activement la communication entre deux parties en temps réel.
Quels sont les types de paquets les plus courants capturés lors d’une attaque par relecture ?
Les types de paquets les plus courants capturés lors d'une attaque par relecture incluent les demandes d'authentification, les jetons de session, les messages de transaction et les commandes de contrôle utilisés dans les communications sans fil ou réseau.
Comment TLS empêche-t-il une attaque par rejeu ?
TLS empêche les attaques par relecture en utilisant des clés de session uniques, des numéros de séquence et des codes d'authentification de message (MAC) pour garantir que chaque message est récent et ne peut pas être renvoyé ou modifié sans détection.
Qu'est-ce qu'une attaque par rejeu Kerberos ?
Une attaque par relecture Kerberos se produit lorsqu'un attaquant capture et renvoie un message d'authentification Kerberos valide pour inciter le système à accorder un accès non autorisé sans se réauthentifier.
Rejoignez l'UEEx
Découvrez la plateforme de gestion de patrimoine numérique leader au monde
Les attaques par rejeu peuvent paraître simples, mais leur impact peut être grave, allant de l'accès non autorisé aux pertes financières et à l'interruption de service.
Il est essentiel de reconnaître les systèmes vulnérables, de comprendre le fonctionnement de ces attaques et d'appliquer des défenses multicouches telles que les nonces, les horodatages et le chiffrement.
Alors que les menaces continuent de cibler les points faibles des processus de vérification, la détection et la prévention précoces deviennent essentielles.
Renforcer les systèmes contre les attaques par rejeu ne se limite pas à la protection ; il s'agit aussi de garantir la confiance, l'intégrité des données et un service constant dans les environnements numériques où la sécurité ne doit pas être compromise.
Akindele T. Francis est un rédacteur polyvalent possédant une vaste expérience dans divers secteurs. Spécialisé dans la rédaction d'articles de blog, de contenus web, de pages de services, de textes commerciaux percutants, etc., Akindele a collaboré avec de nombreuses agences pour produire des contenus captivants et efficaces. Doté d'un sens aigu du détail et d'une passion pour la création de récits percutants, Akindele dépasse constamment les attentes de ses clients, obtenant des résultats et valorisant le message de la marque sur diverses plateformes.
Clause de non-responsabilitéCet article est fourni à titre purement informatif et ne doit pas être considéré comme un conseil en trading ou en investissement. Rien de ce qu'il contient ne doit être interprété comme un conseil financier, juridique ou fiscal. Le trading ou l'investissement en cryptomonnaies comporte un risque considérable de perte financière. Veuillez toujours faire preuve de diligence raisonnable avant de prendre toute décision de trading ou d'investissement.
