Trezor Suite : audit de code source GitHub – comment vérifier l’absence de backdoor et de dépendances malveillantes

Un développeur ou un auditeur de sécurité doit souvent répondre à une question fondamentale : comment vérifier qu’une application de gestion de portefeuille n’a pas été compromis au niveau du code source ? Trezor Suite, le logiciel officiel pour les portefeuilles matériels Trezor, est un projet open-source publié sur GitHub, mais la publication du code et l’absence réelle de portes dérobées sont deux choses différentes. Le défi technique consiste à établir une méthodologie d’audit qui ne dépend pas uniquement de la parole de SatoshiLabs, mais qui repose sur des vérifications reproductibles, des analyses de dépendances, et une compréhension précise de ce que chaque composant fait sur votre ordinateur.

Cet article détaille les étapes pratiques pour un auditeur technique : comment cloner le dépôt, vérifier l’intégrité des fichiers téléchargés, analyser les dépendances npm, examiner le code cryptographique critique, et construire le projet à partir des sources. Un portefeuille matériel comme Trezor isole les clés privées sur un appareil dédié, mais l’application de bureau qui communique avec ce matériel reste un vecteur d’attaque potentiel. Comprendre où le risque réside et comment le mesurer est essentiel pour les utilisateurs ou organisations qui demandent une assurance au-delà d’une simple promesse de transparence.

Pourquoi l’open-source ne suffit pas sans vérification active

Publier le code source d’une application de portefeuille n’élimine pas automatiquement le risque d’une compromission. Trois scénarios concrets l’illustrent. D’abord, le code publié sur GitHub peut différer du code compilé qui est distribué dans le fichier d’installation téléchargé. Ensuite, une dépendance externe (une bibliothèque tierce sur laquelle repose Trezor Suite) peut avoir été modifiée sans que SatoshiLabs n’en soit conscient. Troisièmement, même du code lisible peut contenir des logiques subtiles qui volent des données ou qui transmettent des informations critiques à un serveur tiers sans que l’intention soit immédiatement visible lors d’une lecture rapide.

La vérification cryptographique des fichiers téléchargés est donc une première ligne de défense. Trezor Suite utilise SHA256 pour les fichiers binaires et des signatures numériques pour certains artefacts. Une personne auditeur doit télécharger le fichier d’installation depuis trezor.io, calculer son hash SHA256, et le comparer avec la valeur publiée officiellement. Sur Linux ou macOS, la commande shasum -a 256 fichier ou sha256sum fichier produit un résultat qui doit correspondre exactement au hash annoncé. Si le résultat diverge, le fichier téléchargé a été modifié, soit en transit, soit à la source de distribution.

Cette vérification de hash ne prouve pas que le code source et le binaire correspondent. Elle prouve seulement que le fichier téléchargé n’a pas été altéré après la publication officielle. Pour aller plus loin, il faut compiler le projet à partir du code source disponible sur GitHub et vérifier que le résultat produit le même hash. C’est ce qu’on appelle la compilation reproductible. Si deux compilations indépendantes du même code source produisent des binaires identiques, il devient beaucoup plus difficile pour un attaquant de glisser du code malveillant sans le faire remarquer.

SatoshiLabs publie également les hashes attendus pour les binaires officiels, souvent accompagnés de signatures GPG. Récupérer la clé publique de SatoshiLabs depuis des canaux de confiance multiples (leur site web, les serveurs PGP publics, les comptes de réseau social vérifiés) et vérifier la signature avec gpg –verify fichier.sig fichier ajoute une couche supplémentaire. Si la signature est valide, le fichier a été signé par le titulaire de la clé privée correspondante. Si elle est invalide ou absente, il faut rejeter le fichier, indépendamment de sa provenance.

Clonage du dépôt et vérification de l’intégrité du code source

