Coldcard : un tweet de 2021 décrivait déjà la faille, la communauté crie à l’inside job

Ce qu’il faut retenir :

• Un tweet officiel de Coldcard décrivait en octobre 2021 une attaque par entropie truquée, sept mois après l’introduction du bug.
• Galaxy Research chiffre les vols confirmés à 1 596 bitcoins, jusqu’à 2 055 si une quatrième vague se confirme.
• Coinkite reconnaît une erreur de configuration accidentelle et aucune preuve d’intentionnalité n’a émergé.

Un tweet publié en octobre 2021 par le compte officiel de Coldcard décrivait presque mot pour mot la faille qui a permis de siphonner plus de 100 millions de dollars en bitcoins cinq ans plus tard. La coïncidence a fait ressurgir la publication sur X et nourrit depuis une semaine des accusations de coup monté visant l’équipe de Coinkite, le fabricant canadien.

Que disait le tweet de 2021 ?

Le 10 octobre 2021, le compte @COLDCARDwallet vantait une fonctionnalité maison : la possibilité pour l’utilisateur de générer lui-même son entropie à l’aide de lancers de dés, et de la reproduire de façon vérifiable. Le message affirmait que ce dispositif rendait impossible ce que le secteur appelle une “retirement attack”.

Interrogé en réponse sur la définition de ce terme, le compte a précisé la mécanique : le cas où les concepteurs d’un projet auraient introduit un bug dans la génération d’entropie afin de récupérer les fonds plus tard. Cette réponse constitue le cœur de la polémique actuelle.

L’entropie désigne ici la quantité de hasard réel utilisée pour créer une seed, cette phrase secrète qui contrôle un portefeuille. Une seed BIP-39 doit reposer sur au moins 128 bits d’entropie pour rester hors de portée d’une recherche exhaustive.

Le bug était déjà en production depuis sept mois

C’est la chronologie qui dérange. Le code vulnérable a été introduit le 1er mars 2021, par un commit basculant la génération de seed vers une nouvelle bibliothèque. La première version publique concernée, le firmware 4.0.1, est sortie le 29 mars 2021, soit plus de six mois avant le tweet.

Le défaut technique tient à une ligne de configuration. Lors de la migration, un paramètre désactivait le générateur d’aléa matériel, et l’éditeur de liens a résolu l’appel vers un générateur pseudo-aléatoire logiciel, le fallback de MicroPython, au lieu du TRNG de la puce STM32. Le code du générateur matériel figurait pourtant bien dans le firmware, mais restait inaccessible sur ce chemin précis.

Les conséquences varient selon les modèles. D’après les estimations de Coinkite, les Mk2 et Mk3 équipés des versions 4.0.1 à 4.1.9 tombent à environ 40 bits d’entropie effective, contre 128 attendus. Les Mk4, Mk5 et Coldcard Q s’en tirent avec environ 72 bits, grâce à un mélange partiel avec leurs éléments sécurisés, un niveau encore insuffisant. Le défaut est resté en place plus de cinq ans.

Ce que réclament les partisans de la thèse du coup monté

L’argument tient en une phrase : le bug existait déjà quand l’entreprise a publié la définition exacte du scénario. Une partie de la communauté juge la coïncidence trop parfaite et parle ouvertement d’une opération interne.

Deux éléments plaident en sens inverse. D’abord, ce tweet ne constitue pas un aveu mais la description d’un risque théorique connu de longue date dans le milieu de la sécurité des portefeuilles, précisément mis en avant pour vendre une protection contre ce risque. Enfin, le code de Coldcard est ouvert, ce qui rend une porte dérobée volontaire difficile à cacher sur la durée, même si personne n’avait examiné ce chemin d’exécution pendant cinq ans.

Rodolfo Novak, cofondateur de Coinkite connu sous le pseudonyme NVK, a assumé la responsabilité de l’entreprise, présenté des excuses publiques et décrit l’incident comme une erreur de compilation passée inaperçue, y compris lors des revues internes. Il avance par ailleurs l’hypothèse que la découverte du défaut ait pu être facilitée par des outils d’intelligence artificielle appliqués à du code ouvert. L’entreprise s’engage à accompagner les victimes dans leurs démarches auprès de la police et des assurances, et coopère avec les enquêteurs spécialisés dans l’analyse de la chaîne.

Où en est le bilan des vols ?

Les montants restent des estimations et évoluent vite. Galaxy Research recense 1 596 bitcoins volés sur environ 7 300 adresses, répartis sur trois vagues confirmées, auxquelles s’ajoutent 14 incidents de moindre ampleur.

Une quatrième vague porterait le total à 2 055 bitcoins, soit environ 130 millions de dollars, sans confirmation de victime à ce stade. Le cabinet dit disposer d’un niveau de confiance moyen à élevé sur le fait qu’un seul attaquant en soit à l’origine.

Le premier assaut, le 30 juillet, avait emporté environ 594 bitcoins depuis 500 adresses à signature unique en moins d’une heure, dont beaucoup dormaient depuis des années. La méthode ne suppose ni accès physique ni hameçonnage : elle consiste à retrouver par force brute des seeds à faible entropie, avec une priorité donnée aux adresses détenant plus de 0,15 bitcoin.

Un point rassure les enquêteurs. 90 % des BTC volées n’ont pas bougé, et la totalité des trois premières vagues reste immobile. Galaxy Research transmet les adresses d’attaquants et de victimes aux autorités fédérales américaines, aux plateformes d’échange et aux groupes d’investigation.

Qui reste protégé ?

Deux configurations tiennent a priori. Les seeds générées avec un nombre suffisant de lancers de dés, puisque cette méthode contourne le générateur défectueux. Et celles protégées par une passphrase BIP-39 solide, qui ajoute un secret indépendant de l’entropie initiale. Les montages multisignature n’ont pas été touchés non plus.

Coinkite a publié le 31 juillet des correctifs pour l’ensemble des modèles, en versions 4.2.0 pour les Mk3, 5.6.0 pour les Mk4 et Mk5, et 1.5.0Q pour le Q, et détruit son stock d’appareils vulnérables restants.

Et maintenant ?

L’attaque se poursuit. La consigne reste de transférer ses fonds vers une adresse sûre et de générer une nouvelle seed sur un appareil corrigé, sans attendre de confirmation supplémentaire.

Au-delà du cas Coldcard, l’affaire pose deux questions au secteur. Celle de la confiance dans la conservation autonome, d’abord, puisqu’un utilisateur ne peut pas vérifier lui-même la qualité de l’aléa produit par sa machine. Celle de la relecture du code ouvert ensuite, maintenant que l’IA permet d’auditer massivement des dépôts publics. Les défenseurs y voient un outil de détection, les attaquants une machine à repérer les régressions oubliées.