Dans cet article, nous allons explorer la mauvaise gestion des privilèges des utilisateurs dans le contexte de la blockchain Ethereum. En décryptant les mécanismes de sécurité et les vulnérabilités des comptes et des transactions, nous mettrons en lumière l’importance de la gestion adéquate des privilèges pour garantir l’intégrité et la sécurité du réseau Ethereum.
Les opérations de base sur la Blockchain
La blockchain est un réseau décentralisé Peer-to-Peer avec deux principaux types de nœuds participatifs.
D’une part, les participants qui initient le transfert de valeur en créant une transaction et d’autre part, les participants appelés mineurs. Les mineurs effectuent un travail ou des calculs supplémentaires pour vérifier les transactions, diffuser une transaction.
Ils se concurrencent pour revendiquer le droit de création d’un nouveau bloc et réalisent un consensus pour valider un bloc. Les mineurs assurent aussi la diffusion du bloc nouvellement créé et la confirmation des transactions. Ils sont encouragés par les bitcoins récompensés pour gérer la blockchain.
Validation d’une transaction
La validation de la transaction est effectuée indépendamment par tous les mineurs. Le processus dans bitcoin implique la validation de plus de 20 critères dont :
- La taille,
- la syntaxe,
- les références de l’UTXO d’entrée et de sortie ;
- La validité des UTXO ;
- Les références du montant en entrée et du montant en sortie sont suffisamment appariées.
Les transactions non valides sont rejetées et ne seront pas diffusées. Toutes les transactions valides sont ajoutées à un pool de transactions. Les mineurs sélectionnent un ensemble de transactions dans ce pool pour créer un bloc. La transaction zéro (l’index zéro du bloc confirmé) est créée par le mineur du bloc. Il a un UTXO spécial et n’a pas d’entrée UTXO. C’est ce qu’on appelle la transaction « coinbase » qui génère les honoraires d’un mineur pour la création du bloc.
Création d’un nouveau bloc (minage)
La blockchain est une chaîne de flux liée unique et cohérente. Cependant, si chaque mineur ajoute le bloc à la chaîne, la chaîne comportera de nombreuses branches, ce qui entraînera un état incohérent. Ainsi un système pour surmonter ce défi serait indispensable.
Les mineurs se concourent pour créer un nouveau block et obtenir la récompense. En effet, le minage est une opération qui permet au mineur de trouver un bloc valide par la résolution d’un problème mathématique complexe et de s’octroyer un gain.
Les vulnérabilités, menaces, risques et attaques dans la blockchain
La technologie blockchain est un « simple » composant d’un système, d’une application, ou d’un service, tout comme une base de données dans une application métier.
Elle fournit des propriétés de sécurité, mais les vulnérabilités et les risques doivent également être évalués. Pourtant, dans la pratique, plusieurs attaques existent qui manipulent directement ou indirectement le mécanisme de récompense, donnant d’injustes avantages aux mineurs de large taille aux frais des petits mineurs.
Si la sécurité de Bitcoin était censée initialement être compromise par une attaque de type « 50%+1 », on reconnait aujourd’hui que la taille critique (en termes de puissance de calcul) d’un acteur malveillant qui souhaiterait manipuler le système d’incitation en sa faveur pourrait être bien moins large : on estime ce seuil critique pour lancer une attaque connue comme « selfish mining » à 30% ou moins.
D’autres travaux concluent que tout arbitrage dont les mineurs jouissent, tel que le choix des transactions qui rentrent dans un bloc de la blockchain, permet de manipuler le comportement des autres mineurs. Et comme la valeur intrinsèque d’une unité de crypto-monnaie est difficile à estimer et sujette à une forte spéculation, tout phénomène de ‘bulle’ de prix de marché risque à la fois d’intensifier l’engagement des mineurs, en augmentant la consommation totale d’énergie, et de décourager l’utilisation de la crypto-monnaie pour exécuter des transactions légitimes, que ce soit par des frais élevés, ou par une volatilité des prix accrue.
Ceci tout en attisant la vigueur des attaques contre le système, qui risquent à tout moment de pulvériser la confiance des utilisateurs et des mineurs si une faille sérieuse au niveau des algorithmes ou des protocoles était soudainement exploitée.
Tel que décrit par le groupe Sécurité du comité ISO TC307, il existe plusieurs propriétés de sécurité fournies par les systèmes Blockhain, appelés dans le contexte de l’ISO TC307 DLTs (Distributed Ledger Technologies ). Ce qui suit est une liste de ces propriétés de sécurité.
Certaines d’entre elles sont des propriétés de sécurité communes à toutes les applications basées sur DLT tandis que d’autres sont facultatives et dépendent de la nature de l’application. Cette liste est provisoire et est susceptible de changer :
- L’intégrité : les enregistrements dans le ledger sont protégés contre toute modification après leur création. Aussi connu comme l’immutabilité ou la résistance à l’altération.
- L’Authenticité : toute personne (ou un ensemble certifié d’entités) peut vérifier l’entité qui crée une transaction enregistrée dans le registre.
- La confidentialité : les enregistrements dans le registre ne peuvent être consultés que par une entité autorisée.
- L’ordre des événements : l’ordre des enregistrements dans le ledger ne peut pas être modifié.
- La disponibilité : les transactions enregistrées dans le ledger et la fonctionnalité pour enregistrer et récupérer les données sont toujours disponibles pour les utilisateurs.
Les risques liés aux composants qui interagissent avec une Blockchain telles que des personnes physiques ou morales qui utilisent des interfaces, des applications, des objets intelligents comme des compteurs électriques ou des capteurs, sont multiples. Il faut par exemple que tous ces composants aient un identifiant unique et sécurisé sur la Blockchain afin d’éviter toute usurpation d’identité, et de pouvoir associer une responsabilité à une action dans la Blockchain. Les risques liés aux données doivent également être analysés.
Comment s’assurer par exemple qu’une transaction soumise au système sera bien validée et qu’il n’y a pas eu d’altération des données par un smart contact, ou le système lui-même ?
L’intégrité des données injectées et manipulées est un point clef de la blockchain. Comment respecter des cas d’usage ou des régulations en place qui exigent une confidentialité des données, comme les données personnelles ? Du point de vue de la norme ISO, les risques et les vulnérabilités des systèmes DLT comprennent des risques et vulnérabilités communs aux systèmes d’information tels que :
1. Mauvaise gestion de l’information (altération, suppression, destruction non autorisée, divulgation, etc.).
2. Vulnérabilités de mise en œuvre (y compris les mécanismes cryptographiques, vulnérabilités de mise en œuvre, fuites d’informations au moment de l’exécution, etc.).
3. Mauvaise gestion des mécanismes cryptographiques (y compris l’utilisation d’algorithmes faibles, la divulgation de clé).
4. Mauvaise gestion des privilèges de l’utilisateur. L’identification des vulnérabilités et/ou menace des Blockchains permet de mieux comprendre les mécanismes de sécurité incorporés dans leurs protocoles.
20 D. G. Wood, (2019), « ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER », p. 32. 21 Jean-Patrick GELAS, (Mars 2019) , Introduction à la blockchain Ethereum et aux smarts contracts, Café des développeurs, Université Claude Bernard, Lyon 1-Frances
La blockchain Ethereum
Les comptes, messages et transactions
À la différence de Bitcoin, Ethereum est comme une machine à état où une nouvelle transaction permet de passer d’un état à un autre. L’état global d’Ethereum est composé de nombreux comptes capables d’interagir les uns avec les autres via des transactions ou des messages.
Les comptes Ethereum introduit formellement le concept de compte dans le cadre de son protocole. Le compte est l’initiateur et la cible d’une transaction. Une transaction met directement à jour les soldes des comptes, par opposition au maintien de l’état, comme dans les UTXO en bitcoins et permet la transmission de valeur, de messages et de données entre les comptes pouvant entraîner des transitions d’état.
Chaque compte est associé à un état et à une adresse de 20 octets (c’est-à-dire 160 bits) qui permet de l’identifier.
Il existe deux types de comptes :
1. Les comptes de propriété externe ou EOA (« Externally Owned Accounts ») qui sont contrôlés par des clés privées et ne sont associés à aucun code. Un compte externe est nécessaire pour participer au réseau Ethereum. Il interagit avec la blockchain en créant et en signant une transaction à l’aide de sa clé privée. Une transaction entre deux comptes externes est simplement un transfert de valeur. Mais une transaction entre un compte externe et un compte de contrat active le code du compte de contrat, lui permettant d’effectuer diverses actions (par exemple, transférer des jetons, écrire dans la mémoire interne, créer de nouveaux jetons, effectuer des calculs, créer de nouveaux contrats, etc.).
2. Les comptes de contrat ou CA (« Contract Account »), qui sont contrôlés par leur code de contrat et sont associés à un code. Ils représentent un contrat intelligent et ne peuvent être activés que par un EOA. Les comptes de contrat ne peuvent pas initier de nouvelles transactions par eux-mêmes. Par contre, ils peuvent uniquement déclencher des transactions pour répondre à d’autres transactions qu’ils ont reçues (d’un compte appartenant externe ou d’un autre compte de contrat).
État du compte
L’état d’un compte Ethereum est composé (quelques soit son type) de quatre champs :
1. Le nonce : Si le compte est un compte externe, le nonce représente le nombre de transactions envoyées à partir de l’adresse du compte. S’il s’agit d’un compte de contrat, le nonce est le nombre de contrats créés par le compte.
2. Le solde actuel du compte exprimé en Wei (1 Ether = 1018 Wei),
3. Le storageRoot : c’est le hachage de la racine de l’arbre de Merkle. Cette racine est obtenue à partir du hachage du contenu de stockage du compte. StorageRoot est vide par défaut.
4. Et enfin le codeHash qui représente le hachage du code du compte dans la machine virtuelle d’Ethereum (EVM). Pour un compte de contrat, le code du contrat est haché et stocké sous le nom codeHash et pour un compte externe, le codeHash est le hachage de la chaîne vide.
Figure 12 : L’état d’un compte dans Ethereum
L’état global
L’état global de la blockchain Ethereum est considéré comme un mappage entre les adresses de compte et les états de compte. Ce mappage est stocké dans une structure de données appelée arbre Merkle. Cet arbre doit avoir une clé pour chaque valeur stockée à l’intérieur.
À partir du nœud racine de l’arbre, la clé doit vous indiquer quel nœud enfant suivre pour obtenir la valeur correspondante, stockée dans les nœuds terminaux. Dans le cas d’Ethereum, le mappage clé / valeur de l’arbre d’état se situe entre les adresses et leurs comptes associés, y compris les éléments solde, nonce, codeHash et storageRoot pour chaque compte (où storageRoot est lui-même la racine d’un autre arbre.
Message et Transaction
L’intervention d’une transaction permet de changer l’état global de la blockchain Ethereum. En ce sens, une transaction est une instruction signée avec des fonctions cryptographiques qui est générée par un compte externe, sérialisée, puis soumise à la blockchain.
Il existe deux types de transactions : les appels de message et les créations de contrat (c’est-à-dire les transactions qui créent de nouveaux contrats Ethereum). Toutes les transactions contiennent les composants suivants, quel que soit leur type :
1. Le nonce : nombre de transactions envoyées par l’expéditeur.
2. Le prix du « gas » (gasPrice) : Le nombre de Wei que l’expéditeur est prêt à payer par unité de « gas » nécessaire pour exécuter la transaction.
3. La limite de « gas » (gasLimit) : quantité maximale de « gas » que l’expéditeur est prêt à payer pour l’exécution de cette transaction. Ce montant est défini et payé d’emblée, avant tout calcul.
4. L’adresse du destinataire. Dans une transaction de création de contrat, l’adresse du compte du contrat n’existe pas encore et une valeur vide est donc utilisée.
5. Un champ valeur (Value): le montant (en Wei) à transférer de l’expéditeur au destinataire. Dans une transaction de création de contrat, cette valeur sert de solde de départ dans le compte de contrat nouvellement créé.
6. v, r, s : trois variables utilisées pour générer la signature identifiant l’expéditeur de la transaction.
7. Un champ init (uniquement pour les transactions créant un contrat) qui est un fragment de code utilisé pour initialiser le nouveau compte de contrat. Il est exécuté une seule fois, puis ignoré. Lorsque « init » est exécuté pour la première fois, il renvoie le corps du code de compte, qui est la partie de code associée en permanence au compte du contrat.
8. Les données (champ facultatif qui existe uniquement pour les appels de message) : ce sont les données d’entrée (c.-à-d. les paramètres) de l’appel de message.