Einen Wallet-Download überprüfen: Prüfsummen, Signaturen und reproduzierbare Builds
Wenn du eine Wallet installierst, vertraust du darauf, dass die Datei auf deinem Computer genau die Software ist, die ihre Entwickler veröffentlicht haben – und keine veränderte Kopie von einer kompromittierten Website, einer nachgeahmten Download-Seite oder ein manipulierter Build. Für die meisten Menschen reicht die Installation aus dem offiziellen Store völlig aus. Wer aber lieber prüft statt vertraut, findet bei Open-Source-Wallets drei zunehmend starke Werkzeuge: Prüfsummen, Signaturen und reproduzierbare Builds.
Hier erfährst du, was jedes davon beweist und wie du es mit SSP Wallet nutzt.
Prüfsummen: Ist das dieselbe Datei?
Eine Prüfsumme ist der Fingerabdruck einer Datei, erzeugt von einer Hashfunktion wie SHA-256. Ändert sich auch nur ein einziges Byte, ändert sich der Fingerabdruck vollständig. Stimmt die Prüfsumme der heruntergeladenen Datei mit der von den Entwicklern veröffentlichten überein, hast du dieselbe Datei.
Unter macOS oder Linux kannst du sie im Terminal berechnen:
shasum -a 256 ssp-wallet-chrome-v2.1.3.zip
Eine Prüfsumme allein hat eine Schwäche: Kontrolliert ein Angreifer die Download-Seite, kann er sowohl die Datei als auch die veröffentlichte Prüfsumme austauschen. Deshalb ist der nächste Schritt so wichtig.
Signaturen: Haben die Entwickler das veröffentlicht?
Eine Signatur beweist, wer die Prüfsummen veröffentlicht hat. Die Entwickler signieren die Prüfsummendatei mit einem privaten Schlüssel, und jeder mit dem passenden öffentlichen Schlüssel kann diese Signatur überprüfen. Ein Angreifer, der die Datei oder die Prüfsummen verändert, kann ohne diesen privaten Schlüssel keine gültige Signatur erzeugen.
Das Einzige, was du unbedingt richtig machen musst, ist der öffentliche Schlüssel selbst. Beziehe ihn aus einer offiziellen Quelle des Projekts, gleiche seinen Fingerabdruck über mehr als einen offiziellen Kanal ab und verwende von da an für jede Version denselben Schlüssel.
Reproduzierbare Builds: Wurde diese Datei wirklich aus dem veröffentlichten Code gebaut?
Signaturen beweisen, wer eine Datei veröffentlicht hat, nicht was darin steckt. Der Build-Rechner eines Entwicklers könnte kompromittiert sein und in gutem Glauben schädliche Ergebnisse signieren.
Reproduzierbare – oder deterministische – Builds schließen diese Lücke. Der Build-Prozess ist so festgelegt, dass derselbe Quellcode auf jedem Rechner immer eine Byte für Byte identische Datei erzeugt. Jeder kann eine Version aus dem öffentlichen Code neu bauen und die Prüfsummen vergleichen. Stimmen sie überein, enthält die veröffentlichte Datei genau das, was im Quellcode steht, und nichts anderes. Supply-Chain-Angriffe und deterministische Builds erklärt, warum das für Wallets so wichtig ist.
SSP Wallet überprüfen
Die Versionen von SSP Wallet auf GitHub (RunOnFlux/ssp-wallet) werden für Chrome und Firefox deterministisch gebaut und enthalten zwei zusätzliche Dateien: SHA256SUMS, das die Prüfsumme jedes Pakets auflistet, und SHA256SUMS.asc, eine GPG-Signatur über diese Liste.
1. Lade die Release-Dateien herunter. Lade von der Release-Seite das Paket für deinen Browser – benannt wie ssp-wallet-chrome-v2.1.3.zip oder ssp-wallet-firefox-v2.1.3.zip – zusammen mit SHA256SUMS und SHA256SUMS.asc in einen Ordner herunter.
2. Prüfe die Signatur. Mit dem in GPG importierten öffentlichen Release-Signaturschlüssel von SSP:
gpg --verify SHA256SUMS.asc SHA256SUMS
GPG sollte eine gültige Signatur des erwarteten Schlüssels melden. Meldet es eine ungültige Signatur oder einen unbekannten Schlüssel, brich ab.
3. Gleiche die Dateien mit der Liste ab.
sha256sum -c SHA256SUMS
Unter macOS erledigt shasum -a 256 -c SHA256SUMS dasselbe. Jede heruntergeladene Datei sollte OK melden. Die Liste umfasst sowohl das Chrome- als auch das Firefox-Paket; hast du nur eines heruntergeladen, füge --ignore-missing hinzu, damit das andere nicht als fehlend gemeldet wird.
4. Optional: Baue es selbst. Klone das Repository am Release-Tag und führe den deterministischen Build aus:
git clone https://github.com/RunOnFlux/ssp-wallet.git
cd ssp-wallet
git checkout <release-tag>
yarn build:deterministic
Der Build läuft in einer festgelegten Docker-Umgebung und schreibt seine eigene SHA256SUMS. Stimmen deine Prüfsummen mit den veröffentlichten überein, hast du unabhängig bestätigt, dass die Version aus genau diesem Quellcode gebaut wurde.
Und die Browser-Stores?
Die meisten Menschen installieren SSP Wallet über den Chrome Web Store oder Firefox Add-ons, und das ist eine vernünftige Wahl – Store-Installationen aktualisieren sich automatisch, und die Stores haben eigene Prüfverfahren. Die obigen Prüfsummen betreffen die Release-Pakete auf GitHub. Installierst du aus einem Store, sind die wichtigsten Prüfungen einfacher: dass du den Eintrag über die offizielle Website erreicht hast und dass der Herausgeber stimmt. Gefälschte Wallet-Apps erkennen beschreibt diese Schritte, und Hygiene bei Browser-Erweiterungen zeigt, wie du deinen Browser danach sicher hältst.
Die ehrliche Zusammenfassung
Eine Prüfsumme beweist, dass du dieselbe Datei hast; eine Signatur beweist, wer sie veröffentlicht hat; ein reproduzierbarer Build beweist, dass die Datei aus dem veröffentlichten Code stammt. Jeder Schritt ersetzt eine andere Art von Vertrauen.
Die meisten werden aus dem offiziellen Store installieren, und das ist in Ordnung. Wenn du selbst prüfen möchtest, geben dir die Versionen von SSP Wallet alle drei Werkzeuge: eine signierte Prüfsummenliste, eine einzeilige Prüfung und einen Build, den du Byte für Byte reproduzieren kannst.
