Vulnérabilité du Lightning Network : l'attaque par remplacement de cycle infini expliquée par Antoine Riard

Le Lightning Network, ses limites et ses vulnérabilités ?

Au cours des dernières années, le Lightning Network, une infrastructure de seconde couche (layer 2) pour Bitcoin, s'est imposé auprès de la majorité de la communauté comme la solution permettant de faire passer sa blockchain mère à l'échelle et d'envisager son adoption par des milliards de personnes.

Cependant, son utilisation est limitée par la scalabilité de l'infrastructure sous-jacente, Bitcoin. En effet, l’utilisation du Lightning Network nécessite au moins un UTXO on-chain, ce qui ne permettrait pas de supporter 8 milliards d'utilisateurs de manière non custodiale sans modifications importantes du protocole Bitcoin.

Que ce soit au niveau de la scalabilité de Bitcoin avec les covenants ou l'ajout de fonctionnalités au Lightning Network via les bLIPs, la jeunesse relative de Bitcoin (lancé en 2009) et du Lightning Network (conceptualisé et développé en 2015 et entré en production en 2018) justifie que de nombreuses discussions soient en cours concernant la correction de vulnérabilités, ainsi que sur des améliorations et modifications des protocoles.

⚡Pour aller plus loin – Qu'est-ce que le Lightning Network ?

Parmi les vulnérabilités du Lightning Network, l'attaque par « remplacement de cycle infini », ou « replacement cycling attack » en anglais, a récemment beaucoup fait parler d'elle. Présentée au mois d'octobre 2023 par Antoine Riard, développeur Bitcoin et Lightning francophone, cette attaque permettrait à un acteur malveillant de réaliser une sorte de double dépense.

À l'occasion de la conférence Surfin' Bitcoin 2024, nous avons rencontré Antoire Riard, qui a accepté de nous parler de cette attaque et de nous présenter, selon lui, les solutions pour réparer cette vulnérabilité.

L'attaque par remplacement expliquée par Antoine Riard

Pour mieux appréhender cette attaque, voici quelques bases sur le fonctionnement du Lightning Network :

Les canaux de ce layer 2 sont avant tout constitués d'une transaction d'ouverture à partir de laquelle un ensemble de transactions d'engagement est généré, représentant les soldes de paiement entre les 2 parties du canal.

Chaque fois qu'une nouvelle transaction a lieu dans le canal, une nouvelle transaction d'engagement est émise, tandis que l'ancienne est révoquée. Cela signifie que l'ancienne transaction d'engagement ne peut plus être soumise sur la chaîne principale sans exposer la partie qui tente de la publier à des risques importants, car des mécanismes de pénalité sont en place pour dissuader toute tentative de fraude.

Antoine Riard a tenu à reprendre ces bases à ce sujet :

« Cela représente les balances, ensuite on va avoir les paiements qui eux sont formalisés par d'autres transactions qui vont s'ajouter aux transactions d'engagement, donc qui vont être des transactions de 2e étage qui représentent un "hashed timelock contract" (HTLC) »

Qu'est qu'un Hashed TimeLock Contract (HTLC) ?

Les Hashed TimeLock Contracts (HTLC), que l'on peut traduire en français par « contrats intelligents à déverrouillage alternatif par preuve temporel ou preuve de connaissance », permettent à un nœud du Lightning Network d'envoyer des fonds à un autre sans avoir à ouvrir un nouveau canal. Le paiement est acheminé de manière sécurisée et confidentielle à travers les nœuds intermédiaires du réseau jusqu'à atteindre le nœud destinataire.

Schématisation du réseau Lightning

Antoine nous donne plus de précisions sur les HTLC :

« Ce puzzle cryptographique est limité dans le temps, ce temps est celui de la chaîne de blocs. Il faut imaginer la chaîne de blocs comme une horloge qui va rythmer la vie de ce contrat. Donc ces transactions de 2e étage, il y en a 2 sortes : il y a les transactions qui réclament le paiement et les transactions qui périment cette promesse de paiement. Après que le verrou temporel de ce puzzle cryptographique [les HTLC] soit devenu mature par rapport à la chaîne de blocs, les 2 transactions sont valides et peuvent être incluses dans la chaîne de blocs à tout moment. »

