Coldcard : une faille de génération de "seed" liée à environ 130 M$ de bitcoins dérobés

La promesse d’un portefeuille matériel "hors ligne" est de réduire les attaques à distance. Elle ne protège pas contre un défaut présent au moment même où la phrase de récupération (seed) est créée. C’est le scénario retenu dans le cas de Coldcard, portefeuille Bitcoin-only fabriqué par l’entreprise canadienne Coinkite : selon The Hacker News, citant des travaux de recherche de Block publiés le 1er août 2026, les attaquants n’auraient jamais eu besoin d’accéder aux appareils des victimes. Ils auraient reconstruit hors ligne des seeds candidates, puis les auraient validées en les confrontant à des données publiques de la blockchain. Selon The Hacker News, Block remonte l’origine du problème à une erreur de configuration en production datant de mars 2021. Une macro de compilation, MICROPY_HW_ENABLE_RNG, avait été définie à zéro (Coinkite fournissant sa propre couche d’abstraction pour un générateur matériel), mais une bibliothèque, libngu, ne vérifiait que l’existence de la macro, pas son activation. Résultat : les firmwares concernés basculaient sur le générateur de secours Yasmarang de MicroPython, initialisé à partir de l’identifiant unique de la puce et de registres de temporisation, sans apport d’aléa supplémentaire par la suite. Coinkite estime l’entropie résultante à environ 40 bits sur le modèle Mk3 et à environ 72 bits sur les Mk4, Mk5 et Q, loin des 128 bits attendus pour une seed BIP39 standard de 12 mots, toujours selon The Hacker News. Block n’a pas publié de benchmark opérationnel de force brute ; l’étude évoquerait plutôt des plafonds conditionnels, en soulignant que même l’estimation haute ne correspond pas à une force cryptographique réelle de 73 bits. Aucun rapport public examiné ici n’a, à ce stade, reconstitué la seed d’une victime précise et prouvé le lien direct avec une adresse vidée. Pourquoi le "offline" n’a pas suffi Le point clé est contre-intuitif pour de nombreux acheteurs : l’appareil peut rester déconnecté d’Internet, l’attaque n’en a pas besoin. La faiblesse se situe dans le code qui produit la seed le jour de sa création. Une fois les paramètres suffisamment contraints (ID unique de l’appareil, état des timers, appels aléatoires antérieurs), Block indique qu’il devient possible de générer des flux de seeds candidates et de les tester intégralement hors ligne, en s’appuyant sur des informations on-chain accessibles à tous, d’après The Hacker News. Le coffre, le dispositif ou la boîte de dépôt de la victime ne font alors pas partie de la surface d’attaque. Toujours selon The Hacker News, Galaxy Research a identifié une opération de "sweep" portant sur 1 196 adresses Bitcoin, réalisée en 41 minutes le 30 juillet 2026, pour 1 082,65 BTC (environ 70,2 M$ à l’époque). Galaxy aurait précisé ne pas avoir observé, sur les 30 jours précédents, d’autres transactions Bitcoin présentant le même taux de frais et la même signature "no-change", tout en avertissant qu’un sweep peut aussi correspondre au déplacement volontaire de fonds : ce type de motif permet davantage d’identifier un opérateur que de prouver un vol. Galaxy aurait ensuite signalé deux vagues supplémentaires, portant le total observé à 1 367,05 BTC (environ 88,6 M$) sur 4 585 adresses, avec deux réserves : une vague plus tardive ne doit pas être présumée liée au même acteur, et toutes les adresses marquées n’ont pas été confirmées computationnellement comme issues du bug d’entropie. Portefeuille matériel ou logiciel : même maillon faible, enjeu de confiance différent Le défaut en cause — une génération d’aléa insuffisante lors de la création des clés — n’est pas propre au matériel. The Hacker News rapporte qu’une autre recherche, menée par Coinspect et baptisée Ill Bloom, a mis en évidence une faille de PRNG (générateur pseudo-aléatoire) dans d’anciens portefeuilles logiciels, associée à plus de 5 M$ siphonnés depuis mai sur des adresses Bitcoin, Ethereum, Tron, Rootstock et Polygon. Le média présente ces cas comme deux incidents distincts, sans lien direct, mais révélateurs d’un point commun : qu’une clé soit créée dans un appareil dédié ou dans une application mobile, tout repose sur la qualité du code qui produit le "random". Un second risque, différent de l’entropie, concerne les firmwares : ce sont des logiciels contrôlés et mis à jour par le fabricant, qu’un utilisateur ne peut généralement pas auditer intégralement avant installation. Cointelegraph, dans un résumé conservé pour cette page, qualifie les mises à jour de firmware de "perfect attack vector" pour un acteur cherchant un accès discret aux clés privées — qu’il s’agisse, selon ses termes, d’une "regulatory agency — or worse, a criminal organization" — et cite une vulnérabilité Ledger de 2018. Il s’agit d’un mode de défaillance distinct de Coldcard : ici, les éléments disponibles pointent vers une erreur de code introduite en 2021, pas vers une mise à jour volontairement altérée, et rien ne relie les deux. Correctif : il empêche le futur, pas le passé D’après The Hacker News, Coinkite a diffusé un firmware d’urgence pour tous les modèles et canaux de release concernés le 31 juillet 2026. Le même jour, CoinDesk cite une lettre ouverte du PDG de Coinkite, NVK, demandant aux détenteurs de "déplacer leurs fonds maintenant" en suivant de nouvelles consignes. Le patch empêche la génération de nouvelles seeds vulnérables, mais ne "répare" pas une seed déjà créée sur un firmware affecté : restaurer cette seed sur un firmware corrigé ou sur un autre wallet transfère la faiblesse, selon les deux médias. Le risque dépend donc de la version de firmware en place au moment de la création de la seed, pas de la version installée aujourd’hui. Plages de versions concernées (selon The Hacker News) : Coinkite indique que Mk3 versions 4.0.1 à 4.1.9 sont touchées (corrigé en 4.2.0) et ne cite pas Mk2, tandis que Block inclurait Mk2 et Mk3 versions 4.0.0 à 4.1.9 parmi les chemins vulnérables. Pour Mk4 et Mk5, toutes les versions antérieures à 5.6.0 seraient affectées ; pour Q, antérieures à 1.5.0Q. Les "edge builds" antérieures à 6.6.0X (Mk4/Mk5) ou 6.6.0QX (Q) seraient également concernées. Coinkite précise qu’une seed générée en ajoutant au moins 50 lancers de dés, équitables, indépendants et réalisés en privé, n’est pas exposée à ce bug en lui-même ; si le nombre de lancers ou leur confidentialité sont incertains, l’entreprise recommande une migration des fonds. Une passphrase BIP39 forte et unique crée un portefeuille distinct auquel les seuls mots de seed ne donnent pas accès, mais Coinkite recommande malgré tout de remplacer la seed sous-jacente. Les configurations multisig ne sont protégées que si le quorum de signature ne repose pas exclusivement sur des appareils affectés. Les produits TAPSIGNER, OPENDIME et SATSCARD utiliseraient d’autres bases de code et ne seraient pas concernés. Combien a été perdu ? Des estimations évolutives Les montants publiés varient selon la date, l’enquête on-chain de Galaxy Research étant décrite comme toujours en cours. Aucune de ces valeurs ne constitue un total audité et définitif. • 31 juillet 2026 : 38 M$ (CoinDesk) • 1er août 2026 (sweep initial) : 1 082,65 BTC (~70,2 M$), selon The Hacker News citant Galaxy Research • Mise à jour non datée dans le même article : 1 367,05 BTC (~88,6 M$) sur 4 585 adresses, selon The Hacker News citant Galaxy Research • Plus de 100 M$ : Bloomberg (date non précisée dans les éléments disponibles ici) • 4 août 2026 ("as of Tuesday") : environ 130 M$, TechCrunch citant Galaxy Research ; chiffre présenté comme globalement plausible par Tom Robinson (cofondateur et chief scientist d’Elliptic) Pour mise en perspective, TechCrunch indique, en citant TRM Labs, que plus de 200 piratages visant des entreprises crypto auraient eu lieu depuis le début de 2026, pour des pertes totales supérieures à 950 M$ — un agrégat sectoriel qui ne se limite pas à Coldcard. Un utilisateur, Jonathan Goodman, a affirmé sur X avoir perdu 1,6 M$ depuis un Coldcard sans avoir partagé sa seed ni connecté ses appareils à Internet ; cette déclaration est auto-rapportée et non vérifiée dans les sources utilisées ici. Ce que cette page ne peut pas affirmer Elle ne peut pas donner un total final des pertes : les chiffres ci-dessus sont des instantanés datés d’une enquête présentée comme non close, et les médias cités ont publié des montants différents à des dates différentes pour ce qui pourrait être un même événement en évolution. Le chiffre Bloomberg ("plus de 100 M$") n’est pas daté dans les éléments disponibles ici. La perte revendiquée par Jonathan Goodman ne peut pas être confirmée indépendamment. Les sources examinées ne permettent pas non plus d’établir un lien technique entre Ill Bloom et le bug Coldcard ; The Hacker News les traite comme deux incidents distincts. Le passage de Cointelegraph sur les mises à jour de firmware relève d’un risque différent (mise à jour compromise) et n’est présent ici que sous forme de résumé et d’un extrait, sans corroboration supplémentaire dans ce dossier. Aucun média cité n’identifie l’attaquant, et Galaxy Research avertit qu’une vague plus tardive ne doit pas être attribuée d’office au même opérateur. Enfin, cette page ne dispose d’aucun document primaire (avis Coinkite, papier de Block, rapport Galaxy) : les éléments techniques (entropie, plages de versions) proviennent de reprises journalistiques. Sources : l’ensemble des faits ci-dessus s’appuie sur des articles attribués à The Hacker News, CoinDesk, TechCrunch, Bloomberg, Cointelegraph et Galaxy Research tels que résumés dans les éléments fournis.