Coldcard : une faille de génération de seed accroît le risque de vol de bitcoins

Certains détenteurs d’un Coldcard Mk3 pourraient devoir déplacer leurs bitcoins. Coinkite indique que les fonds liés à des seeds générées avec le firmware 4.0.1 — ou une version Mk3 ultérieure — peuvent être exposés. Le contributeur de Bitcoin Core instagibbs affirme avoir recréé la seed vulnérable sur un Mk3 fraîchement initialisé. Coinkite précise que les appareils Mk4 et Mk5 sont aussi concernés avant le firmware 5.6.0, et que les appareils Q le sont avant 1.5.0Q. L’impact y serait moins critique, mais reste jugé sérieux. L’entreprise prévoit une revue technique formelle afin d’identifier la cause racine. Pourquoi la seed est le point de rupture Un portefeuille matériel protège normalement une clé existante grâce au stockage sécurisé, à la signature hors ligne et à la vérification sur l’appareil. La génération de la seed intervient avant ces protections et conditionne la robustesse initiale du matériau cryptographique. La sécurité d’une phrase de récupération repose sur l"entropie, c’est-à-dire l’aléa qui permet de choisir une combinaison au sein d’un espace immense. Si l’aléatoire est insuffisant, cet espace se réduit et un attaquant peut tester des seeds candidates, en déduire les adresses, puis surveiller les dépôts depuis un autre ordinateur. Une création prévisible neutralise l"air gap dès le départ et transforme le vol en simple problème de recherche à distance. L’attaquant génère des seeds plausibles, observe les adresses correspondantes et dépense les fonds dès qu’une correspondance apparaît. Comme toutes les adresses existantes restent contrôlées par la seed d’origine, la correction passe par de nouvelles clés et un transfert on-chain. Une mise à jour de firmware peut sécuriser les prochains processus d’initialisation, mais ne peut pas modifier le matériau cryptographique qui contrôle déjà les anciennes adresses. Couches de sécurité : ce qu’elles protègent, et leurs limites ici - Air gap : empêche l’exposition des clés via une connexion active ; inutile si la seed était prévisible dès la création. - Stockage sécurisé : isole une clé privée existante ; protège la mauvaise chose si la clé initiale est faible. - Signature hors ligne : permet d’approuver des transactions sans connecter le wallet ; ne s’applique qu’après l’existence de la seed. - Vérification sur l’appareil : confirme adresses et montants à l’écran ; ne prouve pas que la seed a été générée avec assez d’entropie. - Mise à jour du firmware : améliore le comportement futur ; ne remplace pas les anciennes adresses contrôlées par une seed déjà générée. - Nouvelle seed + transfert : crée un nouveau matériau cryptographique et déplace les fonds ; seule remédiation complète en cas de seed potentiellement faible. Le profil de garde le plus à risque L’exposition la plus nette correspond à un Mk3 concerné ayant généré la seed, avec un portefeuille contrôlé par une seule signature. Zéro entropie via dés, zéro passphrase BIP39, zéro multisig : le générateur de seed de l’appareil devient l’unique racine cryptographique. Coinkite souligne qu’une passphrase BIP39 forte et unique ajoute une barrière indépendante. À l’inverse, des passphrases courtes, courantes, à motifs, "citées" ou réutilisées peuvent être devinables. La passphrase est distincte du PIN de l’appareil et dérive un portefeuille séparé à partir de la même mnémonique, ce qui oblige un attaquant à récupérer deux secrets. Même dans ce cas, Coinkite recommande une migration vers une seed nouvellement générée. Un multisig peut limiter l’impact d’une seed faible si le seuil de dépense exige des clés indépendantes. Les dés fournis par l’utilisateur peuvent ajouter une source d’entropie externe ; le parcours avancé de Coinkite prévoit au moins 99 lancers équitables via son flux d’import "dice-only". Ces protections demandent une documentation rigoureuse et une procédure de récupération testée : une passphrase perdue peut bloquer le propriétaire, un multisig mal documenté complique la reprise, et des notes de lancers exposées peuvent révéler la seed de remplacement. Coinkite conseille de vérifier la sauvegarde, l’empreinte (fingerprint) et l’adresse de réception, d’envoyer un petit paiement de test, puis de transférer le solde. Cette séquence vise à éviter qu’une urgence n’entraîne un second incident : adresse mal saisie, portefeuille temporaire fragile ou sauvegarde incomplète. Configurations de garde : lecture du risque - Seed générée par Mk3, single-sig, sans passphrase, sans dés, sans multisig : risque le plus élevé, la seed potentiellement affectée est l’unique racine cryptographique. - Seed générée par Mk3 avec passphrase BIP39 : risque plus faible uniquement si la passphrase est forte et unique ; l’attaquant doit obtenir la mnémonique et la passphrase. - Seed générée par Mk3 avec multisig : risque réduit si les autres signataires sont indépendants ; une seed faible ne suffit pas si le seuil requiert d’autres clés. - Seed générée par Mk3 avec entropie via dés : risque réduit si au moins 50 lancers équitables et privés ont été ajoutés ; moins de 50 lancers ou un doute sur leur qualité impose une migration. - Nouvelle seed sur un appareil non affecté : voie de remédiation, les fonds passent sur un matériau cryptographique neuf. - Migration paniquée vers un wallet/adresse non vérifié(e) : nouveau risque, l’urgence peut causer des pertes sans lien avec la faille initiale. Le "cold storage" se dote d’un calendrier de maintenance Coinkite a publié le dernier firmware Mk3 en juin 2023. Son avis de juillet 2026 couvre les seeds créées par des Mk3 à partir de mars 2021, soit un écart de trois ans entre la fin du support produit et une action de garde urgente. Ce décalage transforme le stockage à froid en problème de maintenance d’héritage : certains détenteurs n’allument leur appareil qu’une fois tous les quelques années, des pages produits anciennes perdent en visibilité, et les avis fabricants peuvent être manqués pendant des mois. Une seed peut survivre à l’appareil, à la branche de firmware et au canal de support initial. Les dispositifs de conservation doivent donc prévoir des alertes durables et des procédures de migration reproductibles. Les fabricants peuvent publier l’architecture d’entropie, des avis spécifiques par appareil et des guides de rotation de clés accessibles des années après la dernière vente. La documentation sécurité de Coinkite met en avant le code ouvert et les builds reproductibles comme outils d’inspection. Les examinateurs peuvent comparer le code source et les binaires publiés. Des défauts peuvent persister tant que le chemin de code exact ayant généré une seed dormante n’a pas été étudié. Les builds reproductibles indiquent quel code s’est exécuté, mais la qualité de l’aléa exige des tests séparés ; d’où l’importance de tests indépendants sur la génération de seed. Scénarios : la suite possible Dans un scénario favorable, les utilisateurs concernés effectuent une rotation de clés de manière méthodique, Coinkite publie la cause racine, et les fabricants renforcent les tests d’entropie ainsi que les canaux d’alerte pérennes. Passphrases, multisig et sources d’aléa indépendantes gagneraient en adoption, multipliant les barrières cryptographiques autour d’un même solde. Dans un scénario défavorable, des wallets Mk3 dormants continuent de recevoir des dépôts sur de vieilles seeds, et les propriétaires découvrent l’avis au fil de récits de vol ou d’appels à l’aide. Les transferts dans la panique entraînent des pertes supplémentaires (adresses non vérifiées, wallets temporaires faibles, sauvegardes égarées). Des affirmations non étayées associent alors des mouvements on-chain sans rapport direct à la faille. Les portefeuilles matériels ont rendu l’auto-conservation praticable en protégeant les clés pendant le stockage et la dépense. L’avertissement Coldcard étend désormais ce modèle de sécurité à l’initialisation, à la surveillance et à la rotation : chaque seed devient une obligation de maintenance à long terme, susceptible de survivre à l’appareil qui l’a créée. Le post "A flaw in Coldcard seed generation lets attackers recreate private keys from the press of a button" est apparu en premier sur CryptoSlate.