Devinée, pas volée : le danger des clés privées faibles

Le pire désastre de portefeuille matériel de l’été 2026 n’a pas commencé par un e-mail piégé, ni par une signature aveugle, ni par une clé à molette. Le 30 juillet, des Bitcoin ont commencé à quitter des milliers d’adresses Coldcard, des appareils réputés pour rester hors ligne, coupés d’Internet, entre les mains de détenteurs souvent chevronnés. Personne n’avait cliqué sur rien. Personne n’avait rien signé. Et pourtant, les fonds partaient.

La raison n’était pas une clé volée, mais une clé qui n’avait jamais vraiment été secrète. Générée des années plus tôt avec trop peu de hasard, elle était devinable pour quiconque connaissait la faille. C’est une catégorie à part de compromission de clés privées : non pas un vol, mais un défaut de naissance. Chez HOGE Wire, nous avons déjà disséqué le versant vol, de la signature aveugle au casse par ingénierie sociale. Ce dossier porte sur le coin le plus ancien et le plus silencieux du problème : l’entropie ratée.

De l’alerte Android de 2013 au fiasco Coldcard de 2026, la même erreur revient sans cesse : un générateur de nombres aléatoires qui n’en est pas un. Voici ce qu’est réellement l’entropie d’une clé, pourquoi on ne peut pas la corriger après coup, et comment produire une clé qui soit, elle, réellement impossible à deviner.

Devinée, pas volée : une compromission dès la naissance

Une clé privée est compromise dès lors qu’un tiers en prend le contrôle. La voie la plus connue est le vol : hameçonnage, logiciel malveillant, signature d’une transaction trafiquée, ou coercition physique. Toutes ces attaques ont un point commun : l’adversaire doit atteindre votre secret, là où il se trouve. Votre hygiène compte, votre appareil compte, votre vigilance compte.

La compromission par faiblesse d’entropie fonctionne à l’envers. L’attaquant n’a pas besoin d’approcher votre appareil, ni de vous piéger, ni même de savoir que vous existez. Il lui suffit de savoir que le générateur qui a produit votre clé puisait dans un réservoir de hasard trop maigre, puis de balayer ce réservoir avec quelques cartes graphiques. La clé n’est pas dérobée : elle est recalculée. Contre ce mode opératoire, ni la plaque en acier gravée, ni la phrase de passe supplémentaire, ni l’isolation totale de l’appareil ne servent à rien. Le mal était déjà fait au moment de la génération.

C’est ce qui rend cette famille d’incidents si déroutante pour les victimes. Elles ont, en apparence, tout bien fait : stockage à froid, sauvegarde de la phrase de récupération, appareil dédié. Le problème est qu’un seul maillon a lâché en amont de tout le reste, invisible et antérieur à la moindre bonne pratique : la qualité du hasard. Et ce maillon ne se voit pas à l’usage. Une clé faible signe des transactions, reçoit des fonds et affiche une adresse tout à fait normale, jusqu’au jour où quelqu’un la devine.

Coldcard, l’étincelle de 2026

L’affaire Coldcard a remis le sujet sous les projecteurs. Selon TRM Labs, près de 1 816 BTC, soit environ 116 millions de dollars (de l’ordre de 100 millions d’euros), ont été siphonnés de plus de 5 200 adresses, en quatre vagues successives à partir du 30 juillet 2026. La première vague a suffi à drainer plus d’un millier d’adresses en une quarantaine de minutes, d’après The Hacker News. Galaxy Research et TechCrunch ont évoqué un total pouvant atteindre 130 millions de dollars si une quatrième vague se confirme.

La cause racine n’a rien d’un piratage spectaculaire. Une erreur de configuration dans le microprogramme (firmware) version 4.0.1, publié en mars 2021, vérifiait si le générateur d’aléa matériel de l’appareil était défini, mais pas s’il était réellement activé. Résultat : sur les appareils concernés, la génération de graine retombait sur un générateur logiciel de secours, bien plus prévisible. L’entropie réelle s’effondrait des 128 bits attendus vers quelques dizaines de bits seulement, une plage que des machines modernes parcourent sans difficulté. Autrement dit, la clé pouvait être reconstituée à distance, sans jamais toucher l’appareil hors ligne.

