Coinkite, le fabricant de Coldcard, a publié le 20 août un nouveau firmware standard qui oblige les utilisateurs de portefeuilles matériels Bitcoin à ajouter une source d'aléa physique à chaque génération de seed : au moins 65 pressions sur les touches à des intervalles imprévisibles, 50 lancers d'un dé à six faces ou 128 lancers de pièce. Cette obligation fait suite à une faille qui permettait à des attaquants de reconstituer des clés privées à partir d'une seule pression sur un bouton dans les firmwares concernés, et Coinkite affirme que certains clients ont déjà subi de lourdes pertes. L'installation du firmware corrigé ne sécurise pas rétroactivement les seeds existantes. Les propriétaires concernés doivent donc générer une nouvelle seed et transférer les soldes, sauf si l'exception documentée des lancers de dé s'applique.
Pourquoi c'est important
La cause profonde, identifiée indépendamment par Block, était un code qui redirigeait les requêtes vers un mécanisme de repli déterministe de MicroPython, parce qu'un indicateur de fonctionnalité défini à zéro était considéré comme présent. Ce type de bug est structurel, et non le fruit d'un dysfonctionnement aléatoire, ce qui explique pourquoi Coinkite considère toute seed générée avec le firmware concerné comme susceptible d'être reconstituée. L'apport humain désormais obligatoire pour les nouvelles seeds standard ajoute une entropie externe et limite les dégâts en cas de nouvelle défaillance de l'aléa de l'appareil, mais ne peut pas ajouter rétroactivement de l'entropie à une seed existante. Coinkite indique que les forces de l'ordre enquêtent et que certains clients ont subi de lourdes pertes, même si aucun nombre vérifié de victimes ni montant total des pertes n'a été publié.
Impact sur le marché
Le périmètre d'exposition est plus large que celui de l'avis de Coinkite. Les recommandations de migration de Coinkite couvrent les firmwares Mk2 et Mk3 de 4.0.1 à 4.1.9, les firmwares standard Mk4 et Mk5 antérieurs à 5.6.0 et les firmwares Edge antérieurs à 6.6.0X, ainsi que les firmwares standard Q antérieurs à 1.5.0Q et les firmwares Edge antérieurs à 6.6.0QX, tandis que l'analyse technique de Block étend le périmètre des Mk2 et Mk3 à 4.0.0. Les propriétaires de la version 4.0.0 ne doivent pas considérer la limite fixée par le fabricant comme une preuve de sécurité. Les versions corrigées actuelles sont 5.6.1 pour les Mk4 et Mk5 et 1.5.1Q pour les appareils Q.
Questions fréquemment posées
-
Que change le nouveau firmware de Coldcard ?
Coinkite a publié le 20 août un firmware qui exige une source d'aléa physique pour chaque nouvelle seed : au moins 65 pressions de touche à intervalles imprévisibles, 50 lancers de dé ou 128 lancers de pièce, ainsi que le renforcement du chemin de signature, notamment par le blocage par défaut des modes SIGHASH_SINGLE.
-
Quelles versions du firmware Coldcard sont concernées ?
Les recommandations de migration de Coinkite couvrent les firmwares Mk2 et Mk3 de 4.0.1 à 4.1.9, les firmwares standard Mk4 et Mk5 antérieurs à 5.6.0 et les firmwares Edge antérieurs à 6.6.0X, ainsi que les firmwares standard Q antérieurs à 1.5.0Q et les firmwares Edge antérieurs à 6.6.0QX. L'analyse de Block étend le…
-
L'installation du firmware corrigé sécurise-t-elle une seed existante ?
Non, la mise à jour du firmware ne renforce que les nouvelles seeds. Les propriétaires d'un firmware concerné doivent générer une nouvelle seed, en vérifier l'empreinte, envoyer une transaction test et transférer tous les soldes associés à l'ancienne seed, sauf si l'exception documentée des lancers de dé s'applique.
-
Quand l'exception des lancers de dé s'applique-t-elle ?
La migration n'est pas nécessaire si l'utilisateur a effectué au moins 50 lancers réels d'un dé équilibré, indépendants et privés, via le processus concerné, sans jamais enregistrer ni exposer la séquence. Avec moins de lancers, ou au moindre doute sur ces conditions, l'utilisateur doit migrer.
-
Quelle était la cause profonde de la faille ?
Block a attribué le défaut à du code qui pouvait rediriger les requêtes vers un mécanisme de repli déterministe de MicroPython, parce qu'un indicateur de fonctionnalité défini à zéro était considéré comme présent. Ce bug structurel permettait aux attaquants de reconstituer des clés privées avec une seule pression sur…