Andrey Lazutkin (Tangem) : plaidoyer pour des hardware wallets plus simples

Le marketing des hardware wallets suit généralement une logique : toujours plus de fonctionnalités, plus d’écrans, plus de connectivité, plus de mises à jour firmware. Tangem a fait le pari inverse pour l’ensemble de son produit.
 

Il n’y a ni écran, ni batterie, ni connectivité USB ou Bluetooth, ni firmware pouvant être mis à jour, ni phrase de récupération à enregistrer. Pour beaucoup dans la communauté sécurité, cela ressemble à la liste des fonctionnalités attendues d’un wallet crypto ; en réalité, c’est la liste de ce qui a été volontairement écarté.
 

Yellow Media s’est entretenu avec Andrey Lazutkin, CTO de Tangem, pour creuser précisément ces choix. 

• Que se passe-t-il si le téléphone est compromis ? 
• Pourquoi livrer un firmware que l’on ne pourra jamais mettre à jour ? 
• Qu’est-ce qui protège une Tangem Ring d’une attaque NFC dans un train bondé ? 
• Et que se passera-t-il avec l’arrivée de l’informatique quantique ?

Le défi du « sans écran » : et si le téléphone ment ?

Un principe fondamental des hardware wallets traditionnels est « ce que vous voyez est ce que vous signez » : un écran intégré permettant de vérifier les détails d’une transaction. Tangem n’a pas d’écran et délègue toute l’interface au smartphone. 

Si un téléphone est compromis par un malware qui modifie ce qui s’affiche à l’écran, un utilisateur pourrait autoriser un transfert NFC malicieux sans le savoir. Comment votre architecture empêche-t-elle la manipulation de l’interface sur un appareil infecté ?

Un écran n’est pas un modèle de sécurité en soi. Ce n’est qu’un composant. Mais chaque composant crée un risque. Plus un hardware wallet est complexe, plus il multiplie les surfaces d’attaque : logique d’affichage, boutons, firmware, mécanismes de mise à jour, USB, Bluetooth, batteries, pilotes, parseurs et interfaces physiques. 

Internet regorge d’exemples où des hardware wallets traditionnels ont été attaqués non pas parce que la cryptographie était cassée, mais parce que la complexité de l’implémentation a ouvert une faille.

Tangem suit la philosophie inverse : rendre l’appareil de signature aussi simple que possible. Pas d’écran, pas de batterie, pas d’USB, pas de Bluetooth, pas de firmware modifiable, pas de système d’exploitation complexe. La clé privée est générée et stockée dans la puce sécurisée, et ne quitte jamais la carte. Cette simplicité constitue un véritable avantage en matière de sécurité.

Le téléphone sert d’interface, mais ce n’est pas là que résident les clés. L’application Tangem est également fortement sécurisée :

• vérifications d’intégrité à l’exécution, 
• anti-debugging,
• anti-émulation, 
• détection de root et de jailbreak, 
• stockage chiffré,
• communication sécurisée, 
• validation des certificats, 
• protection WebView, 
• protection contre le tapjacking, 
• saisie sécurisée, 

À cela s’ajoutent des permissions minimisées, des revues de code, des audits et des contrôles de sécurité automatisés.
 

Nous ne considérons donc pas la sécurité comme « avec ou sans écran ». Nous examinons l’architecture dans son ensemble. Tangem réduit la surface d’attaque au niveau matériel et renforce la couche mobile qui prépare les transactions. Cette approche offre aux utilisateurs une combinaison puissante : un appareil de signature simple et isolé, et une expérience mobile moderne et sécurisée.

En sécurité, la complexité est souvent l’ennemie. L’atout de Tangem, c’est que la carte fait très peu, mais fait une chose critique de façon extrêmement fiable : protéger la clé et signer en toute sécurité.

Pourquoi la carte ne pourra jamais être patchée

