Audit de sécurité interne : Reproduire les tests du GitHub open source Trezor Suite chez soi

Un développeur ou auditeur indépendant souhaite valider que Trezor Suite, l’application de gestion de portefeuille cryptographique de SatoshiLabs, ne contient pas de backdoor logiciel ou de modification non autorisée. Le seul moyen fiable de le vérifier n’est pas de faire confiance à une affirmation publicitaire, mais de compiler soi-même le code source, d’examiner les dépendances, et de reproduire les contrôles de sécurité qu’un auditeur professionnel effectuerait. Cette approche exige une connaissance technique des outils de développement, de la gestion des dépendances Node.js, et de la cryptographie appliquée, mais elle offre une garantie qui n’existe nulle part ailleurs.

Trezor Suite est distribué sur plusieurs canaux : desktop, web et mobile. Le code open source du portefeuille cryptographique est publié sur GitHub, et chaque version de firmware peut être vérifiée par hachage SHA256. SatoshiLabs fournit également une vérification cryptographique de l’intégrité du firmware à chaque connexion du dispositif, une étape devenue standard depuis la version 24.11.2. Pour un auditeur ou un développeur qui ne veut pas dépendre uniquement de la confiance envers un tiers, les étapes suivantes décrivent comment cloner le référentiel, identifier les points critiques de sécurité, compiler localement, et valider l’absence de modifications malveillantes dans la chaîne de construction.

Établir un environnement d’audit isolé et reproductible

Avant de télécharger ou d’examiner du code, l’auditeur doit disposer d’une machine dédiée, de préférence sans accès réseau direct aux services sensibles. Une machine virtuelle ou un conteneur Docker offre une isolation : les modifications malveillantes découvertes lors de la compilation ne peuvent pas contaminer le reste du système. SatoshiLabs publie ses instructions de construction sur le dépôt GitHub officiel, et un auditeur doit commencer par télécharger les outils de développement pertinents : Node.js dans une version spécifiée (généralement LTS), npm ou yarn pour la gestion des dépendances, et les compilateurs C/C++ pour les modules natifs.

La version de Node.js est cruciale. Une version obsolète peut contenir des vulnérabilités connues ; une version trop nouvelle peut introduire des incompatibilités. Le fichier .nvmrc (Node Version Manager) ou le fichier package.json précise la version attendue. Un auditeur doit d’abord vérifier cette spécification dans le dépôt cloné, puis utiliser nvm (ou un gestionnaire de version équivalent) pour installer exactement cette version. Une déviation apparemment mineure peut masquer une injection de dépendance.

Ensuite, configurez un gestionnaire de cache npm isolé. Par défaut, npm télécharge les dépendances à partir du registre public npm.js ou d’autres sources réseau. Un auditeur paranoia peut vouloir utiliser un cache local ou inspectionner chaque dépendance avant son installation. Le fichier package-lock.json enregistre les versions exactes et les hachages SHA512 de chaque dépendance ; la comparaison avec le commit public permet de déterminer si quelque chose a changé depuis la publication officielle. Enfin, documentez l’état exact de la machine : versions de l’OS, outils installés, et toute variable d’environnement qui pourrait affecter la compilation.

Cloner et vérifier l’intégrité du référentiel

Cloner depuis GitHub public exige un premier acte de confiance : supposer que le lien https://github.com/trezor/trezor-suite est le vrai dépôt et non une version usurpée. Une protection partielle consiste à vérifier le certificat SSL utilisé par GitHub et à confirmer que le domaine github.com est authentique. Un auditeur ne devrait jamais cloner depuis un raccourci ou un lien recourtissement sans vérifier la destination complète.

Une fois cloné, les commits du dépôt sont signés cryptographiquement par les développeurs de SatoshiLabs qui possèdent des clés GPG publiques vérifiables. L’auditeur peut télécharger la clé GPG publique du contributeur principal depuis un serveur de clés public ou depuis le profil GitHub vérifié. Puis, exécutez git log –show-signature pour afficher les signatures de commit. Une signature valide indique que le commit n’a pas été modifié après signature. Une signature manquante ou invalide est un signal d’alarme : le commit peut avoir été altéré ou ajouté par un acteur non autorisé.

Vérifiez également l’historique des tags. Les versions de release officielle sont souvent taguées et signées. Comparez le tag actuel avec la version downloadée depuis the official trezor site : les numéros de version doivent correspondre exactement. Une version taguée v24.11.2 ne doit contenir aucun code différent de la version téléchargée. Ensuite, comparez le hash SHA256 du commit taggé avec le hash connu publié par SatoshiLabs. Cette étape transforme un acte de confiance en un fait cryptographique vérifiable.

