Ledger Rejette Les Accusations De Piratage OneKey

Imaginez ouvrir votre portefeuille matériel un matin, convaincu que l’écran de confirmation affiche exactement ce que vous signez, puis découvrir qu’une faille permettrait à un attaquant de modifier silencieusement les paramètres de la transaction. C’est précisément le scénario qui a enflammé la communauté crypto ces derniers jours. OneKey a affirmé avoir « hacké » Ledger en laboratoire. Ledger a immédiatement répliqué que le bug était déjà corrigé et qu’aucun utilisateur n’avait perdu de fonds. Entre déclaration spectaculaire et réponse technique, une question plus large se pose : jusqu’où peut-on encore faire confiance à l’affichage sécurisé de nos appareils ?

Le Désaccord Qui Secoue Le Monde Des Wallets Matériels

Le 27 août, Yishi Wang, fondateur de OneKey, a publié un message clair et direct. Son équipe Anzen avait réussi à reproduire une attaque de substitution de transaction contre l’application Ethereum version 1.22.1 de Ledger. Dans le langage crypto, cette phrase a immédiatement fait le tour des réseaux. « We hacked Ledger », a-t-il écrit. Quelques heures plus tard, Charles Guillemet, directeur technique de Ledger, a répondu avec la même fermeté : reproduire un bug déjà patché ne constitue pas un piratage de l’entreprise.

Cette opposition de points de vue ne porte pas seulement sur une question de sémantique. Elle touche au cœur de ce qui fait la réputation des portefeuilles matériels : la garantie que ce que l’utilisateur voit sur l’écran de l’appareil est exactement ce qui sera signé. Lorsque cette promesse est remise en question, même pour une version ancienne, la confiance vacille.

Ce Que OneKey A Exactement Démontré

Les chercheurs d’OneKey Anzen ont travaillé dans un environnement contrôlé. Ils ont ciblé spécifiquement l’application Ethereum 1.22.1. Leur démonstration repose sur une condition de course, un type de vulnérabilité bien connu en informatique. Pendant que l’utilisateur examinait les détails d’une transaction sur l’écran de l’appareil, un second ordre pouvait arriver et modifier les paramètres stockés en mémoire partagée sans actualiser l’affichage.

Le résultat potentiel était troublant. L’utilisateur approuvait ce qu’il voyait, transaction A, alors que la signature générée concernait en réalité transaction B. Aucun avertissement n’apparaissait. Le seed phrase restait inaccessible, les clés privées n’étaient pas extraites du secure element. Pourtant, la signature produite ne correspondait plus à ce que l’utilisateur pensait valider.

Nous avons réussi à reproduire une attaque de remplacement de transaction contre l’application Ethereum 1.22.1 de Ledger dans notre laboratoire. Le bug est une condition de course entre la logique d’affichage de la transaction et le buffer sous-jacent.

Yishi Wang, fondateur de OneKey

Cette description technique a été rapidement confirmée par Ledger elle-même. L’entreprise a reconnu l’existence de la vulnérabilité, mais a insisté sur un point crucial : elle avait déjà été corrigée avant que la démonstration ne soit rendue publique.

La Réponse Officielle De Ledger

Ledger a publié un bulletin de sécurité détaillé. L’entreprise classifie le problème comme une condition de type time-of-check to time-of-use. En d’autres termes, le moment où l’appareil vérifie les informations et le moment où il les utilise pour signer ne sont plus synchronisés de manière fiable dans certaines conditions.

Selon Ledger, la première correction au niveau de l’application est apparue dans la version 1.22.2, sortie le 13 août. Cette mise à jour introduisait des contrôles d’état destinés à empêcher l’arrivée de nouvelles commandes pendant qu’une transaction était en cours de revue. Quelques jours plus tard, le 21 août, le Secure SDK version 26.6.1 a été publié. Cette version bloque les commandes intercalées avant même qu’elles n’atteignent les applications individuelles.

