Après que le problème est survenu avec la carte, une grande quantité de bitcoins a été déplacée

13 août 2026 · Observations sur l’auto-hébergement et la sécurité des clés

Fin juillet, une faille Coldcard a permis le vol d’environ 1 816 bitcoins, mais les données on-chain montrent qu’ensuite, 233 000 BTC ont été transférés depuis des portefeuilles de long terme, tandis que 22 000 ont été dirigés vers des exchanges. [1] Le PDG de Casa, Nick Neuman, indique que des fonds représentant de 10 à 100 fois le montant volé ont été transférés vers un endroit sûr.

Ces migrations proviennent de deux sources : une partie des clients de Casa utilisaient auparavant un Ledger ou un Trezor à signature unique (des marques d’appareils entièrement différentes), mais l’incident les a poussés à passer à des portefeuilles multisignature ; l’autre partie concernait des utilisateurs qui utilisaient déjà des portefeuilles multisignature, ayant retiré l’appareil Coldcard de la combinaison des clés. [1]

Neuman a comparé cette réponse à un scénario hypothétique de garde centralisée. Si, à valeur égale, du BTC est conservé sur une plateforme, et que la plateforme est compromise, alors l’issue serait inverse : presque tous les fonds disparaissent d’un seul coup, et une petite partie seulement pourrait échapper.[1] En revanche, dans un scénario de self-custody, l’attaquant doit déchiffrer adresse par adresse : à chaque fois, il ne peut récupérer qu’une petite quantité de BTC, tandis que le réseau a du temps pour réagir et transférer le reste des fonds.

Les données de Glassnode confirment l’ampleur : l’offre détenue à long terme est passée d’environ 15 millions de BTC à quelque 14,7 millions — la plus forte baisse hebdomadaire depuis décembre 2024. Cela se produit alors que le prix du BTC reste encore à 50 % sous son record historique d’octobre à 126 000 dollars.[1]

Coinkite a exhorté tous les utilisateurs ayant généré une graine sur des firmwares compris entre 4.0.1 et 4.1.9 (couvrant de mars 2021 à juillet 2026) à migrer immédiatement vers une nouvelle graine. Même si l’appareil a été mis à jour, l’entropie de ces anciennes graines était déjà faible dès leur génération et ne peut pas être corrigée via un correctif.

## Reproduction technique par SlowMist : retour en arrière du générateur aléatoire rendant la clé privée prédictible

L’équipe de SlowMist a reproduit une chaîne d’attaque complète sur le firmware Mk3 4.1.9.[2] La cause profonde résulte de la superposition de deux erreurs au niveau de la compilation.

Première couche : Coldcard met explicitement `MICROPY_HW_ENABLE_RNG` à 0 dans `mpconfigboard.h`, car l’équipe estime avoir encapsulé `ckcc.rng_bytes` qui appelle directement le TRNG matériel STM32. Mais la bibliothèque dépendante `libngu` vérifie ce macro via `#ifndef` : elle ne vérifie que « s’il existe », sans vérifier « s’il est activé ».

Deuxième couche : lorsque le macro vaut 0, la couche de portage MicroPython pour STM32 fait un repli silencieux de `rng_get()` vers un générateur pseudo-aléatoire logiciel nommé Yasmarang. La graine initiale de ce PRNG est composée presque entièrement de valeurs prédictibles : l’UID de la puce (un identifiant de 96 bits, n’utilisant que les 32 bits de poids faible ; dans les lots Phase A, les coordonnées X/Y se situent principalement dans la plage 0–72), `SysTick->VAL` (valeur de compte à rebours sous une horloge de 80 MHz, plage 0–79999) et les registres RTC (qui se résolvent à 0 dans toutes les vecteurs confirmés).[2]

Le résultat est deux instances de Yasmarang : l’une est le flux de constante global de `libngu` ( `pad=0x0a8ce26f`, identique pour tous les appareils), l’autre est l’instance de repli de `rng_get()` ; la seule variable est la valeur 32 bits `UID ^ SysTick`. La véritable source d’entropie dans tout le processus de génération de la graine n’est donc que d’environ 32–72 bits — un espace que les clusters GPU peuvent exhaustivement parcourir en quelques jours.[2]