Le dépôt public de Trezor Suite est accessible sur GitHub. Un auditeur commence en clonant le projet : git clone https://github.com/trezor/trezor-suite.git. Cela télécharge l’intégralité de l’historique des commits, les branches, et les tags. La première vérification utile est de s’assurer que les commits principaux sont signés par des clés reconnues de SatoshiLabs. La commande git log –show-signature affiche si chaque commit porte une signature GPG valide. Un dépôt authentique devrait avoir au moins les commits récents signés par des clés de confiance.

La version stable est généralement marquée par un tag annoté, par exemple v2024.01. Pour basculer vers cette version, l’auditeur exécute git checkout v2024.01 et vérifie que le tag lui-même est signé : git tag -v v2024.01. Cette étape confirm que la version spécifique libérée a été approuvée par les responsables du projet. Les commits d’une branche non signée pourraient avoir été modifiés après coup, ou pire, ils pourraient provenir d’un dépôt bifurqué malveillant qui imite l’apparence du projet original.

Une fois sur la bonne version, l’auditeur examine la structure du projet. Trezor Suite est organisé en plusieurs domaines : la communication avec le matériel Trezor via USB, la gestion des comptes et des adresses, l’interface utilisateur, et les intégrations avec les blockchains. Le fichier package.json à la racine liste les dépendances du projet. C’est un document critique. Chaque dépendance est une opportunité pour un attaquant d’injecter du code compromis. Une dépendance avec peu de contributeurs, une maintenance inactive, ou une croissance soudaine du nombre d’installations peut être un signal d’alerte.

Analyse des dépendances npm et audit de la chaîne d’approvisionnement

Trezor Suite utilise npm pour gérer ses dépendances JavaScript. La commande npm ls affiche l’arborescence complète des dépendances, y compris les dépendances transitives (les dépendances des dépendances). Ce graphe peut devenir très profond. Pour un projet mature, cela représente parfois plusieurs centaines de paquets. Un attaquant qui compromet un seul paquet utilisé indirectement par Trezor Suite peut potentiellement affecter l’application sans jamais toucher au code de Trezor lui-même.

L’outil npm audit scanne les dépendances connues contre une base de données de vulnérabilités publiées. Mais cet outil ne détecte que les vulnérabilités déjà cataloguées. Il ne détecte pas un paquet compromis intentionnellement par un attaquant, un maintaineur malveillant, ou une injection de dépendance typographic (où un nom de paquet similaire à un paquet légitime est publié pour tromper les développeurs). Pour cette raison, un auditeur sérieux doit aussi exécuter npm ls et examiner manuellement les dépendances critiques.

Les dépendances sensibles à examinateur de près sont celles liées à la cryptographie, à la communication USB, à la vérification de signature, et à la gestion des clés. Pour chaque dépendance, il faut vérifier : l’auteur publié sur npm et sur GitHub ; la date de la dernière mise à jour ; le nombre et la nature des contributeurs ; la présence de tests automatisés ; et la conformité avec les bonnes pratiques de sécurité. Une dépendance cryptographique maintenue par une seule personne qui n’a pas de présence publique verifiable est un drapeau rouge. Un paquet qui a soudainement reçu une mise à jour volumineuse après des mois d’inactivité vaut une inspection minutieuse.

Les outils comme trezor suite incluent aussi des mécanismes internes de vérification. Mais l’audit de la chaîne d’approvisionnement reste un processus manuel. Une bonne pratique est de générer un fichier package-lock.json ou yarn.lock qui enregistre exactement quelle version de chaque dépendance a été testée et approuvée. Repéroder cette configuration permet à un auditeur de construire l’application avec les mêmes versions et de vérifier la reproductibilité du résultat.

Examen du code cryptographique et des mécanismes de communication

Les sections critiques du code Trezor Suite sont celles qui traitent la communication avec le matériel, la vérification de firmware, et la construction de transactions. Ces zones doivent être examinées ligne par ligne. La vérification de firmware cryptographique est particulièrement importante. Quand un utilisateur connecte son matériel Trezor, Trezor Suite vérifie que le firmware chargé sur l’appareil provient de SatoshiLabs et qu’il n’a pas été modifié. Cette vérification utilise SHA256 et des signatures numériques. Si cette vérification est contournée ou mal implémentée, un attaquant pourrait installer un firmware malveillant qui enregistre les clés privées.

