Le développeur bitcoin Luke Dashjr a répertorié publiquement le 9 novembre neuf préoccupations concernant le code de génération de nombres aléatoires du wallet matériel Coldcard de Coinkite, affirmant qu'il les avait précédemment signalées à l'entreprise en privé.
« Je ne prétends pas que tous ces éléments puissent être weaponisés, ni qu’ils soient définitivement tous des bogues », a écrit Dashjr dans sa divulgation. Il a déclaré ne pas savoir si Coinkite les avait corrigés et a qualifié son examen d’aperçu rapide, et non d’audit complet.
Son fil fait référence à une révision du micrologiciel de juillet. Les notes de version ultérieures de Coinkite et leur source publiée montrent des modifications corrigeant plusieurs des points qu'il a soulevés, notamment les vérifications d'erreurs de graine de puce et un test de démarrage du chemin du RNG matériel.
https://x.com/i/status/2119836060306018364
La divulgation fait suite à l'incident de génération de seed de Coldcard en juillet. Coinkite affirme que les attaquants ont exploité des seeds de wallet affaiblies en régénérant les clés privées hors ligne et en volant les fonds, sans accéder à distance aux appareils.
Les messages numérotés de Dashjr ont soulevé des préoccupations concernant le code utilisé après le correctif précédent :
Il a remis en question la nécessité de rejeter les échantillons aléatoires initiaux au démarrage, a cité l'absence de vérifications de la graine du circuit et de l'erreur d'horloge, et a indiqué que le manuel du circuit exige un post-traitement pour les applications cryptographiques.
Il a déclaré que des vérifications de sortie répétées étaient appliquées aux lectures tamponnées, mais pas aux appels directs, et a soutenu que la routine de détection d'erreurs de niveau inférieur n'avait pas été suffisamment démontrée à elle seule.
Il s'est interrogé sur la raison pour laquelle la randomisation de l'élément sécurisé n'avait pas préservé la force attendue, a exigé un test complet du nouveau chemin RNG activé, et a demandé une vérification sur l'appareil plutôt que de s'appuyer uniquement sur les mesures de sécurité à la compilation.
Il a averti qu'un délai d'attente géré dans un contexte incapable de traiter en toute sécurité une exception Python pourrait provoquer un comportement indéfini, pouvant entraîner un plantage de l'appareil ou le rendre inutilisable.
Dashjr a déclaré qu'il avait rendu son analyse publique après avoir appris que NVK affirmait que les humains ne pouvaient pas détecter le défaut de Coldcard. Plus tôt dans la journée, le PDG de Coinkite, Rodolfo Novak, connu sous le nom de NVK, a écrit qu'il « fallait un nouveau modèle d'IA pour découvrir ce que les humains n'avaient pas pu trouver ». Le post de Novak concernait la découverte du défaut antérieur de génération de seed ; le fil technique de Dashjr abordait le code après la correction.
Mises à jour du micrologiciel ultérieures ajoutant des vérifications RNG
La page téléchargement de Coinkite liste la version 5.6.3 comme firmware standard actuel pour Mk4/Mk5 et la version 1.5.3Q pour Q. Son historique des versions indique que la détection d'erreurs de seed et un auto-test de démarrage du RNG matériel ont été ajoutés à la version 5.6.1, publiée le 20 août.
La source Mk4 publiée pour la version 5.6.3 rejette les échantillons de mise en route, vérifie les indicateurs d'erreur de graine, réessaie les échecs et teste si les appels atteignent le générateur de nombres aléatoires matériels. Les notes de version indiquent également que les deux éléments sécurisés sont désormais échantillonnés directement pour chaque nouvelle graine principale, plutôt que de contribuer uniquement via l'initialisation du RNG au démarrage.
La source actuelle place toujours son contrôle de sortie répétée dans la routine de lecture tampone plutôt que dans chaque appel direct. Ses commentaires indiquent que les indicateurs d'erreur d'horloge sont délibérément ignorés, en se référant à la documentation du circuit intégré selon laquelle ces erreurs n'invalident pas les nombres générés.
Pour les utilisateurs concernés par l'incident de juillet, les recommandations en vigueur de Coinkite restent que la mise à jour du firmware ne répare pas une graine déjà affaiblie. Ces utilisateurs doivent suivre les instructions de migration de Coinkite, sauf si l'exception indépendante-dice du conseil s'applique.