StartseiteSchulungs-StartseiteEinrichtungs-Startseite

Schlüsselerzeugungs-Checkliste – kommentierte Version

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.

Durchführung – Schlüsselerzeugung

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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".

  9. 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)!

  10. öffentlichen Schlüssel sichern

    gpg --armor --export ... > key.public.asc

    Das ist das zu verbreitende Zertifikat.

  11. 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.

  12. 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.

  13. 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.

  14. 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).

  15. 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.

  16. 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).

  17. 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.

  18. 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.

  19. 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.

  20. 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

  21. 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...

  22. Fertig: Reboot (ins Arbeitssystem)

    init 6

  23. nach Import ins Arbeitssystem ggf. Stick säubern

    wipe key.secret-subkeys.asc