Ledger recommande désormais la version 1.22.3 car elle intègre à la fois les protections de l’application et celles du SDK corrigé, tout en traitant une autre faiblesse liée à l’affichage des transactions. OneKey avait raison de dire que 1.22.3 était sécurisée. Ledger souligne simplement que la première protection concrète existait déjà dans 1.22.2.

Comment Fonctionnait Exactement La Faille

Pour comprendre l’enjeu, il faut se pencher sur le fonctionnement interne des appareils Ledger. Les applications reçoivent des instructions appelées APDU, Application Protocol Data Unit. Ces commandes proviennent du logiciel de portefeuille, d’une page web ou d’une autre interface connectée à l’appareil.

Dans les versions concernées, une application pouvait accepter une seconde commande APDU pendant que l’utilisateur examinait encore la première opération. Cette nouvelle instruction avait la capacité d’écraser les paramètres de signature stockés en mémoire partagée. L’écran, lui, ne se mettait pas à jour. L’utilisateur voyait toujours les mêmes informations, mais le contenu signé avait changé.

Ledger a précisé que le défaut se situait dans la gestion des entrées et sorties du Secure SDK, et non dans le système d’exploitation ou le firmware de l’appareil. Les applications compilées avec les versions affectées du SDK devaient donc mettre en place leurs propres vérifications d’état pour rejeter les commandes arrivant pendant une revue active.

Cette nuance est importante. L’exposition était spécifique à chaque application. Une application restait protégée si tous ses points d’entrée asynchrones vérifiaient correctement leur état, même lorsqu’elle avait été construite avec un SDK vulnérable.

Les Conditions Nécessaires Pour Exploiter La Vulnérabilité

Contrairement à certaines failles spectaculaires, celle-ci ne pouvait pas être exploitée à distance contre un appareil débranché. L’attaquant devait contrôler les communications entre l’application Ledger et son hôte. Ledger a listé plusieurs vecteurs possibles : un malware installé sur l’ordinateur, une application de portefeuille compromise, ou une page web hostile disposant d’un accès WebHID ou WebUSB.

Même dans ces conditions, l’utilisateur devait encore approuver la transaction pendant que le logiciel malveillant manipulait le contexte de signature en attente. Il ne s’agissait donc pas d’une attaque purement passive. Une interaction active de la victime restait indispensable.

Ledger a également affirmé n’avoir trouvé aucune preuve que cette vulnérabilité, désignée sous le nom de LSB 023, ait été exploitée contre des clients. Aucune perte de cryptomonnaies n’a été publiquement liée à ce problème précis.

Pourquoi La Distinction Entre Application Et SDK Compte

Beaucoup d’utilisateurs pensent qu’une mise à jour du firmware suffit à protéger leur appareil. Dans le cas présent, ce n’est pas exact. Mettre à jour le firmware ne remplace pas automatiquement les applications compilées avec un SDK affecté. Chaque application doit être actualisée séparément via Ledger Live.

Les développeurs tiers sont également concernés. Ledger a indiqué que la faiblesse avait été introduite en août 2025 et qu’elle avait affecté les versions du SDK jusqu’à 26.6.0 inclus. Les équipes qui construisent des applications pour les appareils Ledger doivent donc revoir leur gestion des états et reconstruire leurs logiciels avec le Secure SDK 26.6.1 ou une version ultérieure.

Cette complexité technique explique en partie pourquoi Ledger a insisté sur le fait que la démonstration d’OneKey concernait une version déjà dépassée. Pour l’entreprise, le vrai travail de sécurité avait déjà été accompli avant la publication.

Le Débat Sur Le Vocabulaire : Hacker Ou Reproduire

Le choix des mots a joué un rôle central dans la polémique. Lorsque Yishi Wang a écrit « we hacked Ledger », il a employé un terme qui, dans l’esprit du grand public, évoque une intrusion réussie contre un système en production. Charles Guillemet a répliqué que reproduire un bug déjà patché dans un laboratoire n’équivaut pas à pirater l’entreprise.