Votre firmware est injecté en usine et immuable : il ne peut pas être mis à jour à distance, ce qui élimine le risque de mises à jour malveillantes. Mais si une faille critique ou zero-day cryptographique est découverte sur ce lot de puces, l’utilisateur ne peut pas patcher. Pourquoi un composant totalement non modifiable est-il plus sûr pour la garde personnelle à long terme qu’un composant patchable ?

La possibilité de mettre à jour n’est pas gratuite. Dans un hardware wallet, un mécanisme de mise à jour est aussi un mécanisme permanent d’injection de code.

Si un wallet peut recevoir un nouveau firmware après avoir quitté l’usine, l’utilisateur doit alors faire confiance au fournisseur indéfiniment : ses clés de signature, son système de build, sa chaîne de publication, ses serveurs de mise à jour, ses employés, ses processus de sécurité et ses choix futurs. Même si tout est conçu correctement, cette infrastructure devient une partie de la base de confiance.
 

Cela crée de vrais risques : serveurs de mise à jour compromis, clés de signature divulguées, employés malveillants, pression réglementaire, mises à jour accidentelles, ou un futur firmware qui affaiblit le modèle de sécurité initial.

La controverse Ledger Recover l’a bien illustré. Le compte support de Ledger aurait écrit dans un post supprimé depuis : « Techniquement, il a toujours été possible d’écrire un firmware facilitant l’extraction de clés. Vous avez toujours fait confiance à Ledger pour ne pas déployer un tel firmware, que vous le sachiez ou non. » C’est précisément cette hypothèse de confiance que Tangem supprime.
 

Tangem fait le choix de l’immutabilité. Notre firmware est flashé lors de la production et ne peut plus être modifié par la suite. Il n’y a pas de mise à jour OTA, pas de flashage USB, pas de mise à jour sans fil, et aucun moyen pour Tangem d’injecter du nouveau code sur la carte après sa livraison à l’utilisateur.

Oui, cela signifie que nous ne pouvons pas patcher une puce à distance si une faille matérielle est découverte plus tard. Mais un appareil modifiable n’élimine pas le risque : il crée un autre risque, permanent : la possibilité de modifier plus tard du code critique pour la sécurité.

Pour la garde personnelle à long terme, nous pensons que la racine de confiance la plus sûre est immuable. L’appareil ne doit pas dépendre de la fiabilité du fabricant dans le temps. La philosophie de Tangem est simple : la carte protège la clé, signe en toute sécurité, et n’accepte plus jamais de nouveau code.
 

La dépendance aux app stores

Tangem dépend de son application compagnon : il existe une dépendance structurelle à des canaux de distribution centralisés comme l’App Store d’Apple ou Google Play.

 Si un acteur étatique ou un attaquant sophistiqué compromettait vos identifiants développeur et publiait une mise à jour malveillante avant que votre équipe ne s’en rende compte, quels garde-fous natifs dans l’élément sécurisé protègent les fonds des utilisateurs ?

Pour qu’un tel scénario se produise, un attaquant devrait compromettre nos identifiants développeur, contourner l’authentification à plusieurs facteurs et les contrôles d’accès internes, passer le processus d’approbation de publication, injecter du code malveillant dans la version officielle, réussir la validation Apple ou Google, conserver l’identité officielle de l’application, éviter la détection par les plateformes, et rester invisible pour notre équipe, nos systèmes de surveillance et la communauté open source.

Ce n’est pas une seule faille, mais une cascade d’échecs sur plusieurs couches de sécurité indépendantes. C’est précisément ce que j’entends lorsque je dis que la sécurité doit s’évaluer comme un système complet, et non en se focalisant sur une seule fonctionnalité isolée. 

À nos yeux, la probabilité qu’une telle chaîne aboutisse est bien plus faible que les risques créés par une architecture de hardware wallet plus complexe, surtout si elle dépend de mises à jour firmware pour rester sécurisée dans le temps.
 

Des appareils plus complexes nécessitent plus d’interfaces, plus de firmware, plus de mécanismes de mise à jour, plus de composants et plus de processus de confiance. Chacune de ces couches crée de nouvelles surfaces d’attaque : attaques sur la chaîne d’approvisionnement, interfaces de debug, bugs firmware, mises à jour compromises, fuites de clés de signature, compromission du système de build, ou pression du fournisseur pour changer le comportement de l’appareil après expédition.
 

