Le SDK de Ledger envoie par défaut les métadonnées de signature aux serveurs de l'entreprise
Points clés
- •Le module contextuel de Ledger version 1.16.0, daté du 14 avril, a ajouté un rapporteur de blind-signing par défaut qui transmet les métadonnées de signature aux serveurs de Ledger, sauf si le développeur du portefeuille intégrant en fournit un remplaçant.
- •Les rapports peuvent inclure un identifiant d'événement de signature, la méthode de signature, le chain ID, l'adresse cible, le statut de blind-signing, le modèle d'appareil et les versions logicielles, mais ne contiennent pas de clés privées, de phrases de récupération ni de signatures cryptographiques.
- •Ledger a basculé la destination des rapports d'une adresse d'ingestion de staging vers son point de terminaison de production de blind-signing, https://blind-signing.api.ledger.com/ingest, dans la version 2.1.0.
- •Le développeur d'Ambire a déclaré qu'aucune version concernée n'était parvenue à l'application de production du portefeuille, livré avec le reporting désactivé par défaut et une option d'activation dans les paramètres de confidentialité.
- •L'exposition des utilisateurs dépend de la manière dont leur portefeuille intègre le SDK, la décision de conserver ou de remplacer le rapporteur par défaut étant prise dans le code de l'application plutôt que dans les paramètres de l'appareil.

Le logiciel d'intégration des portefeuilles de Ledger comprend un service de reporting par défaut qui transmet les métadonnées de signature aux serveurs de l'entreprise — un comportement que le développeur d'Ambire @0xSuperKalo a mis en lumière le 10 novembre. Le code source public de Ledger montre que les rapports peuvent inclure le réseau, l'adresse de destination, le modèle d'appareil, les versions logicielles et l'indication de savoir si la signature a été effectuée à l'aveugle.
Le mécanisme réside dans le logiciel utilisé par les applications de portefeuille pour communiquer avec le matériel Ledger. Les portefeuilles matériels conservent les clés privées isolées sur l'appareil, et les applications y accèdent via ces kits de développement logiciel réutilisables — ce qui signifie qu'une valeur par défaut intégrée au SDK s'applique partout où il est déployé. L'implémentation de la version 1.16.0 installe un rapporteur réseau, sauf si le développeur intégrant en fournit un remplaçant. L'exposition des utilisateurs dépend donc de la manière dont leur portefeuille intègre le SDK, et non d'une simple mise à jour du firmware.
Le développeur d'Ambire a indiqué qu'aucune version concernée n'était parvenue à l'application de production d'Ambire et que le portefeuille est livré avec le reporting désactivé par défaut, avec une option d'activation dans les paramètres de confidentialité. « Je dirais que la confidentialité devrait être la norme par défaut », a écrit le développeur.
Ce que contiennent les rapports
Le registre des versions de Ledger date le module contextuel 1.16.0 du 14 avril et décrit l'ajout d'un rapporteur de blind-signing au module. Le code de signature Ethereum qui l'accompagne génère des rapports pour les transactions et la signature de données typées, y compris lorsque l'opération est classée comme n'étant pas une signature à l'aveugle.
Le code de génération des rapports fournit un identifiant d'événement de signature généré, la méthode de signature, le chain ID, l'adresse cible, le statut de blind-signing et sa raison, le modèle d'appareil ainsi que les versions de l'application de signature et du firmware lorsqu'elles sont disponibles. Il inclut également le type de clear-signing et le nombre d'erreurs de contexte lorsque ces informations sont disponibles. Le clear-signing désigne la présentation des détails d'une transaction sous forme lisible avant l'approbation ; le blind-signing en est le pendant — l'approbation de données que l'appareil ne peut pas afficher sous forme lisible. Les adresses de destination sont pseudonymes sur les blockchains publiques, mais chaque rapport associe une adresse cible à la méthode de signature, au modèle d'appareil et aux versions logicielles dans une charge unique envoyée aux serveurs de Ledger.
L'implémentation HTTP ajoute un libellé de source d'application et envoie le rapport avec des en-têtes identifiant la version du module contextuel et le jeton d'origine de l'intégration. Le générateur de rapports ne contient pas de clés privées, de phrase de récupération ni de signature cryptographique — ce qui place le comportement signalé dans la catégorie de la collecte de métadonnées plutôt que de la conservation des clés.
La destination des rapports a évolué au fil du temps. La version 1.16.0 configurait une adresse d'ingestion de staging, et le changelog ultérieur de Ledger enregistre un basculement vers le point de terminaison de production de blind-signing dans la version 2.1.0. Le générateur actuel dirige le rapporteur vers
Pour les développeurs de portefeuilles, le générateur offre un moyen de remplacer le rapporteur par défaut. Le développeur d'Ambire indique que son implémentation offrira aux utilisateurs une option dans les paramètres de confidentialité, avec l'envoi des rapports désactivé par défaut. Pour les utilisateurs, le facteur déterminant est le portefeuille qu'ils utilisent : ses développeurs ont-ils conservé le rapporteur par défaut ou l'ont-ils remplacé — un choix effectué dans le code de l'application plutôt que dans les paramètres de l'appareil. Alors que le rapporteur par défaut pointe désormais vers le point de terminaison d'ingestion de production de Ledger depuis la version 2.1.0, la manière dont les créateurs de portefeuilles configurent le module est ce qu'il convient de surveiller.