Version 1.6, 14.07.2014
Wie bei fast allem finden sich auch bei OpenPGP-Schlüsseln gute und schlechte Exemplare. Das beantwortet auch die naheliegende Frage, warum Sie sich einen Schlüssel auf einem Schulungstermin erstellen lassen sollten anstatt das selber zu machen, obwohl wohl jedes Schlüsselverwaltungsprogramm einem die Möglichkeit bietet, mit ein paar Klicks einen Schlüssel zu erzeugen. Zum Testen und Rumspielen kann man das gern machen, aber wenn Sie mit anderen kommunizieren, möchten Sie sicherlich einen guten Schlüssel verwenden. Das Wissen, was gute Schlüssel von schlechten unterscheidet, ist nichts, was man OpenPGP-Anfängern sinnvollerweise zu Beginn vermittelt. Sowohl das Verständnis als auch die Erzeugung erfordern erhebliche geistige Anstrengung und (wenn man es per Hand macht) eine Menge Zeit. Beides lenkt ohne großen Nutzen Anfänger von den wichtigen Dingen ab. Deshalb die Empfehlung: Sie haben die Gelegenheit, ohne diese Anstrengungen einen guten Schlüssel zu bekommen – nutzen Sie sie! Sie werden im Lauf der Zeit ganz zwanglos nach und nach verstehen, wie gut Ihr Schlüssel ist.
Wer die folgenden Aspekte überzogen findet, sollte sich klar machen, dass selbst ein Schlüssel, der all dies leistet, noch nicht den Anforderungen des Signaturgesetzes entspricht, also keine qualifizierten Signaturen erstellen kann.
Was sollen die Kriterien für diese Unterscheidung sein?
ein Schlüssel muss seinen Zweck erfüllen
allen Beteiligten soll möglichst leicht und strukturiert klar sein (können), was der Zweck des Schlüssels ist; da auch andere den Schlüssel nutzen, ist es nicht ausreichend, dass der Besitzer den Zweck kennt und die Eignung des Schlüssels dafür beurteilen kann
der Schlüssel soll seinem Besitzer und den anderen Nutzern nicht ohne guten Grund Beschränkungen auferlegen
Fehlertoleranz: dass unerwünschte Dinge passieren, muss erwartet werden; die negativen Folgen sollen minimiert werden
Offline-Hauptschlüssel ←
Es müssen nicht alle Schlüssel hochsicher sein; das lässt sich mit den meisten Schlüsseln (und Schlüsselaufgaben) gar nicht vereinbaren. Wichtig ist aber, dass man sich darauf einstellen kann, wie sicher ein Schlüssel ist. Die "Metadaten" sind gewissermaßen wichtiger als der Schlüssel selber. Deshalb sollten ernsthaft (vor allem über längere Zeiträume) genutzte Schlüssel, auch wenn sie nicht insgesamt hochsicher sind, immer als Offline-Hauptschlüssel erzeugt werden. Den privaten Hauptschlüssel benötigt man im Alltag nicht, sondern nur zur Verwaltung der eigenen und fremden Schlüssel.
Da man diesen Schlüssel nur selten benötigt, kann man ohne weiteres den Aufwand treiben, ihn nur in einer sicheren Umgebung und mit einer sicheren Passphrase zu verwenden, so dass er weitgehend (jedenfalls elektronisch) unangreifbar wird. Man kann diese dramatisch höhere Sicherheit auch für Signaturen größerer Wichtigkeit nutzen, etwa die Signatur der eigenen Schlüsselrichtlinie. Ein sicherer Offline-Hauptschlüssel hat folgende Konsequenzen:
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.
Der Hauptschlüssel muss dafür allerdings sowohl entschlüsseln als auch signieren können.
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).
Leider unterstützen die verbreiteten GUIs die Erzeugung von Offline-Hauptschlüsseln noch nicht. Man kann sie komfortabel mit meinem Shellscript (bash) erzeugen oder in Handarbeit mit gpg selber (oder mit einem GUI, ergänzt um gpg für die wenigen Aktionen, die das GUI nicht kann) entsprechend dieser Anleitung.
nachhaltige User-ID-Kombination ←
User-IDs kann man nicht wirklich löschen, man kann sie nur für ungültig erklären. Und wie das angezeigt wird, hängt von der jeweiligen Applikation ab. Es ist ärgerlich, wenn man einen etablierten Schlüssel, an dem sonst nichts auszusetzen ist, nach einigen Jahren beerdigt und durch einen neuen ersetzt, nur um User-ID-Altlasten loszuwerden. Deshalb sollte man sich unbedingt in ausreichender Weise Gedanken machen, welche User-IDs man in demselben Schlüssel zusammenfassen will, bevor man die Schlüssel erzeugt.
User-IDs später hinzuzufügen ist weit weniger problematisch, aber nach Möglichkeit sollte man auch das vermeiden (damit die eigenen Kontakte von Anfang an alle User-IDs zertifizieren). Wenn man sowieso erst mal nur für eine einzige E-Mail-Adresse einen Schlüssel erzeugen will, tritt dieses Problem natürlich erst mal nicht auf.
Schlüsselrichtlinie ←
Damit andere Ihren Schlüssel in verantwortungsvoller Weise nutzen können, müssen sie wissen, wofür der Schlüssel gedacht ist (und wofür nicht), also im wesentlichen, wie sicher er ist. Auch weniger sichere Schlüssel haben absolut ihre Berechtigung; die anderen müssen das nur wissen. Ein Schlüssel braucht deshalb eine Richtlinie, die einerseits den Umgang des Besitzers mit diesem Schlüssel beschreibt und andererseits (wenn und sobald er sich am web of trust beteiligen will) erläutert, was Zertifizierungen dieses Schlüssels für andere zu bedeuten haben, also unter welchen Bedingungen der Besitzer mit diesem Schlüssel signiert (und in welcher Weise).
Da es entscheidend ist, von diesem vorgegebenen Verhalten nicht abzuweichen, sollte man eine Schlüsselrichtlinie schon haben (bzw. sich für eine entschieden haben), wenn der Schlüssel erzeugt wird. Es ist viel einfacher, eine vorhandene Richtlinie (in der man jederzeit nachlesen kann) zu befolgen, als sich im nachhinein zu überlegen, was man mit dem Schlüssel alles gemacht hat.
Da es immens komplizierter ist, sich auf eine Zertifizierungsrichtlinie festzulegen, als nur das Sicherheitsniveau und den Zweck des Schlüssels zu beschreiben, ist es für Anfänger ratsam, sich erst mal für eine Schlüsselrichtlinie ohne Zertifizierungsrichtlinie zu entscheiden und keine öffentlichen Zertifizierungen vorzunehmen. Wenn Schlüssel zertifiziert werden (was durchaus nötig sein kann), dann sollte man sich auf lokale Zertifizierungen (lsign
) beschränken.
policy URL ←
Von Ihrer Schlüsselrichtlinie müssen die anderen natürlich auch wissen. Der wesentliche Aspekt dafür ist, dass im Schlüssel die URL hinterlegt ist, unter der (oder unter denen) man das Dokument finden kann. Außerdem ist dies der einfachste Weg, über den sichergestellt werden kann, dass die anderen prüfen können, ob sie es mit der aktuellen Version zu tun haben, weil man mit jeder Änderung der Richtlinie die URL ändert (etwa die Version im Dateinamen hochzählt) und diese URL dann natürlich auch in das Dokument schreibt.
Eine policy URL kann man in der gpg-Konfigurationsdatei festlegen oder als Parameter beim gpg-Aufruf übergeben. Die Optionen dafür sind --cert-policy-url
(Signaturen für Schlüsselkomponenten), --sig-policy-url
(Signaturen für Daten) und --set-policy-url
(alle Signaturen).
preferred keyserver ←
Es ist wichtig, dass man Schlüssel verlässlich aktualisieren kann (vor allem bezüglich möglicher Widerrufe). Dafür muss der Prüfende aber die Sicherheit haben, dass er sich an eine aktuelle Quelle wendet. Dafür kann man den Keyserver, auf den man seine Aktualisierungen schreibt, im Schlüssel vermerken. Das kann statt eines Keyservers auch ein Webserver sein (ein HTTP-URL). Diesen Wert sollte man später nur aus gutem Grund ändern, und auch dann möglichst so, dass die alte Quelle den neuen Schlüssel bekommt.
Den preferred keyserver kann man in der gpg-Konfigurationsdatei festlegen oder als Parameter beim gpg-Aufruf übergeben. Die Option dafür ist --default-keyserver-url
. Bei der Erzeugung eines Schlüssels wird dieser Wert automatisch verwendet. Bei einem bestehenden Schlüssel muss man dafür sorgen, dass (für alle User-IDs) neue Eigenbeglaubigungen erzeugt werden (z.B. durch eine Verlängerung des Gültigkeitszeitraums).
Schlüssellänge und Schlüsseltyp ←
Viel hilft viel
, möchte man meinen. Aber längere Schlüssel haben auch Nachteile. So dauern die Operationen dramatisch länger (doppelte Länge → ca. achtfache Zeit), aber qualitative Aspekte sind noch wichtiger: Lange konnte die OpenPGP-Smartcard nur mit Schlüsseln bis 2048 Bit Länge umgehen. Der Unterschied, ob man eine Smartcard benutzen kann (ggf. auch erst später) oder nicht, ist gravierend. Die Sicherheit, die Schlüssel mit mehr als 2048 Bit Länge bieten, ist dagegen rein theoretisch. Wer auf der GnuPG-Mailingliste behauptet, er brauche mehr, weil 2048 unsicher sei, wird ausgelacht. Man macht eine Kerze ja auch nicht mit einem Schweißbrenner an, nur um sicherzugehen, dass der Docht auch wirklich heiß genug wird...
Mit den Schlüsseltypen ist es ähnlich. Es gibt theoretische Überlegungen, die es wahrscheinlich erscheinen lassen, dass durch das Knacken von DSA auch RSA geknackt wäre, nicht aber umgekehrt. Das ist Theorie. Praxis ist, dass die OpenPGP-Smartcard nur RSA unterstützt, und dass DSA-Schlüssel wertlos werden, wenn sie einmal auf einem Rechner verwendet wurden, der unbrauchbare Zufallszahlen liefert. Echte Praxis, denn das Debian-Disaster war ganz real. Das bei NetBSD auch.
Gute Schlüssel sind also RSA-Schlüssel mit 2048 Bit Länge (das ist die GnuPG-Voreinstellung). 3072 Bit funktioniert nun schon eine Weile mit der Smartcard, kann man also für Hauptschlüssel akzeptieren.
Unterschlüssel ←
Es bietet sich an, jeweils einzelne Unterschlüssel für Verschlüsselung, Signaturen und Authentifizierung (so man denn SSH nutzt) zu haben. Einerseits kann man sie dadurch unterschiedlich handhaben (unterwegs verschlüsselte Mail lesen zu können mag wichtiger sein als in derselben Situation Mails signieren zu können), andererseits mag man irgendwann rechtlich gezwungen oder genötigt sein, seinen Entschlüsselungs-Schlüssel herauszurücken. Dann ist es (Widerruf hin oder her) vorteilhaft, dass mit dem herausgegebenen Schlüssel wirklich nur entschlüsselt werden kann, nicht aber Signaturen gefälscht werden können. Es ist (wenn auch mit Fummelei, weil GnuPG das nicht vorsieht) sogar möglich, unterschiedlichen Schlüsseln eine unterschiedliche Passphrase zu geben. Signieren und Entschlüsseln muss man womöglich ständig, aber SSH-Logins nur selten durchführen. Dann mag man eine längere Passphrase für den Authentifizierungs-Schlüssel akzeptieren.
lückenlose Sicherheit ←
Ein Schlüssel ist immer nur so sicher wie das unsicherste System, auf dem er benutzt bzw. gespeichert wurde. Sicher ist ein Schlüssel also nur dann, wenn er auf einem sicheren Systzem erzeugt wurde und entweder physisch vor Zugriff geschützt wird oder eine Passphrase hat, die sicher ist (vor Knacken und Diebstahl) und nie in einem unsicheren System eingegeben wird. Das betrifft primär Offline-Hauptschlüssel und Hochsicherheits-Schlüssel.
Gültigkeitszeitraum ←
Es gibt bei typischen Schlüsseln keinen überzeugenden Grund, die Gültigkeitsdauer nicht zu begrenzen. Wenn Sie kein Widerrufszertifikat haben und ihren privaten Hauptschlüssel oder dessen Passphrase verlieren, dann wird Ihr Schlüssel auf "ewig" als gültig im Netz herumschwirren, was bestenfalls unprofessionell wirkt.
Wenn Sie Ihren Schlüssel in einer unsicheren Umgebung verwenden, können Sie den Schaden begrenzen, indem Sie die (betroffenen) Unterschlüssel regelmäßig austauschen. Damit das sicher funktioniert, müssen die alten Schlüssel aber ablaufen. Ansonsten braucht ein Angreifer jemandem, der Ihnen verschlüsselt schreiben will, nur eine alte Version Ihres Schlüssels (ohne die neuen Unterschlüssel) unterzujubeln, schon kann er die Kommunikation mitlesen.
eine User-ID ohne E-Mail-Adresse ←
Es ist sinnvoll, eine User-ID ohne E-Mail-Adresse zu haben (für Domaininhaber gilt das nur abgeschwächt). Es kann immer mal sein, dass man eine E-Mail-Adresse nicht mehr hat. Mit dem Widerruf der User-ID werden dann aber alle Zertifizierungen dieser User-ID ungültig. Womöglich bricht einem dadurch ein Teil seiner "web of trust"-Verbindungen weg; im Extremfall (nur eine User-ID (mit Zertifizierungen)) sogar alles.
Der Name dagegen ändert sich quasi nie, und selbst wenn er das durch Heirat o.Ä. mal tut, wird der alte Name dadurch nicht ungültig. Man wird also nie Grund haben, diese User-ID zu widerrufen. Außerdem bietet es sich an, in den Kommentar dieser besonderen User-ID etwas über den Schlüssel insgesamt auszusagen, etwa über dessen Sicherheitsniveau (so was wie Alltagsschlüssel mit sicherem Offline-Hauptschlüssel
).
Hochsicherheits-Schlüssel sollten sogar nur eine einzige User-ID haben und diese sollte keine E-Mail-Adresse haben. Der Grund dafür ist, dass Hochsicherheits-Schlüssel im allgemeinen sowieso nicht vernünftig mit E-Mail verwendet werden können. Also sollte man den Absender gar nicht erst in Versuchung bringen. Daten, die für solche Schlüssel verschlüsselt werden, sollten nur als Attachments verschickt werden.
nur mit starken Hashfunktionen signieren ←
In erster Linie für Hochsicherheits-Schlüssel von Interesse: Eine Signatur ist immer nur so stark wie der verwendete Hash. Das betrifft sowohl Datensignaturen als auch die Eigenbeglaubigungen. Man sollte überhaupt keine Signaturen mit schwachen Hashfunktionen in die Welt setzen. Das betrifft vor allem SHA-1. Heute sind zwar noch keine Preimage-Angriffe auf SHA-1 bekannt, aber das kann in fünf oder zehn Jahren ganz anders aussehen, denn Kollisionsangriffe gibt es für diese Hashfunktion schon.
Da es auf dieser Seite nur um Schlüssel geht: Wenn man keine entsprechenden Vorkehrungen trifft, dann werden bei der Schlüsselerzeugung (und danach allen Änderungen am Schlüssel) SHA-1-Signaturen erzeugt. Man benötigt dafür die Option cert-digest-algo
, sinnvollerweise in der Konfigurationsdatei; also etwa cert-digest-algo SHA256
oder cert-digest-algo SHA512
.
Welche Hashfunktionen in den Eigenbeglaubigungen verwendet wurden, kann man sich mit diesem Kommando ansehen:
gpg --export-options export-minimal --export 0x12345678 |
gpg --list-packets |
grep -A 2 "^:signature packet:" |
grep -o "digest algo [0-9]*,"
Für welche Hashfunktion die Nummern stehen, kann man im RfC 4880 nachlesen. Die wichtigsten: 1 (MD5), 2 (SHA-1), 8 (SHA-256) und 10 (SHA-512).
Aktualisierungen ←
Man kann einen Schlüssel im nachhinein ändert, policy URL und preferred keyserver hinzufügen, natürlich auch User-IDs. Wegen der gegenwärtig eher bescheidenen Aktualisierungsdisziplin der OpenPGP-Nutzer ist es aber erstrebenswert, den Schlüssel bei der Erzeugung (bzw. bevor man ihn einem anderen zugänglich macht) so weit fertig ist (und von veraltenen Signaturen befreit), dass er möglichst lange nicht verändert werden muss.
Backup ←
Um nicht sich selber und womöglich auch anderen große Probleme zu bereiten, ist es von großer Bedeutung, dass man ein Backup seines Schlüssels hat. Das gilt insbesondere für langlebige Schlüssel (Offline-Hauptschlüssel, Hochsicherheits-Schlüssel), aber auch für ganz normale Schlüssel, denn seine eigenen E-Mails nicht mehr lesen zu können ist etwas, das man nicht erleben möchte.
Gerade für diejenigen, die keine Experten sind, bietet es sich an, einmal auszuprobieren, ob das Backup auch funktioniert. Dafür kann man einfach mal die Datei secring.gpg
umbenennen (das ist weniger gefährlich als Löschen), so dass GnuPG keine gehemien Schlüssel mehr sieht.
Zusammengefasst: "Ganz normale Schlüssel" sind wenig mehr als Spielkram. Üblicherweise weiß man nicht, was man von ihnen zu halten hat; für wirklich wichtige Dinge ist fast keiner sicher genug. Aber fast keiner regt sich darüber auf, weil sich fast alle daran gewöhnt haben, dass es Besseres in der Praxis eben nicht gibt. So wie sich die Nicht-Kryptonutzer daran gewöhnt haben, dass ihre Mails eben mitgelesen und gefälscht werden können.
Spricht etwas dagegen, sich einfach erst mal selber einen – suboptimalen – Schlüssel zu erzeugen und den später, wenn man sich besser auskennt, durch einen besseren zu ersetzen? In der Theorie nichts. In der Praxis macht man genau das dann aber doch nicht. Erstens ist man faul, zweitens haben diverse Leute dann schon den Testschlüssel verifiziert. Das alles noch mal machen? Und wie lange will man warten, bis man sich auskennt? Der Initiator dieser Webseite hat etwa sieben Jahre gebraucht, um aus eigener Kraft dieses Niveau zu erreichen. In aller Regel wird man als Anfänger auch nach einem halben Jahr Training noch keinen guten Schlüssel erzeugen. Es sei denn, man holt sich Hilfe. Warum soll man das dann aber nicht schon beim ersten Mal machen?