Tutorial : comment paralyser le Lightning Network de Bitcoin

Buvez un grand verre d’eau et respirez profondément – Derrière ce titre pour le moins provocateur se cache – comme vous allez le découvrir – un constat simple : le Lightning Network de Bitcoin est une grande expérimentation, et plus le temps avancera, plus des acteurs malveillants pourraient être incités à tenter de l’attaquer… même si c’est déjà le cas aujourd’hui. Nous n’allons donc pas réellement apprendre aujourd’hui à paralyser par nous-même le réseau en seconde couche de Bitcoin… par contre, nous allons voir ensemble que certains étudient sérieusement les méthodologies à mettre en oeuvre pour y parvenir.

Courant septembre, une étude à propos du Lightning Network de Bitcoin a commencé à faire surface sur les réseaux. Ses auteurs – Saar Tochner, Aviv Zohar et Stefan Schmid – en sont convaincus : le Lightning Network de Bitcoin est un outil pour le moins fragile. Pourquoi ? Parce qu’il suffirait de s’y connecter intelligemment pour parvenir à le parasiter jusqu’au point où la majorité des paiements sur le réseau ne pourraient tout simplement plus aboutir.

Le Lightning Network est-il définitivement damné ? Doit-on abandonner à jamais l’idée de payer son café en Bitcoin, et préférer se prostrer au sol en posture latérale de sécurité ? Voyons tout cela ensemble, camarades crypto-explorateurs !

Bases théoriques

Si vous tombez sur cet article un peu par accident, vous vous demandez peut-être que peut bien signifier tout ce charabia. Reprenons donc ensemble rapidement les différences principales entre le réseau Bitcoin et le Lightning Network, réseau construit en seconde-couche au dessus d’elle.

Bitcoin et ses bases

Au niveau de la blockchain Bitcoin, la possession de bitcoins se matérialise par des jeux de clés dites publiques et privées. Une clé privée est produite en choisissant au hasard n’importe quel nombre compris entre 1 et 2²⁵⁶. Ce nombre subit ensuite une opération mathématique particulière, que l’on appelle une multiplication de courbe elliptique (dite secp256k1, correspondant à l’algorithme ECDSA). L’on obtient ainsi ce que l’on appelle une clé publique Bitcoin. Cette clé publique est ensuite passée à la moulinette d’une autre fonction informatique – une fonction de hachage – pour obtenir une adresse publique. Cette dernière est utilisée pour recevoir des paiements et peut-être partagée sans risques. Elle peut commencer par un 1,un 3, ou par bc1 depuis certaines évolutions protocolaires. Ces adresses sont ensuite contrôlées pour plus de praticité sous la forme d’un portefeuille (aussi appelé wallet), centralisant les clés privées associées d’un utilisateur.

Ainsi, et pour résumer, vous contrôlez des clés privées que vous êtes le seul à connaître à l’aide d’un wallet, elles vous permettent de prouver que vous êtes propriétaire de fonds libellés en bitcoins (avec un b minuscule) sur le réseau Bitcoin (avec un B majuscule). Vous pouvez ensuite recevoir des bitcoins, et choisir de les envoyer à d’autres à l’aide du système d’adresses précédemment décrites.

Le Lightning Network : Bitcoin, mais en instantané

Mais lorsque vous vous essaierez à Bitcoin, vous constaterez que pour qu’une transaction en bitcoins soit acceptée par le réseau Bitcoin, il faut que passe un certain temps de confirmation : habituellement, il faudra attendre entre une dizaine à une trentaine de minutes, variable (avec des extrêmes possibles) selon la congestion relative du réseau au moment de votre transaction et les frais que vous accepterez de verser au réseau.

C’est pourquoi une solution est actuellement en développement pour permettre des transactions Bitcoin quasi instantanées : le Lightning Network. Construit par dessus le protocole Bitcoin, il permet de mettre sous séquestre des bitcoins sur le réseau Bitcoin en respectant les impératifs liés aux temps de validation (des bitcoins dits on-chain), puis de les dépenser instantanément et sans attendre sur la sur-couche logicielle du Lightning Network (des bitcoins dits off-chain).

Pour utiliser le réseau Lightning Network (aussi abrégé LN), il faut donc posséder des bitcoins on-chain et comme les « télécharger » sur ce réseau parallèle. Ce dernier repose sur des nœuds informatiques spécifiques, déployés en parallèle et au-dessus du réseau Bitcoin. Ils valident que les bitcoins reçus sur le LN sont de vrais bitcoins existants sur la blockchain Bitcoin.

