Les incidents de sécurité les plus instructifs sont parfois ceux qui font tomber une idée reçue.
Pour les hardware wallets, cette idée pourrait se résumer ainsi : « si le firmware est authentique et que l’élément sécurisé fonctionne correctement, alors l’appareil est sûr ».
L’attaque par implant matériel visant des appareils Ledger, révélée en octobre 2026, montre pourquoi ce raisonnement ne suffit pas.
Selon Ledger, des criminels ont acheté de véritables appareils, les ont ouverts, y ont installé des composants clandestins conçus pour capter des informations liées à la phrase de récupération lors de l’initialisation, puis les ont réintroduits dans des circuits de distribution par l’intermédiaire de revendeurs en Asie du Sud-Est.
Ledger affirme que ses puces, son système d’exploitation et ses serveurs n’ont pas été compromis. La modification aurait eu lieu après que les produits ont quitté son contrôle direct.
Un appareil authentique peut devenir un appareil non fiable
Ce cas se distingue d’une simple contrefaçon.
Les appareils à l’origine étaient authentiques.
Or de nombreux contrôles utilisateur sont conçus pour vérifier « est-ce un véritable Ledger ? », et non « ce Ledger authentique a-t-il conservé son intégrité physique depuis sa sortie d’usine ? ».
Ce sont deux questions différentes.
Un appareil peut être authentique au moment de sa fabrication, puis compromis par :
- une ouverture non autorisée ;
- une modification du chemin d’affichage ;
- le remplacement d’un composant ;
- l’ajout d’une puce ou d’un module radio ;
- une modification de l’emballage ;
- un processus de retour chez un revendeur insuffisamment contrôlé.
La sécurité dépend donc de la provenance et de la continuité de contrôle, autant que de la conception du produit.
Ce que Ledger a confirmé
Dans sa communication du 15 octobre, Ledger a décrit une attaque localisée sur les circuits de distribution.
Selon l’entreprise, les auteurs ont acheté des appareils authentiques, ajouté des composants cachés capables de récupérer des informations de phrase de récupération pendant la configuration, puis remis les appareils modifiés en circulation.
Ledger a suspendu les ventes via les canaux concernés, annoncé l’inspection des stocks et renforcé ses exigences envers les distributeurs et revendeurs agréés, notamment concernant les retours et la conservation des produits.
L’entreprise a également indiqué ne pas avoir identifié de compromission généralisée de sa production ni de sa distribution directe.
Certains médias ont relayé des estimations de pertes se chiffrant en dizaines de millions de dollars. Ledger n’a toutefois pas publié de bilan définitif de ces pertes dans sa communication du 15 octobre. Ces montants doivent donc être traités comme des estimations externes, non comme une comptabilité officielle de l’incident.
Pourquoi le secure element ne suffisait pas
Un élément sécurisé protège les clés contre de nombreuses classes d’attaques.
Mais la sécurité d’un système ne se limite pas à la résistance de sa puce cryptographique.
Si un autre composant peut observer des informations sensibles avant ou pendant la création du wallet, l’élément sécurisé peut rester intact alors que le secret est déjà exposé.
Le principe est général : sécuriser le calcul ne suffit pas lorsque le chemin d’entrée ou de sortie des données ne l’est pas.
On retrouve la même faiblesse dans d’autres environnements :
- un serveur sécurisé administré depuis un ordinateur compromis ;
- un HSM associé à une interface d’approbation malveillante ;
- un signataire hors ligne relié à un écran manipulé ;
- un multisig dont le coordinateur présente une transaction différente de celle réellement signée.
L’intégrité de l’affichage et la fiabilité du chemin d’entrée sont des frontières de sécurité à part entière.
La politique d’achat fait partie du modèle de menace
Pour un particulier, acheter directement auprès du fabricant constitue souvent une mesure raisonnable de réduction du risque.
Pour une organisation, la politique d’acquisition doit être plus explicite.
Une procédure mature peut prévoir :
- des circuits d’achat autorisés ;
- une traçabilité de la chaîne de possession ;
- une inspection à la réception ;
- un stockage contrôlé avant attribution ;
- l’interdiction de réutiliser des appareils retournés ;
- des cérémonies d’initialisation documentées ;
- des vérifications indépendantes du firmware et de l’état du matériel ;
- une marche à suivre en cas de doute sur une altération.
L’objectif n’est pas d’accorder une confiance magique à un emballage intact : un sceau peut être imité ou remplacé.
Il s’agit plutôt de limiter les intermédiaires non contrôlés et les transitions non documentées entre la fabrication et l’initialisation.
Que faire lorsqu’un appareil paraît suspect ?
La réponse dépend notamment du fait que l’appareil a déjà été initialisé ou non.
Un appareil suspect encore vierge ne doit pas servir à générer une seed.
Si une phrase de récupération a été créée ou affichée sur un matériel potentiellement modifié, il est prudent de considérer que ce secret pourrait avoir été exposé.
La migration doit alors utiliser une nouvelle seed générée dans un environnement de confiance, avec une destination contrôlée indépendamment avant le transfert des fonds.
Il ne faut jamais « tester » une seed suspecte en la saisissant sur un site web ou dans une application inconnue.
Diversifier les fabricants ne résout pas le risque d’approvisionnement
Un multisig utilisant plusieurs fabricants peut réduire la dépendance à un même firmware ou à une seule chaîne de production.
Mais si tous les appareils proviennent d’un canal d’achat non maîtrisé, un risque corrélé demeure.
La diversification doit porter sur les domaines de défaillance qui comptent vraiment :
- le fabricant ;
- le firmware ;
- l’implémentation de l’élément sécurisé ;
- le canal d’acquisition ;
- le lieu de stockage ;
- les personnes chargées de l’administration.
Sinon, l’architecture peut paraître diversifiée sur un schéma tout en conservant un point de compromission commun dans la réalité.
La self-custody est une procédure, pas un produit
Cet incident ne démontre pas que tous les hardware wallets sont dangereux.
Il rappelle qu’on ne peut pas transférer toute sa responsabilité de sécurité à un appareil, aussi spécialisé soit-il.
Un dispositif résilient repose sur la qualité de la génération des clés, la provenance des équipements, les sauvegardes, la vérification des transactions, les mises à jour, les procédures de migration et la gouvernance.
C’est l’approche défendue par GLOV Secure. GLOV ne conserve ni les fonds ni les secrets de ses clients : nous intervenons sur l’architecture et les procédures destinées à les protéger.
Pour une organisation ou un particulier fortement exposé aux actifs numériques, un audit de sécurité ou une revue d’architecture de custody peut intégrer les achats et les frontières de confiance physique, au même titre que les wallets et leurs sauvegardes.