The current public key is signed with the previous signify key. If you already have the previous signify public key (factory.pub) and want to verify the new key with it:
curl -O https://releases.grapheneos.org/allowed_signers.sig signify -V -m allowed_signers -x allowed_signers.sig -p factory.pub
When the current signing key is replaced, the new key will be signed with it.
Fragen:
1.
Ich kapiere einfach nicht weshalb ich den „new key“ verifizieren sollte…
2.
Ohne -V oder -v funktioniert bei mir der Command nicht, Weshalb wohl?
Wenn du den alten Schlüssel (Key) bereits hast, Stichwort „factory.pub“-Datei, kannst du so wissen ob du dem neuen Schlüssel genauso trauen kannst wie dem alten:
Da der alte, private Schlüssel zum signieren vermutlich nicht kompromittiert wurde, kannst du überprüfen, ob der neue, heruntergeladene Schlüssel nicht ausgetauscht wurde (ohne diesen mit dem alten Schlüssel zu signieren), da er mit eben diesem signiert wurde… und dann nicht überprüft und als gültig angezeigt wird/werden kann, wenn er unerwünscht ausgetauscht wurde.
Mit funktioniert er bei dir nicht.
Hattest du eventuell das Problem, dass du erst nicht signify nutzen konntest, und erst das Programm über den Paketmanager installiert hast?
Falls ja: Nutzt du Debian oder Ubuntu, oder entsprechend MX, Linux Mint, o.Ä.?
Hast du apt install signify verwendet?
Wenn ja: Unter Debian und Ubuntu heißt das korrekte Paket für das signify tool signify-openbsd, und wird unter Debian auch als Programm so ausgeführt (signify-openbsd -V [...] anstatt signify). Entsprechend musst du das Paket anstelle von signify installieren.
Das stand früher auch in der Anleitung, aber signify ist in der neuen nicht mehr in Verwendung, außer du möchtest den neuen Schlüssel mit dem alten verifizieren.
Ganz genau ich habe apt install signify verwendet! Jetzt aber die Version fuer Mint/Debian nachinstalliert mit:
apt install signify-openbsd
Leider funktioniert es immer noch nicht richtig…
…
mint@mint:~/platform-tools$ curl -O https://releases.grapheneos.org/allowed_signers
mint@mint:~/platform-tools$ curl -O https://releases.grapheneos.org/allowed_signers.sig
mint@mint:~/platform-tools$ ls -li
total 16120
812 -rw-r–r-- 1 mint mint 1128669 Jan 1 2008 NOTICE.txt
813 -rwxr-xr-x 1 mint mint 7814144 Jan 1 2008 adb
1751 -rw-rw-r-- 1 mint mint 104 Mar 27 09:51 allowed_signers
1752 -rw-rw-r-- 1 mint mint 144 Mar 27 09:52 allowed_signers.sig
814 -rwxr-xr-x 1 mint mint 303608 Jan 1 2008 etc1tool
815 -rwxr-xr-x 1 mint mint 2472232 Jan 1 2008 fastboot
816 -rwxr-xr-x 1 mint mint 13312 Jan 1 2008 hprof-conv
1915 drwxrwxr-x 2 mint mint 60 Mar 27 09:02 lib64
817 -rwxr-xr-x 1 mint mint 262816 Jan 1 2008 make_f2fs
818 -rwxr-xr-x 1 mint mint 262800 Jan 1 2008 make_f2fs_casefold
819 -rwxr-xr-x 1 mint mint 874336 Jan 1 2008 mke2fs
820 -rw-r–r-- 1 mint mint 1157 Jan 1 2008 mke2fs.conf
821 -rw-r–r-- 1 mint mint 38 Jan 1 2008 source.properties
822 -rwxr-xr-x 1 mint mint 3335144 Jan 1 2008 sqlite3
mint@mint:~/platform-tools$
.
mint@mint:~/platform-tools$ signify-openbsd -V -m allowed_signers -x allowed_signers.sig -p factory.pub
signify-openbsd: can’t open factory.pub for reading: No such file or directory
…
Ah, das letzte Problem ist, dass du den vorherigen Schlüssel wohl gar nicht hast?
In der Anleitung steht „The current public key is signed with the previous signify key. If you already have the previous signify public key (factory.pub) and want to verify the new key with it:“
Du könntest/soll(te)st den Schritt überspringen.
Falls du den vorherigen Schlüssel doch hast - das wäre der Fall wenn du die Anleitung vor dem Wechsel auf den neuen Schlüssel bereits einmal durchgearbeitet hast - müsstest du diesen nur in den Ordner kopieren, in dem du den ls Befehl ausgeführt hast.
Falls nicht, ergibt es eigentlich wenig Sinn diesen beschaffen zu wollen.
Endweder du vertraust der Webseite von GrapheneOS, den richtigen Key zu hosten, dann kannst du aber dem aktuellen Schlüssel genauso vertrauen wie dem alten, wenn er daher stammt -
oder du hast diesen (alten) bereits, oder erhältst ihn von jemandem, den du vertraust.
Dann kannst du ihn zum verifizieren des neuen Schlüssels verwenden, da du dem alten Schlüssel eben schon vertraust (trust on first use-Prinzip).
Alternativ würde Ich sagen, könntest du eine Zeile höher gehen, „Other locations to obtain the signing key:“ anschauen, und dir dort von einer Drittseite den Schlüssel holen, und die Kopie von der GrapheneOS Seite mit der von der Drittseite vergleichen. Der Inhalt der Datei ist nicht lang, sollte also von Hand klappen.
Falls dir das zuwider ist (BlueSky, Twitter, Github (Microsoft)? Igitt! ), aber du es trotzdem irgendwie verifizieren möchtest: Du könntest mir vertrauen.
Hier wäre meine Kopie vom öffentlichen Schlüssel vom 09.07.2022 gehostet bei Proton Drive, für eine Woche.
Da Ich nicht in der Lage bin den Server von Graphene zu kompromittieren… brauchst du dir auch keine Sorgen machen, dass die Signaturdatei dort von mir stammt. Beides muss zusammen passen, dann erst erhältst du von signify ein „Signature Verified“.
Gib gerne Rückmeldung, auch wenn du Ihn nicht nutzen möchtest, dann kann Ich den Schlüssel auch vorher wieder offline nehmen.
(danke, @towaco, du hast Recht, idealerweise sollte man es ausschreiben!)
Ich verstehe nicht, warum man diese Firmware anhand eines Keys verifizieren muss? Man lädt die Firmware doch nicht von Drittservern herunter. Traut GrapheneOS den eigenen Servern nicht?
Hab mir diese CLI-Anleitung nun genauer angesehen.
Die Verifizierung bezieht sich ausschließlich auf den Download der Firmware. Wäre eine simple MD5- oder SHA1-Prüfsumme zur Verifizierung des ZIP-Archives nicht wesentlich einfacher, als die von GOS bereitgestellte Variante? Finde es ziemlich kompliziert…
Außerdem ist eine SSH-Verifizierung nicht dazu gedacht, einen Download zu verifizieren. Die Verbindung läuft doch standardmäßig schon über SSL und das reicht völlig aus.
Ich persönlich würde die komplette Geschichte mit SSH-Verifizierung überspringen und die Firmware per bereitgestellten Link runterladen. Ich muss doch wohl nicht davon ausgehen, dass die GOS-Server kompromitiert sind.
Es wird nur openssh verwendet, da es meist vorinstalliert ist, und den Leuten so nicht - gerade mit den Unterschieden von System zu System, Debian = signify-openbsd / Arch = signify - kompliziertere Instruktionen gegeben werden müssen. Am Ende wird damit nur die Signatur geprüft, ssh, also das Protokoll, wird gar nicht verwendet. TLS ist bekanntermaßen maßgeblich abhängig von Zertifizierungsstellen. Und das ist - gerade in Sicherheitskreisen - ein bekanntes Problem.
Dass weiterhin natürlich der Übergang vom alten zum neuen Schlüssel dort angegeben wird, ist eventuell etwas verwirrend. Aber eben nötig, da
eine einfache Checksumme für den Download nicht das Ziel ist.
Sondern unter anderem das beschaffen des Keys, den man beim erneuten Download dann wieder verwendet, um kryptographisch sicherzustellen dass das Image von GrapheneOS stammt, als auch korrekt ist, denn
ist der Fall. Nicht, weil sie die eigenen Server schlecht absichern (hoffentlich), sondern weil die Chance besteht, dass dieser eben doch kompromittiert wird, da Software komplex sein kann.
Deswegen werden die alternativen Quellen für den Schlüssel auch auf Drittservern angegeben. Natürlich könnten diese Links dorthin auch ausgetauscht werden, aber wenn einem der offizielle GrapheneOS Account auf z.B. Twitter bekannt ist…
Würde ein Angreifer die Installationsmedien für Linux Mint kompromittieren, wenn er kann?
Rhetorische Frage, die Antwort ist ja: Golem: Backdoor in Linux-Mint-ISOs / Artikel über das selbe Thema mit weniger Tracking, aber „reißerischen“ Titel gibt’s bei BITblokes.de.
Das sieht nicht anders für GrapheneOS aus, undzwar gerade dafür…
Klingt teils wirklich absurd, da du das Image (meist) vom gleichen Server lädst wie den Schlüssel.
Es gibt meist aber einfach keinen wirklich besseren Weg, als „trust on first use“, oder den Schlüssel auf X unabhängig administrierten Servern abzuholen und zu vergleichen, wenn du keinen direkten Kontakt zu den Entwicklern hast.
Nur weil ein TLS MITM zum Beispiel den Schlüssel auf beiden Seiten austauschen könnte, heißt das nicht, dass das (ein MITM oder der Austausch auf beiden Seiten) passiert. Vielleicht ist wirklich nur der Webserver von GrapheneOS.org kompromittiert. Das betrifft dann nicht die anderen Quellen, und dein Download wäre abgesichert, weil die Verifizierung fehlschlägt.
Nach deinen eigenen Bedürfnis kann dir das natürlich Egal sein, weil das Risiko eher vernachlässigbar ist, aber persönlich möchte Ich nicht das sehr geringe Risiko in kauf nehmen, teilweise mein Privatleben auf einen kompromittierten Betriebssystem zu haben.
Entsprechend hole Ich mir etwaige Schlüssel im voraus, zusätzlich aus anderen Quellen, etc. und versuche diese so gut es geht zu verifizieren, um dann bei der Installationsmedienbeschaffung eben diese zu verifizieren. Ausnahmslos.
Ein Betriebssystemhersteller der diese Option nicht anbietet ist für mich inkompetent.
Entsprechend zweifel Ich es nicht an, wenn jemand danach fragt, und helfe. Ich kann gar nicht wissen, warum die andere Person etwas tun möchte. Und Ich will es auch gar nicht wissen, solange sie nicht sich selbst oder jemand anderen damit in den Fuß schießt.
Also alle Android befreffenden Hersteller? Ich habe diese recht komplizierte Art und Weise in diesem Zusammenhang nirgendwo anders gesehen.
Übrigens: Der gesamte Ablauf in Bezug auf Android Verified Boot basiert auf SHA-1/SHA-256-Prüfsummen. Für ein ZIP-Archiv mit genau eben diesen Images, die bei AVB anhand von SHA-1/-256 verifiziert werden, soll diese Art der Verifizierung plötzlich nicht mehr gut genug sein? Abgesehen davon, dass es für den User auch um ein vielfaches einfacher wäre.
Was macht denn ein User, der sich das Image einfach über den Link „Releases“ auf der Homepage runterlädt? Muss er davon ausgehen, dass das Image kompromittiert ist? Warum bietet GOS diese Links dann an, wenn sie gar nicht über SSH verifiziert werden können, bzw. sind? Macht absolut null Sinn!
Dort wird das Betriebssystem auf dem Gerät selbst ausgeliefert, und nicht als Download auf einer Webseite zur Verfügung gestellt, als Hauptbezugsweg. Zugleich befindet sich der öffentliche Schlüssel hier bereits auf dem Gerät, und darüber lässt sich das Image verifizieren.
Meine Aussage gilt vorallem für Betriebssysteme von Dritten (GrapheneOS, Lineage, Linux Distributionen, Windows, …): wenn sie tatsächlich(!) keine Signaturen anbieten, um den Download oder einen Schlüssel der im Fall von z.B. verified boot/secure boot das Image überprüft, zu verifizieren, sind sie inkompetent.
(Ja, Ich sehe die Schlüssel von MS für Secure Boot am Desktop als nicht ausreichend an.)
Aber ja, wenn die Hersteller für Ihre Downloads, sollten sie welche Anbieten, und das fände Ich gut, auf Ihrer Seite signierte Dateien anbieten sind sie für mich kompetent.
Andernfalls… kommt es darauf an. Da hier das Image sowieso auf dem Gerät aufgespielt wird, welches den Schlüssel bereits integriert hat, um das Image auf Echtheit zu überprüfen, ist es ja signiert. Nur eben ohne weitere Dateien.
Das habe Ich zwar im Original nicht erwähnt/so geschrieben, aber sehe das auch als kompetent an.
Verifizieren des heruntergeladenen Schlüssels, oder nach dem Prinzip „Trust on first use“ handeln und den Schlüssel beim ersten beziehen vertrauen.
→ gpg --lsign-key {Schlüssel-ID}
Die Ausgabe vom letzten Befehl zeigt an, ob das Installationsmedium mit den privaten Schlüssel signiert wurde. Den letzten Teil des Befehls kann man weglassen, dann wird die Datei bei richtigem Namen von allein gefunden.
Die GrapheneOS Entwickler sind aber etwas allergisch bezüglich gnupg.
Deswegen haben sie erst openbsd’s signify verwendet.
Das war aber unschön für die Anleitung, da das Paket bei Debian/Ubuntu openbsd-signify heißt, und bei Arch und anderen signify.
Und sind inzwischen deswegen wohl dazu gewechselt, eine Funktion von SSH zum verifizieren zu „missbrauchen“. Da ssh eigentlich überall vorinstalliert ist. Dabei wird aber nicht das SSH Protokoll verwendet, sondern eben kryptographische Funktionen die von der Software angeboten werden.
Da aber vorher bereits ein anderes Verfahren verwendet wurde, und bereits Schlüssel im Umlauf sind… ist nun diese konfuse Stelle in der Anleitung, um den alten Schlüssel zu verwenden um den neuen zu verifizieren - was die meisten Leute eben nicht tun können, da sie den alten Schlüssel nicht haben.
Da es für Leute gedacht ist, die den alten Schlüssel schon haben, und damit auch das richtige Signify installiert haben und das alles schon durch haben, gibt es da keine wirklichen Hinweise mehr drauf, außer die Anleitung zum verifizieren.
Wenn sie das schöner/sicherer finden, bitte. Es funktioniert, also reicht mir das persönlich auch.
Checksummen werden auch verwendet, ja. Aber hierbei wird auch ein Signierungsverfahren verwendet, mit einen privaten und einen öffentlichen Schlüssel. Ohne das würde das ganze nicht funktionieren:
Die SHA Checksumme würde sich ändern, wenn es eine neue Version vom System gibt. Das tut sie also auch, und die neue Checksumme wurde ebenfalls signiert. Deswegen startet dann das neue System mit den neuen Checksummen ohne murren.
Woher weiß ‚Verified Boot‘ sonst, welche Checksummen einer zukünftigen Version gültig sind, und welche nicht?
Wenn er sich neben der Datei „husky-factory-2024040300.zip“ nicht auch „husky-factory-2024040300.zip.sig“ herunterlädt, tut er das eben nicht, weil er sich nicht dafür interessiert die Signatur für das Image zu überprüfen?
Du kannst den Schritt in der Anleitung ohne Probleme überspringen, wenn du keine Signaturen prüfen willst. Weißt dann halt nicht, ob das Image von den Entwicklern (oder jemand anderen der den Key hat) signiert wurde oder nicht, also ob es tatsächlich von diesen stammt und nicht manipuliert wurde.
Das geht mit Checksummen alleine nicht, außer du erhältst diese auf einen unkompromittierbaren weg: Vielleicht, wenn dir der Entwickler diese persönlich in’s Gesicht buchstabiert, und du sie dabei überprüfst?
Checksummen bei Downloads haben auch einen Sinn, sind aber nicht wirklich dafür geeignet zu verifizieren, ob sie vom Entwickler stammen und auf dem Weg von dort nicht manipuliert wurden.
Beim signieren kommen sie aber auch zum Einsatz - gewöhnlicherweise aus performance Gründen - aber eben zusätzlich zu einen Schlüssel zum signieren.
Muss er nicht von ausgehen, sollte er aber, wenn er hohe Sicherheitsanforderungen hat.
Es ist auch alles - bis auf den öffentlichen Schlüssel - auf der Release Seite zu finden, also ist es eben doch möglich es zu verifizieren.
Inklusive folgenden Text:
About the releases
[…]
The factory images are used for the initial installation and can be verified with signify. See the installation page for details."
Hervorhebung von mir - wobei der Text veraltet ist, da Signify nicht mehr verwendet wird.
Das Image „musst“ du trotzdem zusätzlich zur Signatur herunterladen, deswegen ist auch ein Downloadlink zum „puren“ Image da.
Persönliche Meinung: bis auf Google sind die alle nicht kompetent, mit ganz wenigen Ausnahmen, aber aus eher anderen Gründen.
Aber ja, das passt alles bezüglich deren Images.
Da du das normale System des Gerätes flasht, ist der Schlüssel zur Prüfung der Signatur des Betriebssystems bereits im Bootloader gespeichert. Und das System wird beim Boot auch überprüft.
Deswegen ist hier tatsächlich dann keine Signatur auf der Seite nötig, wie bereits erwähnt.
Etwas das eben nunmal nicht auf GrapheneOS und andere, „gerätfremde“ Betriebssysteme zutrifft, da deren Schlüssel zur Signierung sich eben nicht auf dem Gerät befindet, und demnach alles erst zu verifizieren ist. Es gibt hier keinen Vertrauensanker, wie bei den Systemen des Geräteherstellers selber - sofern implementiert.
Deswegen sind hier Signaturen notwendig - die aber auch beim Image von Googles Betriebssystem vorhanden sind, nur eben nicht von dir sondern vom Gerät überprüft werden. Die Stelle, an der Ich zuerst davon sprach, ist auch im Zitat vorhanden.
Vielleicht war meine Aussage davor zu generell getätigt, um Missverständnisse zu vermeiden, dafür entschuldige Ich mich, ansich stimmt sie aber: Wenn das Image nicht mit einer Signatur verifiziert werden kann - von dir oder automatisch - ist der Hersteller Inkompetent, wenn er es verteilt.
Es war auch nirgendwo von mir gesagt, dass es komplex/unverständlich sein muss, wie es bei GrapheneOS für die meisten Leute wäre.
Hm, dann kenn Ich mich nicht gut genug mit Androids Architektur an der Stelle aus, und muss dann eventuell sogar meine Aussage zurückziehen?
Bei GrapheneOS muss man noch einen Schlüssel flashen, k.A. wo genau dieser landet. Das müsste man bei Googles Image afaik. nicht tun, da der bereits vorhanden ist.
Falls dem nicht so ist, dass ein Schlüssel bereits in der Hardware, oder irgendwo auf den Speicher unangetastet vorliegt… dann sind diese Hersteller für mich inkompetent, wenn sie keine Signaturen für Ihre Downloads auf der Webseite anbieten, ja. Ohne jeden Zweifel.
Edit: https://source.android.com/docs/security/features/verifiedboot?hl=de hier lese Ich übrigens vom Bootloader, einer Bootpartition, und anderen Partitionen (System, OEM, Vendor).
Für gewöhnlich wird der Bootloader ja nur entsperrt, evtl. ein Schlüssel hinzugefügt (bei third-party Betriebssystemen wie GOS, wenn er wieder geschlossen werden soll), und die Bootpartition geflasht?
Aber ist auch Egal.
), aber du es trotzdem irgendwie verifizieren möchtest: Du könntest mir vertrauen.