Un auditeur examinerait le code responsable de cette vérification, par exemple dans les fichiers du répertoire packages/connect ou packages/transport. Les questions à poser sont : la signature est-elle vérifiée avant d’utiliser le firmware ? Les clés publiques utilisées pour la vérification sont-elles correctement enregistrées et protégées ? Y a-t-il un mécanisme permettant de contourner cette vérification en cas d’erreur ? La vérification examine-t-elle l’ensemble du firmware ou seulement une partie ?

La communication USB entre l’application de bureau et le matériel doit aussi être examinée. Trezor Suite envoie des commandes sérialisées au matériel et reçoit des réponses. Si un attaquant peut injecter des commandes malveillantes ou modifier les réponses en transit, le portefeuille pourrait être compromis. Heureusement, le matériel Trezor lui-même contient une logique de validation qui rejette les commandes non reconnues. Mais l’application de bureau doit aussi valider les réponses reçues et ne jamais supposer qu’une réponse est authentique sans vérification.

L’examen du code de construction de transactions est également essentiel. Avant de signer une transaction, l’utilisateur devrait voir exactement ce qu’il signe : l’adresse de destination, le montant, les frais. Si le code qui prépare cette affichage contient une logique de mise en cache incorrecte, une condition de concurrence, ou une injection SQL-like (pour les données JSON), l’utilisateur pourrait approuver une transaction différente de celle qu’il croit signer.

Construction du projet à partir des sources et vérification de reproductibilité

Une fois que l’auditeur a examiné le code source et les dépendances, l’étape suivante est de compiler le projet. Trezor Suite utilise typiquement Node.js et npm pour les builds. Les instructions de compilation sont documentées dans le fichier README.md ou dans un guide de contribution. Un build typique ressemble à : npm install, suivi par npm run build ou npm run build:desktop pour la version desktop.

La construction du projet génère généralement un répertoire de distribution contenant les fichiers compilés, les assets, et d’autres fichiers nécessaires pour la distribution. Pour la version desktop, cela inclut un fichier d’installation exécutable (par exemple, un fichier .exe pour Windows ou un .dmg pour macOS). Pour la version web, cela produit des fichiers HTML, JavaScript et CSS optimisés.

La reproductibilité exige que deux compilations indépendantes du même code source, sur des machines différentes ou à des moments différents, produisent des binaires identiques. Sur Linux, cela est plus réalisable car l’environnement est plus contrôlable. Sur Windows ou macOS, les outils de construction inclus et les versions des dépendances systèmes peuvent introduire des variations. Pour Trezor Suite, SatoshiLabs pourrait publier des instructions de compilation reproductible exactes, y compris les versions exactes de Node.js, npm, et tout autre outil requis. Un auditeur testerait ces instructions et comparerait le hash SHA256 du binaire obtenu avec le hash officiel.

Si les hashes correspondent, c’est une indication forte que le code source public et le binaire distribué sont sincères. Si les hashes diffèrent, cela signifie soit que la compilation n’est pas reproductible (un problème d’ingénierie, mais pas nécessairement de sécurité), soit que le code source public et le binaire officiels ne correspondent pas (un problème de sécurité grave). Dans ce dernier cas, l’auditeur doit enquêter sur la source de la divergence.

Vérification des certifications SSL et des canaux de distribution sécurisés

Trezor Suite, en tant que logiciel wallet officiel, empêche les attaques de phishing par vérification de certificat SSL. Quand l’application web accède à trezor.io ou à d’autres domaines de confiance, elle vérifie que le certificat présenté par le serveur est valide et émis pour le bon domaine. Un certificat expiré, auto-signé, ou émis pour un domaine différent déclencherait une erreur de vérification, et la connexion serait rejetée.

