Ledger : son kit de signature signale chaque signature Ethereum et Solana, sauf si les portefeuilles le coupent

Le kit de signature que Ledger fournit aux développeurs de portefeuilles envoie un rapport à un serveur de Ledger chaque fois que quelqu’un signe une transaction Ethereum ou Solana avec un appareil Ledger, via un portefeuille qui garde les réglages par défaut du kit. Kaloyan Kosev, développeur chez l’éditeur de portefeuilles Ambire, l’a signalé sur X le 10 novembre 2026. Le code publié sur le GitHub de Ledger montre ce qui part : le réseau, l’adresse vers laquelle la transaction est envoyée, le modèle de l’appareil et son firmware, la version de l’application Ledger installée sur l’appareil et le fait que l’utilisateur ait signé à l’aveugle ou non. L’équipe de sécurité de Ledger, Ledger Donjon, a répondu tard dans la soirée que cela « fait partie du fonctionnement de Clear Signing » et que Ledger ne conserve aucune de ces données, a rapporté Unchained.

blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il s’agit d’une question de vie privée posée à Ledger, pas d’un vol. Aucune source, y compris parmi les détracteurs de Ledger, ne dit que ces rapports permettent de déplacer des fonds ou d’exposer une clé privée : ils portent des métadonnées sur chaque signature, pas des secrets. Le débat porte sur qui décide que les utilisateurs d’un portefeuille sont comptés, et sur le fait que ce comptage soit activé tant que personne ne le coupe.

L’envoi des rapports se trouve dans @ledgerhq/context-module, un paquet du Device Management Kit open source de Ledger que des portefeuilles tiers intègrent à leurs applications. Il ne se trouve pas dans le firmware de l’appareil. Ledger Donjon et Yu Xian, de la société de sécurité SlowMist, l’ont tous deux affirmé sur X après que le développeur Lefteris Karapetsas a demandé si les appareils équipés du dernier firmware « téléphonaient à la maison », selon Unchained.

Ce que le kit de signature de Ledger envoie, champ par champ

Coindaro a lu le code du paquet tel qu’il se présentait sur la branche develop de Ledger à 05 h 50 UTC le 12 novembre. Pour une transaction Ethereum, chaque rapport contient l’identifiant de la chaîne, l’adresse to de la transaction (le destinataire, ou le contrat appelé), le code de quatre octets de la fonction du contrat lorsqu’il y en a un, la méthode de signature, le format d’affichage utilisé à l’écran (basique ou clear signing ERC-7730), un compteur d’erreurs de contexte partielles, et un oui ou non sur la signature à l’aveugle, avec un motif. Pour les données typées signées, l’adresse est celle du contrat nommé dans le message.

Chaque rapport comporte aussi le modèle de l’appareil, la version de l’application Ethereum ou Solana installée sur le Ledger, la version du firmware et une étiquette source, qui vaut « third-party » par défaut. Le format prévoit des champs facultatifs pour la plateforme du portefeuille, sa propre version et le système d’exploitation du téléphone ou de l’ordinateur, mais le code Ethereum et Solana par défaut de Ledger les laisse vides ; un portefeuille qui écrit son propre émetteur de rapports peut les remplir. Chaque rapport reçoit un identifiant composé de six caractères aléatoires et l’heure de la signature à la milliseconde.

Les rapports Solana listent les programmes appelés par la transaction et ceux que Ledger n’a pas su reconnaître. L’« adresse cible » y est le premier programme autre que le System Program de Solana ; un simple transfert de SOL ne signale donc aucune cible. Le format de rapport prévoit une place pour la signature de la transaction Solana, qui désignerait la transaction exacte sur la chaîne, mais le code Solana par défaut ne la remplit pas.

Ce qui manque compte aussi. L’adresse de l’utilisateur lui-même ne figure dans aucun des deux formats, comme Ambire l’avait relevé dans sa pull request du 24 septembre. La charge utile ne comporte pas non plus de champ d’adresse IP, même si le serveur de Ledger, comme n’importe quel serveur, voit l’adresse internet d’où provient chaque requête. Sur Ethereum, un portefeuille en version 2.7.0 ou ultérieure envoie deux rapports par signature : l’un par l’émetteur d’origine, l’autre par le « sign reporter » plus récent, posté sur /v2/blind-signing-events.

D’un serveur de test de Ledger en avril à Solana en octobre

La fonction est arrivée par étapes, toutes listées dans le journal des modifications du paquet. La version 1.16.0, publiée sur npm le 14 avril 2026, a ajouté un « blind signing reporter » et l’a branché sur le module. À ce stade, l’adresse par défaut était un serveur de test de Ledger. La version 2.1.0, le 26 mai, a fait passer le réglage par défaut au point d’accès de production https://blind-signing.api.ledger.com. Protos, qui a rapporté l’affaire le 11 novembre, date le premier commit de l’émetteur du 26 mars.

Un second émetteur, multichaîne, est apparu dans la 2.5.0 fin août, puis a été désactivé avant la sortie de cette version. La pull request n° 1966, ouverte et fusionnée le 8 octobre (fusion à 13 h 54 UTC), l’a réactivé pour Ethereum et Solana. Sa description indique que les événements de signature sont « maintenant postés » vers le point d’accès v2 pour les deux chaînes ; elle nomme la fonction « Multichain blind-sign tracking ». Le changement est arrivé sur npm dans la version 2.7.0 le 16 octobre. La dernière version, la 2.8.0 du 21 octobre, le conserve, et aucune modification des émetteurs n’avait été fusionnée ni ouverte à 05 h 50 UTC le 12 novembre.

La réponse de Ledger : le Clear Signing exige la recherche, et rien n’est conservé

