Bookworm Image Prüfsummen-Datei verifizieren

[Oystercatcher]

Hallo Forum,

in der Vergangenheit habe ich nach dem Herunterladen eines Debian Images lediglich mit Hilfe von SHA512SUM bzw. SHA256SUM die Prüfsumme gebildet und diese mit der ebenfalls heruntergeladenen Prüfsummen-Datei verglichen. Heute habe ich nun ein aktuelles Bookworm Image heruntergeladen und möchte diesmal "lehrbuchmäßig" vorgehen, soll heißen, ich möchte vor dem Prüfsummen Abgleich die Prüfsummen-Datei verifizieren, wie es ja auch unter https://www.debian.org/CD/verify empfohlen wird. Leider konnte ich auf keiner offiziellen Seite in Erfahrung bringen, wie ich hierzu vorgehen muss. Ich habe daher ein wenig recherchiert und bin dann folgendermaßen vorgegangen (debian-12.2.0-amd64-netinst.iso, SHA512SUMS und SHA512SUMS.sign liegen im selben Ordner):

Code: Alles auswählen

$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signatur vom Sa 07 Okt 2023 22:24:41 CEST
gpg:                mittels RSA-Schlüssel DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

$ gpg --keyserver keyring.debian.org --recv-keys DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: /home/oystercatcher/.gnupg/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel DA87E80D6294BE9B: Öffentlicher Schlüssel "Debian CD signing key <debian-cd@lists.debian.org>" importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                              importiert: 1

$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signatur vom Sa 07 Okt 2023 22:24:41 CEST
gpg:                mittels RSA-Schlüssel DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Korrekte Signatur von "Debian CD signing key <debian-cd@lists.debian.org>" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg:          Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck  = DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B

Ist das so die korrekte Vorgehensweise bzw. sind die Ausgaben korrekt? Ich bin bei meiner Recherche auf einen Blogeintrag zum Thema gestoßen, dort wird von gpg jedoch immer wieder eine relativ kurzer Schlüssel (6294BE9B) ausgegeben, an dessen Stelle in meinem Fall ein deutlich längerer Schlüssel (oder Fingerabdruck?) angezeigt wird.

Für Aufklärung wäre ich dankbar!

[rhHeini]

Nimm Dir gtkhash.

[tobo]

Es gibt die short key ID mit 8hex, die long key ID mit 16hex und den fingerprint mit 40hex. Short soll man nicht mehr benutzen, da man ziemlich schnell Kollisionen erzeugen kann. Du hast den fingerprint benutzt, die long key ID wäre DA87E80D6294BE9B. Die ISO musst du jetzt natürlich auch noch prüfen...

[uname]

Ich denke die wenigsten Anwender werden diese Überprüfung durchführen obwohl sie eigentlich notwendig ist. Ein gewisser Teil der Anwender prüft vielleicht minimal die SHA256SUMS. Aber solange diese Datei auf dem gleichen Server liegt, können natürlich sowohl das ISO als auch der die SHA256SUM geändert werden. Eine Suche nach der korrekten SHA256SUM führt leider auch nur zu wenigen Ergebnissen, um die Überprüfung auf eine Internet-Suche einzuschränken. Bzgl. Kollisionen ist im Übrigen das Geburtstagsparadoxon ganz interessant. Trotzdem ist es doch sehr unwahrscheinlich. Als Angreifer eine Kollision finden für eine gefakte ISO-Datei? Das halte ich für kein realistisches Angriffsszenario.

Im Jahr 2016 wurde die Webseite von Linux Mint gehackt und den Anwendern ein falsches ISO untergeschoben. Hier der damalige Beitrag auf Heise und hier die Erklärung von Linux Mint. Würde man ISO und SHA256SUM auf unterschiedliche Server speichern und Anwender würden mindestens SHA256SUM prüfen, dann wäre sowas wohl nicht passiert es sei denn der Hacker kann beide Webseiten übernehmen. Ich glaub in dem Fall lag die SHA256SUM auch auf dem gehackten Webserver. Dann ist es für den Angreifer leicht auch die SHA256SUM auszutauschen für die Anwender, die sich die Mühe machen nur die SHA256SUM zu prüfen.

Wirklich gelernt hat man daraus wohl nicht bzw. glaubt die Anwender würde zur Kontrolle wirklich diese Anleitung verwenden. Ein Unterschied zu früher ist aber vielleicht, dass SHA256SUM und ISO nur auf Mirror-Servern (bisschen scrollen) wie z. B. hier bereitgestellt werden. Trotzdem hätte man die Prüfsummen unabhängig von den Mirror-Servern auf einem anderen Server - diesmal vielleicht dem Webserver - bereitstellen können. Angreifer müssten dann beide Systeme hacken und der alleinige Hack des Webservers wäre unkritisch. Hilft aber auch nur dann, wenn die Anwender tatsächlich das ISO mit md5sum prüft und nur mit der SHA256SUM abgleicht ohne die obige Anleitung zu verwenden.