Quelques détails nécessaires sur le LN

La mise sous séquestre

Pour pouvoir transférer des bitcoins on-chain vers ce réseau off-chain, il existe deux solutions : utiliser des portefeuilles compatibles avec Lightning Network et gérant à votre place un nœud informatique du réseau, ou bien déployer le vôtre. Une fois votre wallet (ou votre nœud) prêt, il faudra mettre en place des canaux de paiement vers d’autres nœuds LN.

Imaginons qu’Alice et Bob décident de créer un canal qu’ils alimentent tous les deux. Ils devront constituer un canal de paiement (payment channel) au niveau du réseau LN, c’est-à-dire qu’ils vont mettre sous séquestre au niveau de la blockchain Bitcoin des soldes de bitcoins à l’aide de transactions co-signées avec leurs clés privées respectives (ce que l’on appelle des transactions multisig).

Petite particularité : sur le Lightning Network, à l’heure actuelle, l’ouverture d’un canal de paiement n’implique pas que les deux participants contribuent financièrement à alimenter ce canal. Si chaque canal est par principe bidirectionnel (les fonds peuvent aller dans un sens comme dans l’autre), ils ne sont pas automatiquement alimentés par chacune des parties, mais principalement par celui qui initie l’ouverture.

Mais le réseau Lightning ne cherche pas seulement à permettre des paiements instantanés entre les utilisateurs qui ouvrent des canaux entre eux. Par extension, le but est de permettre de payer un autre utilisateur à qui l’on n’est pas connecté, du moment que d’autres nœuds avec qui nous partageons un canal partagent – eux – une connexion avec lui. L’idée est donc de permettre de construire un réseau en toile d’araignée permettant des paiements instantanés de tous vers tous, même si tous ne sont connectés qu’à quelques uns.

Pour y arriver, le LN repose sur les HTLC, pour Hash Time-locked Contracts. Dans un tel système, les paiements se font via des promesses conditionnelles, qui ne sont validées qu’à l’arrivée.

Ainsi, si Alice veut payer Dave via le LN, elle va en résumé répondre à une demande de paiement de Dave. Cette demande de paiement comprendra un secret (R) formaté à l’état de hash (H), secret que seule Alice détiendra, et qu’elle démontrera détenir ensuite pour délivrer son paiement. En résumé, c’est le hash (H) du secret (R) qui transite dans les canaux de paiement, et qui explique la nécessité de leur utilisation.

Sans entrer plus dans le détail, un réseau de nœuds interconnectés reposant sur HTLC permet en théorie – et sous conditions – à tous les acteurs de se payer mutuellement à un moment ou à un autre, instantanément et même s’ils ne sont pas directement connectés. Notons cependant que ces HTLC dépendent d’une condition temporelle, c’est-à-dire qu’ils correspondent à des demandes de paiement avec des limites dans le temps (habituellement, une demande de paiement sur LN expire en 24 heures).

Le réseau sur-couche, sa liquidité et son utilisation

Il reste néanmoins un certain nombre de nuances à apporter, ce que nous allons faire maintenant. Le LN est encore un réseau tout à fait embryonnaire, et nombre d’erreurs peuvent advenir lorsque l’on cherche à l’utiliser, même si ses implémentations logicielles évoluent constamment. Pour résumer très sommairement, il arrive encore souvent que des transactions soumises au réseau échouent à cause de multiples facteurs. Celui qui nous intéressera pour la suite de l’article est le suivant : la liquidité du réseau.

Comme nous l’avons dit précédemment, à l’heure actuelle, les canaux de paiement sont bidirectionnels, mais pas nécessairement alimentés de façon égale dans les deux sens de circulation entre les différents utilisateurs.

Pour exemple, voilà l’état des canaux ouverts (et en cours d’ouverture) d’un de mes nœuds LN personnels.

Comme vous pouvez le constater, mon nœud LN est connecté à trois autres nœuds LN. Il s’agit des nœuds de LNBIG.com (un des principaux fournisseurs de liquidité multiconnecté du réseau), de l’association étudiante Kryptosphère et de Namson Lê (UX Researcher chez Zap, un wallet compatible LN).

Il est également en attente de connexion avec le nœud de Jonathan Fraga, contributeur au Journal du Coin.

Comme vous pouvez le constater, les canaux qui n’ont pas encore été utilisés conservent des soldes uni-alimentés, dans le sens où seul celui qui a ouvert le canal de paiement a alimenté ce canal bi-directionnel. C’est le cas des canaux que j’ai ouvert avec Kryptosphère et Namson, mais c’est aussi le cas dans l’autre sens pour le canal que Jonathan a ouvert avec moi.

