L'IA a-t-elle permis de découvrir la faille de sécurité de Coldcard ?

Un vol coordonné vide des centaines de portefeuilles

L’incident a été rendu public après que près de 594 BTC, d’une valeur d’environ 38 millions de dollars à l’époque, ont été transférés depuis environ 500 adresses Bitcoin à signature unique le 30 juillet. Lorsque la nouvelle a été révélée, Bitcoin.com News a noté que les transferts s’étaient déroulés en l’espace d’environ 25 minutes et semblaient cibler des portefeuilles présentant une faille technique commune.

Des analyses ultérieures de la blockchain ont permis d’élargir l’ampleur potentielle du vol. Les chercheurs ont estimé qu’entre 1 082 et 1 196 adresses auraient pu être touchées au cours d’une période d’environ 41 minutes. Un tableau de bord personnalisé appelé « Coldcard Sweep Watch » a par la suite chiffré le total à 1 128,4717 BTC, soit une valeur d’environ 71,1 millions de dollars alors que le bitcoin se négociait à près de 63 044 dollars.

La plupart des fonds ont été regroupés vers une adresse détenant des centaines de bitcoins, où une grande partie est restée pratiquement immobile. Les adresses concernées avaient un point commun important : leurs phrases de récupération avaient été générées sur des portefeuilles matériels Coldcard fabriqués par la société canadienne Coinkite.

Une phrase de récupération est une liste de mots qui contrôle l’accès à un portefeuille de cryptomonnaie. Quiconque parvient à reconstituer ou à obtenir cette phrase peut généralement transférer les fonds du portefeuille sans posséder l’appareil physique.

Coldcard découvre un système de génération aléatoire défaillant

Coinkite a publié un avis urgent avertissant que certaines clés de récupération générées sur les appareils Coldcard pouvaient présenter des failles. Les appareils Mk3 fonctionnant sous la version 4.0.1 du micrologiciel, sortie vers mars 2021, ainsi que les versions ultérieures, figuraient parmi ceux exposés au plus grand risque.

Une analyse plus approfondie a étendu la préoccupation aux graines créées 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 n’auraient pas été affectés, car ils utilisent des logiciels différents.

La faille concernait le processus utilisé pour générer des données aléatoires. Les portefeuilles sécurisés reposent sur un caractère aléatoire de haute qualité afin que leurs graines de récupération ne puissent pas être devinées. Sur les appareils Mk3 les plus gravement touchés, les chercheurs ont estimé que la graine ne contenait peut-être qu’environ 40 bits de caractère aléatoire effectif au lieu des 128 bits prévus.

Cette différence est cruciale. Une graine de 128 bits correctement générée est considérée comme pratiquement impossible à deviner par force brute. Une graine de 40 bits offre nettement moins de possibilités, ce qui permet à un attaquant disposant d’une puissance de calcul suffisante de tester des graines potentielles hors ligne et de comparer les adresses obtenues avec la blockchain publique de Bitcoin.

Certains appareils plus récents ont peut-être fourni environ 72 bits de randomité effective, car un matériel sécurisé ajoutait une couche supplémentaire de données imprévisibles. Cela rendrait les graines plus difficiles à reconstituer, bien qu’elles restent nettement plus faibles que prévu.

Une erreur de configuration est restée inaperçue pendant 5 ans

Le problème a commencé par une erreur de configuration lors de la compilation, impliquant deux fonctions logicielles qui effectuaient des tâches similaires. L’une utilisait le générateur de nombres aléatoires véritables intégré au matériel 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, une vérification logicielle se contentait de vérifier si une étiquette de configuration avait été définie, plutôt que de vérifier si sa valeur avait été mise à zéro. En conséquence, le micrologiciel final pouvait sélectionner en silence la fonction la plus faible.

Les deux fonctions ayant des formats identiques, le logiciel a continué à se compiler et à s’exécuter sans générer d’erreur manifeste. Cette erreur s’est glissée dans le code lors d’une migration logicielle en 2021 et est restée présente dans le micrologiciel accessible au public pendant plus de cinq ans.

La mise à jour d’un appareil ne renforce pas aujourd’hui une graine générée sous le logiciel défectueux. Les utilisateurs concernés doivent créer une graine entièrement nouvelle à l’aide du micrologiciel corrigé ou d’un autre appareil sécurisé, puis transférer leurs fonds vers des adresses contrôlées par cette nouvelle graine.

