Comment une mauvaise entropie continue de coûter des millions en crypto

Le 31 juillet 2026, un attaquant a vidé environ 500 wallets Bitcoin en 25 minutes. L’opération a déplacé près de 594 BTC, soit environ 38 millions de dollars, et chaque wallet concerné appartenait à quelqu’un ayant justement acheté un hardware wallet pour éviter ce scénario.
 

Coinkite disclosed that COLDCARD firmware had been generating keys using a software pseudorandom number generator rather than the hardware generator built into the device. Two functions in the codebase shared the same name and signature, so the linker selected the wrong one, and the build produced no warning.
 

C’est le dernier épisode d’une longue série. Depuis dix ans, les pertes les plus importantes en cryptomonnaies ne proviennent plus de failles sophistiquées, mais d’un problème bien plus fondamental : une absence de véritable aléa.

Qu’est-ce qui se cache derrière la clé privée ?

Qu’il s’agisse d’une application, d’une extension de navigateur ou d’un appareil physique, un wallet crypto repose sur une opération cruciale : générer des nombres impossibles à deviner ou à reproduire. C’est là tout le sens du mot « entropie » dans ce contexte : la quantité d’imprévisibilité d’un nombre généré.

L’entropie correspond à l’aléa brut utilisé par le wallet pour créer une clé privée, mesuré en bits. Plus il y a de bits, plus l’espace de clés à explorer pour un attaquant est vaste. L’entropie intervient lors de l’initialisation du wallet. Toutes les clés, adresses et signatures générées ensuite suivent des règles mathématiques fixes, sans nouvel apport d’aléa par la suite.

Source de l’entropie

En théorie, un wallet peut obtenir son aléa via un pseudorandom number generator (PRNG) : un algorithme qui étire une petite quantité d’entropie « réelle » pour en produire autant que nécessaire, à condition que la graine de départ soit elle-même imprévisible. 

Un logiciel lancé dans un onglet de navigateur ou sur un téléphone fraîchement démarré commence souvent dans une sorte de chambre de privation sensorielle. Pour générer un nombre vraiment aléatoire, il faut du « bruit » : des entrées imprévisibles issues du monde réel, comme des variations de timing du processeur, des mouvements de souris ou des composants matériels spécialisés.

Dans les toutes premières millisecondes après l’allumage d’un appareil, ces réservoirs de bruit peuvent être vides ou à peine initialisés. Si une bibliothèque cryptographique sollicite le générateur de nombres aléatoires trop tôt, elle puise alors dans une source superficielle, produisant des nombres certes aléatoires, mais issus d’un espace assez restreint pour être exploré de façon exhaustive.

Les navigateurs ajoutent leurs propres contraintes. Math.random() de JavaScript n’a jamais été conçu pour la sécurité et même la fonction plus sûre crypto.getRandomValues() dépend du réservoir d’entropie du système d’exploitation. Si ce réservoir est faible, comme cela peut arriver dans des environnements mobiles, des machines virtuelles ou des appareils IoT dépouillés, l’aléa est compromis avant même d’atteindre le code qui génère votre clé privée.

L’aléa dans la signature des transactions

Lorsque vous signez une transaction Bitcoin ou Ethereum, vous n’utilisez pas directement votre clé privée. Vous générez plutôt un nonce : un nombre unique et aléatoire, combiné à votre clé privée dans l’algorithme ECDSA (Elliptic Curve Digital Signature Algorithm) pour produire une signature.

Mais voici le piège : si le même nonce est utilisé deux fois avec la même clé privée, les calculs mathématiques donnent à l’attaquant tout ce dont il a besoin pour retrouver cette clé privée.
Les signatures ECDSA sont une paire de nombres, (r, s), qui satisfont à une équation spécifique impliquant :

• la clé privée (d),
• le nonce (k), et
• le message de la transaction haché (z).

Si k est identique pour deux messages différents, les équations s’alignent et toute personne voyant les deux signatures peut calculer k. Une fois k connu, d — la clé privée — s’obtient par quelques multiplications et un inverse modulaire.

En 2013, une faille dans la fonction SecureRandom d’Android a conduit les premiers wallets Bitcoin sur cette plateforme à produire des nonces prévisibles. Des fonds ont disparu des wallets avant même que la plupart des utilisateurs ne réalisent le problème.

