Version 1.1, 19.06.2015
In OpenPGP-Schulungen ist oft ein gleichermaßen lästiger wie zeitraubender Teil, dass die Teilnehmer ihre Fingerprints austauschen und die importierten Zertifikate verifizieren. Natürlich ist es wichtig, dass sie lernen, wie das geht, und einsehen, dass es – jedenfalls bei entsprechendem Anspruch an die Sicherheit – wichtig ist, aber das heißt nicht, dass man es öfter als ein oder zwei Mal gemacht haben muss; zumal kaum vorstellbar ist, dass die Teilnehmer das zehnmal machen.
Um den Prozess des Fingerprint-Austauschs zu ordnen und das ganz große Chaos zu vermeiden, kann man sich eines abgewandelten Keysigning-Party-Prozesses bedienen (auch wenn man kein Keysigning im engeren Sinn macht, weil man Neulingen vom Web of Trust erst mal fernhalten sollte). Aber das ändert nichts daran, dass – ohne Softwaretricks – für jedes importierte Zertifikat der Fingerprint mit der verifizierten Liste verglichen werden muss (auch wenn das nicht während der Veranstaltung sein muss, sondern später nachgeholt werden kann). Aber auch, wenn man Ruhe hat, will man das nicht für fünf oder zehn Zertifikate machen, also passiert es doch nicht.
[Dies ist nur eine Vorüberlegung; die eigentliche Idee folgt im Absatz sichere Quelle.]
Wenn die Fingerprint-Liste elektronisch verfügbar ist, braucht man eigentlich nicht die Anzeige mit dem abgedruckten Wert zu vergleichen. Man könnte den verifizierten Fingerprint kopieren und dann irgendwie der OpenPGP-Software vorwerfen: Hier, mach was damit!
Leider unterstützen die GUIs das Hineinkopieren eines Vergleichswerts nicht; vielleicht kommt das mal.
Man kann den Prozess aber umdrehen: Normalerweise wählt man ein Zertifikat auf Sicht aus einer Liste aus (indem man es anklickt) und ruft dann den Zertifizierungsdialog auf. Da man aber den verifizierten Fingerprint elektronisch verfügbar hat, kann man das zu signierende Zertifikat auch darüber auswählen und hat die Gewissheit, dass der Fingerprint korrekt ist. Man kann sogar ein Zertifikat über den Fingerprint vom Keyserver importieren – inzwischen prüft GnuPG nach dem Import, ob der Fingerprint korrekt ist...
Da die GnuPG-Versionen vor 2.1.x Fingerprints nur erkennen, wenn sie keine Leerzeichen enthalten, bietet es sich an, die Daten als HTML -Dokument zu verteilen, so dass sie sowohl leicht zu lesen als auch leicht zu kopieren (und zu nutzen) sind:
| ohne Leerzeichen (plain text): | CF51CB887D9AB184AD5021F4DA6B28365A21B2D0 |
| mit Leerzeichen: | CF51 CB88 7D9A B184 AD50 21F4 DA6B 2836 5A21 B2D0 |
| ohne Leerzeichen (HTML/CSS): | CF51CB887D9AB184AD5021F4DA6B28365A21B2D0 |
Wenn man etwas mehr Platz verbraucht (was bei elektronischen Dokumenten egal sein sollte), kann man auch bei reinen Textdateien Lesbarkeit und Kopierbarkeit gleichzeitig optimieren:
CF51 7D9A AD50 DA6B 5A21
CF51CB887D9AB184AD5021F4DA6B28365A21B2D0
CB88 B184 21F4 2836 B2D0
Die Leseerleichterung dient dabei nur dem jeweiligen Schlüsselbesitzer; die anderen kopieren nur den von ihm bestätigten Wert aus der Datei.
Die GUIs helfen einem beim folgenden Schritt nicht weiter; das muss in der Konsole passieren:
gpg --local-user 0x12345678 --lsign-key CF51CB887D9AB184AD5021F4DA6B28365A21B2D0
Die Teilnehmer kopieren jeweils den Fingerprint ans Ende der Befehlszeile.
Unter Linux und MacOS ist das noch einfacher (auch unter Windows wird man das irgendwie programmieren können). Wenn man alle (zu zertifizierenden) Fingerprints zeilenweise in einer Textdatei hat (und sinnigerweise gpg-agent läuft), kann man folgendes machen:
while read fpr; do gpg --local-user 0x12345678 --lsign-key "$fpr"; done < fingerprints.txt
Es kommen dann immer noch Abfragen, aber man ist da schnell durch. Wie viel Spaß es macht, mit nicht IT-affinen Schulungsteilnehmern viel in der Konsole herumzumachen, ist eine andere Sache.
Die übliche Prämisse der Schlüsselhandhabung ist: Die Fingerprints kommen aus einer sicheren Quelle, die Schlüssel aus einer unsicheren. Aber natürlich muss das nicht so sein. Man kann genauso wie bei den Fingerprints auch bei den Schlüsseln dafür sorgen, dass sie aus einer sicheren Quelle kommen. Man ersetzt konsequent die Fingerprints durch die jeweilige Schlüsseldatei (die nicht (injektiv) eineindeutig ist, aber das ist egal). Aus dem Dokument Fingerprintliste wird eine Archivdatei mit allen Schlüsseldateien; aus der Keysigning-Party wird eine Key-Distro-Party:
Export
Die Teilnehmer erzeugen (ggf.) ein leeres Verzeichnis und exportieren ihren Schlüssel darin; sinnigerweise mit einheitlichem Namensschema: hauke_laging__0x12345678.asc
Dateien einsammeln
Die Teilnehmer schicken ihre Datei (und den Fingerprint) irgendwie (z.B. per E-Mail oder auf einem USB-Stick) an den Veranstalter.
Archiv erstellen
Der Veranstalter erzeugt aus allen Dateien ein (ZIP-)Archiv und schickt dieses Archiv an alle Teilnehmer zurück.
Archiv verifizieren
Der Veranstalter und alle Teilnehmer lassen sich den Hashwert für die vorliegende Datei anzeigen (indem sie in der Konsole in das Verzeichnis wechseln, in dem die Datei liegt; die Konsole danach nicht schließen):
start cmd:> gpg --print-md sha1 certs.zip
certs.zip: 605D CBF2 5FE3 F666 23CA 4BBC 987A A86A 30DC FBFEDer Veranstalter liest den Wert vor, wenn alle so weit sind. Dass alle so weit sind, kann man dadurch sicherstellen, dass die Teilnehmer reihum jeweils zwei oder vier Zeichen vorlesen. Alternativ mag es möglich sein, den Hashwert für alle Teilnehmer auszudrucken, so dass sie statt des angezeigten den Wert auf Papier vergleichen (und vorlesen). Das würde es ermöglichen, dass die Leute mit Problemen bei der Hashberechnung wenigstens nicht noch die anderen aufhalten.
eigene Datei verifizieren
Die Teilnehmer extrahieren ihre eigene Datei aus dem Archiv und speichern sie (unter anderem Namen: hauke_laging__0x12345678-i.asc) in dasselbe Verzeichnis. Dann prüfen sie, ob die beiden Dateien identisch sind (das Kommando funktioniert so unter Linux; unter Windows müssen statt *.asc die beiden Dateinamen stehen):
start cmd:> gpg --print-md sha1 *.asc
hauke_laging__0x12345678.asc: 605D CBF2 5FE3 F666 23CA 4BBC 987A A86A 30DC FBFE
hauke_laging__0x12345678-i.asc: 605D CBF2 5FE3 F666 23CA 4BBC 987A A86A 30DC FBFEDer Wert des Fingerprints ist egal, deshalb kommt es nur darauf an, dass beide identisch sind. Man kann die Dateien auch direkt vergleichen:
unter Linux: cmp *.asc
unter Windows: fc hauke_laging__0x12345678.asc hauke_laging__0x12345678-i.asc
Nachdem alle Teilnehmer ihre eigene Datei verifiziert haben, sagen sie der Reihe nach an, ob ihre Datei authentisch ist. Falls nicht alle dazu in der Lage sind, müssen die Teilnehmer sich merken, welche Dateien verifiziert werden konnten. Eine Möglichkeit dafür ist, das ganze Archiv auszupacken und die enthaltenen Dateien auf zwei Verzeichnisse mit z.B. den Namen verifiziert und unverifiziert zu verteilen.
Danach können die Teilnehmer (während der Veranstaltung oder später) die verifizierten Dateien importieren und direkt signieren, ohne dabei noch den Fingerprint prüfen zu müssen.
Das klingt alles ganz einfach, und im Grunde ist es das auch. In der Realität mag man bei nicht sonderlich IT-affinen Leuten an mehreren Stellen bezüglich eines zügigen Ablaufs scheitern:
Kriegen sie es hin, das Zertifikat unter dem richtigen Namen in den richtigen Ordner zu exportieren?
Kriegen sie es hin, die eigene Datei aus dem erhaltenen Archiv unter dem richtigen Namen in den richtigen Ordner zu extrahieren (und dabei insbesondere nicht die Ursprungsdatei zu überschreiben)?
Kriegen sie es hin, eine Konsole zu öffnen und in das richtige Verzeichnis zu wechseln? Es bietet sich wohl an, zwei neue Verzeichnisse auf dem Desktop anzulegen.
Ein zügiger Ablauf kann sicherlich durch eine gut verständliche Anleitung auf Papier unterstützt werden.
Damit das ganze nicht nur schnell, sondern auch sauber abläuft, müssen die Teilnehmer auf einfache Weise notieren können, welche Schlüssel sie dahingehend überprüft haben, dass der Schlüsselbesitzer angesagt hat, dass es sich wirklich um seinen Schlüssel handelt. Das könnte über eine Textdatei gemacht werden, in der die Fingerprints stehen, die also sowieso einen Sinn hat, wenn man sie als Teil des Archivs verteilt. Diese Datei – die dann wohl in einer Version für Windows und einer für Linux / Mac benötigt wird – sollte neben dem Fingerprint auch die (primäre) UID enthalten, damit der richtige Eintrag leichter zu finden ist. Die Teilnehmer könnten einfach ein X reinschreiben, wenn die Prüfung stattgefunden hat:
CF51 CB88 7D9A B184 AD50 21F4 DA6B 2836 5A21 B2D0 [ ] OK Hauke Laging hauke.laging@crypto-fuer-alle 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 [ ] OK Hauke Laging hauke@laging
Falls es sich um eine Turbo-Schulung handelt, bietet es sich an, dass der Dozent / Helfer direkt nach der Schlüsselerzeugung das Zertifikat (und den Fingerprint) an die Sammelstelle schickt. Dabei geht leicht einiges an Zeit verloren, wenn die Teilnehmer das selber machen müssen, weil man dann auf den letzten warten muss. Wenn man nach der Verteilung des Archivs einzelnen helfen muss, ist das weniger schlimm.
Mit u.a. Enigmail, das die meisten Teilnehmer benutzen, kann man diese Mail zudem sehr schnell verschicken. Noch schneller geht es (unabhängig davon, wer die Mail verschickt), wenn man einen Chatraum nutzt und alle die Adresse dort sehen und rauskopieren können.
Auch in dieser Variante müssen die Teilnehmer ihr Zertifikat selber exportieren, denn sie brauchen es für den Vergleich der beiden Dateien. Da sie das aber erst nach dem Erhalt des Archivs machen müssen, halten sie den Betrieb nicht auf, wenn sie damit Probleme haben (sondern nur die Prüfung ihres eigenen Schlüssels für die anderen). Dies sind außerdem Aktivitäten, bei denen die Teilnehmer einander gut unterstützen können: Wer es geschafft hat, sein Zertifikat zu exportieren, hilft den anderen dabei.
Version 1.1, 19.06.2015 (diese Version, Permanentlink)