Les bénéfices de la blockchain peuvent ils s’appliquer à la cybersécurité ? En quoi la Blockchain peut-elle apporter des solutions pour sécuriser tout ou partie de nos systèmes d’information ? Et ces solutions blockchain : sont-elles elles-mêmes sécurisées et exemptes de toute vulnérabilité ?

1. Les apports de la Blockchain à la Cybersécurité

La Blockchain a bien plus à offrir que le simple transfert d’argent. Les bénéfices de cette technologie sont avérés (Désintermédiation, Traçabilité, Certification, …), et l’adoption de cette technologie est aujourd’hui incontestable, tant les cas d’usages métier sont nombreux.

La Blockchain a initialement été créée pour transférer de l’argent de manière décentralisée, sans intermédiaire, tout en maintenant la confiance historiquement opérée par les banques. Derrière ce cas d’usage, et tous ceux qui ont découlé dans la décennie qui a suivi, se cachent des concepts techniques dont on pressent les affinités avec le monde de la cybersécurité. En quoi la Blockchain peut être un nouvel outil pour sécuriser nos systèmes d’informations ?

Les critères de sensibilité de l’information communément admis sont regroupés sus la triade CIA : Confidentiality, Integrity, Availability (Disponibilité, Intégrité et Confidentialité) :

Confidentialité : Garantir que l’information est protégée et accessible sur autorisation explicite uniquement.

La Blockchain, qu’elle soit publique ou privée, est pensée comme une architecture ouverte et s’appuie sur les protocoles de partage Pair-à-pair (P2P). Les transactions effectuées sont publiques afin de pouvoir être vérifiées par le consensus. En revanche, la capacité d’initier une nouvelle transaction reste restreinte au seul propriétaire du portefeuille. Cette gestion des accès repose sur des algorithmes de chiffrement asymétriques éprouvés (clés publiques / clés privées) garantissant un haut niveau de confidentialité.

Afin d’assurer une restriction d’accès aux données qui doivent rester confidentielles, le plus simple reste d’implémenter une Blockchain privée (accès privé) ou hybride (accès permissionné sur une Blockchain publique), sur lesquelles on pourra constituer des groupes de données et des groupes d’utilisateurs, puis implémenter des droits d’accès à l’information sur un modèle de « Contrôle d’Accès Basé sur les Rôles » (RBAC).

Cette gestion des accès n’est pas native sur les Blockchains publiques : on peut par exemple l’implémenter via des protocoles supplémentaires de type « Preuve à divulgation nulle de connaissance » (ZKP), ou bien via l’utilisation de frameworks dédiés comme Pantheon (Ethereum) ou BESU (Hyperledger).

Intégrité : Garantir que l’information est fiable, qu’elle n’a pas été falsifiée par malveillance ou corrompue par défaut d’implémentation.

Par définition, la Blockchain confère aux données un caractère immuable : toute transaction effectuée dans une Blockchain est stockée de manière irréversible. Il n’est plus possible de supprimer cette information. Elle peut être amendée a posteriori, mais on conservera toujours l’historique et la trace de la modification.

Le consensus de la Blockchain garantit que toute tentative de modification a posteriori serait immédiatement repérée dans le reste de la chaîne et, de fait, invalidée par l’ensemble des acteurs de la Blockchain.

Cette intégrité est fondée sur les signatures numériques des fonctions de hachage, est réputée inaltérable, et garantit une intégrité absolue de la donnée.

🛠 Fonctions de Hash

Le hachage est une empreinte numérique à sens unique, une signature unique qui ne peut être ni prédite ni forgée.

Une information stockée dans une Blockchain est certifiée par son hash. Si un acteur malveillant voulait modifier cette information, il devrait s’assurer que le nouveau bloc (modifié) ait exactement le même hash, ce qui est statistiquement impossible puisque cette signature ne peut être prédite.

Impossible de changer « Alice donne 1 Bitcoin à Bob » en « Alice donne 3 Bitcoin à Bob », car on ne saurait pas comment retrouver le hash d’origine, même s’il existe.