Quand on regarde l’historique des attaques sur les hardware wallets, le schéma est limpide. La plupart des problèmes réels ne viennent pas d’une cryptographie cassée, mais de la complexité : erreurs d’implémentation, mécanismes de mise à jour, interfaces physiques, comportements firmware, hypothèses sur la chaîne d’approvisionnement, ou interactions inattendues entre composants.

Une mise à jour malveillante via un app store est un risque théorique. Mais cela nécessite une chaîne d’échecs indépendants avant même d’atteindre l’utilisateur. À l’inverse, un code source modifiable en permanence maintient une porte de mise à jour ouverte par conception, tout au long de la vie du produit.

C’est le cœur du modèle de sécurité Tangem : minimiser le nombre de composants de confiance, réduire la surface d’attaque, et rendre l’appareil de signature immuable.

Sauvegarde sans seed phrase vs. phrase papier

Votre architecture « sans seed phrase » garantit la sécurité en clonant la clé privée sur des cartes de sauvegarde lors de la configuration. Cela supprime le point de défaillance unique d’une phrase papier, mais crée une dépendance physique : si vous perdez toutes vos cartes de sauvegarde, la récupération devient impossible. Comment une sauvegarde purement matérielle peut-elle s’adapter à la transmission intergénérationnelle ou à la succession, par rapport au standard papier BIP-39 ?

Quand on achète un hardware wallet, on attend qu’il protège les clés privées. Mais dans beaucoup de wallets traditionnels, l’appareil affiche d’abord la seed phrase à l’utilisateur et lui transfère la responsabilité.
 

À partir de là, le maillon faible n’est plus le hardware wallet, mais la seed phrase : un bout de papier, une plaque métallique, un tiroir, un coffre, une photo à ne jamais prendre, ou une phrase qui peut être perdue, abîmée, copiée, exposée ou volée.
 

La perte d’accès aux clés privées et phrases de récupération est l’une des principales causes réelles de perte définitive de cryptos. Chainalysis estime que des millions de bitcoins sont irrémédiablement perdus. Les attaques de phishing ciblent aussi directement les seed phrases, car une fois exposée, le prix ou le niveau de sécurité du hardware wallet n’a plus d’importance.
 

Dans le modèle traditionnel, vous avez un hardware wallet et une seed phrase. Vous pouvez faire des copies de la phrase, mais chaque copie augmente le risque, car elle n’est pas protégée par du matériel. L’utilisateur doit inventer son propre système de sécurité.
 

Tangem voit les choses autrement : la sauvegarde doit aussi être protégée par du matériel. C’est pourquoi, dans une configuration standard Tangem, l’utilisateur reçoit trois cartes. Chaque carte est un hardware wallet à part entière avec un élément sécurisé, et non un simple secret papier non protégé.
 

Pour une succession ou un stockage longue durée, on peut garder une carte pour l’usage quotidien, en stocker une autre en lieu sûr, et confier la troisième à un proche, un avocat ou dans le cadre d’un arrangement successoral. Si toutes les cartes sont perdues, il n’y a pas de récupération possible, mais c’est la vraie auto-garde. Ce que Tangem supprime, c’est la partie la plus fragile du modèle traditionnel : une seed phrase exposée.
 

Si la clé privée mérite d’être protégée par un hardware wallet, alors sa sauvegarde doit l’être aussi. C’est exactement ce que propose Tangem.

La simulation de transaction peut-elle être fiable à 100 % ?

Le phishing DeFi et la signature à l’aveugle restent les principales causes de vidage de wallets chez les particuliers. Votre application intègre la simulation de transaction et la détection de scams dApp pour montrer à l’utilisateur ce qu’un contrat exécutera. 

Mais étant donné la nature Turing-complete des smart contracts complexes et multi-hop, une simulation côté client peut-elle jamais être fiable à 100 % ? Ou y a-t-il un risque de donner à l’utilisateur un faux sentiment de sécurité absolue ?

