Traduction [1] d’un article de Jimmy Song publié sur bitcointechtalk.com le 21 août 2017 :
La décision des développeurs de Segwit2x de ne pas inclure de protection « replay » fait polémique. Dans cet article, je vais expliquer ce qu’est une attaque par rejeu [2] et comment une telle attaque pourrait affecter le fork 2x à venir.
Transactions Bitcoin
Afin de comprendre ce qu’est une attaque par rejeu, nous devons d’abord comprendre comment fonctionne une transaction bitcoin.
Bitcoin peut être considéré comme un grand registre mondial et les transactions Bitcoin comme des chèques bancaires. Étant donné que ce grand livre mondial est numérique, une personne qui veut pouvoir auditer ce registre doit télécharger une copie complète de la chaîne de blocs.
Cela signifie également que ces chèques sont publics. C’est-à-dire que tout le monde peut se pencher sur une transaction particulière et vérifier la validité de sa signature numérique.
« Hard fork »
Un « hard fork » c’est une mise à jour [un peu particulière] de ce grand registre mondial. Si tout le monde l’effectue, ce livre reste unique. Sinon, au lieu d’un registre unique, il y en a deux désormais : le registre traditionnel et une version alternative.
Jusqu’à la scission, les registres comptables sont exactement les mêmes. Ils partagent exactement le même historique de transactions. Mais après le fork, à mesure que de nouveaux blocs sont trouvés, les deux registres comptabilisent des transactions différentes et, par conséquent, des soldes différents.
Cela s’est produit, par exemple, lors du « hard fork » de Bitcoin Cash le 1er août 2017.
L’attaque par rejeu
Si vous possédiez un montant sur le registre avant la scission, vous aurez le même montant sur chacun des deux livres après la scission. Mais que se passe-t-il si vous voulez à présent dépenser des fonds sur une seule chaine seulement et pas sur l’autre ?
C’est problématique, car si vous dépensez sur un registre, quelqu’un pourrait copier votre chèque, qui contient votre signature, et le valider dans l’autre livre. Sitôt que votre signature est valable d’un côté, on peut l’utiliser de l’autre. Bien sûr, le destinataire et la somme doivent être exactement les mêmes (sinon la signature serait invalide), mais cela présente tout de même un risque.
On dit que la personne qui présente la copie du chèque sur l’autre registre rejoue la transaction […]. Nous appelons cela une attaque « replay ».
Bitcoin Cash a résolu ce problème en marquant de façon spécifique les chèques du registre BCH afin qu’ils ne soient pas reconnus dans le registre Bitcoin. Ainsi, les nœuds Bitcoin rejettent automatiquement les chèques BCH qui comportent cette marque spéciale et les nœuds Bitcoin Cash rejettent les chèques Bitcoin car cette marque est absente.
Cette marque particulière s’appelle une « protection replay » car elle empêche ce type d’attaques.
Segwit2x
Les développeurs de Segwit2x refusent d’ajouter une protection replay. Ils affirment que c’est aux développeurs de Bitcoin Core d’ajouter cette protection si ça les préoccupe. [3]
Malheureusement, la plupart des systèmes de protection contre les attaques par rejeu nécessitent un « hard fork ». Comme un « hard fork » n’est pas rétro-compatible et que tout le monde ne fait pas les mises à jour en temps et en heure, mettre en place une telle protection sur Bitcoin Core provoquerait une scission supplémentaire. Certains développeurs de Bitcoin Core ont estimé que tout « hard fork » qui n’est pas planifié plus de 12 mois à l’avance entraînerait ce scénario.
Ainsi, si Bitcoin Core décidait d’ajouter une protection « replay » dans le court laps de temps avant le fork Segwit2x (3 mois), cela créerait très probablement trois registres : Segwit2x, Bitcoin avec protection replay et Bitcoin « legacy ». Sans compter Bitcoin Cash […]. Une protection replay sur Bitcoin Core est donc inenvisageable.
Alternatives
Si vous êtes un utilisateur de Bitcoin et que vous souhaitez vous protéger contre les attaques par rejeu après le fork 2x, vous devrez séparer vos comptes sur chacun des deux registres : Bitcoin Core et Segwit2x.
Les utilisateurs peuvent séparer leurs comptes en combinant les transactions. Cela nécessite de trouver une transaction sur une chaîne qui n’est pas rejouable sur l’autre. Il existe au moins une catégorie de transactions qui ne sont pas rejouables.
Les transactions de génération [4] créées après le fork, seront différentes sur les deux chaînes. Ces transactions ne sont donc pas valides sur les deux registres en même temps. Si vous créez une transaction qui se mélange à une transaction sans rejeu possible, le résultat c’est une autre transaction non rejouable. Ainsi, toutes les transactions se mêlant aux transactions de génération seront elles-mêmes non rejouables et les transactions qui se combinent avec elles seront elles aussi protégées. En se mélangeant ainsi, de nombreuses transactions non rejouables se propageront dans le système.
Les « exchanges » mettront peut-être en place des services de « mixing » pour faciliter les transactions sur les deux chaînes.
Conclusion
Pour ceux qui n’effectuent pas beaucoup de transactions, les attaques de rejeu ne seront pas un gros problème. Après la fork 2x, il faudra simplement attendre qu’une solution claire et accessible soit proposée avant d’effectuer à nouveau des transactions.
Le problème de l’attaque de rejeu est préoccupant, mais l’expérience de Bitcoin Cash montre que ce n’est peut-être pas si terrible que cela après tout.
Source : bitcointechtalk.com
[1] Avertissement : il s’agit d’une traduction non-professionnelle. En cas de doute veuillez consulter le texte original.
[2] 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.
[3] Ce choix est politique. Alors que les développeurs de Bitcoin Cash proposaient une alternative à Bitcoin, les développeurs de Segwit2x prétendent travailler sur ce qu’ils considèrent comme le « vrai » Bitcoin.
[4] Toutes les dix minutes environ, de nouveaux bitcoins sont créés ex-nihilo pour récompenser les mineurs. Une telle transaction de génération est appelée « coinbase » (Attention : cela n’a rien à voir avec la société Coinbase).