Ces fonctions de hachage sont présentes partout dans les Blockchains : elles sont justement la chaîne qui lie les blocs entre eux et les transactions entre elles. Pour minimiser la taille des signatures stockées, on effectue même des hash de hash de hash… dans ce que l’on appelle un « Arbre de Merkle », qui permet de ne stocker que le hash de l’ensemble :

Disponibilité : Garantir un accès fiable aux données, à n’importe quel moment, quel que soit l’état du réseau.

La Blockchain est un réseau décentralisé de nœuds connectés entre eux en maillage, sur la base du modèle pair-à-pair (P2P), où chaque acteur de la Blockchain héberge, reçoit et envoie toute ou partie des données à ses pairs. L’absence de centralisation ou de point névralgique garantit que le réseau fonctionne même si une partie est indisponible ou isolée.

La robustesse de ce réseau garantit l’accès aux données, leur pérennité, mais aussi une protection face aux pannes et aux attaques de Déni de Service Distribué (DDoS).

En résumé, les données stockées sur une Blockchain sont hautement disponibles.

Traçabilité : Garantir l’imputabilité et l’auditabilité de l’information sur la base de preuves formelles.

Un quatrième critère est très souvent adjoint au triptyque CIA : la Traçabilité.

La traçabilité est un des piliers fondamentaux de la Blockchain : toute donnée peut et doit être tracée pour être validée selon les règles du consensus. Chaque transaction peut être suivie, et son historique retracé afin de reconstituer l’état d’un compte, de n’importe quelle donnée.

Transposée aux cas d’usages métiers, cette traçabilité garantit la validité de tout actif d’entreprise présent sur une Blockchain : données produits, clients, process.

Quid de l’anonymat ?

Si tous les échanges et données sont tracés et accessibles à l’ensemble des acteurs de la Blockchain, comment garantir l’anonymat ou la confidentialité de certaines données qui le nécessitent ?

Tout d’abord, il convient de rappeler que l’anonymat conféré par les Blockchains reste tout relatif. Certes, les acteurs sont anonymisés derrière des numéros de portefeuilles, mais il s’agit de pseudonymat plutôt que d’anonymat puisque qu’il est possible de remonter à la source des émetteurs / bénéficiaires d’une transaction comme on sait le faire avec des adresses IP, par exemple en reconstituant des regroupements et des schémas relationnels de comptes. (Ex : investigations criminelles et Lutte Contre le Blanchiment d’argent par Elliptic).

Si l’anonymat doit être un prérequis pour un cas d’usage, il peut être aisément implémenté dans le cadre d’une Blockchain privée. En revanche, dans le cas d’une Blockchain publique, le sujet devra être adressé dès la conception :

• Certaines Blockchain publiques sont dédiées à l’anonymisation des transactions (Ex : Monero). Elles fournissent un anonymat extrême : les informations des transactions sont quasiment toutes inaccessibles sauf par l’expéditeur et le bénéficiaire. Cependant, leur réputation reste probablement trop équivoque pour les considérer dans le cadre d’une application industrielle.
• Outre les techniques de mixage et d’obfuscation qui consistent à noyer les transactions parmi d’autres (Ex : protocole PrivateSend de la blockchain DASH), il est possible de concevoir des solutions de type “Blockchain Layer 2” : une surcouche aux Blockchains publiques permettant de stocker dans la chaîne, non pas une donnée, mais son empreinte numérique (hash). La donnée reste elle stockée hors-blockchain, dans une base de données classique (Ex : Woleet).
• Il existe aussi des protocoles de chiffrement “Zero Knowledge Proof” fournissant des preuves à divulgation nulle de connaissance (ZKP) : les données stockées sur la Blockchain ne sont pas accessibles, et pourtant l’utilisateur peut fournir la preuve que cette donnée existe, qu’elle lui appartient, et peut choisir de ne pas divulguer les adresses de transactions (Ex : Zcash et son double système d’adresses transparentes & publiques vs. anonymes et masquées)

Autres apports à la cybersécurité

Outre ces bénéfices fondamentaux en matière de cybersécurité, la Blockchain apporte de nombreuses autres solutions spécifiques :

Lutte contre la fraude

