Bitcoin : comprendre le « hack » qui n’a pas touché le protocole Par Julien Riposo
Par Julien Riposo, CEO & Founder – J.R. Enterprise
Présenté comme un « piratage de Bitcoin », l’incident ayant affecté certains portefeuilles matériels COLDCARD révèle une vulnérabilité plus précise : la génération des secrets cryptographiques. La blockchain, le mécanisme de consensus et la cryptographie elliptique de Bitcoin ont continué de fonctionner normalement. La faiblesse se situait en amont, au moment où certains appareils produisaient la phrase de récupération permettant de dériver les clés privées [1,2,3].
Dans un article publié sur LinkedIn, Maneesh Gupta compare la situation à celle d’un coffre-fort dont la combinaison aurait été fabriquée à partir d’une formule insuffisamment aléatoire. L’attaquant n’aurait alors pas besoin de forcer la porte : il lui suffirait de retrouver la combinaison en reproduisant le processus de génération. Cette analogie résume correctement l’incident COLDCARD [1].
La faille provenait d’une erreur d’intégration logicielle apparue lors d’une évolution du firmware en 2021. Le système destiné à produire des nombres aléatoires utilisait, dans certaines configurations, un générateur logiciel déterministe de MicroPython plutôt que la source matérielle d’aléa prévue. Pour les modèles plus récents, des données provenant d’éléments sécurisés étaient bien ajoutées, mais une partie de cette information était réduite à seulement 32 bits avant d’alimenter le générateur. Des utilisateurs ont signalé des pertes et Block Engineering a publié son analyse en considérant qu’une exploitation active était en cours [2,3].
Coinkite, le fabricant de COLDCARD, a confirmé que le choix de la bibliothèque cryptographique libsecp256k1 était approprié. L’erreur concernait le chemin logiciel emprunté pour produire l’aléa : la bonne fonction existait dans le code, mais la génération des portefeuilles appelait une autre implémentation. Le code source était public, sans que les revues successives aient vérifié jusqu’au bout quelle fonction était effectivement atteinte lors de la création d’une clé [3].
Dans le commentaire technique que j’ai publié sous l’analyse de Maneesh Gupta, j’ai résumé la distinction de la manière suivante : le consensus de Bitcoin et secp256k1 n’ont pas été brisés ; la chaîne d’entropie de COLDCARD l’a été [4].
L’entropie mesure ici l’imprévisibilité réelle du secret. Une quantité pertinente est la min-entropie conditionnelle :
H∞(S | Z) = −log2(maxs,z P(S = s | Z = z))
où S désigne le secret généré et Z l’information éventuellement accessible à l’attaquant. Plus une valeur particulière de S devient probable lorsque Z est connu, plus la sécurité diminue. Les recommandations du NIST consacrées aux générateurs aléatoires placent précisément l’évaluation de la min-entropie, les tests de santé et la validation des sources d’aléa au cœur de leur architecture [5].
Cette distinction explique pourquoi l’utilisation de SHA-256 ne réparait pas le problème. Pour toute fonction déterministe f,
H∞(f(S) | Z) ≤ H∞(S | Z)
Une famille limitée à 240 secrets possibles reste une famille d’au plus 240 résultats après hachage, même lorsque chaque résultat est écrit sur 256 bits. La fonction peut rendre la distribution visuellement plus uniforme, mais elle ne crée pas les 216 bits d’incertitude manquants. Le checksum BIP-39 ne produit pas davantage d’entropie [2,4,7].
Une fois la phrase de récupération retrouvée, l’attaquant peut dériver les clés privées et signer des transactions valides. Du point de vue du réseau Bitcoin, ces transactions respectent les règles du protocole. Aucun bloc n’a été falsifié, aucune signature n’a été mathématiquement cassée et aucune règle de consensus n’a été contournée. La blockchain a exécuté correctement des ordres signés avec des clés obtenues grâce à une faiblesse externe [2].
L’incident rappelle ainsi que le stockage hors ligne ne garantit pas automatiquement la sécurité. Un portefeuille peut ne jamais avoir été connecté à Internet et rester vulnérable si son secret a été mal généré dès l’origine. La conservation des actifs numériques dépend d’une chaîne complète : source physique d’aléa, conditionnement, générateur déterministe, firmware, matériel, sauvegarde et pratiques de l’utilisateur [1,2,3].
Pour les détenteurs concernés, une simple mise à jour du firmware ne suffit pas à renforcer rétroactivement une ancienne phrase de récupération. Coinkite recommande d’installer la version corrigée, de créer une nouvelle phrase, puis de transférer les fonds vers le nouveau portefeuille. Le fabricant précise également que l’ajout initial d’au moins 50 lancers de dés indépendants et privés peut avoir fourni une entropie extérieure suffisante dans certaines configurations [3].
À plus long terme, une architecture défendable peut combiner plusieurs sources réellement indépendantes : générateur matériel, élément sécurisé et source privée telle que des dés. Pour des chaînes binaires de même longueur, une construction possible consiste à calculer
R = RTRNG ⊕ RSE ⊕ Rdice
puis à injecter le résultat dans un générateur déterministe ou une fonction de dérivation standard, avec séparation explicite des domaines. Lorsqu’une des sources est uniforme et indépendante des autres, le XOR final reste uniforme. Le système doit toutefois échouer de manière fermée si une source déclarée obligatoire devient inaccessible, plutôt que de revenir silencieusement vers un générateur prévisible. Cette approche prolonge les principes du NIST, qui articulent sources d’entropie validées et mécanismes DRBG standardisés [4,5,6].
Pour les patrimoines importants, une signature multisig hétérogène de type deux-sur-trois apporte une protection supplémentaire. Les trois clés doivent provenir de matériels, de fabricants et de chaînes d’entropie distincts. La compromission du générateur d’un appareil ne fournit alors pas, à elle seule, le quorum nécessaire pour dépenser les fonds. Block Engineering souligne également qu’un dispositif composé uniquement d’appareils vulnérables conserve la même faiblesse : la diversité doit être réelle [2,4].
L’incident COLDCARD dépasse finalement le seul univers Bitcoin. À mesure que la finance adopte les actifs numériques, la tokenisation et les infrastructures on-chain, l’audit devra suivre le secret depuis sa source physique jusqu’à son usage final. Vérifier la solidité d’un algorithme reconnu ne suffit plus lorsque son intégration peut rediriger silencieusement l’exécution vers un composant plus faible.
Bitcoin n’a pas été piraté. L’événement montre plutôt qu’une infrastructure décentralisée peut rester intacte tandis qu’un maillon périphérique compromet les utilisateurs. La prochaine génération de conservation numérique devra donc rendre vérifiable non seulement ce qui se passe sur la blockchain, mais aussi la manière dont les clés sont créées avant d’y entrer.
Références
[1] Gupta, M., « The Bitcoin Hack That Wasn’t a Hack », LinkedIn, 5 août 2026. Disponible en ligne : linkedin.com/pulse/bitcoin-hack-wasnt-maneesh-gupta-a7kjf
[2] Block Bitcoin Engineering and Security, en collaboration avec des chercheurs en sécurité anonymes, « Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware », Block Engineering Blog, 30 juillet 2026. Disponible en ligne : engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
[3] Coinkite, « Technical Deep Dive into the Entropy Issue », Coinkite Blog, 30 juillet 2026, mis à jour le 1er août 2026. Disponible en ligne : blog.coinkite.com/entropy-technical-backgrounder
[4] Riposo, J., commentaire technique publié sous l’article de Maneesh Gupta « The Bitcoin Hack That Wasn’t a Hack », LinkedIn, août 2026. Disponible en ligne : linkedin.com/pulse/bitcoin-hack-wasnt-maneesh-gupta-a7kjf
[5] Turan, M. S., Barker, E., Kelsey, J., McKay, K., Baish, M. et Boyle, M., Recommendation for the Entropy Sources Used for Random Bit Generation, NIST Special Publication 800-90B, janvier 2018. DOI : 10.6028/NIST.SP.800-90B
[6] Barker, E., Kelsey, J., McKay, K., Roginsky, A. et Turan, M. S., Recommendation for Random Bit Generator (RBG) Constructions, NIST Special Publication 800-90C, septembre 2025. DOI : 10.6028/NIST.SP.800-90C
[7] Palatinus, M., Rusnak, P., Voisine, A. et Bowe, S., « BIP-39: Mnemonic Code for Generating Deterministic Keys », Bitcoin Improvement Proposals, 10 septembre 2013. Disponible en ligne : github.com/bitcoin/bips/blob/master/bip-0039.mediawiki