Coldcard : le post-mortem d’un hack sans coupable

« Je n’ai jamais partagé ma phrase de récupération avec personne. Mes appareils n’ont jamais été connectés à Internet. » Le message de Jonathan Goodman, vu près de 7,6 millions de fois, résume le vertige qui a saisi les partisans de la garde personnelle à l’été 2026. Goodman avait fait exactement ce que tous les guides répètent depuis dix ans : un portefeuille matériel, une phrase de récupération notée hors ligne, aucune photo, aucune sauvegarde dans le cloud. Il a pourtant vu disparaître 18,25 bitcoins, soit environ un million d’euros (près de 1,6 million de dollars canadiens selon son propre décompte), en quelques minutes, comme le rapporte Forbes.

La cause tenait dans une seule ligne de code écrite en 2021, à l’intérieur du firmware de son Coldcard, le portefeuille matériel de la société canadienne Coinkite. Divulguée le 30 juillet 2026, cette faille a permis de deviner les clés privées de milliers d’utilisateurs sans jamais toucher physiquement à leur appareil. Au 4 août, plusieurs sociétés d’analyse on-chain chiffraient le butin à plus de 130 millions de dollars, soit plus de 113 millions d’euros, réparti sur plus de 5 200 adresses, selon TechCrunch.

Cet article est une autopsie : la mécanique de l’exploit, la chronologie de la fuite, et surtout ce qui rend ce dossier singulier. La culture crypto a passé une décennie à codifier le post-mortem, ce rituel public où l’on dissèque un désastre pour en tirer des leçons. Or le cas Coldcard casse d’un coup tous les présupposés du genre : pas de DAO pour voter un remboursement, pas de trésorerie pour éponger la perte, pas d’attaquant unique à qui proposer une prime, pas même de montant final, puisque la fuite se poursuit. C’est un post-mortem sans coupable.

Ce qui s’est passé, en une phrase

Pendant plus de cinq ans, des Coldcard ont été livrés avec un firmware qui, au moment de créer une graine, se rabattait silencieusement sur une source d’aléa de mauvaise qualité au lieu du générateur matériel prévu. Résultat : les clés qui en découlaient n’étaient pas réellement imprévisibles. Un attaquant capable de reconstituer l’espace des graines possibles pouvait alors calculer les adresses correspondantes, vérifier lesquelles contenaient des bitcoins sur la chaîne publique, puis les vider. Le portefeuille censé protéger l’utilisateur produisait lui-même la faiblesse qui allait le trahir.

Ce n’est pas un vol de clés, pas une attaque de smart contract, pas un pont piraté. C’est une défaillance à la racine du modèle de sécurité de la garde personnelle : la génération d’aléa. Et comme cette graine défectueuse a été gravée dans des milliers d’appareils au fil des ans, la correction du firmware ne referme pas la plaie pour ceux qui étaient déjà exposés. Le fabricant Coinkite l’a confirmé sur son propre blog : « nous ignorions l’existence de ce bug jusqu’à aujourd’hui », parlant d’une « série de bugs complexes et subtils » (Coinkite).

La cause racine : une ligne de code de 2021

Le détail technique mérite qu’on s’y arrête, car il est à la fois banal et redoutable. En mars 2021, avec la version 4.0.0 du firmware, Coinkite migre une partie de sa pile cryptographique vers la bibliothèque libsecp256k1. À cette occasion, la génération de graine cesse d’appeler la fonction maison de Coldcard pour lire le générateur d’aléa matériel, et passe par une fonction générique de MicroPython. Un garde-fou était pourtant prévu : une directive de préprocesseur devait vérifier que le générateur matériel était bien activé avant de l’utiliser.