Le plus cruel tient dans la remédiation. Comme l’a résumé TRM Labs, «mettre à jour le firmware corrige le problème pour les futurs portefeuilles, mais ne protège pas les portefeuilles dont la graine a été générée sous le firmware vulnérable». Une clé produite en 2021 avec trop peu de hasard reste faible pour toujours. Aucune mise à jour ne peut rétroactivement lui rendre l’aléa qu’elle n’a jamais eu. Les détenteurs concernés n’avaient qu’une option : transférer leurs fonds vers une clé neuve, générée correctement, et espérer arriver avant les attaquants. L’argument marketing du portefeuille hors ligne, censé être imprenable, s’est retourné : l’isolation n’a servi à rien, puisque rien n’a eu besoin d’atteindre l’appareil.

Ce que « entropie » veut vraiment dire

Une clé privée Bitcoin ou Ethereum est, au fond, un nombre de 256 bits. Tiré parfaitement au hasard, ce nombre a 2^256 valeurs possibles, un espace si vaste qu’il dépasse le nombre d’atomes dans l’univers observable. Balayer cet espace par force brute est physiquement impossible, et le restera même face aux ordinateurs classiques les plus puissants. C’est ce qui fonde toute la sécurité de l’auto-conservation : personne ne peut deviner un nombre correctement aléatoire de 256 bits.

Le mot décisif est «correctement». L’entropie mesure l’imprévisibilité réelle derrière ce nombre, c’est-à-dire la taille du réservoir dans lequel il a été puisé. Si le générateur ne tire en pratique que dans un ensemble de 2^32 possibilités, environ 4,3 milliards, l’espace théorique de 2^256 ne sert à rien : une seule carte graphique parcourt 4,3 milliards de candidats en quelques minutes. Ce qui compte n’est pas la longueur de la clé sur le papier, mais l’entropie disponible au moment de la génération.

La norme BIP-39, qui régit les phrases de récupération de 12 à 24 mots, exige entre 128 et 256 bits d’entropie. Une phrase de 12 mots encode 128 bits, une phrase de 24 mots en encode 256. Tout l’enjeu tient dans l’écart entre une clé qui «ressemble» à 256 bits et une clé qui ne dispose en réalité que de 32 bits d’imprévisibilité. C’est précisément dans cet écart que se logent, un à un, tous les désastres que nous allons parcourir.

Une image aide à saisir l’enjeu. Imaginez un cadenas à combinaison affichant seize roues de chiffres : sur le papier, le nombre de combinaisons est astronomique. Mais si le fabricant, par erreur, bloque quatorze de ces roues sur zéro et n’en laisse tourner que deux, il ne reste que cent combinaisons à essayer, quel que soit l’aspect imposant du cadenas. Une clé privée fonctionne de la même façon : sa longueur affichée ne dit rien du nombre de valeurs réellement atteignables. Un générateur défaillant, c’est le fabricant qui bloque les roues. Le voleur n’a pas besoin de crocheter la serrure ; il lui suffit de connaître le défaut d’usine et d’essayer les combinaisons restantes.

Le péché à 32 bits : le Mersenne Twister qui ne meurt jamais

Un même coupable revient dans la plupart de ces affaires : le Mersenne Twister, alias mt19937. C’est un générateur pseudo-aléatoire (PRNG) rapide et statistiquement excellent, parfait pour une simulation scientifique ou un jeu vidéo. Il a un défaut rédhibitoire pour la cryptographie : il est déterministe et se réamorce à partir d’une seule graine de 32 bits. Qui connaît la graine reproduit toute la suite. L’employer pour fabriquer des clés revient à réduire tout l’espace à environ 4 milliards de possibilités.