Contrairement à une erreur de code classique, il est impossible de détecter un manque d’aléa simplement en lisant le code source. Les appels de fonction peuvent sembler corrects, mais à moins de mesurer les bits réellement produits et de réaliser des tests statistiques sur leur imprévisibilité, une faille critique peut rester cachée pendant des mois ou des années, attendant qu’un attaquant patient l’exploite.

Les principales causes de vulnérabilité liées à l’entropie peuvent se résumer ainsi :

• Pénurie d’entropie au démarrage : les appareils fraîchement allumés n’ont pas accumulé assez de bruit environnemental pour initialiser les PRNG.

• Limites des navigateurs : Math.random() de JavaScript n’est pas sécurisé ; même crypto.getRandomValues() dépend du réservoir d’entropie de l’hôte.

• Outils à risque : les générateurs d’adresses personnalisées, scripts offline ou bibliothèques mal entretenues négligent souvent l’aléa au profit de la rapidité ou de la reproductibilité.

• Saisie humaine : les « brainwallets » et phrases choisies par l’utilisateur ont déjà été craquées par simple recherche dans des dictionnaires.

Les cryptographes privilégient depuis longtemps les générateurs matériels de nombres aléatoires (HRNG), aussi appelés « true RNG ». Ils transforment des phénomènes physiques comme le bruit électronique, les fluctuations thermiques ou la désintégration radioactive en bits aléatoires, tout en s’auto-testant en continu pour détecter toute défaillance ou biais.

Comment le matériel corrige le problème

Dans les systèmes à haut niveau d’assurance, la solution est simple : générer les clés à l’intérieur d’une puce embarquant un HRNG certifié, sans jamais laisser ces clés être copiées.

Un secure element est un microcontrôleur conçu pour résister au sabotage. C’est une puce renforcée pour stocker des secrets et réaliser des opérations cryptographiques sans exposer les clés sous-jacentes. On retrouve ce type de composant dans les passeports (pour éviter la copie), les cartes SIM (pour authentifier les appareils sur le réseau mobile) et les cartes de paiement sans contact (pour autoriser les transactions).

Un secure element peut intégrer un générateur matériel de nombres aléatoires, tirant son imprévisibilité de phénomènes physiques comme les fluctuations thermiques ou le jitter d’oscillateur, plutôt que d’algorithmes mathématiques seuls. 

Ces HRNG ne sont pas de simples dispositifs « one shot ». Selon des normes telles que NIST SP 800-90B, ils doivent effectuer des tests de santé continus, contrôlant chaque flux de sortie pour détecter tout biais statistique, bit bloqué ou autre défaillance susceptible de nuire à la qualité de l’aléa avec le temps. Si quelque chose paraît suspect, la puce peut interrompre la génération de clés immédiatement. Dans un bon hardware wallet, le HRNG du secure element alimente directement le processus de génération de clés à l’intérieur même de la puce. 

Tout le « hardware » ne se vaut pas

Le terme hardware wallet recouvre une grande variété de conceptions, et toutes n’offrent pas le même niveau de protection pour l’aléa et l’isolation des clés.

À l’extrémité basse, on trouve des appareils basés sur des microcontrôleurs généralistes, conçus pour la flexibilité plutôt que pour résister aux attaques physiques ou par canaux auxiliaires. Beaucoup incluent un générateur de nombres aléatoires basique. 

Mais il peut s’agir d’un générateur pseudorandom, initialisé à partir de l’état interne du dispositif, et non d’un HRNG pleinement conforme et testé selon les normes requises. Dans ces architectures, la génération de clés peut se faire dans le firmware, la clé privée étant temporairement stockée en RAM ou en mémoire flash. Cela signifie qu’une faille dans le firmware, une attaque par canal auxiliaire ou une manipulation physique peut exposer la clé.
 

À l’inverse, les wallets basés sur un secure element placent à la fois la source d’entropie et la logique de génération des clés dans un environnement résistant au sabotage. Ce modèle impose aussi un contrôle d’accès strict : les opérations cryptographiques (signature, dérivation) sont réalisées dans la puce, seule la signature finale ou la clé publique en sort, jamais le secret lui-même.

Des normes existent déjà

Le problème de l’aléa n’est pas une question scientifique irrésolue. Les cryptographes ont déjà défini ce qu’est une bonne entropie. Le National Institute of Standards and Technology (NIST) américain a publié la série de normes SP 800-90, qui décompose le problème en éléments clairs.

La norme SP 800-90B décrit comment évaluer une source d’entropie : le processus physique ou logiciel qui produit des bits imprévisibles. Elle exige une analyse statistique rigoureuse pour estimer l’entropie réelle de chaque flux de bits, ainsi que des tests de santé intégrés pour surveiller en continu la source et détecter tout biais ou défaillance.

