Depuis un mois, les nerfs de sécurité du milieu Crypto sont de nouveau tendus.
D'abord, Coldcard a été exposé pour une grave vulnérabilité liée à la génération de nombres aléatoires, puis Trezor et SafePal ont successivement divulgué des incidents de fuite de données privées d'utilisateurs.
À première vue, ces trois incidents n'ont pas grand-chose en commun. Mais si l'on élargit légèrement la chronologie, on constate qu'ils pointent tous vers un problème de plus en plus crucial :
Alors que l'IA commence à automatiser la découverte de vulnérabilités, le développement d'attaques et l'ingénierie sociale, combien d'endroits d'un portefeuille cryptographique peuvent encore devenir le prochain point faible que les attaquants chercheront ?
I. Avec l'IA, les attaques de pirates passent d'un « travail artisanal » à une « production industrielle »
Objectivement, ces trois incidents exposent des surfaces d'attaque complètement différentes.
Le problème de Coldcard réside dans la génération de clés privées, une faille de sécurité grave ; celui de Trezor provient d'un service logistique tiers, celui de SafePal du système de commande et des autorisations des extensions, relevant d'une exposition aux risques liée à une fuite de données privées.
Bien qu'il n'y ait actuellement aucune preuve directe que ces trois incidents soient liés à l'IA, il faut admettre qu'à l'ère de l'IA, la « boîte à outils » des pirates est en train de subir une transformation radicale.
Parce que dans le passé, de nombreuses cyberattaques sophistiquées étaient fondamentalement limitées par une contrainte très réelle : le temps humain.
Étudier une grande base de code, comprendre les relations d'appel, trouver des vulnérabilités logiques cachées depuis des années, nécessitait l'investissement d'un temps considérable par des chercheurs en sécurité expérimentés ; cibler un utilisateur spécifique, recueillir ses informations d'identité, étudier ses habitudes, concevoir un e-mail de phishing suffisamment crédible, pouvait même exiger des mois pour construire un scénario complexe d'ingénierie sociale.
Cela conduisait à un compromis dans les attaques passées : soit un haut degré d'automatisation, mais des méthodes d'attaque relativement grossières, lançant un filet large pour attraper quelques utilisateurs ; soit une conception minutieuse pour des cibles à haute valeur spécifiques, mais difficilement reproductible à grande échelle.
Mais aujourd'hui, avec les capacités de l'IA évoluant à grande vitesse, la boîte à outils des pirates est radicalement mise à niveau :
- Automatisation de la découverte de vulnérabilités : L'IA peut aider les attaquants à analyser rapidement les contrats intelligents, le code client et même le firmware, cherchant automatiquement des vulnérabilités zero-day et des défauts logiques.
- Industrialisation de l'ingénierie sociale : Les e-mails de phishing qui nécessitaient autrefois une rédaction minutieuse peuvent maintenant être générés automatiquement par l'IA à partir de données d'identité utilisateur fuites, produisant un contenu de phishing hautement personnalisé, extrêmement convaincant, sous forme de SMS, voire de voix/vidéo (cf. « Manuel de sécurité des actifs pour le Nouvel An lunaire : Comment protéger vos tokens pendant les visites familiales et la détente ? »).
- Mise en œuvre intelligente des attaques : Du ciblage à la diffusion multicanale simultanée, le coût de l'ensemble de la chaîne d'attaque atteint un point historiquement bas.
On peut dire que des capacités autrefois dispersées entre différents attaquants – du ciblage et de la recherche de vulnérabilités à la génération de code malveillant, l'ingénierie sociale et la diffusion de contenu d'attaque – sont progressivement compressées dans un flux de travail plus automatisé.
C'est aussi l'impact vraiment profond de l'IA sur la cybersécurité.
Elle ne crée pas nécessairement soudainement un nouveau type d'attaque inédit, mais réduit rapidement le coût des méthodes d'attaque existantes – trouver une vulnérabilité devient moins cher, analyser une cible plus rapide, générer mille versions différentes d'e-mails de phishing bien plus facile qu'avant.
En d'autres termes, le fait qu'un système n'ait pas été attaqué par le passé ne signifie pas nécessairement qu'il n'y avait pas de vulnérabilité. Parfois, c'était simplement parce que la vulnérabilité était trop difficile à trouver, le coût de l'attaque trop élevé, ou le rapport qualité-prix pour l'attaquant trop faible. Maintenant, cette frontière de sécurité invisible qui reposait sur le fait que « l'attaquant n'a pas autant de temps » s'amincit progressivement.
Sous cet angle, la bataille offensive-défensive pour la sécurité des actifs cryptographiques est aussi en train de s'étendre d'une « guerre pour la clé privée » relativement concentrée, à une guerre d'usure couvrant l'ensemble de la chaîne : code, appareil, chaîne d'approvisionnement, identité utilisateur et interactions quotidiennes.
L'IA ne fait que presser encore plus sur l'accélérateur.
II. La véritable surface d'attaque d'un portefeuille va bien au-delà d'une phrase de récupération
C'est pourquoi les récents incidents, considérés ensemble, sont si représentatifs.
Ils frappent successivement différentes étapes du cycle de vie d'un portefeuille, nous rappelant que les risques auxquels un portefeuille fait face ont depuis longtemps dépassé la seule dimension « la clé privée est-elle volée ? », et s'inscrivent dans chaque maillon : génération de la clé privée, appareil matériel, chaîne d'approvisionnement logistique et même les informations privées de l'utilisateur.
Prenons un exemple simple.
Coldcard est l'exemple le plus typique, son problème survient alors que l'utilisateur n'a même pas encore vraiment commencé à utiliser le portefeuille.
La phrase de récupération semble toujours être 12 ou 24 mots normaux, l'appareil peut signer et transférer normalement, l'utilisateur pourrait même difficilement percevoir une anomalie. Mais si les nombres aléatoires qui ont généré cette phrase ne sont pas vraiment aléatoires, alors même si vous n'avez divulgué votre phrase de récupération à personne, vous restez potentiellement à risque.
Parce que la condition préalable de « bien garder sa phrase de récupération » est précisément que cette phrase ait d'abord été générée de manière suffisamment sécurisée et imprévisible.
Ensuite viennent Trezor et SafePal.
Contrairement à Coldcard, leur matériel lui-même n'a pas été compromis, la phrase de récupération est intacte, mais elles ont divulgué les données d'achat des utilisateurs – nom, téléphone, e-mail et même adresse de livraison.
C'est comme si vous achetiez un coffre-fort antibalise de pointe, le coffre n'est pas forcé, mais la société de livraison perd le bon de livraison, sur lequel est clairement écrit qui vous êtes, votre e-mail, votre numéro de téléphone, où vous habitez, et que vous avez acheté un portefeuille matériel spécialement conçu pour conserver des actifs cryptographiques.
L'attaquant obtient alors une piste d'utilisateurs Crypto à haute valeur potentielle. Il peut se faire passer pour le service client pour envoyer des notifications de « mise à jour urgente du firmware », personnaliser des pages de phishing en fonction du modèle acheté, téléphoner en prétendant une anomalie sur la commande, voire associer davantage les réseaux sociaux, l'identité publique et les adresses sur chaîne de l'utilisateur.
Autrement dit, ne pas pouvoir craquer la cryptographie ne signifie pas que l'attaque est sans issue.
Dans le monde réel, il existe même une théorie extrême qui circule depuis des années dans la communauté Crypto – l'« attaque à la clé de 5 dollars » : même l'algorithme de chiffrement le plus fort ne peut résoudre le problème d'un attaquant retrouvant directement le détenteur des actifs.
Ce n'est pas qu'un risque théorique. Selon les données fournies par Chainalysis au Financial Times, jusqu'à mi-août 2026, au moins 46 attaques violentes ciblant des détenteurs de Crypto ont été enregistrées cette année, dont plus de la moitié étaient des kidnappings, et plus d'un tiers des intrusions.
Ainsi, en revenant sur ces trois incidents, on réalise que ce qu'on appelle aujourd'hui la « sécurité d'un portefeuille » est en réalité devenue une longue chaîne :
Du code du portefeuille, de la génération des nombres aléatoires et des clés, à la puce, au firmware et à l'appareil, puis au site web, aux canaux d'achat, à la chaîne d'approvisionnement, à la logistique et aux bases de données de commandes ; une fois que l'utilisateur commence vraiment à l'utiliser, il se connecte au RPC, aux DApps, aux extensions de navigateur et aux contrats intelligents, puis il est question d'autorisations, de signatures, de service client, de réseaux sociaux et même d'Agents IA.
N'importe lequel de ces maillons, s'il devient le point le plus faible, peut contourner les défenses de sécurité établies par les autres maillons.
III. Quand l'attaque s'automatise, la défense doit intégrer l'IA
Si l'IA continue d'évoluer à son rythme actuel, les problèmes exposés aujourd'hui ne sont probablement qu'un début.
Parce que l'une des choses que l'IA fait le mieux, c'est de faire face à un système vaste et d'y chercher continuellement des anomalies, des modèles répétitifs et des points faibles.
Les attaquants peuvent faire scanner en continu le code open source par un Agent, tester en masse les pages web, les API et les autorisations d'extensions, collecter automatiquement des informations sur les réseaux sociaux et les bases de données publiques, puis filtrer les cibles potentielles à haute valeur.
Même le phishing lui-même pourrait évoluer des messages stéréotypés du type « votre portefeuille va expirer, entrez votre phrase de récupération », vers de véritables conversations en temps réel qui vous connaissent :
- Si l'attaquant sait que vous venez d'acheter un portefeuille matériel d'un certain modèle, il peut parfaitement générer pour vous une « notification de sécurité du firmware » correspondant à ce modèle.
- S'il sait que vous avez récemment participé à un protocole DeFi, il peut se faire passer pour l'équipe du projet pour vous faire migrer vers un nouveau coffre de protocole.
- S'il obtient davantage vos comptes sociaux et vos publications publiques, il peut même imiter un membre d'équipe, un KOL ou un agent du service client que vous connaissez pour interagir avec vous.
Sous cet angle, un défi majeur pour les portefeuilles à l'avenir sera : quand l'attaque est passée de « règles fixes » à un système qui analyse, juge et s'adapte, la défense peut-elle encore se contenter de règles statiques ?
Après tout, les mécanismes de sécurité des portefeuilles jusqu'à présent restent assez proches d'une « base de règles » : une adresse est marquée comme phishing, une fenêtre pop-up d'avertissement apparaît ; un domaine entre dans une liste noire, l'accès est bloqué ; un certain mode d'autorisation présente un risque élevé, une couche supplémentaire d'avertissement est ajoutée.
Ces mécanismes restent importants, mais face à des attaques de plus en plus dynamiques, s'appuyer uniquement sur les risques déjà survenus pour identifier le prochain risque n'est clairement plus suffisant.
L'IA peut précisément devenir un complément très important du côté défensif (cf. « Quand les pirates utilisent l'IA « plus efficacement », comment la course aux armements de la « lance et du bouclier » Web3 s'intensifie-t-elle ? »). En fait, ce n'est pas une nouvelle problématique qui apparaît soudainement.
Lors de discussions précédentes sur « IA × Sécurité Web3 », imToken avait déjà proposé des orientations similaires : à l'avenir, les capacités de sécurité d'un portefeuille ne devraient pas se limiter aux listes noires d'adresses, aux étiquettes de risque et aux fenêtres pop-up fixes. On pourrait utiliser l'IA pour intégrer davantage le jugement de sécurité dans l'ensemble du processus de transaction de l'utilisateur.
Par exemple, avant que le code n'entre en environnement de production, l'IA peut examiner continuellement les dépendances, les chemins d'appel et la logique anormale du code ; lorsqu'un utilisateur accède à une DApp, on peut combiner l'historique du domaine, le comportement du frontend, l'adresse du contrat et les relations sur chaîne pour juger s'il est anormal ; avant une signature, on peut simuler le résultat réel de l'exécution de la transaction, plutôt que de simplement montrer à l'utilisateur une chaîne de données hexadécimales difficile à comprendre.
Allant encore plus loin, le portefeuille pourrait progressivement établir un modèle de sécurité dynamique pour chaque utilisateur.
Un compte qui n'a effectué que des transferts de quelques centaines de dollars pendant longtemps, et qui soudain s'apprête à autoriser tous ses actifs à un contrat inconnu déployé il y a deux heures, est en soi un signal anormal ; une adresse avec laquelle un utilisateur n'a jamais interagi, demandant soudain une autorisation (Approval) illimitée, devrait recevoir une alerte de risque de priorité plus élevée ; et un e-mail prétendant provenir du support officiel du portefeuille, demandant à l'utilisateur d'entrer sa phrase de récupération, quel que soit le réalisme du contenu, devrait être directement classé comme à haut risque.
Ainsi, le changement apporté par l'IA ne se limite peut-être pas à « aider automatiquement l'utilisateur à juger si une adresse est sûre ». C'est plutôt comme si le portefeuille, passant d'un outil de conservation de clés et de signature relativement passif, acquérait progressivement une capacité active de jugement des risques.
Cela rend également une autre frontière de sécurité, évoquée précédemment par imToken, encore plus importante : l'IA peut aider les utilisateurs à comprendre et exécuter des opérations complexes, mais le contrôle des actifs ne doit pas pour cela être cédé indéfiniment. Pour les comportements clés tels que les transferts de gros montants, les autorisations à de nouvelles adresses, les interactions avec des contrats sensibles, etc., il faut toujours, à travers des principes de moindre privilège, une confirmation humaine, une simulation préalable à l'exécution et une explicabilité claire, limiter les capacités de l'IA à un champ d'autorisation bien défini.
En particulier dans les situations véritablement anormales, dire clairement à l'utilisateur « pourquoi c'est dangereux », « ce qui se passera après exécution » et « où se trouve exactement le risque ».
En d'autres termes, le sens de la défense par l'IA est de faire évoluer le portefeuille d'un outil de signature passif, vers un outil capable de comprendre activement les transactions, d'identifier les anomalies et de contraindre l'exécution.
Pour conclure
La série récente d'incidents de sécurité des portefeuilles ne signifie pas que le modèle d'auto-gestion (self-custody) a perdu sa valeur, encore moins que les utilisateurs devraient rendre le contrôle total de leurs actifs aux plateformes centralisées.
Ce qu'ils nous rappellent vraiment, c'est précisément que l'auto-gestion n'est jamais synonyme de sécurité naturelle, elle ne fait que rendre le contrôle absolu des actifs à l'utilisateur.
Et protéger ce contrôle nécessite un système de sécurité capable d'évoluer avec son temps, de se mettre à niveau continuellement, car la sécurité n'est pas une livraison de produit ponctuelle, c'est un processus dynamique et continu, qui nécessite les efforts conjoints des utilisateurs, des projets et des fabricants de portefeuilles.
Les attaquants peuvent utiliser l'IA pour comprendre le code, l'utilisateur et l'environnement, les défenseurs le peuvent aussi.
Ce sera une longue course à l'armement évolutive entre la « lance et le bouclier ».