La distinction cruciale oppose un PRNG ordinaire à un CSPRNG, un générateur pseudo-aléatoire à vocation cryptographique. Le second (comme getrandom sur Linux ou l’interface système équivalente) puise dans un réservoir d’entropie alimenté par du bruit physique et reste imprévisible même si l’on observe une partie de sa sortie. Le premier, non. Le Ledger Donjon, laboratoire de sécurité de Ledger, l’a formulé sans détour à propos de l’un de ces incidents : «le PRNG utilisé est un Mersenne Twister, et il ne devrait pas être employé à des fins cryptographiques ; mt19937 prend une unique valeur de 32 bits comme graine d’entrée».

Cette erreur a la vie dure. Elle ressurgit d’une année sur l’autre, dans des outils différents, écrits par des équipes différentes, comme une même faille qui frappe deux fois. La raison est presque culturelle : le mt19937 est la fonction de hasard par défaut dans d’innombrables bibliothèques et langages, celle vers laquelle un développeur pressé se tourne par réflexe. Dans un jeu, c’est sans conséquence. Dans un portefeuille, c’est une porte laissée grande ouverte.

Quinze ans de clés faibles

Le tableau ci-dessous rassemble les principaux épisodes documentés où des clés ont été compromises non par vol, mais par faiblesse du hasard à la génération. Les montants sont ceux rapportés par les sources au moment des faits ; pour les cas anciens, ils sont exprimés dans la devise d’origine.

Profanity : la vanité à 160 millions de dollars

En septembre 2022, le teneur de marché Wintermute a perdu environ 160 millions de dollars (à l’époque, à peu près autant en euros, l’EUR et l’USD étant proches de la parité). L’origine tenait à une coquetterie : une adresse dite «vanity», commençant par une longue série de zéros, générée avec l’outil Profanity. Pour produire de telles adresses lisibles, Profanity amorçait son générateur avec une valeur de seulement 32 bits, ce qui rendait toute la clé calculable par force brute.

La faille avait été signalée en amont. Les équipes de 1inch avaient publiquement averti que les adresses issues de Profanity étaient dangereuses, estimant qu’avec un millier de cartes graphiques, un attaquant pouvait retrouver n’importe quelle adresse vanity de sept caractères en une cinquantaine de jours, d’après The Block. Le fondateur de Wintermute, Evgeny Gaevoy, a reconnu une erreur opérationnelle ; l’entreprise est restée solvable. La leçon est nette : optimiser une clé pour son apparence, c’est sacrifier son entropie. Le beau et le sûr tirent ici dans des directions opposées.

L’affaire a eu un mérite : forcer une prise de conscience sur les générateurs d’adresses «esthétiques». Beaucoup d’équipes utilisaient des outils similaires pour obtenir des adresses de contrats ou de trésorerie commençant par une signature reconnaissable, sans mesurer que ce raffinement cosmétique imposait un raccourci fatal au hasard. Après Profanity, la plupart des outils de vanity sérieux ont été soit abandonnés, soit reconstruits autour d’un vrai CSPRNG. Mais des adresses générées à l’époque circulent encore, et rien n’oblige leurs détenteurs à en changer tant qu’ils ignorent le danger. Une faille d’entropie ne fait pas de bruit ; elle attend.

Milk Sad : de l’horloge à la clé, sans hasard ajouté

En 2023, des chercheurs ont mis au jour une faille surnommée «Milk Sad», dans l’outil en ligne de commande Libbitcoin Explorer (bx), utilisé par des développeurs et des services. Sa commande de génération de graine s’appuyait sur std::mt19937, le même Mersenne Twister, amorcé par l’heure système sur 32 bits. Répertoriée sous CVE-2023-39910 avec un score CVSS de 7,5, la vulnérabilité a été exploitée dans la nature dès l’été 2023, déplaçant plus de 900 000 dollars.