Les utilisateurs ayant ajouté au moins 50 lancers de dés indépendants lors de la création de leur graine ont peut-être apporté suffisamment d’aléatoire supplémentaire pour contourner cette faille. Une phrase de passe BIP-39 forte aurait également pu rendre la reconstruction plus difficile, tandis que les portefeuilles exigeant des signatures provenant de plusieurs appareils indépendants auraient pu empêcher une graine compromise de transférer des fonds à elle seule.

Coinkite met en cause l’IA, mais aucune preuve n’a encore été apportée

Le PDG de Coinkite, Rodolfo Novak, a présenté ses excuses publiquement et a déclaré que l’entreprise assumait l’entière responsabilité de la défaillance du micrologiciel. Il a indiqué que l’équipe travaillait à la mise au point d’un logiciel corrigé, à la rédaction de rapports techniques et à la mise en place d’une assistance pour les utilisateurs concernés.

Coinkite et M. Novak ont également avancé une théorie surprenante sur la manière dont la faille a été découverte. Son micrologiciel étant accessible au public depuis des années, l’entreprise a déclaré penser que quelqu’un avait peut-être utilisé l’IA pour examiner d’anciennes versions du code et repérer la faille liée au manque d’aléatoire. « À tous les autres développeurs : nous pensons qu’il s’agit là d’une réalité qui donne à réfléchir dans le nouveau paradigme de l’IA. La révision de code assistée par l’IA permet désormais de détecter des bogues latents à une vitesse qui dépasse même celle des experts les plus chevronnés du secteur », a écrit Novak dans son message d’excuses publié sur X. « Si votre micrologiciel est open source ou a déjà été rendu public, partez du principe qu’il est déjà en train d’être analysé tant par des attaquants que par des défenseurs. »

Les systèmes de codage IA modernes d’aujourd’hui sont capables de traiter de vastes dépôts de logiciels et d’identifier des relations suspectes entre les paramètres de configuration, les fonctions 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.

Des chercheurs indépendants ont par la suite indiqué avoir utilisé des modèles d’IA pour localiser ou expliquer le problème une fois que le problème de randomisation sous-jacent avait été identifié. Cela a démontré à quel point l’analyse de code assistée par l’IA est devenue accessible, mais cela n’a pas permis d’établir que le pirate d’origine avait utilisé l’IA.

Coinkite a reconnu que sa propre analyse, réalisée à l’aide d’un modèle d’IA de pointe, n’avait pas permis de détecter la faille avant le vol. Ce résultat montre que les systèmes d’IA ne détectent pas automatiquement tous les défauts graves. Leurs performances peuvent dépendre des instructions qu’ils reçoivent, de la quantité de code fournie et de la capacité d’un réviseur humain à comprendre les signaux d’alerte.

Les détracteurs affirment que l’erreur humaine est à l’origine du problème

Certains spécialistes de la sécurité font valoir qu’en mettant trop l’accent sur l’intelligence artificielle (IA), on risque de détourner l’attention d’une défaillance technique fondamentale. Beaucoup estiment que l’erreur de configuration était un type d’erreur logicielle connu, et que des revues de code classiques, des procédures de test ou des audits axés sur la génération de graines auraient pu la détecter des années plus tôt.

Ces points de vue opposés ne sont pas nécessairement incompatibles. Une 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 nécessaire pour la détecter, la comprendre ou l’exploiter. Les défenseurs doivent identifier toutes les failles dangereuses, tandis qu’un attaquant n’a besoin d’en localiser qu’une seule.

Cet incident remet également en question les idées reçues concernant la sécurité de l’open source. Le code public permet à des experts indépendants d’inspecter les logiciels, mais sa disponibilité ne garantit pas à elle seule que quelqu’un examinera la bonne section, reconnaîtra 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 graine a été créée. Toute personne disposant d’une graine affectée doit vérifier les instructions via les canaux officiels de Coinkite, installer le micrologiciel corrigé, créer une nouvelle graine et transférer ses fonds avec prudence, tout en restant vigilant face aux tentatives d’hameçonnage et aux faux messages d’assistance.

Les questions à plus long terme porteront sur le montant de bitcoins dérobés, sur la capacité des enquêteurs à identifier le pirate, et sur le rôle décisif que l’IA a pu jouer dans la découverte de la faille. Les fabricants de portefeuilles matériels seront également soumis à une pression pour renforcer les tests d’entropie, auditer les configurations de compilation et examiner en permanence l’ancien code à la fois avec des experts humains et des outils d’IA adversaire.