Un auditeur peut vérifier cela en examinant le code qui effectue les appels HTTPS et en confirmant que la vérification du certificat n’est pas désactivée (par exemple, par un flag insecureHTTPParser: true ou un paramètre rejectUnauthorized: false en production). Il faut aussi s’assurer que toutes les données sensibles transmises sur le réseau utilisent HTTPS et jamais HTTP en clair.

La distribution du logiciel Trezor Suite doit se faire exclusivement via trezor.io. Un fichier d’installation téléchargé à partir de tout autre endroit est potentiellement compromis. Les utilisateurs reçoivent souvent des conseils qui recommandent de toujours vérifier l’URL, de mettre en favori le site officiel, et de se méfier des emails ou de liens sociaux qui prétendent mener au téléchargement. Techniquement, cela signifie aussi que Trezor Suite doit enregistrer le domaine trezor.io sur un registre DNSSEC et utiliser une politique HSTS (HTTP Strict-Transport-Security) pour forcer les connexions HTTPS futures.

Absence de demande de phrase de récupération et validation des promesses de sécurité

Une promesse fondamentale d’un portefeuille matériel est que la phrase de récupération (seed phrase), qui permet de reconstruire les clés privées, ne doit jamais être affichée ou demandée par le logiciel sur un ordinateur. Trezor Suite respecte cette promesse en n’affichant jamais de champ de saisie texte demandant la phrase de récupération. Si une application prétend être Trezor Suite et affiche un champ demandant la phrase, c’est une tentative de phishing. Un auditeur confirme cette promesse en recherchant dans le code source tous les emplacements où une phrase de récupération pourrait être saisie ou affichée. Il ne devrait y en avoir aucun dans l’interface graphique de l’application desktop.

Au lieu de cela, quand un utilisateur doit restaurer un portefeuille, il utilise le matériel Trezor lui-même. L’appareil affiche une invitation à saisir la phrase sur son petit écran. Le matériel valide que la phrase est correcte et restaure les clés privées en interne, sans jamais les exposer à l’ordinateur. Trezor Suite reçoit ensuite l’information que la restauration a réussi, mais il ne voit jamais la phrase elle-même.

Cette séparation entre la gestion de la phrase (matériel) et la gestion des comptes (logiciel) est une architecture de sécurité fondamentale. Un auditeur doit vérifier que Trezor Suite ne contient aucun code qui pourrait contourner cette séparation, par exemple en tentant de saisir la phrase automatiquement ou en l’enregistrant quelque part. Une recherche de mots-clés comme „recovery“, „seed“, „mnemonic“ suivi d’une inspection du contexte devrait donner des résultats qui confirment que ces données ne sont jamais traitées de manière dangereuse.

Audit continu et mise à jour de la méthodologie

L’audit d’une application n’est pas un événement ponctuel. Trezor Suite reçoit des mises à jour régulières pour corriger des bugs, ajouter des fonctionnalités, et patcher des vulnérabilités. Chaque nouvelle version doit être auditée selon la même méthodologie. Les changements clés à examiner lors d’une mise à jour incluent : quelles dépendances ont changé, quelles fonctions cryptographiques ont été modifiées, et si de nouveaux serveurs ou domaines sont contactés.

Un audit continu peut être partiellement automatisé. Les outils d’analyse statique comme eslint, sonarqube, et les scanners de dépendances vulnérables peuvent fournir des alertes. Cependant, aucun outil automatisé ne peut détecter une intention malveillante subtile. Un attaquant sophistiqué cacherait une porte dérobée derrière du code qui, pris isolément, semble légitime. L’inspection humaine reste irremplaçable.

Pour les organismes qui dépendent fortement de Trezor Suite, une bonne pratique est de maintenir une liste de contrôle d’audit personnalisée basée sur les risques spécifiques. Cette liste capture les éléments critiques pour votre contexte : avez-vous besoin de compiler vous-même le logiciel ? Avez-vous besoin que toutes les dépendances proviennent de mainteneurs connus ? Y a-t-il des pays ou des juridictions où vous ne pouvez pas faire confiance aux certificats SSL ? La réponse à ces questions affine la méthodologie générale pour votre situation.