L'incident est devenu public après qu'environ 594 $BTC ont été transférés le 30 juillet à partir d'environ 500 adresses Bitcoin à signature unique, d'une valeur d'environ 38 millions de dollars à l'époque. Lorsque la nouvelle est apparue pour la première fois, Bitcoin.com News a noté que les transferts se sont produits en l'espace d'environ 25 minutes et semblaient cibler des portefeuilles partageant une vulnérabilité technique commune.
Une analyse ultérieure de la blockchain a permis d'estimer l'ampleur potentielle du vol. Les chercheurs ont calculé que de 1 082 à 1 196 adresses pourraient avoir été affectées sur une période d'environ 41 minutes. Par la suite, un tableau de bord de surveillance spécial appelé Coldcard Sweep Watch a estimé le montant total à 1 128,4717 $BTC, ce qui, au moment où le bitcoin se négociait autour de 63 044 dollars, représentait environ 71,1 millions de dollars.
La majeure partie des fonds était concentrée sur une seule adresse, qui contenait des centaines de bitcoins, et une partie importante de ces fonds était pratiquement inactive. Un détail important unissait les adresses touchées : leurs seeds de récupération avaient été créés sur des portefeuilles matériels Coldcard, fabriqués par la société canadienne Coinkite.
Une phrase de récupération (seed phrase) est une liste de mots qui contrôle l'accès à un portefeuille de cryptomonnaies. Toute personne capable de récupérer ou d'obtenir cette phrase de récupération peut généralement transférer les fonds du portefeuille sans posséder l'appareil physique.
Coldcard découvre une vulnérabilité dans le générateur de nombres aléatoires
Coinkite a émis un avertissement urgent indiquant que certains seeds générés sur les appareils Coldcard pourraient être vulnérables. Les appareils Mk3 avec le micrologiciel version 4.0.1, sorti vers mars 2021, et les versions ultérieures faisaient partie de ceux présentant le plus grand risque.
Une analyse plus poussée a élargi les préoccupations pour inclure les seeds créés sur certains appareils Mk4, Mk5 et Q avant que Coinkite ne publie des correctifs d'urgence pour le micrologiciel. Les produits Tapsigner, Opendime et Satscard ne seraient pas affectés par cette vulnérabilité, car ils utilisent un logiciel différent.
La vulnérabilité concernait le processus de génération de données aléatoires. La sécurité des portefeuilles dépend d'une haute qualité d'aléatoire pour que leurs seeds de récupération ne puissent être devinés. Selon les estimations des chercheurs, sur les appareils Mk3 les plus gravement touchés, le seed pouvait ne contenir qu'environ 40 bits d'aléatoire effectif au lieu des 128 bits prévus.
Cette différence est cruciale. Un seed 128 bits correctement généré est considéré comme pratiquement impossible à deviner par force brute. Un seed de 40 bits offre beaucoup moins de possibilités, permettant à un attaquant disposant d'une puissance de calcul suffisante de tester des seeds potentiels hors ligne et de comparer les adresses générées avec la blockchain publique de Bitcoin.
Certains appareils plus récents pourraient avoir fourni environ 72 bits d'aléatoire effectif, car le matériel de sécurité ajoutait une autre couche de données imprévisibles. Cela aurait rendu la récupération des seeds plus difficile, bien qu'ils soient restés beaucoup plus vulnérables que prévu.
Une erreur de configuration a persisté pendant 5 ans
Le problème a commencé par une erreur de configuration lors de la compilation, impliquant deux fonctions logicielles qui remplissaient des tâches similaires. Une fonction utilisait le générateur matériel de nombres aléatoires (TRNG) de l'appareil, tandis que l'autre s'appuyait sur un processus logiciel plus faible, hérité de MicroPython.
Coinkite avait l'intention de désactiver l'option MicroPython. Cependant, la vérification logicielle vérifiait seulement la présence d'une définition de marqueur de configuration, et non si sa valeur était définie sur zéro. Par conséquent, le micrologiciel final pouvait choisir silencieusement la fonction la plus faible.
Comme les deux fonctions avaient les mêmes formats, le logiciel continuait de se compiler et de fonctionner sans erreur apparente. L'erreur s'est glissée dans le code lors d'une migration logicielle en 2021 et est restée dans le micrologiciel public pendant plus de cinq ans.
La mise à jour de l'appareil ne renforce pas actuellement un seed généré par le logiciel défectueux. Les utilisateurs concernés doivent créer un tout nouveau seed à l'aide du micrologiciel corrigé ou d'un autre appareil sécurisé, puis transférer leurs fonds vers des adresses contrôlées par ce nouveau seed.
Les utilisateurs qui, lors de la création de leur seed, ont ajouté au moins 50 lancers de dés indépendants ont peut-être fourni suffisamment d'aléatoire pour éviter cette vulnérabilité. Un mot de passe fort selon le standard BIP-39 aurait également pu rendre la récupération plus difficile, et les portefeuilles nécessitant des signatures provenant de plusieurs appareils indépendants auraient pu empêcher le transfert de fonds à partir d'un seul seed compromis.
Coinkite pointe du doigt l'IA, mais les preuves manquent encore
Le PDG de Coinkite, Rodolfo Novak, s'est publiquement excusé et a déclaré que l'entreprise assumait l'entière responsabilité de l'erreur du micrologiciel. Il a indiqué que l'équipe travaillait sur un logiciel corrigé, des rapports techniques et un soutien aux utilisateurs touchés.
Coinkite et Novak ont également avancé une théorie frappante sur la façon dont la vulnérabilité a été découverte. Étant donné que le micrologiciel de la société était public depuis des années, celle-ci a déclaré penser que quelqu'un pourrait avoir utilisé l'IA pour analyser d'anciennes versions du code et découvrir la faille dans la génération de nombres aléatoires.
"À tous les autres développeurs : nous pensons que c'est la dure réalité du nouveau paradigme de l'IA. La revue de code par l'IA permet maintenant de trouver des bugs cachés à une vitesse surpassant même les experts les plus chevronnés de l'industrie", a écrit Novak dans son message d'excuses publié sur X. "Si votre micrologiciel est open source ou a déjà été public, considérez qu'il est déjà étudié à la fois par des attaquants et des experts en sécurité."
Les systèmes modernes de codage basés sur l'IA sont capables de traiter de vastes dépôts de logiciels et d'identifier des liens suspects entre les paramètres de configuration, les fonctionnalités et les hypothèses de sécurité. Un attaquant pourrait demander à un tel système de rechercher spécifiquement des générateurs de nombres aléatoires faibles, des fonctions de secours ou des erreurs affectant les clés cryptographiques.
Plus tard, des chercheurs indépendants ont signalé avoir utilisé des modèles d'IA pour détecter ou expliquer le problème après que le problème sous-jacent d'aléatoire a été rendu public. Cela a démontré à quel point l'analyse de code par l'IA était devenue accessible, mais n'a pas prouvé que l'attaquant initial avait utilisé l'IA.
Coinkite a reconnu que sa propre revue utilisant un modèle d'IA de premier plan n'avait pas réussi à identifier la vulnérabilité avant le vol. Ce résultat montre que les systèmes d'IA ne détectent pas automatiquement tous les défauts graves. Leur efficacité peut dépendre des instructions reçues, de la quantité de code fournie et de la compréhension par la personne effectuant la revue des signes avant-coureurs.
Les critiques affirment que l'erreur humaine est venue en premier
Certains experts en sécurité affirment qu'une focalisation excessive sur l'intelligence artificielle (IA) risque de détourner l'attention de l'erreur d'ingénierie fondamentale. Beaucoup estiment que l'erreur de configuration était un type connu de bug logiciel, et que des revues de code traditionnelles, des procédures de test ou des audits centrés sur la génération de seeds auraient pu la détecter il y a plusieurs années.
Les points de vue opposés ne sont pas nécessairement incompatibles. L'erreur humaine a créé la vulnérabilité et lui a permis de persister, tandis que l'IA a peut-être réduit le coût de sa découverte, de sa compréhension ou de son exploitation. Les défenseurs doivent identifier toutes les failles dangereuses, tandis qu'un attaquant n'a besoin d'en trouver qu'une seule.
Cet incident remet également en question les hypothèses sur la sécurité du code open source. Le code ouvert permet à des experts indépendants d'examiner les logiciels, mais la seule disponibilité ne garantit pas que quelqu'un analysera le bon morceau, détectera un défaut subtil et le signalera avant qu'un attaquant n'agisse.
Pour les utilisateurs de Coldcard, la priorité immédiate est de déterminer quand et comment leur seed a été généré. Toute personne dont le seed est affecté doit consulter les instructions via les canaux officiels de Coinkite, installer le micrologiciel corrigé, générer un nouveau seed et transférer prudemment les fonds, tout en étant vigilant face aux tentatives de phishing et aux faux messages de support.
À long terme, l'accent sera mis sur la quantité de bitcoins volés, sur la capacité des enquêteurs à identifier l'attaquant et sur le rôle décisif que l'intelligence artificielle a pu jouer dans la découverte de la vulnérabilité. Les fabricants de portefeuilles matériels devront également renforcer les tests d'entropie, auditer les configurations de compilation et revoir en permanence l'ancien code à l'aide à la fois d'experts humains et d'outils d'IA simulant des attaques.
