Recherche. Article original
La faille liée au PRNG et à l’IV lors de la prévente
Dans le cadre de nos recherches sur l’aléatoire faible : voir la présentation intitulée « L’aléatoire faible dans les portefeuilles cryptographiques ».
Le générateur de portefeuilles de la prévente de 2014 s’appuyait sur la fonction Math.random du navigateur dans des cas où il n’aurait pas dû. Notre étude examine si cette prévisibilité ouvre une voie de récupération pour les portefeuilles de prévente qui, sans cela, seraient bloqués.
Il s’agit d’une recherche originale menée par KeychainX, que nous présentons sous la forme d’une étude ouverte plutôt que d’un exploit abouti. Le générateur de portefeuilles utilisé lors de la prévente d’Ethereum en 2014 s’appuyait sur la fonction aléatoire du navigateur — Math.random() — pour générer ses paramètres de chiffrement. Lorsque le processus aléatoire est prévisible, il peut être possible de récupérer les données. Voici ce que nous avons découvert.
Contexte : comment le portefeuille de prévente a été créé
Un portefeuille de prévente est un keystore JSON qui chiffre votre clé privée à l’aide de votre mot de passe, en utilisant les algorithmes PBKDF2 et AES. Le chiffrement nécessite un vecteur d’initialisation (IV) ainsi que d’autres valeurs propres à chaque portefeuille ; celles-ci ont été générées dans le navigateur au moment de la création. Un IV correctement aléatoire n’est pas en soi un secret — mais c’est dans la manière dont le générateur a obtenu ses données aléatoires que réside la faille intéressante, car une partie de ce processus s’appuyait sur Math.random() plutôt que sur une source cryptographique.
Pourquoi Math.random n’est pas fiable !
Math.random() est un générateur pseudo-aléatoire dont la graine est dérivée d’un état limité, souvent lié au temps — il n’a jamais été conçu pour la cryptographie. Si une valeur censée être imprévisible est en réalité produite par Math.random() à partir d’une graine dérivée d’un élément borné, alors l’ensemble des valeurs possibles est suffisamment restreint pour être énuméré. C’est le même principe qui sous-tend Randstorm et MilkSad : l’algorithme est correct, mais la graine est prévisible.
Le problème « undefinedundefined » de Firefox
Notre principale découverte concerne une particularité propre à certains navigateurs. Le générateur intégrait les coordonnées des mouvements de souris comme source d’entropie, mais dans Firefox, dans certaines conditions, ces coordonnées étaient renvoyées sous la forme de la chaîne littérale « undefinedundefined », n’apportant ainsi aucune entropie réelle. Lorsque cela se produisait, l’aléatoire inconnu se réduisait à la source restante : un horodatage d’une milliseconde. Et cet horodatage est limité, car un portefeuille de prévente a été créé dans un intervalle de temps proche du moment où sa transaction de financement a été enregistrée sur la chaîne Bitcoin.
Ce que cela signifie pour la reprise
Cela implique une réduction spectaculaire de l’espace de recherche pour les portefeuilles concernés. Si l’entropie se réduit effectivement à un horodatage d’une milliseconde, limité par les délais de financement sur la chaîne, l’espace des candidats devient énumérable, et une recherche structurée — une recherche par faisceau sur la fenêtre temporelle plausible, reconstruisant l’état du générateur — pourrait reproduire les valeurs nécessaires pour faciliter le décryptage. Nous avons présenté cette méthodologie ; elle est prometteuse pour un sous-ensemble spécifique de portefeuilles créés par Firefox et ne constitue pas une « clé passe-partout » universelle pour les préventes. La plupart des récupérations de préventes se résument toujours aux problèmes d’encodage des mots de passe que nous documentons séparément.
Pourquoi est-ce important pour les cryptomonnaies perdues ?
Les portefeuilles issus de la prévente de 2014 comptent parmi les actifs inactifs les plus précieux de tout l’univers des cryptomonnaies, et une part non négligeable d’entre eux reste bloquée car leurs propriétaires ne sont plus en mesure de les déchiffrer. Toute méthode crédible permettant de réduire l’espace de recherche, ne serait-ce que pour un sous-ensemble de ces portefeuilles, mérite d’être explorée, car les enjeux par portefeuille sont considérables. C’est pourquoi nous prenons très au sérieux l’approche PRNG malgré son champ d’application restreint : pour les portefeuilles spécifiques où un effondrement de l’entropie s’est produit, la différence entre une recherche illimitée et une recherche limitée équivaut à la différence entre une situation désespérée et une situation récupérable. Les recherches qui élargissent l’ensemble des portefeuilles récupérables, même modestement, revêtent ici une valeur inestimable.
La méthodologie en détail
Concrètement, l’approche consiste en une reconstruction bornée. Tout d’abord, on détermine la fenêtre de financement à partir de l’historique on-chain du portefeuille, qui englobe l’heure de création. Ensuite, pour chaque milliseconde candidate de cette fenêtre, on reconstitue l’état du générateur qui aurait résulté de l’entropie réduite, puis on en déduit les paramètres de chiffrement qu’il aurait produits. Enfin, on teste ces paramètres sur le keystore chiffré, en retenant ou en écartant les candidats selon que la dérivation est cohérente en interne. Une recherche par faisceau permet de conserver les états candidats les plus prometteurs plutôt que d’épuiser aveuglément toutes les possibilités. Il s’agit d’un travail minutieux et spécifique au portefeuille — et non d’une attaque par lots —, ce qui est approprié étant donné qu’il ne s’applique que lorsque les conditions spécifiques sont réunies.
Un statut sincère
Nous présentons cela comme un sujet de recherche en cours. Toutes les conditions doivent être réunies — un navigateur spécifique, un effondrement d’entropie particulier et une durée de financement bien délimitée — et chaque portefeuille candidat doit être évalué individuellement. Nous publions ces informations car il s’agit d’un angle d’approche authentique et peu exploré concernant certains des portefeuilles inactifs les plus précieux qui existent, et parce que faire preuve de transparence au sujet d’une méthode prometteuse mais inachevée est plus utile aux propriétaires que de faire des promesses exagérées ou de garder le silence.
À quels portefeuilles cela pourrait-il s’appliquer ?
Pour être précis quant au champ d’application : les candidats les plus probables sont les portefeuilles de prévente créés dans Firefox pendant la période où la source d’entropie des coordonnées de la souris a connu une défaillance, et pour lesquels une transaction de financement permet de déterminer avec précision l’heure de création. Les portefeuilles créés dans d’autres navigateurs, ou pour lesquels la source d’entropie a fonctionné comme prévu, ne présentent pas ce problème et ne sont pas concernés par cette méthode. C’est pourquoi nous évaluons chaque portefeuille individuellement plutôt que de promettre une solution universelle : un même fichier JSON de prévente peut être récupérable via la méthode d’encodage, via cette méthode du générateur de nombres aléatoires pseudo-aléatoires (PRNG), ou via aucune des deux, et seule une inspection du portefeuille en question et de son contexte sur la chaîne nous permet de déterminer laquelle s’applique.
Notre documentation
Cette analyse est le fruit des travaux de KeychainX, menés dans le cadre d’une étude sur les portefeuilles de prévente inactifs (voir notre étude sur les portefeuilles ETH de prévente inactifs ) et de nos travaux plus généraux sur la « randomité faible », menés en collaboration avec Randstorm et MilkSad. Nous la datons ici afin de consigner cette découverte, et nous invitons les chercheurs qui étudient ce même générateur à collaborer avec nous.
Foire aux questions
Est-ce un moyen d’ouvrir n’importe quel portefeuille de prévente ?
Non. Il s’agit d’une piste de recherche prometteuse pour un sous-ensemble spécifique de portefeuilles — ceux créés dans Firefox où l’entropie s’est effondrée — et non d’une méthode universelle. La plupart des récupérations lors des préventes sont plutôt dues à des problèmes de codage des mots de passe.
En quoi consiste ce résultat « indéterminé » ?
Dans Firefox, la source d’entropie basée sur les coordonnées de la souris du générateur pourrait renvoyer la chaîne littérale « undefinedundefined », n’apportant ainsi aucun caractère aléatoire — ce qui ramène l’entropie inconnue à un horodatage limité à une milliseconde.
Pourquoi le délai de financement est-il important ?
Un portefeuille de prévente a été créé à peu près au moment où la transaction de financement en bitcoins a eu lieu ; ainsi, le timing sur la chaîne délimite la fenêtre temporelle dans laquelle l’entropie peut se réduire, ce qui rend cet espace énumérable.
S’agit-il d’une étude achevée ?
Non — nous la présentons comme une étude ouverte, dotée d’une méthodologie bien définie (une analyse par faisceaux sur une fenêtre temporelle), applicable à un sous-ensemble de portefeuilles et évaluée au cas par cas.
Pourriez-vous évaluer mon portefeuille de prévente ?
Oui. Nous vérifions si la méthode de chiffrement par mot de passe ou celle utilisant un générateur de nombres aléatoires pseudo-aléatoires (ou aucune des deux) s’applique à votre portefeuille en particulier.
Vous avez un portefeuille de prévente qui ne veut pas céder ?
Nous déterminons si le problème provient d’un défaut de codage ou s’il est lié à ce problème de PRNG dans votre portefeuille en particulier. Dites-nous de quel portefeuille il s’agit : nous vous fournirons une évaluation honnête dans les 24 heures.