Exploit Coldcard 116M Dollars Relance Débat Sécurité

Imaginez un instant que le coffre-fort numérique dans lequel vous avez placé l’épargne de toute une vie se révèle plus fragile qu’un simple mot de passe trop court. C’est exactement ce qui s’est produit avec certains modèles Coldcard. Plus de cent seize millions de dollars en bitcoin ont été siphonnés parce qu’un générateur de nombres aléatoires, censé garantir l’imprévisibilité des seeds, s’est avéré catastrophiquement faible. Aujourd’hui, la polémique enfle à nouveau. Le fondateur de Coinkite, connu sous le pseudonyme NVK, affirme que quinze examens externes et deux audits payants n’ont rien vu. Une intelligence artificielle, elle, aurait enfin mis le doigt sur la faille. Des figures historiques de Bitcoin, Luke Dashjr en tête, répondent sèchement que des humains avaient déjà tiré la sonnette d’alarme. Entre défense, accusations de négligence et questions sur la transparence des revues de code, l’affaire redessine les contours de la confiance dans les portefeuilles matériels.

La faille qui a coûté 116 millions de dollars

Tout commence en mars 2021. Une simple erreur de configuration de compilation a conduit certains firmwares Coldcard à utiliser une bibliothèque logicielle de génération de nombres aléatoires au lieu du matériel dédié. Sur les appareils plus anciens, la force effective de l’entropie est tombée à environ quarante bits au lieu des cent vingt-huit bits attendus. Autrement dit, l’espace de recherche pour un attaquant devenait accessible avec des moyens de calcul relativement modestes. Plus de cinq mille deux cents adresses ont été touchées. Les vols se sont déroulés en plusieurs vagues à partir de fin juillet. Les analyses de TRM Labs et le suivi de Galaxy Research ont permis de quantifier le préjudice à environ mille huit cent seize bitcoins, soit plus de cent seize millions de dollars au cours de l’époque.

Ce qui frappe, c’est l’absence totale de nécessité d’accès physique. Les attaquants ont pu reconstruire les seeds à distance. Les fonds ont ensuite circulé, certains passés par des bridges comme THORChain pour être convertis en ether. Une partie reste encore immobile, surveillée de près. Les autorités américaines ont reçu des informations. Selon certains acteurs du secteur, l’identité d’au moins un attaquant pourrait être connue des forces de l’ordre, même si aucune confirmation officielle d’arrestation ou de saisie n’a encore filtré.

Comment un défaut de 2021 a pu rester invisible si longtemps

La question qui hante la communauté est simple : comment une erreur aussi critique a-t-elle pu survivre pendant plus de quatre ans ? NVK a publié le 9 novembre un message détaillé sur X. Il y dresse la liste de ce qu’il considère comme un parcours exemplaire de vérifications. Au moins quinze travaux externes ont, selon lui, touché le matériel, le firmware, les outils liés à la génération de nombres aléatoires ou les processus de publication. Deux revues de produits payantes ont eu lieu : une sur le modèle Mk4 en 2022, une autre sur le Q en 2024. Une revue menée avec l’outil OpenAI Cybersecurity Harness de Rob Ham aurait même généré quatre-vingt-cinq pistes de correctifs avant l’incident. Plusieurs ont été traitées. Le défaut de seed, lui, n’apparaissait nulle part.

La vérité inconfortable, c’est qu’il a fallu un nouveau modèle d’intelligence artificielle pour trouver ce que les humains n’avaient pas vu.

NVK, 9 novembre 2026

Cette phrase a fait l’effet d’une allumette dans un baril de poudre. Luke Dashjr, développeur Bitcoin de longue date, a immédiatement réagi. Il affirme avoir partagé des observations en privé avec Coinkite et a décidé de les rendre publiques. Il précise ne pas prétendre que chaque point est forcément exploitable ou même un bug confirmé. Son examen était rapide, loin d’un audit complet. Mais l’idée que seul un modèle d’IA avancé pouvait repérer un problème de générateur aléatoire lui paraît fausse. D’autres voix se sont jointes au débat. Certains accusent Coinkite d’avoir découragé l’examen approfondi du code. D’autres soulignent la différence entre une assurance qualité intégrée à chaque étape du développement et une revue ponctuelle d’un code massif.

Les alertes antérieures qui refont surface

