27.01.2014
Da der Hauptschlüssel die zentrale Komponente eines OpenPGP-Zertifikats ist, kann man ihn sichern, indem man ihn als Offline-Hauptschlüssel behandelt. Das bedeutet, dass man ihn nie auf unsicheren Systemen verwendet (an ein Netzwerk angeschlossene Systeme werden generell als unsicher angesehen; aber natürlich gibt es noch andere Möglichkeiten, Sicherheit zu kompromittieren).
Hauptschlüssel Unterschlüssel lokaler Zertifizierungsschlüssel (lckey)
Wenn die Standardaktionen (Signieren, Entschlüsseln, ggf. auch Authentifizieren) an Unterschlüssel delegiert werden, dann wird der Hauptschlüssel nur noch für Zertifizierungen benötigt, also für die Bearbeitung des eigenen Zertifikats (Gültigkeit verlängern; komplett widerrufen; User-IDs hinzufügen oder deaktivieren; Unterschlüssel hinzufügen oder widerrufen usw.) oder die Zertifizierung anderer Schlüssel (genauer: deren User-IDs).
Die Ausgabe von gpg --edit-key 0x1a571df5 quit zeigt die Schlüsselfähigkeiten:
pub 4096R/0x1A571DF5 erzeugt: 2012-11-04 verfällt: 2014-11-05 Aufruf: SCE
Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub 2048R/0x3F96AD8E erzeugt: 2012-11-04 verfällt: 2014-11-05 Aufruf: S
sub 2048R/0x81F06169 erzeugt: 2012-11-04 verfällt: 2014-11-05 Aufruf: E
sub 2048R/0x34288BDC erzeugt: 2012-11-04 verfällt: 2018-11-04 Aufruf: A
[ uneing.] (1). Hauke Laging (Standardadresse) <hauke@laging.de>
| Ausgabe | Bedeutung |
|---|---|
| C | Zertifizieren (Signaturen für Schlüssel(komponenten)) |
| S | Signieren (Daten) |
| E | Verschlüssen / Entschlüsseln |
| A | Authentifizieren (SSH) |
GnuPG bietet – abseits des OpenPGP-Standards – die Möglichkeit, den (privaten) Hauptschlüssel zu löschen (genauer: nur die Unterschlüssel zu exportieren). Dadurch kann man die Verwendung dieses zentralen Schlüssels auf sichere(re) Systeme beschränken. Der typische Fall:
Man sichert den privaten Hauptschlüssel physisch (d.h. speichert ihn auf einem (oder zwecks Backup: mehreren) USB-Sticks o.Ä., die nur dafür (also nie an unsicheren Systemen) verwendet werden) und / oder mit einer kryptografisch sicheren Passphrase. Letzteres erleichtert das Backup.
Man bootet immer ein vertrauenswürdiges Betriebssystem, sinnvollerweise von einem nichtbeschreibbaren Medium (CD/DVD), um den Schlüssel zu verwenden.
Wirklich sinnvoll ist die Nutzung eines Offline-Hauptschlüssels nur dann, wenn er gleich als solcher erzeugt wird. Leider unterstützen die verbreiteten GUIs die Erzeugung von Offline-Hauptschlüsseln noch nicht. Wie das (per Hand) geht, ist hier erklärt (der entscheidende Schritt ist --export-secret-subkeys).
Da es aufwendig ist, Zertifizierungen mit einem Offline-Hauptschlüssel vorzunehmen, bietet es sich an, ergänzend einen gesonderten, dedizierten lokalen Zertifizierungsschlüssel zu verwenden (der der Öffentlichkeit nicht bekannt ist und nur nichtexportierbare Signaturen (lsign) erzeugt).
Man kann den Hauptschlüssel "ewig" (realistisch sind aus heutiger Sicht 10–20 Jahre) nutzen.
Man vermeidet den (womöglich immensen) Aufwand, alle Zertifizierungen nachzuholen, wenn man statt des Hauptschlüssels ggf. nur die Unterschlüssel widerrufen muss.
Den Kommunikationspartnern können keine gefälschten Unterschlüssel oder User-IDs untergeschoben werden.
Man ist in puncto Schlüsselsicherheit ein verlässliches Mitglied des web of trust (wenn man sich denn daran beteiligt).
Man kann den Kommunikationspartnern eine verlässliche Schlüsselrichtlinie bieten.
Man kann die Gültigkeit seiner Unterschlüssel (und auch seines Hauptschlüssels) regelmäßig – etwa jährlich – auslaufen lassen und hat die Gewissheit, dass niemand darüber getäuscht werden kann. Damit ist man auf der sicheren Seite, wenn man den geheimen Hauptschlüssel oder dessen Passphrase verliert und kein vorher erstelltes Widerrufszertifikat hat (denn ohne geheimen Hauptschlüssel kann man keins erzeugen).
Wenn man keinen zusätzlichen Schlüssel hat, der hohen Sicherheitsanforderungen genügt, dann kann man zumindest auf Umwegen (und mit gewissen Schwierigkeiten für die andere Seite) Signaturen und Verschlüsselung auf hohem Sicherheitsniveau anbieten. Wenn man das nicht kann, steht man in einer Situation, in der man das unerwartet benötigt, ziemlich dumm da.
Signaturen werden wertlos, wenn der signierende Schlüssel zurückgezogen wird, aber man nicht nachweisen kann (im Zweifelsfall sich selbst gegenüber), dass diese Signatur schon vor dem Zurückziehen existierte. Diesen Nachweis führt man üblicherweise, indem man die fragliche Signatur mit einem anderen Schlüssel signiert. Wenn auch der irgendwann wegen Kompromittierung zurückgezogen werden muss, hat man ein Problem. Man tut sich also einen Gefallen, wenn man wenigstens einen Schlüssel hat, bei dem nicht zu befürchten ist, dass er irgendwann kompromittiert wird.