Aufpoliert: Alte PGP-Schlüssel mit neuen Signaturen
Der eigene PGP-Schlüssel ist Statussymbol und Aushängeschild. Wie peinlich, wenn der dann mit veralteten SHA1-Signaturen beglaubigt ist. Mit wenigen Handgriffen bringen Sie das in Ordnung.
Das bis vor einigen Jahren noch weit verbreitete GPGv1 erstellte standardmäßig Signaturen mit dem Hash-Verfahren SHA1. Das ist jedoch mittlerweile so veraltet, dass es nicht mehr zum Einsatz kommen sollte. Trotzdem sind immer noch viele aktuelle PGP-Schlüssel mit diesem Verfahren selbst-signiert. Um es gleich vorweg ganz klar zu sagen: In diesem Kontext ist die Verwendung von SHA1 kein Sicherheitsproblem. Aber ein PGP-Schlüssel ist für ITler auch ein Status-Symbol. Und genauso wie ein Designer keine Visitenkarten mit Comic Sans verteilt, will man als IT-Experte auch keine PGP-Schlüssel mit SHA1-Signaturen in Umlauf bringen. Sogar Microsoft wird demnächst die SHA1-Signaturen ihrer Windows-Updates einstellen.
Wer also Wert auf den Stand der Technik legt, sollte Schlüssel mit SHA1-Eigen-Signatur nicht mehr verwenden. Das einfachste ist, sich neue Schlüssel mit dem aktuellen GPGv2 zu erstellen, das aus Sicherheitssicht sinnvolle Voreinstellungen hat. Insbesondere unterschreibt es alle Schlüssel standardmäßig mit einem SHA256- respektive SHA512-Hash (die Rolle der Hashes bei Signaturen erklärt der Anhang PGP und die Hashes auf der letzten Seite).
SHA1 aufspüren
Allerdings erzeugt ein Schlüsseltausch einiges an Arbeit, die man vielleicht gerne vermeiden möchte. Denn wenn man es ernst meint, sollte man erneut mit allen Kommunikationspartnern Fingerabdrücke vergleichen. Wer sich das ersparen will, kann auch seinen alten Schlüssel mit einigen Handgriffen mit neuen Signaturen ausstatten. Voraussetzung ist allerdings, dass er bereits einen RSA-Schlüssel mit mindestens 2048 Bit enthält; ansonsten sollte man den Schlüssel tatsächlich lieber ausrangieren.
Herauszufinden, mit welchem Hash-Verfahren die Eigen-Signaturen eines Schlüssels erzeugt wurden, gestaltet sich überraschend schwierig. Denn direkt angezeigt wird es eigentlich nirgends – jedenfalls nicht in Enigmail oder den typischen Schlüsselverwaltungs-Tools. Nicht einmal GPG lässt sich diese wichtige Information direkt entlocken. Erst eine genaue Signaturprüfung verrät Codes aus denen Eingeweihte die richtigen Schlüsse ziehen können.
Für das weitere muss man früher oder später den Komfort der grafischen Schlüsselverwaltungs-Tools hinter sich lassen und das Kommandozeilen-Werkzeug gpg nutzen. Deshalb beschreibt der folgende Text den kompletten Vorgang mit gpg. Das ist bei Linux und MacOS standardmäßig mit dabei und wird bei Windows etwa via GPG4Win respektive Enigmail mitinstalliert.
Als erstes sollte man sicherstellen, dass man bereits mit der aktuellen GnuPG-Version 2 arbeitet. Wenn
$ gpg --version
nicht etwas wie gpg (GnuPG) 2.X.Y ausspuckt, steht vor den weiteren Schritten ein Upgrade an. Den eigenen Schlüssel findet man am schnellsten mit
$ gpg --list-secret-keys
Wenn man mehrere davon hat, sucht man sich den gewünschten aus und ergänzt später die GPG-Befehle zum Unterschreiben mit der Option --local-user <KeyID>. Das stellt sicher, dass der Schlüssel die richtige Unterschrift bekommt.
Die aktuellen Signaturen des Schlüssels zeigt
$ gpg --list-signatures <KeyID>
Die Ausgabe ist schon etwas erklärungsbedürftig. Zunächst kommt der Haupt-Schlüssel (primary key):
pub rsa4096 2013-09-10 [SC]
576822F9E1374764
Dann kommen die einzelnen UIDs des Nutzers jeweils mit einer Eigen-Signatur und eventuell weiteren wie bei diesem Schlüssel einer Unterschrift der c't-Kryptokampagne:
uid [uneingeschränkt] Juergen Schmidt (heise online) <ju@heise.de>
sig 3 576822F9E1374764 2019-03-05 Juergen Schmidt (heise online) <ju@heise.de>
sig 3 2BAE3CF6DAFFB000 2013-10-14 ct magazine CERTIFICATE <pgpCA@ct.heise.de>
uid [uneingeschränkt] Juergen Schmidt (Redaktion ct) <ju@ct.de>
sig 3 576822F9E1374764 2019-03-05 Juergen Schmidt (heise online) <ju@heise.de>
...
Und schließlich folgt der Encryption-Key, der auch nochmal beglaubigt wurde.
sub rsa4096 2013-09-10 [E] [verfällt: 2019-06-03]
sig 576822F9E1374764 2019-03-05 Juergen Schmidt (heise online) <ju@heise.de>
Bei manchen Schlüsseln gibt es auch noch einen eigenen Signing-Key; andere vereinen alle Aufgaben im Haupt-Schlüssel, der dann mit [SCE] markiert ist (mehr dazu in Anatomy of a GPG key). Doch wie man sieht, sieht man keine Hash-Verfahren.
Um die Signaturen genauer zu checken, besorgt man sich am besten den öffentlichen Schlüssel in einer Textdatei. Die kann man entweder von einem Keyserver laden oder aus dem eigenen Schlüsselbund extrahieren.
$ gpg --export --armor <KeyID> > mykey.asc
Anschließend kann man GPG auf diese Schlüsseldatei loslassen
$ gpg --list-packets mykey.asc
und bekommt einen sogenannten Packet-Dump zu sehen, der einen wahrscheinlich zunächst verwirrt. Wichtig sind in diesem Zusammenhang nur die Signatur-Pakete, die vom eigenen Schlüssel erstellt wurden. Und dort interessiert dann eigentlich nur die Angabe digest algo, die das verwendete Hash-Verfahren spezifiziert. Diese Angaben sucht man von Hand in der Ausgabe oder filtert sie unter Linux etwa mit einem angehängten
| grep -A2 ':signature packet:.*<KeyID>'
und erhält etwas wie:
:signature packet: algo 1, keyid 576822F9E1374764
version 4, created 1381741909, md5len 0, sigclass 0x13
digest algo 2, begin of digest 9b 07
Hier hat es einen SHA1-Sünder erwischt: digest algo 2 steht für SHA1 und ist böse. Gut wäre etwa digest algo 10 für SHA512; 9 und 8 für SHA384/256 sind auch okay. Bei diesem Schlüssel besteht also akuter Handlungsbedarf.
