thejournalofsierraleonestudies.com

Bitcoins : des clés cryptographiques des wallets de Coldcard trop faciles à reconstituer

Une erreur de programmation aurait empêché certains wallets du fabricant Coldcard d’utiliser leur générateur matériel de nombres aléatoires pour créer des « seeds », ces phrases de récupération de 12 ou 24 mots...

Une erreur de programmation aurait empêché certains wallets du fabricant Coldcard d’utiliser leur générateur matériel de nombres aléatoires pour créer des « seeds », ces phrases de récupération de 12 ou 24 mots. Cette erreur logicielle aurait poussé le générateur de ces portefeuilles à se rabattre sur une méthode reposant sur des données relativement prévisibles (numéro de série de la puce ou encore valeurs liées à l’horloge), explique l’équipe Bitcoin Engineering and Security de Block.

Plus de 100 millions de dollars volatilisés

Le 30 juillet, 1 196 adresses ont été entièrement vidées pour un peu plus de 1 082 bitcoins, ce qui représente environ 70 millions de dollars selon les calculs de Galaxy Research. L’opération a été rapide, elle n’a duré en tout et pour tout 41 minutes. Deux autres vagues ont eu lieu par la suite, pour un total de 1 816 BTC, soit 114 millions de dollars.

Image : Coldcard

Les bitcoins ne sont pas stockés dans les wallets Coldcard eux-mêmes, mais sur la blockchain ; le portefeuille physique ne conserve que les clés privées permettant de déplacer les bitcoins. En temps normal, ces clés sont impossibles à deviner. Mais dans ce cas, une entropie très insuffisante – autrement dit un hasard « prévisible » – aurait considérablement réduit le nombre de phrases de récupération possibles.

L’erreur ne venait pas de l’absence d’un générateur matériel de nombres aléatoires, mais d’un mauvais branchement logiciel. Le code chargé de créer les phrases de récupération appelait par erreur un générateur de secours alimenté notamment par l’identifiant de la puce et des valeurs d’horloge. Sur les anciens wallets Mk2 et Mk3 concernés, aucun véritable hasard cryptographique ne venait corriger cette faiblesse. Sur les modèles plus récents, Coldcard ajoutait bien une source sécurisée, mais n’en conservait que 32 bits, réduisant fortement le nombre de seeds possibles.

L’attaquant n’avait donc pas besoin de pirater les appareils : il lui suffisait de reproduire le générateur défaillant sur ses propres machines, puis de tester les seeds candidates. Toutes les clés privées et les adresses du propriétaire en découlent, c’est pourquoi il importe que la seed soit choisie de manière complètement aléatoire et imprévisible, ce qui n’était pas le cas ici.

Les fonds volés sont regroupés sur quatre adresses bitcoin. Leur parcours peut être suivi publiquement, mais les identités des personnes qui contrôlent ces adresses restent inconnues, sauf à recouper ces transactions avec d’autres informations, par exemple celles d’une plateforme d’échange. Il se trouve que l’attaquant aurait utilisé un compte payant auprès d’un fournisseur de données blockchain pour interroger les adresses au moment du vol.

Ces informations ne proviennent pas d’une plateforme d’échange, mais un compte payant peut laisser des traces potentiellement exploitables pour remettre la main sur le ou les auteurs de ce casse. Quant aux utilisateurs de Coldcard, ils ne doivent pas se contenter de mettre à jour leurs portefeuilles. Il faut aussi et surtout créer une nouvelle seed à partir d’un système mis à jour, puis transférer les cryptos vers les nouvelles adresses.

Des clés aux pieds d’argile

Cette histoire rappelle que les clés, même très longues (128 ou 256 bits) ne sont aussi solides que la méthode cryptographique qui sert à les générer. Si elle ne produit qu’un petit nombre de valeurs possibles, la sécurité de la clé devient largement illusoire. Dans le cas Coldcard, les wallets Mk4, Q et Mk5 généraient des clés d’environ quatre milliards de suites réellement distinctes. Un nombre immense à l’échelle humaine, mais suffisamment réduit pour pouvoir être exploré par des ordinateurs.

Il y a plusieurs exemples de mécanismes cryptographiques robustes, mais affaiblis par leur implémentation. On peut rappeler la découverte du groupe fail0verflow qui, fin 2010, révélait la clé privée permettant de signer les jeux et les logiciels de la PS3. Il devenait donc possible de faire tourner des homebrews et des programmes non autorisés par Sony sur la console.

L’algorithme ECDSA utilisé exigeait une valeur secrète différente pour chaque signature (« nonce »). Mais voilà, la PS3 réutilisait la même valeur… En comparant plusieurs signatures, les bidouilleurs ont pu calculer la clé utilisée par Sony. Le problème ne résidait pas dans l’algorithme en lui-même, mais dans son implémentation.

Autre exemple célèbre : en 2014, le National Institute of Standards and Technology (NIST) américain retirait un algorithme cryptographique de son projet de recommandations sur les générateurs de nombres pseudo-aléatoires. Il s’agissait de Dual_EC_DRBG, qui était très lent, favorisait certains nombres plutôt que d’autres, et avait cette réputation d’être un tuyau percé.

En septembre 2013, des documents révélés par Edward Snowden ont ravivé les soupçons autour de cet algorithme, soupçonné depuis plusieurs années de contenir une porte dérobée conçue par la NSA. L’agence avait justement insisté auprès du NIST pour conserver Dual_EC_DRBG, alors que ses faiblesses étaient connues depuis 2007.