Recherche. Dérivation de clés
Évolution de la clé parent BIP32 non sécurisée
Une propriété peu connue du protocole BIP32 implique qu’une adresse xpub associée à une seule clé privée « enfant » non sécurisée peut permettre de révéler la clé « parent » — ce qui constitue un risque réel, mais aussi, pour le propriétaire, un moyen de récupération.
Les portefeuilles déterministes hiérarchiques BIP32 génèrent tout un arbre de clés à partir d’une seule graine. La plupart des gens savent que cet arbre se développe de haut en bas, des parents vers les enfants. Peu savent cependant que, dans certaines conditions, il est possible de remonter cet arbre. Cette page présente la propriété d’escalade non renforcée : ce qu’elle est, pourquoi elle est importante pour la sécurité et comment elle permet de récupérer un portefeuille.
Comment fonctionne la dérivation HD ?
Dans un portefeuille BIP32, chaque clé génère des clés filles via une fonction à sens unique combinant la clé mère avec un code de chaîne et un index. Il existe deux variantes : la dérivation sécurisée (indices supérieurs à 2³¹), qui nécessite la clé privée mère, et la dérivation non sécurisée, qui peut être effectuée à partir de la clé publique mère. C’est cette dérivation non renforcée qui rend l’xpub utile : un serveur en lecture seule peut générer de nouvelles adresses de réception sans jamais détenir de clé privée.
La propriété d’escalade
Voici le point crucial. Dans le cas d’une dérivation non renforcée, la relation entre une clé privée « enfant » et sa clé « parent » est réversible si l’on connaît également la clé publique du parent (l’xpub). Concrètement : à partir de l’xpub et d’une seule clé privée « enfant » non renforcée, il est possible de calculer la clé privée du parent — et, à partir de là, l’ensemble de la sous-arborescence. La divulgation d’une seule clé « enfant » associée à une xpub publique entraîne la compromission totale de cette branche.
Pourquoi cela représente-t-il un risque pour la sécurité ?
Cela transforme deux éléments apparemment sûrs en un duo dangereux. Partager une xpub à des fins comptables ou de surveillance semble inoffensif, et exposer une seule clé privée enfant donne l’impression d’une perte limitée à une seule adresse. Mais combinées, ce n’est pas le cas : un attaquant en possession de la xpub qui obtient ne serait-ce qu’une seule clé enfant non sécurisée peut remonter jusqu’à la clé parent et vider toutes les adresses de ce compte. Il s’agit d’un classic où deux expositions mineures prises individuellement se combinent pour aboutir à une compromission totale, et c’est la raison pour laquelle la dérivation sécurisée existe aux limites des comptes.
En quoi cela facilite-t-il la récupération de vos clés ?
Ce même élément constitue un véritable atout lorsque vous, en tant que propriétaire, tentez de récupérer vos propres fonds. Si vous disposez de l’xpub du compte et d’une seule clé privée enfant non sécurisée — par exemple une clé exportée, ou la clé d’une adresse que vous possédez encore —, la clé parent et toute la branche peuvent être reconstituées. Un ensemble partiel et fragmentaire de clés, qui semble inutile, peut, par un processus d’escalade, permettre de reconstituer un portefeuille entier. Cela transforme la situation « Je n’ai qu’une ancienne clé privée et un xpub », qui semblait être une impasse, en une récupération complète.
Dans quels cas cela s’applique-t-il ?
Les conditions sont précises : la dérivation doit être non renforcée (les comptes enfants renforcés ne révèlent aucune information sur le compte parent), il faut disposer du xpub correct pour le compte parent, ainsi que d’une véritable clé privée d’un compte enfant lui étant directement subordonné. De nombreux portefeuilles utilisent une dérivation renforcée au niveau du compte précisément pour empêcher cela, ce qui fait que cette méthode ne s’applique pas partout — mais lorsqu’un portefeuille utilise une dérivation non renforcée, il s’agit d’une voie puissante et souvent négligée.
Évaluation d’un cas
Pour déterminer si l’escalation s’applique, il faut identifier le schéma de dérivation du portefeuille — quel logiciel l’a créé, et si la branche en question a été renforcée ou non — puis confirmer que le xpub correspond bien à la clé parente de la clé enfant que vous détenez. Comme les calculs mathématiques sont exacts, une fois ces éléments vérifiés, la reconstruction est déterministe : soit la clé parente s’affiche correctement, soit les entrées ne correspondent pas, sans aucune marge d’interprétation.
Se protéger
La leçon à retenir en matière de sécurité est simple : considérez votre xpub comme une donnée sensible, et non comme une information publique, et ne divulguez jamais la clé privée d’un enfant spécifique tant que l’xpub correspondant est connu de quiconque. Si vous devez partager un xpub à des fins de surveillance uniquement, sachez que la fuite d’une seule clé enfant non sécurisée associée à ce xpub suffit à compromettre le compte. Dans la mesure du possible, privilégiez les portefeuilles qui assurent une sécurité au niveau des limites du compte, de sorte que même la fuite d’un xpub et d’une clé enfant ne puisse pas être combinée pour permettre une escalade des privilèges.
Un exemple concret
Imaginez un portefeuille qui aurait fourni à un comptable un xpub en lecture seule pour suivre les paiements entrants, et qui aurait, séparément, exporté il y a plusieurs années la clé privée d’une adresse afin de récupérer un petit solde. Pris isolément, aucun de ces éléments ne semblait avoir d’importance : un xpub ne révèle aucune clé, et la clé d’une adresse ne représente qu’un risque pour cette adresse-là. Mais si cette adresse était une adresse « enfant » non sécurisée issue du xpub partagé, les deux éléments combinés permettent de reconstituer la clé « parent » et toutes les adresses qui en dépendent. Le même raisonnement qui permettrait à un attaquant d’exploiter cette association est celui qui permet au propriétaire légitime, détenant les deux éléments après avoir perdu son portefeuille principal, de se rétablir et de récupérer tout ce qui se trouve dans cette branche. C’est la démonstration la plus claire de la raison pour laquelle cette propriété est à la fois un danger et une bouée de sauvetage.
Notre documentation
KeychainX a eu recours à une élévation de privilèges non sécurisée pour reconstituer des portefeuilles à partir de fragments de clés lors de récupérations réelles, et nous documentons cette technique ici car elle est tout aussi sous-estimée en tant qu’outil de récupération qu’en tant que risque. Elle s’inscrit dans le cadre de nos travaux plus généraux sur la dérivation de clés, notamment l’analyse forensic de la dérivation sur Trezor. Si vous disposez d’un xpub et d’une clé privée isolée, ne partez pas du principe qu’ils sont inutiles.
Foire aux questions
De quel matériel essentiel avez-vous besoin ?
Idéalement, la clé publique (xpub) du compte ainsi qu’au moins une clé privée enfant non renforcée qui lui est subordonnée. À partir de ces deux éléments, lorsque la dérivation n’est pas renforcée, il est possible de reconstituer la clé parente ainsi que l’ensemble de la branche.
Qu’est-ce que l’escalade non sécurisée selon le protocole BIP32 ?
Propriété selon laquelle, à partir d’une clé publique étendue parente (xpub) et d’une clé privée fille quelconque non renforcée, il est possible de calculer la clé privée parente — et donc l’ensemble de la branche.
Est-ce que je peux communiquer mon xpub en toute sécurité ?
Pas tout à fait. En soi, une xpub est en lecture seule, mais associée à une seule clé privée enfant non renforcée qui aurait fuité, elle expose la clé parent et toutes les adresses de ce compte. Considérez la xpub comme une information sensible.
En quoi cela m’aide-t-il à récupérer mon portefeuille ?
Si vous possédez la clé xpub et ne serait-ce qu’une seule clé privée enfant non renforcée, la clé parente et l’ensemble de la branche peuvent être reconstitués, ce qui permet de récupérer intégralement le matériel de clé à partir de fragments.
Est-ce que cela s’applique toujours ?
Non. Cela nécessite une dérivation non sécurisée et le fichier xpub correspondant. Les portefeuilles qui appliquent la sécurisation au niveau du compte bloquent cette opération ; cela ne s’applique donc qu’à certaines configurations spécifiques.
Combien coûte la remise en état ?
Rémunération au résultat : un pourcentage de la valeur récupérée uniquement si nous retrouvons le portefeuille, et aucun paiement initial.
Posséder un fichier xpub et une clé privée isolée ?
Ces fragments peuvent permettre de reconstituer l’intégralité d’un portefeuille grâce à une procédure d’escalade. Indiquez-nous de quel matériel de clé vous disposez — nous vous fournirons une évaluation honnête dans les 24 heures.