Auditer les dépendances critiques et les points d’injection

Le fichier package.json liste les dépendances directes. Chacune a elle-même des dépendances (arbres de dépendance), formant un graphe qui peut contenir des centaines ou des milliers de paquets. Un auditeur ne peut pas examiner chaque ligne de code, mais peut se concentrer sur les couches les plus sensibles : la génération de clés, l’interaction hardware, la signature des transactions et la gestion des mots de passe.

Les modules critiques incluent généralement libsodium (cryptographie), HID (interface de périphérique), et les bindings pour le Trezor lui-même. Chacun doit être un module public bien connu, avec un historique de maintenance actif et un audit de sécurité connu. Les modules obscurs, récemment publiés, ou contrôlés par un compte npm nouvellement créé méritent un examen minutieux, voire un rejet. Utilisez npm audit pour identifier les vulnérabilités connues dans l’arborescence des dépendances.

Un point d’injection classique est une dépendance en typosquattage : un paquet nommé libsodium au lieu de libsodium.js, ou treazor-bridge au lieu de trezor-bridge. Inspectez le fichier package-lock.json pour confirmer que l’URL exacte du registre npm pour chaque dépendance est correcte. Une URL modifiée pointant vers un registre privé ou un serveur compromis serait catastrophique. Enfin, examinez les scripts npm : les champs preinstall, postinstall, et build dans package.json peuvent exécuter du code arbitraire. Tout script devrait être transparent et compréhensible ; les scripts qui téléchargent des exécutables ou modifient le système de fichiers en dehors du répertoire du projet doivent être considérés avec suspicion.

Compiler et reproduire les binaires officiels

Une fois les dépendances vérifiées, exécutez la commande de compilation locale. Pour Trezor Suite, cela implique généralement npm install suivi de npm run build. Une compilation reproductible signifie que le même code source, compilé sur deux machines différentes avec les mêmes outils, produit un binaire identique (octet par octet). C’est un ideal rarement atteint en pratique, mais SatoshiLabs fournit un Dockerfile et des instructions de construction destinées à faciliter la reproductibilité.

Après la compilation, comparez le hash SHA256 du binaire compilé localement avec le hash du binaire officiel téléchargé. Si les hashes correspondent, le code source public contient effectivement le code que vous avez compilé. Si les hashes diffèrent, il existe trois explications possibles : (1) les outils de compilation locaux diffèrent légèrement des outils officiels, ce qui crée une variation de construction même si le code source est identique, (2) le code source du dépôt public a été modifié depuis la release officielle, ou (3) le binaire officiel contient du code supplémentaire qui n’est pas publié. Les deux derniers cas sont graves.

Pour une reproductibilité plus rigoureuse, SatoshiLabs publie un Dockerfile documentant l’environnement de construction exact. Clonez ce fichier, construisez l’image Docker, puis compilez à l’intérieur du conteneur. Cela élimine les variations dues aux différences de l’OS ou des versions des outils. Documentez le hash du fichier SHA256 de chaque étape et comparez le résultat final avec la release officielle. Si le hash peut être reproduit, vous avez une preuve cryptographique que le binaire officiel provient du code source public.

Valider la vérification du firmware et l’intégrité du dispositif

Trezor Suite ne se limite pas à l’application logicielle de bureau ; elle communique avec un dispositif matériel qui exécute son propre firmware. Le firmware doit être mis à jour uniquement à partir de sources officielles et vérifiées avant installation. À partir de la version 24.11.2, Trezor Suite effectue une vérification cryptographique de l’intégrité du firmware à chaque connexion du dispositif. Un auditeur doit valider le code source de cette vérification.

Le processus de vérification implique de comparer le hash SHA256 du firmware installé sur le périphérique avec une liste de hashes publiée et signée par SatoshiLabs. Le firmware officiel pour Model One, Model T, Safe 3 et Safe 5 doit correspondre à un hash attendu connu. Cette étape empêche l’installation accidentelle ou malveillante d’un firmware compromis. Un auditeur doit examiner le code qui effectue cette vérification : existe-t-il une porte de secours qui contourne la vérification ? Le message d’erreur en cas d’échec est-il clair ? Le dispositif refuse-t-il catégoriquement d’interagir avec un firmware non vérifié ?

