Andrey Lazutkin (Tangem) : plaidoyer pour la simplicité des hardware

Le marketing des hardware wallets va généralement dans un seul sens : toujours plus de fonctionnalités, d’écrans, de connectivité, de mises à jour logicielles. Tangem a fait le pari inverse pour l’ensemble de sa gamme.
 

Il n’y a ni écran, ni batterie, ni connectivité USB ou Bluetooth, ni firmware modifiable, ni seed phrase à noter. Pour beaucoup dans la communauté sécurité, cela pourrait sembler la liste des fonctions attendues d’un wallet crypto ; en réalité, c’est une liste de fonctionnalités volontairement absentes.
 

Yellow Media a rencontré 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 vous ne pourrez jamais mettre à jour ? 
• Comment Tangem Ring résiste-t-il à une attaque NFC dans un train bondé ? 
• Et que se passera-t-il avec l’arrivée du quantique ?

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

Un principe central des hardware wallets traditionnels est « ce que vous voyez est ce que vous signez » : un écran intégré qui permet à l’utilisateur de vérifier les détails de la transaction. Tangem, lui, fait le choix du sans écran et confie toute l’interface au smartphone. 

Si un téléphone est infecté par un malware qui modifie ce qui s’affiche, un utilisateur pourrait autoriser à son insu un transfert NFC malveillant. Comment votre architecture protège-t-elle contre la falsification d’interface sur un appareil compromis ?

Un écran n’est pas un modèle de sécurité en soi. Ce n’est qu’un composant parmi d’autres. Or, chaque composant supplémentaire augmente la surface d’attaque : logique d’affichage, boutons, firmware, mécanismes de mise à jour, USB, Bluetooth, batteries, pilotes, parseurs, interfaces physiques.

Internet regorge d’exemples où des hardware wallets ont été compromis non pas par une faille cryptographique, mais à cause de la complexité de leur implémentation.

Tangem adopte la philosophie opposée : 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é est un atout majeur pour la sécurité.

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

• contrôles d’intégrité à l’exécution,
• anti-debug,
• anti-émulation,
• détection root et 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 minimales, une revue de code, des audits et des contrôles de sécurité automatisés.
 

Nous ne résumons donc pas la sécurité à la question « écran ou pas d’écran ». C’est l’architecture globale qui compte. Tangem réduit la surface d’attaque côté 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 une carte qui fait très peu, mais le fait parfaitement : protéger la clé et signer en toute sécurité.

Pourquoi la carte ne pourra jamais être patchée

Votre firmware est gravé 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 une vulnérabilité cryptographique apparaît plus tard sur ce lot de puces, l’utilisateur ne pourra pas corriger. Pourquoi un composant totalement non modifiable est-il plus sûr pour l’auto-garde à long terme qu’un composant patchable ?

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

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é, ses décisions futures. Même si tout est conçu correctement, toute cette infrastructure devient partie intégrante 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, pressions réglementaires, mises à jour accidentelles ou futures modifications du firmware qui affaiblissent le modèle de sécurité initial.

La controverse Ledger Recover l’a bien illustré. Le support Ledger a écrit dans un post (supprimé depuis) : « Technically speaking, it is and always has been possible to write firmware that facilitates key extraction. You have always trusted Ledger not to deploy such firmware, whether you knew it or not. » C’est précisément cette hypothèse de confiance que Tangem supprime.
 

Tangem fait le choix de l’immutabilité. Notre firmware est gravé lors de la fabrication et ne peut plus être modifié ensuite. Il n’y a pas de mise à jour OTA, pas de flash USB, pas de voie de mise à jour sans fil, et aucun moyen pour Tangem d’injecter du code une fois la carte entre les mains de l’utilisateur.

Oui, cela signifie que nous ne pouvons pas corriger une puce à distance si une faille matérielle est découverte plus tard. Mais un appareil modifiable ne supprime pas le risque : il en crée un autre, permanent : la possibilité de changer le code critique pour la sécurité après coup.

Pour l’auto-garde à 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 la durée. La philosophie 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 stores d’applications

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 poussait une mise à jour malveillante avant que votre équipe ne la détecte, quelles protections natives du composant 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 la MFA et les contrôles d’accès internes, franchir le processus de validation de publication, injecter du code malveillant dans la version officielle, passer la revue Apple ou Google, conserver l’identité 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 vulnérabilité, mais une cascade d’échecs sur plusieurs couches de sécurité indépendantes. C’est exactement ce que j’entends quand je dis que la sécurité doit s’évaluer dans son ensemble, et non sur une 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, notamment celles qui dépendent de mises à jour de firmware pour rester sûres 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 de processus de confiance. Chacune de ces couches ouvre de nouvelles surfaces d’attaque : attaques supply-chain, interfaces de débogage, bugs firmware, mises à jour compromises, fuites de clés de signature, compromission du système de build, ou pression du fournisseur pour modifier le comportement de l’appareil après livraison.
 

