Pour Haseeb Qureshi, associé directeur de Dragonfly, l'aspect le plus frappant de l'expérience GLM 5.2 a été son coût : « GLM 5.2 fonctionnant pendant 20 minutes coûte environ 2 $. Qu'est-ce que cela signifie ? Cela signifie que nous sommes dans un nouveau monde. »

Dragonfly est une société de capital-risque spécialisée dans les cryptomonnaies, et les observations de Qureshi ont du poids dans une industrie où les failles logicielles ont permis certains des plus grands vols jamais enregistrés. Le modèle aurait redécouvert la vulnérabilité liée au récent vol sur ColdCard après que des chercheurs l'aient orienté vers le logiciel concerné. ColdCard, fabriqué par Coinkite, est un portefeuille matériel populaire parmi les utilisateurs de Bitcoin en autoséquestre. Il n'y a aucune preuve que les voleurs aient utilisé l'IA. Le test démontre plutôt à quel point les attaquants comme les développeurs peuvent désormais examiner à faible coût le code qui protège de grandes quantités de cryptomonnaies.

Pourquoi le coût de 2 $ est important

La recherche sérieuse de vulnérabilités exigeait traditionnellement des connaissances spécialisées et de nombreuses heures de travail manuel. Même un chercheur expérimenté ne peut inspecter qu'un nombre limité de versions de firmware, de contrats intelligents et de bibliothèques cryptographiques.

L'IA permet à un beaucoup plus grand volume de code de faire l'objet d'un premier examen. Les chercheurs peuvent affecter plusieurs modèles au même code source, leur demander d'explorer différentes pistes de défaillance et répéter le processus chaque fois qu'un modèle plus puissant devient disponible.

La plupart des recherches peuvent ne rien produire d'utile. Cela devient moins important lorsqu'une tentative individuelle ne coûte que quelques dollars. Quelqu'un qui cherche des failles peut examiner de nombreuses cibles sans avoir besoin que chaque exécution aboutisse. Une seule faille valide dans un logiciel protégeant des millions de dollars pourrait justifier le coût de milliers de tentatives infructueuses.

L'IA n'a pas éliminé le besoin d'expertise en sécurité. Elle a réduit le coût de génération de pistes, de test d'hypothèses et de couverture d'un volume de code supérieur à ce qu'un chercheur humain pourrait inspecter seul.

Ce que le test GLM 5.2 montre réellement

Qureshi a déclaré que les chercheurs avaient demandé à plusieurs modèles d'examiner le logiciel après que l'incident ColdCard avait déjà attiré l'attention dessus. Selon lui, les modèles n'ont pas été informés de l'emplacement de la vulnérabilité, et GLM 5.2 l'a trouvée en environ 20 minutes.

Le contexte est important. Les chercheurs savaient déjà que le logiciel concerné contenait un problème sérieux. Le modèle ne cherchait pas à l'aveugle dans tous les portefeuilles matériels ni ne découvrait une attaque sans point de départ.

Identifier un bug est également différent de l'exploiter à grande échelle. Un attaquant peut encore avoir besoin de :

• Déterminer quels appareils ou portefeuilles sont affectés.
• Reconstituer des clés privées utilisables.
• Identifier les portefeuilles contenant des soldes importants.
• Transférer les fonds avant que les utilisateurs ou les fabricants ne puissent réagir.

Les commentaires de Qureshi ne montrent pas que GLM 5.2 a effectué ces étapes ni qu'un système d'IA a participé au vol initial. Ce que l'expérience établit est plus limité mais reste important : un modèle à usage général aurait redécouvert la faiblesse technique sous-jacente rapidement et à un coût négligeable.

L'IA est là avant la menace quantique

Une grande partie du débat sur la sécurité à long terme autour du Bitcoin s'est concentrée sur l'informatique quantique. Une machine quantique suffisamment puissante pourrait menacer les schémas de signature protégeant les pièces, forçant les réseaux et les utilisateurs à migrer vers de nouvelles techniques cryptographiques. Ce risque nécessite une préparation anticipée.