Toute transaction au sein d’une Blockchain nécessite d’être validée par le réseau en suivant les règles du consensus, avant d’être formellement intégrée. La difficulté de validation du protocole peut être ajustée en fonction de la sécurisation que l’on souhaite garantir à la donnée. Un comportement malveillant qui ne suivrait pas les règles du consensus peut tout à fait être identifié comme tel, intercepté, et ne pas être diffusé au reste du réseau.

Les Blockchain publiques proposent des protocoles de validation souvent longs et complexes (Ex : une transaction sur Bitcoin n’est formellement validée qu’après plusieurs blocs, soit environ une heure), alors qu’une Blockchain privée entre acteurs de confiance peut se permettre d’abaisser ce niveau de complexité, au profit de la vitesse de validation (Ex : consensus PBFT)

Quel que soit le protocole adopté, les transactions stockées sur une Blockchain bénéficient donc de la validation du protocole, et donc d’une certification implicite favorable à la lutte contre la fraude.

Infrastructure de clés décentralisée (DPKI)

En cybersécurité, le chiffrement des données repose sur des clés. Le stockage de ces clés est un point crucial qui est historiquement adressé par des autorités centrales, organismes de confiance qui garantissent le stockage et la distribution des clés et des certificats : les PKI (Private Keys Infrastructures)

Le caractère centralisé de ces organismes crée une dépendance à des intermédiaires privés ou étatiques que l’on ne choisit pas toujours et qui imposent leur confiance au reste du réseau.

Cette centralisation présente par ailleurs un cas d’école pour les attaques de type Man in the Middle (MitM) : ARP Spoofing, IP Spoofing, DNS Spoofing, HTTPS Spoofing sont autant de méthodes exploitables pour se faire passer pour une Autorité Certifiante et délivrer des clés ou certificats corrompus (Ex : attaques sur DigiNotar).

Ce point unique de défaillance (SPOF) peut être adressé par une approche alternative décentralisée : Les Decentralized Public Key Infrastructure (DPKI). Les clés sont alors stockées dans une Blockchain décentralisée qui résout le point unique de défaillance des schémas centralisés des PKI traditionnels. La Blockchain confère une haute disponibilité de ces clés et certificats, et par ailleurs offre plus de sécurité face aux attaques de MitM.

Identity & Access Management

L’IAM est un des piliers de la cybersécurité. Les outils et solutions de l’IAM (Active Directory, Single Sign On, Revues d’accès, etc.) reposent sur des architectures centralisées qui exposent de fait un Point Unique de Défaillance.

Ce modèle est vulnérable aux attaques d’interception et manipulation des données de type MitM. On voit aussi apparaître une certaine défiance des utilisateurs à céder leurs informations personnelles à des organismes centraux (solutions privées) ou fédérés (Google, Facebook).

Des alternatives décentralisées apparaissent afin de résoudre ces vulnérabilités et défiances : L’identité Souveraine Décentralisée (Self Sovereign Identity), portée par une Blockchain, où l’utilisateur reste le seul propriétaire de ses identités numériques et accorde ou révoque les droits d’accès à ses informations à sa guise (ex : Hyperledger INDY / Sovrin).

Vote Numérique

Le vote numérique est un des cas d’usage idéal pour la Blockchain : chaque personne peut voter individuellement via une application et grâce à sa clé privée, sans avoir à transiter par un organisme central, sans avoir à se déplacer.

La confiance est garantie par un Smart Contract automatisé qui assure l’unicité des votes, puis comptabilise automatiquement les résultats, sans intervention ni validation d’un organisme tiers. La blockchain confère la confidentialité du vote, la sécurité et la transparence des résultats. (ex : Le Vote, service de Orange)

La Blockchain est donc un outil supplémentaire à notre attirail en matière de cybersécurité. Mais cet outil est-il lui-même exempt de failles ? Bien que sécurisée par construction, la Blockchain présente-t-elle des vulnérabilités connues ? Sont-elles adressées ?

2. La Blockchain face a ses propres enjeux de sécurité

Les Blockchains sont avant tout des architectures techniques possédant leurs propres infrastructures, protocoles, et applications. Elles se projettent de fait sur l’ensemble du modèle OSI, dont chacune des couches est exposée aux éventuelles attaques.