Excellente question, car vous avez utilisé le terme clé « sécurité absolue ».

La réponse honnête est non. Aucun wallet, moteur de simulation, appareil ou société de sécurité ne peut promettre une sécurité absolue. La crypto est un environnement adversarial. La sécurité n’est pas une fonction magique, mais un ensemble de couches qui rendent les attaques plus difficiles, plus coûteuses et moins généralisables.
 

Et parfois, le point faible n’est pas là où on l’attend. Il existe des cas confirmés publiquement où les données clients d’achats de hardware wallets ont été exposées. Dans ces cas, le problème ne venait pas forcément de la cryptographie ou de l’appareil lui-même, mais du périmètre de sécurité global autour de l’utilisateur : phishing, ingénierie sociale, faux supports, faux appareils de remplacement, ou pression ciblée.
 

Côté DeFi, Tangem utilise certaines des couches de protection les plus avancées : simulation de transaction, analyse de risque des smart contracts, détection de dApps malveillantes, vérification de domaines, alertes sur comportements suspects, et protection contre la signature à l’aveugle partout où la transaction peut être décodée et analysée.
 

Mais la simulation peut-elle être fiable à 100 % pour chaque smart contract ? Non. Les contrats complexes, les routes multi-hop, l’état on-chain évolutif, les front-ends malveillants, les domaines de phishing et l’ingénierie sociale font que l’utilisateur doit toujours vérifier à quoi il se connecte, ce qu’il approuve et s’il fait confiance à la dApp.
 

Nous ne présentons donc jamais la simulation comme une protection absolue. C’est une couche de sécurité supplémentaire, qui améliore considérablement la visibilité avant signature. Elle aide l’utilisateur à comprendre ce qu’une transaction est susceptible de faire, à détecter les scams plus tôt, et à éviter les validations à l’aveugle.

La bonne approche est la suivante : Tangem protège la clé par le matériel, réduit la surface d’attaque avec une carte simple et immuable, et ajoute des protections DeFi modernes dans l’application. Mais l’utilisateur doit continuer à privilégier les dApps de confiance, vérifier les domaines, éviter les transactions précipitées ou sous pression, rester vigilant sur les autorisations, et ne jamais considérer un système d’alerte comme un substitut au bon sens.

La sécurité absolue n’existe pas. Une sécurité solide repose sur des défenses en couches — c’est exactement la philosophie Tangem.
 

Payer les frais réseau en stablecoins sans compromettre le cold storage

Vous avez récemment introduit une fonctionnalité permettant de payer les frais réseau natifs en stablecoins comme USDT ou USDC au lieu du token gas natif. En coulisses, contourner les mécanismes natifs de gas nécessite généralement des relayers d’abstraction de compte ou de la liquidité tierce. 

Ces fonctionnalités pratiques introduisent-elles des risques de contrepartie ou des dépendances centralisées dans ce qui doit rester un environnement de cold storage ?
 

Tangem utilise EIP-7702 pour Smart Gas sur les réseaux EVM compatibles. Cela permet de régler les frais réseau avec certains tokens ERC-20 au lieu de détenir le token gas natif. Le modèle de garde ne change pas : la clé privée reste dans la carte Tangem, l’utilisateur signe toujours avec le hardware wallet, et aucun tiers n’a accès aux clés.
 

Application open source, puce propriétaire

Votre application compagnon est totalement open source sur GitHub, en phase avec l’esprit communautaire « Don’t Trust, Verify ». Mais l’élément sécurisé EAL6+ des cartes s’appuie sur une architecture propriétaire, fermée, développée par les fabricants de puces. 

Comment concilier la philosophie open source de la DeFi avec un socle matériel qui impose de faire confiance à une conception fermée d’un industriel du silicium ?
 

L’open source est important, mais penser que chaque couche d’un produit matériel sécurisé doit être open source est une vision simpliste qui trahit une méconnaissance de la sécurité hardware.
 