Le garde-fou testait la mauvaise chose. Il vérifiait si une macro de configuration était définie, et non si sa valeur était non nulle. Or la macro était définie mais valait zéro. La condition n’a donc jamais déclenché l’alerte, et le firmware s’est rabattu en silence sur le générateur pseudo-aléatoire logiciel de MicroPython, surnommé « Yasmarang », au lieu de la puce matérielle dédiée. Le média spécialisé Blockhead résume la faille d’une formule limpide : le contrôle « vérifiait seulement qu’un réglage existait, pas qu’il était activé ». Une garde personnelle irréprochable reposait, à son insu, sur un tirage à pile ou face truqué.

Concrètement, la génération de graine est passée de la fonction interne de Coldcard, qui lisait directement la puce d’aléa matériel, à une routine générique empruntée à MicroPython. Le générateur pseudo-aléatoire de secours n’était jamais censé produire des clés de valeur ; il servait à des usages sans enjeu de sécurité. Le code étant public, n’importe qui pouvait en théorie repérer l’anomalie. Mais personne ne relit un firmware ligne par ligne à la recherche d’une macro définie à zéro, et rien, dans le comportement de l’appareil, n’invitait à soupçonner quoi que ce soit. Le bug était à la fois visible par tous et vu par personne.

Ce genre d’erreur ne saute pas aux yeux à la lecture. Elle ne provoque aucun plantage, aucune alerte, aucun symptôme visible. L’appareil affiche une phrase de douze ou vingt-quatre mots parfaitement normale. Rien ne distingue, à l’écran, une graine tirée avec 128 bits d’entropie d’une graine tirée avec 40. C’est précisément ce qui a permis au bug de dormir cinq ans.

L’entropie, ou pourquoi 128 bits ne valent pas 40 bits

Une phrase de récupération n’est qu’une manière lisible de représenter un très grand nombre secret. Pour une phrase de douze mots, ce nombre porte 128 bits d’entropie, soit environ 3,4 fois dix puissance 38 possibilités. Aucune ferme de calcul au monde ne peut parcourir un tel espace : c’est ce qui rend la garde personnelle solide. Le problème n’est pas la longueur de la phrase, mais le nombre de tirages réellement imprévisibles qui l’ont produite.

C’est là que la faille fait mal. Sur les modèles Mk2 et Mk3, l’entropie effective tombait à environ 40 bits, soit à peine plus de mille milliards de combinaisons, un espace qu’un attaquant motivé peut balayer. Sur les Mk4, Mk5 et Q, une puce de sécurité limitait les dégâts, mais l’entropie effective plafonnait autour de 72 bits, et l’analyse des chercheurs de Block la ramène à seulement 32 bits utiles dans le pire des cas. Passer de 128 à 40 bits, ce n’est pas diviser la sécurité par trois : c’est la faire s’effondrer d’un facteur astronomique.

Pour mesurer l’écart, une image aide. Explorer 128 bits dépasse l’entendement : c’est hors de portée, définitivement. Explorer environ 40 bits, en revanche, revient à parcourir un peu plus de mille milliards de combinaisons, un espace qu’une infrastructure de calcul déterminée peut balayer. Ce n’est pas une hypothèse d’école : c’est précisément ce qui s’est produit. La comparaison la plus juste est celle du coffre-fort de banque face à une boîte à chaussures fermée par un cadenas à trois chiffres. Les modèles récents, mieux protégés par leur puce de sécurité, relevaient la barre sans jamais la ramener au niveau prévu. Le tableau ci-dessous résume l’exposition par modèle.

Comment on vide un coffre sans jamais le toucher

La phrase de Jonathan Goodman, « mes appareils n’ont jamais touché Internet », dit une vérité qui, dans ce cas précis, ne l’a pas protégé. L’attaque n’avait pas besoin d’accéder à son Coldcard. Puisque les graines étaient prévisibles, un attaquant pouvait les générer hors ligne, en masse, dériver pour chacune les adresses Bitcoin correspondantes, puis interroger la blockchain publique pour repérer celles qui contenaient des fonds. La transparence de la chaîne, d’ordinaire présentée comme une vertu, s’est transformée en liste de cibles.

