Carte froide : après la vulnérabilité de la clé secrète, obligation de saisir la clé 65 fois… La migration est obligatoire pour les anciens portefeuilles

La société Coinkite, fabricante de portefeuilles matériels pour Bitcoin, a annoncé le 20 août la publication d'une nouvelle version du firmware pour son appareil Coldcard. Cette mise à jour met l'accent sur l'obligation pour l'utilisateur d'intervenir physiquement et d'introduire une source de hasard lors de la création de la phrase de récupération. L'utilisateur doit obligatoirement effectuer l'une des actions suivantes : saisir au moins 65 clés à intervalles imprévisibles, lancer un dé à 6 faces 50 fois, ou lancer une pièce de monnaie 128 fois. Cette exigence vise à réduire les risques liés à la dépendance exclusive du portefeuille à son générateur de nombres aléatoires (RNG). Les versions concernées par cette recommandation sont nombreuses. Pour les modèles Mk2 et Mk3, il s'agit des firmwares de la version 4.0.1 à la 4.1.9. Pour les modèles Mk4 et Mk5, il s'agit des firmwares standard inférieurs à la version 5.6.0 et des firmwares "Edge" inférieurs à la version 6.6.0X. Pour les appareils de la série Q, il s'agit des firmwares standard inférieurs à la version 1.5.0Q et des firmwares "Edge" inférieurs à la version 6.6.0QX. Une analyse technique indépendante a révélé que les modèles Mk2 et Mk3 devraient également inclure la version 4.0.0, allant au-delà des limites officielles de CoinKite. Cette analyse met en garde contre le fait que les normes de sécurité proposées par le fabricant ne suffisent pas à garantir la sécurité. La cause fondamentale de cette vulnérabilité réside dans le code de repli (fallback) de MicroPython. Selon l'analyse de Block, un indicateur de fonctionnalité défini à zéro était traité comme "existant", ce qui pouvait entraîner le routage des demandes de génération de nombres aléatoires vers un mécanisme de repli déterministe. Par conséquent, lorsque la graine (seed) était générée sans suffisamment d'entropie externe, la sécurité était considérablement compromise. L'entrée physique forcée a pour objectif de limiter les dommages, même si la génération de nombres aléatoires de l'appareil échoue à nouveau, mais elle ne peut pas être appliquée rétroactivement à une graine déjà générée. Cette mise à jour comprend de nombreux éléments de sécurité, en plus de la génération de clés. Elle intègre une vérification pas à pas des checksums PSBT pour les revues USB, effectue une nouvelle vérification des octets de la transaction avant la signature, et bloque par défaut le mode SIGHASH_SINGLE. De plus, elle limite les téléchargements USB aux résultats de session chiffrés actuels, ajoute une vérification de la longueur des fichiers de firmware, arrête les problèmes persistants liés au générateur de nombres aléatoires (RNG), et inclut une fonction de vérification de la connexion au matériel RNG au démarrage. Il existe une exception à l'obligation de migration. Les utilisateurs qui utilisaient un firmware vulnérable et qui ont lancé le dé plus de 50 fois dans des conditions équitables, indépendantes et confidentielles sont exemptés de la migration. Cependant, si le nombre de lancers est insuffisant ou si l'utilisateur n'est pas certain que les conditions ont été remplies, il doit impérativement générer une nouvelle clé, sauvegarder ses données et transférer ses fonds. Le guide officiel de CoinKite recommande de procéder comme suit : générer une nouvelle clé, effectuer une sauvegarde, vérifier l'empreinte digitale du portefeuille, vérifier l'adresse de réception sur l'appareil, effectuer un petit transfert de test, puis transférer l'intégralité du solde. La duplication ou la restauration d'un portefeuille ne sont pas considérées comme la génération d'une nouvelle clé. Coinstrike a déclaré que certains clients avaient subi des pertes importantes et que les autorités enquêtaient sur l'affaire. Cependant, le nombre exact de victimes et l'ampleur totale des pertes n'ont pas été divulgués. De plus, l'entreprise a précisé que les éléments de vérification actuellement disponibles (examen du code source, tests du chemin d'accès du générateur de nombres aléatoires sur des appareils réels, construction reproductible et suivi du chemin des nombres aléatoires) ne constituent pas un audit complet de l'ensemble du binaire modifié.