Reproduire un bug déjà corrigé n’est pas « hacker Ledger ». Il s’agit d’un exercice de laboratoire contre une application ancienne.

Charles Guillemet, CTO de Ledger

Cette différence de perspective n’est pas anodine. Dans le domaine de la sécurité, les chercheurs en vulnérabilités testent régulièrement des versions anciennes pour comprendre l’impact potentiel d’une faille. Ledger considère que le terme « hack » implique une action contre un système encore vulnérable en conditions réelles. OneKey met en avant la réussite technique de la reproduction, même si la version ciblée n’était plus la plus récente.

Les deux positions contiennent une part de vérité. OneKey a effectivement démontré que la condition de course existait et pouvait être exploitée dans un cadre contrôlé. Ledger a raison de souligner que les utilisateurs qui avaient déjà mis à jour leur application n’étaient plus exposés au moment de la publication.

Ce Que Cela Révèle Sur La Confiance Dans Les Affichages Sécurisés

Les portefeuilles matériels reposent sur un principe fondamental : l’utilisateur peut vérifier sur un écran isolé les montants, les adresses et les actions de contrat avant de signer. Cette garantie, souvent appelée trusted display, constitue l’un des principaux arguments de vente de ces appareils. La faille découverte fragilise précisément ce principe.

Même si les clés privées n’étaient pas extraites, le fait qu’une signature puisse être générée pour des paramètres différents de ceux affichés pose un problème de confiance majeur. Dans un univers où une seule transaction mal signée peut entraîner la perte définitive de fonds, chaque écart entre l’affichage et l’action réelle devient critique.

Cette affaire rappelle que la sécurité d’un portefeuille matériel ne se limite pas à la protection du seed. Elle dépend aussi de la robustesse de la communication entre l’appareil et son environnement, ainsi que de la qualité du code des applications qui s’y exécutent.

Les Recommandations Concrètes Pour Les Utilisateurs

Ledger a été clair sur les actions à entreprendre. Les détenteurs d’appareils doivent ouvrir Ledger Live, installer les dernières versions des applications et vérifier spécifiquement la version de l’application Ethereum affichée sur le hardware wallet. Une simple mise à jour du firmware ne suffit pas.

Les utilisateurs qui n’ont pas encore mis à jour leur application depuis le 13 août devraient le faire sans délai. Même si Ledger affirme qu’aucune exploitation n’a été observée, le principe de précaution reste de mise.

Un Contexte De Vigilance Accrue Dans Le Secteur

Cette révélation s’inscrit dans une période où plusieurs fabricants de portefeuilles matériels ont dû publier des correctifs. BitBox, par exemple, a récemment patché deux failles concernant l’installation de firmware et la gestion des adresses Bitcoin, sans non plus signaler d’exploitation confirmée.

Ces annonces successives illustrent une réalité du secteur : même les dispositifs conçus pour maximiser la sécurité nécessitent des mises à jour régulières. Les utilisateurs qui considèrent leur portefeuille matériel comme un objet figé une fois acheté se trompent. La maintenance logicielle reste essentielle.

Paradoxalement, la transparence avec laquelle Ledger a communiqué sur cette vulnérabilité, en confirmant son existence tout en précisant le calendrier des correctifs, peut renforcer la confiance à long terme. Les entreprises qui tentent de dissimuler les problèmes finissent généralement par perdre davantage de crédibilité.

Les Implications Pour Les Développeurs D’Applications

Au-delà des utilisateurs finaux, l’affaire concerne tous les développeurs qui créent des applications pour l’écosystème Ledger. La faiblesse se situait dans le SDK, ce qui signifie que de nombreuses applications tierces pouvaient potentiellement être affectées si elles ne mettaient pas en place leurs propres contrôles d’état.

Ledger a appelé ces équipes à revoir leur code et à recompiler leurs applications avec le Secure SDK 26.6.1 ou une version plus récente. Cette recommandation souligne l’importance d’une chaîne d’approvisionnement logicielle saine. Une vulnérabilité introduite dans un SDK peut se propager à de nombreux produits dérivés.

