Pendant près de 15 ans, toutes les communications entre les nœuds du réseau Bitcoin ont été transmises entièrement en clair, sans aucun cryptage. Cela a changé en 2024 avec l’adoption du BIP 324, qui a introduit le « v2 » protocole de transport pour la communication entre les nœuds. Ce nouveau protocole propose un cryptage opportuniste, rendant le trafic illisible pour les adversaires passifs capables de surveiller les messages entre les nœuds. Depuis qu’il a été pris en charge dans Bitcoin Core 26.0 et activé par défaut dans 27.0, il est désormais utilisé pour la majorité du trafic Bitcoin P2P mondial.
En prenant du recul, la fonction principale d’un nœud Bitcoin est d’échanger des informations fondamentalement publiques : blocs dans la blockchain, transactions dans le mempool et adresses IP d’autres nœuds Bitcoin. Comme il ne s’agit pas d’informations secrètes, il n’est pas immédiatement évident pourquoi il serait bénéfique de les chiffrer en cours de route. Mais en y regardant de plus près, il y a beaucoup de métadonnées associé au trafic Bitcoin qui mérite d’être protégé. Si un adversaire à grande échelle peut voir quelle transaction est relayée, quand et par quelle adresse IP, il peut en déduire quel nœud était probablement l’initiateur – et donc le créateur – d’une transaction. En plus de cela, l’observation des connexions entre les nœuds eux-mêmes peut révéler à qui appartiennent certains nœuds, permettant ainsi aux nœuds d’entreprises ou de mineurs spécifiques d’être ciblés par des attaques. Et pour certains utilisateurs exécutant des nœuds dans des régimes oppressifs, il peut ne pas être souhaitable de révéler qu’ils exécutent un nœud Bitcoin.
Dans le protocole P2P tel que conçu par Satoshi, les nœuds se connectent les uns aux autres et, via ces connexions, envoient des messages tels que inv. (« J’ai de nouveaux blocs/transactions pour vous »), obtenir des données (« donnez-moi ce bloc/transaction »), adresse (« voici l’adresse IP d’un autre nœud »), et bien d’autres. L’ensemble des messages et des fonctionnalités qu’ils prennent en charge a considérablement changé au fil du temps, notamment la prise en charge des premiers clients SPV avec BIP 37, le relais de blocs compacts avec BIP 152, la prise en charge des adresses Tor v3 avec BIP 155 et des dizaines d’autres. Mais la façon dont ces messages sont codés en octets envoyés sur le réseau – ce que nous appelons le protocole de transport – n’a pratiquement jamais changé depuis 2009. La seule exception à cette règle a été l’introduction de sommes de contrôle dans le protocole en mai 2010. Le BIP 324 a été le premier changement de cette nature depuis lors.
Notez que bien qu’il s’agisse d’un changement assez fondamental par rapport à ce qui peut être décrit comme faisant partie du « protocole Bitcoin », il est entièrement facultatif. Il ne s’agit pas d’un changement consensuel et ne nécessite aucun mécanisme de coordination ou d’activation. Il est simplement utilisé entre des nœuds individuels qui le prennent en charge, mais lorsqu’un nœud prenant en charge le BIP 324 communique avec un autre qui ne le prend pas en charge, ils reviennent à l’ancien protocole de transport (« v1 »). C’est ainsi que, sans grande fanfare, à peine deux ans après la sortie du logiciel client qui l’active par défaut, la majorité des communications entre les nœuds Bitcoin ont abouti à l’aide du protocole de transport crypté v2.
L’idée de chiffrer le trafic Bitcoin n’était pas nouvelle. En 2016, Jonas Schnelli, développeur de Bitcoin Core, a proposé le BIP 151, qui permettrait de mettre à niveau les connexions pour les faire passer en mode crypté. La proposition n’est pas allée loin, et comme cette approche ne pouvait pas cacher la poignée de main initiale entre deux nœuds aux regards indiscrets, le BIP 324 a été proposé en 2019 pour réorganiser entièrement le protocole de transport. Cette approche plus moderne a plutôt introduit une toute nouvelle classe de connexions qui sont cryptées dès le départ. Les progrès se sont accélérés lorsqu’il a été repris par Dhruv Mehta en 2021, et avec Tim Ruffing et moi-même, nous nous sommes transformés en une proposition complète qui comprenait quelques nouvelles fonctionnalités comme un flux d’octets entièrement pseudo-aléatoire, des possibilités de mise en forme du trafic et des extensions facultatives. Nous l’avons annoncé sur la liste de diffusion Bitcoin-dev en 2022 et, après avoir reçu plusieurs commentaires, nous l’avons mis en œuvre au cours de 2022 et 2023. La fonctionnalité complète a été fusionnée dans Bitcoin Core en 2023. Après des tests plus approfondis, elle a été activée par défaut pour toutes les connexions (avec des pairs prenant en charge) en 2024.
La fonctionnalité de flux d’octets entièrement pseudo-aléatoire offerte par le nouveau protocole signifie qu’il ne présente aucun modèle reconnaissable dans les octets envoyés sur le réseau. Par exemple, TLS, utilisé pour la communication avec des sites Web sécurisés (URL « https:// »), crypte le contenu des sites Web, mais pas le fait que TLS est utilisé, ou (jusqu’en 2020 avec Encrypted Client Hello, « ECH ») le nom d’hôte à partir duquel le site a été demandé. Le transport v1 utilisé avant le BIP 324 envoyait 16 premiers octets fixes très reconnaissables sur chaque connexion, ce qui permettait aux pare-feu de censure de bloquer facilement toute connexion avec ce modèle. En revanche, le transport v2 n’a aucun modèle de ce type ; chaque octet est uniformément aléatoire du point de vue d’un tiers, et donc complètement imprévisible. Toute entité qui a l’intention de bloquer le trafic Bitcoin en l’utilisant devrait bloquer tout ce qui semble aléatoire, ce qui pourrait être politiquement plus difficile que de simplement bloquer étroitement le trafic de type Bitcoin. La partie la plus difficile pour rendre l’ensemble du protocole pseudo-aléatoire était le fait que lors de la prise de contact – avant la mise en place du chiffrement – les nœuds devaient échanger des clés publiques, et les clés publiques ne sont pas seulement des octets aléatoires. Ce n’est que grâce à une technique cryptographique assez moderne appelée Elligator (2013), et plus particulièrement à une variante appelée ElligatorSwift (2022) qui permet de coder des clés publiques à courbe elliptique dans des octets d’aspect aléatoire, qu’il a été possible d’éviter même ce modèle.
Il convient de souligner qu’en raison de la nature publique du réseau Bitcoin, il existe des limites importantes aux protections de confidentialité qu’une couche de transport cryptée entre les nœuds peut offrir. Les nœuds Bitcoin ne font pas confiance à leurs pairs et ne se soucient donc pas vraiment de savoir à qui ils parlent. Les nœuds Bitcoin n’ont pas de clés publiques connues, c’est pourquoi le cryptage proposé par le transport v2 est opportuniste et non authentifié ; les deux côtés constituent simplement une nouvelle clé temporaire pour chaque connexion. Cela signifie qu’il est possible pour des adversaires actifs (par exemple, votre FAI) d’effectuer une attaque de l’homme du milieu : parlez v2 aux deux côtés de la connexion, mais décryptez et recryptez toutes les communications circulant entre eux, permettant toujours l’espionnage, et éventuellement la falsification ou la censure ce faisant. Cependant, le fait est que cela est beaucoup plus coûteux à réaliser à grande échelle que la simple inspection de messages individuels non chiffrés comme cela est possible dans le transport v1. Et bien sûr, puisque la plupart des connexions Bitcoin sont établies arbitrairement vers des nœuds aléatoires non fiables, un adversaire qui souhaite espionner à grande échelle d’autres nœuds a toujours la possibilité de simplement créer lui-même un grand nombre de nœuds et de faire en sorte qu’une grande partie du réseau s’y connecte. Comme pour les attaques de l’homme du milieu, cette opération est plus coûteuse à réaliser à grande échelle que la simple inspection des paquets v1.
Le BIP 324 n’est donc pas considéré comme une amélioration de la confidentialité en soi, mais comme faisant partie d’un effort plus large visant à augmenter les coûts de surveillance à grande échelle du réseau Bitcoin, sans s’appuyer sur des réseaux alternatifs comme Tor ou I2P, qui ont leurs propres compromis comme une latence accrue et un risque de déni de service qui ne seraient pas acceptables pour tous les nœuds du réseau. Le BIP 324 offre également un certain nombre de fonctionnalités qui ne sont pas encore implémentées, comme la mise en forme du trafic pour éviter de révéler des informations sur les transactions relayées simplement en observant la taille des paquets cryptés. Espérons que ceux-ci seront davantage exploités dans les années à venir.
Ne manquez pas votre chance de posséder La question centrale — présentant des articles rédigés par de nombreux développeurs principaux expliquant les projets sur lesquels ils travaillent eux-mêmes !
Cet article est la lettre de l’éditeur présentée dans la dernière édition imprimée du magazine Bitcoin, The Core Issue. Nous le partageons ici comme un premier aperçu des idées explorées tout au long du numéro complet.