Aller au contenu
Financial Context Wiki

Chemins de dérivation des portefeuilles : normes, découverte et récupération

Apprenez comment les chemins de dérivation de portefeuille sélectionnent les clés enfants déterministes, comment les niveaux à dérivation renforcée et les conventions de compte diffèrent, et comment vérifier les chemins lors de la récupération.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Un chemin de dérivation de portefeuille est une séquence ordonnée d’indices d’enfants qui indique à un algorithme de dérivation de clé déterministe quel nœud sélectionner dans un arbre de clés. Dans la notation courante BIP-32, m/84'/0'/0'/0/7 commence au nœud privé maître m et traverse cinq enfants. L’apostrophe marque un enfant BIP-32 durci. Un chemin est une métadonnée de routage : ce n’est pas une clé privée, cela ne chiffre pas une graine, cela n’identifie pas lui-même un solde de blockchain, et cela ne peut rien récupérer sans le matériel racine correct et l’algorithme de dérivation.

Pour les portefeuilles de type BIP-44, le modèle est m / purpose' / coin_type' / account' / change / address_index. Les niveaux ont des significations convenues, pas des étiquettes arbitraires. purpose sélectionne une convention de portefeuille, coin_type sépare les espaces de noms d’actifs enregistrés, account sépare les comptes logiques, change distingue normalement les adresses de réception externes (0) des adresses de retour internes (1), et address_index sélectionne une feuille. BIP-44 renforce les trois premiers niveaux et laisse les deux derniers non renforcés afin qu’une clé publique étendue de compte puisse dériver des adresses de réception et de retour sans posséder de clés privées.

Le même mnémonique peut conduire à de nombreux ensembles d’adresses valides mais non liés. Pour Bitcoin, les chemins à clé unique courants incluent m/44'/0'/account'/change/index pour P2PKH, m/49'/0'/account'/change/index pour P2WPKH imbriqué dans P2SH, m/84'/0'/account'/change/index pour P2WPKH SegWit natif, et m/86'/0'/account'/change/index pour Taproot P2TR à clé unique. Un portefeuille doit également connaître la sortie ou la construction du script ; un chemin à lui seul n’est pas une politique de portefeuille Bitcoin complète.

D’autres écosystèmes réutilisent des parties de cette notation sans garantir une sémantique identique. L’Ether est enregistré comme type de monnaie BIP-44 60, et m/44'/60'/0'/0/index est une convention courante de compte détenu par un tiers, mais les implémentations de portefeuilles ont utilisé plusieurs dispositions de comptes. La même clé EVM peut produire la même adresse de compte sur plusieurs réseaux EVM même si les soldes et les historiques de transactions sont spécifiques à la chaîne. Les clés BLS des validateurs Ethereum utilisent ERC-2333 et ERC-2334 plutôt que BIP-32 ; leur chemin m/12381/3600/account/use n’a pas d’apostrophes et n’est pas interopérable avec un arbre BIP-32. La récupération nécessite donc l’implémentation exacte, la courbe, la graine ou le mot de passe, la convention de chemin, le réseau et la construction de l’adresse, et non une chaîne ayant simplement l’apparence d’être correcte.

Identifier et vérifier un chemin de dérivation

1. Déterminer le matériel racine et l’algorithme de dérivation

Inventoriez le format mnémonique, la liste de mots, la phrase de passe optionnelle, la graine brute ou la clé étendue, ainsi que l’implémentation logicielle ou matérielle qui a créé le portefeuille. BIP-39 convertit 128 en 256 bits d’entropie en un mnémonique et dérive une graine 512-bit à partir de ce mnémonique plus la phrase de passe exacte ; chaque phrase de passe produit une graine syntaxiquement valide mais différente. BIP-32 dérive ensuite des clés étendues secp256k1 à partir d’une graine. D’autres familles de portefeuilles peuvent utiliser différents schémas mnémoniques, courbes, fonctions de dérivation de clé, ou règles de clé maître, donc des mots correspondants ne prouvent pas une racine correspondante.

2. Identifier la norme, le réseau et le rôle de la clé