L’explication des chercheurs, sur le site de divulgation, reste la meilleure image pédagogique de tout le problème. En substance : la commande prenait 32 bits de temps d’horloge de haute précision, les passait au mixeur d’une fonction de dérivation, puis les étendait à 256 bits, sans jamais ajouter la moindre information nouvelle. On peut gonfler 32 bits pour qu’ils ressemblent à 256 bits en sortie ; on ne peut pas créer de l’entropie qui n’a jamais existé. La clé finale paraissait longue et robuste, mais restait, au fond, un nombre de 32 bits déguisé.

Milk Sad illustre aussi pourquoi ces failles restent longtemps invisibles. L’outil bx était un couteau suisse en ligne de commande, intégré à des scripts, des tutoriels et des services d’infrastructure ; personne ne relançait sa génération de graine sous prétexte qu’elle fonctionnait. Une clé sortait, une adresse s’affichait, les fonds arrivaient. Rien, dans l’usage quotidien, ne trahissait la faiblesse. Ce n’est qu’en rétro-ingénierie de la fonction de génération que les chercheurs ont compris que des milliers de portefeuilles partageaient un même petit ensemble de graines possibles. Entre-temps, ces clés avaient servi pendant des années, offrant aux attaquants une cible patiente et parfaitement statique.

Le navigateur, cette fabrique de clés fragiles

Les plateformes généralistes, navigateurs et systèmes mobiles, ont fourni certaines des pires sources de hasard de l’histoire de la crypto. En novembre 2022, l’extension de navigateur Trust Wallet a été touchée par une variante exacte du péché à 32 bits : dans plusieurs versions, la génération de mnémoniques reposait sur un mt19937 amorcé par une seule valeur de 32 bits, ramenant l’univers des phrases possibles à environ 4 milliards, cassables au GPU et sans la moindre interaction de l’utilisateur. Le problème a été signalé à Binance le 17 novembre 2022, corrigé en quelques jours, et le Ledger Donjon a reçu une prime de 100 000 dollars pour sa découverte, d’après Ledger. Environ 30 millions de dollars d’actifs étaient exposés.

Plus ancienne et plus vaste, la faille «Randstorm» a concerné les portefeuilles créés entre 2011 et 2015 avec la bibliothèque BitcoinJS, sur laquelle s’appuyaient de nombreux services de l’époque, y compris les premiers portefeuilles Blockchain.info. Le composant SecureRandom reposait sur le Math.random du navigateur, dont l’imprévisibilité pouvait tomber sous les 48 bits, pire encore avant 2012. Révélée en novembre 2023 par la société Unciphered, qui l’a découverte en récupérant un portefeuille de 2014, la faiblesse aurait potentiellement exposé jusqu’à 1,4 million de BTC, selon Dark Reading, même si tous ces fonds n’ont pas été volés.

Enfin, en 2013, une alerte officielle de bitcoin.org a signalé que la classe SecureRandom d’Android était défaillante. Le défaut produisait non seulement des clés faibles, mais aussi des nonces ECDSA réutilisés lors des signatures. Or réutiliser le nonce d’une signature permet, à partir de deux transactions, de recalculer la clé privée : un double coup qui a vidé des portefeuilles Android jusqu’à ce que les applications intègrent un correctif. Le point commun de ces trois épisodes est le même : livrer de la cryptographie de valeur avec le générateur de hasard d’un environnement qui n’a jamais été conçu pour cela.

Brainwallets : le cerveau humain n’est pas un générateur d’aléa

Il existe une forme d’entropie faible que personne n’a codée par erreur : celle que les utilisateurs se sont infligée volontairement. Les «brainwallets» dérivent une clé privée du haché d’une phrase de passe choisie par un humain, l’idée séduisante étant de ne rien avoir à stocker, juste à mémoriser. Le problème est que les choix humains sont désespérément peu aléatoires : citations, paroles de chansons, versets, mots de passe recyclés. Un attaquant n’a qu’à hacher des milliards de phrases plausibles et à comparer aux adresses financées.