L’historique des attaques sur les hardware wallets est clair : 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 supply-chain ou interactions inattendues entre composants.

Une mise à jour malveillante via un store reste un risque théorique. Mais elle nécessite une chaîne d’échecs indépendants avant que l’attaquant n’atteigne l’utilisateur. Un code source modifiable en permanence, au contraire, 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é de Tangem : minimiser le nombre de composants de confiance, réduire la surface d’attaque, et rendre l’appareil de signature immuable.

Backup 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 l’initialisation. Cela élimine le point de défaillance unique du papier, mais crée une dépendance physique : si vous perdez toutes vos cartes de backup, la récupération devient impossible. Comment ce modèle purement matériel s’adapte-t-il à l’héritage ou à la transmission sur plusieurs générations, face aux standards papier BIP-39 ?

Quand on achète un hardware wallet, on attend qu’il protège la clé privée. Mais dans de nombreux wallets classiques, l’appareil affiche d’abord la seed phrase puis transfère la responsabilité à l’utilisateur.
 

À partir de ce moment, le maillon faible n’est plus le wallet matériel, mais la seed phrase : un bout de papier, une plaque métallique, un tiroir, un coffre, une photo qu’il ne faudrait jamais prendre, ou une phrase qui peut être perdue, endommagé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 crypto. Chainalysis estime que des millions de bitcoins sont définitivement perdus. Les attaques de phishing ciblent aussi directement les seed phrases, car une fois la phrase exposée, le prix ou le niveau de sécurité du hardware wallet n’a plus d’importance.
 

Dans le modèle traditionnel, on dispose d’un wallet matériel et d’une seed phrase. On peut faire des copies de la phrase, mais chaque copie augmente le risque, car elles ne sont pas protégées par du matériel. L’utilisateur doit inventer son propre système de sécurité.
 

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

Pour l’héritage ou la conservation à long terme, 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 : c’est la vraie auto-garde. Tangem supprime ainsi le maillon le plus fragile du modèle classique : la seed phrase exposée.
 

Si la clé privée mérite d’être protégée par un hardware wallet, 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 principaux vecteurs de vidage des wallets. Votre application intègre la simulation de transaction et la détection de scams dApps pour montrer à l’utilisateur ce qu’un contrat va exécuter. 

Mais vu la complexité des smart contracts multi-hop et la nature Turing-complete, une simulation côté client peut-elle vraiment être fiable à 100 % ? Ou risque-t-elle de donner un faux sentiment de sécurité absolue ?

Excellente question, car vous employez l’expression clé « sécurité absolue ».

La réponse honnête est non. Aucun wallet, moteur de simulation, appareil matériel ou société de sécurité ne peut promettre la 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 maillon faible n’est pas là où on l’attend. Il existe des cas publics où les données clients issues d’achats de hardware wallets ont été exposées. Dans ces situations, le problème ne venait pas forcément de la cryptographie ou du matériel, mais du périmètre de sécurité global : phishing, ingénierie sociale, faux supports, faux appareils de remplacement, pressions ciblées.
 

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

Mais la simulation peut-elle garantir à 100 % la fiabilité sur tous les smart contracts ? Non. La complexité des contrats, les routes multi-hop, l’état on-chain évolutif, les front-ends malicieux, les domaines de phishing, l’ingénierie sociale font que l’utilisateur doit toujours vérifier où 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 supplémentaire qui améliore considérablement la visibilité avant signature. Elle aide à comprendre ce qu’une transaction va probablement faire, à détecter les scams plus tôt, et à éviter les validations à l’aveugle.

L’état d’esprit à adopter : Tangem protège la clé par le matériel, réduit la surface d’attaque avec une carte simple et immuable, et ajoute une protection DeFi moderne dans l’application. Mais l’utilisateur doit continuer à utiliser des 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é forte repose sur la défense en profondeur : c’est exactement l’approche Tangem.
 

Payer le gas en stablecoins sans perdre 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 du réseau. Techniquement, contourner le mécanisme gas natif implique souvent des relayers d’abstraction de compte ou de la liquidité tierce. 

Est-ce que ces fonctions de confort introduisent 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 en certains tokens ERC-20 au lieu de détenir le token gas natif. Cela ne modifie pas le modèle de garde : 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 entièrement open source sur GitHub, en accord avec la philosophie communautaire « Don’t Trust, Verify ». Mais l’élément sécurisé EAL6+ dans les cartes repose sur une architecture propriétaire et fermée, développée par les fabricants de puces. 

Comment conciliez-vous la philosophie open source de la DeFi avec une base matérielle qui impose de faire confiance à une conception fermée d’un fondeur ?
 

L’open source est essentiel, mais affirmer que chaque couche d’un produit hardware sécurisé doit l’être relève d’une incompréhension de la sécurité matérielle.
 