Si les Blockchains savent résister aux cyber attaques traditionnelles, le monde du hacking a naturellement su élaborer de toutes pièces des attaques spécifiques aux Blockchains :

Vulnérabilités du réseau

Les Blockchain reposent sur des infrastructures distribuées (P2P) garantissant en théorie une réplication et une validation de l’information. En pratique, un réseau distribué n’offre pas une réplication parfaite (cf. théorème CAP) et chaque nœud d’une Blockchain n’est connecté qu’à un nombre limité de ses pairs : 9 nœuds pour le réseau Bitcoin et 13 pour Ethereum par exemple. Ainsi, il est possible d’opérer des attaques niveau réseau sur des Blockchains :

Attaque par Déni De Service (DOS)

L’attaquant perturbe le réseau en inondant les nœuds du réseau avec des nombreuses transactions de faible valeur. Cette saturation d’information peut faire tomber un nœud et le sortir du réseau, au profit d’autres nœuds contrôlés par l’attaquant.
La Blockchain Bitcoin a été victime d’une telle attaque en Septembre 2018. Cf. CVE-2018–17144

Attaque Sybil

L’attaquant prend le contrôle de plusieurs nœuds du réseau, entourant la victime de nœuds malveillants et l’isolant du reste du réseau. Les nœuds corrompus minent et valident ce qu’ils veulent et orientent la Blockchain dans le sens de l’attaquant, permettant par exemple des attaques de type double dépense.

Attaque Eclipse

L’attaquant modifie les informations de connections sortantes du nœud de la victime, forçant ses requêtes à être adressées à des adresses IP qu’il contrôle. Ce « node spoofing » permet d’isoler la cible et de ne lui envoyer que les informations de son choix : double dépense, fausses transactions.

Vulnérabilités des Protocoles

La valeur ajoutée des Blockchains repose principalement sur leurs protocoles. Ces derniers sont bien souvent disponibles en open source, et les contributions sont nombreuses pour répondre à la frénésie de l’innovation. Encore peu éprouvés, ces protocoles s’exposent parfois à des vulnérabilités de type « zero day ».

Faille d’implémentation

Le 15 août 2010, la Blockchain du Bitcoin a été victime d’une faille dans l’implémentation de son protocole : une vulnérabilité de type « value overflow » a permis de créer 184 milliards de Bitcoins à partir de rien (la limite totale de Bitcoins étant de 21 millions…). Le code ne vérifiait pas que des montants trop importants pouvaient dépasser la limite, devenir négatifs et ainsi être validés.
L’incident a été corrigé et la transaction annulée. Cf. CVE-2010–5139

Forge de monnaie à partir de rien

Dans l’exemple précédent, il a été facile de repérer l’incident, de corriger le code, et d’annuler la transaction en revenant sur le bloc fautif. En revanche, quand ce type de malveillance arrive sur des cryptomonnaies à fort anonymat (Monero, Zcash), il est très difficile de prouver que de la monnaie a été créée (minée ou reçue) légitimement et non à partir de rien (« from thin air ») puisque par définition, ces protocoles offrent peu de traçabilité publique.

Collision de Hash

Comme vu précédemment, les Blockchains s’appuient fortement sur les fonctions de hash pour garantir l’intégrité et l’inaltérabilité des données de transactions.
Nous avons vu que les fonctions de hash généraient une signature unique… Mais en réalité pas totalement. Des collisions peuvent survenir, c’est-à-dire que 2 données différentes pourraient avoir le même hash :

En pratique, les algorithmes de hash garantissent que ces collisions sont très peu probables (inférieures à une chance sur 10⁶⁶). En théorie, cela reste possible, et on pourrait imaginer le scénario suivant :

1. L’attaquant altère une donnée de Blockchain dans le passé (modification d’une transaction)
2. L’attaquant trouve une collision de hash qui permet au bloc de conserver son hash initial malgré sa modification.
3. Le bloc conserve sa signature et ne brise pas en cascade la chaîne de hash des blocs suivants.
4. L’altération est implicitement validée par l’ensemble du réseau puisque ce bloc a déjà été validé dans le passé.

