Les utilisateurs canadiens représentent 25 % des pertes liées à l'exploitation de la faille Coldcard

Répartition géographique des pertes

Les détenteurs canadiens de bitcoins apparaissent comme le groupe démographique le plus touché par l’attaque en cours visant le portefeuille matériel Coldcard, absorbant 25 % de l’ensemble des pertes attribuables. Les analystes notent que cette forte concentration régionale correspond à l’importante présence locale de la société mère de Coldcard, Coinkite, dont le siège social est situé à Toronto.

D’après le suivi visuel de Chainalysis, l’Australie se classe au deuxième rang des pays les plus durement touchés, représentant entre 15 % et 20 % du montant total des pertes. Les États-Unis et la Thaïlande suivent de près, avec des pertes comprises entre 10 % et 15 %. Si cette faille a frappé le plus durement les pays anglophones et les juridictions ayant adopté très tôt le bitcoin, les données mettent en évidence des répercussions mondiales étendues en Europe occidentale, en Amérique latine et dans les principaux pôles africains de la cryptomonnaie, tels que le Nigeria et l’Afrique du Sud.

Le montant total des actifs volés à la suite de cet incident s’élève à 116 millions de dollars. Dans une analyse de cette faille, Galaxy Research a identifié une mise à jour du micrologiciel datant de mars 2021 — plus précisément la mise en place d’un nouveau générateur de nombres aléatoires — comme le point de défaillance unique ayant permis l’attaque.

« Le problème venait d’un câblage incorrect qui a entraîné par défaut l’utilisation d’un générateur plus faible. La défaillance s’est produite silencieusement, sans aucun avertissement. Personne ne savait que ses clés privées étaient générées avec une faible entropie », a déclaré Galaxy Research. « Cinq ans plus tard, un pirate a dérobé 70 millions de dollars dans 1 200 portefeuilles en 41 minutes. »

Expliquant comment les contrôles standard n’ont pas détecté ce bug pendant plus de cinq ans, Natalie Newson, enquêtrice senior spécialisée dans la blockchain chez CertiK, a révélé que la cause première provenait d’une erreur de configuration spécifique : la variable MICROPY_HW_ENABLE_RNG était définie sur zéro.

« Pour un contrôle statique de type #ifndef, une macro définie sur 0 est toujours considérée comme définie », a expliqué Mme Newson. « Le contrôle de sécurité a renvoyé la valeur "true", supprimant ainsi le contrôle #error et permettant au système de compilation de poursuivre comme si tout était correctement configuré. »

Protocoles d’intervention en cas d’incident et de correction d’urgence

Afin d’éviter que des replis silencieux similaires ne se produisent vers un pseudo-aléatoire logiciel, Mme Newson a exhorté les fabricants à revoir en profondeur leurs normes architecturales. « La mesure de contrôle la plus efficace consiste à supprimer ce repli de l’environnement de production et à n’avoir qu’un seul fournisseur de générateur de nombres aléatoires (RNG) agréé », a-t-elle souligné, précisant que l’ensemble du processus, de l’acquisition de l’entropie à la génération de la graine, doit se situer strictement dans les limites de validation définies par la norme NIST FIPS 140-3.

Concernant la gestion du risque opérationnel lié au déploiement précipité de correctifs d’urgence alors que des analyses automatisées sont en cours, Mme Newson a souligné que la réponse aux incidents doit accorder la priorité à la communication avec les utilisateurs parallèlement aux tests techniques.

« La priorité doit être de communiquer immédiatement l’étendue de la vulnérabilité, d’identifier les utilisateurs concernés et de fournir des conseils clairs sur les mesures d’atténuation, tout en validant minutieusement tout correctif avant sa publication », a déclaré Mme Newson, ajoutant que la transparence est tout aussi cruciale que le correctif lui-même.

Pour les utilisateurs non techniciens détenant des phrases de récupération compromises et craignant de « bricker » leurs appareils lors de mises à jour d’urgence du micrologiciel, M. Newson a recommandé un protocole de remédiation strict : tout d’abord, les utilisateurs doivent se procurer un portefeuille matériel fiable, générer une nouvelle phrase de récupération hors ligne et vérifier la configuration à l’aide d’une petite transaction test. Ensuite, ils doivent transférer tous les fonds restants vers la configuration nouvellement vérifiée avant de tenter toute mise à jour du firmware sur l’appareil d’origine. M. Newson a également exhorté les utilisateurs à éviter de créer un point de défaillance unique en utilisant des portefeuilles matériels de différents fabricants afin de répartir le risque sur plusieurs comptes.

Un tournant pour les discours sur l’auto-custode

Cet incident a contraint le secteur de l’auto-custode et ses défenseurs à se poser des questions fondamentales sur les modèles de sécurité standard. Les détracteurs soulignent que la fuite soudaine de avoirs dormants et détenus depuis longtemps prouve que l’exécution hors ligne à elle seule ne garantit pas une protection absolue.

Nanak Nihal Khalsa, cofondateur de Human.tech, a fait valoir que cet incident met en évidence la réalité persistante du risque lié aux tiers au sein des écosystèmes matériels. « Le slogan “Ce ne sont pas vos clés, ce ne sont pas vos cryptomonnaies” passe à côté d’un fait important : vous externalisez toujours la confiance, même en cas d’auto-custode. Cela ne fait qu’ajouter un élément de preuve supplémentaire au fait que l’auto-custodie ne change rien à cette réalité », a observé M. Khalsa, avertissant que les vecteurs de menaces émergents, tels que les exploits assistés par l’IA, risquent d’aggraver ces risques.

M. Newson, de CertiK, a fait écho à ces préoccupations concernant les configurations à signature unique, soulignant que l’adoption à grande échelle nécessite des systèmes conçus avec une dégradation progressive, où une seule erreur — de la part d’un utilisateur ou d’un fournisseur — ne réduit pas à néant les économies d’une vie.

« L’auto-custodie à signature unique n’offre aucune marge d’erreur », a déclaré M. Newson. « Les utilisateurs qui s’appuient sur un seul appareil font confiance au matériel physique, au code et à toutes ses dépendances, ainsi qu’aux contrôles d’assurance qualité destinés à détecter d’éventuels problèmes. »

Par conséquent, le consensus du secteur s’oriente vers des configurations multi-fournisseurs, à signatures multiples ou à signature par seuil (MPC) comme norme minimale impérative. « Oui, cela devrait être la norme par défaut », a conclu M. Newson. « L’objectif est de passer de la “confiance en un seul appareil” à la garantie qu’aucun composant ou acteur compromis ne puisse à lui seul déplacer les fonds. En pratique, les clés de signature ou les parts de seuil doivent s’étendre sur des domaines de défaillance organisationnels et technologiques indépendants, de sorte qu’aucun fournisseur ne puisse reconstituer la clé ou autoriser une transaction à lui seul. »