Version 1.2, 10.01.2016
Nach (standardmäßig) zwei Jahren läuft die Gültigkeit der nach den Empfehlungen dieser Website oder mit dem bereitgestellten Script erzeugten Haupt- und Unterschlüssel ab. Irgendwann wird das Script mal eine Funktion bekommen, um die Verlängerung zu automatisieren; bis dahin muss man es per Hand machen (oder mit einem GUI, was aber in der CD-Version von Knoppix 7.2 nicht zur Verfügung steht). Manche Teilnehmer der Schulung haben Verlängerungssignaturen, die nur noch aktiviert werden müssen. Diese liegen im Verzeichnis export/expire und müssen nur entschlüsselt und importiert werden.
Um den Schlüssel zu bearbeiten, brauchen Sie den Hauptschlüssel; zum Umgang mit den unterschiedlichen Passphrasen siehe hier. Es ist gerade der Zweck eines Offline-Hauptschlüssels, dass er im normalen System nicht zur Verfügung steht. Und er darf da auch nicht zur Verfügung stehen, weil er ansonsten wertlos würde. Dass er dort als verschlüsselte Datei vorhanden ist, ist unproblematisch, solange in dem normalen, unsicheren System die Passphrase des Offline-Hauptschlüssels nie eingegeben (und natürlich auch nicht gespeichert) wird.
Bei der Schlüsselerzeugung bekommen die Teilnehmer einen Ordner openpgp-scripte mit folgender Struktur (gekürzt auf den relevanten Teil):
| openpgp-scripte/ | |||
| export/ | |||
| import/ | |||
| 0x????????.public.asc | |||
| gpg.conf | |||
| certs/ | |||
| secure-environment-only/ | |||
| 0x????????.secret-mainkey.asc | |||
| expire/ | |||
| sigs/ | |||
| misc/ |
Das heißt, Sie booten ein sicheres System, kopieren (von einem USB-Stick oder von der Festplatte des normalen Rechners, wenn Sie den von einem sicheren Medium gebootet haben) die export/import/gpg.conf dort in ~/.gnupg (also die ggf. vorhandene überschreiben) und importieren den öffentlichen und den privaten Hauptschlüssel (der folgende Konsolenverlauf ist nicht aus Knoppix, sondern openSUSE; dadurch ergeben sich kleine Abweichungen in der Ausgabe):
vm-0:~ # cd /verzeichnis/des/usb-sticks # oder wohin Sie die Dateien von dort kopiert haben vm-0:/verzeichnis/des/usb-sticks # gpg --list-keys # damit ~/.gnupg angelegt wird gpg: Verzeichnis /root/.gnupg/gpg.conf' erstellt gpg: WARNUNG: Optionen in /root/.gnupg/pubring.gpg' erstellt gpg: /root/.gnupg/trustdb.gpg: trust-db erzeugt vm-0:/verzeichnis/des/usb-sticks # cp gpg.conf ~/.gnupg vm-0:/verzeichnis/des/usb-sticks # gpg --import 0x3D320B34.public.asc gpg: Schlüssel 3D320B34: Öffentlicher Schlüssel "Joe User (Demoschlüssel) <joe@example.org>" importiert gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1 gpg: importiert: 1 (RSA: 1) vm-0:/verzeichnis/des/usb-sticks # gpg --import 0x3D320B34.secret-mainkey.asc gpg: Schlüssel 3D320B34: geheimer Schlüssel importiert gpg: Schlüssel 3D320B34: "Joe User (Demoschlüssel) <joe@example.org>" nicht geändert gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1 gpg: unverändert: 1 gpg: gelesene geheime Schlüssel: 1 gpg: geheime Schlüssel importiert: 1 vm-0:/verzeichnis/des/usb-sticks # cd
Der Schlüssel wird als verfallen angezeigt (in diesem Fall; man kann – und sollte! – ihn natürlich auch schon verlängern, bevor er abläuft); in der Standardkonfiguration sind die abgelaufenen Unterschlüssel nicht einmal mehr zu sehen. Man braucht Tricks, um sie anzeigen zu lassen:
vm-0:~ # gpg --list-keys /root/.gnupg/pubring.gpg ------------------------ pub 1024R/3D320B34 2013-03-20 [verfallen: 2014-03-20] uid Joe User (Demoschlüssel) <joe@example.org> vm-0:~ # gpg --list-options show-unusable-subkeys --list-keys /root/.gnupg/pubring.gpg ------------------------ pub 1024R/3D320B34 2013-03-20 [verfallen: 2014-03-20] uid Joe User (Demoschlüssel) <joe@example.org> sub 1024R/EB105005 2013-03-20 [verfallen: 2014-03-20] sub 1024R/23A29D89 2013-03-20 [verfallen: 2014-03-20]
Wenn in dem sicheren System die Passphrase nicht gecacht wird (weil gpg-agent nicht läuft, wie im Fall der Knoppix-CD), dann kann man sich Zeit und Frust ersparen, indem man zunächst die Passphrase auf irgendwas Kurzes (foo
) ändert, um nicht die kryptografisch sichere Passphrase viermal (plus Vertipper) eingeben zu müssen). Diese Änderung wird nur im laufenden System gespeichert. Wenn das also nur ins RAM schreibt (wie Knoppix), dann ist dies sicherheitsmäßig unbedenklich.
vm-0:~ # gpg --edit-key 0x3D320B34 passwd
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Geheimer Schlüssel ist vorhanden.
pub 1024R/3D320B34 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: verfallen
[verfall.] (1). Joe User (Demoschlüssel) <joe@example.org>
Schlüssel ist geschützt.
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Joe User (Demoschlüssel) <joe@example.org>"
1024-Bit RSA Schlüssel, ID 3D320B34, erzeugt 2013-03-20
Geben Sie die neue Passphrase für diesen geheimen Schlüssel ein.
gpg> save
vm-0:~ #
So sieht es in der Konsole aus, wenn die Passphrase über die grafische Oberfläche abgefragt wird. Ist das nicht möglich, fände auch diese Abfrage über die Konsole statt, was aber am Ablauf nichts ändert.
Nun wird der Schlüssel mit --edit-key bearbeitet. Zuerst wird der Hauptschlüssel verlängert, danach die Unterschlüssel (jeweils einzeln; das geht leider offenbar nicht gleichzeitig):
vm-0:~ # gpg --edit-key 0x3D320B34
gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Geheimer Schlüssel ist vorhanden.
pub 1024R/3D320B34 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: verfallen
sub 1024R/EB105005 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: E
sub 1024R/23A29D89 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: S
[verfall.] (1). Joe User (Demoschlüssel) <joe@example.org>
gpg> expire
Ändern des Verfallsdatums des Hauptschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
0 = Schlüssel verfällt nie
<n> = Schlüssel verfällt nach n Tagen
<n>w = Schlüssel verfällt nach n Wochen
<n>m = Schlüssel verfällt nach n Monaten
<n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1y
Key verfällt am Sa 21 Mär 2015 02:38:43 CET
Ist dies richtig? (j/N) j
pub 1024R/3D320B34 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 1024R/EB105005 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: E
sub 1024R/23A29D89 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: S
[ uneing.] (1). Joe User (Demoschlüssel) <joe@example.org>
gpg> key 1
pub 1024R/3D320B34 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 1024R/EB105005 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: E
sub 1024R/23A29D89 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: S
[ uneing.] (1). Joe User (Demoschlüssel) <joe@example.org>
gpg> expire
Ändern des Verfallsdatums des Unterschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
0 = Schlüssel verfällt nie
<n> = Schlüssel verfällt nach n Tagen
<n>w = Schlüssel verfällt nach n Wochen
<n>m = Schlüssel verfällt nach n Monaten
<n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1y
Key verfällt am Sa 21 Mär 2015 02:39:04 CET
Ist dies richtig? (j/N) j
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Joe User (Demoschlüssel) <joe@example.org>"
1024-Bit RSA Schlüssel, ID 3D320B34, erzeugt 2013-03-20
pub 1024R/3D320B34 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 1024R/EB105005 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: E
sub 1024R/23A29D89 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: S
[ uneing.] (1). Joe User (Demoschlüssel) <joe@example.org>
gpg> key
pub 1024R/3D320B34 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 1024R/EB105005 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: E
sub 1024R/23A29D89 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: S
[ uneing.] (1). Joe User (Demoschlüssel) <joe@example.org>
gpg> key 2
pub 1024R/3D320B34 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 1024R/EB105005 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: E
sub* 1024R/23A29D89 erzeugt: 2013-03-20 verfallen: 2014-03-20 Aufruf: S
[ uneing.] (1). Joe User (Demoschlüssel) <joe@example.org>
gpg> expire
Ändern des Verfallsdatums des Unterschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
0 = Schlüssel verfällt nie
<n> = Schlüssel verfällt nach n Tagen
<n>w = Schlüssel verfällt nach n Wochen
<n>m = Schlüssel verfällt nach n Monaten
<n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1y
Key verfällt am Sa 21 Mär 2015 02:39:17 CET
Ist dies richtig? (j/N) j
Die Kommandos am gpg-Prompt zusammengefasst:
gpg> expire
gpg> key 1
wählt den ersten Unterschlüssel aus
gpg> expire
gpg> key
deselektiert alle Unterschlüssel
gpg> key 2
gpg> expire
Falls man mehr Unterschlüssel hat, kann es natürlich sein, dass entsprechend andere Nummern eingegeben werden müssen.
Danach müssen die Änderungen in den Keyring geschrieben werden:
pub 1024R/3D320B34 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 1024R/EB105005 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: E
sub* 1024R/23A29D89 erzeugt: 2013-03-20 verfällt: 2015-03-21 Aufruf: S
[ uneing.] (1). Joe User (Demoschlüssel) <joe@example.org>
gpg> save
Danach muss das aktualisierte Zertifikat (der öffentliche Schlüssel) exportiert und auf den USB-Stick (oder direkt ins Arbeitssystem, wenn möglich) kopiert werden; an den geheimen Schlüsseln ändert sich nichts, die brauchen also nicht exportiert zu werden:
vm-0:~ # gpg --armor --export 0x3D320B34 >0x3D320B34.public--2014-03-21.asc