Le mécanisme s’appuie sur la manière même dont Bitcoin dérive les adresses. À partir d’une seule graine, un portefeuille engendre de façon déterministe une arborescence entière d’adresses, selon des standards publics et documentés. Deviner la graine, c’est donc deviner d’un coup toutes les adresses présentes et futures du portefeuille. L’attaquant n’avait pas à cibler une adresse précise : il générait des graines candidates, dépliait pour chacune les premières adresses de l’arbre, et les comparait à la liste, publique, des adresses contenant des fonds. Un simple recoupement, mené à l’échelle industrielle.

Une fois les adresses fortunées identifiées, il ne restait qu’à signer et diffuser des transactions de balayage. Pas de hameçonnage, pas de logiciel malveillant, pas de faux site, pas d’ingénierie sociale. L’utilisateur n’avait aucun geste à commettre, aucune erreur à faire : la faille était déjà dans la graine, du premier jour. C’est ce qui rend le dossier si dérangeant. Les conseils habituels (ne jamais taper sa phrase sur un clavier, ne jamais la photographier, se méfier des liens) étaient tous respectés par les victimes, et tous inutiles ici.

La chronologie d’une fuite qui n’en finit pas

Le 30 juillet 2026, la faille est rendue publique. La première vague est brutale : selon The Hacker News, 1 196 adresses sont vidées de 1 082,65 BTC, soit environ 70,2 millions de dollars, en 41 minutes. Il ne s’agit pas d’un rançongiciel qui laisse le temps de négocier ; c’est une course de vitesse, où plusieurs acteurs se disputent le même vivier d’adresses faibles.

Deux jours plus tard, le compteur s’est encore emballé. Blockhead évoque près de 1 367 BTC, soit environ 88,6 millions de dollars, drainés de plus de 4 500 adresses, un chiffre qui « n’a cessé de grimper » depuis le 30 juillet. Le 4 août, Forbes parle de plus de 116 millions de dollars sur plus de 5 200 adresses, tandis que TechCrunch rapporte que les sociétés de surveillance on-chain dépassent désormais les 130 millions de dollars. Tom Robinson, cofondateur et chief scientist de la société d’analyse Elliptic, a indiqué à TechCrunch que cette estimation était globalement exacte. Fait marquant, il ne s’agit pas d’un seul voleur : TechCrunch et la cellule Galaxy Research documentent « au moins une douzaine » de groupes distincts, agissant en parallèle sur le même jeu d’adresses.

Un butin qui monte encore

Résumer ce dossier par un chiffre unique serait trompeur, car le total est une cible mouvante. Le tableau ci-dessous reprend les estimations successives, chacune rattachée à sa source et à sa date, sans les fondre en une fausse précision.

Pourquoi ce chiffre refuse-t-il de se figer ? Parce que la correction du firmware ne répare pas une graine déjà générée avec une entropie insuffisante, comme l’a confirmé Coinkite et comme le rappellent tous les décomptes, y compris celui de Privacy Guides. Tant que des utilisateurs conservent des fonds sur des adresses issues de graines faibles, le vivier reste ouvert. Il n’y a donc pas d’événement de clôture, pas de moment où l’on pourra dire « c’est terminé, voici le bilan définitif ». La couverture médiatique de la CBC parle d’un piratage « en cours », et c’est la formulation exacte (CBC).

Le post-mortem sans coupable

Voici le cœur de ce dossier. Depuis dix ans, la crypto a inventé une réponse culturelle propre aux catastrophes : le post-mortem, autopsie publique inspirée à la fois de la culture de l’ingénierie de fiabilité et d’un besoin de reconstruire la confiance quand aucun recours légal n’existe. Ce rituel suppose toujours au moins un point d’ancrage : un protocole vivant, une équipe, une trésorerie, une DAO qui vote, ou à défaut un attaquant identifiable à qui parler. Le cas Coldcard fait sauter chacun de ces ancrages en même temps.

