COLDCARD RNG Incident (2026) désigne la faille de génération de secrets divulguée en juillet 2026 et sa correction. Le modèle, la branche et la version du firmware lors de la création du seed, son origine et toute entropie indépendante sont déterminants. Il ne s’agissait ni d’une prise de contrôle à distance de l’appareil ni d’une faille du consensus Bitcoin.
Coinkite et Block ont publié leurs premières analyses le 30 juillet 2026 après des signalements de pertes. Le fabricant décrit des attaquants dérivant hors ligne des clés privées faibles, et non prenant le contrôle des appareils à distance. La seule marque du portefeuille ne permet pas d’établir la cause d’une perte individuelle. Le dossier technique et les consignes ultérieures doivent être lus avec leurs dates de révision. [Coinkite — COLDCARD Security Advisory] [Block — Predictable RNG Fallback and 32-Bit Reseed]
Après le passage à libNgU, ngu.random.bytes atteignait rng_get de MicroPython et son générateur Yasmarang. MICROPY_HW_ENABLE_RNG valait 0 ; pourtant, #ifndef vérifiait l’existence de la macro, pas l’activation du chemin matériel. Le code TRNG prévu pouvait être présent dans le binaire sans servir à la génération du seed. Aucune panne matérielle ne déclenchait un repli d’urgence pendant l’exécution. [Coinkite — Technical Deep Dive into the Entropy Issue]
L’état logiciel provenait de données de l’appareil, de compteurs temporels et de l’historique des appels. Pour Mk4, Mk5 et Q, Block décrit un réensemencement supplémentaire limité à 32 bits : au plus 2^32 flux distincts lorsque le reste de l’état est fixé. Coinkite avançait des estimations totales préliminaires d’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 déterminent ni un coût universel d’attaque ni la compromission immédiate de chaque portefeuille. [Block — Predictable RNG Fallback and 32-Bit Reseed] [Coinkite — Technical Deep Dive into the Entropy Issue]
Les consignes officielles citent Mk2/Mk3 4.0.1–4.1.9. L’analyse initiale de Block inclut déjà 4.0.0 et le changement de mars 2021 ; cette divergence documentaire reste explicite. En cas d’origine incertaine du seed, le guide recommande la voie prudente de migration. Mk4/Mk5 et Q étaient affectés avant la correction de leur branche. L’ancienne affirmation de la première analyse concernant toutes les versions de production ne décrit pas les versions corrigées actuelles. [Coinkite — COLDCARD Security Advisory] [Block — Predictable RNG Fallback and 32-Bit Reseed] [COLDCARD — Seed migration guide]
Les correctifs minimaux 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. Les numéros de branches différentes ne forment pas une seule suite comparable. Lors de cette révision, la page de suivi recommande Standard 5.6.2 pour Mk4/Mk5 et 1.5.2Q pour Q. Avant installation, vérifiez la page officielle actuelle, le hash et la signature de la version ; un numéro supérieur dans une autre branche ne suffit pas. [COLDCARD — Current Security Status]
Un hachage déterministe peut changer l’apparence de la sortie, pas agrandir l’ensemble des entrées possibles. BIP39 Checksum n’ajoute pas non plus l’entropie manquante. Un seed externe créé de manière sûre n’est pas affaibli par cet incident du seul fait de son importation dans une COLDCARD. À l’inverse, un seed affecté le reste après restauration sur un autre appareil ; mise à jour, clonage ou transfert n’en font pas un nouveau seed. [Block — Predictable RNG Fallback and 32-Bit Reseed] [COLDCARD — Seed migration guide]
L’exception du fabricant exige au moins 50 lancers équitables, indépendants et privés saisis dans le parcours initial Add Dice Rolls, puis l’utilisation des mots finaux affichés après leur ajout. Avec moins de lancers ou en cas d’incertitude, il recommande de migrer. Une BIP39 Passphrase forte et unique ajoute une barrière, mais ne répare pas un seed faible ; le fabricant recommande aussi la migration à ses utilisateurs. Le PIN n’est pas une passphrase. Les exigences actuelles de création d’un seed doivent être distinguées de cette exception historique. [Coinkite — COLDCARD Security Advisory]
Le guide actuel prévoit la vérification des sauvegardes, l’installation du correctif adapté, un seed réellement nouveau, le contrôle de son empreinte et de l’adresse de réception sur l’appareil, puis une petite transaction de test. Le reste des fonds ne suit qu’après vérification de la nouvelle destination. Conservez l’ancienne sauvegarde jusqu’à confirmation complète et recensez tous les comptes financés, portefeuilles avec passphrase, enfants dérivés et politiques multisig. En cas de divergence, n’effacez et n’envoyez rien ; les données privées de récupération n’ont pas leur place dans un formulaire web. [COLDCARD — Seed migration guide]
Multisig ne constitue pas une exception automatique : assez de clés de signature compromises peuvent satisfaire le seuil de l’ancienne politique. Il faut évaluer les clés sûres restantes et vérifier la politique de remplacement. Block identifie aussi d’autres consommateurs du même aléa, dont les clés autonomes de paper wallets et certaines clés de chiffrement temporaires. La gravité dépend du protocole et des données disponibles ; l’impact n’est pas identique pour chaque fonction. [Block — Predictable RNG Fallback and 32-Bit Reseed] [COLDCARD — Seed migration guide]
La page de suivi distingue un test du RNG matériel sur une véritable Mk4, des revues de sources et une compilation reproduite d’un correctif précis. Ce sont des vérifications limitées du chemin et du mécanisme, pas un audit complet de chaque binaire ni une preuve d’absence de défauts. Le firmware Standard actuel exige aussi un apport d’entropie de l’utilisateur ; l’ancienne affirmation selon laquelle il serait toujours facultatif serait trompeuse. La page indique encore qu’un rapport technique détaillé distinct sur l’incident est en préparation. [COLDCARD — Current Security Status]
Nouveau firmware, mais toujours le seed d’origine
Un utilisateur a créé un seed sur Mk3 4.1.9 sans lancers de dés personnels. Il a ensuite installé 4.2.0 et restauré les mêmes mots sur un autre appareil. L’origine du seed n’a pas changé. Il évalue la correction selon le guide de migration : nouveau seed créé de façon sûre, sauvegarde et adresse vérifiées, transfert de test, puis seulement transfert du reste. Il conserve l’ancienne sauvegarde jusqu’à confirmation de tous les fonds.
Pour une vision complète, lisez aussi Cryptographic Entropy, Deterministic RNG, Seed Generation, BIP39 checksum, BIP39 passphrase, Dice Roll Entropy.
01Une mise à jour du firmware ou un nouveau portefeuille suffisent-ils ?+
Non. Aucune de ces opérations ne modifie un seed existant. Le lieu et le mode de création comptent. Les fonds affectés doivent être traités selon les consignes de migration et les conditions exactes de l’exception des dés indépendants ; restaurer les mêmes mots ne supprime pas le problème.
02Le chiffre de 32 bits signifie-t-il que tous les modèles sont aussi faciles à attaquer ?+
Non. Dans l’analyse de Block, il limite le réensemencement supplémentaire lorsque le reste de l’état et l’historique des appels sont fixés. Des données d’appareil ou des timings inconnus modifient le travail de l’attaquant. Ce n’est ni un benchmark universel ni une preuve de sécurité d’un seed affecté donné.