James O’Beirne a relancé un fil plus ancien. En mai 2025, il s’était penché sur le firmware Coldcard pour comprendre d’où provenait exactement l’entropie. Il avait questionné l’utilisation de la bibliothèque libngu, s’étonné de constantes codées en dur dans le fallback logiciel, et recommandé de lier directement contre libsecp256k1. On lui avait répondu que la configuration était correcte pour les appareils physiques et qu’un problème aurait déjà éclaté au grand jour. Il reconnaît n’avoir pas poussé l’investigation plus loin. Quelques jours plus tard, il a fait état d’un second témoignage crédible selon lequel quelqu’un avait déjà alerté Coinkite dès 2021. Trois personnes indépendantes auraient donc potentiellement tiré la sonnette d’alarme, sans résultat visible.

Ces éléments dessinent un tableau plus complexe qu’un simple oubli technique. Ils soulèvent des questions sur la culture de sécurité au sein de l’entreprise, sur la façon dont les retours externes sont traités, et sur la limite des audits ponctuels face à des défauts latents dans des composants critiques.

La défense de NVK face aux critiques

NVK insiste sur le volume de travail déjà réalisé. Il distingue clairement les contrôles indépendants ciblés d’un audit exhaustif de chaque binaire corrigé. La page de sécurité de Coinkite présente toujours un postmortem vivant, tout en indiquant qu’un rapport technique détaillé séparé est encore en préparation. Shinobi, une autre figure du débat, a pris la défense de NVK en rappelant que des examinateurs avaient bien regardé le système d’entropie sans trouver le défaut. Il a défié les critiques de produire une démonstration reproductible plutôt que de se contenter de messages privés exprimant une inquiétude.

Le débat touche à un point sensible : la différence entre signaler une préoccupation et réaliser une divulgation de sécurité formalisée. Dans l’univers Bitcoin, où la confiance repose souvent sur des relations personnelles et des échanges informels, cette frontière reste floue. Certains estiment que Coinkite aurait dû traiter avec plus de sérieux les retours reçus. D’autres considèrent que la responsabilité première reste celle de l’utilisateur qui doit vérifier la provenance et l’état de son firmware.

Pourquoi les portefeuilles matériels restent vulnérables

Les portefeuilles matériels sont présentés depuis des années comme le graal de la sécurité Bitcoin. Ils isolent les clés privées du système d’exploitation principal, limitent les surfaces d’attaque et imposent des validations physiques. Pourtant, l’affaire Coldcard rappelle que le matériel n’est qu’une partie de l’équation. Le firmware, la qualité de l’entropie, le processus de compilation et la gestion des mises à jour pèsent tout aussi lourd. Un générateur de nombres aléatoires faible transforme le meilleur isolateur matériel en simple illusion de sécurité.

Dans le cas présent, le fallback logiciel a été activé par erreur. Sur du matériel sain, l’entropie matérielle aurait dû prévaloir. Mais la configuration de build a fait basculer certains appareils vers une source prévisible. Les attaquants n’ont pas eu besoin de casser le boîtier ni de forcer un écran. Ils ont simplement exploré un espace de seeds réduit. Cette réalité change la façon dont on doit évaluer les risques. Un audit qui se concentre uniquement sur les attaques physiques ou sur les interfaces utilisateurs peut complètement manquer une faille d’entropie.

Les réactions de la communauté Bitcoin

La discussion sur X a rapidement dépassé le simple échange technique. Alex Waltz a accusé l’entreprise et NVK d’avoir freiné les regards extérieurs sur le code. Kenneth a souligné qu’avoir une équipe qui passe une fois sur l’ensemble du code source n’équivaut pas à une assurance qualité intégrée à chaque étape. Chercher une aiguille dans une botte de foin entière est bien plus difficile que de vérifier des sous-ensembles plus petits et plus fréquents. Ces remarques touchent à la philosophie même du développement open source et de la sécurité continue.

D’autres participants ont rappelé que les portefeuilles matériels, même open source, restent des produits commerciaux. Les utilisateurs paient pour un niveau de confiance et de rigueur. Lorsque ce niveau est remis en question, la réaction est d’autant plus vive. Le fait que des alertes aient potentiellement été ignorées ou minimisées renforce le sentiment de rupture de confiance. Pour beaucoup, l’affaire ne se limite plus à un bug technique. Elle interroge la capacité d’une équipe à écouter les signaux faibles venant de la communauté.

Ce que recommande Coinkite aujourd’hui