Pour les développeurs, l’épisode sert de rappel : même dans un environnement sécurisé comme celui d’un hardware wallet, les hypothèses sur l’ordre d’arrivée des commandes et sur l’état de la mémoire partagée doivent être systématiquement vérifiées.

Pourquoi Cette Affaire Mérite D’Être Suivie

Au premier abord, le désaccord entre OneKey et Ledger peut sembler purement technique ou même commercial. Deux acteurs du même secteur se disputent la formulation d’une découverte. Pourtant, derrière les mots, se joue quelque chose de plus profond.

La confiance dans les portefeuilles matériels repose sur une promesse simple : ce que vous voyez est ce que vous signez. Chaque fois qu’une faille remet en cause cette promesse, même pour une version ancienne, les utilisateurs sont en droit de demander des comptes. La manière dont Ledger a réagi, en confirmant la vulnérabilité tout en détaillant le calendrier des correctifs, montre une certaine maturité. La manière dont OneKey a communiqué, en utilisant un langage fort, a forcé l’attention sur un sujet qui aurait pu passer inaperçu.

Dans un marché où les montants stockés sur des appareils physiques atteignent des niveaux considérables, la moindre faille de communication entre l’écran et la signature devient un sujet d’intérêt public. Les utilisateurs ne peuvent plus se contenter d’acheter un appareil et de l’oublier. Ils doivent suivre les mises à jour, comprendre les vecteurs d’attaque et rester vigilants quant à l’environnement dans lequel ils connectent leur hardware wallet.

Les Limites De La Démonstration En Laboratoire

Il est important de rappeler que la reproduction d’OneKey s’est déroulée dans un cadre contrôlé. Les conditions d’exploitation réelles sont plus exigeantes. L’attaquant doit déjà disposer d’un certain contrôle sur la machine de la victime. Un appareil débranché et stocké dans un endroit sûr reste hors de portée de cette attaque particulière.

Cette distinction entre vulnérabilité théorique et risque pratique est essentielle. Beaucoup de failles de sécurité existent dans le code sans jamais être exploitées à grande échelle, soit parce que les conditions d’exploitation sont trop complexes, soit parce que les correctifs sont déployés rapidement.

Ledger affirme n’avoir observé aucune exploitation. Jusqu’à preuve du contraire, cette affirmation doit être prise en compte. Cela ne diminue pas l’intérêt de la découverte d’OneKey, mais elle place le risque dans une perspective plus réaliste.

Comment Évaluer La Réponse Des Fabricants

Face à une vulnérabilité, la qualité de la réponse d’un fabricant se mesure à plusieurs critères. La rapidité avec laquelle le correctif a été déployé, la clarté de la communication, la transparence sur le calendrier et l’absence de minimisation du problème.

Dans le cas présent, Ledger a publié un bulletin détaillé, a confirmé l’existence de la faille, a fourni une chronologie précise des versions et a formulé des recommandations concrètes. L’entreprise a également insisté sur le fait que les utilisateurs devaient mettre à jour leurs applications et non seulement le firmware.

OneKey, de son côté, a joué un rôle de lanceur d’alerte en rendant publique une démonstration technique. Même si le langage employé a été jugé excessif par Ledger, l’effet a été d’attirer l’attention de la communauté sur un sujet technique qui aurait pu rester confiné aux spécialistes.

Les Enseignements Plus Larges Pour La Sécurité Crypto

Cette affaire illustre plusieurs vérités générales sur la sécurité dans l’écosystème des cryptomonnaies. Premièrement, aucun système n’est parfait. Même les appareils conçus pour isoler les clés privées peuvent présenter des faiblesses dans la gestion des communications ou dans le code des applications.

Deuxièmement, la mise à jour régulière des logiciels est non négociable. Les utilisateurs qui négligent les alertes de sécurité s’exposent inutilement. Troisièmement, la collaboration, même conflictuelle, entre différents acteurs du secteur peut aboutir à une meilleure protection globale. Lorsque OneKey publie une démonstration et que Ledger répond par un correctif et une communication transparente, l’ensemble de la communauté en bénéficie.

