Les détenteurs canadiens de bitcoins constituent le groupe le plus important touché par l'attaque en cours sur le portefeuille matériel Coldcard, représentant 25 % de toutes les pertes associées. Les analystes notent que cette forte concentration régionale des pertes correspond à la présence locale importante de la société mère de Coldcard, Coinkite, dont le siège social est situé à Toronto.
Selon une analyse visuelle de Chainalysis, l'Australie arrive en deuxième position des pays les plus touchés par l'attaque, représentant entre 15 % et 20 % du préjudice total. Les États-Unis et la Thaïlande suivent, avec des pertes comprises entre 10 % et 15 %. Bien que la fuite ait principalement frappé les pays anglophones et les juridictions ayant adopté le bitcoin tôt, les données indiquent des répercussions mondiales plus larges en Europe de l'Ouest, en Amérique latine et dans des pôles cryptographiques africains clés tels que le Nigeria et l'Afrique du Sud.
Le montant total des actifs volés suite à cet incident a atteint 116 millions de dollars. En analysant l'incident, Galaxy Research a identifié la mise à jour du micrologiciel publiée en mars 2021 – et plus précisément l'introduction d'un nouveau générateur de nombres aléatoires – comme le seul point de défaillance ayant rendu l'attaque possible.
« Le problème était qu'il était connecté de manière incorrecte et utilisait par défaut un générateur plus faible. La défaillance s'est produite de manière imperceptible, sans aucun avertissement. Personne ne savait que leurs clés privées étaient générées avec une faible entropie », a déclaré Galaxy Research. « Cinq ans plus tard, un attaquant a volé 70 millions de dollars en 41 minutes à partir de 1200 portefeuilles. »
Expliquant pourquoi les vérifications standard n'ont pas détecté cette erreur pendant plus de cinq ans, Natalie Newson, enquêtrice principale en blockchain chez CertiK, a indiqué que la cause première résidait dans une erreur de configuration spécifique : la variable MICROPY_HW_ENABLE_RNG avait été définie à zéro.
« Pour une vérification statique #ifndef, une macro définie à 0 est toujours considérée comme définie », a expliqué Newson. « La vérification de sécurité renvoyait true, supprimant la protection #error et permettant au système de compilation de continuer comme si tout était configuré correctement. »
Protocoles de réponse aux incidents et d'atténuation d'urgence
Pour prévenir de tels basculements furtifs vers la pseudo-aléatoire logicielle, Newson a exhorté les fabricants à revoir leurs normes architecturales. « Le moyen de contrôle le plus robuste est de supprimer le mécanisme de secours de l'environnement de production et d'avoir exactement un fournisseur de GNA approuvé », a-t-elle souligné, notant que l'ensemble du chemin depuis l'obtention de l'entropie jusqu'à la génération de la graine doit impérativement respecter les limites de validation définies par la norme NIST FIPS 140-3.
Évoquant la gestion du risque opérationnel lié à la publication précipitée de correctifs d'urgence lors de contrôles automatisés actifs, Newson a souligné que la réponse aux incidents doit accorder une priorité égale à l'information des utilisateurs et aux tests techniques.
« La priorité doit être d'informer immédiatement sur l'étendue de la vulnérabilité, d'identifier les utilisateurs affectés et de fournir des instructions claires de réduction des risques, tout en testant minutieusement tout correctif avant sa publication », a déclaré Newson, ajoutant que la transparence est aussi importante que le correctif lui-même.
Pour les utilisateurs non techniques détenant des phrases de récupération compromises et craignant de rendre leurs appareils inutilisables lors de mises à jour d'urgence du micrologiciel, Newson a recommandé un protocole strict d'atténuation : premièrement, les utilisateurs doivent acquérir un portefeuille matériel fiable, générer une nouvelle phrase de récupération hors ligne et vérifier la configuration avec une petite transaction test. Ensuite, ils doivent transférer tous les fonds restants vers la nouvelle configuration vérifiée, avant d'essayer de mettre à jour le micrologiciel de l'appareil d'origine.
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 pour répartir le risque sur plusieurs comptes.
Un tournant pour le concept d'auto-gardiennage
Cet incident a contraint l'industrie de l'auto-gardiennage et ses partisans à se confronter à des questions fondamentales sur les modèles de sécurité standard. Les critiques pointent la disparition soudaine d'actifs inactifs à long terme comme preuve que le seul fait d'être exécuté hors ligne ne garantit pas une protection absolue.
Nanaak Nihal Khalsa, cofondateur de Human.tech, a déclaré que cet incident souligne la réalité immuable des risques liés à l'implication de tiers dans les écosystèmes de portefeuilles matériels.
« Le slogan 'Pas tes clés, pas tes pièces' omet un fait important : vous transférez toujours la confiance à des tiers, même en auto-gardiennage. Cela ne fait qu'ajouter une preuve supplémentaire que l'auto-gardiennage ne change pas ce fait », a remarqué Khalsa, avertissant que les vecteurs de menace émergents, comme les exploits utilisant l'IA, vont probablement exacerber ces risques.
Newson de CertiK a partagé les inquiétudes concernant les configurations à signature unique, notant que l'adoption de masse nécessite des systèmes conçus avec une dégradation gracieuse, où une seule erreur – qu'elle provienne de l'utilisateur ou du fournisseur – ne mène pas à la perte des économies d'une vie.
« L'auto-gardiennage à signature unique ne laisse aucune marge d'erreur », a déclaré Newson. « Les utilisateurs qui dépendent d'un seul appareil font confiance au matériel physique, au code et à toutes ses dépendances, ainsi qu'aux vérifications de contrôle qualité censées détecter tout problème. »
Par conséquent, le consensus dans le secteur évolue vers des configurations multi-fournisseurs, utilisant des signatures multiples ou des signatures à seuil (MPC) comme norme de base obligatoire.
« Oui, cela devrait être la norme de base par défaut », a conclu Newson. « L'objectif est de passer d'une 'confiance en un seul appareil' à s'assurer qu'aucun composant ou entité compromis ne puisse déplacer les fonds. En pratique, les clés de signature ou les parts de signature à seuil doivent couvrir des domaines indépendants de défaillances organisationnelles et technologiques, afin qu'aucun fournisseur seul ne puisse reconstituer la clé ou autoriser une transaction. »