Déterminez si la cible est une clé de paiement Bitcoin, un compte détenu extérieurement EVM, une clé de validateur, un signataire multisig, un administrateur de contrat ou une autre autorité. Enregistrez la chaîne et le réseau, la norme et la version applicables, la courbe de clé, le type de sortie ou d’adresse, et l’application du portefeuille. Un enregistrement de type de monnaie SLIP-0044 attribue un espace de noms ; il ne prouve pas que tous les portefeuilles pour cet actif suivent BIP-44, qu’un projet est approuvé, ou qu’une autre chaîne ne peut pas dériver la même clé ailleurs.

3. Interpréter précisément chaque composant du chemin

Traitez / comme une limite parent-enfant et conservez chaque indice, profondeur et marqueur de durcissement. Sous BIP-32, les enfants normaux utilisent les indices 0 à 2^31 - 1 ; les enfants durcis utilisent 2^31 à 2^32 - 1, généralement écrits avec ', h ou H. Ainsi, 7' encode le numéro de l’enfant 2^31 + 7, et non l’enfant ordinaire 7. Confirmez comment une interface d’importation représente la racine, si elle accepte un chemin complet ou un suffixe relatif, et si une clé étendue exportée se situe déjà en dessous d’une partie de ce chemin.

4. Relier le chemin à la sémantique de l’adresse ou de la sortie

Pour les portefeuilles de la famille BIP-44 Bitcoin, confirmez les purpose, coin_type, account, change et address_index, puis confirmez de manière indépendante le type de script et le réseau prévus. BIP-49, BIP-84 et BIP-86 utilisent délibérément des valeurs de but différentes afin que des types de sortie incompatibles n’apparaissent pas silencieusement dans un compte. Pour les portefeuilles multisig ou à descripteur, conservez chaque origine de clé, empreinte principale, suffixe de dérivation, seuil, ordre des clés, construction du script et somme de contrôle ; un chemin ne peut pas reconstruire la politique complète.

5. Reproduire la découverte des comptes et des adresses

Ne déduisez pas une perte à partir d’un seul compte par défaut vide. La découverte BIP-44 vérifie les comptes dans l’ordre et scanne la chaîne externe, en utilisant une limite de décalage d’adresses de 20 adresses consécutives non utilisées. Les portefeuilles qui ont créé des adresses au-delà de cette limite, utilisé des branches internes de manière inhabituelle, sauté des comptes ou appliqué une disposition propriétaire peuvent ne pas être trouvés par une analyse par défaut. Recherchez uniquement avec des données de surveillance fiables ou une dérivation hors ligne, fixez des limites explicites, documentez chaque branche recherchée et évitez de téléverser une phrase mnémonique ou une clé privée étendue sur un site web.

6. Vérifier l’identité du portefeuille avant de se fier au solde

Comparez l’empreinte principale, la clé publique étendue au niveau du compte lorsque cela est approprié, le chemin d’origine complet et plusieurs adresses de réception et de changement précédemment enregistrées. Pour Bitcoin, dérivez les scripts de sortie attendus ou le descripteur et interrogez le réseau correct pour l’historique des transactions, y compris les sorties dépensées. Pour les chaînes basées sur les comptes, vérifiez le chainId exact, l’adresse, les contrats de jetons et l’activité historique. Un solde vide est une preuve faible : l’adresse peut être erronée, le réseau ou l’index peut différer, ou les actifs peuvent déjà avoir été déplacés.

7. Récupérer ou migrer selon un processus contrôlé

Utilisez un logiciel vérifié et compatible dans un environnement de confiance ; privilégiez l’importation d’un descripteur en lecture seule ou de la clé publique du compte pour la découverte avant d’exposer le matériel de signature. Testez la signature et la récupération avec un compte isolé ou une petite transaction, puis réconciliez les adresses dérivées, l’historique on-chain, la propriété des sorties, les frais et l’état final. Si des secrets ont été saisis dans un outil de récupération non fiable, considérez-les comme compromis et migrez tous les actifs, rôles de contrat, approbations, tâches de validateur et autorités de récupération vers une nouvelle racine plutôt que de continuer à utiliser le portefeuille récupéré.

