Seite 2: Der expire-Trick

Inhaltsverzeichnis

Der expire-Trick

Bevor man jetzt Änderungen vornimmt, sollte man eine Sicherheitskopie der kompletten Konfiguration inklusive aller Schlüssel anlegen. Unter Linux erledigt das:

$ cp -a ~/.gnupg ~/.gnupg-ORG

Damit kann man bei Problemen jederzeit zum alten Zustand zurück. Unter Windows liegt das Verzeichnis in %APPDATA%\gnupg – man muss es jedoch unter Umständen erst sichtbar machen. Anschließend sorgt man für eine Konfiguration, die SHA1 komplett ächtet. Dazu trägt man in ~/.gnupg/gpg.conf folgendes ein:

# Liste der bevorzugten Algorithmen für neue Schlüssel
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
# Bevorzugte Verschlüsselungsalgorithmen
personal-cipher-preferences AES256 AES192 AES CAST5
# Bevorzugte Hashalgorithmen
personal-digest-preferences SHA512 SHA256 SHA384 SHA224
# Hashalgorithmus zur Signatur von Schlüsseln
cert-digest-algo SHA512 

Wichtig ist, dass in dieser Konfiguration SHA1 nicht mehr vorkommt. Auch GPGv2 enthält das veraltete Hash-Verfahren noch als Fallback. Wenn es jedoch nicht mehr erlaubt ist, zwingt man gpg dazu, neue Signaturen mit einem besseren Verfahren zu erstellen. Diesen Signatur-Vorgang lösen dann die folgenden Befehle aus, die ein neues Ablaufdatum setzen. Sie können dabei einen beliebige Frist wie 90 Tage setzen und diese danach sofort wieder auf den ursprünglichen Wert zurücksetzen.

$ gpg --edit-key <KeyID>
gpg> expire
...
sec  rsa4096/576822F9E1374764
     erzeugt: 2013-09-10  verfällt: 2019-06-03  Nutzung: SC  
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa4096/8B7EB38F7E60DABF
     erzeugt: 2013-09-10  verfällt: niemals     Nutzung: E   
...

Wie man sieht, wurde hier nur einer der beiden Keys (der mit der Kennung sec) geändert und signiert. Wenn es wie hier einen Unter-Schlüssel gibt, wählt man ihn mit:

gpg> key 1
sec  rsa4096/576822F9E1374764
     erzeugt: 2013-09-10  verfällt: 2019-06-03  Nutzung: SC  
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb* rsa4096/8B7EB38F7E60DABF
     erzeugt: 2013-09-10  verfällt: niemals  Nutzung: E   

Der Stern bei ssb* zeigt, dass jetzt der andere Key aktiv ist. Ein erneutes "expire" unterschreibt auch den neu. Das macht man dann für alle Sub-Keys und vermerkt anschließend die neuen Präferenzen im Schlüssel:

gpg> setpref
Setze die Liste der Voreinstellungen auf:
     Verschlü.: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Komprimierung: ZLIB, BZIP2, ZIP, nicht komprimiert
     Eigenschaften: MDC, Keyserver no-modify
Die Voreinstellungen wirklich ändern? (j/N) 

Dann noch die überflüssigen SHA1-Signaturen entfernen lassen

gpg> clean
User-ID "Juergen Schmidt (heise online) <ju@heise.de>": 4 Signaturen entfernt
... 

und das ganze mit "save" abspeichern. Danach sollte der Schlüssel mit neuen SHA512-Signaturen versehen sein. Man testet das am besten nochmal explizit mit:

$ gpg --export <KeyID> | gpg --list-packets | grep -A 2 signature 

und erhält im Idealfall nur noch SHA512-Signaturen aka "digest algo 10":

:signature packet: algo 1, keyid 343B45801E25E7D7
    version 4, created 1551979115, md5len 0, sigclass 0x13
    digest algo 10, begin of digest 33 ad
:signature packet: algo 1, keyid 343B45801E25E7D7
    version 4, created 1551979136, md5len 0, sigclass 0x18
    digest algo 10, begin of digest 48 b5

Wer möchte, kann jetzt das ganze auch wiederholen und das Expire-Datum auf den ursprünglichen Wert zurücksetzen. Es ist übrigens auch möglich, mit dem gpg-Kommando "sign" die Unterschlüssel der UIDs zu unterschreiben; um das bei bereits unterschriebenen UIDs zu machen, muss man gpg mit --expert starten.

Veröffentlichen

Wenn der Kontrollaufruf immer noch SHA1-Signaturen enthält, dann handelt es sich ziemlich sicher um Signaturen von Dritten, was man an der fremden Key-ID erkennt:

:signature packet: algo 17, keyid 2BAE3CF6DAFFB000
    version 4, created 1381749853, md5len 0, sigclass 0x13
    digest algo 2, begin of digest ca 25

Die kann man natürlich nicht selbst erneuern, sondern muss im Zweifelsfall den Unterschreibenden um eine neue Signatur bitten. Sprechen Sie ruhig die Eigentümer der Schlüssel mal darauf an, dass die bei Gelegenheit ihre eigenen Signatur-Einstellungen checken. Falls es sich wie in diesem Beispiel

$ gpg --list-key 2BAE3CF6DAFFB000
pub   dsa1024 2006-02-27 [SCA]
      2BAE3CF6DAFFB000
uid        [ vollständig ] ct magazine CERTIFICATE <pgpCA@ct.heise.de>

um eine etwas ältere Signatur der c't-Kryptokampagne handelt: Die signiert aktuell bereits mit einem RSA4096-Key und SHA-512. Kommen Sie doch einfach mal vorbei, um sich eine Unterschrift abzuholen.

Vergessen Sie nicht, nach all der Arbeit den neuen Schlüssel auch in Umlauf zu bringen. Sie können ihn dazu wie oben beschrieben aus dem Schlüsselbund exportieren und Ihren Kommunikationspartnern direkt zukommen lassen. Der Befehl

$ gpg --keyserver hkps://hkps.pool.sks-keyservers.net --send-keys <KeyID>

schiebt den SHA512-signierten Schlüssel direkt in den SKS-Pool der PGP-Keyserver. Damit sollte er spätestens am nächsten Tag der ganzen Welt bereit stehen. Man kann diesen Schlüssel dann wie gewohnt verwenden; wer nicht genau hinschaut wird keinen Unterschied bemerken. Nicht einmal der Fingerprint hat sich geändert.

Allerdings bleibt da ein kleiner Schönheitsfleck: Die Keyserver entfernen die alten SHA1-Signaturen nicht; sie fügen grundsätzlich immer nur neue hinzu. Auf den Keyservern werden Ihre Keys dann also zukünftig beide Eigen-Signaturen aufweisen: eine alte mit SHA1 und eine neue mit SHA2. Da das nicht schadet, kann man das durchaus als Zeichen für einen in erfahrenen PGP-Nutzer interpretieren, der sich um die Pflege seiner Schlüssel kümmert.