💡 Il convient donc d’utiliser des fonctions de hash reconnues et éprouvées (ex : SHA256) et surtout de ne pas tenter de réinventer sa propre fonction, comme a voulu le faire la Blockchain IOTA, leur fonction de Hash s’étant avérée beaucoup trop sensible aux collisions.

Exploitation du Consensus

Une des vulnérabilités les plus connues de la Blockchain repose sur le consensus le plus utilisé : la preuve de travail (Proof Of Work). Dans ce protocole, le mineur qui créera le prochain bloc est déterminé au hasard, au prorata de la puissance de calcul qu’il met à contribution pour le réseau. Un mineur qui possède 1% de la puissance de calcul totale du réseau a donc 1% de chance de miner le prochain bloc.
Ainsi, un attaquant qui possèderait 51%, c’est-à-dire plus de la moitié de la puissance de calcul pourrait valider les transactions de son choix et opérer une attaque de « double dépense » :

1. L’attaquant prétend donner un certain montant à sa cible, et récupère la contrepartie en échange.
   « 👴Charlie donne 5 BTC à 👱‍♀️Alice » (et récupère des Euros en échange par exemple)
2. Il effectue en parallèle une autre transaction dans laquelle il renvoie le même montant à un complice.
   « 👴Charlie donne 5 BTC à 🧔Bob »
3. L’attaquant manipule la Blockchain et grâce à ses 51%, l’oriente à sa guise de manière à invalider la 1ère transaction « 👴Charlie donne 5 BTC à 👱‍♀️Alice » au profit de la seconde « Charlie donne 5 BTC à 🧔Bob »
4. Alice réalise — trop tard — que la transaction « Charlie donne 5 BTC à 👱‍♀️Alice » n’est plus valide. Elle a perdu sa contrepartie.

Plusieurs Blockchains ont déjà été victimes d’attaques de ce type :

• Avril 2018 : Verge (24O K$ détournés)
• Mai 2018 : BTC Gold (18 M$ détournés)
• Juin 2018 : ZenCash (600 K$ détournés)

💡 Une des solutions consiste à adopter un autre consensus moins sensible aux attaques de ce type (ex : Proof of Stake) ou un consensus privé (ex : Ripple). Gardons à l’esprit que cette attaque n’est envisageable que pour une Blockchain peu minée pour laquelle acquérir 51% serait envisageable, ce qui n’est pas le cas du Bitcoin, qui, par construction et par son adoption, en fait une Blockchain très résiliente.

Vulnérabilités des Applications

Même si les fondations des protocoles de Blockchain sont sécurisées et verrouillées, ces dernières mettent à disposition des interfaces d’instanciations et d’interactions qui multiplient les surfaces d’attaques. C’est tout particulièrement le cas avec les Blockchains proposant des interfaces de programmation : les fameux Smart Contracts.

Cette couche applicative crée une dimension supplémentaire de vulnérabilités qui ont depuis longtemps été exploitées. On ne compte plus les attaques sur les plateformes, les marchés, et plus globalement les services tierces s’appuyant sur des Blockchains :

DAO

DAO était une Organisation Autonome Décentralisée lancée sur la Blockchain Ethereum en 2016, proposant un modèle d’entreprise décentralisé, sans structure de gestion ni conseil d’administration. Le concept était novateur et son financement participatif a levé l’équivalent de 120 millions de $.

Mais l’aventure a tourné court lorsque le service s’est fait hacker et voler un tiers de ses fonds quelques semaines plus tard. (60 millions de $)

La vulnérabilité exploitée était applicative : une faille dans le code permettait un appel récursif à une fonction de retrait de fonds, qui opérait le transfert du montant avant de mettre à jour la balance des comptes.

Il est intéressant de noter que ce Hack a été corrigé puis résolu par la manière forte : Afin de récupérer les fonds volés, la communauté Ethereum a choisi de revenir dans le temps et de reprendre la Blockchain avant l’exploitation de la vulnérabilité, via un « hard fork » qui a donné naissance à « Ethereum Classic »

Mt. Gox

