Sécurité des portefeuilles matériels bitcoin : Enseignements tirés de la faille de génération de la graine Coldcard
2026/08/09 08:05:06
Bogue de génération de seed Coldcard expose une faiblesse de la sécurité des wallets bitcoin
Un changement de micrologiciel en mars 2021 dans les portefeuilles matériels Bitcoin Coldcard de Coinkite a redirigé la génération de la graine loin du générateur matériel de nombres aléatoires STM32 prévu vers un générateur logiciel déterministe de nombres pseudo-aléatoires. L'erreur est restée non détectée jusqu'à la fin juillet 2026, lorsque des attaquants ont vidé plus de 1 000 adresses bitcoin en vagues coordonnées, retirant environ 1 082 à 1 367 BTC d'une valeur comprise entre 70 millions et 88 millions de dollars à l'époque. Galaxy Research a cartographié la première vague de 41 minutes portant sur 1 196 adresses le 30 juillet, puis a identifié par la suite des vagues supplémentaires qui ont élargi le total observé. L'équipe d'ingénierie de Block et des chercheurs indépendants ont remonté la cause racine à une vérification de macro du préprocesseur qui liait libngu à la fonction de secours Yasmarang de MicroPython, qui était initialisée à partir de l'ID unique du processeur et des registres du minuteur, plutôt qu'à une entropie fraîche.
Coinkite a confirmé le problème sur les modèles Mk2, Mk3, Mk4, Mk5 et Q, a publié un micrologiciel d'urgence le lendemain, et a demandé aux utilisateurs de générer de nouveaux seeds complets, car la mise à jour du micrologiciel existant ne peut pas réparer une phrase de récupération compromise. Cet épisode a renouvelé l'attention portée sur la manière dont les portefeuilles matériels obtiennent et vérifient l'entropie, les limites pratiques de l'audit open-source, et les risques résiduels qui persistent même dans les appareils isolés. La faille de génération de seed du Coldcard démontre que les portefeuilles matériels restent dépendants de l'intégration correcte des sources d'entropie dans le micrologiciel ; une erreur de configuration unique durant cinq ans peut réduire la randomité effective bien en dessous de la cible de 128 bits d'un seed BIP-39 standard, permettant la reconstruction hors ligne des clés privées et un vol à grande échelle que n'importe quelle isolation physique ne peut empêcher une fois que le seed lui-même est faible.
Comment une migration du micrologiciel 2021 a désactivé le générateur aléatoire matériel de Coldcard
En mars 2021, Coinkite a migré les opérations elliptiques de Coldcard vers libsecp256k1 de Bitcoin Core et a introduit la bibliothèque libngu MicroPython. Le code de génération de seed est passé de l'appel spécifique à la carte ckcc.rng_bytes, qui invoquait correctement le générateur de nombres aléatoires matériels true RNG de STM32, à ngu.random.bytes. La configuration de la carte de production définissait MICROPY_HW_ENABLE_RNG à zéro car Coinkite fournissait son propre wrapper pour le RNG matériel. La vérification du préprocesseur de libngu ne testait que si la macro était définie, et non si sa valeur était non nulle. En conséquence, la compilation a réussi et s'est liée à la fonction de secours logicielle Yasmarang de MicroPython. Cette fonction de secours s'est initialisée une seule fois, en utilisant les 32 bits les moins significatifs de l'ID unique du puce XORés avec les registres de temps SysTick et RTC, puis a produit un flux déterministe sans collecte supplémentaire d'entropie.
Sur les appareils Mk2 et Mk3 fonctionnant sous les versions 4.0.1 à 4.1.9, le chemin fourni n'offrait pratiquement aucune entropie cryptographique. Plus tard, les firmwares Mk4, Mk5 et Q mélangeaient des valeurs de secure-element, mais ne conservaient que quatre octets après hachage et les utilisaient pour réinitialiser un seul mot d'état de 32 bits, laissant environ 72 bits d'entropie effective contre les 128 bits prévus. Le code prévu du RNG matériel restait présent dans le binaire, mais n'était jamais atteint par le chemin de génération du wallet. Les revues de code existantes ont confirmé la présence de l'implémentation TRNG, mais n'ont pas vérifié la résolution symbolique de bout en bout depuis le point d'appel de génération de la graine. La régression est donc restée indétectée pendant plus de cinq ans jusqu'à ce qu'une exploitation active force la divulgation publique.
Effet et résultat
La conséquence pratique est qu’un attaquant capable de contraindre ou d’obtenir l’UID du dispositif, le moment approximatif du démarrage et l’historique des appels RNG précédents peut régénérer des flux candidats hors ligne. Chaque candidat peut être étendu en une graine BIP-39, transformé en adresses, puis vérifié sur la blockchain publique. Pour les dispositifs Mk3 les plus gravement affectés, Coinkite a estimé l’espace de recherche effectif à environ 40 bits ; l’analyse de Block a placé les limites conditionnelles bien en dessous des niveaux de sécurité cryptographique pour les modèles ultérieurs.
Le hachage de la sortie faible ou l'application du checksum BIP-39 ne peut pas augmenter le nombre de graines possibles. Une fois qu'une adresse correspondante est trouvée, la clé privée associée contrôle chaque dérivation ultérieure, permettant un retrait complet sans accès physique à l'appareil. La surface d'attaque dépend donc de la phrase de récupération elle-même, et non de l'appareil qui la contient actuellement. Restaurer une graine affectée sur un firmware corrigé ou sur tout autre wallet ne fait que transférer le même secret faible.
Galaxy Research cartographie le sweep du 30 juillet et les vagues suivantes
Le 30 juillet 2026, un opérateur non identifié a vidé 1 196 adresses bitcoin dans une fenêtre de 41 minutes, en retirant 1 082,65 BTC d'une valeur d'environ 70,2 millions de dollars. Galaxy Research a identifié le cluster grâce à un taux de frais distinctif de 30 sat/vB et à l'absence de sorties de change, des motifs qui se démarquaient de l'activité normale sur la chaîne. L'entreprise a ensuite documenté deux vagues supplémentaires, portant le total cumulé observé à 1 367,05 BTC sur 4 585 adresses, soit environ 88,6 millions de dollars aux prix en vigueur. Galaxy a averti que les heuristiques sur la chaîne seules ne prouvent pas computationnellement que chaque adresse provient d'une faible entropie Coldcard, mais le regroupement temporel et la liaison technique fournie par l'analyse de cause racine de Block rendent cette connexion hautement probable.
L'entreprise a signalé environ 600 adresses suspectées d'être contrôlées par des attaquants aux enquêteurs et aux services de conformité. Aucune reconstitution publique d'une seed victime spécifique n'a été publiée, mais l'ampleur des prélèvements démontre que l'entropie réduite était suffisante pour un énumération hors ligne pratique une fois que les contraintes d'état de l'appareil nécessaires étaient connues ou approchées. La rapidité de la première vague souligne que la vulnérabilité ne nécessitait aucune interaction en temps réel avec les wallets physiques. Une fois que les seeds candidates pouvaient être générées et validées contre des adresses connues financées, l'opérateur signait et diffusait simplement les transactions.
Des vagues ultérieures ont continué après l'avis de Coinkite, indiquant que tous les détenteurs n'avaient pas terminé la migration. Galaxy a noté que le modèle de transaction identifie davantage l'opérateur que le vol lui-même, car un détenteur légitime regroupant des pièces peut produire des signatures identiques sur la blockchain. L'absence d'activités antérieures partageant les mêmes caractéristiques de frais et de change au cours des trente jours précédents a renforcé l'attribution à une seule campagne plutôt qu'à un comportement utilisateur organique. L'incident illustre donc à la fois la puissance de l'analyse de blockchain pour une détection rapide et les limites de ces outils lorsque la faiblesse cryptographique sous-jacente provient hors ligne.
Réponse d'urgence et correctifs hotfix du firmware de Coinkite
Coinkite a publié son premier avis public le 31 juillet 2026 et a élargi le périmètre le lendemain après une analyse supplémentaire. Des versions corrigées du micrologiciel ont été publiées pour chaque modèle concerné : 4.2.0 pour les Mk2 et Mk3, 5.6.0 pour les Mk4 et Mk5 standards, 1.5.0Q pour les Q standards, ainsi que les builds Edge correspondants 6.6.0X et 6.6.0QX. L'entreprise a arrêté les expéditions des stocks vulnérables et détruit les stocks restants. Les conseils officiels soulignent que l'installation du nouveau micrologiciel ne répare pas une graine existante ; une nouvelle graine doit être générée sur l'appareil corrigé, et les fonds doivent être transférés après vérification de la nouvelle sauvegarde et de l'adresse de réception.
Coinkite a estimé l'entropie effective à environ 40 bits pour les seeds Mk3 affectées et environ 72 bits pour les seeds Mk4, Mk5 et Q antérieures au correctif. Le conseil excluait explicitement les seeds créées avec au moins 50 lancers de dés impartiaux, indépendants et privés, car la contribution des dés fournissait seule les 128 bits requis et était hachée avec la sortie de l'appareil. Des phrases de passe BIP-39 fortes et uniques ont été reconnues comme une barrière supplémentaire empêchant un attaquant qui ne récupère que les mots de la seed d'accéder aux fonds, mais l'entreprise a tout de même recommandé une migration complète car la seed sous-jacente reste faible.
Les instructions de migration insistaient sur une vérification séquentielle et calme : confirmer la version fixe du micrologiciel, générer le nouveau seed, enregistrer et vérifier la sauvegarde et l'empreinte, envoyer une petite transaction de test, puis déplacer le solde restant tout en conservant l'ancienne sauvegarde jusqu'à confirmation. Les utilisateurs dont le seul appareil était un Mk2 ou Mk3 ont reçu une procédure soigneuse à un seul appareil qui alterne entre les anciens et les nouveaux seeds. Coinkite a également noté que les produits TAPSIGNER, OPENDIME et SATSCARD utilisent des bases de code distinctes et ne sont pas affectés. La réponse a démontré à la fois les avantages d'un modèle de micrologiciel open source permettant un correctif rapide et la difficulté pratique de communiquer l'urgence à une base d'utilisateurs dispersée qui a pu générer des seeds il y a plusieurs années puis laisser les appareils hors ligne.
Estimations d'entropie et pourquoi 40 ou 72 bits ne répondent pas aux objectifs du BIP-39
Une seed BIP-39 standard de 12 mots est conçue pour offrir 128 bits de sécurité. Lorsque la source d'entropie sous-jacente s'effondre à environ 40 bits sur les appareils Mk3 ou 72 bits sur les modèles ultérieurs, l'espace combinatoire devient accessible avec les ressources informatiques modernes. L'analyse de Block a montré que le mécanisme de secours MicroPython Yasmarang, une fois initialisé à partir de valeurs fixes ou contraintes, produit un flux entièrement déterministe. Sur les appareils Mk4 et ultérieurs, la contribution de l'élément sécurisé est réduite à un reseed de 32 bits d'un seul mot d'état ; les sorties ultérieures restent dans une famille d'au plus 2^32 flux pour tout état antérieur et historique d'appel fixe.
Le hachage déterministe de cette sortie ne peut pas élargir la famille. Par conséquent, un attaquant qui obtient ou approxime les paramètres d'initialisation nécessaires peut énumérer des candidats hors ligne, dériver les adresses correspondantes et les faire correspondre avec l'ensemble public des UTXO. Le coût est dominé par la dérivation des adresses plutôt que par une simple tentative aléatoire, mais il reste réalisable à l'échelle observée des vols. Les chiffres préliminaires de Coinkite sont conformes aux évaluations indépendantes selon lesquelles l'entropie résiduelle est insuffisante pour une auto-gestion à long terme de soldes importants.
L'écart n'est pas théorique ; les opérations du 30 juillet et les vagues suivantes ont fourni une confirmation empirique que l'espace réduit était déjà exploité. Même la estimation supérieure de 72 bits pour les modèles ultérieurs laisse une marge bien inférieure au niveau de sécurité attendu par les utilisateurs qui ont choisi des wallets matériels précisément pour éviter les défaillances d'entropie des wallets logiciels. L'épisode fournit donc un point de calibration concret pour la conception future des wallets matériels : tout chemin pouvant basculer silencieusement vers un PRNG logiciel initialisé à partir d'un état de dispositif non cryptographique doit être rejeté au moment de la construction, et non simplement revu a posteriori.
Lancers de dés et phrases de passe comme mesures partielles d'atténuation
Le conseil de Coinkite établit une distinction claire pour les graines intégrant au moins 50 lancers de dés équitables, indépendants et privés entrés via l'interface dédiée de l'appareil. Dans ces cas, l'entropie des dés seule atteignait ou dépassait la cible de 128 bits et était combinée à la sortie faible de l'appareil avant l'affichage des mots de la graine finale. À condition que les lancers n'aient jamais été enregistrés ni observés, la graine résultante est considérée comme hors du champ de la faille du RNG. Moins de 50 lancers, ou toute incertitude concernant le nombre ou la confidentialité des lancers, ramène la graine dans la catégorie à risque.
Une phrase de passe BIP-39 forte et unique crée un wallet indépendant qui ne peut pas être atteint uniquement à partir des mots de semence ; un attaquant doit également récupérer la phrase de passe. Les phrases de passe courtes, communes ou réutilisées ne sont pas considérées comme valides. Même lorsqu'une phrase de passe forte est présente, Coinkite recommande une migration ultérieure, car la semence sous-jacente reste cryptographiquement faible et la phrase de passe elle-même devient un point unique de défaillance en cas d'exposition. Ces mesures de protection illustrent la valeur des défenses en couches, tout en révélant leur insuffisance. Les lancers de dés exigent des procédures physiques rigoureuses que beaucoup d'utilisateurs n'ont jamais suivies.
Les phrases de passe exigent une sauvegarde séparée soigneuse et un rappel exact ; une seule erreur de frappe génère un wallet différent et vide. Aucune de ces mesures ne restaure l'entropie que le firmware n'a pas fournie, et aucune ne protège les fonctionnalités avancées de l'appareil qui continuent de dépendre du même chemin de génération de nombres aléatoires affaibli. Les utilisateurs qui s'appuyaient uniquement sur la génération par défaut de la graine ont donc subi pleinement l'impact de l'espace de recherche réduit, tandis que ceux qui avaient déjà adopté une entropie supplémentaire ou des phrases de passe ont gagné du temps, mais pas une sécurité permanente.
Configurations multisignatures et les limites du risque partagé
Lorsque chaque clé d'un quorum multisignature est générée sur un Coldcard affecté, l'ensemble de la politique devient dépensable par un attaquant qui récupère les graines faibles. Une configuration 2-sur-3 dans laquelle deux des trois graines proviennent d'un firmware vulnérable permet toujours à l'attaquant de remplir le seuil une fois ces deux graines connues. Seules les configurations qui conservent au moins une clé externe forte en dehors de l'ensemble affecté préservent la sécurité. Liana et d'autres wallets basés sur Miniscript introduisent des considérations supplémentaires sur les chemins : un chemin principal pouvant être satisfait uniquement par des clés Coldcard faibles est immédiatement dépensable, tandis qu'un chemin de récupération verrouillé par un timelock reste protégé uniquement tant que le verrou est actif. Dépenser un wallet SegWit révèle le descripteur complet lors de la première transaction, permettant potentiellement la reconstruction de chaque adresse si toutes les clés sont faibles.
Taproot limite la révélation au chemin utilisé, réduisant ainsi le rayon d’action de l’attaque, mais expose toujours les clés faibles impliquées dans ce chemin. La leçon pratique est que la diversité matérielle et les sources d’entropie indépendantes restent essentielles, même au sein de schémas multisignatures. S’appuyer sur plusieurs appareils du même modèle et de la même génération de firmware concentre les risques au lieu de les répartir. Les utilisateurs qui ont combiné des clés Coldcard avec des clés d’autres fabricants ou avec des seeds générées par dés ont conservé une protection partielle ; ceux qui se sont uniformisés sur une seule ligne de produits vulnérables ont découvert que le seuil de quorum n’offrait aucune défense une fois la défaillance d’entropie exploitée. Cet incident renforce donc les recommandations de longue date en faveur de sources de clés hétérogènes, tout en démontrant que cette recommandation n’est pas seulement théorique.
Échecs d'examen open source et rôle de l'IA dans la découverte
Le micrologiciel Coldcard est depuis longtemps publié sous une licence open source, permettant une inspection indépendante. L'erreur d'intégration du RNG a néanmoins survécu à plusieurs cycles de publication et à une analyse externe. Les revues existantes ont vérifié que l'implémentation matérielle du RNG prévue existait dans le binaire, mais n'ont pas confirmé que l'appel de génération du wallet atteignait effectivement cette implémentation plutôt que la solution de repli MicroPython. La protection du préprocesseur utilisait #ifndef au lieu d'une vérification de valeur, permettant à une définition nulle de passer silencieusement. Coinkite a noté que même l'analyse de code récente assistée par l'IA réalisée par l'entreprise elle-même n'a pas révélé le problème, tandis que les attaquants ou les chercheurs ayant identifié pour la première fois cette faille auraient pu bénéficier d'outils similaires. Cet épisode met donc en lumière un écart persistant entre la présence du code source et la vérification du comportement à l'exécution à travers les limites des sous-modules.
La latence de cinq ans illustre également la difficulté de détecter les pannes silencieuses d'entropie. Contrairement aux débordements de tampon ou aux bogues de signature qui provoquent des plantages immédiats ou des signatures invalides, un PRNG faible continue de générer des graines qui semblent plausibles et passent les vérifications de cohérence interne. Seule une énumération hors ligne ultérieure par rapport à la blockchain révèle cette déficience. Les processus d'audit futurs devront inclure des audits explicites de l'entropie de bout en bout, obligeant le système de compilation à rejeter toute voie de secours et à mesurer la qualité statistique de la sortie dans des conditions contrôlées. L'open source reste une condition nécessaire à la confiance, mais le cas Coldcard montre qu'il ne suffit pas sans une vérification ciblée des chemins de code les plus critiques sur le plan de la sécurité.
Praticité de la migration et risque de transferts précipités
Coinkite a répété à plusieurs reprises qu'une migration précipitée peut créer de nouveaux vecteurs de perte dépassant le risque initial. Les utilisateurs ont été invités à vérifier la version du micrologiciel fixe sur l'appareil, à générer la nouvelle graine uniquement après la mise à jour, à enregistrer la sauvegarde et l'empreinte hors ligne, à confirmer une adresse de réception sur l'écran de l'appareil, et à transférer un petit montant de test avant de déplacer la majeure partie des fonds. Les propriétaires d'un seul appareil ont dû effectuer des étapes supplémentaires, en alternant entre l'ancienne et la nouvelle graine tout en conservant les deux sauvegardes intactes jusqu'à la confirmation finale. Toute erreur dans l'ordre des opérations, toute adresse saisie incorrectement ou toute destruction prématurée de l'ancienne sauvegarde pourrait entraîner la perte définitive des pièces.
L'entreprise a également averti contre la restauration d'une graine affectée sur un nouvel appareil ou un wallet logiciel, car la vulnérabilité se déplace avec la phrase elle-même. Le volume de wallets affectés et les prélèvements continus ont créé une pression temporelle en conflit avec la nécessité d'une procédure réfléchie. De nombreux détenteurs à long terme avaient généré des graines il y a plusieurs années, stocké les appareils hors ligne et conservé uniquement des sauvegardes papier. Reconstituer la version exacte du micrologiciel utilisée au moment de la génération n'était pas toujours simple. L'avis a donc équilibré urgence et prudence, en incitant à une action immédiate pour les graines non protégées tout en exigeant des étapes de vérification pour éviter les pertes auto-infligées. La tension entre rapidité et sécurité reste une caractéristique inhérente à toute migration massive de graines et réapparaîtra lors de futurs incidents liés aux wallets matériels.
Contexte industriel : Portefeuilles matériels après l'incident Coldcard
La faille Coldcard intervient après des épisodes antérieurs d'entropie faible dans les environnements logiciels et matériels, notamment la recherche Ill Bloom qui a lié un problème distinct de PRNG de wallet logiciel à plus de 5 millions de dollars de pertes multi-chaînes. Les wallets matériels étaient longtemps présentés comme la solution définitive aux défaillances d'entropie logicielle et aux logiciels malveillants. Les événements de 2026 démontrent que la limite de protection n'est aussi forte que le firmware qui implémente le chemin d'entropie. Les concurrents qui s'appuient sur des éléments sécurisés différents, des architectures de nombres aléatoires différentes ou des processus de revue différents n'ont pas été impliqués, mais le marché dans son ensemble doit désormais affronter la possibilité que des erreurs d'intégration similaires puissent exister ailleurs. La demande pour des outils de mesure indépendants de l'entropie, une vérification formelle des graphes d'appel RNG, et des interfaces standardisées de lancers de dés ou d'entropie externe devrait augmenter.
Les défenseurs de la auto-gestion font face à un défi parallèle. L'incident a déjà suscité un débat public sur la question de savoir si les détenteurs à long terme devraient envisager un stockage diversifié, incluant des produits réglementés, pour une partie de leurs actifs. Dans le même temps, la diffusion rapide d'un firmware fixe et la transparence des divulgations techniques réaffirment les avantages des écosystèmes de matériel ouvert capables de réagir en quelques heures plutôt qu'en plusieurs mois. L'effet net est une calibration plus réaliste du risque, et non un rejet total des wallets matériels. Les utilisateurs qui considèrent l'appareil comme un composant d'un modèle de sécurité en couches incluant de l'entropie externe, des phrases de passe et une diversité multisignatures conservent une protection plus forte que ceux qui traitent tout produit unique comme une protection absolue.
Leçons pour la conception future des wallets matériels
Les systèmes de compilation doivent exiger la présence d'un RNG matériel vérifié aux emplacements exacts d'appel utilisés pour la génération de graines ; une bascule silencieuse vers un PRNG logiciel alimenté par les métadonnées de l'appareil est inacceptable. Les vérifications au préprocesseur doivent tester l'état d'activation des fonctionnalités d'entropie, et non simplement leur définition. Les contributions du secure-element doivent conserver toute l'entropie, sans être tronquées à 32 bits avant de recharger une machine d'état faible. Les tests end-to-end mesurant la qualité statistique des graines générées dans des conditions de démarrage réalistes doivent devenir des critères standard de sortie.
La documentation doit clarifier que la version du micrologiciel au moment de la génération du seed, et non la version actuellement installée, détermine l'exposition. Enfin, les interfaces utilisateur doivent afficher l'état de la source d'entropie et encourager ou exiger une entropie supplémentaire via des dés ou une entropie externe pour les wallets à haute valeur. Ces modifications de conception sont progressives, mais auraient empêché la régression de Coldcard et réduit la probabilité de défaillances similaires dans d'autres produits.
Étapes pratiques pour les propriétaires actuels de Coldcard
Les propriétaires ayant généré des seeds sur les firmwares Mk2 ou Mk3 versions 4.0.1 à 4.1.9, ou sur les firmwares Mk4, Mk5 ou Q avant les versions corrigées du 31 juillet, doivent considérer ces seeds comme compromises, à moins qu'ils ne puissent confirmer au moins 50 lancers de dés privés ou une phrase de passe unique et robuste. Installez le firmware corrigé approprié depuis les pages de téléchargement officielles de Coinkite, générez une nouvelle seed sur l'appareil mis à jour, vérifiez la sauvegarde et l'empreinte hors ligne, confirmez une adresse de réception sur l'écran de l'appareil, effectuez une petite transaction de test, puis seulement après, transférez le solde restant.
Gardez l’ancienne sauvegarde jusqu’à ce que le nouveau wallet affiche le montant complet confirmé. Les utilisateurs qui n’ont jamais généré de seed sur un appareil affecté, mais qui ont importé une seed affectée dans un autre wallet, doivent néanmoins effectuer la migration, car la faiblesse réside dans la phrase. Les participants multisignature doivent évaluer chaque clé indépendamment en fonction de son appareil et de sa firmware de génération. L’avis officiel et le document technique de fond restent les références autorisées pour les instructions spécifiques au modèle.
Implications plus larges pour les pratiques de auto-gestion du bitcoin
L'épisode Coldcard souligne que la garde autonome est un processus continu, et non un simple achat de matériel. La qualité de l'entropie, l'origine du firmware, la vérification des sauvegardes et la diversité des clés doivent être réévaluées périodiquement. L'analyse sur chaîne peut détecter rapidement des exploitations à grande échelle, mais les détenteurs individuels restent responsables de surveiller les canaux officiels et d'agir en fonction des avis. Le marché des audits de sécurité indépendants pour les firmwares de wallets matériels est susceptible de s'étendre, tout comme la demande pour des outils permettant aux utilisateurs de mesurer l'entropie effective de leurs seeds sans les exposer.
En même temps, cet incident ne remet pas en cause la valeur fondamentale du stockage hors ligne des clés ; il démontre simplement que la limite hors ligne doit être complétée par une force cryptographique vérifiée au moment de la génération de la clé. Les détenteurs qui combinent du matériel patché, une entropie supplémentaire, des phrases de passe et des arrangements multisignatures continuent de contrôler leurs propres clés avec un niveau de sécurité supérieur à ceux qui s'appuient sur une seule couche.
|
KuCoin célèbre son 9e anniversaire avec une campagne spéciale sur la plateforme, remplie de récompenses exclusives, d'activités de trading et d'offres à durée limitée. Ne manquez pas l'occasion de participer et de profiter des avantages alors que la plateforme célèbre neuf ans de croissance et d'innovation. Visitez la page officielle de la campagne dès maintenant :
|
FAQ
Quelles versions du micrologiciel de Coldcard sont affectées par la faille de génération de la graine ?
Les appareils Mk2 et Mk3 exécutant les versions 4.0.1 à 4.1.9 incluses ont généré des seeds avec environ 40 bits d'entropie effective. Les appareils Mk4 et Mk5 avant la version standard 5.6.0 ou la version Edge 6.6.0X, ainsi que les appareils Q avant la version standard 1.5.0Q ou la version Edge 6.6.0QX, ont produit des seeds avec environ 72 bits d'entropie. L'exposition est déterminée par la version du firmware présente au moment de la génération du seed, et non par la version actuellement installée. Les versions corrigées réparent la génération de nouveaux seeds, mais ne peuvent pas réparer les seeds faibles existants. Les pages de téléchargement officielles listent les versions corrigées pour chaque modèle et chaque canal de mise à jour. Les utilisateurs ayant généré des seeds en dehors de ces plages, ou ceux ayant utilisé au moins 50 lancers de dés privés, ne font pas partie de la catégorie à risque principal.
La mise à jour du firmware sur un Coldcard existant protège-t-elle une seed déjà générée ?
Non. La vulnérabilité réside dans l'entropie utilisée pour créer les mots de la graine eux-mêmes. L'installation d'un firmware corrigé ne modifie que le chemin de génération des futures graines. Restaurer une phrase de récupération affectée sur un firmware corrigé ou sur tout autre wallet ne fait que transférer le même secret faible. La seule solution fiable consiste à générer une toute nouvelle graine sur un firmware corrigé et à migrer les fonds après vérification complète de la nouvelle sauvegarde et de l'adresse de réception. L'avis de Coinkite est explicite sur ce point et fournit des procédures de migration étape par étape pour les scénarios à plusieurs appareils et à un seul appareil.
Les graines créées avec des lancers de dés sont-elles toujours sûres ?
Les graines qui intègrent au moins 50 lancers de dés justes, indépendants et privés saisis via l'interface officielle du dispositif obtiennent une entropie suffisante uniquement à partir des lancers de dés. Le dispositif hache ces lancers avec sa propre sortie (faible), de sorte que la graine finale atteint ou dépasse la cible de 128 bits à condition que les lancers n'aient jamais été observés ou enregistrés. Moins de 50 lancers, ou toute incertitude concernant le nombre ou la confidentialité des lancers, ramène la graine dans la catégorie à risque. Les lancers de dés ne protègent pas les fonctionnalités avancées du dispositif qui continuent de dépendre du même chemin de génération aléatoire, mais ils protègent bien les mots de graine eux-mêmes contre cette faille spécifique.
Comment un mot de passe BIP-39 modifie-t-il le profil de risque ?
Une phrase de passe BIP-39 forte et unique crée un wallet distinct qui ne peut pas être dérivé uniquement à partir des mots de la graine. Un attaquant qui récupère uniquement la graine faible ne peut pas accéder aux fonds protégés par la phrase de passe sans découvrir également cette phrase de passe. Les phrases de passe courtes, communes, basées sur un motif ou réutilisées n'offrent pas une protection significative. Même avec une phrase de passe forte, Coinkite recommande une migration ultérieure, car la graine sous-jacente reste cryptographiquement déficiente et la phrase de passe elle-même devient un secret critique qui doit être sauvegardé séparément et jamais saisi sur des appareils non fiables. La phrase de passe est indépendante du code PIN de l'appareil.
Que doivent faire les utilisateurs de signatures multiples si certaines clés proviennent de Coldcards affectés ?
Évaluez chaque clé en fonction de l'appareil et du micrologiciel qui l'ont générée. Si le nombre de clés affectées atteint ou dépasse le seuil de dépense de n'importe quel chemin, ce chemin est immédiatement en danger. Un arrangement 2-sur-3 comprenant deux clés Coldcard faibles peut être dépensé par un attaquant qui récupère ces deux graines. Les chemins de récupération protégés par des verrous temporels actifs restent plus sûrs jusqu'à l'expiration du verrou. Les utilisateurs doivent générer de nouvelles clés sur un micrologiciel fixe ou sur des appareils non affectés, créer une nouvelle politique multisignature et migrer les fonds après avoir vérifié le nouveau descripteur et les adresses. L'utilisation de sources de clés hétérogènes réduit la probabilité qu'une seule faille de micrologiciel compromette l'ensemble du quorum.
L’attaque est-elle toujours en cours, et comment les détenteurs peuvent-ils surveiller d’éventuelles nouvelles saisies ?
Galaxy Research a observé plusieurs vagues après le balayage initial du 30 juillet et a signalé que l'activité a continué pendant la migration des utilisateurs. Les modèles on-chain caractérisés par des taux de frais spécifiques et un comportement de change peuvent être suivis via des explorateurs et des services d'analyse publics, mais les détenteurs individuels ne peuvent pas compter uniquement sur une détection a posteriori. La protection la plus efficace consiste à migrer rapidement tout seed non protégé. Les canaux officiels de Coinkite et les comptes de recherche réputés restent les sources principales pour obtenir des mises à jour sur d'autres vagues ou des clusters d'adresses récemment identifiés.
Clause de non-responsabilité : Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil en investissement. Les investissements dans les cryptomonnaies comportent des risques. Veuillez effectuer vos propres recherches (DYOR).
Avertissement : Pour votre confort, cette page a été traduite à l'aide de la technologie IA. Pour obtenir les informations à la source, consultez la version anglaise originale.