Version 1.2, 11.10.2013
Um einerseits ein kurzes Dokument zum Ausdrucken zu haben und andererseits nachvollziehen zu können, warum das so passiert, gibt es diese zweite Version der Anleitung, in der die relevanten Kommandos erklärt sind. Das Schlüsselerzeugungs-Script verwendet (von irrelevanten Details abgesehen) genau diese Kommandos.
Zumindest bei der gleichzeitigen Schlüsselerzeugung an mehreren Rechnern bietet es sich an, die einzelnen User auf Papier notieren lassen, bei welchem Punkt sie gerade sind.
Hinweis zur Nomenklatur: Die Schreibweise gpg --edit-key ... cmd1; cmd2; cmd3
ist so zu lesen, dass das Shellkommando gpg --edit-key 0x12345678
oder gpg --edit-key 0x12345678 cmd1
ist und dann, nach Abarbeitung von cmd1
am gpg-Prompt (gpg>
) die folgenden Kommandos (ohne ;
) einzeln einzugeben sind (gpg> cmd2
). Wenn cmd1
einen *
enthält (key *
), dann muss der natürlich maskiert werden, wenn cmd1
schon in der Shell eingegeben wird und nicht erst am gpg-Prompt.
Hauptschlüssel erzeugen (UID ohne E-Mail; für Signaturen und Verschlüsselung); simple Passphrase (foo
)
gpg --gen-key
; Gültigkeit auf ein Jahr begrenzen
Bei der Erzeugung des Hauptschlüssels kann nur eine User-ID angegeben werden. Die ist nicht wichtiger als diejenigen, die später hinzugefügt werden. Welche die Haupt-ID ist, wird am Ende gesondert festgelegt.
Konfigurationsdatei anpassen
policy URL (mit der key ID)
Es ist sinnvoll, die ID des Schlüssels in der policy URL zu haben (ebenso bei der URL des Keyservers, falls man keinen richtigen Keyserver angibt, sondern eine URL auf einen Webserver). Die ID weiß man aber erst nach der Erzeugung des Hauptschlüssels.
ggf. Schlüsselrichtlinie anpassen
key ID
Natürlich sollte die ID (sogar der ganze Fingerprint) in der Schlüsselrichtlinie stehen. Die ID weiß man aber erst nach der Erzeugung des Hauptschlüssels.
Eigensignatur löschen und neu erzeugen
Damit die policy URL drin ist: --edit-key ... uid *; delsig; sign; save
Man bekommt die policy URL nur in den Schlüssel, indem man eine neue Eigensignatur erzeugt. Das erlaubt GnuPG aber nur dann, wenn keine vorhanden ist, also muss die bestehende gelöscht werden. Auch wenn dies nicht erforderlich wäre, gäbe es keinen Grund, die alte Eigensignatur zu behalten, weil die nie in die Öffentlichkeit gelangen soll. Sicher vor Manipulation ist man nur dann, wenn alle User-IDs die policy URL enthalten.
Unterschlüssel mit je einer Fähigkeit und einem Jahr Gültigkeit erzeugen
gpg --edit-key ... addkey; save
Es hat Vorteile, Entschlüsselung und Signierung nicht mit demselben Schlüssel zu betreiben. Wenn man einen Signaturschlüssel auslaufen lässt und durch einen neuen ersetzt, kann man ihn löschen. Bei einem Entschlüsselungs-Schlüssel ist das heikel, weil immer mal der Bedarf aufkommen kann, alte Daten zu entschlüsseln. Man mag sich auch juristisch genötigt fühlen, einen Entschlüsselungs-Schlüssel herauszugeben (in Ländern zweifelhafter Rechtsstaatlichkeit wie den USA und GB); es gibt aber nie einen Grund, einen Signaturschlüssel herauszugeben. Das wäre quasi Identitätsklau.
ggf. UIDs für die anderen E-Mail-Adressen erzeugen
gpg --edit-key ... adduid; save
Bei langlebigen Schlüssel ist es wichtig, dass man sich gut überlegt, welche Adressen man in dasselbe Zertifikat nimmt.
ggf. primäre User-ID festlegen
gpg --edit-key ... uid 2; primary; save
Normalerweise wird standardmäßig die zuletzt angelegte (bzw. bearbeitete) User-ID angezeigt. Man kann aber eine als primäre markieren. Diese Markierung (die später geändert werden kann) hat dann Priorität gegenüber der neusten Eigenbeglaubigung.
unnötige Signaturen löschen
gpg --edit-key ... minimize; save
Wenn der Ablauf genauso war wie hier beschrieben, dann dürfte jede User-ID nur eine Eigenbeglaubigung haben. Mit diesem Kommando – es schadet nicht; ggf. bewirkt es einfach nichts – kann man den Schlüssel vor dem Export "aufräumen".
kompletten (geheimen) Schlüssel temporär sichern (Aufwandsminimierung Passphrase)
gpg --armor --export-secret-keys ... > key-tmp.secret-mainkey.asc
Dadurch, dass der komplette Schlüssel mit der voreingestellten Passphrase (foo
) abgespeichert wird, erspart man den Teilnehmern unnötige Eingaben ihrer sicheren Passphrase: Anstatt nach dem Setzen der Passphrase mit dem gerade veränderten Schlüssel weiterzuarbeiten, wirft man ihn (nach dem Export) komplett weg und importiert die vorher gesicherte Version mit der Standardpassphrase. Diese Datei muss später sicher gelöscht werden (wenn sie nicht nur in eine RAMdisk geschrieben wird)!
öffentlichen Schlüssel sichern
gpg --armor --export ... > key.public.asc
Das ist das zu verbreitende Zertifikat.
exportierten öffentlichen Schlüssel signieren
gpg --armor --local-user 0x12345678\! --detach-sign key.public.asc
Das ist nicht wichtig und nicht üblich; vermutlich für die meisten auch verwirrend. Mit einer Hauptschlüsselsignatur über die Zertifikatsdatei kann man nachweisen, dass das jeweilige Zertifikat vollständig ist (man kann zwar nichts hinzufügen, aber unbemerkt Unterschlüssel und User-IDs entfernen). Man könnte damit (natürlich nicht direkt nach der Schlüsselerzeugung) auch nachweisen, dass ein Schlüssel noch aktuell ist (weil die Signatur ihr Erstellunsgdatum enthält), obwohl er lange nicht verändert wurde. Sozusagen das Gegenteil eines Widerrufszertifikats.
ggf. Schlüsselrichtlinie signieren
gpg --armor --local-user 0x12345678\! --detach-sign keypolicy_0x12345678.html
Die Schlüsselrichtlinie müsste man dafür natürlich erst noch anpassen (zumindest den Fingerprint eintragen); zumeist wird man dies erst später machen.
Passphrase für den Offline-Hauptschlüssel setzen
gpg --edit-key ... passwd; save
Sicher ist eine Passphrase ab 18 Stellen mit den Zeichen [0-9a-zA-Z], also Ziffern, Klein- und Großbuchstaben (ohne Umlaute, Sonderzeichen und sonstige Problemquellen), wenn die Passphrase rein zufällig ist. Auf einem sicheren System kann man sie vom Computer generieren lassen (gpg --armor --gen-random 1 18
). Es bietet sich an, darauf achten, keine verwechselbaren Zeichen (1IlkKO0) zu verwenden, weil es ziemlich lästig ist, in einer langen Passphrase den Fehler zu suchen. Auf jeden Fall sollten Sie sich auf den Zettel, auf dem Sie die Passphrase notieren, eine deutliche Erinnerung schreiben, dass diese Passphrase nie in einer unsicheren Umgebung eingegeben werden darf. Sie können dafür dieses Passphrase-Formular verwenden.
alle geheimen Schlüssel exportieren
gpg --armor --export-secret-keys ... > key.secret-mainkey.asc
Diese Exportdatei enthält alles: öffentliche Schlüssel, geheime Schlüssel, Hauptschlüssel, Unterschlüssel und User-IDs. Wenn später Unterschlüssel hinzugefügt werden, sollte vorher diese Datei importiert und anschließend durch eine neue Version ersetzt werden (mit demselben Kommando).
alle geheimen Unterschlüssel löschen
gpg --edit-key ... key *; delkey; save
Auf diese Weise ist es möglich, nur den Hauptschlüssel zu exportieren.
nur den geheimen Hauptschlüssel exportieren
gpg --armor --export-secret-keys ... > key.secret-mainkey-only.asc
Für die Erzeugung von Hauptschlüssel-Signaturen ist es hilfreich, wenn die Unterschlüssel gar nicht da sind (weil man sie nicht mit importiert hat). Auf diese Weise werden "Verwechselungen" unmöglich. Man braucht dann nur noch die Datei zu importieren, die keine Unterschlüssel enthält (was leicht zu prüfen ist).
Passphrase resetten (auf foo
)
gpg --delete-secret-key ...
gpg --import key-tmp.secret-mainkey.asc
Damit wird der Zustand vor dem Punkt Passphrase für den Offline-Hauptschlüssel setzen wiederhergestellt.
Passphrase für die Subkeys setzen
gpg --edit-key ... passwd
Verändert wird die Passphrase dadurch auch für den (gerade aktiven) Hauptschlüssel, aber der wird nicht mit exportiert.
Wenn diese Datei (später) nicht direkt ins Arbeitssystem, sondern auf z.B. einen USB-Stick kopiert wird (insbesondere einen fremden), dann sollte hier eine Passphrase verwendet werden, die ähnlich sicher ist wie die des Hauptschlüssels (natürlich nicht dieselbe). Nach dem Import ins Arbeitssystem kann man die dann auf den gewünschten Wert ändern.
geheime Subkeys exportieren
gpg --armor --export-secret-subkeys ... > key.secret-subkeys.asc
Diese Datei muss in das Arbeitssystem importiert werden.
Dies dürfte das einzige (wichtige) Kommando sein, dass die GUIs derzeit nicht anbieten. Im Prinzip kann man also so vorgehen, dass man den Rest im GUI macht und nur an dieser Stelle auf die Konsole ausweicht.
Dateien sichern (oder gleich ins Arbeitssystem kopieren)
mount ...
cp key.public.asc key.public.asc.asc key.secret-subkeys.asc key.secret-mainkey.asc /ziel/pfad
Ein Tipp aus Erfahrung: Es ist gut investierte Zeit, sich
kritische Dateien löschen
wipe key-tmp.secret-mainkey.asc secring.gpg
Wenn die Dateien nur ins RAM geschrieben wurden, reicht das Ausschalten des Rechners.
Ein Tipp aus Erfahrung: Es ist gut investierte Zeit, sich vor dem Löschen bzw. Ausschalten davon zu überzeugen, dass die Dateien erfolgreich kopiert wurden...
Fertig: Reboot (ins Arbeitssystem)
init 6
nach Import ins Arbeitssystem ggf. Stick säubern
wipe key.secret-subkeys.asc