En définitive, schématiquement et dans le meilleur des cas, si je souhaite recevoir un paiement, je ne pourrais que recevoir le total des soldes distants venant vers moi, tandis que je ne pourrais qu’envoyer le total des soldes locaux alimentés de mon côté. Dans l’exemple précédent, le canal de Jonathan n’étant pas encore validé, je ne pourrais envoyer que 264 640 satoshis instantanément – et sous réserve d’autres facteurs indépendants de ma volonté. Je ne pourrais enfin recevoir que 68 634 satoshis pour l’heure, mais 364 563 satoshis une fois que tous les canaux seront ouverts. Je pourrais donc faire transiter mes satoshis vers un nœud non connecté au mien, du moment qu’il est lui-même connecté à d’autres nœuds de proche en proche jusqu’à être lié à un nœud de mon voisinage.

Il est donc important d’être connecté au réseau d’autres nœuds, et suffisamment bien pour pouvoir profiter au mieux du LN. Cependant, et comme nous allons le voir ci-après, le réseau est encore expérimental, et il convient de ne rester mesuré dans les soldes de bitcoins que vous mettez sous séquestre sur LN : gardez à l’esprit qu’il est possible de voir le réseau attaqué, de subir des bugs encore imprévus ou de perdre vos fonds à cause de mauvaises manipulations. On ne se lance pas à la conquête de l’or numérique sans prendre aucun risque. Préférez donc y mettre de l’argent de poche que vous accepteriez de perdre, sans que cette perte vous empêche de dormir si elle devait arriver. Votre serviteur parle d’expérience…

Embouteillages sur l’autoroute de la valeur

Pourquoi et comment attaquer le réseau Lightning ?

Revenons enfin à l’étude qui nous occupe : Saar Tochner, Aviv Zohar et Stefan Schmid en sont ses auteurs, et ils ont voulu tester la solidité du réseau LN actuel. Comment réagirait-il face à un attaquant qui souhaiterait perturber le bon fonctionnement du réseau ? Admettons que LN devienne un jour mainstream, pourrait-on l’attaquer pour le paralyser ? Cette étude se propose donc d’apporter des éléments de réponse, sans pouvoir pour autant être totalement catégorique. Comme nous allons le voir, le LN évolue constamment au gré des mises à jour de ses clients logiciels (répondant aux noms de lnd, c-lightning et eclair).

L’avarice est un vilain pêché

Leur idée est qu’un utilisateur malfaisant puisse déployer un nœud qui viendrait s’interfacer efficacement dans le réseau, de telle sorte qu’il finisse par y occuper une place relativement centrale. Une fois en place, il verrait transiter des transactions, puis déciderait de ne plus les transmettre. Ce faisant, il parviendrait perturber une partie des transactions en question, lesquelles ne pourraient pas aboutir. Pour parvenir à réellement menacer le réseau, les auteurs envisagent un attaquant qui déploierait en réalité plusieurs nœuds agressifs. En agissant de la sorte, l’attaquant contrôlerait à la fois les canaux de paiement les plus connectés et les plus empruntés, mais aussi les canaux secondaires principaux qui seraient utilisés par les clients logiciels comme solution de secours lors de l’échec de la première tentative de paiement.

Pour se placer dans cette position envieuse, les auteurs expliquent qu’il suffirait d’exploiter les mécanismes d’ouverture de canaux de chacune des implémentations du LN : ainsi, partant du principe que des paiements transiteront préférentiellement par des canaux demandant des frais de transaction très bas, les auteurs envisagent un modèle où un attaquant placerait des nœuds offrant des transactions quasi gratuites afin d’attirer un maximum d’utilisateurs.

Chaque implémentation utilise des modèles de consensus variés dit de gossip, permettant une organisation décentralisée de ces connexions au prix de certaines concessions.

Les conclusions de l’étude

L’étude considère ainsi qu’un tel attaquant, profitant d’une position établie centralisatrice (à la manière du noeud LNBIG évoqué précédemment), pourrait tirer partie des mécanismes de délai lié à la composante temporelle des HTLC et de sa position pour bloquer tous les paiements qui lui sont soumis, et ainsi paralyser le réseau. Les chiffres évoqués font froid dans le dos, comme vous allez le voir.