Pour un élément sécurisé, un firmware bas niveau fermé et des circuits internes propriétaires ne sont pas un défaut, mais font partie du modèle de protection. Ces puces sont conçues pour résister aux attaques physiques et invasives : injection de fautes, analyse par canaux auxiliaires, sondage, glitching, attaques laser et autres techniques de laboratoire. Publier des informations détaillées sur le comportement firmware interne, la mémoire, les capteurs, les contre-mesures ou la logique de détection de fautes ne rendrait pas les utilisateurs plus sûrs. Cela donnerait une carte aux attaquants.
 

Ce n’est pas une naïve « sécurité par l’obscurité ». La sécurité matérielle sérieuse repose sur des couches : éléments sécurisés certifiés, commandes limitées, audits indépendants, firmware immuable, surface d’attaque minimale. 

Mais cela implique aussi de ne pas exposer de détails bas niveau inutiles qui faciliteraient les attaques physiques.

Et soyons honnêtes : même lorsqu’on parle de « firmware open source », la puce sécurisée elle-même n’est jamais totalement ouverte. Elle contient de la logique matérielle, de la ROM, du microcode, des contre-mesures propriétaires, des procédés de fabrication et des mécanismes physiques que l’utilisateur ne peut ni inspecter, ni reproduire.

Prétendre qu’un consommateur peut tout vérifier dans la chaîne de confiance matérielle simplement parce qu’une partie du code firmware est publiée est trompeur.

Notre modèle de sécurité est : « fermé là où la divulgation aiderait les attaquants, évalué indépendamment là où la confiance est requise, et rester aussi minimaliste que possible ».

Le hardware dans l’espace public : Tangem Ring

À mesure que Tangem élargit sa gamme au-delà des cartes vers des objets connectés grand public comme la Tangem Ring, le hardware entre dans l’espace public. Quelles mesures techniques protègent l’utilisateur d’un adversaire qui tenterait, via un lecteur NFC amplifié dans une foule, d’initier des échanges non autorisés ou de forcer un code d’accès ?

Tout d’abord, NFC signifie Near Field Communication. C’est conçu pour fonctionner à très courte distance, donc l’idée d’un « lecteur amplifié » interagissant discrètement avec une bague au doigt dans une foule n’est pas un scénario réaliste au quotidien.

Il y a aussi un aspect pratique : la Tangem Ring est conçue pour ressembler à un accessoire ordinaire, comme une bague de paiement ou un bijou connecté. Un attaquant devrait d’abord identifier qu’il s’agit d’un hardware wallet crypto, et non d’une simple bague.

Mais même si quelqu’un essayait d’interagir avec la bague via NFC, cela ne lui donnerait pas accès au wallet. La Tangem Ring, comme les cartes Tangem, est protégée par un code d’accès défini par l’utilisateur. Sans ce code, un attaquant ne peut pas autoriser d’opérations sur le wallet.

La force brute n’est pas non plus réaliste. L’appareil protège contre les tentatives répétées de mot de passe : après plusieurs erreurs, le délai entre essais augmente, rendant le « bruteforce » automatisé irréaliste.

Le modèle de sécurité est donc simple : la proximité NFC seule ne suffit pas, la présence physique seule ne suffit pas, et deviner le code d’accès n’est pas réaliste. Les utilisateurs peuvent porter la Tangem Ring en public en toute sécurité.

Régulation et cœur de l’auto-garde

Les régulateurs mondiaux renforcent les cadres autour des « unhosted wallets » et du filtrage obligatoire des destinations de transaction. En tant que CTO, concevez-vous votre infrastructure pour résister à d’éventuelles futures exigences de conformité embarquée ou d’intégration KYC dans les applications d’auto-garde — ou votre logiciel est-il conçu pour rester totalement non modifiable, quels que soient les changements réglementaires ?
 

Il est d’abord important de distinguer l’architecture de l’appareil de la couche réglementaire.

