Le firmware, ou micrologiciel, est le logiciel qui commande un appareil, par exemple une Hardware Wallet. Sa compilation est reproductible lorsque les mêmes sources, l’environnement défini et les instructions produisent exactement les mêmes fichiers, déterminés à l’avance. Un comportement identique ne suffit pas : on compare les données elles-mêmes. Pour une publication signée, le traitement de la signature doit aussi être clairement défini.
Le fabricant peut publier du code qu’un programmeur sait lire. Vous installez pourtant généralement sur votre appareil un fichier terminé en langage machine, appelé binaire. La compilation relie ces deux formes. Une personne indépendante peut la répéter et comparer son résultat à la publication. Elle recherche des octets identiques, c’est-à-dire les mêmes unités de données, souvent au moyen d’un hachage cryptographique : une empreinte calculée à partir du contenu. La vérification porte sur des résultats définis, par exemple le fichier du firmware, pas automatiquement sur tous les fichiers de travail et journaux. [1] [4]
Imaginons deux développeurs qui vérifient une mise à jour. Le nom du projet ne suffit pas : il leur faut le même commit, c’est-à-dire une révision précise du code. Ils doivent aussi connaître les versions des bibliothèques utilisées et du compilateur, l’outil qui transforme le code en langage machine. Ses options, les réglages pertinents de l’environnement et le modèle de l’appareil font également partie de la procédure. Ces données doivent être définies à l’avance ou enregistrées lors de la compilation. Sinon, les deux personnes peuvent travailler honnêtement et obtenir des résultats différents. [1] [2]
Une différence ne signifie pas forcément que quelqu’un a modifié le fonctionnement du programme. Le compilateur peut inscrire le chemin du dossier de travail dans les informations servant à rechercher des erreurs. Si les développeurs rangent le projet à des endroits différents, les fichiers peuvent donc différer. Un chemin imposé ou une méthode prévue pour uniformiser les chemins peut résoudre le problème. Cette règle doit être une partie connue de la procédure. Effacer après coup des différences inexpliquées pour obtenir une correspondance ferait perdre tout sens au contrôle. [3]
Une signature numérique permet de vérifier qu’un fichier correspond à une signature créée avec la clé concernée. Attribuer cette clé au fabricant est un autre élément de confiance. La compilation reproductible pose une autre question : le fichier correspond-il au code source défini ? Les deux contrôles se complètent. La mise à jour officielle peut toutefois contenir des données de signature absentes du résultat local. Comparer les fichiers entiers sans connaître leur format peut ainsi faire apparaître un écart même si le programme a été compilé correctement. [5]
La documentation Trezor décrit le choix d’une version et d’un modèle, la compilation du firmware et la comparaison avec le fichier officiel. Le résultat local n’étant pas signé comme la publication du fabricant, la procédure met d’abord à zéro des champs de signature précisément définis. Les anciens formats diffèrent aussi par leurs en-têtes, les parties initiales contenant des informations sur les fichiers. La structure dépend du modèle et de la version : on ne peut pas transposer sans vérification la procédure d’un appareil à un autre. La signature originale se vérifie séparément ; comparer des copies adaptées ne remplace pas ce contrôle. [5]
Il faut d’abord établir si la comparaison porte sur la même révision, le même modèle et la même variante du firmware. Viennent ensuite les outils, les bibliothèques et les transformations prescrites. Les fichiers originaux et la trace de l’écart doivent être conservés. La cause peut être une erreur d’environnement ou d’instructions, mais aussi une modification du programme distribué. L’écart seul ne désigne ni responsable ni cause. Tant qu’il n’est pas expliqué et que le contrôle n’a pas été répété, il ne faut pas déclarer la compilation vérifiée. [1] [4]
Si le code publié contient déjà une erreur, chaque reconstruction peut la reproduire fidèlement. Un compilateur commun non fiable pourrait aussi ajouter la même modification malveillante à tous les résultats ; le réutiliser ne revient pas à le contrôler indépendamment. Des composants binaires fermés limitent par ailleurs ce qui peut être reconstruit depuis les sources disponibles. Et un fichier identique sur un ordinateur ne prouve pas qu’un appareil particulier est authentique ni qu’il exécute ce firmware. Vérifier l’origine du fichier est une étape importante de sécurité, pas une preuve complète. [6] [1]
La mention « vérifié » devient utile lorsqu’on peut identifier qui a fait le contrôle, quelle révision a été compilée, pour quel modèle et selon quelle procédure. Le rapport doit préciser les fichiers comparés, la fonction de hachage, les résultats et le traitement exact des signatures. D’autres personnes peuvent alors examiner ou répéter le travail. Plusieurs reconstructions indépendantes réduisent la dépendance envers un seul éditeur. L’examen du code, du processus de mise à jour et de l’appareil reste nécessaire. [2] [4]
Deux résultats identiques et une empreinte différente
Deux développeurs compilent la même révision du firmware pour le même modèle dans le même environnement. Les empreintes SHA-256 de leurs fichiers correspondent, mais celle de la version officielle signée diffère. Si la documentation définit précisément les champs de signature, ils appliquent la transformation prévue à des copies et comparent à nouveau. La correspondance porte alors sur ce contenu défini. La signature originale doit toujours être vérifiée séparément ; les autres différences inexpliquées ne peuvent pas être simplement supprimées.
Pour une vision complète, lisez aussi Hardware Wallet, Private Key, Cold Storage, Secure Element. Cette entrée est également citée par COLDCARD RNG Incident (2026).
01Dois-je compiler moi-même le firmware ?+
Vous n’avez pas besoin d’être programmeur pour comprendre un résultat de vérification. Assurez-vous cependant que le rapport indépendant précise la version, le modèle et les fichiers comparés. Une empreinte identique ne prouve pas l’absence d’erreurs : un même code malveillant ou compilateur peut produire les mêmes fichiers. Examiner le code et décider de faire confiance à l’appareil restent des questions distinctes.
02Une empreinte différente pour une mise à jour signée indique-t-elle une attaque ?+
Pas automatiquement. Le fichier peut contenir des signatures ou des en-têtes différents déjà prévus par la méthode de vérification. Il faut contrôler la version, le modèle et les instructions exactes. Un écart inexpliqué n’est toutefois pas une vérification réussie et ne doit pas être contourné en supprimant des données arbitrairement.