Un détenteur de Bitcoin en France souhaite gérer son portefeuille sans compromettre la sécurité de ses clés privées. Il télécharge Trezor Suite Web, connecte son appareil matériel, et voit immédiatement une question : comment ses données transitent-elles entre son ordinateur et les serveurs ? Qui pourrait accéder à ses transactions, ses adresses, ou ses soldes ? La réponse implique plusieurs couches de cryptographie que la plupart des utilisateurs ne voient jamais, mais qui forment la base de la confiance qu’on peut accorder à l’application.

Trezor Suite Web n’est pas une simple interface web traditionnelle. C’est une application construite autour d’une architecture où les données sensibles ne quittent jamais l’appareil matériel sans chiffrement, et où même SatoshiLabs, l’entreprise qui développe Trezor Suite Web, ne peut pas lire ce que l’utilisateur stocke. Cette distinction entre « avoir accès au serveur » et « pouvoir déchiffrer les données » est le cœur de la confidentialité moderne. Comprendre comment elle fonctionne exige d’examiner les protocoles cryptographiques utilisés, la façon dont les signatures numériques garantissent l’intégrité, et pourquoi le contrôle de la clé privée reste absolument à l’utilisateur.

L’architecture fondamentale : où réside vraiment le contrôle des clés

Trezor Suite Web fonctionne selon un principe d’isolation stricte. La clé privée, c’est-à-dire le secret mathématique qui autorise les transactions, ne quitte jamais l’appareil matériel Trezor. Pas une seule fois. Lorsqu’un utilisateur connecte son appareil à son ordinateur via USB, Trezor Suite Web crée un tunnel de communication bidirectionnel, mais ce tunnel ne transporte jamais la clé privée elle-même. Au lieu de cela, l’application envoie les données à signer vers l’appareil matériel, qui effectue le calcul cryptographique à l’intérieur de son environnement sécurisé, puis retourne uniquement la signature.

Cette architecture est l’inverse d’un portefeuille logiciel traditionnel, où la clé privée réside sur l’ordinateur, vulnérable aux malwares, aux enregistreurs de frappe, et aux captures d’écran. Avec Trezor Suite Web, l’ordinateur n’est qu’un intermédiaire. C’est comme envoyer un document important à notarier sans jamais lui confier l’original : vous recevez le document signé, mais le notaire n’a jamais eu la possibilité de le modifier ou de le conserver. La signature elle-même est produite par un calcul mathématique qui dépend de la clé privée sans la révéler.

Techniquement, cette séparation utilise une forme de cryptographie asymétrique. L’appareil matériel contient une paire de clés : une clé privée (secrète) et une clé publique (que tout le monde peut voir). Lorsqu’une transaction doit être signée, l’appareil utilise un algorithme tel que ECDSA (Elliptic Curve Digital Signature Algorithm) ou EdDSA pour générer une signature mathématiquement liée au secret, sans jamais exposer le secret lui-même. L’ordinateur et les serveurs ne voient que la signature, qui prouve que la transaction a été autorisée par le propriétaire de la clé privée, mais ne révèle rien sur la clé elle-même.

C’est cette séparation qui rend Trezor Suite Web différente d’une application web ordinaire. Même si les serveurs de Trezor étaient compromis, même si un attaquant en prenait le contrôle total, il ne pourrait pas accéder aux clés privées, car elles ne résident pas sur ces serveurs. Elles vivent exclusivement dans le microprogramme sécurisé de l’appareil matériel.

Le chiffrement des données en transit : protéger l’échange avec le serveur

Lorsque Trezor Suite Web communique avec les serveurs de Trezor pour récupérer les données du portefeuille—les adresses, les soldes, l’historique des transactions—cette communication traverse Internet. Sans chiffrement, n’importe quel observateur sur le réseau (un fournisseur d’accès, un gouvernement, un attaquant sur le réseau Wi-Fi local) pourrait voir quelles adresses Bitcoin l’utilisateur possède et combien il a reçu ou dépensé. C’est là que le chiffrement en transit intervient.

Trezor Suite Web utilise HTTPS (HTTP Secure), qui repose sur le protocole TLS 1.3, un standard de chiffrement moderne et approuvé. Lorsqu’une connexion HTTPS s’établit, le navigateur et le serveur exécutent un « handshake » cryptographique qui crée une clé de session partagée. Cette clé de session, que seul le navigateur et le serveur connaissent, chiffre ensuite tout ce qui transita entre eux. Un tiers qui observe le réseau ne voit que du bruit aléatoire, pas les données réelles.