Exemples chiffrés

Interprétation d’un chemin Bitcoin à dérivation renforcée

Considérons m/84'/0'/2'/1/17. Les champs indiquent le purpose SegWit natif 84', le type de monnaie Bitcoin 0', le compte 2', la branche interne ou de monnaie 1 et l’indice d’adresse 17. Comme les indices renforcés BIP-32 ajoutent 2^31 = 2,147,483,648, leurs numéros enfants sérialisés sont 84' = 2,147,483,732, 0' = 2,147,483,648 et 2' = 2,147,483,650. Les deux derniers restent les indices normaux 1 et 17 ; omettre une apostrophe sélectionne un autre sous-arbre, pas une notation équivalente.

Un écart d’adresses qui masque une adresse utilisée

Supposons que la branche externe ait utilisé les adresses d’indice 0 et 5, puis que le portefeuille parcoure 6 à 25 et trouve 20 adresses consécutives inutilisées. Selon la règle d’écart BIP-44, la découverte s’arrête à 25 ; l’adresse utilisée à 26 se situe donc après la condition d’arrêt et est omise. Étendre le parcours jusqu’à une borne explicite et documentée peut la trouver, mais la cause est le portefeuille source qui a créé une adresse au-delà de l’écart standard sans activité intermédiaire.

Calcul d’une recherche de récupération bornée

Un relevé de récupération ne précise pas laquelle des 4 familles de purpose Bitcoin (44', 49', 84' et 86') a été utilisée, ni lequel des 3 comptes, 2 branches et premiers 20 indices. La recherche initiale comprend 4 × 3 × 2 × 20 = 480 feuilles candidates. Trouver une adresse connue identifie un chemin candidat, pas nécessairement tout le portefeuille : il faut encore vérifier la monnaie, les indices suivants, les autres comptes, le descripteur et l’historique. Expliciter les dimensions rend la récupération reproductible et évite un tâtonnement sans borne.

Pourquoi une xpub de compte n’est pas une donnée publique ordinaire

Pour une clé enfant BIP-32 non renforcée, les scalaires privés suivent child = parent + tweak (mod n). Dans un exemple simplifié modulo 101, si les données de dérivation exposées par la clé publique étendue de compte fixent tweak = 37 et que le scalaire privé enfant 12 fuit, alors parent = 12 - 37 mod 101 = 76. Le véritable BIP-32 emploie l’ordre du groupe secp256k1 et des valeurs HMAC, mais la conséquence algébrique est identique : une xpub parente et une clé privée descendante non renforcée correspondante peuvent révéler la clé privée étendue parente et son sous-arbre. Les frontières de compte renforcées limitent ce défaut.