Le chercheur en sécurité Ryan Castellucci l’a démontré dès la DEF CON 23, en 2015, avec son outil Brainflayer. Selon CoinDesk, la quasi-totalité des brainwallets ayant jamais été financés avait fini par être balayée par des attaquants ; Castellucci a lui-même cassé une adresse détenant 250 BTC et en a restitué le contenu. Ses formules sont restées célèbres : «il semble vraiment, vraiment difficile d’empêcher les gens de choisir le nom de leur chien», et, sur l’inertie du secteur, «on peut crier sur tous les toits qu’une chose est faible et vulnérable, beaucoup resteront dans le déni tant qu’il n’existe pas de preuve de concept fonctionnelle».

La morale dépasse les brainwallets : l’entropie que l’on croit fabriquer dans sa tête n’en est pas. Un cerveau humain est un très mauvais dé, biaisé vers le familier et le prononçable. C’est aussi pour cela que les bonnes pratiques déportent entièrement la génération du hasard vers des sources physiques mesurables, hors de portée de nos travers.

Pourquoi une clé faible ne se corrige jamais

C’est le point le plus contre-intuitif, et le plus grave. Dans la sécurité logicielle habituelle, on découvre une vulnérabilité, on publie un correctif, on met à jour, on passe à autre chose. Une clé cryptographique n’obéit pas à cette logique. Le correctif ne répare que la génération future ; la clé déjà créée, elle, reste faible à jamais. Il n’existe aucun moyen d’insuffler rétroactivement du hasard dans un secret qui en manquait dès l’origine.

La seule remédiation possible est une migration : générer une clé neuve, correctement aléatoire, et y transférer les fonds au plus vite. Mais cette fenêtre est une course. Dès que la faille est publique, tout le monde connaît le même réservoir réduit, et les portefeuilles vulnérables deviennent une file d’attente que les attaquants vident par ordre de solde décroissant. Les victimes de Coldcard, d’Android ou de Milk Sad se sont toutes retrouvées dans cette situation : averties d’un danger déjà présent dans une clé qu’elles utilisaient parfois depuis des années.

Un corollaire dérange l’industrie de l’audit. Un portefeuille peut passer une revue de code irréprochable et livrer malgré tout des clés faibles, parce que le défaut se niche dans un chemin de configuration ou une dépendance, pas dans la logique métier auditée. Le firmware de Coldcard était ouvert et scruté ; la faille tenait à un test qui vérifiait la mauvaise condition. C’est le même paradoxe que celui d’un oracle manipulé malgré tous les contrôles, cet angle mort qui ne meurt jamais : l’audit valide ce qu’il regarde, or il ne regarde pas toujours la qualité du hasard.

Bien générer une clé : du CSPRNG au TRNG matériel

La défense contre la compromission de naissance se joue entièrement au moment de la génération. Le socle est l’usage d’un CSPRNG, jamais d’un PRNG généraliste : sur un système d’exploitation moderne, l’appel système dédié (getrandom, un /dev/urandom bien alimenté, l’API de la plateforme) puise dans un réservoir d’entropie mêlant plusieurs sources de bruit physique. Au-dessus, un portefeuille sérieux confie la génération à un élément sécurisé doté d’un vrai générateur matériel (TRNG), qui tire son aléa de phénomènes physiques (bruit thermique, gigue d’horloge) plutôt que d’un algorithme.

Pour qui veut ajouter sa propre marge de sécurité, BIP-39 autorise l’apport d’entropie externe : un dé à six faces fournit environ 2,58 bits par lancer, si bien qu’une centaine de lancers suffit à constituer 256 bits vérifiables à la main, sans faire confiance à un seul composant. Une pièce de monnaie, à un bit par lancer, fait le même travail en plus long. À l’échelle institutionnelle, la génération de clés distribuée (DKG) et le calcul multipartite (MPC) suppriment carrément le point unique de défaillance : la clé n’est jamais assemblée en un seul endroit, et son entropie provient de plusieurs parties indépendantes. La frontière actuelle est l’entropie vérifiable, où le générateur prouve, par attestation, que son aléa était sain.

