Quand le hasard échoue : le bug d'entropie Coldcard et ce que changent deux appareils
Fin juillet 2026, des attaquants ont commencé à vider des bitcoins de milliers de portefeuilles matériels qui n'avaient rien fait de mal. Leurs propriétaires avaient suivi les conseils. Ils avaient acheté un appareil dédié à la signature, gardé la graine hors ligne, ne l'avaient jamais tapée sur un site web. Rien de tout cela n'a compté, car la graine que ces appareils produisaient n'avait jamais été aussi aléatoire qu'elle en avait l'air.
Environ 1 816 BTC ont quitté plus de 5 200 adresses en quatre vagues. C'est devenu le plus grand exploit de portefeuille matériel de l'année.
Cet article n'est pas un tour d'honneur. Le bug en cause est de ceux qui auraient pu arriver à presque n'importe quel portefeuille, y compris le nôtre, et la question intéressante n'est pas qui l'a livré, mais ce que fait l'architecture d'un portefeuille quand cela arrive.
Ce qui a réellement mal tourné
Un seul commit, en mars 2021.
La conception de Coldcard prévoyait que les graines soient produites par un générateur matériel de nombres aléatoires — une puce dédiée tirant son entropie de processus physiques. C'est la bonne façon de faire. Mais une modification du firmware 4.0.1 a fait passer la génération de graines par un générateur pseudo-aléatoire logiciel initialisé à partir de constantes publiques inscrites en dur.
Un PRNG est déterministe par définition. À valeur de départ identique, il produit toujours la même suite. Une graine ainsi produite n'est donc pas un nombre que personne ne peut deviner : c'est un nombre tiré d'un ensemble assez petit pour être parcouru, avec des constantes qui figuraient depuis toujours dans le firmware publié.
Les appareils continuaient de se comporter normalement. Ils affichaient vingt-quatre mots, on les notait, ils dérivaient des adresses correctes, signaient des transactions valides. Aucun portefeuille n'a d'écran vous indiquant combien d'entropie est entrée dans votre graine. Chaque utilisateur touché avait un appareil qui ressemblait et se comportait exactement comme un appareil sain, pendant jusqu'à cinq ans.
La fenêtre va du firmware 4.0.1 de mars 2021 au 4.1.9 de juillet 2026. Mettre à jour le firmware corrigeait la génération pour la suite et ne faisait absolument rien pour les graines déjà créées : ces clés étaient déjà faibles, et aucune mise à jour ne peut ajouter rétroactivement du hasard à un nombre déjà inscrit sur une carte au fond d'un coffre. Les personnes touchées ont dû générer une nouvelle graine et déplacer leurs pièces.
Pourquoi un hasard faible est une perte totale et silencieuse
Il vaut la peine d'être précis sur la gravité de cette classe de bug, car ce n'est pas intuitif.
Une graine BIP-39 de 24 mots représente 256 bits d'entropie. En deviner une n'est pas simplement difficile, c'est inimaginable : aucun ordinateur, présent ou futur, ne parcourt cet espace par force brute. C'est le socle sur lequel repose tout le modèle d'auto-conservation : votre clé est en sûreté parce qu'elle est une parmi un nombre incompréhensiblement grand de possibilités.
Cette garantie n'est pas une propriété des mots. C'est une propriété du procédé qui les a choisis. Vingt-quatre mots tirés d'un générateur faible sont identiques à vingt-quatre mots tirés d'un générateur fort. Ils passent toutes les sommes de contrôle, produisent des adresses valides et se restaurent parfaitement dans n'importe quel portefeuille. La seule différence, c'est que quelqu'un d'autre peut y parvenir aussi.
L'échec est donc invisible de l'intérieur, et il est complet. Non pas « un attaquant pourrait vous voler si vous faites une erreur » — il n'y a pas d'erreur à éviter, pas de lien d'hameçonnage à refuser, pas de boîte de confirmation à lire attentivement. L'argent est prenable au moment qui arrange l'attaquant, et le premier signe que quelque chose clochait, c'est qu'il n'est plus là.
Ce que changent deux appareils
Voici la partie qui compte sur le plan architectural, et je veux l'énoncer avec précision plutôt qu'en termes de marketing.
SSP est un multisig 2-sur-2. Les fonds vivent à une adresse contrôlée par deux clés indépendantes, produites sur deux appareils indépendants — l'une dans l'extension de navigateur, l'autre dans l'application mobile SSP Key — et une transaction exige les deux signatures. L'arrangement deux-sur-deux est toute la base du portefeuille.
Appliquez maintenant le scénario Coldcard à cette structure. Supposons que la génération de graines de l'extension ait le même défaut et qu'un attaquant puisse dériver entièrement votre clé de navigateur.
Il ne peut toujours rien dépenser. Il détient une des deux signatures requises. L'adresse ne libère pas de fonds pour une seule clé, quelle qu'elle soit et quelle qu'ait été la manière de l'obtenir. Pour déplacer vos pièces, il lui faudrait en outre casser, indépendamment et simultanément, la clé de votre téléphone — une autre application, un autre système d'exploitation, une autre source d'entropie, produite à un autre moment.
Voilà la différence structurelle. Dans un portefeuille à clé unique, une graine faible est une perte totale. Dans un 2-sur-2, une graine faible est un problème sérieux qui n'est pas, à lui seul, une perte.
La réserve, dite franchement
Il serait facile de s'arrêter là et de vous laisser conclure que SSP y est immunisé. Il ne l'est pas, et prétendre le contraire pendant l'incident d'autrui serait précisément le mauvais moment.
Les deux applications SSP utilisent la même implémentation de BIP-39 — @scure/bip39, figée à la même version dans les deux. Un défaut de cette bibliothèque elle-même toucherait les deux clés. L'indépendance que SSP vous donne est réelle mais précise : deux graines distinctes, produites à des moments différents sur des appareils différents, puisant leur entropie dans des sources système différentes — la Web Crypto du navigateur d'un côté, le CSPRNG de la plateforme mobile de l'autre. Ce n'est pas l'indépendance de deux bases de code entièrement étrangères l'une à l'autre.
Ce que cela achète, c'est une protection contre le mode de défaillance survenu chez Coldcard : une erreur d'implémentation propre à un appareil dans la façon dont un produit générait ses graines. Cela ne protégerait pas d'un défaut de la primitive cryptographique partagée en dessous.
C'est une affirmation nettement plus faible que « cela ne peut pas nous arriver », et c'est la vraie. Quiconque vous dit que son portefeuille est catégoriquement immunisé contre une défaillance d'entropie vous parle de son marketing, pas de son architecture.
Ce qu'il faut en retenir
Si vous avez une Coldcard de cette fenêtre de firmware, la seule hypothèse sûre est que la graine est compromise, que des fonds aient bougé ou non. Générez-en une nouvelle sur un firmware corrigé et migrez. Un appareil qui n'a pas encore été vidé n'est pas un appareil sûr.
Si vous utilisez un portefeuille à clé unique, c'est le risque que vous portez, et il vaut mieux en être conscient qu'anxieux. Les portefeuilles matériels restent très supérieurs aux alternatives pour la plupart des gens. La leçon n'est pas qu'ils sont mauvais ; c'est qu'une clé unique est un point de défaillance unique, et que chaque partie de l'histoire de cette clé — y compris l'instant de sa naissance, il y a des années, dans un firmware que vous n'avez pas lu — fait partie de votre modèle de menace.
Et de façon générale, préférez les architectures où une seule chose qui tourne mal ne suffit pas. Ce principe explique pourquoi SSP exige deux appareils, pourquoi certaines opérations réclament une nouvelle signature même déjà authentifié, et pourquoi ce qui arrête réellement une transaction est une question à poser à tout portefeuille auquel vous confiez quelque chose. La réponse ne devrait jamais être « un secret, et l'espoir qu'il a été produit correctement ».
Pour une comparaison plus large des options et de ce que chacune protège vraiment, comparer les options d'auto-conservation traite des compromis.