Il n’y a pas de DAO ni de jeton, donc aucune gouvernance pour voter un remboursement. Il y a un fabricant, Coinkite, mais une petite société matérielle n’a pas les reins pour absorber plus de 113 millions d’euros. Il n’y a pas un attaquant, mais une douzaine de groupes anonymes qui se sont rués sur les mêmes adresses, et aucune attribution à un acteur étatique du type Lazarus ne tient pour l’instant. Et il n’y a pas de perte finale, puisque le compteur tourne encore. Comparé aux grands précédents, l’écart saute aux yeux.

Dans les trois autres cas, un responsable existe et l’utilisateur, au bout du compte, est le plus souvent rendu entier. Sky Mavis a levé des fonds pour rembourser les victimes de Ronin ; Bybit a puisé dans son bilan ; l’attaquant d’Euler a même rendu l’argent. Coldcard n’offre aucun de ces épilogues. La question du remboursement, que nous avions déjà explorée sous l’angle « qui paie vraiment quand le piratage a lieu » dans notre analyse sur la responsabilité après un hack, trouve ici sa réponse la plus dure : personne.

Personne avec qui négocier

La crypto a inventé un objet rituel que ni la finance traditionnelle ni le monde du logiciel ne connaissaient : la négociation on-chain avec l’attaquant. En 2023, l’auteur du hack d’Euler Finance avait laissé un message on-chain, « No intention of keeping what is not ours » (aucune intention de garder ce qui ne nous appartient pas), avant de restituer la quasi-totalité des fonds contre une prime de 10 pour cent, comme l’a documenté The Block. Poly Network, en 2021, avait offert au sien le titre de « conseiller en chef pour la sécurité » et récupéré presque tout. Cette diplomatie de la dernière chance suppose un interlocuteur unique, joignable, sensible à la réputation ou à la menace pénale.

Coldcard n’a rien de tel. Face à une douzaine de groupes opportunistes qui se disputent la même liste d’adresses, à qui adresser une offre ? Comment garantir qu’un remboursement d’un groupe n’ouvre pas la voie à un autre ? La négociation on-chain, cette parade que la crypto affichait comme une preuve de maturité, devient inopérante dès lors que l’attaquant n’est pas un mais une nuée. La voie judiciaire n’est guère plus prometteuse : identifier, localiser et poursuivre une douzaine d’acteurs pseudonymes répartis sur plusieurs juridictions relève de l’exploit, et l’histoire récente, des procès autour des mixeurs jusqu’aux poursuites contre les fondateurs de plateformes que nous avons suivies dans notre dossier sur les rug pulls et la justice, montre combien la responsabilité pénale reste difficile à établir dans cet univers.

L’ironie : un bug repéré par une IA

Le firmware de Coldcard est open source. Longtemps présentée comme un gage de confiance (n’importe qui peut auditer le code), cette ouverture prend soudain une couleur plus ambiguë. Rodolfo Novak, cofondateur et PDG de Coinkite, a livré une explication qui a fait débat : selon lui, la revue de code assistée par IA « peut désormais repérer des bugs latents à une vitesse qui dépasse même les experts les plus chevronnés du secteur », et il ajoute que si votre firmware est ou a été public, il faut « partir du principe qu’il est déjà lu par les attaquants comme par les défenseurs » (Bitcoin Magazine).