[tobo]

Ich denke die wenigsten Anwender werden diese Überprüfung durchführen obwohl sie eigentlich notwendig ist. Ein gewisser Teil der Anwender prüft vielleicht minimal die SHA256SUMS. Aber solange diese Datei auf dem gleichen Server liegt, können natürlich sowohl das ISO als auch der die SHA256SUM geändert werden.

Weswegen da ja auch noch eine *.sign rumliegt, wodurch das Problem umgangen wird: Jetzt wird nicht nur die Unversehrtheit, sondern auch die Urheberschaft geprüft.

Zu den Kollisoinen bei kurzen IDs - das ist eine Sache von Sekunden:
https://evil32.com/
https://www.heise.de/news/Haufenweise-F ... 97175.html

[Oystercatcher]

Danke für Eure Antworten und entschuldigt bitte meine späte Rückmeldung.

Die Problematik der unterschiedlichen Schlüssellängen bzw. kurzen Schlüssel war mir so bislang nicht bekannt. Sehe ich richtig, dass PGP diesbezüglich irgendwann in den letzten 5 Jahren mal angepasst wurde? In dem von mir verlinkten Blog Eintrag hat der Autor ja ein Debian 9 Image als Beispiel herangezogen. Dort wurde ihm von PGP ("gpg --verify SHA512SUMS.sign") die (short) key ID (6294BE9B) ausgegeben. In meinem Fall ja anscheinend der Fingerprint (DF9B9C49EAA9298432589D76DA87E80D6294BE9B) wobei dieser dennoch als "RSA Schlüssel" bezeichnet wurde. Werden da nicht irgendwie die Begrifflichkeiten durcheinander geworfen?

[tobo]

Die Problematik der unterschiedlichen Schlüssellängen bzw. kurzen Schlüssel war mir so bislang nicht bekannt.

Es geht nicht um Schlüssellängen, sonderm um den Hash, die Darstellung eines Schlüssels. Du hast z.B. eine große Datei und stellst die durch einen verhältnismäßig kurzen Hash dar. Also (beispielhaft z.B.) eine Datei 235 durch den Hash 8 - eine 3-stellige Zahl wird repräsentiert durch eine einstellige Zahl. Wenn jede 3-stellige Zahl durch einen einstelligen Hash dargestellt wird, dann ist aber auch klar, dass der Beispiel-Hash 8 auch noch auf sehr viel mehr 3-stellige Zahlen zutreffen muss. Der große Zahlenraum wird auf den Kleinen abgebildet - für jeden einstelligen Hash gibt es ~100 3-stellige Zahlen. Der Punkt ist jetzt, dass man von einer Zahl den Hash findet (wegen der Rechenvorschrift), aber nicht rückwärts (wegen fehlender Rechenvorschrift) von einem Hash auf eine Zahl kommt. Bei 3-stelligen Zahlen, mit einstelligem Hash, könnte man jetzt einfach durchprobieren. Bei genügend großen Zahlen/Hashs kann man man aber keine Dateien (Keys) finden/erzeugen, die auf den gesuchten Hash ebenfalls zutreffen.
Dieser Hash, das ist dann der Fingerprint. Die Key-IDs sind nur Ausschnitte dieses Fingerprints (von hinten) und damit mit minderer Sicherheit, da weniger Stellen. In deinem Beispiel:

Code: Alles auswählen

DF9B9C49EAA9298432589D76DA87E80D6294BE9B  ## Fingerprint
                        DA87E80D6294BE9B  ## Long Key-ID
                                6294BE9B  ## Short Key-ID

Von den Hash-Verfahren jetzt mal abgesehen - umso kürzer der Hash, umso einfacher die Generierung eines passenden Keys. Im Beispiel passt ein einstelliger Hash auf 100 Keys, ein 2-steliger Hash aber nur noch auf 10 Keys.

Sehe ich richtig, dass PGP diesbezüglich irgendwann in den letzten 5 Jahren mal angepasst wurde?

Ja, die "Darstellung" wurde geändert. Wenn du aber erstmal nur die kurze ID hast, dann musst du dir halt auch darüber den/die Schlüssel besorgen.

In dem von mir verlinkten Blog Eintrag hat der Autor ja ein Debian 9 Image als Beispiel herangezogen. Dort wurde ihm von PGP ("gpg --verify SHA512SUMS.sign") die (short) key ID (6294BE9B) ausgegeben. In meinem Fall ja anscheinend der Fingerprint (DF9B9C49EAA9298432589D76DA87E80D6294BE9B) wobei dieser dennoch als "RSA Schlüssel" bezeichnet wurde. Werden da nicht irgendwie die Begrifflichkeiten durcheinander geworfen?

Theoretisch ja, praktisch nein, da vom Hash ja kein Rückschluss auf den Key möglich ist.