Coldcard PRNG : faille d'aléa et vol de Bitcoin

Qu'est-ce que la faille Coldcard ?

Selon Block, qui a analysé le micrologiciel, une erreur d'intégration faisait utiliser à la génération de graine le générateur de repli déterministe de MicroPython (Yasmarang) au lieu du générateur matériel du microcontrôleur STM32. D'après The Hacker News, l'erreur remonte à mars 2021 : une configuration de compilation et une bibliothèque qui testait l'existence d'une macro plutôt que son activation ont lié l'appareil au générateur de repli, alimenté par l'identifiant unique de la puce et des registres de minuterie, sans entropie fraîche.

Coinkite estime l'entropie à environ 40 bits pour le Mk3 et environ 72 bits pour les Mk4, Mk5 et Q, contre 128 bits pour une graine BIP-39 de 12 mots. Un espace aussi réduit peut être exploré hors ligne : l'attaquant génère des graines candidates, en dérive les adresses et les compare à la blockchain publique, qui joue le rôle d'oracle.

Quels appareils et quelles versions sont touchés ?

• Mk2 et Mk3 : micrologiciel 4.0.1 à 4.1.9 ; corrigé en 4.2.0 ou plus.
• Mk4 et Mk5 : avant 5.6.0 (version standard) ou avant 6.6.0X (Edge) ; corrigé en 5.6.0 ou 6.6.0X.
• Q : avant 1.5.0Q (standard) ou 6.6.0QX (Edge) ; corrigé en 1.5.0Q ou 6.6.0QX.

L'exposition dépend du micrologiciel utilisé au moment de la création de la graine, pas de la version installée aujourd'hui. TAPSIGNER, OPENDIME et SATSCARD ne sont pas concernés.

Comment l'attaque s'est-elle déroulée ?

Le 30 juillet 2026, un attaquant a vidé 1 196 adresses en 41 minutes. Galaxy Research a cartographié les transactions et situe l'attaque environ 30 heures avant la divulgation publique de Coinkite. Chainalysis indique qu'environ 30 millions de dollars ont été pris dans les dix premières minutes et que l'attaquant semble avoir étudié les portefeuilles à l'avance. Deux autres vagues suspectes ont été identifiées le 1er août ; Galaxy n'a pas confirmé que toutes les adresses viennent d'une entropie faible. Block a signalé le problème à Coinkite le 30 juillet.

Quelles consignes donne Coinkite ?

Vérifier sa sauvegarde, installer le micrologiciel corrigé, générer une nouvelle graine, vérifier l'adresse sur l'appareil, faire un petit test de transaction, puis déplacer le reste et garder l'ancienne sauvegarde jusqu'à confirmation. Une graine complétée par au moins 50 lancers de dés équitables, indépendants et privés n'est pas considérée comme exposée par ce seul bug. Une phrase secrète BIP-39 longue et unique complique l'attaque sans dispenser de migrer. Ces consignes concernent des propriétaires d'appareils ; elles ne constituent pas un conseil financier.

Comment détecter et tester un défaut d'aléa dans vos produits ?

1. Inventoriez tout ce que votre produit génère : clés d'API, jetons de session, liens de réinitialisation, clés de signature, identifiants d'invitation.
2. Repérez les sources non cryptographiques : Math.random(), générateurs seedés par l'horloge, UUID version 1, compteurs.
3. Testez l'entropie : générez un grand échantillon, vérifiez l'absence de doublons et de motifs, et contrôlez qu'un redémarrage ne reproduit pas la même séquence.
4. Ajoutez un test au démarrage qui échoue si la source d'aléa renvoie une sortie anormale, car une mise à jour de dépendance ou de configuration peut permuter la source sans bruit.

Comment corriger ?

Utilisez un générateur cryptographique du système (crypto.randomBytes, secrets, getrandom) avec au moins 128 bits d'entropie pour un secret, et 256 bits pour une clé durable. Un correctif ne rétroactive pas les secrets existants : faites tourner tout ce qui a été généré pendant la fenêtre de vulnérabilité. Limitez le débit des points de validation, qui servent d'oracle.

Que change l'accès d'un agent IA à la génération de secrets ?

Les agents créent des secrets plus souvent qu'on ne le pense : ils écrivent du code qui génère des jetons, provisionnent des clés d'API, créent des comptes de service, et de plus en plus des portefeuilles pour des paiements automatisés. Trois risques propres aux agents. Le code généré : un assistant de programmation peut produire un générateur de jetons avec Math.random() ou une graine temporelle ; le défaut passe les tests car la sortie semble aléatoire. Le modèle comme source d'aléa : un grand modèle de langage ne constitue pas un générateur cryptographique, et une consigne du type « génère une clé au hasard » peut produire des valeurs prévisibles ; l'aléa doit venir d'un outil système, jamais du texte du modèle. Et la détention de clés : un agent qui possède une clé de signature ou une phrase de récupération dans son contexte peut être amené à la divulguer par injection de prompt (OWASP LLM01, LLM02), et une clé faible rend ce vol inutile à l'attaquant, qui peut simplement la recalculer.

Les contrôles utiles : génération de secrets par une fonction système auditée, secrets hors du contexte du modèle, plafonds de montant et validation humaine pour toute action de paiement, et rotation après tout incident. Voir la sécurité des agents IA et les clés d'API dans l'historique Git.

Que vérifier côté agent avec la faille d'aléa Coldcard ?

Un test de red team d'agent vérifie d'où viennent les secrets que l'agent crée, ce qu'il en fait, ce qu'il peut signer ou dépenser et ce qu'un contenu piégé lui fait révéler. En cinq jours et pour 1 900 €, le Red Team Agent Express regarde ce qu'un agent fait de clés générées avec un aléa faible. La méthode détaille la démarche.

Quelle leçon en tirer ?

La différence entre un secret et une valeur publique tient à la source d'aléa. Vérifiez-la à l'exécution et pas seulement à l'intégration, traitez les registres publics comme des oracles et faites tourner les secrets dès qu'une faille de génération est connue.