Dérivation renforcée

Chaque nœud d'un arbre BIP-32 peut produire 4 294 967 296 enfants, et la moitié supérieure de cette plage se comporte différemment. Les indices à partir de 2 147 483 648 sont renforcés, notés avec une apostrophe ou la lettre h, et aucune clé publique ne peut les dériver. Cette restriction est la fonctionnalité, pas une lacune.

Comment cela fonctionne

La dérivation renforcée et la dérivation normale diffèrent par une seule entrée dans le même hachage. Les deux intègrent le code de chaîne du parent et un indice d'enfant dans HMAC-SHA512. La dérivation normale ajoute la clé publique du parent, que quiconque détient la clé publique étendue possède déjà. La dérivation renforcée ajoute à la place la clé privée du parent, précédée d'un octet nul, de sorte que le calcul ne peut pas être effectué sans le secret.

La raison est une faiblesse précise que le BIP-32 expose dans ses notes de sécurité : la connaissance d'une clé publique étendue parente et de n'importe quelle clé privée non renforcée qui en descend équivaut à connaître la clé privée étendue parente, et donc toutes les clés situées en dessous de ce point. L'arithmétique qui la sous-tend est simple. Une clé privée d'enfant normale est égale à la clé du parent plus une valeur calculée à partir d'informations publiques, donc soustraire cette valeur permet de retrouver le parent.

Les indices renforcés ferment la voie. Il n'existe pas de fonction de dérivation publique pour eux, donc une clé publique étendue s'arrête net à la frontière. Un xpub divulgué pour un compte expose l'historique de ce compte et rien au-dessus ni à côté.

Où cela se voit

Le renforcement apparaît sous forme d'apostrophes dans un chemin de dérivation, et l'endroit où elles se placent est une décision de conception délibérée.

Le chemin natif SegWit standard est m/84'/0'/0'/0/0. Les trois premiers niveaux, objectif, type de cryptomonnaie et compte, sont renforcés. Les deux derniers, chaîne et indice d'adresse, ne le sont pas. Cette séparation est exactement ce qui rend un portefeuille en lecture seule utilisable : une clé publique étendue de compte peut générer toutes les adresses de réception et de monnaie situées en dessous d'elle, tandis qu'un attaquant qui obtient ce même xpub ne peut pas remonter vers la clé maîtresse ni passer latéralement dans m/84'/0'/1'.

La notation varie sans rien changer. Le BIP-32 écrit 0', de nombreux outils acceptent 0h, et Bitcoin Core écrit h dans les descripteurs qu'il exporte parce qu'une apostrophe doit être échappée dans du JSON. Un chemin copié de Sparrow vers Core revient réécrit sous la forme h, ce qui alarme les gens la première fois et est purement cosmétique.

La règle pratique est courte. Renforcez chaque niveau jusqu'au compte, laissez les deux niveaux en dessous non renforcés pour que les outils en lecture seule continuent de fonctionner, et considérez tout logiciel proposant d'exporter une seule clé privée d'enfant non renforcée comme un danger plutôt qu'une commodité, car cette exportation combinée à votre xpub représente toute la branche.

Dérivation renforcée vs phrase secrète

La dérivation renforcée est automatique ; une phrase secrète BIP-39 est un secret que vous choisissez. On les regroupe comme des moyens de renforcer un portefeuille et elles répondent à des problèmes sans rapport. Le renforcement protège un arbre contre une clé publique étendue qui s'est échappée, et tout portefeuille standard l'applique déjà sans vous le demander. Une phrase secrète est une entrée supplémentaire mélangée à la phrase de récupération avant même que l'arbre soit construit, ce qui produit un portefeuille totalement distinct à partir des mêmes douze ou vingt-quatre mots. Oubliez la phrase secrète et les bitcoins sont inaccessibles, car rien ne l'enregistre nulle part. Oubliez le renforcement et rien ne se passe, car vous n'avez jamais été celui qui en décidait.