Firmware ist die Software, die ein Gerät wie eine Hardware Wallet steuert. Ein Build ist reproduzierbar, wenn derselbe Quellcode mit der festgelegten Umgebung und Anleitung genau dieselben, vorher bestimmten Dateien ergibt. Gleiches Programmverhalten genügt nicht: Verglichen werden die Daten selbst. Bei signierten Veröffentlichungen muss außerdem klar sein, wie die Signatur behandelt wird.
Ein Hersteller kann Code veröffentlichen, den Programmierer lesen können. Auf der Wallet landet jedoch gewöhnlich eine fertige Datei in Maschinensprache, eine Binärdatei. Der Build verbindet diese beiden Formen. Eine unabhängige Person kann ihn wiederholen und das Ergebnis mit der Veröffentlichung vergleichen. Gesucht werden gleiche Bytes, also einzelne Dateneinheiten, häufig mithilfe eines kryptografischen Hashes: eines aus dem Inhalt berechneten Fingerabdrucks. Die Aussage gilt für bestimmte Ergebnisse, etwa die Firmware-Datei, nicht automatisch auch für sämtliche Arbeitsdateien und Protokolle. [1] [4]
Zwei Entwickler wollen dieselbe Aktualisierung prüfen. Der Projektname reicht dafür nicht: Sie benötigen denselben Commit, also einen genau bestimmten Stand des Codes. Auch die Versionen eingebundener Bibliotheken und des Compilers müssen bekannt sein. Der Compiler übersetzt den Code in Maschinensprache. Seine Optionen, relevante Umgebungseinstellungen und das Wallet-Modell gehören ebenfalls zur Anleitung. Diese Angaben müssen vorher festgelegt oder beim Build aufgezeichnet werden. Sonst können beide sorgfältig arbeiten und trotzdem unterschiedliche Ergebnisse erhalten. [1] [2]
Eine Abweichung bedeutet nicht zwangsläufig, dass jemand das Programmverhalten verändert hat. Ein Compiler kann den Pfad zum Arbeitsordner in Informationen zur Fehlersuche speichern. Liegt das Projekt bei den Entwicklern an unterschiedlichen Orten, können sich dadurch die Dateien unterscheiden. Ein vorgeschriebener Pfad oder ein unterstütztes Verfahren zur Vereinheitlichung kann helfen. Die Regel muss ein bekannter Teil des Builds sein. Ungeklärte Unterschiede nach einem fehlgeschlagenen Vergleich zu löschen, nur um Übereinstimmung zu erreichen, entwertet die Prüfung. [3]
Mit einer digitalen Signatur lässt sich prüfen, ob eine Datei zur Signatur des entsprechenden Schlüssels passt. Diesen Schlüssel dem Hersteller zuzuordnen, ist ein weiterer Teil des Vertrauens. Ein reproduzierbarer Build prüft dagegen, ob die Datei zum festgelegten Quellcode gehört. Beide Kontrollen ergänzen sich. Die offizielle Aktualisierung kann jedoch Signaturdaten enthalten, die im lokalen Build fehlen. Wer die ganzen Dateien ohne Kenntnis des Formats vergleicht, kann deshalb auch bei korrekt erstelltem Programm eine Abweichung erhalten. [5]
Die Trezor-Dokumentation beschreibt die Auswahl von Version und Modell, den Build der Firmware und den Vergleich mit der offiziellen Datei. Da das lokale Ergebnis nicht wie die Veröffentlichung des Herstellers signiert ist, werden vorher genau festgelegte Signaturfelder auf null gesetzt. Ältere Formate unterscheiden sich auch bei den Headern, den einleitenden Dateibereichen mit zusätzlichen Angaben. Der Aufbau hängt von Modell und Version ab. Eine Anleitung für ein Gerät lässt sich deshalb nicht ungeprüft auf ein anderes übertragen. Die ursprüngliche Signatur wird separat geprüft; der Vergleich angepasster Kopien ersetzt das nicht. [5]
Zuerst muss geklärt werden, ob tatsächlich derselbe Codestand, dasselbe Modell und dieselbe Firmware-Variante verglichen wurden. Danach folgen Werkzeuge, Bibliotheken und vorgeschriebene Dateianpassungen. Originaldateien und der Nachweis der Abweichung sollen erhalten bleiben. Ursache kann ein Fehler der Umgebung oder Anleitung sein, aber auch eine Veränderung des ausgelieferten Programms. Die Abweichung allein benennt weder Verantwortliche noch Ursache. Solange sie nicht erklärt und die Prüfung wiederholt wurde, darf der Build nicht als verifiziert gelten. [1] [4]
Steckt ein Fehler bereits im veröffentlichten Code, kann jeder erneute Build ihn unverändert übernehmen. Ein gemeinsam genutzter, nicht vertrauenswürdiger Compiler könnte allen Ergebnissen dieselbe schädliche Änderung hinzufügen. Ihn erneut einzusetzen ist keine unabhängige Prüfung des Werkzeugs. Geschlossene Binärbestandteile begrenzen außerdem, was sich aus verfügbarem Code neu erstellen lässt. Eine übereinstimmende Datei auf dem Computer beweist auch nicht, dass die konkrete Wallet echt ist oder diese Firmware ausführt. Die Herkunftsprüfung ist ein wichtiger Sicherheitsbaustein, aber kein vollständiger Sicherheitsnachweis. [6] [1]
Die Aussage „verifiziert“ wird erst hilfreich, wenn ersichtlich ist, wer welchen Codestand für welches Modell nach welcher Anleitung erstellt hat. Der Bericht sollte verglichene Dateien, Hashfunktion, Ergebnisse und den genauen Umgang mit Signaturdaten nennen. Andere können die Arbeit dann nachvollziehen oder wiederholen. Mehr unabhängige Ersteller verringern die Abhängigkeit von einem einzigen Herausgeber. Code, Aktualisierungsverfahren und Gerät selbst müssen dennoch geprüft werden. [2] [4]
Zwei gleiche Ergebnisse und ein anderer Hash
Zwei Entwickler erstellen Firmware aus demselben Codestand für dasselbe Modell in derselben Umgebung. Die SHA-256-Fingerabdrücke ihrer Dateien stimmen überein, derjenige der offiziellen signierten Version jedoch nicht. Wenn die Dokumentation die Signaturfelder genau festlegt, passen sie Kopien nach dieser Vorgabe an und vergleichen erneut. Eine Übereinstimmung gilt dann für den so definierten Inhalt. Die ursprüngliche Signatur muss weiterhin separat geprüft werden; andere ungeklärte Unterschiede dürfen nicht einfach verschwinden.
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Hardware Wallet, Private Key, Cold Storage, Secure Element. Auf diesen Eintrag verweisen außerdem COLDCARD RNG Incident (2026).
01Muss ich die Firmware als Nutzer selbst erstellen?+
Um ein Prüfergebnis zu verstehen, müssen Sie nicht programmieren können. Achten Sie aber darauf, ob der unabhängige Bericht konkrete Version, Modell und verglichene Dateien nennt. Ein gleicher Hash beweist keine Fehlerfreiheit: Derselbe schädliche Code oder Compiler kann gleiche Dateien erzeugen. Die Prüfung des Codes und das Vertrauen in das Gerät bleiben eigene Fragen.
02Bedeutet ein anderer Hash einer signierten Aktualisierung einen Angriff?+
Nicht automatisch. Die Datei kann andere Signaturdaten oder Header enthalten, die das Prüfverfahren bereits berücksichtigt. Version, Modell und genaue Anleitung müssen stimmen. Eine ungeklärte Abweichung ist jedoch keine erfolgreiche Verifizierung und darf nicht durch beliebiges Löschen von Daten umgangen werden.