Les Canadiens concentrent 25% des pertes liées à l'exploit du wallet Coldcard

Les détenteurs de bitcoin au Canada représentent 25% des pertes attribuables à l'exploit visant les portefeuilles matériels Coldcard. Le total des actifs dérobés atteint 116 millions de dollars, et Galaxy Research relie l'attaque à une mise à jour de firmware publiée en mars 2021. Répartition géographique des pertes Le Canada apparaît comme la zone la plus touchée, une concentration que des analystes rapprochent de l'ancrage local de Coinkite, maison mère de Coldcard, dont le siège est à Toronto. D'après les visualisations de suivi de Chainalysis, l'Australie arrive en deuxième position avec 15% à 20% des dommages. Les États-Unis et la Thaïlande suivent, avec des pertes estimées entre 10% et 15%. Si l'incident a frappé en priorité des juridictions anglophones et historiquement parmi les premières adoptantes du bitcoin, les données mettent aussi en évidence des retombées plus larges en Europe occidentale, en Amérique latine et dans des pôles crypto africains majeurs comme le Nigeria et l'Afrique du Sud. Origine technique: une défaillance introduite en mars 2021 Selon Galaxy Research, le point de rupture provient d'une mise à jour de mars 2021, liée à l'implémentation d'un nouveau générateur de nombres aléatoires (RNG). "Le problème, c'est qu'il était câblé de façon incorrecte et basculait par défaut vers un RNG plus faible. La défaillance s'est produite silencieusement, sans alerte. Personne ne savait que les clés privées étaient générées avec une faible entropie", indique Galaxy Research. "Cinq ans plus tard, un attaquant a siphonné 70 millions de dollars depuis 1.200 wallets en 41 minutes." Natalie Newson, enquêtrice blockchain senior chez CertiK, explique que le bug est passé sous les radars pendant plus de cinq ans à cause d'une erreur de configuration: MICROPY_HW_ENABLE_RNG était réglé à zéro. "Pour un garde statique vérifiant #ifndef, une macro fixée à 0 reste définie", précise-t-elle. "Le contrôle de sécurité a été évalué à true, ce qui a neutralisé le garde #error et permis au système de build de continuer comme si tout était correctement configuré." Réponse à incident et remédiation d'urgence Pour éviter des bascules silencieuses vers de la pseudo-aléatoire logicielle, Newson appelle les fabricants à revoir leurs standards d'architecture. "Le contrôle le plus robuste consiste à supprimer la solution de repli en production et à n'avoir qu'un seul fournisseur RNG approuvé", souligne-t-elle, ajoutant que l'ensemble du chemin, de l'acquisition d'entropie à la génération de la seed, doit rester strictement dans le périmètre de validation défini par NIST FIPS 140-3. Face au risque opérationnel de publier des correctifs en urgence alors que des balayages automatisés sont en cours, elle insiste sur la communication aux utilisateurs autant que sur les tests. "La priorité doit être de communiquer immédiatement l'étendue de la vulnérabilité, d'identifier les utilisateurs concernés et de fournir des consignes de mitigation claires, tout en validant soigneusement tout correctif avant publication", affirme-t-elle, jugeant la transparence aussi essentielle que le patch. Pour les utilisateurs non techniques disposant de phrases de récupération potentiellement compromises et craignant de "briquer" leur appareil lors d'une mise à jour de firmware d'urgence, Newson recommande un protocole strict: se procurer d'abord un wallet matériel de confiance, générer une nouvelle seed hors ligne et valider l'installation via une petite transaction de test. Transférer ensuite l'ensemble des fonds restants vers ce nouveau dispositif vérifié, avant de tenter toute mise à jour sur l'appareil d'origine. Elle conseille aussi d'éviter un point de défaillance unique en répartissant les avoirs entre des wallets de fabricants différents. Un signal fort pour le récit de la self-custody L'épisode pousse l'industrie de la conservation autonome et ses défenseurs à réexaminer les modèles de sécurité standards. Des critiques y voient, avec le drainage soudain d'avoirs restés dormants sur le long terme, la preuve que l'exécution hors ligne ne garantit pas une protection absolue. Nanak Nihal Khalsa, cofondateur de Human.tech, estime que l'affaire illustre la persistance du risque de tiers dans les écosystèmes matériels. "'Not your keys, not your coins' manque un fait important: on externalise toujours la confiance, même en self-custody. Cela apporte simplement une preuve supplémentaire que la self-custody ne change pas cette réalité", observe-t-il, avertissant que des vecteurs émergents comme les exploits assistés par l'IA pourraient encore accroître ces risques. Newson met aussi en garde contre les configurations single-sig, jugeant que l'adoption grand public exige des systèmes capables d'une dégradation maîtrisée, où une erreur unique, côté utilisateur ou fournisseur, ne suffit pas à effacer les économies d'une vie. "La self-custody en single-sig ne laisse aucune marge d'erreur", dit-elle. "Les utilisateurs qui s'appuient sur un seul appareil font confiance au matériel, au code et à toutes ses dépendances, ainsi qu'aux contrôles QA censés détecter les problèmes." Dans ce contexte, le consensus de l'industrie s'oriente vers des schémas multi-fournisseurs, multi-signatures ou à signatures seuil (MPC) comme base de référence. "Oui, cela devrait être la base par défaut", conclut Newson. "L'objectif est de passer de 'faire confiance à un seul appareil' à la garantie qu'aucun composant ou acteur compromis ne puisse déplacer les fonds. En pratique, les clés de signature ou parts de seuil doivent s'étendre sur des domaines de défaillance organisationnels et technologiques indépendants, afin qu'aucun fournisseur ne puisse reconstituer la clé ou autoriser seul une transaction."