Reste la dimension humaine, souvent négligée. Un excellent générateur ne sert à rien si la graine est ensuite affichée sur un écran connecté, photographiée, saisie dans un gestionnaire de mots de passe synchronisé ou stockée en clair dans le cloud. La qualité de l’entropie se défend aussi par la procédure : générer hors ligne, vérifier l’appareil, ne jamais ressaisir une phrase de récupération sur une machine en réseau, et privilégier des sources d’aléa que l’on peut inspecter soi-même. Le hasard est une chaîne, et sa solidité se mesure à son maillon le plus faible, du silicium qui le produit jusqu’aux mains qui le manipulent.

Détecter une exposition et réagir avant les attaquants

La difficulté propre à cette menace est qu’on ne peut pas auditer l’entropie d’une clé de l’extérieur : une clé faible est en tout point identique à une clé solide. La détection est donc indirecte, et elle repose sur la traçabilité. Tenir un inventaire de la manière dont chaque clé est née, l’appareil, la version de firmware ou de logiciel, la date de génération, est de loin le renseignement le plus utile le jour où une divulgation tombe. Sans cette provenance, on ignore si l’on est concerné, et l’incertitude paralyse au pire moment.

Quand une faille est rendue publique, la réaction se joue en trois temps et se mesure en heures. D’abord, identifier les clés produites par l’outil ou la version incriminés. Ensuite, générer des clés neuves sur un chemin réputé sain : firmware corrigé, autre appareil sérieux, ou entropie tirée aux dés. Enfin, déplacer les fonds par ordre de valeur décroissante, car c’est exactement l’ordre dans lequel les attaquants vident la file. Il ne faut pas attendre un moment commode : la fenêtre est adverse, et chaque heure passée est une heure offerte à quelqu’un qui connaît déjà le réservoir réduit.

Pour qui détient des montants significatifs, le vrai correctif est structurel : ne pas dépendre d’un seul chemin de génération. Répartir les avoirs sur plusieurs clés générées indépendamment, ou recourir au MPC de sorte qu’aucune défaillance de générateur ne soit fatale à elle seule, transforme un événement catastrophique et total en incident partiel et survivable. La leçon de quinze ans d’incidents n’est pas «faites confiance à un meilleur outil», c’est «ne laissez pas le hasard d’un seul outil constituer toute votre sécurité».

2026, l’année où la clé a battu le code

La faiblesse d’entropie n’est qu’une part d’un basculement plus large. Pour la première fois dans l’histoire mesurée du secteur, la compromission de clés a dépassé les bugs de contrat intelligent comme premier vecteur de pertes, avec environ 1,3 milliard de dollars envolés sur les huit premiers mois de 2026, d’après crypto.news. Le rapport Chainalysis chiffrait déjà 2025 à 3,4 milliards de dollars volés, dont un record de 2,02 milliards attribués à la Corée du Nord.

La cible s’est déplacée vers les particuliers et leurs portefeuilles : la part de la valeur volée visant des portefeuilles personnels est passée d’environ 7,3 % en 2022 à près de 44 %, selon The Block. Sur le premier semestre 2026, Forbes décrit des attaques «moins nombreuses mais bien plus chirurgicales», dont les compromissions de portefeuilles constituent la première catégorie. Dans ce paysage, l’entropie faible reste une petite tranche, mais la plus insidieuse : elle ne réclame aucune interaction de la victime.

Le déplacement de la surface d’attaque, du code vers la clé, résume l’époque. Ronghui Gu, cofondateur de la société d’audit CertiK, le formulait ainsi auprès de Forbes : «un protocole peut passer un audit de code irréprochable et perdre malgré tout des millions à cause d’une clé d’administration compromise». La même vérité vaut à l’autre bout de la chaîne, chez le particulier : le maillon faible n’est plus la ligne de code, c’est le nombre secret et la manière dont il est né. À l’heure où nous écrivons, le Bitcoin s’échange autour de 74 000 euros (environ 84 600 dollars) et l’Ether autour de 2 350 euros (environ 2 694 dollars), d’après CoinGecko : autant de valeur qui repose, in fine, sur la qualité d’un tirage aléatoire.