Beaucoup d’ingénieurs en sécurité récusent cette lecture : le bug relève d’une erreur humaine classique, une condition de préprocesseur mal écrite, pas d’une trouvaille que seule une machine pouvait faire. Mais l’intuition de fond dérange par sa justesse. Si des outils automatisés savent désormais explorer des dépôts publics et faire remonter des failles dormantes plus vite que les humains, alors chaque ligne de code open source jamais publiée devient un actif à défendre en continu. Ido Ben-Natan, cofondateur et PDG de la société de sécurité Blockaid, replace la responsabilité au bon endroit : « La sécurité d’un portefeuille matériel se résume en fin de compte au firmware et aux systèmes avec lesquels l’utilisateur interagit sans jamais les voir » (Forbes). Cette bascule vers une sécurité assistée par machine, que nous abordons aussi sous l’angle du calcul vérifiable dans notre article sur l’IA vérifiable et le restaking, coupe dans les deux sens : elle arme autant les défenseurs que les prédateurs.

Ce qu’un bon post-mortem fait quand même

Le dossier Coldcard n’a peut-être pas de coupable exploitable, mais il a un post-mortem, et il faut lui reconnaître ses qualités. Coinkite a publié un document technique détaillé expliquant la mécanique exacte du bug, a diffusé des firmwares corrigés pour toute la gamme, et a communiqué presque en temps réel sur l’ampleur des dégâts. C’est la meilleure tradition du genre : celle des rapports post-incident sans recherche de bouc émissaire, celle qui a fait la réputation de Bybit en 2025 quand son PDG Ben Zhou a choisi la transparence radicale, celle que consignent des archives comme le classement de rekt.news.

Cette culture a produit des institutions. Des collectifs de white hats comme SEAL 911 interviennent en urgence pendant les attaques ; des cadres comme le Safe Harbor de la Security Alliance offrent aux hackers repentis un retour balisé des fonds contre une prime plafonnée ; des enquêteurs on-chain retracent publiquement le cheminement des cryptoactifs volés. Tout cet appareillage suppose néanmoins une chose que Coldcard n’a pas : un flux de fonds concentré, attribuable, et un adversaire que l’on peut approcher ou dissuader. Dispersée entre une douzaine d’acteurs et des milliers de victimes indépendantes, l’affaire échappe à ces outils autant qu’aux régulateurs.

Mais la transparence n’est pas la restitution. Un excellent post-mortem qui n’aboutit à aucun remboursement laisse les victimes exactement où elles étaient, plus les explications. C’est la limite structurelle de la garde personnelle : elle transfère à l’utilisateur non seulement la maîtrise, mais aussi le risque final, sans filet. Aucune assurance de dépôt, aucun fonds de garantie n’entre en jeu. Les dispositifs d’assurance on-chain existent, et nous en avons détaillé les promesses et les limites dans notre analyse sur le slashing en cascade et la course à l’assurance, mais leurs paiements réels restent minuscules au regard des pertes du secteur, et aucun ne couvre une graine faible générée par un appareil personnel. Le post-mortem, ici, remplit une fonction morale et pédagogique, pas économique.

Déjà vu : quand le hasard trahit

Le plus troublant, c’est que cette famille de failles n’est pas nouvelle. En août 2013, une faiblesse du composant SecureRandom d’Android avait conduit plusieurs applications de portefeuille Bitcoin, dont Bitcoin Wallet, l’application de blockchain.info, BitcoinSpinner et Mycelium, à réutiliser la même valeur « aléatoire » pour signer des transactions différentes. Or, en Bitcoin, un tel nombre secret réutilisé permet de reconstituer la clé privée à partir de données publiques. Le projet Bitcoin avait alors publié une alerte officielle et recommandé la seule parade valable : générer une nouvelle adresse avec un générateur d’aléa réparé, puis déplacer les fonds (bitcoin.org).

Treize ans séparent l’alerte Android du fiasco Coldcard, et pourtant la forme est identique : un aléa défaillant, une clé devenue devinable, une remédiation qui consiste à tout régénérer et tout migrer. La leçon n’a rien de folklorique. La sécurité cryptographique repose entièrement sur la qualité de l’aléa au moment de la création de la clé, un instant unique, invisible, impossible à corriger a posteriori. Chaque fois qu’un maillon (système d’exploitation, bibliothèque logicielle, firmware) court-circuite en silence la source d’entropie, le même désastre se reproduit. La crypto adore parler de mathématiques incassables ; ses accidents les plus coûteux viennent souvent, non des maths, mais de la plomberie qui les alimente.