Mais TLS seul n’est pas suffisant pour la confidentialité complète. Même en utilisant HTTPS, le serveur de Trezor sait quelles adresses l’utilisateur demande, car il doit traiter la requête pour récupérer les données correspondantes. C’est pourquoi Trezor Suite Web ajoute une couche supplémentaire : le chiffrement côté client. Avant que les données quittent l’ordinateur de l’utilisateur, l’application les chiffre localement en utilisant une clé dérivée du seed (la graine de récupération). Le serveur reçoit donc des données déjà chiffrées, qu’il stocke et transmet, mais qu’il ne peut pas lire. Lorsque l’utilisateur accède à ses données, elles sont déchiffrées localement, dans Trezor Suite Web elle-même.

Cette approche crée ce qu’on appelle le chiffrement bout en bout (end-to-end encryption). L’utilisateur et son appareil Trezor sont les deux « bouts ». Les serveurs et le réseau sont au milieu, transportant des données chiffrées sans jamais pouvoir les lire. Si SatoshiLabs reçoit une assignation gouvernementale exigeant d’accéder aux données des utilisateurs, les données qu’elle possède sont inutiles : elles sont chiffrées, et SatoshiLabs ne détient pas les clés de déchiffrement.

Hash verification et signatures numériques : garantir que rien n’a été altéré

Le téléchargement de Trezor Suite Web depuis trezor.io inclut une étape souvent ignorée : la vérification du SHA256. Un hash SHA256 est une empreinte numérique unique de 64 caractères hexadécimaux. Si un seul bit du fichier téléchargé change, le hash devient complètement différent. Lorsqu’un utilisateur télécharge Trezor Suite Web et vérifie manuellement son hash par rapport à la valeur publiée sur le site officiel, il s’assure qu’aucun attaquant n’a intercepté le fichier et n’y a injecté un malware.

Cette vérification n’est pas autorisée par un tiers de confiance. C’est une vérification mathématique : soit le hash correspond, soit il ne correspond pas. Aucune tromperie n’est possible si l’utilisateur compare avec la source officielle. En pratique, peu d’utilisateurs effectuent cette vérification manuellement, c’est pourquoi des systèmes de signature numérique jouent un rôle supplémentaire. SatoshiLabs signe numériquement ses fichiers à l’aide d’une clé privée. Toute personne qui télécharge le fichier peut vérifier que la signature est valide, sans avoir à faire confiance à SatoshiLabs pour l’affirmer—la mathématique cryptographique le prouve.

Cette même logique s’applique aux mises à jour du firmware de l’appareil Trezor. Chaque fois que l’utilisateur connecte son appareil à Trezor Suite Web, l’application vérifie automatiquement que le firmware stocké dans la mémoire de l’appareil n’a pas été modifié, endommagé, ou remplacé par une version malveillante. Si l’utilisateur est invité à mettre à jour, l’application télécharge le nouveau firmware, vérifie sa signature, puis envoie seulement les données chiffrées vers l’appareil. L’appareil, à son tour, valide la signature avant d’installer quoi que ce soit. Cette chaîne de vérifications rend un attaque silencieuse extrêmement difficile.

Ce système illustre un principe de sécurité : la confiance n’est jamais aveugle. Vous ne devez pas simplement croire que Trezor Suite Web est sûre. Vous pouvez le vérifier. Le code source est disponible sur GitHub. Les signatures cryptographiques de tous les fichiers officiels sont publiées. Chacun peut examiner le code, recompiler l’application, et vérifier que la version que vous téléchargez correspond exactement à ce qui a été examiné et signé par SatoshiLabs.

Seed phrase sécurité : pourquoi il ne doit jamais apparaître sur écran

La graine de récupération, ou seed phrase, est une liste de 12 ou 24 mots mnémoniques qui représentent la clé privée racine. Quiconque connaît ces mots peut accéder à tous les fonds. Trezor Suite Web n’affiche jamais cette phrase sur l’écran de l’ordinateur, c’est un design fondamental. Lorsqu’un nouvel utilisateur configure un appareil Trezor pour la première fois, c’est l’appareil lui-même qui génère la phrase, la stocke dans sa mémoire sécurisée, et l’affiche sur l’écran minuscule de l’appareil matériel.