C'est à ce moment-là que des acteurs malveillants peuvent intervenir. En effet, au moment où ces 2 transactions deviennent valides, une des parties du canal pourrait utiliser le mécanisme de « Replace-By-Fee » (RBF) sur la blockchain pour tenter de remplacer une transaction par l'autre grâce à des frais plus élevés.

Ce remplacement de transaction par les frais, couplé à une transaction exécutée sur la seconde couche, peut permettre une perte des fonds. Antoine complète son explication comme cela :

« On s’est rendu compte que rien n'empêche une contrepartie d’utiliser une transaction de 2e étage, c'est à dire une transaction qui réclame le paiement, comme un remplacement légitime d’une transaction de péremption et cela dans une boucle. »

Pour vulgariser cette attaque, prenons l'exemple d'Alice et Bob qui sont engagés dans un canal :

Supposons qu'Alice décide de fermer le canal parce qu'elle n'a plus de nouvelles de Bob. La chaîne principale (Bitcoin) joue ici le rôle d'arbitre en cas de litige. Alice peut donc diffuser sa transaction d'engagement sur la chaîne pour fermer le canal, suivant la procédure normale.

👛 Découvrez notre top 12 des wallets pour sécuriser vos Bitcoins

Cependant, Bob, qui possède encore une transaction liée à un HTLC (promesse de paiement), pourrait s'en apercevoir avant la confirmation et tenter de retarder la transaction d'Alice en soumettant des transactions concurrentes avec des frais plus élevés, utilisant des mécanismes comme le Replace-by-Fee, jusqu'à ce que la transaction d'Alice expire et que celle de Bob soit validée.

Dans ce scénario, Alice, en tant que nœud de routage sur le Lightning Network, pourrait avoir plusieurs transactions HTLC en cours. Bob pourrait alors retarder la confirmation de la transaction de fermeture du canal, lui permettant ainsi de récupérer les fonds une fois que les HTLC expirent.

« Et une fois que la transaction de péremption est elle aussi mature sur le canal entrant par rapport à Alice, sachant que c'est le canal sortant qui est attaqué, on peut avoir une transaction de préimage qui se confirme dans le canal de paiement sortant et une transaction de péremption qui se confirme sur le canal entrant. Donc Bob aura gagné 1 BTC en sortie, et en entrée Alice aura une entrée nulle, donc Alice aura perdu 1 BTC. »

Antoine nous a ensuite expliqué que cette double dépense n'en est pas réellement une, mais plutôt une analogie soulignant que les soldes des comptes d'Alice ne sont pas équilibrés, sans que la transaction initiale d'Alice ne soit confirmée à aucun moment, constituant ainsi davantage un vol par dépassement dans la mempool. Mais cela peut devenir une double dépense lorsque les 2 canaux entrants et sortants sont confirmés sur la chaîne.

À quel point l'attaque par remplacement de cycle infini est-elle réalisable ?

Antoine Riard nous expliquait que des attaques par remplacement de cycle infini étaient bel et bien faisables, et qu'elles avaient déjà été réalisées sur un regtest, une blockchain parallèle à Bitcoin fonctionnant de manière presque identique principalement utilisée pour le développement privé.

« À quel point est-ce faisable ? Ça l'est dans le sens qu'on l'a exercé dans un laboratoire, sur ce qu'on appelle sur un regtest, mais sur un réseau mainnet, pour l'instant nous n'avons pas vu ce type d'attaque. »

Plusieurs solutions de mitigation ont été mises en place, mais elles pourraient ne pas être suffisantes :

« Certaines mitigations ont été déployées par les implémentations de Lightning, mais cela reste très controversé. Et il n'y a pas de convergence entre les experts, que les mitigations soient robustes en face d'adversaires qui ont une belle vue du réseau de propagation des transactions et qui pourraient adapter leur stratégie offensive à celle du défenseur. »

Antoine a ensuite souligné que ce type d'attaque pouvait également se produire lorsque les mempools sont vides et que les transactions sont confirmées rapidement :

« Il y a un point qui est intéressant à préciser, c'est que cette attaque peut être jouée quel que soit le niveau de congestion des memepools. Et ça veut dire que même quand les mempools sont vides et qu'une transaction peut être confirmée, à tout moment cette attaque peut être jouée et on pourrait voir à l'avenir des nœuds Lightning de routage qui perdent une partie de leur fonds à cause de ce genre de scénarios offensif. »