La plateforme d’échange Mt. Gox a subi en 2014 une attaque menant à sa faillite. La vulnérabilité était fondée sur la « malléabilité de transactions » de la Blockchain Bitcoin, permettant à un attaquant de changer l’identifiant d’une transaction avant sa confirmation. L’attaquant, qui avait pu récupérer une clé privée du wallet central a pu forger une signature valide et prétendre être le bénéficiaire de transactions avant même leur validation dans un bloc.

On estime que 450 millions de $ ont ainsi été détournés.

Parity

Parity est un portefeuille dédié à la blockchain Ethereum. Cette surcouche propose des services comme la gestion « MultiSgnature » des portefeuilles Ethereum, permettant d’assigner plusieurs clés d’accès à un même portefeuille.

En juillet 2017, le portefeuille Parity a été hacké. La vulnérabilité applicative venait du code du Smart Contract qui était hérité (importation d’une bibliothèque externe) dans l’implémentation de Parity. La fonction « constructeur » du portefeuille pouvait être appelée à nouveau après son instanciation et permettait à l’attaquant de devenir le propriétaire du portefeuille. Une fois propriétaire, rien de plus simple que d’en vider le contenu.

Notons qu’un groupe de White Hackers (hackers éthiques), a rapidement identifié puis exploité cette même faille pour hacker les portefeuilles encore vulnérables et mettre sous verrou les fonds restants.

On estime que 32 millions de $ ont ainsi été détournés.

Ces exploits restent malheureusement assez fréquents et leur impact souvent coûteux. Gardons à l’esprit que ces vulnérabilités peuvent survenir chez les meilleurs, tant les environnements de développement des Blockchain sont encore complexes et les technos encore peu matures.

💡 Quelques bonnes pratiques pour éviter ce type de vulnérabilités applicatives :

• Utiliser les standards ERC des Smart Contracts, qui sont audités, éprouvés, et éviteront une majorité du rework et de générer de nouvelles failles.
• Utiliser les dernières versions du compilateur de Solidity qui alertent sur les failles connues.
• Vérifier le code source des Smart Contracts utilisés ou hérités (avec Etherscan par exemple)
• Utiliser des compilateurs à Preuve Formelle qui garantissent la sortie attendue du Smart Contract (ex : langage OCaml, ou le Michelson de TEZOS)

Vulnérabilités des utilisateurs

Sur une Blockchain, les utilisateurs doivent conserver précieusement les clés privées qui leur permettent d’accéder à leur portefeuille.
Ces clés sont doublement précieuses :

1. Elles sont le seul moyen d’accéder à son portefeuille et de dépenser ses cryptomonnaies. Un attaquant qui récupère la clé privée peut utiliser (et vider) le portefeuille sans autre contrainte.
2. Elles ne peuvent pas être récupérées en cas de vol ou de perte. Contrairement à un mot de passe qui peut être réinitialisé, les clés privées sont uniques et non récupérables.

Ownership

La majorité des vols de cryptomonnaies sont imputables à des vols de clés privées. L’utilisateur étant totalement responsable de ses clés (True ownership), il en est le seul gestionnaire, et offre par conséquent un angle d’attaque idéal : Cette somme d’utilisateurs individuels représente une surface d’attaque étendue pour les attaquants, et la majorité des utilisateurs n’ont pas les compétences nécessaires en matière de cybersécurité pour sécuriser correctement l’accès à leurs clés.

💡 La conservation des clés n’est pas triviale et si les portefeuilles électroniques sont une bonne solution, il s’agit de bien les choisir afin de minimiser les risques :

Portefeuilles corrompus

De nombreux portefeuilles sont disponibles sous forme d’applications pour smartphones. Il a été révélé que certains d’entre eux, directement développés par des attaquants, envoient les clés ou siphonnent les comptes des victimes.

Ex : les applications « Trezor Mobile Wallet » et « Coin Wallet » qui transmettent les logins et mots de passes de la victime sur le site de l’attaquant :

Et plus récemment, GetMonero, le wallet de Monero a été piraté en novembre 2019 : la version malveillante interceptait les codes du portefeuille et les envoyait à l’attaquant.

💡 Il vaut mieux privilégier les portefeuilles physiques (hardware wallets) contenant un Secure Element qui stockent la clé et valident les transactions par confirmation physique (ex : Ledger)