J’ai donc contacté les auteurs de l’étude pour obtenir des éclaircissements. Pour m’éclairer, M. Aviv Zohar m’a ainsi expliqué qu’il suffirait « d’ouvrir 20 canaux de paiement » de façon intelligente pour paralyser près de « 80% des transactions du réseau LN ». Ainsi, pour bloquer la quasi totalité des transactions inférieures ou égales à 100$ (une valeur déjà conséquente aujourd’hui sur le LN), il suffirait d’ouvrir « 20 canaux avec chacun 100$ affectés par canal, de telle sorte qu’il suffirait de mobiliser 2000$ » pour paralyser le réseau LN. Ces chiffres avaient ainsi été rapportés in-extenso en début de semaine par CoinDesk.

Cependant, et même si le Lightning Network n’en est qu’à ses débuts, une telle conclusion peut laisser pensif. A titre personnel, et même si j’accepte tout à fait l’idée que le LN soit à l’heure actuelle une expérimentation curieuse qui n’en est qu’à ses débuts, il m’a semblé étrange qu’il suffise de créer un nœud LN, de se connecter à 20 autres pairs et de proposer des frais très bas pour bloquer le réseau quasi intégralement, avec un simple capital de départ de 2000 dollars.

Des conclusions à mitiger

J’ai donc continué mes échanges avec les auteurs, qui sont pour l’heure encore en cours. J’en profite pour les remercier pour leur ouverture et leurs réponses avisées à des questions pas toujours des plus affûtées. Ils justifieront d’ailleurs peut-être une mise à jour de cet article et ses arguments et contre-arguments.

Mais il me fallait aussi d’autres avis éclairés : pour ce faire, j’ai contacté des contributeurs divers des trois principales implémentations de LN. Je n’ai pour l’heure pas pu obtenir de réponse du côté d’Acinq et de son client logiciel eclair, mais deux autres bonnes âmes ont accepté de me donner leur avis sur cette étude. Je remercie d’ailleurs également Messieurs Namson Lê et Antoine Poinsot pour leur disponibilité et leurs éclairages respectifs, respectivement contributeurs des clients lnd et c-lightning.

Dommages collatéraux

Précisons qu’il ne s’agit pas rejeter en bloc (vous l’avez ?) les conclusions de ladite étude. Fabrice Drouin, co-fondateur d’Acinq, société travaillant sur l’implémentation eclair, s’est d’ailleurs déjà exprimé auprès de CoinDesk, jugeant qu’il s’agissait d’une étude « très intéressante » et estimant qu’il était sain de voir « des chercheurs indépendants [s’intéresser au Lightning Network]« .

Pour autant, il convient de préciser qu’il peut sembler un peu étrange de considérer qu’il suffise de connecter son nœud directement en proposant des taux bas pour faire tomber le réseau, le tout pour un coût somme toute modique.

En effet, il est intéressant de tenir compte notamment des frais d’entretien exigés par le déploiement d’un nœud central au réseau. Il ne s’agit pas d’ouvrir 20 canaux, il faut encore assurer leur maintenance, payer les coûts variables on-chain d’ouverture puis de fermeture des canaux (notamment lors de la fermeture de canaux devenus inactifs car les nœuds rattachés ne sont plus réactifs). Précisons que même si la facture finale était un peu plus élevée, ces frais ne la feraient pas exploser au vu de la taille très réduite du LN  à l’heure actuelle. Pour mémoire, l’opérateur de LNBIG – voyant alors passer 40% de la capacité du réseau – évaluait à la louche ses frais de gestion de canaux à 1000$ d’ouverture et de fermeture de canaux par mois, soit pas non plus vraiment de quoi casser trois pâtes à un canard hacker.

Mais là où les choses se compliquent possiblement, c’est lorsqu’il faut considérer le fait que le système dynamique par lequel les nœuds s’envoient des paiements entre canaux tient compte des comportements récents de ses pairs.

Soignez votre réputation

Les nœuds ne sont pas aveugles. Si un de leurs pairs passe son temps à refuser de transmettre des paiements qu’un nœud lui envoie, le nœud expéditeur cherchera à le contourner en passant par ailleurs pour atteindre sa destination finale. Vous comprenez mieux pourquoi les auteurs de l’étude envisageaient donc un attaquant qui aurait investi sur plusieurs nœuds, de manière à tenter de bloquer les passages par les principaux chemins possibles.

