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. Près de 594 BTC, soit environ 38 millions de dollars, ont été transférés, et chaque wallet concerné appartenait à quelqu’un ayant acheté un hardware wallet précisément 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.
 

Ceci n’est que la dernière d’une longue série. Au cours de la dernière décennie, les pertes les plus importantes en cryptomonnaies proviennent moins d’exploits sophistiqués que d’un problème plus fondamental : une « randomness » qui ne l’était pas assez.

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, tout wallet crypto repose sur une opération critique : générer des nombres impossibles à deviner ou à recréer. C’est tout le sens du mot « entropie » ici : la quantité d’imprévisibilité dans un nombre généré.

L’entropie est la source de hasard brute qu’un wallet utilise pour créer une clé privée, mesurée en bits. Plus il y a de bits, plus l’espace de clés à explorer pour un attaquant est vaste. Cette entropie intervient lors de la création du wallet. Toutes les clés, adresses et signatures générées ensuite suivent des règles mathématiques fixes : aucune nouvelle « randomness » n’est introduite par la suite.

Source d’entropie

En théorie, un wallet peut obtenir de la « randomness » via un pseudorandom number generator (PRNG) : un algorithme qui étend une petite quantité d’entropie « réelle » en autant qu’il en faut, mais uniquement si la graine de départ est 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, un programme a besoin de « 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 trop tôt le générateur de nombres aléatoires, elle puise dans une source trop pauvre, produisant des nombres certes aléatoires, mais dans un espace si restreint qu’il peut ê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 pool d’entropie du système d’exploitation. Si ce pool est faible, comme cela peut être le cas dans des sandbox mobiles, des machines virtuelles ou des appareils IoT limités, la « randomness » est compromise avant même d’atteindre le code qui génère votre clé privée.

La « randomness » dans la signature des transactions

Lorsque vous signez une transaction Bitcoin ou Ethereum, vous n’utilisez pas directement votre clé privée. À la place, vous générez un nonce : un nombre aléatoire unique, 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é.
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 transaction haché (z).

Si k est identique pour deux messages différents, les équations s’alignent et toute personne ayant accès aux deux signatures peut calculer k. Une fois k connu, d — la clé privée — s’obtient en quelques multiplications et une inversion modulaire.

En 2013, une faille dans la fonction SecureRandom d’Android a provoqué la génération de nonces prévisibles par les premiers wallets Bitcoin sur la plateforme. 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 une mauvaise « randomness » en lisant simplement le code source. Les appels de fonctions peuvent sembler corrects, mais à moins de mesurer les bits effectivement produits et de réaliser des tests statistiques pour vérifier leur imprévisibilité, une faille fatale peut rester invisible pendant des mois ou des années, attendant qu’un attaquant patient l’exploite.

Voici pourquoi l’entropie demeure une vulnérabilité persistante :

• Pénurie d’entropie au démarrage : les appareils tout juste allumés n’ont pas encore 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 pool d’entropie de l’environnement d’exécution.

• Outils non sécurisés : générateurs d’adresses personnalisées, scripts hors ligne ou bibliothèques mal entretenues négligent souvent l’aléa au profit de la rapidité ou de la reproductibilité.

• Facteur humain : les « brainwallets » et phrases choisies par l’utilisateur ont été cassées par de simples attaques par dictionnaire.

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

Comment le matériel résout 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 intégrant un HRNG certifié, sans jamais permettre leur duplication.

A secure element is a purpose-built, tamper-resistant microcontroller. It is a fortified chip designed to store secrets and perform cryptographic operations without revealing the underlying keys. They are the same class of component used in passports to prevent cloning, SIM cards to authenticate devices to mobile networks, and contactless payment cards to authorize transactions.

Un secure element peut embarquer un générateur de nombres aléatoires matériels, dont l’imprévisibilité provient du bruit physique — fluctuations thermiques ou jitter d’oscillateur — plutôt que d’algorithmes mathématiques seuls. 