Clear Signing est le nom que Ledger donne à l’affichage d’une transaction sur l’écran de l’appareil en mots qu’une personne peut vérifier, comme le jeton, le montant et le contrat d’un échange, au lieu d’une suite hexadécimale. Il s’appuie sur des fichiers de description rédigés selon ERC-7730, un projet de norme Ethereum créé en février 2024 qui indique à un portefeuille comment étiqueter et formater un appel de contrat donné. Quand aucun descripteur ne correspond, l’utilisateur est invité à signer à l’aveugle, c’est-à-dire à approuver des données que l’écran ne peut pas expliquer.

L’argument de Ledger Donjon, tel que relayé par Unchained et Protos, est que ces fichiers sont trop volumineux pour tenir dans l’appareil : le module par défaut les cherche donc sur les serveurs de Ledger au moment de la signature. « Cela exige d’envoyer les détails de la transaction nécessaires pour trouver le bon descripteur », a écrit Donjon, selon Protos. Ledger affirme ne conserver aucune de ces données et indique que les éditeurs de portefeuilles peuvent brancher un module de leur choix.

Le code confirme une partie de cette explication et en laisse une autre ouverte. Dans le kit, les recherches de descripteurs vont vers une autre adresse de Ledger, le service Crypto Assets List à global.api.prd.ledger.com/cal/v1. Les rapports, eux, partent vers le point d’accès de signature à l’aveugle une fois que le kit a décidé si la signature était claire ou aveugle, et ils portent ce verdict. Ils se lisent comme un relevé de la fréquence des échecs du clear signing et des contrats concernés, ce qui correspond au nom même de la fonction, plutôt que comme la recherche elle-même. Ledger n’a pas publié l’usage qu’il fait des rapports, la durée pendant laquelle ses serveurs gardent les journaux de requêtes, ni de notice de confidentialité propre à ce point d’accès. Personne en dehors de Ledger n’a vérifié l’affirmation selon laquelle rien n’est conservé.

Qui est concerné : les portefeuilles bâtis sur le kit, pas l’appareil lui-même

Aucune liste des portefeuilles qui utilisent le kit avec ses réglages par défaut n’a été publiée. Protos écrit que les applications doivent se désinscrire et que « l’écrasante majorité ne le fait pas », sans donner de chiffre. Ambire est le seul cas nommé, et affirme qu’aucune version avec les rapports activés n’a atteint son application en production : son code les garde désormais désactivés sauf si l’utilisateur les active dans les paramètres de confidentialité, selon Unchained.

Pour qui possède un Ledger Nano X ou un autre Ledger, les rapports ne partent pas de l’appareil. Ils sont envoyés par l’application du portefeuille, sur le téléphone ou l’ordinateur, qui dialogue avec internet ; l’appareil, lui, se contente de signer. Une mise à jour du firmware n’y change rien, et Ledger n’a demandé à personne de déplacer ses fonds ni de changer sa phrase de récupération. C’est aussi une affaire distincte des appareils Ledger piégés sur lesquels la police de Singapour a lancé l’alerte en octobre.

Comment désactiver les rapports de signature de Ledger

Pour les utilisateurs, le seul levier est le portefeuille. Chez Ambire, les rapports sont déjà désactivés sauf activation volontaire. Les utilisateurs d’autres portefeuilles qui se connectent à un Ledger peuvent demander à l’éditeur s’il livre le context-module de Ledger avec l’émetteur par défaut, et dans quelle version : rapports Ethereum à partir de la 1.16.0 (vers la production à partir de la 2.1.0), rapports Solana et second rapport Ethereum à partir de la 2.7.0.

Pour les éditeurs de portefeuilles, le constructeur de Ledger offre trois voies dans le code actuel :

• setReporterConfig change l’adresse vers laquelle postent les deux émetteurs, par exemple vers un serveur que le portefeuille exploite lui-même.
• setBlindSigningReporter remplace l’émetteur d’origine par un émetteur écrit par le portefeuille, qui peut très bien ne rien faire.
• Un portefeuille peut fournir au signataire son propre context-module, la voie que Ledger Donjon a indiquée.

Le constructeur ne propose aucun interrupteur pour remplacer à lui seul le nouvel émetteur multichaîne ; un portefeuille qui veut s’en passer doit rediriger l’adresse ou fournir son propre module. Un réglage par défaut de Ledger qui n’enverrait rien rendrait tout cela inutile.

La confidentialité par défaut, et les questions que Ledger n’a pas tranchées

« Je soutiens que la confidentialité devrait être le réglage par défaut », a écrit Kosev, selon Unchained. Une adresse et un modèle d’appareil ne sont pas des secrets en soi. Envoyée à chaque signature avec une version de firmware, une adresse de destination peut cependant être rapprochée du registre public et horodaté d’une blockchain, et les rapports partent vers Ledger tant que l’éditeur du portefeuille ne change pas le réglage. Nicolas Bacca, cofondateur de Ledger parti de l’entreprise en 2023, a dit que ce réglage avait pu être « négligé », a rapporté Protos.

Ledger est une entreprise basée à Paris, et selon le droit européen de la protection des données, une information rattachable à une personne identifiable peut constituer une donnée personnelle. Aucune autorité de protection des données n’avait réagi publiquement au 12 novembre, et Ledger n’a publié ni billet de blog ni avis sur ces rapports.

La suite appartient à Ledger. L’entreprise peut passer le réglage par défaut sur « désactivé » dans une nouvelle version du context-module, publier ce que le point d’accès de signature à l’aveugle conserve et pendant combien de temps, ou laisser les portefeuilles se désinscrire un par un. Pour qui prépare un appareil, notre guide pour configurer un portefeuille matériel explique comment vérifier le traitement des données par l’application associée.