Consultez également le code source de gestion des mises à jour du firmware. SatoshiLabs publie les mises à jour uniquement sur ses serveurs officiels ; Trezor Suite ne doit jamais accepter une mise à jour du firmware à partir d’une autre source. Vérifiez que les URLs sont en dur ou proviennent d’un fichier de configuration officiel, et que les empreintes digitales TLS des serveurs de mise à jour sont correctes. Une mise à jour de firmware compromise, même si elle se présente comme légitime, pourrait voler des clés privées ou modifier le comportement de signature des transactions.

Inspecter la gestion des clés privées et les interactions hardware

Le secret fondamental qui doit être protégé est la clé privée. Trezor Suite doit jamais demander à l’utilisateur de saisir la phrase de récupération (seed) sur l’ordinateur. La seed ne doit exister que sur le périphérique Trezor, de préférence jamais sur un système connecté au réseau. Un auditeur doit vérifier que l’application contient un refus explicite d’accepter une seed tapée, importée ou copiée depuis le presse-papiers.

Examinez le protocole de communication entre Trezor Suite et le dispositif matériel. La bibliothèque trezor-connect ou le bridge correspondant doit utiliser HID (Human Interface Device) pour la communication USB ou une connexion bridge sécurisée pour les appareils mobiles. Chaque message doit être chiffré et authenticité vérifiée si le protocole le prévoit. Recherchez des appels système qui semblent sortir de portée : des tentatives de lecture du système de fichiers, des connexions réseau non documentées, ou des interfaces de debugging activées en mode production.

Un développeur malveillant pourrait aussi transformer l’application en enregistreur de frappe (keylogger) passif : même si elle n’accepte pas la seed directement, elle pourrait surveiller les événements clavier globaux. Inspectez tout code utilisant des hooks de système, des packages comme node-global-keyboard-listener, ou des accès au système de fichiers user. Aucun de ces éléments ne devrait être présent dans une application de portefeuille sérieuse, sauf si documenté explicitement et audité indépendamment.

Tests de régression et validation du comportement attendu

Après l’examen statique du code, exécutez les suites de tests fournis par SatoshiLabs. La commande npm run test ou npm run test:unit doit exécuter les tests unitaires qui valident les fonctions critiques. Une couverture de test élevée (> 80 %) est un bon signe ; une faible couverture suggère que des portions du code ne sont pas validées par des tests automatiques.

Exécutez également les tests d’intégration si disponibles. Connectez un vrai périphérique Trezor (ou un émulateur) et validez que Trezor Suite peut initialiser le dispositif, dériver des adresses, signer des transactions, et vérifier le firmware. Documentez le résultat de chaque test. Si l’application refuse correctement un firmware non signé ou un dispositif non initialisé, c’est un comportement attendu. Si elle accepte un firmware forgé ou une clé privée sur l’ordinateur, c’est un résultat d’audit inacceptable.

Enfin, créez un processus de régression : documentez les résultats de chaque version que vous auditez. En comparant les versions, vous pouvez identifier si une régression de sécurité a été introduite. Par exemple, si la version 24.11.1 refuse un firmware forgé mais que la version 24.11.2 l’accepte silencieusement, c’est un signal critique. Partagez vos conclusions avec SatoshiLabs par les canaux de divulgation responsable si vous découvrez une faille, plutôt que de la publier immédiatement.

Documentation et reproductibilité pour les pairs

L’objectif final d’un audit interne est la connaissance reproductible. Un auditeur qui effectue ces vérifications doit documenter chaque étape : les versions des outils, les commandes exactes exécutées, les hashes SHA256 des artefacts clés, et les résultats des tests. Cette documentation peut ensuite être partagée avec d’autres développeurs ou auditeurs qui pourront reproduire votre travail indépendamment.

Utilisez un contrôle de version (git) pour suivre votre processus d’audit. Créez un dépôt séparé contenant votre Dockerfile de compilation, vos scripts de vérification de hash, et un journal des découvertes. Signez vos commits avec votre propre clé GPG pour établir la chaîne de custody : ces conclusions proviennent effectivement de vous, et n’ont pas été modifiées après. Si plusieurs auditeurs indépendants publient des rapports concordants, la confiance dans le code open source augmente de façon exponentielle.

Une publication anonyme ou sous pseudonyme peut être appropriée si vous découvrez une vulnérabilité et que vous attendez un correctif. Un rapport ouvert et signé est plus puissant si l’audit est positif : une déclaration testifiée que vous, en tant que développeur nommé, avez audité le code source public de Trezor Suite et que vous n’avez pas trouvé de backdoor. Cette forme de preuve décentralisée est plus difficile à contrefaire qu’une affirmation publicitaire centralisée.