AMF, MiCA et la responsabilité de l’auto-conservation

Sur le plan réglementaire, la faiblesse d’entropie tombe dans un angle mort selon qui détient la clé. Un particulier en auto-conservation, avec un portefeuille matériel comme Coldcard, se situe hors du champ de supervision des prestataires. Ni l’AMF ni le règlement européen MiCA ne couvrent un outil que vous exécutez vous-même : c’est le revers de la formule «vos clés, vos cryptos». Les victimes de Coldcard n’avaient aucun intermédiaire régulé vers qui se retourner, car la génération de leur graine relevait de leur seule responsabilité.

La donne change pour un prestataire de services sur actifs numériques (PSAN, désormais CASP sous MiCA). MiCA définit la conservation comme la garde ou le contrôle des «moyens d’accès», c’est-à-dire des clés cryptographiques privées, et son régime de responsabilité (article 75) fait peser sur le prestataire la charge de la preuve ainsi qu’une obligation de ségrégation des avoirs. Le règlement DORA, sur la résilience opérationnelle informatique, s’y ajoute : un gardien professionnel qui générerait ses clés avec un générateur défaillant ne pourrait pas se contenter de blâmer un fournisseur. En France, la conservation de clés privées est une prestation enregistrable de longue date (doctrine AMF DOC-2019-24).

Le calendrier ajoute une pression. La période transitoire du régime PSAN issu de la loi PACTE s’est achevée le 1er juillet 2026, et la non-conformité expose désormais à des sanctions pénales, comme l’a rappelé l’AMF. Pour les trésoreries d’entreprise qui détiennent du Bitcoin en propre, à l’image de la société française Capital B, l’hygiène de génération des clés cesse d’être un détail technique pour devenir un risque de niveau conseil d’administration. Une revue qui valide le code sans interroger la source d’entropie, comme le rappelle le suivi des audits menés jusqu’aux projets d’État, laisse précisément la porte par laquelle ces pertes sont entrées.

Questions fréquentes

Qu’est-ce qu’une clé privée «faible» ?

C’est une clé générée avec trop peu d’entropie, c’est-à-dire de hasard réel. Le nombre est tiré d’un ensemble bien plus petit que les 2^256 valeurs théoriques, parfois quelques milliards seulement, si bien qu’il peut être retrouvé par force brute. La clé paraît normale à l’usage, mais elle était devinable dès sa création.

Comment savoir si mon portefeuille est concerné ?

Vérifiez si votre matériel ou votre logiciel figure parmi les versions signalées : firmware Coldcard 4.0.1 et suivantes de mars 2021, extension de navigateur Trust Wallet de fin 2022, Libbitcoin bx en version 3.x, ou anciens portefeuilles web du début des années 2010. Dans le doute, générez une clé neuve sur un dispositif corrigé et transférez vos fonds ; on ne peut pas tester après coup l’entropie d’une clé existante.

Un portefeuille matériel me protège-t-il vraiment ?

Seulement si son générateur d’aléa est sain. Coldcard a prouvé qu’un appareil hors ligne peut malgré tout produire des clés faibles. Le stockage à froid protège contre le vol à distance d’une clé solide, pas contre une clé qui était faible dès sa naissance.

Pourquoi une mise à jour ne corrige-t-elle pas une clé faible ?

Parce qu’un correctif ne répare que la génération future, pas les clés déjà créées. Une clé faible reste compromise pour toujours ; le seul remède est de transférer les fonds vers une nouvelle clé générée correctement, avant que quelqu’un d’autre ne la devine.

L’AMF ou MiCA couvrent-ils ces pertes ?

Pour l’auto-conservation, non : elle est hors du champ de supervision des prestataires, et le détenteur assume seul le risque. Pour un conservateur régulé (CASP), le régime de responsabilité de MiCA et le règlement DORA s’appliquent, de sorte qu’une défaillance de générateur pourrait engager sa responsabilité.

Anneke de Vries couvre la sécurité et la cryptographie pour HOGE Wire.