Risques et défauts de vérification

  • Phrase mnémonique ou phrase secrète erronée : un seul mot, son ordre, la normalisation Unicode ou une phrase secrète différente produit une autre racine qui peut sembler valide.
  • Schéma de dérivation erroné : appliquer BIP-32 à un portefeuille ayant utilisé un autre schéma mnémonique, une autre courbe, KDF ou méthode de clé maîtresse dérive des clés sans rapport.
  • Réseau ou type de monnaie erroné : une racine correcte dans un autre espace de noms peut produire des adresses plausibles alors que la chaîne visée reste inexplorée.
  • Purpose ou script erroné : confondre 44', 49', 84' ou 86' peut omettre la classe de sortie Bitcoin qui contient réellement les fonds.
  • Marqueur de dérivation renforcée absent : 7, 7', 7h et 7H peuvent être interprétés autrement ou refusés ; les clés enfants renforcées et normales ne sont pas interchangeables.
  • Indice de compte erroné : ne vérifier que le compte 0' peut omettre des fonds ou pouvoirs détenus dans des comptes logiques ultérieurs.
  • Confusion entre branche externe et branche de monnaie : ne parcourir que la branche 0 peut omettre les sorties de monnaie de la branche 1 ou une structure propre au portefeuille.
  • Indice d’adresse erroné : reconnaître la première adresse ne prouve pas que les indices ultérieurs, omis ou les adresses importées ont été couverts.
  • Échec dû à l’écart d’adresses : 20 adresses externes consécutives inutilisées peuvent arrêter le parcours BIP-44 avant une utilisation ultérieure non conforme.
  • Compte sauté : la découverte séquentielle peut s’arrêter sur un compte inutilisé et ne pas atteindre un compte créé après lui.
  • Politique Bitcoin incomplète : sans descripteur, scripts, seuil, ordre des clés, empreintes ou somme de contrôle, un chemin peut ne pas reconstruire les sorties financées.
  • Convention propre au portefeuille : une application peut utiliser des structures anciennes, propriétaires ou de migration qu’un outil générique n’énumère pas.
  • Fuite de confidentialité de la clé publique étendue : une xpub peut révéler des groupes d’adresses, l’historique, les soldes et de futurs descendants non renforcés.
  • Exposition excessive de la clé privée étendue : importer une xprv peut exposer tout un sous-arbre, et non la seule feuille nécessaire à une opération.
  • Compromission de la clé parente BIP-32 : une xpub parente associée à une clé privée enfant non renforcée correspondante peut révéler la clé privée étendue parente et son sous-arbre.
  • Fausse confiance dans le format d’adresse : une adresse syntaxiquement valide ne prouve ni la seed, ni le chemin, le réseau, le script ou la propriété attendus.
  • Confusion entre chaînes partageant la même adresse : une clé EVM peut produire la même adresse sur plusieurs réseaux, mais soldes, nonce, tokens et risques restent distincts.
  • Logiciel de récupération malveillant : site, extension, partage d’écran, surveillance du presse-papiers, enregistreur ou faux appareil peuvent capter le secret racine.
  • Confusion entre importation et sweep : l’importation maintient l’ancienne autorité ; le sweep ou la migration crée une transaction dont il faut contrôler les frais et la destination.
  • Récupération incomplète : trouver un solde sans vérifier signatures, monnaie, contrats de tokens, rôles, approbations, clés de validateurs et sauvegardes peut laisser des actifs cachés ou exposés.

Idées reçues

Le chemin de dérivation est-il un mot de passe ou un secret ?

Non. Un chemin décrit normalement une structure publique et doit être conservé en tant que métadonnées de récupération. Il ne remplace pas le mnémonique, la phrase secrète, la graine, la clé privée ou la politique du portefeuille. Publier un chemin peut révéler des informations organisationnelles, mais la possession du chemin seul ne confère pas l’autorité de signature.

La même phrase mnémonique restaure-t-elle toujours automatiquement le même portefeuille ?

Non. Le résultat dépend également du schéma mnémonique, de la phrase secrète exacte, du traitement de la graine, de l’algorithme de dérivation, du chemin, de la courbe, du réseau et de la construction de l’adresse ou du script. Le logiciel de portefeuille peut choisir des valeurs par défaut différentes même s’il accepte les mêmes mots.

Le type de monnaie empêche-t-il d’utiliser une clé sur une autre chaîne ?

Non. Le type de monnaie est un espace de noms de dérivation et une convention de compatibilité, pas une autorisation de protocole. Le logiciel peut dériver ou réutiliser une clé ailleurs, et les réseaux EVM exposent couramment la même adresse de compte pour la même clé privée.

Un compte récupéré sans solde prouve-t-il que les actifs ont disparu ?

Non. Cela ne prouve que les adresses particulières et le réseau interrogé actuellement ne montrent aucun solde détecté. Des chemins, comptes, branches, types de scripts, limites de découverte, indexation des jetons ou sélection de réseau incorrects peuvent tous masquer l’historique prévu.

Un outil de récupération peut-il tester en toute sécurité tous les chemins possibles ?

Non. L’espace de recherche peut être vaste, les conventions de portefeuille ne sont pas entièrement universelles, et exposer un secret racine à un outil non fiable constitue en soi un événement de perte. Utilisez la provenance, les empreintes et adresses enregistrées, la découverte hors ligne limitée et les logiciels vérifiés pour restreindre la recherche.

Sujets liés

Sources

Navigation

Rechercher dans le wiki...