COLDCARD RNG Incident (2026) désigne l’incident révélé en juillet 2026, dans lequel une erreur logicielle affaiblissait la création du seed. Le seed est la base secrète dont sont dérivées les clés du portefeuille ; RNG signifie générateur de nombres aléatoires. Le risque dépend de sa création et du firmware alors utilisé. Il ne s’agissait ni d’une défaillance des règles de Bitcoin ni d’une prise de contrôle à distance.
Coinkite et Block ont publié leurs premières analyses le 30 juillet 2026 après des signalements de pertes. Selon le fabricant, les attaquants n’avaient pas besoin de contrôler l’appareil : ils pouvaient reproduire des secrets mal générés et retrouver les clés privées correspondantes, qui permettent de signer des transferts. Garder le portefeuille hors ligne ne suffisait donc pas. Cette explication ne détermine toutefois pas la cause de chaque perte individuelle ; la marque seule ne permet pas de la connaître. [2] [3]
Le portefeuille devait utiliser une source matérielle de hasard, appelée TRNG. Après intégration de la bibliothèque libNgU, ngu.random.bytes aboutissait pourtant à rng_get de MicroPython et à son générateur logiciel Yasmarang. Les mauvais composants avaient été reliés lors de la construction du programme. MICROPY_HW_ENABLE_RNG valait 0, tandis que #ifndef vérifiait seulement l’existence de ce réglage, pas sa valeur. Le bon code matériel pouvait donc être présent dans le fichier sans servir à créer les seeds. Ce n’était ni une panne de puce ni un mode de secours volontaire. [1]
Un attaquant est avantagé si le secret provient d’un ensemble plus petit. Ici, l’état du programme dépendait de données de l’appareil, de compteurs de temps et d’appels antérieurs. Pour Mk4, Mk5 et Q, Block décrit une actualisation supplémentaire limitée à 32 bits : au plus 2^32 suites de sortie distinctes si le reste demeure fixé. Coinkite estimait provisoirement l’entropie totale, c’est-à-dire l’incertitude, à environ 40 bits pour Mk2/Mk3 et 72 bits pour les modèles plus récents. Ces chiffres reposent sur des hypothèses différentes. Ils ne donnent ni le coût de chaque attaque ni la preuve que tout portefeuille serait immédiatement vulnérable. [3] [1]
L’avertissement officiel mentionne Mk2/Mk3 avec 4.0.1–4.1.9. La première analyse de Block inclut déjà 4.0.0 et la modification de mars 2021. Les sources divergent donc sur la limite initiale ; mieux vaut conserver cette incertitude que la remplacer par une supposition. Si l’origine du seed est inconnue, le guide recommande de traiter le portefeuille comme affecté. Mk4/Mk5 et Q étaient aussi concernés avant la correction de leur branche. L’ancienne affirmation sur toutes les versions de production ne décrit pas les versions corrigées ultérieures. [2] [3] [5]
Les premières versions corrigées sont Mk2/Mk3 4.2.0, Mk4/Mk5 Standard 5.6.0, Q Standard 1.5.0Q, Mk4/Mk5 Edge 6.6.0X et Q Edge 6.6.0QX. Standard et Edge sont des branches distinctes ; un numéro supérieur dans une autre branche ne prouve rien à lui seul. Lors de cette révision, le fabricant recommande Standard 5.6.3 pour Mk4/Mk5 et 1.5.3Q pour Q. Avant installation, vérifiez la page officielle actuelle, le hash du fichier et la signature de la version. Le hash est une empreinte du contenu ; la signature aide à en vérifier l’origine. Même une mise à jour correcte ne modifie pas un seed existant. [4]
Imaginez restaurer un seed faible sur un nouvel appareil. L’appareil change, mais le secret reste le même. Cloner ou transférer le portefeuille présente la même limite. Le hash, une empreinte calculée sur les données, n’ajoute pas de nouvelles entrées possibles. BIP39 Checksum aide à détecter des erreurs dans les mots, sans fournir le hasard manquant. À l’inverse, un seed créé sûrement ailleurs n’est pas affaibli par ce défaut précis lors de son import dans COLDCARD. Son origine est déterminante. [3] [5]
Le fabricant prévoit une exception pour au moins 50 lancers indépendants d’un dé équilibré, saisis dans la fonction originale Add Dice Rolls. Leur suite ne devait jamais être enregistrée ni divulguée, et le portefeuille devait utiliser les mots définitifs produits après leur ajout. Avec moins de lancers ou en cas de doute, il recommande la migration. BIP39 Passphrase est une autre mesure : un texte secret supplémentaire qui détermine, avec le seed, un autre portefeuille. Une passphrase forte et unique ajoute un obstacle, mais ne répare pas le seed ; le fabricant recommande aussi de migrer à ses utilisateurs. Le PIN protège seulement l’accès à l’appareil. Les règles actuelles pour de nouveaux seeds sont distinctes de cette exception historique. [2]
Vérifiez d’abord que la sauvegarde du portefeuille initial est utilisable. Selon le guide de migration, créez ensuite un seed vraiment nouveau sur un firmware corrigé et vérifiez sa sauvegarde. Contrôlez le fingerprint, un identifiant court du portefeuille, et l’adresse de réception sur l’écran de l’appareil. Envoyez une petite somme test ; ne transférez le reste qu’après vérification de la destination et de la réception. Incluez tous les comptes approvisionnés, portefeuilles avec passphrase, portefeuilles dérivés et configurations multisig. Gardez l’ancienne sauvegarde jusqu’à confirmation de l’ensemble. En cas d’écart, ne supprimez et n’envoyez rien. Ne saisissez jamais les secrets de récupération dans un formulaire web. [5]
Multisig exige un nombre déterminé de signatures issues de plusieurs clés pour un transfert. Si un attaquant obtient assez de clés pour satisfaire cette règle, la protection ne suffit plus. Il faut évaluer les clés restantes, préparer une nouvelle règle de signature, la vérifier sur l’appareil et y transférer les fonds. Block décrit d’autres usages du même générateur : des clés autonomes de Paper Wallet et certaines clés temporaires de chiffrement. Les conséquences dépendent de l’usage précis et des données disponibles pour l’attaquant ; elles ne sont pas identiques pour chaque fonction. [3] [5]
La page de suivi distingue un test du générateur matériel sur un véritable Mk4, des examens du code source et la reconstruction indépendante d’une correction précise. Ces contrôles aident à valider le mécanisme décrit, sans prouver la sécurité de chaque fichier publié. Le Standard actuel exige aussi un apport de hasard de l’utilisateur pour créer un seed. L’ancien conseil selon lequel cet apport était toujours facultatif n’est donc pas la procédure actuelle de cette branche. La page suit les mesures correctives ; elle indique toujours qu’un rapport technique détaillé séparé sur les causes est en préparation. [4]
Appareil à jour, problème inchangé
Une personne crée un seed sur Mk3 4.1.9 sans ajouter ses propres lancers de dé. Elle installe 4.2.0 puis restaure les mêmes mots sur un autre appareil, mais utilise toujours le secret initial. Le guide de migration demande un nouveau seed sur firmware corrigé, une sauvegarde et une adresse vérifiées, puis un petit transfert test. Le reste ne suit qu’ensuite. L’ancienne sauvegarde est conservée jusqu’à confirmation complète.
Pour une vision complète, lisez aussi Cryptographic Entropy, Deterministic RNG, Seed Generation, BIP39 checksum, BIP39 passphrase, Dice Roll Entropy.
01Suffit-il d’acheter un nouvel appareil ?+
Non, si vous y restaurez le même seed affecté. Le nouvel appareil ne change pas la manière dont le secret a été créé. Le parcours dépend de son origine et des conditions exactes de l’exception des dés indépendants. Pour un seed affecté, il faut envisager le transfert vers un nouveau portefeuille, pas seulement remplacer le matériel.
02Les 32 bits rendent-ils tous les modèles aussi faciles à attaquer ?+
Non. Dans l’analyse de Block, ils concernent le changement supplémentaire de l’état du générateur, lorsque le reste de l’état et l’historique des appels sont fixés. Des données d’appareil ou des timings inconnus changent la tâche de l’attaquant. Ce chiffre n’est ni une mesure universelle de vitesse ni une garantie de sécurité d’un seed particulier.