Bei der Schlüsselerzeugung sind mehrere Aspekte von großer Bedeutung:
Sicherheit
Der erzeugte Schlüssel darf nicht kompromittiert werden, weder das Schlüsselmaterial noch die Passphrase. Natürlich muss der Schlüssel auch lang genug sein. Ein wesentlicher Punkt dabei ist, dass man keine Fehler macht, also vor allem keine Arbeitsschritte vergisst.
Vollständigkeit
Man kann Schlüssel mit unterschiedlich umfangreicher Konfiguration erstellen (policy URL; preferred keyserver; signature notations; cipher/digest preferences). Man sollte da nicht aus Bequemlichkeit Abstriche machen.
Zeitaufwand
Die Schlüsselerzeugung sollte nur wenige Minuten in Anspruch nehmen, die Planung nicht eingerechnet (welche User-IDs; welche policy URL; welche Schlüsselrichtlinie).
Verständlichkeit
Es ist für Veranstaltungen mit größeren Gruppen sehr hilfreich, wenn die Schlüsselerzeugung weitgehend idiotensicher ist. Das manuelle Erzeugen von Schlüsseln per GnuPG in der Konsole ist davon sehr weit entfernt. Idealerweise sollten die Nutzer gar nicht mit komplizierten Vorgängen konfrontiert werden, weil ihr Aufmerksamkeitspensum begrenzt ist und nicht sinnlos für die Schlüsselerzeugung (die sie ja gerade nicht lernen müssen) verballert werden sollte.
Checkliste
Es ist sehr hilfreich, jederzeit zu wissen, was noch zu tun ist. Das kann man mit Papier erledigen, aber das muss man dann nach jeder Änderung neu ausdrucken. Papier macht den Veranstalter weniger flexibel.
ergänzende Aktionen
Auch Aktionen, die oftmals im Rahmen der Schlüsselerzeugung ablaufen, sollten schnell, bequem und mit minimalem Fehlerpotential ablaufen: Zertifizierung anderer Schlüssel; (Hauptschlüssel-)Signierung einer Schlüsselrichtlinie usw.
Workarounds
Wenn unter Knoppix Schlüssel generiert werden, haben die immer(?) einen um eine Stunde verschobenen Erzeugungs-Zeitstempel, mit entsprechendem Ärger beim Import ins Arbeitssystem. Das lässt sich durch eine Zeitumstellung leicht korrigieren. Man muss nur dran denken. Und bis man das erledigt hat, ist schon wieder eine Minute weg. Oder auch gerne mal mehr.
Die Schlüsselerzeugungs-Checkliste war in dieser Hinsicht schon ein großer Fortschritt, aber selbst wenn man nichts vergisst und keine Zeit mit Nachdenken verplempert, dauert das einfach lange. Und ist keine Option für Leute mit Konsolen-Aversion.
Alle diese Dinge lassen sich mehr oder weniger dramatisch verbessern, indem man die Schlüsselerzeugung von einem Script erledigen lässt. Die Teilnehmer erzeugen sich vorher eine Script-Konfigurationsdatei, in der die zu erzeugenden User-IDs festgelegt werden, und nehmen ggf. Anpassungen der GnuPG-Konfigurationsdatei vor, die nach der Erzeugung des Hauptschlüssels (also sobald der Fingerprint bekannt ist) von dem Script bearbeitet wird, und der Rest ist in wenigen Minuten erledigt; der zeitlich aufwendigste Teil ist die Generierung von genug Entropie (könnte man auslagern).
Ohne Abstriche bei der Qualität der erzeugten Schlüssel reduziert so ein Script auch die Anforderungen an die GnuPG- und Shellkenntnisse der Dozenten erheblich. Von Verbesserungen profitieren alle, ohne sie verstehen oder auch nur kennen zu müssen.
Das aktuelle Script (Version 1.7 vom 24.05.2013, ca. 1700 Zeilen) ist ein bash-Script. Das bedeutet, dass es (gut) nur unter Linux u.Ä. läuft. Das ist insofern wenig problematisch, als Schlüssel sowieso nur in einer sicheren Umgebung erzeugt werden sollen. Diese mit Windows bereitzustellen, ist in vielerlei Hinsicht aufwendiger. Deshalb und weil das Script primär für den Einsatz bei Schulungen gedacht ist und nicht dafür, dass es aus Bequemlichkeit von Windows-Nutzern in ihrer normalen (also reichlich unsicheren) Arbeitsumgebung verwendet wird, ist derzeit keine Windows-Version geplant. Allerdings soll es später ein ergänzendes Windows-Script geben, das den Import der Dateien erleichtert.
Das Schlüsselerzeugungs-Script benötigt eine Konfigurationsdatei zur Festlegung der User-IDs. Alle anderen Einstellungen sind "fest" vorgegeben (natürlich ist es einfach, das Script zu ändern). Das ist kein Programmiermangel, sondern eine Designentscheidung. Dieses Script soll hochwertige Schlüssel für Anfänger erzeugen (die sind auch für Nicht-Anfänger gut genug). Ich denke, wer sich für so clever hält, dass er meint, bei der Schlüsselerzeugung Vorgaben machen zu können, die besser sind als meine Empfehlungen, der braucht kein Script. Für die anderen 99% ist dagegen wichtig, möglichst wenige Fehler machen zu können. Die Erfahrung zeigt, dass selbst halbwegs IT-affine Leute mit der Festlegung ihrer User-IDs schon voll ausgelastet sind. Weitere Konfigurationsmöglichkeiten wären da nur verwirrend.
Eine Erläuterung der einzelnen Vorgaben werde ich irgendwann nachliefern.
die Script-Konfigurationsdatei (mit ausführlichen Erläuterungen; Signatur)
der Vollständigkeit halber: die GnuPG-Konfigurationsdatei (Signatur)
Die ersten drei Dateien müssen sich im selben Verzeichnis befinden; das darf nicht ~/.gnupg sein.
Das Script wird ganz simpel über ./key-generation.sh gestartet (als root, sonst funktioniert das Anpassen der Systemzeit nicht). Idealerweise hat man vorher auch die GnuPG-Konfigurationsdatei schon angepasst (siehe dortige Erläuterungen, v.a. die Zeilen mit dem Stichwort ANPASSEN). Nach dem Start des Programms wird man aufgefordert, einen Symlink namens targetdir im Verzeichnis ~/.gnupg anzulegen. In das so verlinkte Verzeichnis werden alle relevanten Dateien kopiert (die erzeugten sowie das Script selber und die GnuPG-Konfigurationsdatei). Das Zielverzeichnis sollte auf z.B. einen USB-Stick oder die lokale Platte zeigen (aber sinnvollerweise nicht auf ein bereits existierendes GnuPG-Konfigurationsverzeichnis, weil sonst Dateien überschrieben werden, die womöglich noch gebraucht werden).
Das Script ist (von Tests abgesehen) ausschließlich dafür gedacht, in einem sicheren System gestartet zu werden; dieses sichere System sollte auf jeden Fall mit dem Kernelparameter norandmaps gestartet werden, weil der Kernel sonst kostbare Entropie verbrät (das fragliche Sicherheitsfeature ist in diesem Szenario sowieso irrelevant). Eine grafische Oberfläche braucht es nicht. Getestet wurde es mit openSUSE und Knoppix (7.0.4).
Das Script ist ziemlich gesprächig. Es gibt nicht nur Fehler aus, sondern auch allerlei Hinweise, sowohl allgemeine als auch auf die konkrete Situation bezogene. Da nicht jeder gern viel liest, sagt es vorab immer, wie wichtig der folgende Text ist.
Feedback zum Script ist willkommen, und zwar bezüglich
Bugs
Usability
Featurewünsche
Sicherheitslücken
problematischen Situationen in bestimmten Umgebungen
Die Kernfunktionen des Scripts sind der Schlüsselerzeugungs-Checkliste nachprogrammiert. Die kommentierte Checkliste erleichtert nicht nur das Verständnis des Scripts, sondern ermöglicht es einem, auch ohne das Script solche Schlüssel zu erzeugen.
Wenn man es in der Standardvariante laufen lässt, werden diese Funktionen ausgeführt:
| Shellfunktion | Bedeutung |
|---|---|
| sub__checks | Es wird auf eine Reihe möglicher Fehlerzustände getestet. |
| sub__time_change | Die Systemzeit wird drei Stunden zurückgesetzt, um in Knoppix Probleme mit vermeintlich zukünftigen Zeitstempeln zu vermeiden. |
| sub__mainkeygen | Der Hauptschlüssel und die erste User-ID werden erzeugt: 2048 Bit RSA, Signier- und Verschlüsselungsfähigkeit, 1 Jahr Gültigkeit |
| sub__time_restore | Systemzeit zurücksetzen |
| sub__set_vars | Mit Hilfe des nun bekannten Fingerprints werden die Namen der später exportierten Dateien bestimmt. |
| sub__adapt_config | Die GnuPG-Konfigurationsdatei wird angepasst (Fingerprint, short und long ID werden eingetragen; auskommentierte Einträge aktiviert). |
| sub__uids_subkeys | Eigensignatur des Hauptschlüssels wird gelöscht und (mit den neuen Werten aus der veränderten Konfiguration) neu erzeugt. Dann werden die Unterschlüssel und die weiteren User-IDs erzeugt. |
| sub__script | Ein kleines Script wird in ~/.gnupg erzeugt, mit dem auf einfache Weise Hauptschlüssel-Signaturen erzeugt werden können (z.B. für Schlüsselrichtlinien und OTR-Fingerprints). Auf diese Weise muss man sich nicht merken, wie man Hauptschlüssel-Signaturen erzwingt. Am Ende des Blocks wird das Script gelöscht. |
| sub__export | Es werden Exportdateien für den öffentlichen Schlüssel (das Zertifikat), den geheimen (Offline-)Hauptschlüssel und die geheimen Unterschlüssel erzeugt. |
| sub__deltmp | temporärer Export des geheimen Hauptschlüssels wird gelöscht |
| sub__copy | Die Exportdateien werden zusammen mit dem Script und der GnuPG-Konfigurationsdatei ins Verzeichnis ~/.gnupg/targetdir kopiert und anschließend (zusammen mit dem Keyring) gelöscht. |
Das ist alles keine schwarze Magie. Auch Leute mit bescheidenen Shellkenntnissen sollten in der Lage sein, das Script so weit nachzuvollziehen, dass ihnen klar ist, dass es keinen Schaden anrichtet.
Das Script kann mit Parametern gestartet werden, die dafür sorgen, dass nur ein Teil der Funktionen aufgerufen wird, also insbesondere nicht die Schlüsselerzeugung. Implementiert ist aktuell nur --adapt-config. Dann wird nur die Konfigurationsdatei angepasst. Das ist ein reines Bequemlichkeitsfeature, wenn man schon einen Schlüssel hat (oder die vorbereitete Konfigurationsdatei testen will).
Der zukünftige Schlüsselbesitzer sollte sich nach dem Booten des sicheren Systems (also vor dem ersten Starten des Scripts!) einen kryptografisch sicheren Hash der Scriptdatei notieren (darauf weist das Script auch selber hin, aber dann muss man halt neu booten). Dann kann er später in aller Ruhe das Script prüfen (lassen) und hat die Gewissheit, dass genau die Datei gestartet wurde, die ihm zur Prüfung vorliegt. Das setzt natürlich voraus, dass das sichere System vertrauenswürdig ist... :-)
Folgende Kommandos zeigen den SHA-1-Hash der Datei an (MD5 kommt als sicherer Hash nicht mehr in Frage):
sha1sum key-generation.sh
gpg --print-md SHA1 key-generation.sh
Man ist zum Verständnis des Scripts nicht allein auf den Code angewiesen. Man kann es auch so starten: bash -vx ./key-generation.sh, dann zeigt die bash an, was das Script macht. Weil das ziemlich viel ist, sollte man diese Ausgabe in eine Datei umlenken: bash -vx ./key-generation.sh 2>scriptdebug.txt
Schaden kann man aus der Shell (jedenfalls ohne Superuser-Rechte) kaum anrichten; dafür braucht man externe Programme, die man aus der Shell heraus aufruft. Wie diese Aufrufe aussehen, kann man sich mit strace ansehen. Das ist eine sichere Sache, wenn strace mit Superuser-Rechten läuft, das Script aber nicht.
Zunächst benötigt man die PID der Shell, aus der man das Script starten wird. Die bekommt man in der Shell (bash) mit diesem Kommando: echo $$
Der Übersichtlichkeit halber kann man strace darauf beschränken, die prozessrelevanten Syscalls zu protokollieren:
strace -f -e trace=process -p 1234
wobei 1234 für die PID der Shell steht. Mit -o logdatei.txt oder strace ... 2>logdatei.txt bekommt man die strace-Ausgabe in eine Datei. Auch pipen in less ist natürlich möglich: strace ... 2>&1 | less
Sobald strace an der Shell hängt, kann man das Script starten.