Dans le cas de c-lightning, Antoine Poinsot nous a expliqué qu’un algorithme Djikstra assez simple était utilisé pour l’heure pour servir cet objectif. Du côté de lnd, Namson Lê évoque quand à lui une récente mise à jour datant de juin servant à peu près les mêmes objectifs, et introduisant une mécanique de routage des paiements probabiliste où la composante de l’efficacité et de l’honnêteté des nœuds des pairs entre en jeu dans la sélection des routes empruntées pour l’envoi des paiements. De plus, une fonctionnalité permettant de blacklister des nœuds considérés comme fautifs et éviter d’emprunter ces routes où sévissent les mauvais acteurs. L’investissement pourrait donc paraître quelque peu donc déraisonnable : en quelques attaques, les nœuds en question se retrouveraient blacklistés, et peu empruntés. 

En soi, il serait donc possible que les récentes évolutions (et celles à venir) de ces clients logiciels soient déjà suffisants pour mitiger toute attaque qui ressemblerait à celle décrite dans l’étude en question. Quel intérêt aurait un attaquant à s’insérer comme noeud de confiance principal du réseau, à entretenir cette place un temps certain, pour finalement voir sa fréquentation chuter et finalement se faire exclure des schémas de routage et ne plus être emprunté ? Eh bien… Tout simplement parce que ce système de réputation est loin d’être parfait.

Anonymisation relative

Comme nous l’avons décrit un peu plus haut, les paiements de pair-à-pair reposent sur les HTLC décrits précédemment. La particularité du LN est qu’il offre une anonymisation des noeuds : si mon voisinage de noeuds partageant des canaux directs avec moi sait que j’envoie des satoshis et les font passer, il ignore la destination finale de mon envoi. De la même façon, le noeud qui recevra mon paiement, s’il ne possède pas de canal direct avec moi, ne saura pas exactement d’où provient le paiement et le chemin qu’il aura emprunté.

C’est un avantage en terme de privacy, mais clairement un problème en terme de système de réputation : comme l’explique Aviv Zohar, les noeuds étant anonymisés, ils leur sera bien difficile de savoir précisément quel noeud est malicieux sur les routes empruntées. D’ailleurs, l’attaquant ayant déployé plusieurs autres noeuds malicieux pour se positionner comme routes de secours lors du premier échec de paiement, il pourrait alors plus ou moins continuellement continuer à refuser les paiements.

En résumé : si son voisinage proche pourrait se rendre compte de son comportement et l’exclure de leurs voies de transmission, ce ne serait pas nécessairement le cas des autres noeuds plus lointains. De même, il existe une composante temporelle dans le mécanisme de réputation : il suffirait de déployer un nœud honnête pendant deux semaines pour se positionner efficacement, les réputations en place ne gardant pas une mémoire plus ancienne des événements, et la plupart se basant principalement sur les dernières tentatives de paiement de chaque nœud. Ce n’est qu’après ce délai d’incubation que l’attaquant passerait à l’action.

La liquidité ne fait pas défaut

Enfin, et pour conclure, il faut considérer la question de la liquidité : si dans votre voisinage proche de nœuds interconnectés, il vous faut considérer votre liquidité locale, la situation est différente dans le contexte global LN. Pour permettre les échanges instantanés du LN, le système considère principalement la liquidité globale présente dans les canaux. Ainsi, selon M. Zohar, un attaquant qui viendrait ouvrir lui-même des canaux et entretiendrait deux semaines son nœud de façon honnête aurait toutes les chances d’attirer à lui des ouvertures de canaux. Il proposerait alors des frais bas pour faire transiter la majeure partie des paiements par lui, tout en déployant des nœuds adverses supplémentaires pour couvrir les voies de secours. En définitive, cela lui permettrait d’être certain de pouvoir paralyser les paiements à la hauteur de la liquidité qu’il aura fournie. 

Le mot de la fin

Si vous avez tenu jusque là, félicitations. 

En résumé, et pour conclure, nous venons d’explorer ensemble tant les bases de Bitcoin que celles de son réseau Lightning Network. Comme nous le répétons à longueur d’articles consacrés au LN, ce réseau reste foncièrement expérimental : qui dit expérimentation, dit risques. Ces risques ne veulent pas dire que la viabilité-même du réseau est remise en question : comme l’explique M. Zohar, l’objectif de l’étude menée par ses collègues et lui-même est de poser des questions pour amener à des évolutions du protocole qui puissent résoudre les problèmes identifiés. Selon lui, dans ce cas précis, il sera à terme possible de répondre aux menaces de ce type, à l’aide modifications des protocoles de routage des paiements (et de meilleurs systèmes de réputation) mais aussi des modifications spontanées probables de la typologie du LN avec le temps (plus de nœuds honnêtes occupant les voies de secours par défaut, si plus de monde déploie de nœuds).