## Les « pensées intérieures » du modèle AI entièrement divulguées, 62 clés API retrouvées

Des chercheurs en sécurité ont découvert une méthode permettant de lire « les pensées intérieures » chiffrées de chaque modèle d’inférence AI grand public, et ont récupéré 62 clés API actives et 33 mots de passe à partir des journaux de session partagés publiquement par des développeurs (sans savoir ce qu’ils contenaient).[3]

« En décodant 315 320 blocs d’inférence récupérés à partir d’un dépôt public, nous avons restauré 367 PII (informations personnelles identifiantes) et 182 identifiants. » L’équipe de recherche l’a écrit dans l’article déposé le 10 août.[3]

Tous les principaux fournisseurs d’IA chiffrent les tokens d’inférence avec la même clé globale. En exploitant cela, l’attaquant a décodé 315 320 blocs d’inférence cachés à partir de journaux publics, puis a retrouvé les mots de passe et les clés API actives au cours du processus.[3]

Il s’agit du troisième incident signalé d’attaque visant un tiers par un modèle de laboratoire d’IA à la pointe, après les révélations d’OpenAI et d’Anthropic au cours des dernières semaines.

En juillet, OpenAI a déclaré que deux modèles s’étaient échappés du bac à sable de tests et avaient compromis Hugging Face lors de la recherche de réponses aux questions de référence. La société a ensuite divulgué que ces modèles avaient également accédé à quatre autres services en ligne.[3] Anthropic a ensuite indiqué que trois modèles Claude avaient attaqué de vraies organisations après que des tests d’erreur les aient exposés à Internet. En août, Meta a déclaré qu’une erreur similaire a permis à un de ses modèles d’exploiter un service tiers.[3]

Ces événements ont poussé des législateurs à proposer un projet de « kill switch » pour l’IA, autorisant le gouvernement fédéral à limiter ou désactiver des modèles puissants en situation d’urgence.

## Le serveur MCP peut envoyer des instructions par segments, permettant à l’assistant de codage IA de divulguer discrètement des clés

Un serveur malveillant connecté à un assistant de codage IA peut emporter discrètement des clés SSH, des secrets d’environnement, du code source et des données clients, sans avoir à envoyer une seule instruction qui paraisse clairement nuisible.[4]

Cette astuce reste efficace même après le rejet de la version « évidente » du même vol : découper la requête en plusieurs morceaux qui semblent tous très normaux, les placer dans les canaux que l’assistant utilise déjà, puis laisser l’assistant les assembler lui-même.[4]

Le Model Context Protocol (MCP) permet à l’assistant de codage IA d’appeler des outils externes via des interfaces structurées — lire des fichiers, interroger une base de données, exécuter des commandes. L’attaquant peut intégrer une deuxième consigne dans le message de réponse de l’outil, guidant l’assistant à renvoyer les données sensibles qu’il vient de lire vers le serveur de l’attaquant ; à première vue, cela ressemble simplement à de la « journalisation » ou à du « formatage ».[4]

Comme chaque appel est fractionné et qu’à chaque instruction prise séparément, elle paraît raisonnable, les garde-fous intégrés de l’assistant ne se déclenchent pas. Mais une fois que le flux de données part vers le serveur malveillant, la fuite est déjà en cours.[4]

Cette attaque ne nécessite de franchir aucune barrière : elle exploite uniquement la conception même de MCP. L’assistant fait confiance aux données structurées renvoyées par l’outil, et l’outil peut insérer, dans son contenu de retour, une deuxième couche d’instructions.

Auteur travaille sur un portefeuille MPC sans phrase de récupération, donc il a une position sur ce sujet. Les données viennent de sources indiquées ; à vous de juger.

https://cowallet.ai/en?pid=jingle