Reproducible Firmware Build bezeichnet einen Build, bei dem derselbe Quellcode, dieselbe Umgebung und dieselben Anweisungen vorab festgelegte, bytegleiche Ausgaben erzeugen. Version, Gerätemodell und Vergleichsumfang müssen angegeben werden, besonders wenn eine Veröffentlichung eine zusätzliche Signatur enthält.
Die Aussage betrifft eine festgelegte Ausgabe, etwa ein Firmware-Abbild, nicht automatisch jede Datei oder jedes Protokoll. Gleiches Programmverhalten genügt nicht: Gesucht werden identische Bytes, üblicherweise mithilfe eines kryptografischen Hashes. Offener Quellcode ohne wiederholbaren Build belegt diese Verbindung zur veröffentlichten Binärdatei allein nicht. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Dokumentieren Sie den genauen Commit, Abhängigkeiten samt Versionen, Compiler, Build-Optionen, relevante Umgebungsvariablen und das Zielmodell. Projektname oder veränderlicher Branch reichen nicht aus. Die für die Wiederholung nötigen Informationen müssen veröffentlicht oder beim Build aufgezeichnet werden; sonst lassen sich Unterschiede nicht zuverlässig beurteilen. [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]
Ein Compiler kann den Pfad des Arbeitsverzeichnisses in Debug-Informationen einbetten. Derselbe Quellcode an zwei Orten kann dadurch unterschiedliche Dateien ergeben. Der Pfad lässt sich vorab festlegen oder mit einem unterstützten Verfahren normalisieren. Diese Regel muss zur Anleitung gehören; unbekannte Unterschiede nachträglich zu entfernen würde die Prüfung entwerten. [Reproducible Builds — Build paths]
Eine gültige Signatur bindet eine Veröffentlichung innerhalb eines bestimmten Vertrauensmodells an ihren Signaturschlüssel. Ein unabhängiger Build untersucht den Zusammenhang zwischen Quellcode und Binärausgabe. Eine offiziell signierte Datei kann Daten enthalten, die im unsignierten lokalen Build fehlen. Der bloße Vergleich vollständiger Dateien ist dann möglicherweise kein geeigneter Test der behaupteten Reproduzierbarkeit. [Trezor — Reproducible build verification]
Die Trezor-Dokumentation wählt Version und Modell, erstellt das Abbild in der festgelegten Umgebung und vergleicht es mit der offiziellen Veröffentlichung. Vor dem Vergleich beschreibt sie das Nullsetzen genau definierter Signaturfelder; ältere Formate unterscheiden sich außerdem in den Headern. Der Aufbau hängt von Modell und Version ab. Ein Verfahren für ein Abbild darf daher nicht blind auf ein anderes angewandt werden; die ursprüngliche Signatur wird getrennt geprüft. [Trezor — Reproducible build verification]
Prüfen Sie zuerst Revision, Modell, Firmware-Variante, Abhängigkeiten und deklarierte Änderungen am Abbild. Bewahren Sie die Originaldateien und einen Nachweis der Abweichung auf. Ein Unterschied kann aus einer fehlerhaften Anleitung oder Umgebung, aber auch aus einer veränderten ausgelieferten Binärdatei entstehen; allein benennt er die Ursache nicht. Kennzeichnen Sie das Ergebnis erst als verifiziert, wenn der Unterschied erklärt und die Prüfung wiederholt wurde. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Fehlerhafter oder bösartiger Quellcode kann vollständig reproduzierbar sein. Ein gemeinsam verwendeter, nicht vertrauenswürdiger Compiler kann dieselbe Änderung in alle Ergebnisse einfügen; die Wiederholung desselben Werkzeugs ist kein unabhängiges Compiler-Audit. Geschlossene Binärbestandteile begrenzen, was aus verfügbarem Quellcode neu gebaut werden kann. Übereinstimmende Dateien bestätigen weder echte Hardware noch die tatsächlich auf einem konkreten Gerät installierten Daten. [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]
Ein nützlicher Nachweis nennt die ausführende Person, Commit, Anleitung, Modell und verglichene Dateien. Ergänzen Sie Hash-Algorithmus, Ergebnisse und genaue Ausnahmen für Signaturdaten. Weitere unabhängige Ersteller verringern die Abhängigkeit von einem einzigen Herausgeber, ersetzen aber weder die Prüfung des Quellcodes und Aktualisierungsprozesses noch die Sicherheitsbewertung des gesamten Geräts. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
Gleicher Code, anderer Signaturbereich
Zwei Ersteller verwenden denselben Commit, dasselbe Modell und dieselbe Umgebung. Ihre lokalen Abbilder haben denselben SHA-256, das offiziell signierte Abbild einen anderen. Definiert die Dokumentation die Signaturfelder genau, vergleichen sie Kopien nach der vorgeschriebenen Anpassung. Die Übereinstimmung gilt für diesen festgelegten Inhalt; die ursprüngliche Signatur wird separat geprüft. Andere Unterschiede dürfen sie nicht einfach entfernen.
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Hardware Wallet, Privater Schlüssel, Cold Storage, Secure Element. Auf diesen Eintrag verweisen außerdem COLDCARD RNG Incident (2026).
01Beweist ein übereinstimmender Hash sichere Firmware?+
Nein. Die Übereinstimmung belegt das Ergebnis eines konkreten Vergleichs, nicht die Fehlerfreiheit. Bösartiger Quellcode oder ein gemeinsam verwendeter, nicht vertrauenswürdiger Compiler können gleiche Ausgaben erzeugen. Build-Verifikation, Quellcodeprüfung und Vertrauen in das Gerät müssen getrennt betrachtet werden.
02Bedeutet ein anderer Hash einer signierten Veröffentlichung automatisch einen Angriff?+
Nein. Ein signiertes Abbild kann abweichende, vorab dokumentierte Signaturfelder oder Header enthalten. Prüfen Sie zuerst die richtige Version, das Modell und das Vergleichsverfahren. Eine ungeklärte Abweichung darf jedoch weder als erfolgreiche Verifikation gelten noch durch beliebiges Löschen von Bytes umgangen werden.