Après avoir démonté un Ledger authentique, TBC discute des véritables limites de l'auto-garde

Un portefeuille matériel acheté par des canaux officiels, avec un emballage intact et un autocollant de sécurité non altéré, démarre normalement lors de l'autotest. Cependant, un composant caché a été implanté à l'intérieur pour capturer la phrase de récupération.

Le 15 octobre 2026, Ledger a répondu à cet incident : des attaquants ont acheté des appareils authentiques, les ont démontés pour y implanter du matériel, puis les ont remis sur le marché via des canaux de distribution en Asie du Sud-Est. Ledger a souligné que la puce, le système d'exploitation et les serveurs n'avaient pas été compromis, qualifiant cela d'attaque ciblée sur des canaux de distribution, et non d'une intrusion systémique dans la chaîne d'approvisionnement.

Le 14 octobre, Tom's Hardware a cité une estimation de Bloomberg, évaluant les pertes à environ 93 millions de dollars. Il est important de préciser que ce chiffre provient de médias tiers et n'est pas confirmé par une déclaration officielle de Ledger.

À qui appartient ce chiffre n'est pas important. Ce qui est important, c'est ce qu'il révèle.

I. L'auto-garde n'élimine pas les risques, elle les déplace simplement

Au cours de la dernière décennie, l'industrie a raconté une histoire très claire : mettre des cryptomonnaies sur un échange, c'est confier son destin à une entreprise ; garder ses clés privées en main, c'est être libre.

Cette histoire est en partie vraie.

Le risque de la garde par un échange est concentré et visible : détournement, ruée bancaire, faillite, gel réglementaire. Après FTX, le slogan « Not your keys, not your coins » a été accepté par un plus grand nombre d'utilisateurs, et l'industrie a commencé à discuter plus sérieusement des outils d'auto-garde et de la gestion des phrases mnémoniques.

Mais l'auto-garde n'est pas la fin du risque, c'est un transfert de risque.

Elle remplace la question « la plateforme peut-elle être malveillante ? » par une autre série de questions : d'où vient votre appareil ? Le firmware a-t-il été modifié ? Dans quel environnement la phrase mnémonique a-t-elle été générée ? Le contenu affiché à l'écran lors de la signature correspond-il à la transaction réellement signée ? Qui a le droit d'initier ce transfert ?

Dans cette série de questions, toute défaillance à un seul maillon aboutit à un résultat identique à celui d'une fuite d'un échange. L'estimation de 93 millions de dollars par un tiers achète essentiellement cette leçon.

Ce qui est plus problématique, c'est que la forme de ces attaques a changé. Elles ne compromettent pas la cryptographie, ne compromettent pas la puce, ne compromettent pas l'algorithme de consensus. Elles attaquent la jonction entre le monde physique et la chaîne de confiance : canaux de distribution, étapes de démontage, reconditionnement, transit logistique.

La cryptographie peut prouver qu'une signature est valide, mais elle ne peut pas prouver si la main qui a signé a été contrainte, ni prouver si cet appareil a secrètement envoyé la phrase mnémonique dans un endroit que vous ne pouvez pas voir.

Le maillon le plus faible du modèle de sécurité n'est jamais l'algorithme, mais les personnes, les appareils et les processus.

II. Décomposer une clé privée en plusieurs conditions vérifiables

La véritable leçon de l'incident Ledger n'est pas « ne pas utiliser de portefeuille matériel », mais plutôt : se fier uniquement à l'hypothèse « la clé privée est entre mes mains » est en soi un point de défaillance unique.

La bonne direction est de faire en sorte que le transfert de fonds nécessite de satisfaire simultanément plusieurs conditions, et que ces conditions soient réparties dans différents domaines de confiance.

La position de TBC sur cette affaire doit être exprimée avec retenue. Elle ne prétend pas pouvoir éliminer les attaques terminales, aucune chaîne ne peut le faire. Sa valeur réside dans le fait que les contrats natifs UTXO et les outils de multi-signature permettent aux projets de décomposer le risque de clé privée unique en plusieurs conditions vérifiables.

Concrètement, TBC utilise le modèle SHA256 PoW et UTXO, le code des nœuds TBCNODE est public et vérifiable. La caractéristique naturelle du modèle UTXO est que chaque sortie non dépensée peut être contrainte par des conditions de script indépendantes, plutôt que d'être attachée à un solde de compte global. Cela signifie que les règles de dépense peuvent être écrites sur la chaîne, et non dans un service de backend.

Le SDK tbc-contract fournit des requêtes sur la chaîne, l'obtention d'UTXO, la construction de transactions, la signature et la diffusion, et inclut MultiSig, NFT, FT et des flux de Pool. L'exemple officiel de MultiSig prend en charge la définition d'un seuil de signature de 1 à 6 parmi 3 à 10 clés publiques, le document fournit un exemple de 2-of-3.