Portefeuilles légers

Certains portefeuilles applicatifs, non malveillants par essence, n’utilisent pas les protocoles les plus sécurisés et s’exposent ainsi à des exploitations de failles de protocole — Blockchain ou plus classiquement HTTP.

Par exemple, les portefeuilles légers comme Mycelium ou Electrum, afin de d’optimiser le poids de l’application et le temps de validation, n’utilisent pas le protocole Bitcoin complet mais s’appuient sur un protocole léger de vérification des transactions : le « simple payment verification » (SPV). Ce dernier ne télécharge pas l’ensemble de la Blockchain mais uniquement les entêtes de blocks et demande la validation à des nœuds aléatoires.

De fait, la confiance dans nœuds n’est pas certifiée : une attaque de type « Man in the Middle » (MitM) peut bloquer ou valider certaines transactions, voire modifier les montants en manipulant les méthodes HTTP.

💡 Les protections sont plus complexes à mettre en place dans ce cas de figure. S’il semble difficile de se connecter à son propre nœud Blockchain, on peut toujours se connecter en VPN, ou a minima éviter l’envoi de transactions via les Wi-Fi publics pour éviter les attaques MitM.

Vulnérabilités structurelles

Certaines Blockchains présentent par ailleurs des vulnérabilités structurelles, dont on a souvent dit qu’elles mèneraient à leur perte à long terme :

Recentralisation

Si l’on regarde la répartition de la puissance de calcul (hashrate) de la Blockchain Bitcoin, on constate qu’une grande majorité est aujourd’hui localisée en Chine :

La Blockchain n’a pas été conçue ni prévue pour une telle recentralisation, qu’elle soit géographique ou économique. Outre les attaques à 51% qui pourraient être opérées via de tels regroupements, toute manipulation de la Blockchain serait à craindre dans l’absolu.

Les mineurs chinois ont un accès facilité à de l’énergie à bas prix, et le consensus (Proof of Work) devient hackable pour qui a les moyens de produire du hashrate. Idéalement, un consensus non contrôlable devrait reposer sur quelque chose qui ne peut pas s’acheter.

Gouvernance

La Blockchain est décentralisée par définition. Cela sous-entend une absence structurelle de gouvernance, qui a déjà causé son lot de dégâts dans le milieu des cryptomonnaies. Sans gouvernance, difficile de prendre des décisions ou d’imposer à la communauté des contraintes, qui pourraient pourtant s’avérer nécessaires vis-à-vis de la sécurité et/ou de la régulation.

Les Forks de Blockchain sont donc légion, que ce soit pour imposer une nouvelle fonctionnalité (Bitcoin Cash, Bitcoin Gold, Segwit, etc.) ou pour corriger une vulnérabilité et annuler les effets d’une attaque (Ethereum Classic).

De nouvelles Blockchains adressent ce problème, en proposant une gouvernance inscrite par construction dans l’algorithme. C’est le cas de la Blockchain française TEZOS, qui est auto-régulée par ses utilisateurs : les évolutions sont votées par la communauté, les développeurs soumettent des propositions pour faire évoluer le protocole, chaque proposition est testée, votée, puis implémentée de manière décentralisée.

Cet auto-amendement permet à la blockchain TEZOS d’éviter les forks et la division de la communauté.

En conclusion

La plupart de ces critiques sont légitimes mais concernent souvent les Blockchains les plus anciennes — et aussi les plus populaires par conséquent. Ethereum aura bientôt 5 ans et le Bitcoin en a passé le cap des 10 ans… autant dire une éternité dans le monde de l’innovation galopante des systèmes d’informations.

Aujourd’hui, de nouvelles Blockchains adressent aisément ces failles structurelles par de nouveaux consensus, de nouveaux protocoles, de nouveaux types de gouvernance. Sans parler des Blockchains privées qui couvrent encore la majorité des applications Blockchain industrielles et qui, par définition, adoptent les protocoles et consensus qui leur conviennent le mieux afin de garantir toutes ces contraintes de sécurité, régulation et gouvernance, quitte à s’éloigner des fondamentaux activistes de la Blockchain tel que Satoshi Nakamoto les avait originellement pensés.