Portefeuilles
Le mot "portefeuille" est utilisé pour décrire quelques choses différentes dans Ethereum.
À un niveau élevé, un portefeuille est une application logicielle qui sert d’interface utilisateur principale à Ethereum. Le portefeuille contrôle l’accès à l’argent d’un utilisateur, gère les clés et les adresses, suit le solde et crée et signe des transactions. De plus, certains portefeuilles Ethereum peuvent également interagir avec des contrats, tels que les jetons ERC20.
Plus étroitement, du point de vue d’un programmeur, le mot wallet ou portefeuille fait référence au système utilisé pour stocker et gérer les clés d’un utilisateur. Chaque portefeuille a un composant de gestion des clés. Pour certains portefeuilles, c’est tout ce qu’il y a. D’autres portefeuilles font partie d’une catégorie beaucoup plus large, celle des navigateurs, qui sont des interfaces vers des applications décentralisées basées sur Ethereum, ou DApps, que nous examinerons plus en détail dans [decentralized_applications_chap]. Il n’y a pas de lignes de distinction claires entre les différentes catégories qui sont regroupées sous le terme portefeuille.
Dans ce chapitre, nous examinerons les portefeuilles en tant que conteneurs de clés privées et en tant que systèmes de gestion de ces clés.
Présentation de la technologie de portefeuille
Dans cette section, nous résumons les différentes technologies utilisées pour construire des portefeuilles Ethereum conviviaux, sécurisés et flexibles.
L’une des principales considérations dans la conception des portefeuilles est l’équilibre entre commodité et confidentialité. Le portefeuille Ethereum le plus pratique est celui avec une clé privée unique et une adresse que vous réutilisez pour tout. Malheureusement, une telle solution est un cauchemar pour la confidentialité, car n’importe qui peut facilement suivre et corréler toutes vos transactions. L’utilisation d’une nouvelle clé pour chaque transaction est préférable pour la confidentialité, mais devient très difficile à gérer. Le bon équilibre est difficile à atteindre, mais c’est pourquoi une bonne conception de portefeuille est primordiale.
Une idée fausse courante à propos d’Ethereum est que les portefeuilles Ethereum contiennent de l’ether ou des jetons. En fait, très strictement parlant, le portefeuille ne contient que des clés. L’ether ou d’autres jetons sont enregistrés sur la chaîne de blocs Ethereum. Les utilisateurs contrôlent les jetons sur le réseau en signant des transactions avec les clés dans leurs portefeuilles. Dans un sens, un portefeuille Ethereum est un porte-clés. Cela dit, étant donné que les clés détenues par le portefeuille sont les seules choses nécessaires pour transférer de l’ether ou des jetons à d’autres, en pratique, cette distinction est assez peu pertinente. Là où la différence est importante, c’est dans le fait de changer d’état d’esprit et de ne plus avoir affaire au système bancaire conventionnel centralisé (où seuls vous et la banque pouvez voir l’argent sur votre compte, et vous n’avez qu’à convaincre la banque que vous voulez transférer des fonds pour faire une transaction) vers un système décentralisé des plates-formes chaîne de blocs (où tout le monde peut voir le solde d’un compte, bien qu’il ne connaisse probablement pas le propriétaire du compte, et tout le monde doit être convaincu que le propriétaire veut déplacer des fonds pour une transaction édictée). En pratique, cela signifie qu’il existe un moyen indépendant de vérifier le solde d’un compte, sans avoir besoin de son portefeuille. De plus, vous pouvez déplacer la gestion de votre compte de votre portefeuille actuel vers un autre portefeuille, si vous n’aimez plus l’application de portefeuille que vous avez commencé à utiliser.
|
Note
|
Les portefeuilles Ethereum contiennent des clés, pas d’ether ni de jetons. Les portefeuilles sont comme des porte-clés contenant des paires de clés privées et publiques. Les utilisateurs signent des transactions avec les clés privées, prouvant ainsi qu’ils possèdent l’ether. L’ether est stocké sur la chaîne de blocs. |
Il existe deux principaux types de portefeuilles, qui se distinguent par le fait que les clés qu’ils contiennent sont liées ou non.
Le premier type est un portefeuille non déterministe, où chaque clé est générée indépendamment à partir d’un nombre aléatoire différent . Les clés ne sont pas liées les unes aux autres. Ce type de portefeuille est également connu sous le nom de portefeuille JBOK, de l’expression "Just a Bunch Of Keys" ou "Juste un tas de clés".
Le deuxième type de portefeuille est un portefeuille déterministe, où toutes les clés sont dérivées d’une seule clé maîtresse, connue sous le nom de seed ou graine ou valeur d’amorçage. Toutes les clés de ce type de portefeuille sont liées les unes aux autres et peuvent être générées à nouveau si l’on dispose de la valeur d’amorçage d’origine. Il existe un certain nombre de méthodes différentes de dérivation de clé utilisées dans les portefeuilles déterministes. La méthode de dérivation la plus couramment utilisée utilise une structure arborescente, comme décrit dans Portefeuilles déterministes hiérarchiques (BIP-32/BIP-44).
Pour rendre les portefeuilles déterministes légèrement plus sûrs contre les accidents de perte de données, comme le vol de votre téléphone ou sa chute dans les toilettes, les valeurs d’amorçages sont souvent encodées sous la forme d’une liste de mots (en anglais ou dans une autre langue) à noter et à utiliser en cas d’accident. Ceux-ci sont connus sous le nom de mots de code mnémoniques du portefeuille. Bien sûr, si quelqu’un met la main sur vos mots de code mnémoniques, il peut également recréer votre portefeuille et ainsi accéder à vos contrats intelligents et votre ether. En tant que tel, soyez très, très prudent avec votre liste de mots de récupération ! Ne les stockez jamais électroniquement, dans un fichier, sur votre ordinateur ou votre téléphone. Écrivez-le sur papier et rangez-le dans un endroit sûr et sécurisé.
Les prochaines sections présentent chacune de ces technologies à un niveau élevé.
Portefeuilles non déterministes (aléatoires)
Dans le premier portefeuille Ethereum (produit pour la prévente Ethereum), chaque fichier de portefeuille stockait une seule clé privée générée aléatoirement. Ces portefeuilles sont remplacés par des portefeuilles déterministes car ces portefeuilles "à l’ancienne" sont à bien des égards inférieurs. Par exemple, il est considéré comme une bonne pratique d’éviter la réutilisation de l’adresse Ethereum dans le cadre de la maximisation de votre vie privée lors de l’utilisation d’Ethereum, c’est-à-dire d’utiliser une nouvelle adresse (qui nécessite une nouvelle clé privée) chaque fois que vous recevez des fonds. Vous pouvez aller plus loin et utiliser une nouvelle adresse pour chaque transaction, bien que cela puisse coûter cher si vous traitez beaucoup de jetons. Pour suivre cette pratique, un portefeuille non déterministe devra régulièrement augmenter sa liste de clés, ce qui signifie que vous devrez effectuer des sauvegardes régulières. Si jamais vous perdez vos données (panne de disque, accident d’abus de boisson, vol de téléphone) avant d’avoir réussi à sauvegarder votre portefeuille, vous perdrez l’accès à vos fonds et à vos contrats intelligents. Les portefeuilles non déterministes de "type 0" sont les plus difficiles à gérer, car ils créent un nouveau fichier de portefeuille pour chaque nouvelle adresse de manière "juste à temps".
Néanmoins, de nombreux clients Ethereum (y compris geth)utilisent un fichier keystore ou magasin de clés, qui est un fichier codé JSON contenant une clé privée unique (générée de manière aléatoire), chiffrée par une phrase secrète pour plus de sécurité . Le contenu du fichier JSON ressemble à ceci :
{
"address": "001d3f1ef827552ae1114027bd3ecf1f086ba0f9",
"crypto": {
"cipher": "aes-128-ctr",
"ciphertext":
"233a9f4d236ed0c13394b504b6da5df02587c8bf1ad8946f6f2b58f055507ece",
"cipherparams": {
"iv": "d10c6ec5bae81b6cb9144de81037fa15"
},
"kdf": "scrypt",
"kdfparams": {
"dklen": 32,
"n": 262144,
"p": 1,
"r": 8,
"salt":
"99d37a47c7c9429c66976f643f386a61b78b97f3246adca89abe4245d2788407"
},
"mac": "594c8df1c8ee0ded8255a50caf07e8c12061fd859f4b7c76ab704b17c957e842"
},
"id": "4fcb2ba4-ccdb-424f-89d5-26cce304bf9c",
"version": 3
}Le format de magasin de clés utilise une fonction de dérivation de clé (KDF ou key derivation function), également connue sous le nom d’algorithme d’étirement de mot de passe, qui protège contre les attaques par force, par dictionnaire et par table arc-en-ciel. En termes simples, la clé privée n’est pas chiffrée directement par la phrase secrète. Au lieu de cela, la phrase secrète est étirée, en la hachant à plusieurs reprises. La fonction de hachage est répétée pendant 262 144 tours, ce qui peut être vu dans le magasin de clés JSON sous la forme du paramètre crypto.kdfparams.n. Un attaquant essayant de forcer brutalement la phrase secrète devrait appliquer 262 144 cycles de hachage pour chaque phrase secrète tentée, ce qui ralentit suffisamment l’attaque pour la rendre impossible pour les phrases secrètes d’une complexité et d’une longueur suffisantes.
Il existe un certain nombre de bibliothèques logicielles qui peuvent lire et écrire le format keystore, comme la bibliothèque JavaScript keythereum.
|
Tip
|
L’utilisation de portefeuilles non déterministes est déconseillée pour autre chose que de simples tests. Ils sont trop encombrants pour être sauvegardés et utilisés pour autre chose que les situations les plus élémentaires. Utilisez plutôt un portefeuille HD standard avec une valeur d’amorçage mnémonique pour la sauvegarde. |
Portefeuilles déterministes (par valeur d’amorçage)
Les portefeuilles déterministes ou "ensemencés par valeurs d’amorçages" sont des portefeuilles qui contiennent des clés privées qui sont toutes dérivées d’une seule clé maîtresse ou valeur d’amorçage. La valeur d’amorçage est un nombre généré aléatoirement qui est combiné avec d’autres données, telles qu’un numéro d’index ou un "code de chaîne" (voir Clés publiques et privées étendues), pour dériver n’importe quel nombre de clés privées. Dans un portefeuille déterministe, la valeur d’amorçage est suffisante pour récupérer toutes les clés dérivées, et donc une seule sauvegarde, au moment de la création, est suffisante pour sécuriser tous les fonds et contrats intelligents dans le portefeuille. La valeur d’amorçage est également suffisante pour une exportation ou une importation de portefeuille, permettant une migration facile de toutes les clés entre différentes implémentations de portefeuille.
Cette conception rend la sécurité de la valeur d’amorçage d’une plus haute importance, car seule la valeur d’amorçage est nécessaire pour accéder à l’ensemble du portefeuille. D’un autre côté, le fait de pouvoir concentrer les efforts de sécurité sur une seule donnée peut être considéré comme un avantage.
Portefeuilles déterministes hiérarchiques (BIP-32/BIP-44)
Les portefeuilles déterministes ont été développés pour faciliter la dérivation de nombreuses clés à partir d’une seule valeur d’amorçage. Actuellement, la forme la plus avancée de portefeuille déterministe est le portefeuille hiérarchique déterministe (HD ou Hierarchical Deterministic) défini par le standard BIP-32 de Bitcoin. Les portefeuilles HD contiennent des clés dérivées dans une structure arborescente, de sorte qu’une clé parent peut dériver une séquence de clés enfants, chacune pouvant dériver une séquence de clés petits-enfants, et ainsi de suite. Cette arborescence est illustrée dans Portefeuille HD : un arbre de clés généré à partir d’une seule valeur d’amorçage.
Les portefeuilles HD offrent quelques avantages clés par rapport aux portefeuilles déterministes plus simples. Tout d’abord, la structure arborescente peut être utilisée pour exprimer une signification organisationnelle supplémentaire, par exemple lorsqu’une branche spécifique de sous-clés est utilisée pour recevoir des paiements entrants et qu’une branche différente est utilisée pour recevoir la monnaie des paiements sortants. Les branches de clés peuvent également être utilisées dans les paramètres de l’entreprise, en attribuant différentes branches à des départements, des filiales, des fonctions spécifiques ou des catégories comptables.
Le deuxième avantage des portefeuilles HD est que les utilisateurs peuvent créer une séquence de clés publiques sans avoir accès aux clés privées correspondantes. Cela permet aux portefeuilles HD d’être utilisés sur un serveur non sécurisé ou dans une capacité de surveillance ou de réception uniquement, où le portefeuille n’a pas les clés privées qui peuvent dépenser les fonds.
Valeurs d’amorçage et codes mnémoniques (BIP-39)
Il y a beaucoup de manières d’encoder une clé privée pour une sauvegarde et une récupération sécurisées. La méthode actuellement préférée consiste à utiliser une séquence de mots qui, lorsqu’ils sont pris ensemble dans le bon ordre, peuvent recréer de manière unique la clé privée. Ceci est parfois connu sous le nom de mnémonique, et l’approche a été normalisée par BIP-39. Aujourd’hui, de nombreux portefeuilles Ethereum (ainsi que des portefeuilles pour d’autres crypto-monnaies) utilisent cette norme et peuvent importer et exporter des valeurs d’amorçage pour la sauvegarde et la récupération à l’aide de mnémoniques interopérables.
Pour comprendre pourquoi cette approche est devenue populaire, examinons un exemple :
FCCF1AB3329FD5DA3DA9577511F8F137
wolf juice proud gown wool unfair wall cliff insect more detail hub
En termes pratiques, le risque d’erreur lors de l’écriture de la séquence hexadécimale est inacceptablement élevé. En revanche, la liste des mots connus est assez facile à gérer, principalement parce qu’il y a une forte redondance dans l’écriture des mots (surtout des mots anglais). Si « inzect » avait été enregistré par accident, il pourrait être rapidement déterminé, lors de la récupération du portefeuille, que « inzect » n’est pas un mot anglais valide et que « insect » devrait être utilisé à la place. Nous parlons d’écrire une représentation de la valeur d’amorçage car c’est une bonne pratique lors de la gestion des portefeuilles HD : la valeur d’amorçage est nécessaire pour récupérer un portefeuille en cas de perte de données (que ce soit par accident ou par vol), il est donc très prudent de conserver une sauvegarde. Cependant, la valeur d’amorçage doit rester extrêmement privée, les sauvegardes numériques doivent donc être soigneusement évitées ; d’où le conseil précédent de sauvegarder avec un stylo et du papier.
En résumé, l’utilisation d’une liste de mots de récupération pour coder la valeur d’amorçage d’un portefeuille HD constitue le moyen le plus simple d’exporter, de transcrire, d’enregistrer sur papier en toute sécurité, de lire sans erreur et d’importer un ensemble de clés privées dans un autre portefeuille.
Meilleures pratiques de portefeuille
Alors que la technologie des portefeuilles de cryptomonnaie a mûri, certaines normes industrielles communes ont émergé qui rendent les portefeuilles largement interopérables, faciles à utiliser, sécurisé et flexible. Ces normes permettent également aux portefeuilles de dériver des clés pour plusieurs cryptomonnaies différentes, toutes à partir d’un seul mnémonique. Ces normes communes sont :
-
Mots de code mnémonique, basés sur BIP-39
-
Portefeuilles HD, basés sur BIP-32
-
Structure de portefeuille HD polyvalente, basée sur BIP-43
-
Portefeuilles multidevises et multicomptes, basés sur BIP-44
Ces normes peuvent changer ou être obsolètes par les développements futurs, mais pour l’instant, elles forment un ensemble de technologies imbriquées qui sont devenues la norme de facto de portefeuille pour la plupart des plateformes de chaîne de blocs et leurs cryptomonnaies.
Les normes ont été adoptées par une large gamme de portefeuilles logiciels et matériels, rendant tous ces portefeuilles interopérables. Un utilisateur peut exporter un mnémonique généré dans l’un de ces portefeuilles et l’importer dans un autre portefeuille, en récupérant toutes les clés et adresses.
Quelques exemples de portefeuilles logiciels prenant en charge ces normes incluent (classés par ordre alphabétique) Jaxx, MetaMask, MyCrypto et MyEtherWallet (MEW). Les exemples de portefeuilles matériels prenant en charge ces normes incluent Keepkey, Ledger et Trezor.
Les sections suivantes examinent chacune de ces technologies en détail.
|
Tip
|
Si vous implémentez un portefeuille Ethereum, il doit être construit comme un portefeuille HD, avec une valeur d’amorçage encodée sous forme de code mnémonique pour la sauvegarde, conformément aux normes BIP-32, BIP-39, BIP-43 et BIP-44, comme décrit dans les rubriques suivantes. |
Mots de code mnémonique (BIP-39)
Les mots de code mnémoniques sont des séquences de mots qui encodent un nombre aléatoire utilisé comme valeur d’amorçage pour dériver un portefeuille déterministe. La séquence de mots est suffisante pour recréer la valeur d’amorçage, et à partir de là recréer le portefeuille et toutes les clés dérivées. Une application de portefeuille qui implémente des portefeuilles déterministes avec des mots mnémoniques montrera à l’utilisateur une séquence de 12 à 24 mots lors de la première création d’un portefeuille. Cette séquence de mots est la sauvegarde du portefeuille et peut être utilisée pour récupérer et recréer toutes les clés dans la même application de portefeuille ou dans n’importe quelle application de portefeuille compatible. Comme nous l’avons expliqué précédemment, les listes de mots mnémoniques facilitent la sauvegarde des portefeuilles par les utilisateurs, car elles sont faciles à lire et correctement transcrire.
|
Note
|
Les mots mnémoniques sont souvent confondus avec les "brainwallets". Ils ne sont pas les mêmes. La principale différence est qu’un brainwallet se compose de mots choisis par l’utilisateur, tandis que les mots mnémoniques sont créés de manière aléatoire par le portefeuille et présentés à l’utilisateur. Cette différence importante rend les mots mnémoniques beaucoup plus sûrs, car les humains sont de très mauvaises sources d’aléatoire. Peut-être plus important encore, l’utilisation du terme "brainwallet" suggère que les mots doivent être mémorisés, ce qui est une idée terrible et une recette pour ne pas avoir votre sauvegarde lorsque vous en avez besoin. |
Les codes mnémoniques sont définis dans le BIP-39. Notez que BIP-39 est une implémentation d’une norme de code mnémonique. Il existe une norme différente, avec un ensemble de mots différent, utilisée par le portefeuille Electrum Bitcoin et antérieure à BIP-39. BIP-39 a été proposé par la société à l’origine du portefeuille matériel Trezor et est incompatible avec la mise en œuvre d’Electrum. Cependant, BIP-39 a maintenant obtenu un large soutien de l’industrie à travers des dizaines d’implémentations interopérables et devrait être considéré comme la norme de facto industrielle. De plus, BIP-39 peut être utilisé pour produire des portefeuilles multidevises prenant en charge Ethereum, contrairement aux valeurs d’amorçage Electrum.
La BIP-39 définit la création d’un code mnémonique et d’une valeur d’amorçage, que nous décrivons ici en neuf étapes. Pour plus de clarté, le processus est divisé en deux parties : les étapes 1 à 6 sont présentées dans Génération de mots mnémoniques et les étapes 7 à 9 sont illustrées dans Du mnémonique à la valeur d’amorçage.
Génération de mots mnémoniques
Les mots mnémoniques sont générés automatiquement par le portefeuille en utilisant le processus standardisé défini dans BIP-39. Le portefeuille part d’une source d’entropie, ajoute une somme de contrôle, puis mappe l’entropie sur une liste de mots :
-
Créer une séquence cryptographiquement aléatoire
Sde 128 à 256 bits. -
Créez une somme de contrôle de
Sen prenant la première longueur de S ÷ 32 bits du hachage SHA-256 deS. -
Ajoutez la somme de contrôle à la fin de la séquence aléatoire
S. -
Divisez la concaténation de séquence et de somme de contrôle en sections de 11 bits.
-
Associez chaque valeur 11 bits à un mot du dictionnaire prédéfini de 2 048 mots.
-
Créez le code mnémonique à partir de la séquence de mots en respectant l’ordre.
Génération d’entropie et encodage sous forme de mots mnémoniques montre comment l’entropie est utilisée pour générer des mots mnémoniques.
Codes mnémoniques : entropie et longueur des mots montre la relation entre la taille des données d’entropie et la longueur des codes mnémoniques en mots.
| Entropie (bits) | Somme de contrôle (bits) | Somme de contrôle d’entropie + (bits) | Longueur mnémonique (mots) |
|---|---|---|---|
128 |
4 |
132 |
12 |
160 |
5 |
165 |
15 |
192 |
6 |
198 |
18 |
224 |
7 |
231 |
21 |
256 |
8 |
264 |
24 |
Du mnémonique à la valeur d’amorçage
Les mots mnémoniques représentent l’entropie d’une longueur de 128 à 256 bits . L’entropie est ensuite utilisée pour dériver une valeur d’amorçage plus longue (512 bits) grâce à l’utilisation de la fonction d’étirement de clé PBKDF2. La valeur d’amorçage produite est utilisée pour construire un portefeuille déterministe et en dériver ses clés.
La fonction d’étirement de clé prend deux paramètres : le mnémonique et un sel. Le but d’un sel dans une fonction d’étirement de clé est de rendre difficile la construction d’une table de recherche permettant une attaque par force brute. Dans la norme BIP-39, le sel a un autre objectif : il permet l’introduction d’une phrase secrète qui sert de facteur de sécurité supplémentaire protégeant la valeur d’amorçage, comme nous le décrirons plus en détail dans Phrase secrète facultative dans BIP-39.
Le processus décrit aux étapes 7 à 9 continue à partir du processus décrit dans la section précédente :
-
Le premier paramètre de la fonction d’étirement de clé PBKDF2 est le mnémonique produit à l’étape 6.
-
Le deuxième paramètre de la fonction d’étirement de clé PBKDF2 est un sel. Le sel est composé de la constante de chaîne "mnémonique" concaténée avec une phrase secrète facultative fournie par l’utilisateur.
-
PBKDF2 étend les paramètres mnémoniques et de sel en utilisant 2 048 cycles de hachage avec l’algorithme HMAC-SHA512, produisant une valeur de 512 bits comme sortie finale. Cette valeur de 512 bits est la valeur d’amorçage.
Du mnémonique à la valeur d’amorçage montre comment un mnémonique est utilisé pour générer une valeur d’amorçage.
|
Note
|
La fonction d’étirement de clé, avec ses 2 048 cycles de hachage, est une protection assez efficace contre les attaques par force brute contre le mnémonique ou la phrase secrète. Cela rend coûteux (en calcul) d’essayer plus de quelques milliers de combinaisons de mots de passe et de mnémoniques, alors que le nombre de valeurs d’amorçage dérivées possibles est vaste (2512, soit environ 10154) - bien plus grand que le nombre d’atomes dans l’univers visible (environ 1080). |
Les tables #mnemonic_128_no_pass, #mnemonic_128_w_pass et #mnemonic_256_no_pass montrent quelques exemples de codes mnémoniques et les valeurs d’amorçage qu’ils produisent.
Entrée d’entropie (128 bits) |
0c1e24e5917779d297e14d45f14e1a1a |
|---|---|
Mnémonique (12 mots) |
army van defense carry jealous true garbage claim echo media make crunch |
Phrase secrète |
(rien) |
Valeur d’amorçage (512 bits) |
5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39 a88b76373733891bfaba16ed27a813ceed498804c0570 |
Entrée d’entropie (128 bits) |
0c1e24e5917779d297e14d45f14e1a1a |
|---|---|
Mnémonique (12 mots) |
army van defense carry jealous true garbage claim echo media make crunch |
Phrase secrète |
SuperDuperSecret |
Valeur d’amorçage (512 bits) |
3b5df16df2157104cfdd22830162a5e170c0161653e3afe6c88defeefb0818c793dbb28ab3ab091897d0 715861dc8a18358f80b79d49acf64142ae57037d1d54 |
Entrée d’entropie (256 bits) |
2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c |
|---|---|
Mnémonique (24 mots) |
cake apple borrow silk endorse fitness top denial coil riot stay wolf luggage oxygen faint major edit measure invite love trap field dilemma oblige |
Phrase secrète |
(rien) |
Valeur d’amorçage (512 bits) |
3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3a04356e53d062e5 5f1e0deaa082df8d487381379df848a6ad7e98798404 |
Phrase secrète facultative dans BIP-39
La norme BIP-39 permet l’utilisation d’une phrase secrète facultative dans la dérivation de la valeur d’amorçage. Si aucune phrase secrète n’est utilisée, le mnémonique est étiré avec un sel constitué de la chaîne constante "mnémonique", produisant une valeur d’amorçage spécifique de 512 bits à partir de n’importe quel mnémonique donné. Si une phrase secrète est utilisée, la fonction d’étirement produit une valeur d’amorçage différente à partir de ce même mnémonique. En fait, étant donné un seul mnémonique, chaque phrase secrète possible conduit à une valeur d’amorçage différente. Essentiellement, il n’y a pas de "mauvaise" phrase secrète. Toutes les phrases secrètes sont valides et mènent toutes à des valeur d’amorçage différentes, formant un vaste ensemble de portefeuilles non initialisés possibles. L’ensemble des portefeuilles possibles est si grand (2512) qu’il n’y a aucune possibilité pratique de forcer brutalement ou de deviner accidentellement celui qui est utilisé, tant que la phrase secrète a une complexité et une longueur suffisantes.
|
Tip
|
Il n’y a pas de "mauvaises" phrases secrète dans BIP-39. Chaque phrase secrète mène à un portefeuille qui, à moins qu’il n’ait été utilisé auparavant, sera vide. |
La phrase secrète facultative crée deux fonctionnalités importantes :
-
Un deuxième facteur (quelque chose de mémorisé) qui rend un mnémonique inutile par lui-même, protégeant les sauvegardes mnémoniques de la compromission par un voleur.
-
Une forme de déni plausible ou "portefeuille sous contrainte", où une phrase secrète choisie mène à un portefeuille avec une petite quantité de fonds , utilisé pour distraire un attaquant du "vrai" portefeuille qui contient la majorité des fonds.
Cependant, il est important de noter que l’utilisation d’une phrase secrète introduit également un risque de perte :
-
Si le propriétaire du portefeuille est incapacité ou décédé et que personne d’autre ne connaît la phrase secrète, la valeur d’amorçage est inutile et tous les fonds stockés dans le portefeuille sont perdus à jamais.
-
À l’inverse, si le propriétaire sauvegarde la phrase secrète au même endroit que la valeur d’amorçage, cela va à l’encontre de l’objectif d’un deuxième facteur.
Bien que les phrases secrètes soient très utiles, elles ne doivent être utilisées qu’en combinaison avec un processus soigneusement planifié de sauvegarde et de récupération, compte tenu de la possibilité que des héritiers survivant au propriétaire puissent récupérer la cryptomonnaie.
Travailler avec des codes mnémoniques
BIP-39 est implémenté comme une bibliothèque dans de nombreux langages de programmation différents. Par example:
- python-mnemonic
-
L’implémentation de référence de la norme par l’équipe SatoshiLabs qui a proposé BIP-39, en Python
- ConsenSys/eth-lightwallet
-
Portefeuille léger JS Ethereum pour nœuds et navigateur (avec BIP-39)
- npm/bip39
-
Implémentation JavaScript de Bitcoin BIP-39 : Code mnémonique pour générer des clés déterministes
Il existe également un générateur BIP-39 implémenté dans une page Web autonome (Un générateur BIP-39 en tant que page Web autonome), ce qui est extrêmement utile pour les tests et l’expérimentation. Le Mnemonic Code Converter génère des mnémoniques, des valeurs d’amorçage et des clés privées étendues. Il peut être utilisé hors ligne dans un navigateur ou accessible en ligne.
Créer un portefeuille HD à partir de la valeur d’amorçage
Les portefeuilles HD sont créés à partir d’une seule valeur d’amorçage racine, qui est un nombre aléatoire de 128, 256 ou 512 bits. Le plus souvent, cette valeur d’amorçage est générée à partir d’un mnémonique comme détaillé dans la section précédente.
Chaque clé du portefeuille HD est dérivée de manière déterministe de cette valeur d’amorçage racine, ce qui permet de recréer l’intégralité du portefeuille HD à partir de cette valeur d’amorçage dans n’importe quel portefeuille HD compatible. Cela facilite l’exportation, la sauvegarde, la restauration et l’importation de portefeuilles HD contenant des milliers, voire des millions de clés en transférant uniquement le mnémonique à partir duquel la valeur d’amorçage racine est dérivée.
Portefeuilles HD (BIP-32) et Chemins (BIP-43/44)
La plupart des portefeuilles HD suivent le Standard BIP-32, qui est devenu un standard industriel de facto pour la génération de clé déterministe.
Nous ne discuterons pas de tous les détails du BIP-32 ici, seulement des composants nécessaires pour comprendre comment il est utilisé dans les portefeuilles. Le principal aspect important est les relations hiérarchiques arborescentes qu’il est possible que les clés dérivées aient, comme vous pouvez le voir dans Portefeuille HD : un arbre de clés généré à partir d’une seule valeur d’amorçage. Il est également important de comprendre les notions de clés étendues et clés renforcées, qui sont expliquées dans les sections suivantes.
Il existe des dizaines d’implémentations interopérables de BIP-32 proposées dans de nombreuses bibliothèques de logiciels. Ceux-ci sont principalement conçus pour les portefeuilles Bitcoin, qui implémentent les adresses d’une manière différente, mais partagent la même implémentation de dérivation de clé que les portefeuilles compatibles BIP-32 d’Ethereum. Utilisez-en un https://github.com/ConsenSys/eth-lightwallet [conçu pour Ethereum], ou adaptez-en un à partir de Bitcoin en ajoutant une bibliothèque d’encodage d’adresses Ethereum.
Il existe également un générateur BIP-32 implémenté sous la forme d’une page Web autonome qui est très utile pour tester et expérimenter avec BIP-32.
|
Warning
|
Le générateur BIP-32 autonome n’est pas un site HTTPS. C’est pour vous rappeler que l’utilisation de cet outil n’est pas sécurisée. C’est uniquement pour tester. Vous ne devez pas utiliser les clés produites par ce site avec des fonds réels. |
Clés publiques et privées étendues
Dans la terminologie BIP-32, les clés peuvent être "étendues". Avec les bonnes opérations mathématiques, ces clés "parentes" étendues peuvent être utilisées pour dériver des clés "enfant", produisant ainsi la hiérarchie des clés et des adresses décrites précédemment. Une clé parent n’a pas besoin d’être au sommet de l’arborescence. peut être choisi n’importe où dans l’arborescence. L’extension d’une clé implique de prendre la clé elle-même et d’y ajouter un code de chaîne spécial. Un code de chaîne est une chaîne binaire de 256 bits qui est mélangé avec chaque clé pour produire des clés enfants.
Si la clé est une clé privée, elle devient une clé privée étendue qui se distingue par le préfixe xprv :
xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8i...
Une clé publique étendue se distingue par le préfixe xpub :
xpub661MyMwAqRbcEnKbXcCqD2GT1di5zQxVqoHPAgHNe8dv5JP8gWmDproS6kFHJnLZd23tWevhdn...
Une caractéristique très utile des portefeuilles HD est la possibilité de dériver les clés publiques enfants des clés publiques parents, sans avoir les clés privées. Cela nous donne deux façons de dériver une clé publique enfant : soit directement à partir de la clé privée enfant, soit à partir de la clé publique parent.
Une clé publique étendue peut donc être utilisée pour dériver toutes les clés publiques (et uniquement les clés publiques) dans cette branche de la structure du portefeuille HD.
Ce raccourci peut être utilisé pour créer des déploiements très sécurisés à clé publique uniquement, où un serveur ou une application possède une copie d’une clé publique étendue, mais aucune clé privée. Ce type de déploiement peut produire un nombre infini de clés publiques et d’adresses Ethereum, mais ne peut pas dépenser l’argent envoyé à ces adresses. Pendant ce temps, sur un autre serveur plus sécurisé, la clé privée étendue peut dériver toutes les clés privées correspondantes pour signer des transactions et dépenser de l’argent.
Une application courante de cette méthode consiste à installer une clé publique étendue sur un serveur Web qui sert une application de commerce électronique. Le serveur Web peut utiliser la fonction de dérivation de clé publique pour créer une nouvelle adresse Ethereum pour chaque transaction (par exemple, pour le panier d’un client) et n’aura aucune clé privée vulnérable au vol. Sans les portefeuilles HD, la seule façon d’y parvenir est de générer des milliers d’adresses Ethereum sur un serveur sécurisé séparé, puis de les précharger sur le serveur de commerce électronique. Cette approche est lourde et nécessite une maintenance constante pour s’assurer que le serveur ne manque pas de clés, d’où la préférence d’utiliser des clés publiques étendues à partir de portefeuilles HD.
Une autre application courante de cette solution est pour le stockage à froid ou pour les portefeuilles matériels. Dans ce scénario, la clé privée étendue peut être stockée dans un portefeuille matériel, tandis que la clé publique étendue peut être conservée en ligne. L’utilisateur peut créer des adresses "de réception" à volonté, tandis que les clés privées sont stockées en toute sécurité hors ligne. Pour dépenser les fonds, l’utilisateur peut utiliser la clé privée étendue dans un client Ethereum de signature hors ligne ou signer des transactions sur le périphérique de portefeuille matériel.
Dérivation de clé enfant renforcée
La possibilité de dériver une branche de clés publiques à partir d’une clé publique étendue, ou xpub, est très utile, mais elle comporte un risque potentiel. L’accès à une xpub ne donne pas accès aux clés privées enfants. Cependant, étant donné que le xpub contient le code de chaîne (utilisé pour dériver les clés publiques enfants de la clé publique parent), si une clé privée enfant est connue ou divulguée d’une manière ou d’une autre, elle peut être utilisée avec le code de chaîne pour dériver tous les autres enfants privés. clés. Une seule clé privée enfant divulguée, associée à un code de chaîne parent, révèle toutes les clés privées de tous les enfants. Pire encore, la clé privée enfant associée à un code de chaîne parent peut être utilisée pour déduire la clé privée parent.
Pour contrer ce risque, les portefeuilles HD utilisent une fonction de dérivation alternative appelée dérivation renforcée, qui "casse" la relation entre la clé publique parent et le code de chaîne enfant. La fonction de dérivation renforcée utilise la clé privée parent pour dériver le code de chaîne enfant, au lieu de la clé publique parent. Cela crée un "pare-feu" dans la séquence parent/enfant, avec un code de chaîne qui ne peut pas être utilisé pour compromettre une clé privée parent ou sœur.
En termes simples, si vous souhaitez utiliser la commodité d’un xpub pour dériver des branches de clés publiques sans vous exposer au risque d’une fuite de code de chaîne, vous devez le dériver d’un parent renforcé, plutôt que d’un parent normal. La meilleure pratique consiste à toujours dériver les enfants de niveau 1 des clés principales par dérivation renforcée, afin d’éviter toute compromission des clés principales.
Numéros d’index pour dérivation normale et durcie
Il est clairement souhaitable de pouvoir dériver plus d’une clé enfant à partir d’une clé parent donnée. Pour gérer cela, un numéro d’index est utilisé. Chaque numéro d’index, lorsqu’il est combiné avec une clé parent à l’aide de la fonction spéciale de dérivation d’enfant, donne une clé enfant différente. Le numéro d’index utilisé dans la fonction de dérivation parent-enfant BIP-32 est un entier de 32 bits. Pour distinguer facilement les clés dérivées via la fonction de dérivation normale (non renforcée) des clés dérivées via la dérivation renforcée, ce numéro d’index est divisé en deux plages. Les numéros d’index entre 0 et 231–1 (0x0 à 0x7FFFFFFF)sont utilisés uniquement pour la dérivation normale. Les numéros d’index entre 231 et 232–1 (0x80000000 à 0xFFFFFFFF)sont utilisés uniquement pour la dérivation renforcée. Ainsi, si l’indice est inférieur à 231, l’enfant est normal, alors que si l’indice est égal ou supérieur à 231, l’enfant est endurci.
Pour faciliter la lecture et l’affichage des numéros d’index, les numéros d’index pour les enfants endurcis sont affichés à partir de zéro, mais avec un symbole prime. La première clé enfant normale est donc affichée sous la forme 0, tandis que la première clé enfant renforcée (index 0x80000000)est affichée sous la forme 0'. Dans l’ordre, alors, la deuxième clé renforcée aurait un index de 0x80000001 et serait affichée comme 1', et ainsi de suite. Lorsque vous voyez un index de portefeuille HD i', cela signifie 231 + i.
Identifiant de clé de portefeuille HD (chemin)
Les clés d’un portefeuille HD sont identifiées à l’aide d’un " chemin", avec chaque niveau de l’arborescence séparé par une barre oblique (/) (voir [hd_path_table]). Les clés privées dérivées de la clé privée principale commencent par m. Les clés publiques dérivées de la clé publique principale commencent par M. Par conséquent, la première clé privée enfant de la clé privée principale est m/0. La première clé publique enfant est M/0. Le deuxième petit-enfant du premier enfant est m/0/1, et ainsi de suite.
L'"ascendance" d’une clé se lit de droite à gauche, jusqu’à atteindre la clé maîtresse dont elle est issue. Par exemple, l’identifiant m/x/y/z décrit la clé qui est le z-ème enfant de la clé m/x/y, qui est le y-ème enfant de la clé m/x, qui est le x-ième enfant de m.
Exemples de chemin de portefeuille .HD
| Chemin HD | Clé décrite |
|---|---|
m/0 |
La première clé privée enfant ( |
m/0/0 |
La clé privée du premier petit-enfant du premier enfant (m/0) |
m/0'/0 |
Le premier petit-enfant normal du premier enfant renforcé (m/0') |
m/1/0 |
La clé privée du premier petit-enfant du deuxième enfant (m/1) |
M/23/17/0/0 |
La clé publique du premier arrière-arrière-petit-enfant du premier arrière-petit-enfant du 18e petit-enfant du 24e enfant |
Naviguer dans l’arborescence du portefeuille HD
La structure arborescente du portefeuille HD est extrêmement flexible. Le revers de la médaille est qu’il permet également une complexité illimitée : chaque clé étendue parent peut avoir 4 milliards d’enfants : 2 milliards d’enfants normaux et 2 milliards d’enfants renforcés. Chacun de ces enfants peut avoir 4 milliards d’enfants supplémentaires, et ainsi de suite. L’arbre peut être aussi profond que vous le souhaitez, avec un nombre potentiellement infini de générations. Avec tout ce potentiel, il peut devenir assez difficile de naviguer dans ces très grands arbres.
Deux BIP offrent un moyen de gérer cette complexité potentielle en créant des normes pour la structure des arborescences de portefeuille HD. BIP-43 propose l’utilisation du premier index enfant renforcé comme identifiant spécial qui signifie le "but" de la structure arborescente. Basé sur BIP-43, un portefeuille HD ne devrait utiliser qu’une seule branche de niveau 1 de l’arborescence, le numéro d’index définissant l’objectif du portefeuille en identifiant la structure et l’espace de noms du reste de l’arborescence. Plus précisément, un portefeuille HD utilisant uniquement la branche m/i'/... est destiné à signifier un objectif spécifique et cet objectif est identifié par le numéro d’index i.
Étendant cette spécification, BIP-44 propose une structure multicompte multidevise signifiée en définissant le numéro de "but" à 44'. Tous les portefeuilles HD suivant la structure BIP-44 sont identifiés par le fait qu’ils n’utilisent qu’une seule branche de l’arbre : m/44'/*.
BIP-44 spécifie la structure comme étant composée de cinq niveaux d’arborescence prédéfinis :
m / but' / type_de_monnaie' / compte' / change / index_adresse
Le premier niveau, but', est toujours réglé sur 44'. Le deuxième niveau, type_de_monnaie', spécifie le type de pièce de cryptomonnaie, permettant des portefeuilles HD multidevises où chaque devise a son propre sous-arbre sous le deuxième niveau. Il existe plusieurs devises définies dans un document standard appelé SLIP0044 ; par exemple, Ethereum vaut m/44'/60', Ethereum Classic vaut m/44'/61', Bitcoin vaut m/44'/0' et Testnet pour tous devises est m/44'/1'.
Le troisième niveau de l’arborescence est compte', qui permet aux utilisateurs de subdiviser leurs portefeuilles en sous-comptes logiques distincts à des fins comptables ou organisationnelles. Par exemple, un portefeuille HD peut contenir deux "comptes" Ethereum : m/44'/60'/0' et m/44'/60'/1'. Chaque compte est la racine de sa propre sous-arborescence.
Parce que BIP-44 a été créé à l’origine pour Bitcoin, il contient une "bizarrerie" qui n’est pas pertinente dans le monde Ethereum. Au quatrième niveau du chemin, change, un portefeuille HD a deux sous-arbres : un pour créer des adresses de réception et un pour créer des adresses de change (retour du change de la transaction). Seul le chemin "réception" est utilisé dans Ethereum, car il n’est pas nécessaire de changer d’adresse comme c’est le cas dans Bitcoin. Notez qu’alors que les niveaux précédents utilisaient une dérivation renforcée, ce niveau utilise une dérivation normale. Cela permet au niveau du compte de l’arborescence d’exporter des clés publiques étendues pour une utilisation dans un environnement non sécurisé. Les adresses utilisables sont dérivées par le portefeuille HD en tant qu’enfants du quatrième niveau, faisant du cinquième niveau de l’arborescence le index_adresse. Par exemple, la troisième adresse de réception des paiements Ethereum dans le compte principal serait M/44'/60'/0'/0/2. [bip44_path_examples] montre quelques exemples supplémentaires.
Exemples de structure de portefeuille .BIP-44 HD
| Chemin HD | Clé décrite |
|---|---|
M/44'/60'/0'/0/2+ |
La troisième clé publique de réception pour le compte Ethereum principal |
M/44'/0'/3'/1/14+ |
La 15ème clé publique d’adresse de change pour le 4ème compte Bitcoin |
m/44'/2'/0'/0/1 |
La deuxième clé privée du compte principal Litecoin, pour la signature des transactions |
Conclusion
Les portefeuilles sont la base de toute application chaîne de blocs destinée aux utilisateurs. Ils permettent aux utilisateurs de gérer des collections de clés et d’adresses. Les portefeuilles permettent également aux utilisateurs de démontrer leur propriété d’ether et d’autoriser les transactions, en appliquant des signatures numériques, comme nous le verrons dans [tx_chapter].