Enfin, le langage utilisé pour communiquer sur les failles de sécurité a un impact réel. Un terme comme « hack » attire l’attention, mais il peut aussi créer une confusion si les conditions d’exploitation ne sont pas clairement expliquées. Les chercheurs et les entreprises ont intérêt à trouver un équilibre entre l’impact médiatique et la précision technique.

Que Faire Si Vous Possédez Un Appareil Ledger

Si vous êtes propriétaire d’un Ledger, la priorité est simple. Vérifiez immédiatement la version de votre application Ethereum. Si elle est antérieure à 1.22.2, mettez-la à jour sans attendre. Idéalement, installez la version 1.22.3 ou supérieure pour bénéficier de l’ensemble des protections.

Prenez également l’habitude de ne jamais valider une transaction sur un ordinateur ou un navigateur dont vous n’êtes pas certain de l’intégrité. Les vecteurs d’attaque décrits par Ledger passent tous par un contrôle de la communication entre l’appareil et son hôte. Réduire la surface d’attaque au niveau de l’ordinateur diminue considérablement le risque.

Enfin, restez attentif aux communications officielles de Ledger. Les bulletins de sécurité constituent la source la plus fiable d’information. Les publications sur les réseaux sociaux, même lorsqu’elles émanent de chercheurs réputés, doivent toujours être croisées avec les annonces de l’éditeur.

La Place Des Portefeuilles Matériels Dans Une Stratégie De Sécurité Globale

Malgré cette alerte, les portefeuilles matériels restent l’une des solutions les plus robustes pour stocker des cryptomonnaies à long terme. Ils isolent les clés privées du système d’exploitation principal et forcent une validation physique des opérations sensibles. La faille découverte n’invalide pas ce modèle. Elle rappelle simplement qu’il n’est pas infaillible.

Une stratégie de sécurité complète combine plusieurs couches. Un hardware wallet bien mis à jour, un environnement informatique sain, une attention particulière aux adresses et aux montants affichés, et une hygiène numérique générale. Aucun outil, aussi sophistiqué soit-il, ne remplace la vigilance de l’utilisateur.

Dans le cas de la vulnérabilité signalée, un utilisateur attentif qui aurait remarqué une incohérence entre le montant affiché et le montant réellement attendu aurait pu refuser de signer. La faille réduisait la fiabilité de l’affichage, mais elle n’obligeait pas l’utilisateur à approuver.

Perspectives Et Suivi De L’Affaire

Il est probable que d’autres détails techniques émergeront dans les semaines à venir. Les chercheurs en sécurité continuent d’analyser le code des applications et des SDK. Ledger pourrait publier des informations supplémentaires si de nouvelles versions ou de nouveaux vecteurs sont identifiés.

OneKey, de son côté, a démontré sa capacité à tester en profondeur les produits concurrentiels. Cette concurrence sur le terrain de la sécurité peut être bénéfique pour l’ensemble du marché, à condition qu’elle s’accompagne d’une communication précise et responsable.

Pour les utilisateurs, le message principal reste inchangé. Mettez à jour vos applications, vérifiez les versions, restez informés. La sécurité des cryptomonnaies n’est jamais un état acquis une fois pour toutes. C’est un processus continu qui demande attention et discipline.

L’épisode entre OneKey et Ledger ne marque pas la fin de la confiance dans les portefeuilles matériels. Il marque plutôt un moment de maturité où les failles sont identifiées, discutées publiquement et corrigées rapidement. Dans un secteur encore jeune, cette capacité à réagir constitue peut-être le meilleur indicateur de solidité à long terme.

Les prochains mois diront si d’autres applications ou d’autres fabricants sont concernés par des problématiques similaires. En attendant, la priorité pour chacun reste de s’assurer que ses propres appareils tournent avec les dernières versions disponibles. Car au final, la meilleure protection contre une vulnérabilité déjà patchée, c’est encore d’avoir installé le correctif.