La décentralisation dans les blockchains

Quel lien entre décentralisation et sécurité ?

Vitalik Buterin (fondateur de l’Ethereum) a développé le concept de triangle d’incompatibilité de la blockchain. Ce dernier stipule qu’il n’est pas possible d’optimiser en même temps ces 3 principes : sécurité, scalabilité et décentralisation. Sur commission de la DARPA, une agence de recherche rattachée au département de la défense des Etats-Unis, une étude approfondit la corrélation entre sécurité et décentralisation.

Node, décentralisation et sécurité

La décentralisation est au cœur des blockchains. Cette décentralisation à la fois dans les échanges d’informations mais aussi dans le stockage de l’information et du réseau fait de cette technologie une des plus sécurisée qui soit. En effet, les blockchains sont réputées être inviolables ; elles reposent sur chacun des membres composant le réseau : « les nodes ». Ces éléments constituant le réseau assurent l’enregistrement des échanges et chacun héberge soit partiellement, soit de façon exhaustive les données de la blockchain.

Le fait que la blockchain repose sur le fonctionnement simultané d’autant d’entités différentes caractérise justement sa sécurité : pour corrompre le réseau et porter atteinte à son intégrité, il faut être capable de s’emparer d’un certain pourcentage de force de calcul (ce chiffre diffère selon le mécanisme opérant la blockchain). Toutefois, dans l’étude faite par Trail of Bits, plusieurs facteurs pouvant potentiellement compromettre l’intégrité des blockchains ont été mis en exergue, et sont autant de points d’attention pour qui souhaite mettre en place une telle technologie.

Quelles menaces peuvent alors menacer une blockchain ?

Une blockchain peut présenter des vulnérabilités qui faciliteraient les opérations dites « attaque des 51% » : dénomination d’une attaque consistant à prendre le contrôle d’un pourcentage critique des nodes opérant la blockchain. Le pourcentage précédemment mentionné est uniquement valable pour des mécanismes de Proof of Work, comme le Bitcoin. L’Ethereum qui devrait passer prochainement en septembre 2022 au Proof of Stake serait également sensible à une affluence extérieure pouvant paralyser le processus de validation.

L’étude de Trails of Bits a exposé plusieurs vulnérabilités pouvant porter atteinte à la décentralisation d’une blockchain. Si le réseau a une tendance à être plus centralisé, alors il s’expose à un risque plus grand. L’objectif est de porter une attention particulière à la distribution du réseau (ou pour ainsi dire des nodes), et aux externalités pouvant l’affecter.

Le coefficient de Nakamoto : un seuil critique

Le premier facteur à prendre en compte est le coefficient de Nakamoto : le coefficient de Nakamoto caractérise le nombre le plus petit de nodes pour une blockchain donnée, qu’il faut corrompre pour porter atteinte à l’intégrité du réseau dans sa globalité. Pour expliciter ce point, il suffit de prendre le cas du Bitcoin : les nodes sont récompensées en crypto-monnaie (Bitcoin) pour leur contribution à la blockchain, cependant ces récompenses sont divisées par deux tous les quatre ans, c’est ce qu’on appelle le Halving.

Aussi pour continuer à maintenir leurs profits, les nodes de minages se sont regroupées; il est ainsi possible d’augmenter la puissance de calcul en partageant les coûts. Ces groupes, appelés mining pool, opèrent sur leur propre protocole et interagissent avec le réseau Bitcoin via une seule node. Leur popularité est telle que les quatre plus grands groupes contribuent pour plus de 51% de la puissance de calcul. Ainsi, le nombre d’entités nécessaire pour opérer une attaque des 51% est de quatre, nous retrouvons donc le coefficient de Nakamoto. Plus ce nombre est élevé, plus l’effort pour corrompre le réseau est important et inversement ; plus le nombre est faible, plus le réseau est vulnérable.

Quelle solution pour lutter contre la centralisation induite par le Halving et la recherche de profit ?

Une des propositions pour parer à ce phénomène serait d’instaurer un coût de Sybil: le coût d’opération de plusieurs nodes par une unique personne serait plus grand que pour un individu opérant une seule node. Cela inciterait les agents du réseau à n’entretenir plus qu’une seule node, divisant ainsi la puissance de calcul plus efficacement. À ce jour, il n’a été trouvé aucun moyen d’implémenter cette solution.

Un risque de centralisation multi-factoriel :

Au-delà de la centralisation des nodes induites par le Halving au travers des mining pool, il faut considérer plusieurs autres facteurs externes de centralisation impactant négativement la sécurité.

La répartition des nodes est un enjeu majeur : que ce soit géographiquement, au niveau d’un FAI (Fournisseur d’Accès à Internet), ou même à l’échelle d’un service cloud pour opérer les nodes. Pour reprendre l’exemple précédent, beaucoup de nodes opèrent depuis le cloud : on estime qu’une partie non négligeable des nodes opèrent sur quatre acteurs du cloud (OVH, AWS, Hetzner et Digital Ocean).

Ainsi, la vulnérabilité du réseau dépend aussi des vulnérabilités de ses prestataires. Pour les FAI, il faut s’attacher à la répartition géographique : ces derniers étant liés aux états, si un gouvernement est hostile au développement d’une blockchain et que la majorité des nodes de cette dernière opèrent sur son territoire, alors il y a un fort risque que le réseau soit atteint. Notons par ailleurs que ce sont approximativement 60% du trafic du réseau Bitcoin qui transitent au travers de seulement trois FAI.

Si nous regardons à présent les interfaces utilisées, toujours au travers du prisme des prestataires : il semblerait que près de la moitié des nodes sont connectées au client BitcoinCore via le navigateur Tor. Bien que cela permette de sécuriser et de privatiser la connexion, il n’en reste pas moins qu’avec une telle proportion, le réseau Bitcoin dépend fortement de Tor. Or s’il advenait que le service subisse une défaillance quelconque, c’est tout le réseau Bitcoin qui en pâtirait.

Enfin, un autre enjeu porte sur la version du logiciel de blockchain utilisé. En effet, selon l’étude menée par Trails of Bits, des nodes collaborant sur une même blockchain mais fonctionnant avec des versions différentes du logiciel peuvent provoquer des erreurs de consensus. Or, le danger d’une erreur de consensus réside dans le fait qu’elle puisse provoquer à son tour un incident autrement plus conséquent : un fort.

Si des divergences de version dans les logiciels peuvent créer des divergences de consensus entre les valideurs d’une Blockchain, il faut également comprendre que tout changement induit dans la version du logiciel peut également provoquer ce type d’incident. La centralisation concerne directement les développeurs du logiciel, si un développeur se trouve compromis d’une façon ou d’une autre, alors il n’est pas exclu que des modifications arbitraires soient implémentées dans le code source.

De la sécurité des Systèmes d'Information

Les blockchains restent des technologies prometteuses. Cependant, cette étude met en valeur des comportements adverses qui peuvent nuire à la sécurité de cette technologie. Bien qu’il existe de plus en plus de propositions différentes pour opérer une blockchain (proof of History, proof of Authority…), les conclusions de l’étude mettent en valeur des principes de précaution non négligeables.

Ces derniers sont non seulement valables pour cette technologie, mais relèvent également du bon sens à l’échelle de la sécurité des systèmes d’information plus globalement. Cette relation est une autre façon de dévoiler de nouvelles opportunités d’amélioration en termes de gouvernance, en prenant des failles bien connues au regard de la sécurité des Systèmes d’Information, qui seraient tout aussi pertinentes au regard d’une blockchain : vulnérabilités des développeurs des solutions, du langage utilisé et de ses évolutions…