Les solutions contre l'attaque par remplacement

Pour contrer l'attaque par remplacement de cycle infini, plusieurs solutions ont été trouvées et implémentées dans les principaux logiciels Lightning, tels que Core Lightning, LND, Eclair et LDK.

Selon Antoine, la principale solution envisagée consiste à repropager les transactions de fermeture des canaux Lightning, c'est-à-dire à les réémettre sur le réseau de relais des transactions. Cette repropagation serait effectuée dans un délai plus ou moins aléatoire afin de compliquer la tâche de l'attaquant.

Illustration de la mempool de Bitcoin 

Toutefois, Antoine a bien précisé que cette solution avait ses limites :

« Sur Bitcoin, la publication des transactions se fait de manière publique afin de garantir que la compétition pour le minage des blocs et la collecte des frais de transaction reste transparente et accessible à tous, sans qu'il existe de chambre de soumission privée. Ainsi, un attaquant peut aussi adapter sa stratégie même avec une publication des transactions aléatoires. »

Cette solution a été adoptée par plusieurs implémentations du Lightning Network. Plus tard, Peter Todd a approfondi cette idée dans une publication de blog, où il a présenté le concept de rémission altruiste des transactions au niveau du layer 1. Ce concept permettrait d'augmenter la fréquence de repropagation des transactions, afin que la transaction légitime atteigne plus rapidement la mempool des mineurs de Bitcoin.

Cependant, une telle modification nécessite davantage de discussions, notamment parce qu'elle impliquerait des nœuds capables de supporter une bande passante plus élevée.

Cette attaque remet en question la manière dont le Lightning Network a été construit

En conclusion, Antoine Riard a souligné un point crucial concernant ce que révèlent ces types d'attaques :

« Il est important de rappeler, face à ces différentes classes d'attaques visant le Lightning Network, à quel point ce réseau reste un paradigme relativement jeune, même pour les experts qui sont toujours au milieu de leur courbe d'apprentissage. La véritable question est : comment réussir à superposer un protocole aussi complexe que Lightning sur une blockchain publique ? »

Les attaques par remplacement de cycle infini révèlent en effet que le problème ne réside pas directement dans le Lightning Network ou Bitcoin individuellement, mais dans la manière dont ces 2 protocoles communiquent et s'imbriquent l'un dans l'autre.

Antoine continue dans son explication :

« De la part des développeurs et des experts techniques, cela demande un travail conséquent de reconceptualisation et de réimplémentassions d'une partie assez conséquente des interfaces et du fonctionnement du 1er niveau. La 1re fois que les experts Lightning ont commencé à se poser ce genre de questions, c'était en 2018. La découverte de cette attaque nous pousse à nous demander : Est-ce qu'on a bien pensé la séparation entre les 2 étages ? Parce que 5 ans après, on découvre cette nouvelle attaque qui demande des mois, voire des années de travail supplémentaire. »

Alors que certains développeurs envisagent d'ajouter de nouvelles fonctionnalités à Bitcoin, d'autres réalisent qu'un travail important est encore nécessaire pour assurer le bon fonctionnement des infrastructures déjà existantes.

Cela remet en question la nécessité des débats autour de l'ajout de covenants et d'opcodes dans le script de Bitcoin par exemple, des changements qui pourraient modifier profondément la manière dont l'ensemble du réseau est construit. De telles modifications demandent un recul beaucoup plus important avant d'être implémentées.

🪙 Découvrez notre article détaillé sur les covenants, OP_CAT et OP_CTV : la potentielle prochaine mise à jour de Bitcoin

Contrairement à des blockchains alternatives comme Ethereum, dont le processus de mise à jour et de modification est bien plus centralisé, Bitcoin fait le choix d'une évolution lente. Et bien que cela puisse sembler frustrant pour certains crypto-enthousiastes, cette lenteur est en réalité une caractéristique essentielle pour préserver la décentralisation d'un protocole comme Bitcoin.

D'abord attiré par l'appât du gain, je suis maintenant piégé deep into the rabbit hole. Sans porte de sortie, je n'ai plus qu'à partager mes connaissances et transmettre la passion que j'ai pour Bitcoin. Je suis également le créateur d'Adopt a Block, un site éducatif dédié à Bitcoin.

Marius Farashi Tasooji

363 articles

Tous ses articles