L'analyse de code assistée par l'IA présente un problème différent car les outils peuvent déjà être utilisés contre des logiciels en fonctionnement aujourd'hui. L'IA n'a pas besoin de vaincre les mathématiques sous-jacentes du Bitcoin. Elle peut rechercher dans le code environnant des erreurs telles qu'une génération faible de nombres aléatoires, des secrets exposés, des implémentations cryptographiques défectueuses et des fonctions de récupération non sécurisées.

Une analyse précédente des menaces de l'IA et de l'informatique quantique pour les cryptomonnaies a examiné la même distinction. L'informatique quantique pourrait éventuellement créer un problème cryptographique à l'échelle du réseau. L'IA peut déjà être dirigée vers des portefeuilles, des ponts, des bibliothèques et des applications qui protègent actuellement les fonds des utilisateurs.

La préoccupation immédiate est donc une erreur humaine dans le logiciel entourant le Bitcoin plutôt qu'une IA cassant le Bitcoin lui-même.

Attaquants et développeurs ont accès au même outil

L'IA n'a aucune préférence pour une sécurité renforcée ou une attaque réussie. Son effet dépend de la tâche que les gens lui confient.

Un attaquant peut utiliser un modèle pour scanner d'anciens firmwares, automatiser des analyses répétitives et tester des faiblesses potentielles. Un fabricant de portefeuilles peut utiliser le même modèle avant la mise sur le marché, en l'orientant vers la génération de clés, la signature de transactions et les procédures de récupération.

Les développeurs peuvent également réexaminer des produits commercialisés avant l'existence des agents de codage modernes. Un logiciel audité il y a cinq ans peut désormais être examiné avec des outils qui n'étaient pas disponibles lorsqu'il a atteint les clients. Plusieurs entreprises de sécurité blockchain ont déjà commencé à intégrer l'analyse assistée par l'IA dans leurs flux de travail d'audit, bien que la technologie reste un complément à la révision humaine plutôt qu'un remplacement.

Les deux camps ne fonctionnent cependant pas dans des conditions égales. Un attaquant peut agir dès qu'une vulnérabilité utile est confirmée. Un développeur doit reproduire la découverte, comprendre quels utilisateurs sont affectés, préparer un correctif sûr et le distribuer sans révéler suffisamment d'informations pour accélérer l'exploitation.

Les modèles peuvent également mal interpréter le code, produire des faux positifs ou décrire des attaques qui échouent en pratique. Les chercheurs humains restent responsables de vérifier le résultat et de décider de l'urgence de la réponse du projet.

L'IA élargit le volume de code pouvant être examiné. Elle ne remplace pas l'expertise ni la réponse aux incidents requise après la découverte d'une faille sérieuse.

L'autoséquestre dépend toujours du portefeuille

Qureshi a décrit les utilisateurs affectés comme des personnes qui avaient suivi les conseils de sécurité habituels : « Des personnes qui font tout correctement. »

Ils avaient déplacé leur Bitcoin hors des plateformes d'échange et l'avaient stocké dans des portefeuilles matériels dédiés. Pourtant, l'autoséquestre dépend toujours de la capacité de l'appareil à créer et protéger correctement ses clés.

Qureshi a déclaré que le firmware affecté utilisait une source d'aléatoire plus faible que prévu. Si une clé privée est générée à partir d'entrées prévisibles, maintenir l'appareil hors ligne ne peut pas rendre la clé plus forte a posteriori. Une séparation physique (air gap) peut réduire l'exposition aux attaques à distance contre un secret correctement généré. Elle ne peut pas réparer un secret qui était faible dès sa création.

Les utilisateurs de portefeuilles matériels dépendent donc de plus que de leur propre gestion de la phrase de récupération. Ils font également confiance au firmware du fabricant, à la conception matérielle, aux bibliothèques cryptographiques et au générateur de nombres aléatoires. Des années sans exploitation connue peuvent montrer qu'un logiciel a survécu à un usage ordinaire. Elles ne prouvent pas que chaque faiblesse sérieuse a déjà été identifiée.

L'ancien code de portefeuille doit être réexaminé