Cette séparation du contexte est déterminante. Un écran d’ordinateur peut être observé par un logiciel malveillant, enregistré par un trojan, ou capturé par une caméra cachée. L’écran de l’appareil Trezor, en revanche, est physiquement isolé. Aucun logiciel sur l’ordinateur n’y a accès. Un attaquant devrait être physiquement présent dans la pièce avec vous pour voir la phrase, ou avoir accès à l’appareil lui-même avant sa configuration. Ce contraste crée une assurance asymétrique : tout ce qui dépend de l’écran de l’ordinateur est suspect, tout ce qui dépend de l’écran de l’appareil est de facto beaucoup plus sûr.

Même lorsque l’utilisateur entre son code PIN pour accéder à l’appareil, ce code n’est jamais visible sur l’écran de l’ordinateur. L’écran de l’appareil affiche un clavier de saisie brouillé, et l’utilisateur appuie sur les boutons de l’appareil pour composer le PIN. L’ordinateur, qui reçoit les appuis de boutons via USB, ne sait pas quel PIN a été entré, car les appuis sont aléatoires à chaque tentative. De cette façon, même un malware ayant un accès complet à l’ordinateur ne peut pas intercepter le PIN.

C’est là que réside la vraie raison pour laquelle Trezor Suite Web est sûre pour l’accès quotidien : elle n’attend jamais de l’utilisateur qu’il expose son secret le plus critique sur un appareil potentiellement compromis. Chaque action sensible—signer une transaction, entrer le PIN, récupérer la phrase—met en avant l’appareil matériel et relègue l’ordinateur au rôle d’affichage et d’interface utilisateur. L’ordinateur est un outil, pas un coffre-fort.

Cryptographie du portefeuille : dérivation hiérarchique des clés

Trezor Suite Web ne gère pas une seule clé privée. Il gère des centaines ou des milliers de clés, dérivées hiérarchiquement d’une clé maître unique. Ce système, appelé BIP32 (Bitcoin Improvement Proposal 32), permet de générer une arborescence de clés à partir d’une seule graine, sans jamais exposer la graine elle-même. Chaque adresse Bitcoin que l’utilisateur reçoit a sa propre clé privée, dérivée mathématiquement de la clé maître, mais le serveur de Trezor et Trezor Suite Web ne voient que les clés publiques correspondantes.

Cette cryptographie du portefeuille hiérarchique crée plusieurs avantages. Premièrement, l’utilisateur peut créer de nouveaux portefeuilles à partir de la même graine sur différents appareils, et ils auront exactement les mêmes clés et les mêmes soldes. Deuxièmement, l’utilisateur peut partager une clé de vue (ou « master public key ») avec une application qui n’a jamais besoin de connaître les clés privées, mais qui peut quand même surveiller les soldes et valider les paiements reçus. Troisièmement, si une clé privée (correspondant à une adresse) était hypothétiquement compromise, cela n’affecterait que cette adresse spécifique, pas toutes les autres.

L’algorithme utilisé pour cette dérivation suit un standard mathématique précis. Chaque clé enfant est dérivée de sa clé parent en utilisant un algorithme de hachage HMAC-SHA512, imprégné d’une valeur d’index. Bien que ce processus implique du hachage (une fonction à sens unique), il existe une relation mathématique robuste : connaître les clés publiques enfants ne permet pas de déduire la clé publique parent ou la clé privée parent. Cette propriété, appelée hardened derivation dans les cas où la clé privée parent est impliquée, protège la hiérarchie contre un attaquant qui aurait accès à certaines clés publiques.

Lorsqu’un utilisateur importe ou restaure un portefeuille en utilisant une seed phrase, Trezor Suite Web n’a pas à stocker des milliers de clés privées. Il dérive chaque clé à la volée, à partir de la graine, chaque fois qu’elle est nécessaire. Cela signifie que l’application peut recréer le portefeuille complet à partir de la seule seed phrase, mais la phrase n’est jamais stockée ou exposée dans l’application elle-même.

Vérification des adresses sur l’appareil : prévenir le détournement

Imagine un attaquant qui a réussi à installer un malware dans Trezor Suite Web, ou qui contrôle le réseau entre l’ordinateur et le serveur Trezor. Cet attaquant pourrait modifier l’adresse affichée à l’écran, incitant l’utilisateur à envoyer des Bitcoin à une adresse contrôlée par l’attaquant au lieu de l’adresse légitime. C’est un vecteur d’attaque classique appelé « address substitution » ou « man-in-the-middle ».