La page de sécurité actuelle de Coinkite est claire sur un point : les mises à jour de firmware ne peuvent pas réparer des seeds déjà affectées. La seule voie de sortie consiste à générer une nouvelle seed sur un appareil à jour, à vérifier la sauvegarde et l’adresse de réception, à effectuer un petit transfert test, puis à déplacer le reste des fonds. Les versions recommandées sont 5.6.3 pour les Mk4 et Mk5, et 1.5.3Q pour le modèle Q. L’entreprise présente son document public comme un postmortem vivant, tout en annonçant un rapport technique plus détaillé encore en préparation.

Cette approche progressive laisse une partie de la communauté sur sa faim. Beaucoup attendent une chronologie précise des alertes reçues, des décisions prises et des raisons pour lesquelles certaines pistes n’ont pas été explorées plus avant. D’autres veulent comprendre comment une erreur de configuration de compilation a pu traverser autant de contrôles. La promesse d’un rapport technique séparé est notée, mais sa publication effective sera scrutée avec attention.

Les leçons pour tous les utilisateurs de portefeuilles matériels

L’affaire Coldcard offre plusieurs enseignements concrets. Premièrement, la génération de seed est un point de défaillance unique. Une faiblesse à ce niveau rend tous les autres mécanismes de sécurité secondaires. Deuxièmement, les audits ponctuels, même nombreux, ne remplacent pas une culture de vérification continue et d’écoute active des retours externes. Troisièmement, la distinction entre matériel et logiciel reste artificielle : un appareil physique parfait avec un firmware défaillant n’offre qu’une illusion de protection.

Les utilisateurs sont invités à vérifier systématiquement les versions de firmware, à privilégier les builds reproductibles lorsque c’est possible, et à considérer toute seed générée sur un appareil potentiellement touché comme compromise. La migration vers une nouvelle seed reste la seule solution fiable. Cette opération, bien que fastidieuse, est le prix de la prudence. Dans un écosystème où les montants en jeu atteignent facilement des dizaines ou des centaines de milliers d’euros, le coût d’une migration est négligeable face au risque de perte totale.

Le rôle de l’intelligence artificielle dans la détection des failles

NVK a mis en avant le fait qu’un modèle d’IA récent a réussi là où des examinateurs humains avaient échoué. Cette affirmation ouvre un débat plus large sur l’avenir des audits de sécurité. Les outils d’intelligence artificielle excellents dans la détection de patterns complexes et dans l’exploration exhaustive d’espaces d’états. Ils peuvent examiner des quantités de code que des humains ne peuvent pas absorber en un temps raisonnable. Pourtant, ils restent limités par la qualité des données d’entraînement et par la capacité à comprendre le contexte métier.

Dans le cas Coldcard, l’IA aurait repéré le défaut d’entropie. Cela ne signifie pas que les humains étaient incapables de le faire. Cela signifie plutôt que le défaut se situait dans une zone peu regardée ou que les signaux d’alerte antérieurs n’avaient pas été suffisamment creusés. L’IA devient un outil complémentaire précieux, mais elle ne dispense pas d’une rigueur humaine dans le traitement des retours et dans la priorisation des risques.

Confiance, transparence et responsabilité dans l’écosystème Bitcoin

Bitcoin repose sur un principe de confiance minimale. On ne fait pas confiance aux institutions, on vérifie. Les portefeuilles matériels s’inscrivent dans cette logique en offrant un contrôle physique sur les clés. Mais lorsque le fabricant lui-même devient l’objet d’un doute, le modèle se fissure. La transparence sur les processus d’audit, sur le traitement des signalements et sur les décisions techniques devient alors un élément central de la confiance.

Coinkite a choisi de publier un postmortem vivant et d’annoncer un rapport technique plus complet. C’est un pas. La communauté attend désormais des détails précis sur la chronologie, sur les alertes reçues et sur les raisons pour lesquelles certaines pistes n’ont pas abouti plus tôt. Luke Dashjr a choisi la divulgation publique après avoir partagé ses observations en privé. James O’Beirne a rappelé ses propres questionnements de 2025 et les témoignages plus anciens. Ces prises de parole contribuent à une culture de responsabilité collective.

Les implications pour les prochains audits de sécurité

L’affaire va probablement modifier la façon dont les audits de portefeuilles matériels sont conçus. Les examinateurs devront accorder une attention particulière aux sources d’entropie, aux fallbacks logiciels, aux configurations de compilation et aux différences entre les builds destinés aux différents modèles. Les revues ne pourront plus se contenter de vérifier les interfaces utilisateurs ou les protections contre les attaques physiques. Elles devront explorer les chemins d’exécution rares et les conditions de bord.