Pour un élément sécurisé, un firmware bas niveau fermé et des circuits internes non publics ne sont pas un défaut, mais une 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, sondes, glitchs, attaques laser et autres techniques de laboratoire. Publier des détails sur le comportement interne du firmware, l’organisation mémoire, les capteurs, les contre-mesures ou la logique de détection de faute ne rendrait pas l’utilisateur plus sûr : cela donnerait une carte aux attaquants.
 

Ce n’est pas une naïve « sécurité par l’obscurité ». La vraie sécurité matérielle repose sur la défense en profondeur : é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 inutilement des détails d’implémentation bas niveau qui faciliteraient les attaques physiques.

Et soyons honnêtes : même quand quelqu’un prétend publier un « firmware open source », la puce sécurisée elle-même ne l’est jamais totalement. Elle contient de la logique matérielle, du 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 vérifier entièrement la racine matérielle de confiance parce qu’une partie du code firmware est publiée est trompeur.

Notre modèle de sécurité : « fermer ce qui aiderait les attaquants, faire auditer ce qui exige la confiance, et rester aussi minimaliste que possible ».

Le hardware dans l’espace public : Tangem Ring

Avec le développement de Tangem Ring, le hardware sort de la carte pour entrer dans les objets connectés portés au quotidien. Quelles mesures protègent l’utilisateur face à un adversaire qui utiliserait un lecteur NFC amplifié dans un lieu bondé pour tenter des handshakes non autorisés ou des attaques par force brute sur le 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 la foule n’est pas réaliste au quotidien.

Il y a aussi un aspect pratique : Tangem Ring ressemble à un accessoire connecté classique, comme une bague de paiement ou un autre objet du quotidien. Un attaquant devrait d’abord identifier que la personne porte un wallet crypto, et non une simple bague.

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

La force brute n’est pas non plus réaliste. L’appareil protège contre les tentatives répétées : après plusieurs codes erronés, le délai entre essais augmente, rendant le brute force automatisé impossible.

Le modèle de sécurité est simple : la proximité NFC ne suffit pas, la présence physique non plus, et deviner le code d’accès n’est pas un vecteur réaliste. L’utilisateur peut porter Tangem Ring en public sans crainte.

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

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

D’abord, il faut bien distinguer l’architecture de l’appareil et 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 la clé et signe à la demande de l’utilisateur.
 

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

Concernant la régulation, il faut rester réaliste : forcer les wallets d’auto-garde à intégrer des mécanismes de contrôle dans la couche de signature serait un mauvais choix. Il existe de nombreux wallets gratuits, open source, forks, solutions alternatives. Si les régulateurs poussent les utilisateurs hors des produits sûrs et audités, beaucoup iront vers des alternatives moins transparentes et moins sûres. Cela augmenterait les pertes, les scams et l’activité souterraine, au lieu de les réduire.
 

Ce qu’on observe déjà à l’échelle mondiale, c’est une autre tendance : les régulateurs ciblent les points de contact avec les services régulés : exchanges, on-ramps, off-ramps, produits de paiement, intermédiaires financiers. C’est là que s’appliquent KYC, AML, contrôles de sanctions et obligations de reporting.
 

Si certains pays exigent des flux conformes pour des services spécifiques, Tangem peut aider l’utilisateur à rester conforme dans ces usages. Mais cela n’a rien à voir avec l’idée de transformer le hardware wallet lui-même en appareil à autorisation.
 

Notre position est claire : Tangem peut faciliter l’accès conforme à des services régulés, mais le cœur de l’auto-garde doit rester l’auto-garde. La carte protège la clé. L’utilisateur contrôle ses fonds. Tangem ne détient pas les actifs, ne contrôle pas la clé privée, et n’a pas d’interrupteur à distance pour décider si l’utilisateur a le droit de signer.
 

La question quantique

La grande majorité des hardware wallets, dont Tangem, reposent sur la cryptographie à courbe elliptique ECDSA ou Ed25519. Avec l’accélération du quantique, quelle vulnérabilité pour des puces à firmware figé face à la décryption quantique, et quel est votre plan de transition vers la cryptographie post-quantique pour les cartes physiques existantes ?
 

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

Les hardware wallets ne définissent pas les algorithmes de signature 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 mis en œuvre dans les wallets, éléments sécurisés et appareils de signature.
 

Aujourd’hui, 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 poursuit ses recherches, ses tests et ses débats pour trouver la bonne 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 cartes bancaires, cartes SIM, éléments sécurisés, documents d’identité, objets connectés et bien d’autres systèmes critiques pour la sécurité.

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

L’essentiel 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 : la sécurité est une propriété du système global, pas d’une seule fonctionnalité. Moins de points de défaillance, moins de confiance à accorder, moins de risques de casse, et une mission critique exécutée à la perfection.