Pour prévenir cela, Trezor Suite Web offre une fonctionnalité critique : la vérification des adresses sur l’appareil. Lorsque l’utilisateur demande à recevoir des Bitcoin sur une adresse spécifique, l’appareil Trezor affiche cette adresse sur son écran, indépendamment de ce que l’ordinateur dit. L’utilisateur doit confirmer que l’adresse affichée sur l’appareil correspond à celle affichée sur l’écran de l’ordinateur. Seul en cas de correspondance, l’appareil accepte les paiements à cette adresse. De même, lorsque l’utilisateur dépense, l’adresse de destination s’affiche sur l’écran de l’appareil, et l’utilisateur doit l’approuver en appuyant sur les boutons de l’appareil.

Cette vérification double écran est un exemple de authentification multifacteur appliquée à la cryptographie. Même si un attaquant contrôle l’ordinateur, il devrait aussi modifier l’écran de l’appareil (qui n’est pas connecté à Internet et fonctionne sur un microprogramme signé cryptographiquement) pour tromper l’utilisateur. C’est pratiquement impossible. Ce mécanisme transforme l’appareil de simple cryptographe en arbitre indépendant de la transaction.

Intégrité de l’application et vérifications de sécurité continues

Trezor Suite Web est distribuée sous une forme que les utilisateurs peuvent examiner. Le code source complet est publié sur GitHub, ce qui permet aux chercheurs en sécurité de l’auditer. Cela ne signifie pas que le code est parfait—tout logiciel peut contenir des bogues—mais cela signifie que les bogues cachés sont plus difficiles à introduire intentionnellement. Une organisation malveillante qui essaierait de publier une version modifiée de Trezor Suite Web serait rapidement identifiée par des comparaisons de code et de signature numérique.

À chaque démarrage, Trezor Suite Web vérifie son propre intégrité et celle de l’appareil Trezor connecté. Les signatures numériques des fichiers d’application et du firmware sont validées avant que le code ne s’exécute. Cette vérification automatique d’intégrité est complètement transparente pour l’utilisateur, mais elle joue un rôle de pare-feu silencieux. Si une version modifiée du microprogramme tente de démarrer, l’appareil la rejettera. Si l’application a été altérée, la signature échouera et l’application refusera de fonctionner.

Les utilisateurs peuvent également activer des fonctionnalités de sécurité avancées telles que l’authentification multifacteur, les code passphrase supplémentaires, ou la configuration d’une phrase de passe BIP39. Cette phrase de passe, qui est différente de la seed phrase, s’ajoute à la graine pour dériver une seconde arborescence de clés complètement différente. Même si quelqu’un connaissait la seed phrase de l’utilisateur, il ne pourrait pas accéder aux fonds protégés par la phrase de passe sans la connaître aussi. C’est une couche de dénégation plausible : l’utilisateur peut avoir un portefeuille apparent (sans phrase de passe) contenant une petite quantité, et un portefeuille caché (avec phrase de passe) contenant les véritables économies.

Limitations et points de confiance résiduels

Aucun système n’est sans limites. Trezor Suite Web repose sur plusieurs hypothèses qui, si elles échouent, pourraient compromettre la sécurité. Premièrement, l’utilisateur doit télécharger l’application depuis le site officiel trezor.io et vérifier le hash ou la signature. Si l’utilisateur télécharge une version contrefaite depuis un site piraté ou un lien de phishing, la cryptographie ne l’aidera pas. Deuxièmement, l’appareil Trezor lui-même doit être authentique. SatoshiLabs vend par des canaux agréés pour réduire ce risque, mais un utilisateur qui achète sur un site de tiers pourrait recevoir un appareil contrefait.

Troisièmement, bien que Trezor Suite Web n’affiche jamais la seed phrase sur écran, l’utilisateur doit stocker cette phrase en toute sécurité. Si la seed phrase est écrite sur un papier laissé sur un bureau, photographiée, ou envoyée par email, elle est compromise, peu importe la force de la cryptographie. Quatrièmement, l’interface utilisateur entre l’ordinateur et l’appareil, qui est en USB, pourrait hypothétiquement être exploitée par un malware extérieur ordinaire—bien que Trezor Suite Web et l’appareil incluent des vérifications pour minimiser ce risque.

Enfin, la confiance dans SatoshiLabs elle-même demeure un facteur. Trezor Suite Web repose sur des serveurs de Trezor pour fournir les données de blockchain. Si ces serveurs sont compromis, un attaquant pourrait potentiellement servir des données falsifiées concernant les soldes ou les transactions. Pour atténuer cela, les utilisateurs avancés peuvent configurer leurs propres nœuds Bitcoin ou Ethereum et les connecter à Trezor Suite Web, éliminant la dépendance à l’égard des serveurs Trezor. Cette option existe précisément parce que la cryptographie, tout en étant puissante, ne résout pas tous les problèmes de confiance organisationnelle.