Les fabricants, de leur côté, auront intérêt à formaliser davantage le traitement des signalements externes. Un message privé exprimant une inquiétude ne doit pas être traité comme un simple commentaire. Il doit entrer dans un processus de triage, d’évaluation et de réponse. La distinction entre préoccupation informelle et divulgation de sécurité formalisée doit être clarifiée pour éviter les malentendus futurs.

Une crise de confiance qui dépasse Coldcard

Au-delà de Coinkite, l’épisode rappelle que aucun portefeuille matériel n’est à l’abri d’une erreur de configuration ou d’un défaut de conception. Les utilisateurs doivent diversifier leurs approches, ne jamais concentrer l’intégralité de leurs avoirs sur un seul appareil, et rester prêts à migrer rapidement en cas de doute. La génération de seed hors ligne, l’utilisation de multisignature et la vérification des builds reproductibles restent des pratiques saines.

La polémique actuelle ne porte pas uniquement sur un bug de 2021. Elle porte sur la façon dont une entreprise de sécurité gère les retours critiques, sur la place accordée aux alertes de la communauté, et sur la capacité à reconnaître qu’un défaut a pu échapper à de nombreux regards. NVK défend un bilan de revues conséquent. Ses détracteurs estiment que des signaux ont été négligés. Le rapport technique promis devra trancher une partie de ces questions.

Ce qu’il faut retenir pour l’avenir

Les portefeuilles matériels restent un outil précieux. Ils réduisent considérablement la surface d’attaque par rapport à un logiciel purement desktop. Mais ils ne sont pas magiques. Leur sécurité dépend de la qualité de l’entropie, de la rigueur du firmware, de la transparence des processus et de la capacité de l’équipe à écouter les retours. L’affaire Coldcard montre qu’une erreur de configuration peut survivre des années et coûter des dizaines de millions de dollars.

Pour les utilisateurs concernés, la priorité absolue reste la migration vers une nouvelle seed générée sur un appareil à jour. Pour le reste de la communauté, l’épisode doit servir de rappel permanent : vérifier, questionner, et ne jamais considérer un audit comme une garantie absolue. La sécurité est un processus, pas un état. Et dans Bitcoin, ce processus ne s’arrête jamais.

La suite de l’histoire dépendra en grande partie de la publication du rapport technique détaillé annoncé par Coinkite. Si ce document apporte une chronologie claire, une analyse des alertes reçues et des enseignements concrets, il pourra contribuer à restaurer une partie de la confiance. Dans le cas contraire, le débat risque de s’enliser dans des échanges d’accusations et de justifications. Pour l’instant, les utilisateurs de Coldcard et l’ensemble de l’écosystème Bitcoin restent en attente d’une clarté que seul un postmortem complet pourra apporter.

En attendant, la leçon la plus immédiate reste celle de la prudence. Toute seed générée sur un appareil potentiellement touché doit être considérée comme compromise. Toute mise à jour de firmware doit être suivie d’une vérification minutieuse. Et toute alerte, même informelle, mérite d’être traitée avec le sérieux qu’exige la protection de fonds irréversibles. Dans un monde où cent seize millions de dollars ont disparu à cause d’un générateur de nombres aléatoires trop faible, ces principes ne sont plus des recommandations optionnelles. Ils deviennent des réflexes de survie.

Le débat entre NVK, Luke Dashjr, James O’Beirne et le reste de la communauté illustre parfaitement les tensions qui traversent l’écosystème Bitcoin : exigence de transparence, responsabilité individuelle, limites des audits humains, place grandissante de l’intelligence artificielle, et nécessité permanente de remettre en question même les solutions présentées comme les plus sûres. Cette tension n’est pas un défaut. Elle est le moteur qui pousse le secteur à s’améliorer. À condition, bien sûr, que les enseignements soient tirés et que les prochaines générations de portefeuilles matériels intègrent réellement les leçons de cette douloureuse expérience.

Les prochains mois diront si Coinkite parvient à transformer cette crise en opportunité de renforcement de ses processus. Ils diront aussi si la communauté Bitcoin saura conserver son exigence sans basculer dans une défiance généralisée qui nuirait à l’adoption d’outils pourtant indispensables. Pour l’instant, le compteur des fonds volés reste figé à cent seize millions de dollars, les seeds compromises restent inutilisables, et la discussion sur la qualité des audits de sécurité n’a jamais été aussi vive. C’est dans cet état d’alerte permanente que se construit, jour après jour, la résilience de l’écosystème.