Il est important de préciser : la multi-signature est un outil de contrôle des risques configurable, ce n'est pas une sécurité automatique, et encore moins une sécurité absolue.

Si quelqu'un pense qu'avec une configuration 2-of-3 tout est réglé, c'est la même erreur que de croire que « l'achat d'un portefeuille matériel garantit la sécurité ». La multi-signature change la structure des coûts d'attaque, mais pas la possibilité d'attaque.

La documentation TBC AMM explique une autre chose : le SDK construit, évalue et signe localement, la diffusion est explicitement initiée par l'application ; l'état des pools et le contrôle des actifs dépendent des règles UTXO et des scripts. Cela constitue la base des transactions non gardées et de la séparation des autorisations.

Il faut également clarifier les limites : cela ne signifie pas que l'AMM n'a pas de risques de contrat, de risques de prix ou de risques de frontend. La signature locale résout le problème « la clé privée ne quitte pas l'appareil », mais ne résout pas « la transaction que vous signez est-elle vraiment celle que vous souhaitez signer ? »

III. Pourquoi la multi-signature est souvent une simple dispersion formelle

C'est la partie la plus facile à ignorer, mais aussi la plus mortelle.

Si plusieurs clés de signature proviennent de la même phrase mnémonique, sont stockées sur le même appareil, ou sont contrôlées par la même personne, la multi-signature n'est qu'une dispersion formelle.

Un attaquant qui obtient une phrase mnémonique obtient en fait tous les droits de signature. Si un appareil est compromis, cela signifie que tous les seuils sont simultanément violés. Cette configuration semble être 3-of-5 sur la chaîne, mais en réalité, c'est 1-of-1.

Ainsi, la véritable question n'est pas « combien de signatures ai-je configurées ? », mais plutôt des questions plus difficiles :

• L'environnement de génération de ces clés est-il indépendant les uns des autres ?
• Sont-elles stockées sur des appareils physiquement isolés ?
• La personne qui initie la transaction est-elle la même que celle qui l'approuve ?
• Les transferts à haut risque ont-ils des délais et des vérifications manuelles ?
• Les processus de rotation et de récupération des clés ont-ils été pratiqués ?

Le modèle UTXO de TBC ne réparera pas automatiquement les clés privées volées. Cela doit être reconnu. Ce que les règles sur la chaîne peuvent faire, c'est empêcher le transfert non autorisé de fonds lorsque certaines conditions sont violées ; elles ne peuvent pas restaurer des actifs à partir de rien si la clé privée a déjà été compromise.

Les pratiques d'ingénierie associées ne doivent pas être négligées : appareils de signature indépendants, rotation des clés, limites de montant par transaction et par jour, verrouillage temporel, vérification multipartite des transactions à haut risque, et plans de récupération exécutables.

Il faut également admettre que TBC doit continuer à s'améliorer. La facilité d'utilisation des interactions multi-signatures, la profondeur de compatibilité avec les portefeuilles matériels mainstream, les modèles d'autorisation prêts à l'emploi, les tests de référence par des tiers indépendants, ainsi que l'audit continu des composants SDK, portefeuille et AMM, sont tous des travaux en cours.

TBCNODE a déjà des enregistrements d'audit de sécurité versionnés par CertiK et SlowMist. Mais l'audit ne peut prouver que des versions spécifiques, dans des portées spécifiques ont été vérifiées, il ne couvre pas les terminaux matériels, ne couvre pas les habitudes de gestion des clés des utilisateurs, ne couvre pas le code soumis à l'avenir, ni toute la logique de couche d'application. Considérer un rapport d'audit comme un certificat de sécurité est une autre forme de paresse.

IV. La véritable auto-garde est une règle sur la chaîne

Revenons à cet appareil démonté.

Il nous rappelle que « la clé privée est entre mes mains » est une condition nécessaire, mais pas suffisante. La provenance de l'appareil, la distribution des droits de signature, et les règles de dépense sur la chaîne doivent toutes être simultanément valables pour que la structure de sécurité soit solide.

Les changements à venir dans l'industrie seront probablement que les fabricants de portefeuilles matériels renforceront le contrôle des canaux et la conception anti-démontage, que les services d'assurance et de garde redéfiniront le risque de la chaîne d'approvisionnement physique, et que les projets commenceront à considérer la « conception des autorisations » comme un sujet d'ingénierie aussi important que « l'audit de code ».

La position de TBC dans ce tableau n'est pas « une solution aux attaques matérielles », mais plutôt de fournir des outils pour écrire des règles d'autorisation sur la chaîne : les contrats natifs UTXO contraignent les conditions de dépense, la multi-signature décompose les droits de signature dans différents domaines de confiance, et les composants de transaction non gardée garantissent que la clé privée ne quitte pas le local.

La véritable auto-garde n'est pas seulement une clé privée, mais c'est aussi la capacité d'empêcher le transfert non autorisé de fonds lorsque n'importe quel point unique échoue.