L’angle français : Ledger, la garde personnelle et un régulateur hors-jeu

Le dossier résonne particulièrement en France, patrie de Ledger. Fondée à Paris en 2014, la société est devenue le champion national du portefeuille matériel, avec des appareils vendus par millions dans le monde. Ses cadres se sont exprimés, et pas seulement par opportunisme concurrentiel. Vincent Bouzon, expert en cybersécurité chez Ledger, a énoncé le principe qui manquait précisément chez Coldcard : la génération de clés « doit être ancrée dans du matériel sécurisé, avec une architecture qui ne peut pas silencieusement se rabattre sur une source logicielle non fiable » (Forbes). Toute la faille tient dans ce mot : silencieusement.

Le directeur technique de Ledger, Charles Guillemet, a de son côté mis en garde contre une réaction réflexe. Après l’incident, beaucoup d’utilisateurs se sont précipités vers le multisig, persuadés que multiplier les signatures réglait le problème. Selon lui, tel que rapporté par Decrypt et sur le blog de Ledger, le multisig n’est pas automatiquement la bonne réponse : sa complexité peut introduire de nouveaux risques au lieu d’éliminer les anciens, et pour la plupart des utilisateurs, un portefeuille à signature unique correctement sauvegardé reste le choix le plus raisonnable, éventuellement complété par des outils comme Miniscript ou le standard MuSig2. Ce débat, nous l’avons disséqué en détail dans notre checklist multisig 2026. Andrew Lazutkin, directeur technique de Tangem, ajoute une nuance salutaire : un firmware open source « ne doit pas être automatiquement assimilé à une meilleure sécurité ». L’ouverture aide à auditer ; elle n’audite pas à votre place.

AMF, MiCA, DORA : personne n’est compétent

Une victime française de ce piratage se heurterait à un vide juridique presque total. Le règlement MiCA, dont la période transitoire pour les prestataires de services sur actifs numériques s’est achevée le 1er juillet 2026 (AMF), encadre les acteurs qui conservent ou échangent des cryptoactifs pour le compte de tiers. Or Coinkite ne conserve rien : la société vend un objet, elle n’est pas un prestataire de services sur actifs numériques. L’AMF n’a donc pas de prise sur elle.

Même logique du côté de la résilience opérationnelle. Le règlement DORA impose aux entités financières régulées un calendrier strict de déclaration des incidents (notification initiale sous quelques heures, rapport intermédiaire puis rapport final sous un mois), comme le détaille le site de l’autorité européenne compétente. Un fabricant de portefeuilles matériels n’entre pas dans ce périmètre : aucun compte à rendre, aucun délai imposé. La transparence de Coinkite fut un choix volontaire, pas une obligation légale. Il reste, en théorie, le droit commun de la responsabilité du fait des produits défectueux et le droit de la consommation, du ressort en France de la DGCCRF et non de l’AMF. Mais ces voies sont lentes, coûteuses, et sans précédent connu pour ce type précis de défaillance. Le paradoxe est complet : la garde personnelle, que la logique réglementaire encourage implicitement (vos clés, votre responsabilité), tombe entièrement hors du champ des régulateurs financiers. Le post-mortem sans coupable est aussi un post-mortem sans juge.

Que faire si vous détenez un Coldcard

La marche à suivre est simple à énoncer, moins agréable à exécuter. D’abord, identifiez votre modèle et la version de firmware utilisée au moment où la graine a été créée. Si cette graine a été générée sur un firmware vulnérable (Mk2 et Mk3 en 4.0.0 à 4.1.x, Mk4, Mk5 et Q sur les versions antérieures aux correctifs), considérez-la comme compromise, quelle que soit la prudence dont vous avez fait preuve depuis. Mettre à jour ne suffit pas : le correctif empêche la création de futures graines faibles, mais ne répare pas une graine existante.