SP 800-90C explique comment combiner cette entropie avec des générateurs déterministes de bits aléatoires (DRBG) pour garantir une sortie robuste même si une source se dégrade.

Un appareil conforme ne se contente pas de produire des nombres aléatoires une fois pour toutes. Il vérifie en continu sa propre « pulsation » : si le motif du HRNG change, si un bit reste bloqué ou si le résultat échoue aux tests statistiques, la génération de clés est stoppée pour éviter de créer des clés faibles.

Comment savoir si vous êtes exposé ?

La plupart des utilisateurs ne peuvent pas mesurer directement l’entropie, mais il est possible de s’interroger sur l’origine et la méthode de génération de vos clés. Si elles ont été créées « dans une page web » ou « sur une vieille application Android », en particulier avant le milieu des années 2010, ces clés sont probablement faibles. La meilleure approche consiste à générer un nouveau wallet sur un appareil matériel utilisant un aléa certifié et documenté, puis à y transférer vos fonds.

Chronologie des attaques sur l’entropie 

Une entropie faible évite à l’attaquant de devoir remonter toute la chaîne. Il lui suffit d’énumérer l’ensemble réduit de clés que le générateur défaillant aurait pu produire, d’en déduire les adresses, puis de vérifier sur la blockchain si elles détiennent des fonds. Quelques exemples marquants :

• 2018 — Arnaque au générateur de seed IOTA : les utilisateurs étaient invités à créer leur seed wallet via un site web. L’opérateur du site conservait une copie de ces seeds et a vidé les fonds par la suite, détournant près de 4 millions de dollars. L’aléa était ici nul : l’attaquant connaissait déjà les nombres.

• 2019 — The Blockchain Bandit : des chercheurs en sécurité ont identifié 732 clés privées Ethereum faibles dans la nature. Un attaquant inconnu surveillait ces adresses depuis des années, siphonnant environ 45 000 ETH dès que des fonds y apparaissaient.

• 2022 — Catastrophe des adresses personnalisées Profanity : l’outil open source Profanity générait des adresses Ethereum personnalisées à partir de seeds avec seulement 32 bits d’entropie, soit environ quatre milliards de possibilités. Une carte graphique moderne peut explorer cet espace en quelques heures. Wintermute, un market maker londonien, a ainsi perdu près de 160 millions de dollars.

• 2023 — Faille de l’extension navigateur Trust Wallet : une divulgation de l’équipe sécurité de Ledger a révélé que l’extension générait des seeds avec environ 32 bits d’entropie. Le problème a été corrigé rapidement et Trust Wallet a remboursé certains utilisateurs, mais pendant plusieurs mois, toute création de wallet via cette extension exposait à un risque.

• 2025 — L’affaire LuBian : l’allégation d’Arkham reste à confirmer, mais si la perte de 127 426 BTC s’explique vraiment par une génération de clés prévisible, ce serait l’exemple ultime d’une seule erreur à la création pouvant condamner des milliards d’actifs.

• 2026 — COLDCARD : Coinkite disclosed that a software pseudorandom generator had replaced the intended hardware generator in shipped firmware. The fallback entered the upstream dependency in May 2018 and reached key generation in March 2021.

  Coinkite estime que l’espace de recherche effectif était d’environ 40 bits sur le matériel Mk3, et 72 bits sur les modèles suivants qui mélangeaient des données du secure element. Ces deux chiffres restent nettement en dessous de l’objectif de 128 bits.

  Un garde-fou existait pour éviter précisément ce cas. Il testait si une macro de configuration était définie, et non si sa valeur était différente de zéro ; la macro était bien définie, mais à zéro, donc le test passait et l’erreur n’était jamais déclenchée.

Vous envisagez de quitter COLDCARD ?

Tangem génère votre clé à l’intérieur d’une puce secure element certifiée, à l’aide d’un générateur matériel de nombres aléatoires. 

Si vous en avez assez de vous soucier des seed phrases, notre configuration sans seed signifie : aucun mot de passe de 12 ou 24 mots à écrire, photographier ou égarer ; exactement ce qui a causé la plupart des piratages de wallets dans le passé.

Auditée indépendamment par Cure53, Kudelski et Riscure. Conçue pour répondre à ce risque précis.

Déplacez vos cryptos là où l’aléa est réellement aléatoire. Découvrez Tangem Wallet.