Une analyse par IA moins coûteuse rend l'ancien code plus facile à réévaluer. Les logiciels qui attiraient auparavant peu d'attention peuvent désormais être examinés de manière répétée et à grande échelle.

Les fabricants de portefeuilles et les protocoles cryptographiques devraient réanalyser les anciennes versions lorsque les modèles majeurs s'améliorent, en particulier lorsque le code crée des clés privées, signe des transactions ou contrôle la récupération de portefeuille.

Une mise à jour de firmware ne résoudra pas tous les problèmes. Lorsqu'une faille affecte la façon dont les clés existantes ont été créées, la correction du logiciel peut protéger les nouveaux portefeuilles tout en laissant les anciens exposés. Les utilisateurs peuvent avoir besoin de générer de nouvelles clés dans le système réparé et de transférer leurs fonds. Les fournisseurs devraient donc être capables d'identifier les versions affectées, de contacter rapidement les clients et d'expliquer comment migrer en toute sécurité.

Ce processus crée également des opportunités pour les escrocs. Les incidents de sécurité produisent souvent de faux comptes de support, des sites de migration malveillants et des messages demandant aux utilisateurs de vérifier leurs portefeuilles. Les utilisateurs ne devraient jamais fournir de phrase seed ou de clé privée à un représentant de support, un site web, un compte de réseau social ou un chatbot d'IA. Un processus de récupération légitime ne nécessite pas qu'une autre personne ou un autre service reçoive ces secrets.

La revue de sécurité ne peut plus être un événement unique

L'analyse assistée par l'IA devrait faire partie du développement normal plutôt qu'un outil utilisé uniquement après que des fonds ont été volés. Les entreprises de cryptomonnaies devraient envisager :

• Scanner le nouveau code avant sa mise en production.
• Réexaminer les anciens firmwares et bibliothèques à mesure que les modèles s'améliorent.
• Utiliser plusieurs modèles pour aborder le même code sous différents angles.
• Demander à des chercheurs expérimentés de reproduire les découvertes sérieuses.
• Préparer des procédures de communication d'urgence et de migration de portefeuilles.
• Maintenir des programmes de divulgation responsable et de chasse aux bugs.

Les modèles offrent une couverture plus large et plus rapide. Les équipes de sécurité doivent toujours distinguer les véritables vulnérabilités des rapports incorrects, développer un correctif et gérer les conséquences pour les utilisateurs.

La course à la sécurité devient moins coûteuse

L'exemple de Qureshi ne montre pas que l'IA peut casser le Bitcoin. Il montre que les logiciels protégeant le Bitcoin peuvent désormais être testés pour des vulnérabilités à un coût qui devient rapidement négligeable.

Ce développement peut produire une meilleure sécurité ou des attaques moins coûteuses. Les développeurs peuvent utiliser l'IA pour mettre à l'épreuve leurs propres produits et détecter les erreurs avant la mise en production. Les attaquants peuvent l'orienter vers du code oublié, répéter des recherches sur de nombreuses cibles et agir dès le premier résultat utile.

La technologie est disponible pour les deux. Le résultat dépend de qui l'utilise, de la précision avec laquelle les découvertes sont vérifiées et de la rapidité de réponse des défenseurs. Les projets qui réévaluent continuellement leurs logiciels peuvent bénéficier des mêmes outils qui facilitent les attaques. Ceux qui s'appuient sur d'anciens audits ou qui supposent qu'un bug caché depuis longtemps aurait déjà été trouvé laissent cette opportunité à quelqu'un d'autre.

Avis de non-responsabilité : Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil en matière de sécurité, de finance ou d'investissement. L'expérience rapportée n'établit pas que l'IA a été utilisée dans le vol ColdCard ni que GLM 5.2 peut identifier de manière fiable chaque vulnérabilité logicielle.

Méthodologie : Cette analyse utilise les commentaires publics de Haseeb Qureshi, associé directeur de Dragonfly, concernant l'incident ColdCard et le test GLM 5.2 signalé. La comparaison entre les risques liés à l'IA et à l'informatique quantique distingue les outils de recherche de vulnérabilités actuellement disponibles des menaces à plus long terme nécessitant du matériel quantique capable sur le plan cryptographique.