Chez Tangem, la clé privée est générée et stockée dans la carte. La carte ne sait pas ce qu’est le KYC, ne dépend d’aucun serveur de conformité, et ne demande pas l’autorisation de Tangem pour signer une transaction. Elle protège simplement la clé et signe quand l’utilisateur l’autorise.
 

L’utilisateur peut interagir avec la carte via l’application officielle Tangem, ou via des outils et SDK open source. Cela signifie que Tangem ne peut pas geler la carte à distance, extraire la clé ou empêcher l’accès aux fonds au niveau matériel.
 

Concernant la régulation, il faut être réaliste. Forcer les wallets d’auto-garde à intégrer des mécanismes de contrôle directement dans la couche de signature serait une mauvaise solution. Il existe de nombreux wallets gratuits, open source, forks ou solutions alternatives. Si les régulateurs poussent les utilisateurs hors des produits sûrs et audités, beaucoup se tourneront vers des alternatives moins transparentes et moins sûres. Cela augmenterait les pertes, les arnaques et l’activité souterraine, au lieu de les réduire.
 

Ce que l’on observe déjà à l’échelle mondiale, c’est une autre tendance : les régulateurs se concentrent sur les points de contact entre la crypto et les services régulés : exchanges, on-ramps, off-ramps, produits de paiement, intermédiaires financiers. C’est là que les obligations KYC, AML, sanctions et reporting s’appliquent généralement.
 

Si certaines juridictions imposent des parcours de conformité pour des services spécifiques, Tangem peut aider ses utilisateurs à rester conformes lors de l’utilisation de ces services. Mais cela n’a rien à voir avec l’idée de rendre le hardware wallet lui-même « permissionné ».

Notre position est simple : Tangem peut faciliter l’accès à des services régulés, mais le cœur de l’auto-garde doit rester intact. La carte protège la clé. L’utilisateur contrôle les fonds. Tangem ne détient pas les actifs, ne contrôle pas la clé privée, et ne dispose d’aucun bouton à distance pour décider si un utilisateur peut signer ou non.
 

La question quantique

La grande majorité des hardware wallets, y compris Tangem, reposent sur la cryptographie à courbe elliptique standard (ECDSA ou Ed25519). Avec l’accélération de l’informatique quantique, dans quelle mesure des puces à firmware figé sont-elles vulnérables à une éventuelle cryptanalyse quantique, et quelle est votre feuille de route pour la transition des cartes physiques existantes vers la cryptographie post-quantique ?
 

La transition vers la cryptographie post-quantique doit commencer au niveau des protocoles blockchain.

Les hardware wallets ne définissent pas quels algorithmes de signature sont acceptés par Bitcoin, Ethereum, Solana ou d’autres réseaux. Il faut d’abord que les blockchains adoptent des standards cryptographiques résistants au quantique. Ce n’est qu’ensuite que ces algorithmes pourront être implémentés dans les wallets, éléments sécurisés et dispositifs de signature.
 

À ce jour, il n’existe pas de chemin de migration universellement accepté ni d’algorithme post-quantique standardisé par les grandes blockchains pour la signature des transactions courantes. L’industrie continue de rechercher, tester et débattre de la meilleure approche.
 

Tangem travaille activement dans cette direction, mais ce défi dépasse largement le seul secteur des hardware wallets. La même transition concernera les cartes bancaires, les cartes SIM, les éléments sécurisés, les documents d’identité, les objets connectés et bien d’autres systèmes critiques pour la sécurité.

Dans les prochaines années, on s’attend à une forte accélération de la cryptographie post-quantique, du support matériel sécurisé et des standards au niveau blockchain. Quand les réseaux seront prêts à supporter ces algorithmes, Tangem évoluera avec eux.

Le point clé est simple : la migration post-quantique est une transition à l’échelle de l’écosystème : d’abord les blockchains, puis les hardware wallets.

Le fil conducteur de chaque réponse reste le même argument que Tangem défend depuis le premier jour : la sécurité est une propriété de l’ensemble du système, pas d’une seule fonctionnalité. Moins de pièces mobiles, moins de confiance à accorder, moins de points de défaillance — et une mission critique réalisée à la perfection.