• Générez une nouvelle graine sur un firmware corrigé, puis transférez l’intégralité de vos fonds vers les nouvelles adresses, sans tarder.
• Si votre graine provient d’au moins 50 lancers de dés indépendants, elle ne dépendait pas du générateur de l’appareil et n’est pas concernée par cette faille.
• Vérifiez systématiquement la signature des firmwares que vous installez, et n’installez que depuis la source officielle.
• Pour l’avenir, diversifiez vos sources d’entropie : combiner l’aléa matériel avec des lancers de dés physiques est une ceinture et des bretelles peu coûteuses.
• Ne réagissez pas dans la panique en empilant des dispositifs complexes que vous maîtrisez mal ; un montage sophistiqué mais mal compris est souvent moins sûr qu’un montage simple bien exécuté.

Au-delà du geste technique, il y a une hygiène de fond. La garde personnelle reste, pour l’immense majorité des détenteurs, plus sûre que de laisser ses cryptoactifs sur une plateforme. Mais elle exige de comprendre que la sécurité ne s’arrête pas à la phrase de récupération notée sur un bout de papier : elle descend jusqu’à la qualité de l’aléa qui a produit cette phrase, une couche que l’utilisateur ne voit jamais et sur laquelle il place pourtant une confiance absolue.

Frequently Asked Questions

Mon Coldcard est-il concerné par la faille ?

Tout appareil dont la graine a été générée sur un firmware vulnérable est potentiellement exposé : Mk2 et Mk3 en versions 4.0.0 à 4.1.x, ou Mk4, Mk5 et Q sur les versions antérieures aux correctifs. Les graines créées à partir d’au moins 50 lancers de dés indépendants ne dépendaient pas du générateur de l’appareil et ne sont pas concernées. En cas de doute, considérez la graine comme compromise et migrez vos fonds.

Mettre à jour le firmware suffit-il à me protéger ?

Non. Le correctif empêche la génération de nouvelles graines faibles, mais il ne répare pas une graine déjà créée avec une entropie insuffisante. La seule parade est de générer une nouvelle graine sur un firmware corrigé, puis de transférer l’intégralité des fonds vers les nouvelles adresses.

Combien a été volé au total ?

Le montant est une cible mouvante. La première vague a vidé 1 196 adresses en 41 minutes le 30 juillet ; au 4 août, plusieurs sociétés d’analyse on-chain évaluaient le butin à plus de 130 millions de dollars, soit plus de 113 millions d’euros, sur plus de 5 200 adresses. Comme le correctif ne sécurise pas les graines déjà générées, ce total peut encore augmenter.

Qui va rembourser les victimes ?

Personne n’a annoncé de plan d’indemnisation. Coinkite, le fabricant, aide les utilisateurs à migrer mais n’a pas proposé de compensation, et une petite société matérielle n’a pas les moyens d’éponger plus de 113 millions d’euros. Aucun régulateur, ni l’AMF ni le cadre MiCA, n’a compétence sur un fabricant de portefeuilles matériels, qui n’est pas un prestataire de services sur actifs numériques.

Un portefeuille matériel reste-t-il plus sûr qu’un portefeuille logiciel ?

Pour la grande majorité des utilisateurs, oui : un portefeuille matériel bien sauvegardé isole les clés d’un ordinateur connecté. Le cas Coldcard rappelle toutefois que la sécurité dépend du firmware et de la qualité du générateur d’aléa, des couches invisibles pour l’utilisateur. Diversifier les sources d’entropie et vérifier les signatures du firmware réduisent nettement ce risque.

Anneke de Vries couvre la sécurité et les exploits on-chain pour HOGE Wire.