Ces HRNG ne sont pas de simples dispositifs « one-shot ». Selon des normes comme  NIST SP 800-90B, ils doivent réaliser des tests de santé en continu sur chaque flux de sortie pour détecter tout biais statistique, bit bloqué ou autre défaillance susceptible de dégrader l’aléa au fil du temps. Si une anomalie est détectée, la puce peut arrêter la génération de clés immédiatement. Dans un bon hardware wallet, le HRNG du secure element injecte directement l’aléa dans le processus de génération de clés, au sein même de la puce. 

Tout le « hardware » ne se vaut pas

Le terme hardware wallet recouvre un large éventail de conceptions, et tous n’offrent pas le même niveau de protection pour l’aléa et l’isolation des clés.

À l’entrée de gamme, on trouve des appareils basés sur des microcontrôleurs généralistes, conçus pour la flexibilité plutôt que pour résister à des attaques physiques ou par canaux auxiliaires. Beaucoup intègrent 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 de l’appareil, et non d’un HRNG pleinement conforme et testé selon les normes requises. Dans ces architectures, la génération de clé se fait parfois dans le firmware, la clé privée étant temporairement stockée en RAM ou en mémoire flash. Une faille dans le firmware, une attaque par canal auxiliaire ou une manipulation physique peut alors exposer la clé.
 

À l’inverse, les wallets à secure element placent à la fois la source d’entropie et la logique de génération de clé dans un environnement inviolable. 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, et seule la signature finale ou la clé publique en sort, jamais le secret lui-même.

Des standards existent déjà

Le problème de la « randomness » n’est pas un défi scientifique non résolu. 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 sujet en éléments clairs.

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, 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 de bits aléatoires déterministes (DRBG), afin que la sortie reste forte 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 bruit du HRNG change, si un bit se bloque ou si la sortie ne passe plus les seuils statistiques, le système arrête la génération de clés 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 le lieu 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 ancienne app Android », en particulier avant le milieu des années 2010, ces clés sont probablement faibles. L’approche la plus sûre consiste à générer un nouveau wallet sur un appareil matériel utilisant une « randomness » certifiée et documentée, puis à y transférer vos fonds.

Chronologie des attaques sur l’entropie 

Une faible entropie supprime la nécessité de remonter la piste. L’attaquant énumère le petit ensemble de clés que le générateur défaillant aurait pu produire, dérive les adresses pour chaque candidat, puis vérifie ces adresses sur la blockchain pour y trouver un solde. Voici quelques exemples :

• 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 plus tard, détournant environ 4 millions de dollars. Ici, l’aléa était 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 qu’un solde apparaissait.
   

• 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 perdu environ 160 millions de dollars de cette façon.
   

• 2023 — Faille de l’extension navigateur Trust Wallet : selon une divulgation de l’équipe sécurité de Ledger, l’extension produisait des seeds de wallet avec seulement 32 bits d’entropie. Le bug a été corrigé rapidement, Trust Wallet a remboursé certains utilisateurs, mais pendant plusieurs mois, toute création de wallet via l’extension était à risque.
   

• 2025 — L’affaire LuBian : l’affirmation d’Arkham reste à confirmer, mais si la perte de 127 426 BTC s’explique bien par une génération de clés prévisible, ce serait l’exemple ultime d’une simple 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 ultérieurs qui mélangeaient des données du secure element. Ces deux valeurs restent en dessous de l’objectif de 128 bits.

  Un garde-fou existait pour éviter précisément ce scénario. Il testait si une macro de configuration était définie, et non si sa valeur était différente de zéro : la macro était fixée à zéro, le test était donc validé et l’erreur n’a jamais été détecté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 de nombres aléatoires matériel. 

Si vous en avez assez de vous soucier des seed phrases, notre configuration sans seed signifie qu’il n’y a plus de phrases de 12 ou 24 mots à écrire, photographier ou perdre : la cause de la plupart des hacks de wallets passés.

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

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