zurück zur IT-Sicherheits-Startseite

Einführung in die Funktionsweise von OpenPGP / GnuPG (gpg)

Ein GnuPG-Tutorial mit vielen Hintergrundinformationen.

Version 1.8.1, 26.03.2015 (Signaturdatei dieser Seite, hoffentlich aktuell..., und der CSS-Datei)

mein Projekt zur Förderung kostenloser OpenPGP-Schulungen: Logo www.openpgp-schulungen.de

Für diejenigen, die sich hierher "verlaufen" haben: Was ist OpenPGP / GnuPG? OpenPGP ist ein offener Standard für ein Kryptografiesystem (Verschlüsselung; digitale Unterschriften; Web of Trust), insbesondere für die Verwendung bei E-Mails. GnuPG (Gnu Privacy Guard) ist eine freie und quelloffene Software (für viele Betriebssysteme verfügbar), die den OpenPGP-Standard implementiert. Diese Seite versucht zu erklären, was man wissen muss, um sinnvoll verschlüsseln und signieren zu können, und wie das mit Hilfe von (v.a.) GnuPG geht. OpenPGP ist eins von zwei verbreiteten Verfahren zur Verschlüsselung und Signatur von E-Mails, das andere ist S/MIME. Allgemein gilt OpenPGP bei Privatanwendern als deutlich weiter verbreitet, in Unternehmen wird dagegen ganz überwiegend S/MIME verwendet, zumal dieselbe Technik (SSL/TLS) auch für gesicherte Verbindungen im Internet (v.a. zu Webservern: https) verwendet wird, was OpenPGP nicht kann (bzw. was in der Praxis keine Rolle spielt).

Ich biete (privat) auch Schulungen zum Einsatz von OpenPGP / GnuPG an und bemühe mich, das Angebot (und die Nachfrage) kostenloser Schulungen zu erhöhen: www.openpgp-schulungen.de.

Ich biete XMPP Live-Unterstützung an.

Inhalt dieser Seite

  1. Erläuterung zum Inhalt dieser Seite

    1. Feedback erwünscht

    2. Referenzimplementierung

    3. Shellprompt in den Beispielen

    4. öffentlicher Schlüssel vs. Zertifikat

  2. historische Entwicklung

  3. Warnung

  4. die Kurzfassung

  5. technische Basis

    1. Installation

    2. Kompatibilität

    3. Support

  6. die wichtigsten Aktionen

    1. Erzeugung eines Schlüsselpaars und Schlüsselverwaltung

      1. Primärschlüssel / Hauptschlüssel

      2. Schlüsseltypen

      3. Schlüssellänge

      4. Gültigkeitszeitraum

      5. Unterschlüssel

      6. Benutzerkennung

      7. Passphrase

    2. Keyring und Schlüsselinformationen anzeigen

      1. Schlüsselauswahl

      2. list options

    3. Schlüssel beglaubigen – Gültigkeit festlegen

      1. Wann ein Schlüssel als gültig betrachtet wird

      2. direkte Überprüfung – eigene Beglaubigung

      3. Anzeige des Fingerabdrucks

      4. Signatur / Zertifikat erzeugen

      5. Zusatzangaben zur Signatur

      6. Risiko einer schlampigen Signatur

      7. lokale Signaturen

      8. Fingerabdruck immer auf Papier dabei haben

      9. Signatur aktualisieren

      10. indirekte Überprüfung – das Web of Trust (WoT)

      11. Zertifizierungspfad – in Anlehnung an das Web of Trust

    4. Import und Export von Schlüsseln

      1. Import

      2. Export

      3. Transfer von Schlüsseln auf andere Rechner

    5. Schlüssel zurückziehen (revoke)

      1. präventives Sperrzertifikat

    6. Verschlüsseln / Entschlüsseln

      1. Verschlüsseln mit ASCII-Armor

      2. Sessionkeys

      3. Festlegung des Verschlüsselungsverfahrens (Cipher)

    7. Signieren

      1. Daten und Signatur in einer oder mehreren Dateien

      2. Signaturcodierung

      3. Mehrfachsignatur

      4. Reihenfolge von Verschlüsselung und Signatur

      5. technische Details

    8. Signaturen prüfen

  7. Zusammenspiel von gpg und gpg-agent

  8. Bedrohungen der Schlüssel und Gegenmaßnahmen

    1. Warum dann überhaupt noch Schlüssel?

    2. Schutz der Wichtigkeit anpassen

    3. nichtautorisierte Signaturen

    4. Offline-Hauptschlüssel

    5. Was ist ein sicheres System?

  9. Smartcards

    1. verfügbare Hardware

  10. Bedeutung von Signaturen: technische und organisatorische Maßnahmen

    1. die größte Lücke ist das Missverständnis

      1. Was bedeutet eine Signatur?

      2. Signaturhäufigkeit

      3. Sicherheit des Schlüssels

    2. Vermeidung von Missverständissen: klare Ansage per Schlüsselrichtlinie (key policy)

  11. Verwendung von OpenPGP für E-Mail

Erläuterung zum Inhalt dieser Seite

Ich gebe zu, dass der Titel dieser Seite inzwischen irreführend ist. Bei einem 190-KiB-Dokument (nur der Text...) kann man kaum von einer Einführung sprechen. Das war es mal, allerdings ist es mit meiner Kenntnis der Thematik immer weiter gewachsen; wenn ich etwas lerne, das mir relevant erscheint, wird dieser Text länger. Inzwischen geht diese Erklärung weit über das hinaus, was auch bei überdurchschnittlich kompetenten Anwendern üblich ist. Ich halte das aber für sinnvoll: Vorhandene Abschnitte kann man überspringen, mit fehlenden kann man sich schlechter arrangieren. Eine überschaubare Einführung in die wichtigsten Aspekte von Kryptografie (Verschlüsselung, Signierung, Hashwerte, Schlüsselauthentifizierung), unabhängig von gpg, bietet diese Seite.

Ich bemühe mich sehr darum, hier nur korrekte Informationen zu verbreiten. Deshalb verlasse ich mich nicht auf Dokumentationen (die manchmal falsch oder missverständlich sind), sondern habe (fast) alles, was ich hier beschreibe, vorher ausprobiert.

Ich habe zu einem erheblichen Teil die Wikipedia-Artikel zu GnuPG, OpenPGP und dem Web of Trust mitgeschrieben.

Feedback erwünscht

Insbesondere da dieses Dokument sich mehr oder weniger laufend weiterentwickelt wird, freue ich mich über Feedback. Was fehlt, was ist unverständlich, und – insbesondere – was ist falsch? Anmerkungen an hauke@laging.de

Im folgenden werden viele Möglichkeiten erläutert, wie man mit gpg arbeiten kann (also direkt mit dem Konsolenprogramm). Wer den Umgang mit gpg beherrscht, wird mit den grafischen Oberflächen dafür keine großen Probleme haben; umgekehrt kann man das wohl nicht behaupten. Der Schwerpunkt dieses Dokuments ist nicht eine Schritt-für-Schritt-Anleitung der einzelnen Kommandos, auch wenn die nötigen Kommandos natürlich in der einen oder anderen Weise genannt werden, sondern ein Gesamtverständnis davon, was zu tun ist bzw. getan werden kann. Das war für mich in der Lernphase (ohne gute Anleitung) das größte Problem. Wie die Kommandos und Optionen heißen, kann man leicht nachlesen. Aber wenn man das Gesamtbild nur unzureichend verstanden hat, ist es nicht leicht, den Sinn der vielen Kommandos und Optionen zu erfassen. Deshalb ist mir an dieser Stelle das Warum wichtiger als das Wie, zumal das allgemeine Verständnis auch für andere OpenPGP-Implementationen, teilweise sogar für andere Kryptosysteme, hilfreich ist. Zur Verbesserung des Wie stelle ich (nach und nach) jedem Abschnitt eine Liste der für ihn relevanten allgemeinen und speziellen Kommandos und Optionen, jeweils mit der offiziellen verlinkt, voran.

Unerfahrene Nutzer sollten sich nicht vom Umfang und dem technischen Tiefgang abschrecken lassen. Man muss diese Seite nicht verstanden haben, um gpg nutzen zu können. Ich halte es aber für einen guten Überblick der Technologie, sich das hier einmal durchzulesen. An vielen Stellen wird man für sich entscheiden, dass man das jeweilige Feature nicht braucht, aber dann hat man mal davon gehört und ist zudem mit einigen wichtigen Aspekten des Umgangs mit Kryptografie konfrontiert worden. Es ist nichts dagegen zu sagen, dass man erst mal irgendwie mit OpenPGP "rumspielt", um damit vertraut zu werden, und sich das wünschenswerte tiefere Verständnis erst später aneignet. Man sollte dann nur nicht den Fehler machen, dem Schutz der Daten und der Vertrauenswürdigkeit von Daten während dieser Spielphase einen großen Umfang zu attestieren!

Und damit klar ist, was Normalsterbliche für den ersten Überblick gerne überspringen dürfen, stehen die weniger wichtigen Details in Absätzen, die so markiert sind wie dieser.

Zu Beginn eines Abschnitts sind die für das jeweilige Thema relevanten Kommandos und Optionen aufgelistet, mit der Original-Dokumentation verlinkt und mit einer Fly-over-Help versehen. Diejenigen Optionen, die sich für einen Eintrag in die Konfigurationsdatei eignen (wenn auch nicht alle gleichzeitig), sind so markiert: --dummy1 (statt --dummy2). Viele Kommandos gibt es auch als Kurzversion, etwa -e statt --encrypt. Die Kurzversionen verwende ich hier nicht. Sie sparen kaum Zeit und wären dem Verständnis hier nicht förderlich.

Referenzimplementierung

Die meisten Informationen auf dieser Seite sollten nicht implementierungsspezifisch sein. Die Beispiele und Aussagen (insbesondere, soweit sie die Ergebnisse von Tests betreffen) beziehen sich aber auf GnuPG 2.0.x unter Linux.

Shellprompt in den Beispielen

In den Codebeispielen sieht der Prompt anders aus, als man es gewohnt ist. Auf gpg hat das natürlich keinen Einfluss, aber wer sich dafür hinteressiert, mag einen Blick auf meine Seite zur Shellprompt-Konfiguration werfen.

öffentlicher Schlüssel vs. Zertifikat

Meist werden die Begriffe öffentlicher Schlüssel und Zertifikat synonym verwendet, auch auf dieser Seite. Der Unterschied spielt im allgemeinen keine Rolle, sei hier der Vollständigkeit halber aber dennoch erwähnt. Ein öffentlicher Schlüssel ist – genau wie ein privater – nur eine Zahl (bzw. eine Kombination mehrerer Zahlen, meist zwei). Nackte Schlüssel, das Zahlenmaterial, kommt bei der Verwendung von OpenPGP / GnuPG nicht vor. Am nächsten dran ist der Fingerprint, der sich nur auf dieses Zahlenmaterial bezieht. Man kann die reinen Schlüssel normalerweise weder importieren noch exportieren (Ausnahmen: (a) auf eine Smartcard; (b) mittelbar über --with-key-data --list-keys).

Ein Zertifikat ist ein Dokument (eine Datei in einem bestimmten Format), das die Zuordnung eines Schlüssels zu einer Person oder sonstigen Instanz bestätigt (und die öffentlichen Schlüsselkomponenten enthält). Ein OpenPGP-Schlüssel enthält mindestens eine User-ID (UID), die einen Namen und/oder eine E-Mail-Adresse und/oder beliebigen Text enthalten kann. Ein OpenPGP-Zertifikat bindet mit Hilfe von Eigensignaturen einzelne Komponenten an den öffentlichen Hauptschlüssel; mindestens eine UID, möglicherweise weitere UIDs und Unterschlüssel. Zusätzliche Signaturen von Dritten, die UIDs an den Hauptschlüssel binden, können die Verlässlichkeit des Zertifikats erhöhen. Zertifikate sind meist wenige Kilobyte groß, können aber (v.a. durch viele UIDs mit jeweils vielen Signaturen) die Größe eines Megabytes überschreiten, was natürlich auch Nachteile hat.

Ein minimales Zertifikat ist so aufgebaut (siehe /usr/share/doc/packages/gpg2/DETAILS):

start cmd:> gpg --with-colons --list-sigs 0x1a571df5
pub:u:4096:1:BF4B8EEF1A571DF5:1351995465:1383531465::u:::escESCA:
uid:u::::1352004488::EEDB6E9B3F9B8686B76CAE89A7F2684D0E9192E4::Hauke Laging (Standardschlüssel\x3a siehe policy URL und signature notations):
sig:::1:BF4B8EEF1A571DF5:1352004488::::Hauke Laging (Standardschlüssel\x3a siehe policy URL und signature notations):13x:
  1. Der erste Block ist das Schlüsselmaterial mit der Angabe von Schlüsseltyp und -länge, seiner long ID, seinem Erzeugungszeitpunkt, seinem Ablaufzeitpunkt (sofern vorhanden), dem zugewiesenen Ownertrust (der hier mit angezeigt wird, aber nicht Bestandteil des Zertifikats ist, sondern von jedem Nutzer individuell festgelegt wird) und den Fähigkeiten (zwingend: Zertifizieren (C); optional: Entschlüsseln (E), Signieren (S) und Authentifizieren (A; für SSH).

  2. Der zweite Block ist die User-ID (mit Gültigkeit, Erzeugungszeitpunkt, dem Text und (davor) dem Hash des Textes).

  3. Der dritte Block ist die Eigenbeglaubigung der UID (mit Signaturtyp, long ID des signierenden Schlüssels, Signierzeitpunkt, der primären UID des signierenden Schlüssels)

Den öffentlichen Schlüssel im engeren Sinn braucht GnuPG, um Daten zu verschlüsseln und Signaturen zu prüfen. Den restlichen Inhalt des Zertifikats braucht es, um den Schlüssel verwalten zu können, also um ihn anders als über seinen Fingerprint bzw. seine ID ansprechen zu können und um seine Gültigkeit bestimmen (und beeinflussen) zu können.

Wenn ein Schlüssel signiert wird, nennt man das Zertifizierung, Schlüsselsignatur, Beglaubigung oder eben Eigenzertifizierung, Eigenbeglaubigung, wenn ein Hauptschlüssel seine eigenen Komponenten signiert. Diese Termini werden von mir synonym verwendet. Beim Unterschreiben von Daten wird dagegen lediglich von Signaturen gesprochen.

historische Entwicklung

1991 veröffentlichte der amerikanische Programmierer Phil Zimmermann seine Software Pretty Good Privacy (PGP). Sie wurde von seiner Firma kommerziell vertrieben, war aber für Privatanwender kostenlos nutzbar. Als Alternative wurde 1998 der OpenPGP-Standard verabschiedet und in der FOS-Software GnuPG (Gnu Privacy Guard) implementiert. GnuPG ist die dominante (wenn nicht sogar einzige) Basis für freie und offene OpenPGP-Software.

Warnung

Installation und Aufruf von gpg macht niemanden zum Experten. Man kann, erst recht per GUI, mit Kryptografiesoftware hantieren, ohne auch nur den blassesten Schimmer davon zu haben, was man gerade macht. Die Software kann Wissensmängel ihres Benutzers nicht ausgleichen und wird das auch nicht zufällig tun.

Es ist auf jeden Fall sinnvoll, sich mit GnuPG zu beschäftigen, aber es ist für ein gutes Ergebnis absolut unerlässlich, dass man sich klar macht, inwieweit man verstanden hat, was man tut. Solange man das nötige Verständnis nicht erworben hat, sollte man sich bewusst machen, dass die in der konkreten Situation gebotene Sicherheit möglicherweise sehr begrenzt ist, und sich nicht darauf verlassen, dass die 4096 Bit Schlüssellänge es schon irgendwie regeln werden. Das tun sie nämlich auf keinen Fall. Auch "kurze" Schlüssel sind für die meisten Angreifer unüberwindbar. Selbstüberschätzung wenig qualifizierter Anwender ist dagegen eine Einladung.

Der IT-Sicherheits-Guru Bruce Schneier hat das mal so formuliert:

Security is a process, not a product.

Er meint damit, dass man Sicherheit nicht kaufen kann wie eine zusätzliche Festplatte. Sicherheit ist in den meisten Fällen keine rein technische Kategorie, sondern auch wesentlich eine des eigenen Verhaltens.

die Kurzfassung

Um OpenPGP mit GnuPG (sinnvoll) zu nutzen, sind folgende Schritte erforderlich:

  1. Man entscheidet sich, für welches Sicherheitsniveau oder welche Sicherheitsniveaus jeweils ein Schlüssel erzeugt werden soll.

  2. Man besorgt sich GnuPG und ggf. ergänzende Software (eine grafische Oberfläche dafür; Add-on fürs Mailprogramm) aus einer sicheren Quelle.

  3. Man erzeugt sich (mindestens) einen Schlüssel, der in Länge, Ausgestaltung und der Sicherheit des ihn erzeugenden, des ihn speichernden und des ihn verwendenden Systems dem gewählten Niveau entspricht (--gen-key).

  4. Man besorgt sich (--import) die öffentlichen Schlüssel (und möglichst auch die zugehörigen Richtlinien) der Kommunikationspartner oder deren Fingerprint aus einer sicheren Quelle und markiert sie (für sich selber oder für die Öffentlichkeit) als vertrauenswürdig (--edit-key sign).

  5. Man informiert die Kommunikationspartner über den Fingerprint (--fingerprint) und das Sicherheitsniveau des eigenen Schlüssels.

  6. Für alle Schlüssel bzw. von allen Schlüsseln, die man importiert und als vertrauenswürdig markiert hat oder denen man indirekt (über das Web of Trust) vertraut, kann man nun direkt (mit gpg) oder indirekt (z.B. gpg-GUI oder Mailclient) verschlüsseln bzw. Signaturen prüfen.

Damit kann man dann:

technische Basis

GnuPG bzw. gpg/gpg2 (der technische Programmname) ist ein Konsolen-Programm und deshalb aus Sicht der meisten Anwender nicht benutzerfreundlich. Es gibt allerdings einige Programme, die als grafische Oberfläche für gpg fungieren, so dass man sich meist nicht mit dem Eintippen von Befehlen auseinandersetzen muss, sondern die gewünschten Aktionen intuitiv mit der Maus oder einem Menü vornehmen kann. Viele sehr spezielle Funktionen werden allerdings von den grafischen Programmen nicht angeboten. In solchen Fällen muss man gpg direkt aufrufen (in der Konsole/Shell), um das Gewünschte zu erreichen.

Konfigurationsdateien

Man kann über eine gpg-Konfigurationsdatei das Standardverhalten von gpg und Programmen, die es aufrufen, beeinflussen. Unter Linux ist das die Datei ~/.gnupg/gpg.conf bzw. ~/.gnupg/gpg.conf-2 (gpg 2.x). Unter Windows C:\Users\[your user name]\AppData\Roaming\GnuPG (ab Vista) bzw. C:\Documents and Settings\[your user name]\Application Data\GnuPG (XP).

In der Konfigurationsdatei können nur die Langversionen der Optionen verwendet werden. Die beiden führenden Bindestriche müssen weggelassen werden. Aus --expert wird also expert. Wie üblich kann man Werte aus der Konfigurationsdatei bei einzelnen Aufrufen von GnuPG überschreiben, indem man den Wert auf der Kommandozeile angibt; der hat Vorrang (siehe aber Zusammenwirken von list options auf der Kommandozeile mit denen in der Konfigurationsdatei für den Spezialfall Parameterlisten). Man kann mittels --no-options dafür sorgen, dass die Konfigurationsdatei komplett ignoriert wird (und das Verzeichnis ~/.gnupg/ nicht erzeugt wird), mit --options kann man eine alternative Konfigurationsdatei angeben (relativ zum aktuellen Verzeichnis, nicht zum Konfigurationsverzeichnis). Mit --homedir (oder, mit geringerer Priorität, der Umgebungsvariable $GNUPGHOME, unter Windows der Registry-Eintrag HKCU\Software\GNU\GnuPG:HomeDir) kann man das Konfigurationsverzeichnis festlegen; in der Konfigurationsdatei wird diese Option nicht ausgewertet.

Mittels --homedir kann man beispielsweise abweichende Konfigurationen für einzelne Applikationen festlegen. Ich nutze kgpg nur als Krypto-Editor, und das eigentlich auch nur für meine eigenen Schlüssel. Die lange Liste von Schlüsseln bei der Auswahl nervt eigentlich nur. Also habe ich das Verzeichnis ~/.gnupg/apps/kgpg angelegt, darin eine angepasste ~/.gnupg/gpg.conf (den Dateinamen gpg.conf-2 mag kgpg erstaunlicherweise nicht) erzeugt, meine privaten und öffentlichen Schlüssel importiert und random_seed mit der eigentlichen Datei verlinkt. Ich wurde dazu geradezu provoziert, weil man in kgpg explizit ein gpg-Konfigurationsverzeichnis angeben kann. Wäre das nicht möglich (wie in anderen Programmen, etwa Enigmail), hätte sich derselbe Effekt wohl durch Angabe von gpg --homedir /home/hl/.gnupg/apps/kgpg erreichen lassen; habe ich aber bisher nicht ausprobiert. Schlimmstenfalls müsste man das mit einem Wrapperscipt, das den Aufruf von gpg in (bezogen auf bash) exec gpg --homedir /home/hl/.gnupg/apps/kgpg "$@" ändert, lösen können.

Ein Beispiel dafür, was man in eine Konfigurationsdatei schreiben kann (für Erklärungen s.u.):

# wegen Offline-Hauptschlüssel
trusted-key 0xBD7D6D27ECCB5814
default-key  0xD44C6A5B71B0427CCED3025CBD7D6D27ECCB5814
encrypt-to  0xECCB5814
keyserver  hkp://eu.pool.sks-keyservers.net
force-mdc
ask-cert-level
set-policy-url http://www.hauke-laging.de/openpgp/policy.html
expert
utf8-strings
keyid-format 0xshort
s2k-mode 3
s2k-count 1000000
verify-options show-notations,show-policy-urls,show-keyserver-urls
list-options show-policy-urls,show-notations,show-sig-expire,show-keyserver-urls,show-uid-validity

GnuPG kann inzwischen nicht mehr nur OpenPGP verwenden, sondern auch das zweite relevante Kryptografieverfahren, S/MIME. Es wird auch von dem grafischen Programm Kleopatra unterstützt, das sowohl für Windows als auch für Linux (usw.) zur Verfügung steht.

Installation

Man kann gpg direkt von der GnuPG-Webseite herunterladen. Das ist aber zumeist nicht der beste Weg (Ausnahme: frühe Updates unter Windows).

Unter Linux u.Ä. sollte gpg sowieso installiert sein, alleine schon für die Prüfung der Integrität von Updates. Jede relevante Distribution bietet die Installation und Updates für gpg an.

Für Windows-Anwender ist es am einfachsten, das kostenlose Programm Gpg4win zu installieren. Dies ist ein grafisches Installationsprogramm, das gpg und einige (grafische) Zusatzprogramme (Schlüsselverwaltung; Integration in den Windows-Dateimanager) beinhaltet. Außerdem gibt es eine deutsches Onlinehilfe. Dieses Programm wurde im Auftrag des BSI (Bundesamt für Sicherheit in der Informationstechnik) erstellt (BSI-Webseite zu Gpg4win).

Für MacOS ist www.gpgtools.org die richtige Anlaufstelle.

Weitere relevante Downloadlinks, u.a. für die Plug-ins für Mailprogramme, finden sich hier.

Kompatibilität

Wie so ziemlich jede komplexe Software wird auch GnuPG ständig weiterentwickelt, was alleine schon der Entwicklung der Kryptografie geschuldet ist. Das bringt es mit sich, dass nicht alle Funktionen abwärtskompatibel sind. Wenn man die Möglichkeiten einer neuen Version von GnuPG ausreizt, erzeugt man Daten, die die Nutzer alter Versionen oder anderer PGP-Programme nicht verwenden können. Es gibt eine Reihe von Optionen in GnuPG, um die Kompatibilität zu beeinflussen (z.B. --pgp2, --pgp6, --pgp7, --pgp8), aber manche Hürden lassen sich damit nicht umgehen.

In der Praxis ist das kein großes Problem, zumal sowieso die meisten Leute GnuPG einsetzen (und leicht aktualisieren können). Wenn man aus eigenem Antrieb GnuPG benutzt, sollte man eine moderne Konfiguration wählen. Für den seltenen Fall, dass man später mit jemandem korrespondieren will, der engere technische Restriktionen hat, kann man schlimmstenfalls immer noch einen neuen Schlüssel erzeugen. Man tut sich und der Welt aber keinen Gefallen, wenn man sich rein präventiv auf den kleinsten gemeinsamen Nenner beschränkt.

Support

Weitere Informationen findet man auf der GnuPG-Webseite zu gpg und den zugehörigen Konsolenprogrammen, insbesondere den gpg-Kommandos und den gpg-Optionen. Außerdem gibt es natürlich auch dort FAQ.

Falls man Probleme hat, die man nicht selber lösen kann, kann man sich an die Anwender-Mailingliste wenden.

meine Angebote

Ich biete (privat) auch Schulungen zum Einsatz von OpenPGP / GnuPG an und fördere solche Schulungen durch andere.

Außerdem biete ich unter der XMPP-Adresse gnupg-support@jabber.org Live-Unterstützung an, so ich denn mit diesem Account online bin. XMPP ist ein offenes Chatprotokoll (nach dem ersten Client auch manchmal unpräzise Jabber genannt), für das es eine Vielzahl von Clientprogrammen und Serverbetreibern (u.a. Google) gibt. Man kann dafür z.B. bei jabber.org oder beim Chaos Computer Club kostenlos einen Account registrieren. Ein Client, den ich empfehlen kann (und selber verwende) und der neben XMPP eine Menge weiterer Protokolle versteht (ICQ, MSN usw., quasi alles außer Skype), ist Pidgin. Man kann also innerhalb eines einzigen Programms viele unterschiedliche Accounts und Protokolle nutzen (bei mir aktuell fünf XMPP-Dienste (inklusive Facebook), außerdem ICQ und MSN). Mit Hilfe des Plugins OTR kann Pidgin auch verschlüsseln; OTR gibt es auch für weitere IM-Clients, etwa das KDE-Programm Kopete.

häufige Fehlermeldungen

Da Suchmaschinen häufig mit Fehlermeldungen gefüttert werden (die folgenden können Meldungen von gpg oder darauf aufsetzenden oder ähnlichen Programmen sein):

die wichtigsten Aktionen

Erzeugung eines Schlüsselpaars und Schlüsselverwaltung

wichtige Kommandos --gen-key --edit-key (addkey) --edit-key (adduid) --edit-key (primary)
wichtige Optionen --expert
Links zum Thema
spezielle Kommandos --edit-key (notation) --edit-key (keyserver) --edit-key (addrevoker)
spezielle Optionen --set-notation --cert-notation --set-policy-url --cert-policy-url --allow-freeform-uid --default-keyserver-url
spezielle Links zum Thema

Wenn man sich nicht darauf beschränken will, anderer Leute Signaturen zu prüfen und anderen (unsignierte) verschlüsselte Nachrichten zu schicken, sondern auch selber (asymmetrisch, also im üblichen Sinn von OpenPGP verschlüsselte) Daten entschlüsseln oder signieren will, dann benötigt man einen eigenen Schlüssel; mindestens einen, denn es spricht nichts dagegen, sich für unterschiedliche Zwecke unterschiedliche Schlüssel zuzulegen. Wichtig ist: Die Sicherheit des Schlüssels ist nie höher als die des Systems, auf dem er erzeugt wird; das gilt abgeschwächt auch für Systeme, auf denen er (und sei es nur kurzzeitig) gespeichert wird! Diese Maßnahmen sind deshalb sinnvoll, wenn der jeweilige Schlüssel für mehr als nur Rumspielen gedacht ist:

  1. Vor der Erzeugung des Schlüssels eine Schlüsselrichtlinie erstellen. Das hilft einem dabei, sich darüber klar zu werden, was man eigentlich will, und hilft einem hinterher dabei, gemessen an diesen Vorgaben keine Fehler zu machen.

  2. Man sollte den Schlüssel in einem sicheren System erzeugen. Auch wenn man mit dem Schlüssel anfangs keine superwichtigen Dinge tun will, mag man sich später mal darüber freuen, dass der Hauptschlüssel sehr sicher ist und die Unterschlüssel mit begrenzter Gültigkeitsdauer erzeugt wurden.

  3. Den Hauptschlüssel (der eigene und andere UID-Schlüssel-Kombinationen sowie die eigenen Unterschlüssel signiert) von den Unterschlüsseln trennen, siehe den Abschnitt externe Speicherung des Primärschlüssels / Hauptschlüssels. Diese Empfehlung gilt vor allem für Schlüssel, die in einer unsicheren Umgebung (also auf "ganz normalen" PCs) verwendet oder auch nur gespeichert werden.

  4. Unterschiedliche Schlüssel für unterschiedliche Sicherheitsanforderungen erzeugen und diese Unterschiedlichkeit den Kommunikationspartnern auch mitteilen (z.B. durch einen Kommentar in der UID). Also etwa einen für den alltäglichen Einsatz wie das Signieren aller E-Mails und einen anderen für die Signierung und Verschlüsselung von Daten mit hohen Anforderungen an die Integrität oder Vertraulichkeit (z.B. Verträge über hohe Summen).

Es mag am einfachsten sein, erst mal einen Schlüssel zum Rumspielen zu erzeugen und später, mit etwas mehr Erfahrung, die für ernsthafte Zwecke.

Viele grafische OpenPGP-Programme bieten zunächst die Erzeugung eines Schlüsselpaars an, wenn sie beim Start feststellen, dass es noch keins gibt. Die Erzeugung eines Schlüssels ist nichts anderes als die Bestimmung einer geeigneten, sehr großen Zufallszahl. So groß, dass es "unmöglich" ist, sie zu raten oder durch Ausprobieren zu finden, auch wenn man tausende von Computern zusammenschaltet und jahrelang arbeiten lässt.

Darin liegt ein Problem (Sicherheitsrisiko), weil Computer eben nicht dafür geschaffen sind, zufällige Ergebnisse zu produzieren, sondern ganz im Gegenteil deterministisch arbeiten. Computer sind grundsätzlich schlechte Zufallszahlengeneratoren. Nur wenige Computer verfügen über entsprechende Zusatzhardware, die dieses Problem mehr oder weniger beseitigt (wenn man Hardware dafür hat, stellt sich nämlich die Frage, ob sie fehlerfrei funktioniert... :-) ). Deshalb passiert es leicht (vor allem bei langen Schlüsseln), dass man bei der Schlüsselerzeugung aufgefordert wird, irgendwelche Aktivitäten vorzunehmen (Tasten drücken, Maus bewegen), damit der Rechner genügend Entropie ("Zufallsdaten") sammeln kann. Unter Linux kann man sich mit dem Kommando cat /proc/sys/kernel/random/entropy_avail anzeigen lassen, wie groß der Entropiepool des Kernels gerade ist.

Wenn man die wirklich spannenden Sachen mit gpg machen will (auch bei der Erzeugung von Schlüsseln), muss man dem Programm mitteilen, dass man entsprechend furchtlos ist:

start cmd:> gpg --expert --gen-key
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (1) RSA und RSA (voreingestellt)
   (2) DSA und Elgamal
   (3) DSA (nur signieren/beglaubigen)
   (4) RSA (nur signieren/beglaubigen)
   (7) DSA (Leistungsfähigkeit selber einstellbar)
   (8) RSA (Leistungsfähigkeit selber einstellbar)
Ihre Auswahl?

Dadurch werden eine Menge Optionen freigeschaltet, die GUIs normalerweise nicht bieten. Beispiel – dasselbe ohne --expert (kann man sich übrigens in die Konfigurationsdatei schreiben):

start cmd:> gpg --gen-key
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (1) RSA und RSA (voreingestellt)
   (2) DSA und Elgamal
   (3) DSA (nur signieren/beglaubigen)
   (4) RSA (nur signieren/beglaubigen)
Ihre Auswahl?

Ich empfehle für die meisten Schlüssel, einen RSA-Hauptschlüssel zu erzeugen, der signieren und entschlüsseln kann (Auswahl 8), und zusätzlich (in einem zweiten Schritt) jeweils einen RSA-Unterschlüssel für Signaturen und Entschlüsselung (und, falls für SSH benötigt, außerdem einen für Authentisierung) zu erzeugen; der Hauptschlüssel sollte sofort nur offline gespeichert werden.

Primärschlüssel / Hauptschlüssel

Sowohl aus technischen als auch organisatorischen Gründen bestehen OpenPGP-Schlüssel normalerweise aus mehr als einem Schlüssel, typischerweise aus zweien. Der Primärschlüssel / Hauptschlüssel ist, man ahnt es schon, der wichtigste. Seine Wichtigkeit resultiert daraus, dass er zwingend in der Lage sein muss und als einziger in der Lage ist, die eigenen Unterschlüssel und außerdem die eigenen Benutzerkennungen (UIDs: meist Name, E-Mail-Adresse, ggf. ein Kommentar) sowie die anderer Schlüssel zu unterschreiben. Wenn ein OpenPGP-Schlüssel in seiner Gesamtheit identifiziert wird (mit dem Fingerprint), bezieht sich dies auf den Primärschlüssel / Hauptschlüssel.

externe Speicherung des Primärschlüssels / Hauptschlüssels und Schlüsselfähigkeiten

Es ist sinnvoll, einen Schlüssel so zu erzeugen, dass der Primärschlüssel / Hauptschlüssel zertifizieren, signieren und entschlüsseln kann (damit man auch ohne dedizierten Hochsicherheitsschlüssel im Einzelfall / Notfall auf hohem Sicherheitsniveau signieren und verschlüsselt kommunizieren kann), und diesen nicht auf einem normalen Arbeitsrechner zu speichern (oder ihn zumindest mit einer langen (20 Zufallszeichen bei Groß- und Kleinbuchstaben und Ziffern, so wie ZlpZn5DFYlrULFCh3ywS) Passphrase zu schützen, die (natürlich nicht dieselbe ist wie bei den Unterschlüsseln und) im normalen Betrieb nie eingegeben wird, sondern etwa nur dann, wenn man von einem sicheren Medium bootet). Man kann aber für alle hochsicheren Schlüssel(komponenten) dieselbe kryptografisch harte Passphrase verwenden. Für Motivation und die Vorgehensweise siehe unten.

Schlüsseltypen

Die derzeit von GnuPG unterstützten Schlüsseltypen sind RSA, DSA und ElGamal; in naher Zukunft ist die Unterstützung von ECC zu erwarten. Für normale Zwecke bestehen keine relevanten Unterschiede zwischen den beiden Verfahren. Der Primärschlüssel kann nur ein DSA- oder RSA-Schlüssel sein. Ich empfehle die Verwendung von RSA-Schlüsseln, weil die mit der g10-Smartcard verwendet werden können. Außerdem haben DSA- und ECDSA-Schlüssel den Nachteil, dass sie schon dadurch kompromittiert werden, dass sie auf einem System, das schlechte Zufallszahlen liefert (siehe das Debian-Desaster), eine Signatur erzeugen.

Die gängigen Algorithmen für einen Primärschlüssel sind RSA und DSA. RSA-Schlüssel haben den wesentlichen Vorteil, auf die aktuelle Version der g10-Smartcard kopiert werden zu können. Wenn man den Hauptschlüssel aber sowieso nur in einer sicheren Umgebung verwendet (Booten von CD/DVD) und sicher verwahrt (lange Passphrase, die nur auf sicheren Systeme eingegeben wird), ist das weniger wichtig; dann reicht es, die Unterschlüssel auf der Smartcard zu haben. Man kann also einen DSA-Hauptschlüssel mit RSA-Unterschlüsseln auf einer Smartcard kombinieren. Ob es dafür gute Gründe gibt, ist eine andere Frage...

Die gängige Struktur eines OpenPGP-Schlüssels sieht so aus, dass er einen RSA- oder DSA-Primärschlüssel hat, der Daten (S) und andere Schlüssel (C; nur diese Fähigkeit ist ganz allgemein zwingend) signieren kann (bzw. darf) und eventuell auch zur Authentifizierung (A) verwendet werden kann und der einen Elgamal-Unterschlüssel zum Verschlüsseln (E) hat.

DSA hat bei Verwendung von Schlüsseln bis 1024 Bit den Nachteil, dass Hashwerte nur bis 160 Bit Länge erzeugt werden können. 2048-Bit-DSA-Schlüssel sind aber zu alten Implementierungen nicht kompatibel (und müssen in früheren GnuPG-Versionen erst mit -enable-dsa2 freigeschaltet werden).

Es bestehen große Unterschiede in der Performance von RSA-, DSA- und ElGamal-Operationen. Für Leute, die nur im üblichen Umfang Kryptooperationen durchführen, ist das belanglos. Wenn jemand zigtausende von Signaturen erzeugen oder prüfen muss, mag es relevant werden. RSA verschlüsselt mehr als zehnmal so schnell wie ElGamal, ist beim Entschlüsseln aber etwa 15% langsamer. ElGamal-Nachrichten sind länger als dieselbe Nachricht in RSA-Verschlüsselung. Für die Erzeugung einer Signatur braucht RSA etwa fünfmal so lange wie DSA, aber DSA für die Prüfung einer Signatur etwa 30mal so lange wie RSA. Bei großen Datenmengen pro Signatur sollten sich diese Unterschiede verringern.

Schlüssellänge

Für alle Schlüssel muss die gewünschte Länge angegeben werden. Meist sind dies 1024, 2048 oder 4096 Bit. 1024 Bit ist inzwischen in den kritischen Bereich gerutscht; ich empfehle 2048 Bit.

Die naheliegende Frage, warum man nicht automatisch immer 4096 nehmen solle, wenn das doch problemlos möglich sei, wurde von einem der Gurus auf der GnuPG-Mailingliste mal wie folgt beantwortet: Damit in den nächsten 10+ Jahren 2048-Bit-Schlüssel geknackt werden können, müssen derart abartige Dinge passieren (in der Technik oder Mathematik), dass man davon ausgehen darf, dass diese Entwicklung dann auch gleich die 4096-Bit-Schlüssel erledigt. (Ende der Widergabe) Die Lebensdauer von Hashfunktionen liegt sowieso weit unter der von 2048-Bit-Schlüsseln. Relevant mögen die 4096 Bit Länge für jemanden sein, der Daten verschlüsselt und auf Jahrzehnte sicher sein will, dass sie nicht entschlüsselt werden können. Wenn einem also nicht egal ist, ob die Daten in 20 oder 35 Jahren gelesen werden können, mag man sich den längeren Schlüsseln zuwenden. Aber mit derart extremen Anforderungen sollte man vielleicht auch nicht mehr auf die Sicherheit von AES vertrauen, sondern die Daten zweimal verschlüsseln, mit unterschiedlichen Algorithmen.

Die Erzeugung eines 2048-Bit-Schlüssels dauert schon merklich lange (ganz abgesehen von dem o.g. Problem, dass normale Rechner gar nicht so viel Entropie besitzen, so dass man am Ende viel scheinbare Sicherheit hat). Bei einem 4096-Bit-Schlüssel dauert nicht nur die Erzeugung ewig, sondern auf langsamen Rechnern auch die Verwendung des Schlüssels lange.

Die g10-Smartcard kann mit aktuellen Versionen von GnuPG auch RSA-Schlüssel mit einer Länge bis 4096 Bit Länge verwenden. Man sollte längere RSA-(Unter-)Schlüssel (und auch Nicht-RSA-Unterschlüssel) deshalb nur dann erzeugen, wenn man genau weiß, was man tut; also speziell, dass man niemals (für diesen Schlüssel) eine Smartcard verwenden wird.

Der Sicherheitsgewinn bei RSA- und DSA-Schlüsseln durch eine größere Länge ist bescheiden. Die Zukunft der Schlüssel liegt deshalb in neuen Verfahren (eliptische Kurven, ECC), die mit sehr viel kürzeren Schlüsseln auskommen. Man darf die Länge eines RSA-Schlüssels nicht mit der eines symmetrischen Schlüssels verwechseln. Ein symmetrischer 128-Bit-Schlüssel ist nach menschlichem Ermessen auch in den nächsten Jahrzehnten nicht zu knacken (2¹²⁸=340282366920938463463374607431768211456~3,4×10³⁸). Das Restrisiko liegt in der fraglichen Zufälligkeit des Schlüssels und der Sicherheit des Verschlüsselungsverfahrens.

Ein asymmetrischer Schlüssel muss sehr viel länger sein als ein symmetrischer, um dieselbe Sicherheit zu bieten:

ungefähr äquivalente Schlüssellängen
symmetrisch asymmetrisch (RSA, DSA) asymmetrisch (ECC)
80 1024 160
112 2048 224
128 3072 256
192 7680 384
256 15360 512

Gültigkeitszeitraum

Sinnvoll ist eine Beschränkung des Gültigkeitszeitraums sowohl für Hauptschlüssel als auch für Unterschlüssel, denn diese Beschränkung ist nicht in Stein gemeißelt, sondern kann mit Hilfe des Hauptschlüssels beliebig oft geändert werden (indem eine neue self signature erzeugt wird, die dann das neuen Ablaufdatum enthält). Wenn sie ungültig werden, können die Verwender des eigenen Schlüssels sich mit wenig Aufwand eine aktualisierte Version des Schlüssels mit verlängerten Gültigkeitszeiträumen beschaffen. Die bestehenden Zertifizierungen beziehen sich nicht auf das Ablaufdatum, so dass der neue Schlüssel ohne weiteres als gültig erkannt wird. Ob Kommunikationspartner allerdings immer clever genug sind, im Fall eines abgelaufenen Hauptschlüssels nach einer neueren Version des Schlüssels zu suchen, ist eine andere Frage. Bei Sicherheitssoftware sollte man die Kompromisse aber nicht an den Kompetenzmängeln mancher Nutzer ausrichten. Der Schaden ist größer, wenn man auf ein Ablaufdatum verzichtet.

Es gibt allerdings auch ein Argument für Hauptschlüssel mit endlicher Lebensdauer (mal abgesehen davon, dass niemand mehr in 20 Jahren die heutigen Schlüssel verwenden wird: Das nächste Schlüsselformat für OpenPGP steht vor der Tür. Sobald der SHA-3 festgelegt ist, ist damit zu rechnen.): Man kann (mit Hilfe des privaten Hauptschlüssels) die Gültigkeitsdauer von Unterschlüsseln und auch die des Hauptschlüssels verlängern. Wenn man die Gültigkeitsdauer nicht verlängert, heißt das, dass man sie entweder nicht verlängern kann oder will. In beiden Fällen gibt es keinen Grund, warum der Schlüssel weiter benutzt werden sollte.

Das Ablaufdatum eines bestehenden Schlüssels ändert man mit gpg --edit-key 0xeccb5814 – dann wählt man (falls es um einen Unterschlüssel geht) mit z.B. key 1 den gewünschten Unterschlüssel (nur einen zur Zeit, entsprechend der Liste des Kommandos list, die aber schon standardmäßig angezeigt wird) aus und setzt dann über das Kommando expire den neuen Zeitstempel. Wird kein Unterschlüssel ausgewählt, wird nur die Gültigkeit des Hauptschlüssels bearbeitet; die der Unterschlüssel bleibt unverändert. Es ist möglich, das gewünschte Datum direkt zu setzen (als JJJJ-MM-TT), nicht aber die Uhrzeit. Jedenfalls war das vor Jahren noch so, und ich habe nichts Anderslautendes finden können. Die Uhrzeit übernimmt gpg in dem Fall offenbar vom Hauptschlüssel. Diese Schlüsselbearbeitung ist nicht möglich, wenn der private Hauptschlüssel offline gespeichert wird. Diese Änderung sollte also nur in einem sicheren System vorgenommen werden, in das der private Hauptschlüssel ggf. zuvor importiert wird.

Änderung der Gültigkeit des Hauptschlüssels:

start cmd:> gpg --local-user 0xeccb5814 --edit-key 0xeccb5814
pub  1024D/0xECCB5814  erzeugt: 2005-09-05  verfällt: niemals     Aufruf: SCA 
                       Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  2048R/0x51B279FA  erzeugt: 2010-03-04  verfällt: 2013-03-03  Aufruf: E   
sub  2048R/0x3A403251  erzeugt: 2010-03-04  verfällt: 2013-03-03  Aufruf: S   
sub  2048R/0x2282921E  erzeugt: 2010-03-08  verfällt: 2013-03-07  Aufruf: A   
[ uneing.] (1). Hauke Laging <hauke@laging.de>

gpg> expire
Ändern des Verfallsdatums des Hauptschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0)

Änderung der Gültigkeit eines Unterschlüssels:

start cmd:> gpg --local-user 0xeccb5814 --edit-key 0xeccb5814
pub  1024D/0xECCB5814  erzeugt: 2005-09-05  verfällt: niemals     Aufruf: SCA 
                       Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  2048R/0x51B279FA  erzeugt: 2010-03-04  verfällt: 2013-03-03  Aufruf: E   
sub  2048R/0x3A403251  erzeugt: 2010-03-04  verfällt: 2013-03-03  Aufruf: S   
sub  2048R/0x2282921E  erzeugt: 2010-03-08  verfällt: 2013-03-07  Aufruf: A   
[ uneing.] (1). Hauke Laging <hauke@laging.de>

gpg> key 1

pub  1024D/0xECCB5814  erzeugt: 2005-09-05  verfällt: niemals     Aufruf: SCA 
                       Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 2048R/0x51B279FA  erzeugt: 2010-03-04  verfällt: 2013-03-03  Aufruf: E   
sub  2048R/0x3A403251  erzeugt: 2010-03-04  verfällt: 2013-03-03  Aufruf: S   
sub  2048R/0x2282921E  erzeugt: 2010-03-08  verfällt: 2013-03-07  Aufruf: A   
[ uneing.] (1). Hauke Laging <hauke@laging.de>

gpg> expire
Ändern des Verfallsdatums des Unterschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0)

Das ist für alle zu bearbeitenden Unterschlüssel zu wiederholen. Vorher ist durch erneute Angabe von key n oder von key ohne Parameter der gerade bearbeitete Unterschlüssel zu deselektieren.

Direkte Eingabe des Zieldatums (im --edit-key-Menü):

gpg> expire
Ändern des Verfallsdatums des Hauptschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2013-12-31
Key verfällt am Di 31 Dez 2013 11:59:47 CET
Ist dies richtig? (j/N)

Die Gültigkeit von Unterschlüsseln zu verlängern erscheint am ehesten bei solchen Unterschlüsseln sinnvoll, die mittels einer Smartcard oder nur in einer sicheren Umgebung verwendet werden. Alle anderen können unbemerkt kompromittiert worden sein. Durch den regelmäßigen Austausch der Unterschlüssel reduziert man den Schaden, den ein Angreifer anrichten kann (wenn das fragliche Sicherheitsproblem in der Zwischenzeit abgestellt wurde).

Man kann (mit dem Konsolen-gpg auch getrennt für Primär- und Unterschlüssel) die maximale Gültigkeit des Schlüssels festlegen. Nach dem Verfallsdatum verweigern die Programme normalerweise die Verwendung des Schlüssels. Eine endliche Lebensdauer verhindert, dass versehentlich uralte Schlüssel verwendet werden, die vom Eigentümer gar nicht mehr benutzt werden und vielleicht schon kompromittiert sind. Eine kurze Gültigkeit des Primärschlüssels bringt allerdings das Problem mit sich, dass nach entsprechend kurzer Zeit alle Verwender des Schlüssels den Nachfolge(unter)schlüssel erhalten müssen. Das Problem lässt sich verringern, indem man Schlüssel mit überlappenden Gültigkeitszeiträumen verwendet. Wer den Schlüssel aktualisiert, verwendet automatisch den neueren, die anderen können problemlos noch den alten verwenden.

Das größere Problem als die Schlüsselaktualisierung dürfte, insbesondere bei der Verwendung von E-Mails, die nicht mehr uneingeschränkte Validierung der Signaturen sein. Wenn man die Prüfung mit gpg direkt durchführt, sieht man wenigstens, was los ist:

start cmd:> gpg --verify test.html.71FDC5CB.sig test.html
gpg: Signatur vom Fr 23 Jul 2010 01:57:32 CEST
gpg:                mittels RSA-Schlüssel 0xBB8A54D2
gpg: Korrekte Signatur von "Test Key (Demo) <test@key.inv>"
[...]
gpg: Hinweis: Dieser Schlüssel ist verfallen!

gpg beendet sich in diesem Fall aber nicht mit einem Fehlercode! (Im Scriptaufruf bekommt man dann (über --status-fd) den Wert EXPKEYSIG statt GOODSIG.) Was man im GUI sieht, ist Glückssache (GPA macht es richtig.) Aber selbst ein Mailprogramm mit ansonsten hervorragender OpenPGP-Integration wie KMail versagt in diesem Fall total: Die Signatur eines verfallenen Schlüssels wird genau so angezeigt wie eine fehlerhafte Signatur, ohne jeden Hinweis auf das eigentliche Problem. Die Lösung solcher Probleme ist die rechtzeitige Signierung mit einem anderen Schlüssel. Das passiert in der Praxis ständig (wenn auch nicht unbedingt mit OpenPGP): Rechnungen müssen für den Fall einer Steuerprüfung zehn Jahre aufbewahrt werden. Im Fall digitaler Rechnungen mit einer qualifizierten Signatur heißt das natürlich, dass sie zehn Jahre lang eine gültige Signatur haben müssen. Die für Signaturen verwendeten Algorithmen werden vom BSI aber generell nur fünf Jahre im voraus für zulässig erklärt, die Gültigkeit des Unterschrifts-Zertifikats endet meist schon nach viel kürzerer Zeit. Es ist also gar nicht möglich, eine Datei derart mit einer qualifizierten Signatur zu versehen, dass sie in zehn Jahren noch gültig signiert ist. Die Lösung des Problems ist einfach: Man signiert (die Daten und) die Signatur rechtzeitig vor ihrem Verfall mit einem anderen Schlüssel, der entsprechend länger gültig ist. Dieser Vorgang muss dann regelmäßig wiederholt werden. Beispiel: 2010 wurde ein Dokument von einem Schlüssel signiert, dessen Zertifikat 2013 abläuft. Wenn diese Signatur nun 2012 mit einem Schlüssel signiert wird, dessen Zertifikat bis 2015 gültig ist, dann ist 2014 die erste Signatur zwar ungültig, aber mit der späteren kann nachgewiesen werden, dass die erste Signatur bereits zu einem Zeitpunkt existierte, zu dem sie noch gültig war:

__________________________2010___2011___2012___2013___2014___2015___2016___
Signaturerstellung             1             2           [   3   ]
Gültigkeit Schlüssel 1      ======================
Gültigkeit Schlüssel 2                     =======================    
Gültigkeit Schlüssel 3                                   ===================

Gut zu sehen ist, dass Verlängerungssignaturen immer in dem Zeitraum entstehen müssen, in dem beide Schlüssel (der alte und der neue) gültig sind.

Dieses Verfahren beugt auch den Problemen vor, die entstehen, wenn ein Schlüssel zurückgezogen wird. Das Datum einer Signatur ist trivial fälschbar. Wenn man eine Mail oder Datei hat, die angeblich 2011 signiert wurde, der Schlüssel aber 2012 zurückgezogen (revoke) wird, wie soll man dann 2013 entscheiden, ob diese Daten gültig sind, weil sie signiert wurden, bevor der Schlüssel kompromittiert wurde, oder erst danach? Wenn man die Signatur beim Empfang selber signiert hat, kann man dies sicher entscheiden. Leider bietet meines Wissens kein Mailprogramm so ein Feature.

Man kann (mit Hilfe des Hauptschlüssels) sogar nachträglich die Gültigkeitszeiträume verändern; sowohl für die Unterschlüssel als auch für den Hauptschlüssel selber.

Das häufige Wechseln von Unterschlüsseln kann problematisch sein, wenn man für diese Schlüssel eine Smartcard nutzt, weil man dann nicht mehr alle Schlüssel auf einer Karte hat. die Gültigkeitsbegrenzung bietet sich also in erster Linie für Schlüssel an, die ganz normal auf einem PC gespeichert sind, zumal Schlüssel auf einer Smartcard kaum in Gefahr sind, kompromittiert zu werden.

Unterschlüssel

Es können beliebig viele Unterschlüssel angelegt werden, deren Algorithmus (DSA/RSA/Elgamal), Länge und Fähigkeiten (S/A/E) nichts mit dem Primärschlüssel zu tun haben, allerdings begrenzt der Algorithmus des Unterschlüssels eventuell dessen Länge und (von OpenPGP/GnuPG unterstützte) Fähigkeiten; so kann (bzw. darf) beispielsweise Elgamal (in GnuPG) nur verschlüsseln, DSA nur Schlüssel bis 1024 Bit Länge erzeugen und nur Hashwerte bis 160 Bit für Signaturen verwenden (siehe --enable-dsa2 für die Aufhebung dieser Limitationen).

Es kann sinnvoll sein, mehrere Unterschlüssel für dieselbe Aktion zu haben. Auf diese Weise kann man etwa Kompatibilitätsprobleme umgehen. Wenn ein Kommunikationspartner einen neuen Unterschlüssel nicht verwenden kann, weil seine OpenPGP-Implementierung z.B. den Algorithmus noch nicht kennt, dann muss man auf die Vorteile der neuen Technik nicht verzichten: Man erzeugt einfach zwei Schlüssel, einen davon zu Kompatibilitätszwecken in einer älteren Variante. Man sollte aber den Schlüssel, der bevorzugt verwendet werden soll, als letzten erzeugen, damit GnuPG ihn standardmäßig auswählt. Wenn der für jemanden nicht funktioniert, sollte sein System automatisch auf den anderen ausweichen.

Im allgemeinen spielt die Geschwindigkeit von Kryptografieoperationen keine Rolle (Ausnahmen: beispielsweise massenhafte Verschlüsselung / Signierung; lange Schlüssel auf langsamer Hardware); der Vollständigkeit halber: RSA ist beim Verschlüsseln immens schneller als ElGamal; beim Entschlüsseln ist es geringfügig langsamer. Beim Erstellen von Signaturen RSA drastisch langsamer als DSA, beim Überprüfen aber extrem schneller. Sollte man wirklich mal ein Performanceproblem haben oder befürchten, mag es sinnvoll sein, jeweils beide Arten von Unterschlüsseln zu erzeugen und in relevanten Fällen die jeweils geeigneteren zu verwenden.

Ein abschreckendes Beispiel für die Anzeige eines Schlüssels mit vielen Unterschlüsseln:

start cmd:> gpg --list-keys 0x71FDC5CB
pub   1024D/71FDC5CB 2010-02-25 [verfällt: 2011-02-25]
uid                  Test Key (Demo) <test@key.inv>
sub   1024D/DE57F59A 2010-02-25 [verfällt: 2010-12-22]
sub   1024R/BB8A54D2 2010-02-25 [verfällt: 2011-01-21]
sub    512g/801FDB58 2010-02-25 [verfällt: 2010-12-22]
sub   1024R/7D2C11A4 2010-02-25 [verfällt: 2011-01-21]
sub   1024D/1C0A9017 2010-02-25 [verfällt: 2012-02-25]
sub   1024R/027DBA86 2010-02-25 [verfällt: 2013-02-24]

Angezeigt werden Länge (1024 Bit), Typ (DSA), (short) ID (71FDC5CB), Erzeugungs- und Verfallsdatum des Primärschlüssels sowie von sechs unterschiedlichen Unterschlüsseln sowie die einzige UID dieses Schlüssels. Warum es so viele Unterschlüssel sind, zeigt sich bei einem anderen gpg-Aufruf (siehe die Spalte ganz rechts):

start cmd:> gpg --expert --edit-key 0x71FDC5CB
Geheimer Schlüssel ist vorhanden.

pub  1024D/71FDC5CB  erzeugt: 2010-02-25  verfällt: 2011-02-25  Aufruf: C
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  1024D/DE57F59A  erzeugt: 2010-02-25  verfällt: 2010-12-22  Aufruf: S
sub  1024R/BB8A54D2  erzeugt: 2010-02-25  verfällt: 2011-01-21  Aufruf: S
sub   512g/801FDB58  erzeugt: 2010-02-25  verfällt: 2010-12-22  Aufruf: E
sub  1024R/7D2C11A4  erzeugt: 2010-02-25  verfällt: 2011-01-21  Aufruf: E
sub  1024D/1C0A9017  erzeugt: 2010-02-25  verfällt: 2012-02-25  Aufruf: A
sub  1024R/027DBA86  erzeugt: 2010-02-25  verfällt: 2013-02-24  Aufruf: A
[ uneing.] (1). Test Key (Demo) <test@key.inv>

Jeweils zwei Unterschlüssel können Daten signieren (S), verschlüsseln/entschlüsseln (E) oder authentifizieren (A). Der Primärschlüssel kann als einziger beglaubigen (C) und auch nur das. Normalerweise hat man nicht so viele Schlüssel gleichzeitig im Einsatz; das dient hier nur Demonstrationszwecken.

Es folgt die Anzeige der Signaturen:

start cmd:> gpg --list-sigs 0x71FDC5CB
pub   1024D/71FDC5CB 2010-02-25 [verfällt: 2011-02-25]
uid                  Test Key (Demo) <test@key.inv>
sig 3        71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>
sig 3        ECCB5814 2010-02-25  Hauke Laging <hauke@laging.de>
sub   1024D/DE57F59A 2010-02-25 [verfällt: 2010-12-22]
sig          71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>
sub   1024R/BB8A54D2 2010-02-25 [verfällt: 2011-01-21]
sig          71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>
sub    512g/801FDB58 2010-02-25 [verfällt: 2010-12-22]
sig          71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>
sub   1024R/7D2C11A4 2010-02-25 [verfällt: 2011-01-21]
sig          71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>
sub   1024D/1C0A9017 2010-02-25 [verfällt: 2012-02-25]
sig          71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>
sub   1024R/027DBA86 2010-02-25 [verfällt: 2013-02-24]
sig          71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>

Man sieht, dass die UID und alle Unterschlüssel vom Primärschlüssel beglaubigt sind und dass andere Schlüssel (hier: 0xECCB5814) nur UIDs beglaubigen. Die 3 hinter sig gibt an, dass die beglaubigende Person die beglaubigte Identität nach eigener Einschätzung (siehe Signatur-Policy, sofern vorhanden) sehr sorgfältig geprüft hat. 2 würde bedeuten, dass er ihn flüchtig geprüft hat, 1, dass er ihn gar nicht geprüft hat, und 0 bzw. keine Anzeige bedeutet, dass die beglaubigende Person keine Angabe dazu macht, wie sorgfältig sie war.

Ein Sicherheitsproblem entsteht dadurch, dass man zwar sicher sein kann, dass ein Unterschlüssel vom Besitzer des Hauptschlüssels signiert wurde, nicht aber sicher sein, dass es sich dabei um einen Unterschlüssel handelt, der dem Hauptschlüsselbesitzer gehört. Jeder kann sich (prinzipiell) einen existierenden Unterschlüssel (von jemand anderem) mit seinem Hauptschlüssel unterschreiben und dadurch den Eindruck erwecken, es sei seiner. Er kann natürlich weder Daten für diesen Unterschlüssel entschlüsseln noch Signaturen mit ihm erzeugen, weil ihm der private Schlüssel fehlt. Aber Verwirrung kann man auf diese Weise stiften. Dieses Problem wurde vor einiger Zeit in OpenPGP behoben, jedenfalls für Signatur-Unterschlüssel (die problematischer sind). Wenn ein Signatur-Unterschlüssel erzeugt wird, dann wird mit diesem der Hauptschlüssel signiert. Diese zusätzliche Signatur garantiert, dass der Unterschlüssel zum Hauptschlüssel gehört. Wenn diese Zusatzsignatur fehlt (weil ein Schlüssel vor langer Zeit erstellt wurde), gibt gpg eine Warnung aus, die auf den entsprechenden Teil die GnuPG-Webseite verweist.

Auswahl der Unterschlüssel

gpg wählt automatisch den (bzw. einen) passenden Unterschlüssel aus. Normalerweise gibt man als Benutzer nur an, welcher Hauptschlüssel verwendet werden soll. Wenn mehrere Schlüssel in Frage kommen, wählt gpg denjenigen aus, der zuletzt erzeugt wurde. Man kann aber auch, was selten benötigt werden sollte, den zu verwendenden Unterschlüssel angeben (oder den Hauptschlüssel auf diese Weise, wenn er statt eines Unterschlüssels verwendet werden soll, etwa für besonders sichere Signaturen eines Offline-Hauptschlüssels). Statt des Hauptschlüssels 71FDC5CB

gpg --encrypt --symmetric --recipient 0x71FDC5CB testdatei.txt

gibt man dann mit Ausrufezeichen die ID des Unterschlüssels an, etwa 801FDB58:

gpg --encrypt --symmetric --recipient 0x801FDB58! testdatei.txt

Das funktioniert natürlich nicht, wenn man – wie üblich – gpg nicht direkt verwendet, sondern über eine Anwendung (Mailprogramm). Mir ist auch keine Möglichkeit bekannt, das über die Konfiguration von gpg zu regeln. Man kann natürlich immer – auf die harte Tour – den Empfängerschlüssel sichern (exportieren), alle zu vermeidenden Unterschlüssel löschen, die Aktion durchführen und dann die Unterschlüssel (durch Importieren des vorher exportierten Schlüssels) wiederherstellen.

Ob eine Signatur mit dem Haupt- oder einem Unterschlüssel erzeugt wurde, kann man leicht sehen:

start cmd:> gpg --verify hauke__0x1a571df5.asc.asc
gpg: Signatur vom So 04 Nov 2012 05:54:37 CET
gpg:                mittels RSA-Schlüssel 0x1A571DF5
gpg: Korrekte Signatur von "Hauke Laging (Standardschlüssel: siehe policy URL und signature notations)"
gpg:                     alias "Hauke Laging (Standardadresse) <hauke@laging.de>"

start cmd:> gpg --verify hauke__0x1a571df5.asc.sig 
gpg: Signatur vom So 04 Nov 2012 05:56:05 CET
gpg:                mittels RSA-Schlüssel 0x3F96AD8E
gpg: Korrekte Signatur von "Hauke Laging (Standardschlüssel: siehe policy URL und signature notations)"
gpg:                     alias "Hauke Laging (Standardadresse) <hauke@laging.de>"

start cmd:> gpg --verbose --verify hauke__0x1a571df5.asc.sig 
gpg: die unterzeichneten Daten sind wohl in hauke__0x1a571df5.asc
gpg: Signatur vom So 04 Nov 2012 05:56:05 CET
gpg:                mittels RSA-Schlüssel 0x3F96AD8E
gpg: der Unterschlüssel 0x3F96AD8E wird anstelle des Hauptschlüssels 0x1A571DF5 verwendet
gpg: verwende Vertrauensmodell PGP
gpg: Korrekte Signatur von "Hauke Laging (Standardschlüssel: siehe policy URL und signature notations)"
gpg:                     alias "Hauke Laging (Standardadresse) <hauke@laging.de>"
gpg: Binäre Signatur, Hashmethode "SHA1"

Die erste abgetrennte Signatur (hauke__0x1a571df5.asc.asc) wurde mit dem Hauptschlüssel erzeugt, die zweite (hauke__0x1a571df5.asc.sig) mit dem Unterschlüssel. Bei einem normalen Aufruf wird nur die ID ausgegeben; die muss man dann schon erkennen, um zu wissen, woran man ist. Wenn man aber gpg mittels --verbose (das zur Steigerung des Effekts auch mehrfach angegeben werden kann) auf gesprächig schaltet, bekommt man (u.a.) den Hinweis explizit: der Unterschlüssel 0x3F96AD8E wird anstelle des Hauptschlüssels 0x1A571DF5 verwendet

Benutzerkennung

Zu einem Primärschlüssel gehört mindestens eine Benutzerkennung. Diese besteht typischerweise aus dem Namen, der E-Mail-Adresse und eventuell einem Kommentar (z.B., dass es sich vorbildlicherweise um einen Offline-Hauptschlüssel handelt):

UID
Hauke Laging (Offline-Hauptschlüssel) <hauke@laging.de>
Name optionaler Kommentar E-Mail-Adresse
Hauke Laging (Offline-Hauptschlüssel) <hauke@laging.de>

Man kann nach belieben UIDs hinzufügen und löschen, allerdings muss immer eine erhalten bleiben.

So kann man denselben Schlüssel für mehrere E-Mail-Adressen verwenden: Man trägt einfach alle E-Mail-Adressen als UIDs ein. Das ist bequem und nur dann problematisch, wenn nicht jeder wissen soll, dass alle Adressen zu derselben Person gehören (etwa bei beruflichen und privaten oder solchen, die spamfrei bleiben sollen und deshalb nicht auf Keyservern veröffentlicht werden sollen).

Wenn man alle UIDs löscht (bzw. mit --edit-key und dem Kommando revuid zurückzieht), die ein Kommunikationspartner signiert hat (oder über das web of trust verifizieren kann), dann ist der Schlüssel für ihn mehr oder weniger wertlos. Das sollte man sich deshalb gut überlegen. Vor diesem Hintergrund erscheint es sinnvoll, einem Schlüssel gleich bei der Erzeugung eine UID ohne E-Mail-Adresse zu spendieren, also nur mit dem Namen, denn diese wird man nie zurückziehen, und so bleibt immer eine signierte UID erhalten. Es besteht allerdings ein kleines Risiko, dass andere OpenPGP-Implementierungen mit einer UID, die nicht die übliche Form hat, nicht zurechtkommen. Das kann man zur Not durch Löschung der UID auf dem jeweiligen System lösen, aber mit jedem Update vom Keyserver wäre die UID wieder da.

Streng technisch ist die UID nur ein Textfeld, in das man quasi alles reinschreiben kann (nicht etwa drei getrennte Felder für Name, E-Mail und Kommentar). Um ungewöhnliche UIDs zu erzeugen, wird eventuell die Option --allow-freeform-uid benötigt.

start cmd:> gpg --list-sigs 0x71FDC5CB
pub   1024D/71FDC5CB 2010-02-25 [verfällt: 2011-02-25]
uid                  Test Key (Demo) <test@key.inv>
sig 3        71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>
sig 3        ECCB5814 2010-02-25  Hauke Laging <hauke@laging.de>
uid                  Neue UID (nach der Signierung hinzugefügt) <test2@key.inv>
sig 3        71FDC5CB 2010-02-25  Test Key (Demo) <test@key.inv>

Zu der ersten UID Test Key (Demo) <test@key.inv> ist nun die UID Neue UID (nach der Signierung hinzugefügt) <test2@key.inv> hinzugekommen. Da dies nach der Signierung durch den anderen Schlüssel 0xECCB5814 erfolgte, hat nur die alte UID eine Signatur von 0xECCB5814.

Die hier angezeigten Informationen finden sich (fast alle) auch in der Schlüsselübersicht der grafischen Programme. Diese Zusammenhänge muss man verstehen:

  1. Ein Schlüssel wird über seinen öffentlichen Primärschlüssel identifiziert (bzw. über (den letzten Teil von) dessen Fingerabdruck).

  2. Zu einem Primärschlüssel gehören eine oder mehrere UIDs (Name, E-Mail, eventuell Kommentar).

  3. Alle UIDs und alle Unterschlüssel sind von dem Primärschlüssel unterschrieben. Eine UID oder ein Unterschlüssel ohne Signatur (so was kann man regulär gar nicht erzeugen) ist wertlos bzw. sogar ein Hinweis auf Manipulation.

  4. Signaturen von anderen Schlüsseln betreffen (fast) immer nur UIDs (genauer: die Kombination aus Primärschlüssel und UID).

  5. Jeder Primär- und jeder Unterschlüssel besteht aus einem öffentlichen und einem privaten Schlüssel. Mit dieser Unterscheidung hat man aber nur selten zu tun, etwa dann, wenn man seine privaten Schlüssel sichern oder auf einem anderen Rechner verfügbar machen will und sie deshalb exportieren muss. gpg verwendet immer automatisch den richtigen der beiden Schlüssel.

Passphrase

Bei der Erzeugung eines Schlüssels wird man nach einer Passphrase gefragt. Diese Bezeichnung anstelle von Passwort soll zum Ausdruck bringen, dass die Eingabe auch Leerzeichen enthalten darf, also aus mehreren Wörtern, etwa einem Satz, bestehen kann. Der Sinn einer Passphrase ist zu verhindern, dass jemand, der die Datei, die den geheimen Schlüssel enthält, in seinen Besitz bringt, den Schlüssel sofort verwenden kann. Die Sicherheit einer Passphrase kann üblicherweise nicht mal im Ansatz mit der Sicherheit von OpenPGP-Schlüsseln mithalten. Eine normale Passphrase ist schnell geknackt. Man sollte also (jedenfalls bei "wertvollen" Schlüsseln und auch bei anderen, wenn sie auf z.B. USB-Sticks transportiert oder archiviert werden, die nicht in geeigneter Weise vor physischem Zugriff geschützt sind) eine lange Zufallsfolge wählen (was man sich eben gerade noch so merken kann; besser: (einen Teil) aufschreiben). Für selten genutzte Schlüssel kann man auch eine lange Passphrase wählen, die man sich aufschreiben muss. Eine gute Kombination ist eine Passphrase, die man häufig verwendet und dementsprechend nicht vergisst, und eine, die man sich aufschreiben muss.

Eine Passphrase ist anders als eine normale Passworteingabe keine "Lasse ich das den User jetzt machen?"-Entscheidung des Computers, sondern ohne sie kann auch der Computer den Schlüssel nicht verwenden, weil der geheime Teil mit der Passphrase verschlüsselt wird, bevor er gespeichert wird. Das heißt auch: Ist die (gute) Passphrase weg, ist der Schlüssel weg. Es heißt außerdem: Wird ein geheimer Schlüssel exportiert, dann wird man nicht nach seiner Passphrase gefragt. In der exportierten Datei ist der Schlüssel genauso verschlüsselt wie im Keyring. Möchte man den geheimen Schlüssel für ein Backup besonders sichern, dann ist eine Möglichkeit, vor dem Export die Passphrase zu ändern (zu einer besseren).

Wenn man nacheinander einen anderen Schlüssel oder eigene Schlüsselkomponenten zertifiziert / signiert, Daten entschlüsselt und Daten signiert, dann kann es (bei guter Schlüsselstruktur) passieren, dass man dreimal nach einer Passphrase gefragt wird, obwohl es immer dieselbe ist und GnuPG auch nur eine einheitliche Passphrase für alle Schlüssel eines Zertifikats setzen kann. Der Grund ist, dass es sich technisch um unterschiedliche Schlüssel handelt, die im Prinzip auch jeweils eine individuelle Passphrase haben könnten. Dass die Schlüssel zusammengehören, interessiert die Passphrase-Verwaltung nicht – eine durchaus verbesserungswürdige Situation. Unterschiedliche Passphrasen zu verwenden, ist bei GnuPG aber mit einiger Fummelei (gpgsplit) verbunden, die man wohl nur Experten zumuten möchte. Ausnahme: Die Verwendung einer eigenen Passphrase für den Hauptschlüssel und einer gemeinsamen für alle Unterschlüssel ist relativ leicht zu bewerkstelligen (--export-secret-subkeys). Die Passphrasen der unterscheiden Zertifikate hängen nicht zusammen, allerdings erscheint es im allgemeinen wenig sinnvoll, nicht dieselbe Passphrase für alle Schlüssel eines Keyrings zu verwenden.

Wie lang muss eine Passphrase sein?

Auch hier gilt das Prinzip des schwächsten Glieds einer Kette. Es hat wenig Sinn, einen superlangen Schlüssel zu erzeugen, wenn die Passphrase leicht zu raten ist – es sei denn, man kann in ausreichendem Maß sicherstellen, dass kein Unberechtigter Zugriff auf die Schlüsseldatei bekommt (etwa wenn die nur auf einem physisch gesicherten USB-Stick gespeichert ist, der nie an unsichere Systeme angeschlossen wird). Die beiden Extreme sind also: keine Passphrase und schlüsseläquivalente Sicherung. Wenn man die Schlüsseldatei auf eine Webseite stellt, dann sollte die Passphrase nicht schwächer sein als die Schlüssellänge. Ein 2048-Bit-RSA-Schlüssel entspricht einem symmetrischen 112-Bit-Schlüssel (und nichts anderes ist eine Passphrase). Das sind etwa 19 Zeichen (Groß- und Kleinbuchstaben ohne Umlaute plus Ziffern), also so etwas: EAVgDCgGynRluorw08v. Allerdings kann man den Wert von --s2k-count (s.u.) aus den 112 Bit noch herausrechnen. Der Standardwert entspricht 16 Bit, so dass man auf 16 Ziffern kommt.

Für Schlüssel, die man nur auf sicheren Systemen (Knoppix o.Ä.) verwendet, sollte man nicht dieselbe Passphrase verwenden wir für einen Schlüssel, den man auf einem normalen Rechner verwendet. Allgemeiner: Man sollte für einen Offline-Schlüssel nichts als Passphrase verwenden, das man auch auf einem normalen Rechner eingibt.

Alle Teile eines von GnuPG eingelesenen Schlüssels haben dieselbe Passphrase (das ist nicht technisch zwingend, aber eine GnuPG-Limitation). Wenn man dennoch etwa für den Hauptschlüssel eine andere Passphrase nehmen will als für die Unterschlüssel, muss man den Schlüssel in zwei Schlüsselbunden speichern und in einem davon den Hauptschlüssel löschen. Je nachdem, mit welchem Schlüsselbund man GnuPG aufruft, wird die eine oder andere Passphrase benötigt.

Gegen das Knacken der Passphrase kann man sich mit einer hohen Anzahl Iterationen beim passphrase mangling schützen. Diese wird über die Option --s2k-count festgelegt. Der zulässige Wertebereich ist 1024 bis 65011712, der Standardwert ist 65536. --s2k-count 655360 verzehnfacht also den Rechenaufwand zum Knacken einer Passphrase gegenüber der Standardeinstellung. Auf langsamen Systemen mag man mit sehr großen Werten allerdings merkliche Verzögerungen auslösen. Diese Option greift auch dann, wenn man nicht asymmetrisch (also für einen öffentlichen Schlüssel), sondern symmetrisch verschlüsselt, also für Ver- und Entschlüsselung dasselbe Passwort angeben muss.

Man setzt den Wert, indem man ihn konfiguriert (in der Konfigurationsdatei oder per Kommandozeile) und dann die Passphrase "ändert" (mit --edit-key → passwd; kann auch gleich bleiben, muss nur noch mal eingegeben werden). Der Wert wird dann in den Schlüssel geschrieben. Der Schlüssel kann also immer verwendet werden, unabhängig davon, welcher Wert gerade für die gpg-Installation konfiguriert ist, die auf dem Schlüssel zugreift. Es kann aber sein, dass man durch eine Änderung der Passphrase unbeabsichtigt (und unbemerkt) diesen Wert verändert.

Eine starke Passphrase schützt Schlüssel im laufenden Betrieb nur bedingt, weil von den meisten Systemen die Passphrase gecacht wird. Wer es schafft, über Schadsoftware Zugriff auf den Rechner zu bekommen, kann trivial den Schlüssel benutzen (auf dem Rechner) oder sogar die Passphrase bzw. den Klartext-Schlüssel auslesen.

Keyring und Schlüsselinformationen anzeigen

wichtige Kommandos --list-keys --list-secret-keys --fingerprint
wichtige Optionen --list-options
Links zum Thema
spezielle Kommandos --list-sigs --check-sigs --card-status
spezielle Optionen --with-colons --keyring --secret-keyring --primary-keyring --no-default-keyring
spezielle Links zum Thema

Man kann sich auf unterschiedliche Weise anzeigen lassen,

Standardmäßig werden angezeigt:

start cmd:> gpg --list-keys 0x1a571df5
pub   4096R/1A571DF5 2012-11-04 [verfällt: 2013-11-04]
uid                  Hauke Laging (Standardschlüssel: siehe policy URL und signature notations)
uid                  Hauke Laging (Standardadresse) <hauke@laging.de>
sub   2048R/3F96AD8E 2012-11-04 [verfällt: 2013-11-04]
sub   2048R/81F06169 2012-11-04 [verfällt: 2013-11-04]
sub   2048R/34288BDC 2012-11-04 [verfällt: 2013-11-04]

Die öffentlichen Schlüssel werden mit --list-keys / --list-public-keys angezeigt, die privaten mit --list-secret-keys. Ohne Argument zeigen diese Kommandos alle aktuell verfügbaren Schlüssel an. Das sind in der Standardeinstellung diejenigen in der Datei pubring.gpg (bzw. secring.gpg).

Die Auswahl der Schlüsselbund-Dateien kann mit den Optionen --keyring, --secret-keyring, --primary-keyring und --no-default-keyring beeinflusst werden. Sind die Standarddateien (bzw. die (ersten) konfigurierten) bei einem Aufruf von gpg nicht vorhanden, werden sie erzeugt.

Schlüsselauswahl

Oftmals will man keine Übersicht aller Schlüssel, sondern will Informationen über einen speziellen. Es gibt mehrere Möglichkeiten, einen Schlüssel auszuwählen. Die einzige eindeutige Methode dafür ist der Fingerprint:

start cmd:> gpg --list-keys 0xD44C6A5B71B0427CCED3025CBD7D6D27ECCB5814
pub   1024D/0xECCB5814 2005-09-05
uid         [ uneing.] Hauke Laging <hauke@laging.de>
sub   2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]

Diese Methode ist offensichtlich im allgemeinen nicht praktikabel und mit Kanonen auf Spatzen geschossen. Sinnvoll ist die Verwendung des Fingerprints als Auswahlkriterium in Scripten. Als Abkürzung des Fingerprints gibt es die short ID (die letzten vier Byte des Fingerprints) und die long ID (acht Byte), also in diesem Fall ECCB5814 bzw. BD7D6D27ECCB5814. In vielen Fällen kann man das direkt so verwenden, in Groß- oder Kleinschreibung. Formal werden IDs aber mit dem Präfix "0x" gekennzeichnet. Da dies in allen Fällen funktioniert, sollte man es sich so angewöhnen: 0xECCB5814 bzw. 0xBD7D6D27ECCB5814 oder 0xeccb5814 bzw. 0xbd7d6d27eccb5814.

Die andere Möglichkeit ist über den Inhalt der UID, die typischerweise so aufgebaut ist:

Vorname Name (Kommentar) <E-Mail-Adresse>

Folgende Varianten sind möglich:

Mehrere Angaben werden als ODER-Verknüpfung verarbeitet (d.h. die Einzelergebnisse werden addiert). Man kann sogar z.B. eine exakte Suche mit einer Substringsuche verbinden. Die typische Vorgehensweise ist, erst mit einer UID-Suche den passenden Schlüssel zu finden und dann mit dessen ID weiterzumachen:

Schritt 1:

start cmd:> gpg --list-keys hauke

pub   1024D/0xECCB5814 2005-09-05
uid         [ uneing.] Hauke Laging <hauke@laging.de>
uid         [ uneing.] Hauke Laging <mail@hauke-laging.de>
sub   2048g/0xE623EF88 2005-09-05 [verfallen: 2010-04-03]
sub   2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]
sub   2048R/0x3A403251 2010-03-04 [verfällt: 2013-03-03]
sub   2048R/0x2282921E 2010-03-08 [verfällt: 2013-03-07]

pub   1024R/0x2D6AAED6 2010-11-13
uid         [ uneing.] lokaler Signaturschlüssel (unsicher; nur für internen Gebrauch) <lsign@hauke-laging.de>
sub   1024R/0x6E259E87 2010-12-11 [verfallen: 2011-12-11]

pub   4096R/0x1A571DF5 2012-11-04 [verfällt: 2013-11-04]
uid         [ uneing.] Hauke Laging (Standardschlüssel: siehe policy URL und signature notations)
uid         [ uneing.] Hauke Laging (Standardadresse) <hauke@laging.de>
sub   2048R/0x3F96AD8E 2012-11-04 [verfällt: 2013-11-04]
sub   2048R/0x81F06169 2012-11-04 [verfällt: 2013-11-04]
sub   2048R/0x34288BDC 2012-11-04 [verfällt: 2013-11-04]

Schritt 2:

start cmd:> gpg --armor --local-user 0x1A571DF5 --detach-sign datei.txt

Anzeige der Signaturen

OpenPGP-Schlüssel bestehen aus einzelnen Blöcken: genau einem Hauptschlüssel, mindestens einer User-ID und beliebig vielen (also auch null möglich) Unterschlüsseln. UID-Blöcke und Unterschlüssel werden erst dadurch gültig, dass sie eine korrekte und gültige (d.h. nicht abgelaufene) Signatur des Hauptschlüssels tragen. Es ist durchaus möglich, dass für dasselbe Objekt mehrere Signaturen vorhanden sind; verwendet wird dann die neuste. Signaturen können Zusatzinformationen enthalten.

Schlüssel werden durch Dritte beglaubigt,

list options

Welche Informationen GnuPG über einen Schlüssel ausgibt, ist konfigurierbar. Dies geschieht mit der Option --list-options, sinnigerweise in der Konfigurationsdatei. Ich empfehle, sich standardmäßig vieles anzeigen zu lassen, weil man ansonsten wichtige Informationen verpassen kann:

list-options show-policy-urls,show-notations,show-uid-validity,show-sig-expire,show-keyserver-urls

relevante Parameter für --list-options
show-policy-urls Zeigt (für jede UID) den Wert einer policy URL (--cert-policy-url, --set-policy-url) an. Dort sollte man nachlesen können, was man von dem Schlüssel (seiner Sicherheit, seinen Signaturen, seinen Beglaubigungen) zu halten hat.
show-notations Zeigt (für jede UID) eventuell vorhandene signature notations (--cert-notation, --set-notation) an. Die sind bisher leider nicht standardisiert, können aber wichtige Informationen über den Schlüssel (etwa eine Kurzform der Schlüsselrichtlinie (policy URL)) oder eine Beglaubigung des Schlüssels enthalten.
show-uid-validity Zeigt für jede User-ID die Gültigkeit an (basierend auf den Signaturen, die sie vom eigenen und von anderen Schlüsseln hat).
show-sig-expire Zeigt an, ob eine Signatur (Zertifizierung) ein Ablaufdatum hat.
show-keyserver-urls Zeigt, falls vorhanden, die URL des preferred keyserver an.
wenig relevante Parameter für --list-options
show-photos Zeigt Fotos an, die man an einen Schlüssel (bzw. an UIDs) hängen kann. Damit habe ich keine Erfahrung; ich vermute, auf der Kommandozeile führt das zu nichts.
show-unusable-uids Zeigt auch die unbrauchbaren (abgelaufenen oder widerrufenen) User-IDs an.
show-unusable-subkeys Zeigt auch die unbrauchbaren (abgelaufenen oder widerrufenen) Unterschlüssel an.
show-keyring Zeigt den Keyring (die Datei) an, in dem der Schlüssel gefunden wurde. Das ist nur sinnvoll, wenn man mit mehreren oder unterschiedlichen Keyrings arbeitet (siehe den Block spezielle Optionen am Anfang dieses Abschnitts).
show-sig-subpackets Für diejenigen, die Schmerzen mögen: Zusammen mit --with-colons (und nur dann) bricht eine Flut an für Normalsterbliche nicht verständlichen Detailinformationen über den geneigten Betrachter herein...
Zusammenwirken von list options auf der Kommandozeile mit denen in der Konfigurationsdatei

Normalerweise überschreibt ein Wert auf der Kommandozeile den in der Konfigurationsdatei. --list-options hat allerdings eher eine Liste von Werten als die Gesamtliste als Einzelwert, deshalb wird nicht die eine durch die andere ersetzt, sondern die auf der Kommandozeile freigeschalteten Parameter ergänzen die bereits in der Konfigurationsdatei freigeschalteten. Will man einen Parameter aus der Konfigurationsdatei deaktivieren, ohne gleich per --no-options die ganze Konfigurationsdatei abzuschießen, muss man diesen Parameter explizit deaktivieren, was mit dem Präfix no möglich ist. Steht also in der Konfigurationsdatei beispielsweise

list-options show-policy-urls,show-uid-validity,show-sig-expire

dann nutzt der Aufruf

gpg --list-options show-uid-validity,no-show-sig-expire,show-keyserver-urls

effektiv die Kombination

gpg --list-options show-policy-urls,show-uid-validity,show-keyserver-urls

Schlüssel beglaubigen – Gültigkeit festlegen

wichtige Kommandos --edit-key (sign) --edit-key (lsign)
wichtige Optionen --ask-cert-level --set-policy-url --sig-policy-url --cert-policy-url
Links zum Thema
spezielle Kommandos --edit-key (tsign) --edit-key (nrsign)
spezielle Optionen --set-notation --sig-notation --cert-notation --ask-cert-expire --default-cert-expire
spezielle Links zum Thema

Es ist sehr wichtig zu verstehen, warum Schlüssel signiert werden (also was eine Signatur bedeutet und was nicht). Technik löst zumeist nicht von allein alle Probleme des Anwenders. Sie bietet ihm lediglich die Möglichkeit dazu. Um sein Problem zu lösen (und nicht noch zu vergrößern) muss der Anwender die Technik aber noch richtig einsetzen!

Die Motivation dafür, Verschlüsselung oder Signaturen zu benutzen, ist typischerweise die, dass nur der beabsichtigte Empfänger die Nachricht lesen kann bzw. man wirklich sicher sein kann, dass Daten vom angenommenen Absender sind. Das erreicht man, indem man die Nachricht mit seinem Schlüssel verschlüsselt. Das muss aber auch wirklich der korrekte Schlüssel sein, den sonst wäre ein Dritter in der Lage, die Nachticht zu lesen. Wenn man einen Schlüssel aus einer unsicheren Quelle hat (von einem Schlüsselserver, von einer Webseite, aus einer E-Mail), dann kann der manipuliert sein. Man will etwas an Person A schicken, und Person B ist in der Lage, die Daten zu manipulieren, die man bekommt (durch Manipulation der Verbindung oder der Daten am Ziel). Dann kann B den Schlüssel von A gegen den eigenen austauschen. Man verschlüsselt also unwissentlich an B, der fängt die Nachricht ab, packt sie aus, packt sie für A mit dessen richtigem Schlüssel ein, und weder man selber noch der Empfänger hat eine Chance, die Manipulation zu erkennen. Das nennt man einen Man-in-the-middle-Angriff.

Deshalb ist es ungemein wichtig, dass man die Zuordnung von Schlüsseln zu einer Person oder Organisation gegen Fehler absichert. Das geschieht,

  1. entweder durch eigene Aktivität in zwei Schritten, nämlich

    1. einerseits organisatorisch

      1. indem man sich den Schlüssel aus einer sicheren Quelle beschafft (unüblich)

      2. indem man sich den Schlüssel aus einer unsicheren, aber seinen Fingerabdruck aus einer sicheren Quelle (persönlich, telefonisch, Zeitschrift u.Ä.) beschafft und dann den korrekten Fingerabdruck mit dem des importierten Schlüssels vergleicht (Normalfall)

    2. andererseits technisch (Markierung des Schlüssels als gültig)

      1. indem man den Schlüssel signiert (allgemein oder lokal (s.u.); der signierende Schlüssel muss dem System aber dauerhaft als vertrauenswürdig bekannt sein; wird er später gelöscht oder verliert seinen Status, wird die Signatur mehr oder weniger wertlos) oder

      2. indem man den Zertifizierungsvertrauenswert (ownertrust) des Schlüssels (also eigentlich den in die Zertifizierverlässlichkeit seines Besitzers) auf Maximum (absolut / ultimate) setzt (per --edit-key trust oder --trusted-key)

      3. indem man den Schlüssel einfach nur importiert und --trust-model auf always setzt (das möchte man im allgemeinen nicht)

      Selbst erzeugte Schlüssel (nicht aber importierte private Schlüssel!) gelten automatisch als vertrauenswürdig (Das ist ein indirekter Effekt: Sie werden als maximal vertrauenswürdig in die trustdb eingetragen. Wird die trustdb (oder der komplette Schlüssel) gelöscht, verliert der Schlüssel seine Vertrauenswürdigkeit.). Wenn man also aus Sicherheitsgründen den privaten Hauptschlüssel nicht im System (das gilt nicht für Smartcards) speichert, muss man den Schlüssel auf einem der genannten Wege autorisieren.

  2. oder "automatisch", indirekt, durch das Web of Trust (WoT)

    1. indem man zunächst andere Schlüssel aktiv verifiziert (mindestens einen)

    2. den einzelnen Schlüsseln eine Vertrauensstufe (ownertrust) zuweist

    3. ggf. die Standardwerte für die Berechnung des Vertrauensstatus ändert und die Vertrauensdatenbank aktualisiert

Wann ein Schlüssel als gültig betrachtet wird

GnuPG behandelt Schlüssel als gültig, wenn eine der folgenden Bedingungen zutrifft:

  1. Sein ownertrust wurde explizit (--edit-key trust; --trusted-key) oder implizit (bei der Schlüsselerzeugung) auf absolut (ultimate) gesetzt. Das sind typischerweise die eigenen Schlüssel (privater Schlüssel verfügbar).

  2. Eine seiner User-IDs hat eine gültige (nicht abgelaufene, nicht widerrufene) Beglaubigung von einem Schlüssel mit ownertrust absolut (ultimate). Das sind typischerweise diejenigen Schlüssel, die man selber beglaubigt hat.

  3. --trust-model ist auf classic oder pgp gesetzt und der Schlüssel hat entsprechend der aktuellen Konfiguration genügend Beglaubigungen von gültigen Schlüsseln der ownertrust-Werte marginal und complete (oder, seltener Fall, eine trust signature)

  4. --trust-model ist auf always gesetzt.

Wenn ein Schlüssel komplett gelöscht wird (--delete-secret-and-public-key), wird auch sein ownertrust gelöscht. Wenn man anschließend den privaten Schlüssel importiert, wird der ownertrust nicht automatisch wieder auf absolut (ultimate) gesetzt; das passiert nur bei der Erzeugung des Schlüssels. Werden Schlüssel also in einem sicheren System erzeugt und dann (als Offline-Hauptschlüssel) in einem anderen System importiert, muss (ggf.) ihr ownertrust dort manuell auf absolut (ultimate) gesetzt werden.

Die Gültigkeit eines Schlüssels kann man sich auf mehrere Arten anzeigen lassen:

start cmd:> gpg --list-options show-uid-validity --list-keys 0x1a571df5
pub   4096R/0x1A571DF5 2012-11-04 [verfällt: 2013-11-04]
uid         [ uneing.] Hauke Laging (Standardschlüssel: siehe policy URL und signature notations)
uid         [ uneing.] Hauke Laging (Standardadresse) <hauke@laging.de>

start cmd:> gpg --with-colons --list-keys 0x1a571df5
pub:u:4096:1:BF4B8EEF1A571DF5:1351995465:1383531465::u:::escESCA:
uid:u::::1352004488::EEDB6E9B3F9B8686B76CAE89A7F2684D0E9192E4::Hauke Laging (Standardschlüssel\x3a siehe policy URL und signature notations):
uid:u::::1352004513::D0F326ACF54A1527BC714BD5858AD81C7AAE70CD::Hauke Laging (Standardadresse) <hauke@laging.de>:

Im ersten Fall wird für jede User-ID die Gültigkeit angezeigt. Die Gültigkeit des Schlüssels ist die höchste der UIDs. Im zweiten Fall wird für den Hauptschlüssel (pub) der resultierende Wert explizit angezeigt: Das u im zweiten Feld steht für ultimate.

Was man sich auf normalem Weg leider nicht anzeigen lassen kann, ist, was den Gültigkeitsstatus eines Schlüssels auslöst. Man kann sich zwar mit --list-sigs anzeigen lassen, welche Signaturen die User-IDs haben, aber welche davon relevant sind, sieht man nicht. Klar ist nur, dass unbekannte Schlüssel (angezeigt als unbekannte UIDs) nicht zur Gültigkeit beitragen (schon aus dem technischen Grund, dass die Signaturen nicht geprüft werden können, wenn der Schlüssel nicht im Keyring ist) und dass der Gültigkeitlevel absolut / ultimate nicht durch Signaturen erreicht werden kann, sondern nur durch direkte Zuweisung in der Vertrauensdatenbank.

direkte Überprüfung – eigene Beglaubigung

Die gängigsten Möglichkeiten der Überprüfung sind, dass man den Fingerabdruck schriftlich (nichtelektronisch, am besten persönlich) oder telefonisch erhält. Man vergleicht ihn mit dem Fingerabdruck des Schlüssels, den man importiert hat. Wenn der Fingerabdruck stimmt, stimmt auch der Schlüssel (der Algorithmus des Fingerabdrucks ist so konstruiert, dass man sich darauf verlassen kann). Dass man diese Überprüfung vorgenommen hat, dokumentiert man (entweder nur für sich oder für die Allgemeinheit) dadurch, dass man den Schlüssel signiert (nicht insgesamt, sondern eine oder mehr UIDs).

Das bedeutet aber noch nicht, dass auch alle UIDs korrekt sind (v.a. die E-Mail-Adresse). Wer es besonders gut machen will, prüft deshalb auch, ob die E-Mail-Adresse der UID stimmt. Und das für jede UID (mit anderer E-Mail-Adresse) einzeln. Das kann man leicht händisch machen, indem man eine verschlüsselte Nachricht an die jeweilige Adresse schickt, mit jeweils unterschiedlichem Inhalt. Man signiert dann alle UIDs, von deren E-Mail-Adresse man eine Antwort erhalten hat, die das entschlüsselte Zitat enthält.

Das Programm caff (CA – fire and forget) hat eine elegante Lösung dafür: Es erzeugt für jede UID eine einzelne Signaturdatei, verschlüsselt diese für den signierten Schlüssel und mailt die an die jeweilige Adresse. Wenn der Schlüsselbesitzer auch Zugriff auf die E-Mail-Adresse hat, kann er die Signaturdatei entschlüsseln und importieren.

Signaturen bestätigen nur die Zuordnung eines Schlüssels zu einer Person (oder Organisation). Sie sagen nichts über die Person (z.B. ihre Vertrauenswürdigkeit) aus! Es gibt deshalb keinen Grund, Schlüssel nur deshalb nicht zu signieren, weil man den Besitzer nicht mag.

Anzeige des Fingerabdrucks

Relevant ist üblicherweise nur der Fingerabdruck des Primärschlüssels. Es handelt sich dabei um einen SHA-1-Hash; die 40 Zeichen entsprechen einer Hashlänge von 160 Bit (10^48). Die letzten acht Zeichen ergeben die short ID des Schlüssels, die letzten 16 die long ID.

start cmd:>gpg --fingerprint 0x71FDC5CB
pub   1024D/71FDC5CB 2010-02-25 [verfällt: 2011-02-25]
  Schl.-Fingerabdruck = A92E 91A9 5526 AB4C 7B80  3B11 E47D A993 71FD C5CB

start cmd:> gpg --fingerprint --fingerprint 0x1a571df5 
pub   4096R/0x1A571DF5 2012-11-04 [verfällt: 2013-11-04]
  Schl.-Fingerabdruck = 7D82 FB9F D25A 2CE4 5241  6C37 BF4B 8EEF 1A57 1DF5
uid         [ uneing.] Hauke Laging (Standardschlüssel: siehe policy URL und signature notations)
uid         [ uneing.] Hauke Laging (Standardadresse) <hauke@laging.de>
sub   2048R/0x3F96AD8E 2012-11-04 [verfällt: 2013-11-04]
  Schl.-Fingerabdruck = 03C7 C358 A842 1264 50C1  04BA 486B 17AB 3F96 AD8E
sub   2048R/0x81F06169 2012-11-04 [verfällt: 2013-11-04]
  Schl.-Fingerabdruck = D78C 14BC D8B8 6DE8 AD0A  6AE3 7643 11F2 81F0 6169
sub   2048R/0x34288BDC 2012-11-04 [verfällt: 2013-11-04]
  Schl.-Fingerabdruck = 0290 942E D838 585E 487C  4319 FF27 6278 3428 8BDC

Durch doppelte Angabe von --fingerprint werden auch die Fingerprints der Unterschlüssel angezeigt, die aber normalerweise nicht benötigt werden.

Signatur / Zertifikat für einen Schlüssel erzeugen

Für das Erzeugen einer Signatur benötigt man den eigenen privaten Schlüssel, wird also nach der Passphrase gefragt.

Man muss in dem Menü, das von --edit-key erzeugt wird, das Kommando sign eingeben, oder man übergibt es beim Aufruf gleich mit:

start cmd:> gpg --local-user 0xECCB5814 --ask-cert-level --ask-cert-expire --edit-key 0x71FDC5CB

start cmd:> gpg --local-user 0xECCB5814 --ask-cert-level --ask-cert-expire --edit-key 0x71FDC5CB sign

--local-user 0xECCB5814 gibt an, welcher eigene Schlüssel verwendet werden soll, um die Signatur zu erzeugen (nur relevant, wenn mehrere private Hauptschlüssel vorhanden sind). Man kann in der Konfigurationsdatei allerdings einen Standardschlüssel definieren (--default-key).

Für Spezialfälle gibt es Variationen: lsign, tsign, nrsign. Durch die Optionen --ask-cert-level und --ask-cert-expire wird man nach dem Prüfungsablauf und der Gültigkeitsdauer der Signatur gefragt. Wenn man das nicht benötigt, lässt man sie weg. Manche grafischen Oberflächen für gpg fragen das entweder nicht ab oder tragen die Antwort nicht in die Signatur ein. In dem Fall bleibt einem dann womöglich nur der Weg über die Kommandozeile.

Zusatzangaben zur Signatur

Man kann allerlei ergänzende Angaben machen, wenn man einen Schlüssel signiert. Die häufigste dürfte sein, wie gründlich man den Schlüssel geprüft hat (--ask-cert-level). Möglich sind die Angaben 0 (keine Angabe), 1 (keine Prüfung), 2 (flüchtige Prüfung) und 3 (sehr sorgfältige Prüfung). Das Ergebnis indirekter Prüfungen kann man davon abhängig machen, was die anderen diesbezüglich angegeben haben. Man kann auch die Gültigkeit der Signatur zeitlich begrenzen (--ask-cert-expire) und eine URL hinzufügen (mit --cert-policy-url URL, sinnvollerweise in der Konfigurationsdatei), unter der man Angaben dazu macht, wie man Schlüssel prüft, bevor man sie selber signiert, damit Dritte sich ein besseres Bild davon machen können, welchen Wert die eigenen Signaturen haben.

Risiko einer schlampigen Signatur

Das Risiko schlampigen Signierens liegt darin, dass man von anderen dafür "haftbar" gemacht werden kann, wenn auch meist nicht im rechtlichen Sinn. Das Web of Trust lebt davon, dass man den Angaben anderer vertrauen kann. Wenn sich herausstellt, dass jemand Informationen signiert, die falsch sind, werden andere demjenigen das Vertrauen entziehen. Technisch hat das für denjenigen erst mal keine Folgen, weil er ja nur auf verlässliche Signaturen anderer angewiesen ist, nicht aber darauf, dass seine Signaturen für andere von Wert sind.

Natürlich kann dieser Vertrauensverlust auch außerhalb der OpenPGP-Welt Folgen haben. Um solchen Ärger zu vermeiden, bietet es sich an, andere nicht im Unklaren darüber zu lassen, was die eigenen Signaturen zu bedeuten haben (policy URL).

keine falsche Sicherheit vortäuschen: lokale Signaturen

Es gibt Situationen, in denen man einen Schlüssel zertifizieren will, ohne dass man ihn hinreichend überprüfen konnte. gpg meckert, wenn man nichtzertifizierte Schlüssel für Verschlüsselung verwendet oder deren Signaturen prüft. Das möchte man womöglich vermeiden. Es wäre nun sehr ärgertlich, wenn diese Signatur in die freie Wildbahn käme, weil Dritte nicht wüssten, dass das "keine echte" Signatur ist (auch wenn man --ask-cert-level auf 1 setzen könnte). Außerdem mag es sein, dass (auch bei richtiger Prüfung) Dritte nicht wissen sollen, dass man den Schlüssel signiert hat (und ihn vermutlich benutzt).

In solchen Situationen kann man eine lokale Signatur erzeugen. Solche Signaturen werden nicht exportiert (und auch nicht ohne Verrenkungen importiert). Dies erreicht man mit der Option --lsign-key oder dem Kommando lsign (statt sign) im Menü von --edit-key.

Tipp: Fingerabdruck immer auf Papier dabei haben

Es ist hilfreich, den eigenen Fingerprint immer ausgedruckt auf ein paar kleinen Zetteln dabei zu haben. Papier erlebt in der High-Tech-Welt eine ungeahnte Renaissance... So können Leute, die man getroffen hat, sich später den Schlüssel aus unsicherer Quelle besorgen, aber ihn verifizieren. Wenn man den Fingerprint allerdings auswendig weiß, muss man damit rechnen, von Nicht-Nerds für irgendwie gefährlich gehalten zu werden...

Hauke Laging
hauke@laging.de
D44C 6A5B 71B0 427C CED3
025C BD7D 6D27 ECCB 5814

Signatur aktualisieren

Man kann problemlos Signaturen erneuern. Das bietet sich an, wenn man die Zuordnung des Schlüssels zur Person erst nur oberflächlich und später gründlich geprüft hat oder wenn man eine policy URL ergänzen will. Es ist zudem quasi unvermeidbar, wenn man die Gültigkeit der Signatur beschränkt hat. Wenn meine Erinnerung nicht täuscht, ließ GnuPG erneutes Signieren nicht zu, wenn bereits eine besteht. Mit meiner aktuellen Version (2.0.18) ist das aber problemlos möglich. Früher ließ sich das einfach dadurch lösen, dass man vor der Signierung die alte Signatur löscht (--edit-key, dann delsig) oder zurückzieht (--edit-key, dann revsig). Wenn man die alte Signatur behalten will, kann man vorher den Schlüssel exportieren und hinterher importieren. GnuPG stört sich nicht an mehreren vorhandenen Signaturen; es verwendet immer die neuste.

indirekte Überprüfung – das Web of Trust (WoT)

wichtige Kommandos --edit-key (trust), --update-trustdb --check-trustdb
wichtige Optionen --trusted-key
Links zum Thema

Für das Verständnis des Web of Trust muss man zwei Dinge streng auseinanderhalten:

  1. die Gültigkeit (validity) eines Schlüssels (woraus auch immer die sich ergibt)

  2. das Vertrauen in die Verlässlichkeit der von einem Schlüssel ausgestellten Zertifikate, das aus zwei Komponenten besteht:

    1. das Zertifizierungsverhalten des Schlüsselbesitzers (ownertrust): Wie konsequent und gründlich prüft der Schlüsselbesitzer die Daten, die er zertifiziert (Name (mit Schreibweise, gerade bei fremdsprachlichen Namen), E-Mail-Adressen, Kommentar)?

    2. die Sicherheit des signierenden Schlüssels. Es hilft wenig, wenn jemand diszipliniert Identitäten prüft, sich dann aber unbemerkt seinen Hauptschlüssel klauen lässt. Es ist generell nicht wünschenswert, dass Zertifikate mit unsicheren Schlüsseln erzeugt werden, aber gerade bei Zertifikaten von unsicheren Schlüsseln ist nicht gesichert, dass sie vom Besitzer erzeugt wurden.

      Deshalb ist die Bezeichnung ownertrust irreführend, denn es geht nicht nur um den Besitzer, sondern um die Kombination Besitzer–Schlüssel. Schlüssel desselben Besitzers können durchaus unterschiedliche ownertrust-Werte haben.

Diese beiden Eigenschaften hängen nicht zusammen:

  1. Es ist normal, dass man sich von der Gültigkeit eines Schlüssels überzeugt hat, aber dem Zertifizierungsverhalten seines Besitzers nicht traut (und sei es, weil man ihn kaum kennt).

  2. Man kann volles Vertrauen in das Zertifizierungsverhalten von jemandem haben, aber unsicher sein, ob ein bestimmter Schlüssel seiner ist. Einem Schlüssel quasi vorab (also bevor er als gültig akzeptiert wird) einen (hohen) ownertrust zu geben, ist zumindest möglich.

Indirekte Überprüfung funktioniert so: Man nimmt einen Schlüssel als gültig an, wenn er genügend Signaturen von Leuten hat, denen man ausreichend vertraut. Was "genügend" ist, kann man für die beiden Vertrauensstufen (marginally trusted und completely trusted) einzeln festlegen; die Standardwerte sind drei und eins.

Beispiel: Man will den Schlüssel von A überprüfen; den von B hat man erfolgreich überprüft. Wenn B den Schlüssel von A signiert hat und man dieser Signatur vertraut (also darauf vertraut, dass einerseits B den Schlüssel ordentlich überprüft hat und andererseits diese Signatur sicher ist), kann der Schlüssel als überprüft gelten.

WoT-Skizze: Tiefe 2

Alle drei beteiligten Schlüssel sind vollständig gültig (gekennzeichnet durch den grünen Rahmen), haben aber einen unterschiedlichen Vertrauensstatus (ownertrust; gekennzeichnet durch die Hintergrundfarbe). Schlüssel A wird überhaupt nicht für Zertifizierungen vertraut, dennoch ist er gültig.

Wenn man der Überprüfung durch B nur begrenzt vertraut, mag man zufrieden sein, wenn nicht nur B, sondern auch C und D den Schlüssel signiert haben. Das ist keine technische Entscheidung, sondern ein organisatorisches bzw. soziales Problem. Je mehr Signaturen ein Schlüssel hat, desto besser. Bei mehr Signaturen ist die Wahrscheinlichkeit größer, dass ein Benutzer des Schlüssels wenigstens einer davon vertraut, ebenso die, dass er mehrere bekannte Signaturen findet und dem Schlüssel dadurch stärker vertrauen kann.

Die indirekte Überprüfung dient aber nur der Konfiguration der eigenen OpenPGP-Anwendung (damit sie weiß, was sie als Vertrauenswürdig ansehen soll und was nicht). Einen nur indirekt überprüften Schlüssel sollte man nicht signieren, jedenfalls nicht für die Öffentlichkeit (sondern allenfalls lokal).

WoT

Normalerweise hat man einige Schlüssel selber zertifiziert (direkt verifiziert) und kann deshalb (eventuell) weitere Schlüssel indirekt verifizieren. Alle Schlüssel, zu denen man über Zertifizierungen eine Verbindung konstruieren kann, kann man sich als in konzentrischen Kreisen um den eigenen Schlüssel angeordnet vorstellen. Jeder weitere Kreis steht für einen weiteren Schlüssel zwischen dem eigenen und dem Zielschlüssel.

WoT

Um den eigenen Schlüssel herum gibt es einen (normalerweise) zusammenhängenden Bereich von Schlüsseln, die als gültig angesehen werden (grün), und einen (normalerweise ebenfalls zusammenhängenden) Bereich von Schlüsseln, denen ein Vertrauenswert (ownertrust) zugewiesen wurde (gelb). Diese Bereiche sind weitgehend überlappend. Der Gültigkeitsbereich kann aber nur maximal eine Stufe über den Vertrauensbereich hinausgehen, der Vertrauensbereich theoretisch beliebig über den Gültigkeitsbereich (was aber keine Auswirkungen hat). Es gibt meist auch einen Bereich (hellgrün) von erst teilweise verifizierten Schlüsseln (die mindestens eine relevante Signatur haben, die aber in der jeweiligen Konfiguration nicht ausreicht).

WoT-Verifikation über mehrere Ebenen

Es folgen Beispiele für die unterschiedlichen Möglichkeiten einer Schlüsselverifikation über drei Ebenen. Die eigenen Schlüssel (für die der private Schlüssel vorhanden ist) haben immer den ownertrust-Wert ultimate.

WoT

Bei normaler Konfiguration benötigt man von Schlüsseln mit ownertrust complete nur ein einziges Zertifikat, um einen weiteren Schlüssel gültig zu machen.

WoT

Die Schlüssel der zweiten Ebene (mit ownertrust marginal) werden wir im vorigen Beispiel schon durch ein einziges Zertifikat gültig. Der neue Schlüssel (Ebene drei) ist nur deshalb gültig, weil er drei Zertifikate trägt, da diese von Schlüsseln mit geringerem Zertifizierungsvertrauen sind. Man erkennt hieran auch, dass es nur auf die Anzahl der Zertifikate ankommt, nicht auf die Anzahl der unterschiedlichen Wege dorthin.

WoT

In diesem Beispiel ist es umgekehrt: Den Schlüsseln der ersten Ebene wird weniger Zertifizierungsvertrauen entgegengebracht, weswegen für den Schlüssel der zweiten Ebene drei Zertifikate benötigt werden.

WoT

Wenn die Schlüssel der ersten Ebene nicht alle denselben Schlüssel in der zweiten Ebene zertifizieren, werden die Schlüssel der zweiten Ebene nicht vollständig gültig, sondern nur marginal gültig. Das bedeutet, dass ihre Zertifikate nicht gewertet werden, so dass der Schlüssel der dritten Ebene komplett ungültig bleibt. Hier kann man auch sehen, dass Schlüssel, die nicht vollständig gültig sind, einen positiven ownertrust haben können.

WoT

Wenn die Schlüssel der ersten Ebene jeweils nicht nur einen, sondern alle drei Schlüssel der zweiten Ebene zertifizieren, dann werden (wie in einem vorigen Beispiel) die Schlüssel der zweiten Ebene alle gültig und damit wie gehabt auch der in der dritten.

WoT

Die Zertifikate zur Validierung eines Schlüssels können aus unterschiedlichen Ebenen kommen.

WoT-Konfiguration

Die wichtigsten Kommandos und Optionen für die Konfiguration des WoT sind:

  • --completes-needed

  • --marginals-needed

  • --max-cert-depth

  • --trust-model

  • --update-trustdb

  • --check-trustdb

  • --edit-key 0x12345678 trust

Eine Statistik über die Verteilung der Schlüsselstatus in den einzelnen Ebenen kann man sich von gpg anzeigen lassen (nach Änderungen der trustdb, etwa beim Setzen der ownertrust-Werte, passiert das automatisch):

start cmd:> gpg --marginals-needed 2 --check-trustdb
gpg: 2 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0  gültig:  16  signiert:  25  Vertrauen: 0-, 0q, 0n, 0m, 0f, 16u
gpg: Tiefe: 1  gültig:  25  signiert:   3  Vertrauen: 0-, 0q, 10n, 7m, 8f, 0u
gpg: Tiefe: 2  gültig:   3  signiert:   2  Vertrauen: 0-, 0q, 0n, 0m, 3f, 0u
gpg: Tiefe: 3  gültig:   2  signiert:   1  Vertrauen: 0-, 0q, 0n, 2m, 0f, 0u
gpg: Tiefe: 4  gültig:   1  signiert:   0  Vertrauen: 0-, 0q, 0n, 1m, 0f, 0u

Für jede Ebene wird angegeben, wie viele Schlüssel sie enthält (Ebene 0 sind die eigenen Schlüssel, alle mit ultimativem Vertrauen) und wie diese sich auf die möglichen ownertrust-Zustände verteilen:

  • -: Für diese Schlüssel wurde noch keine Angabe gemacht (das Kommando --update-trustdb würde sie abfragen).

  • q: Auswahl weiß nicht so recht (quasi dasselbe wie die erste Kategorie, aber keine Abfrage)

  • n: Diesen Schlüsseln wird explizit nicht vertraut.

  • m: Diesen Schlüsseln wird marginal vertraut (--marginals-needed)

  • f: Diesen Schlüsseln wird vollständig vertraut (--completes-needed)

  • u: Diesen Schlüsseln wird ultimativ vertraut, d.h., sie werden wie die eigenen Schlüssel behandelt: Auch einzelne Zertifikate eines solchen Schlüssels machen einen Schlüssel immer gültig (unabhängig vom Wert für --completes-needed). Außerdem wird so ein Schlüssel immer als gültig betrachtet (siehe --trusted-key), unabhängig davon, ob sein privater Schlüssel vorhanden ist und unabhängig von seiner Position im WoT (auch wenn er gar keine Signaturen hat).

Zertifizierungspfad – in Anlehnung an das Web of Trust

Man kann die öffentlichen Zertifizierungen auch anders nutzen als vollautomatisiert durch das Web of Trust. Der Aufhänger dieses Hinweises ist, dass ein zukünftiger Teilnehmer meiner OpenPGP-Schulung mich fragte, ob die Distribution Talis ein sicheres Bootmedium sei. Ich kannte diese Distribution nicht, war aber positiv davon überrascht, dass sie sich diesem Problem umfangreich widmet; insofern nicht erstaunlich, als Kryptografie einer der Schwerpunkte dieser auf Debian basierenden Distribution ist.

Der Signaturschlüssel der Entwickler hat eine Zertifizierung eines auch in GnuPG-Kreisen bekannten Debian-Entwicklers (Daniel Kahn Gillmor). Ich habe keine Ahnung, wie diszipliniert er Schlüssel signiert; ich kenne ihn nur von der GnuPG-Mailingliste. Aber ich habe vollen Vertrauen darin, dass ein Debian-Entwickler beim Zertifizieren des Signaturschlüssels einer Distribution nicht schlampt. Auch wenn ich (ohne weitere Informationen) seinem Schlüssel nicht grundsätzlich einen hohen ownertrust zuweisen würde, mag ich sein Zertifikat für den Tails-Schlüssel als ausreichend ansehen, um auf die Gültigkeit des Talis-Schlüssels zu vertrauen.

Import und Export von Schlüsseln

Import

wichtige Kommandos --import --recv-keys --search-keys --refresh-keys
wichtige Optionen
Links zum Thema

Die lokal erzeugten und die importierten Schlüssel speichert GnuPG in seinem Konfigurationsverzeichnis (unter Linux ~/.gnupg) in den beiden Dateien pubring.gpg und secring.gpg. Zusätzliche Schlüssel kann man auf drei Arten verfügbar machen:

  1. Import aus einer Datei (typischerweise *.gpg (im Binärformat) oder *.asc (ASCII-Format, base64)): --import

  2. expliziter (--search-keys, --recv-keys) oder impliziter (auto-key-retrieve) Import von einem Keyserver

  3. Aufruf mit einem anderen / zusätzlichen Keyring (letzteres nur bei öffentlichen Schlüsseln möglich): --keyring --secret-keyring --primary-keyring --no-default-keyring

Das Aktualisieren eines vorhandenen Schlüssels ist nichts anderes als ein Import. Von einem Keyserver können einzelne oder auch alle Schlüssel mit dem Kommando --refresh-keys aktualisiert werden.

Grundsätzlich nutzt jeder den Keyserver, der ihm aus welchem Grund auch immer am meisten zusagt. Es gibt Gruppen von Keyservern, die unter einem gemeinsamen Namen zusammengeschaltet sind, um die Verfügbarkeit zu erhöhen, z.B. eu.pool.sks-keyservers.net.

start cmd:> gpg --import hauke__0xECCB5814.asc 
gpg: Schlüssel 0xECCB5814: "Hauke Laging <hauke@laging.de>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1

start cmd:> gpg --search-keys 0xeccb5814
gpg: suche nach "0xeccb5814" auf hkp-Server eu.pool.sks-keyservers.net
(1)     Hauke Laging <hauke@laging.de>
        Hauke Laging <mail@hauke-laging.de>
          1024 bit DSA key 0xECCB5814, erzeugt: 2005-09-05
Keys 1-1 of 1 for "0xeccb5814".  Eingabe von Nummern, Nächste (N) oder Abbrechen (Q) > 1
gpg: fordere Schlüssel 0xECCB5814 von hkp-Server eu.pool.sks-keyservers.net an
gpg: Schlüssel 0xECCB5814: "Hauke Laging <hauke@laging.de>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1

start cmd:> gpg --recv-keys 0xeccb5814
gpg: fordere Schlüssel 0xECCB5814 von hkp-Server eu.pool.sks-keyservers.net an
gpg: Schlüssel 0xECCB5814: "Hauke Laging <hauke@laging.de>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1

Wenn man mittels --search-keys sucht, kann man auswählen, ob man einen der angezeigten Schlüssel importieren will. Der Aufruf --recv-keys importiert direkt, also ohne Rückfrage. Diese Abfragen funktionieren nur mit der Option --keyserver, die hier nicht auftaucht, weil sie bereits in der Konfigurationsdatei steht.

Ein anderer Keyring kann auf diese Weise verwendet werden:

gpg --no-default-keyring --keyring .gnupg/pubring.gpg --list-keys

Sicherheits-Warnung

Es reicht nicht aus, einen Schlüssel über seine short ID oder long ID zu importieren. Man muss danach auf jeden Fall noch den Fingerprint prüfen. Das gilt zumeist auch beim Import einer Datei.

gefilterter Import

Nicht immer will man alle Komponenten eines Schlüssels haben. Es können sich im Laufe der Zeit Komponenten ansammeln, die man nicht braucht:

  1. Signaturen können veraltet sein (abgelaufen oder durch neuere ersetzt), UIDs können abgelaufen oder zurückgezogen sein.

  2. Signaturen können nutzlos sein, etwa dann, wenn sie von unbekannten Schlüsseln erzeugt wurden.

Außerdem kann es sein, dass man Schlüssel nur aktualisieren möchte, ohne neue Schlüssel zu importieren, was passieren kann, wenn man einfach einen Haufen Schlüsseldateien en bloc importiert.

Die Keyserver löschen keine veralteten Komponenten; die Schlüssel werden immer größer. Und damit auch unübersichtlicher. Man kann deshalb den Schlüsselimport so konfigurieren (mittels --import-options, eignet sich für die Konfigurationsdatei), dass nur die relevanten Komponenten importiert werden:

import-clean Alle nicht nutzbaren (zurückgezogenen oder abgelaufenen) UIDs werden minimiert: alle Signaturen außer der (neusten) Eigenbeglaubigung werden gelöscht. Bei den nutzbaren UIDs werden alle Signaturen entfernt, die für die Vertrauenskalkulation nutzlos sind: ungültige (fehlerhafte); diejenigen, die durch eine spätere Signatur ersetzt wurden; diejenigen, die zurückgezogen wurden; diejenigen, deren Schlüssel nicht im Keyring enthalten sind. äquivalent zu --edit-key → clean
import-minimal Alle verzichtbaren Komponenten werden gelöscht, das sind alle Signaturen aller UIDs mit Ausnahme der jeweils neusten Eigenbeglaubigung. äquivalent zu --edit-key → minimize
merge-only Nur vorhandene Schlüssel aktualisieren, keine neuen importieren. Dieser Parameter wirkt sich nur beim Import per --import (also aus einer Datei) aus, nicht aber beim Zugriff auf Keyserver.
import-local-sigs Für den speziellen Fall, dass Zertifikate mit lokalen Signaturen importiert werden sollen (weil die standardmäßig nicht importiert werden). Das ist allerdings nicht nötig, wenn der geheime Schlüssel, der diese lokalen Signaturen erzeugt hat, sich im Keyring befindet (funktioniert auch mit Offline-Hauptschlüssel): Solche Signaturen werden immer importiert.  

Export

wichtige Kommandos --export --export-secret-keys --send-keys
wichtige Optionen --armor --output
Links zum Thema
spezielle Kommandos --export-secret-subkeys --export-ownertrust
spezielle Optionen --export-options
spezielle Links zum Thema

Der Export von Schlüsseln ist etwas komplizierter, was daran liegt, dass Importieren als Anweisung eindeutig ist, beim Exportieren aber nicht. Es ist zu unterscheiden, ob öffentliche Schlüssel (Zertifikate), private Schlüssel oder nur private Unterschlüssel exportiert werden sollen.

Ohne die Angabe von --output wird der exportierte Schlüssel auf die Standardausgabe geschrieben, von wo man ihn in einer Shell bequem in eine Datei umleiten kann:

gpg --armor --export 0x1a571df5 > 0x1a571df5.asc

gpg --export 0x1a571df5 > 0x1a571df5.gpg

Binärdateien haben üblicherweise die Endung gpg, Dateien in ASCII-Armor asc.

[FIXME]

Transfer von Schlüsseln auf andere Rechner

Wenn nur ein einzelner Schlüssel auf einen anderen Rechner übertragen werden soll, exportiert man ihn in der oben beschriebenen Weise und importiert ihn auf dem anderen Rechner. Wenn dagegen die ganze Installation kopiert oder transferiert werden soll, kopiert man das ganze Verzeichnis, weil die Installation noch mehr Informationen als nur die Schlüssel umfasst. Die Datei random_seed sollte man allerdings nicht mitkopieren bzw. auf dem Zielsystem vor der ersten Verwendung löschen. Beim kompletten Exportieren von Schlüsseln (eigenen wie fremden) ist zu beachten, dass die Exportoptionen so gesetzt werden (--export-options export-local-sigs,export-sensitive-revkeys), dass auch wirklich alles exportiert wird (etwa auch lokale Signaturen und auf "sensitive"Einträge für designated revoker).

eigene Schlüssel

Bei der Übertragung einzelner eigener Schlüssel muss nur darauf geachtet werden, dass es sich möglicherweise um einen Offline-Hauptschlüssel handelt und man ggf. den Hauptschlüssel in geeigneter Weise ebenfalls transferiert. Wird der Schlüssel für SSH-Authentifizierungen verwendet, sind auf dem Zielsystem entsprechende Anpassungen vorzunehmen.

fremde Schlüssel

Werden fremde Schlüssel auf ein anderes System transferiert, ist zu bedenken, auf dem Zielsystem ihren ownertrust zu setzen. Außerdem ist es möglich, dass so ein Schlüssel nicht von eigenen Schlüsseln signiert wurde, sondern nur durch das WoT gültig wird. Die dafür erforderlichen fremden Schlüssel sind auf dem Zielsystem möglicherweise nicht vorhanden oder haben dort einen anderen ownertrust-Wert, so dass der Schlüssel auf dem Quellsystem gültig ist, ohne die entsprechenden Anpassungen aber nicht auf dem Zielsystem.

Schlüssel zurückziehen (revoke)

wichtige Kommandos --gen-revoke --edit-key (revuid) --edit-key (revkey)
wichtige Optionen
Links zum Thema
spezielle Kommandos --edit-key (addrevoker) --desig-revoke
spezielle Optionen
spezielle Links zum Thema

Wenn ein Schlüssel (oder ein Teil davon) kompromittiert wurde oder aus anderen Gründen nicht mehr verwendet werden soll, kann man ihn zurückziehen (revoke). Dies erfolgt über ein Sperrzertifikat, das mit einer Signatur des zurückzuziehenden Schlüssels (oder eines anderen, speziell dazu autorisierten, siehe addrevoker) versehen wird, so dass jeder Nutzer des Schlüssels sicher sein kann, dass nur der Besitzer des jeweiligen Schlüssels die Sperrung veranlasst hat. Dies lässt sich für Haupt- und Unterschlüssel nicht rückgängig machen! Wenn ein Sperrzertifikat für einen Schlüssel erst einmal in Umlauf ist, kann man den betroffenen Schlüssel komplett vergessen; für UIDs kann man mit GnuPG ein revocation certificate durch eine später erzeugte, weitere reguläre Signatur quasi überschreiben. Warum das bei Unterschlüsseln nicht genauso machbar ist, obwohl zwischen ihnen und User-IDs diesbezüglich kein struktureller Unterschied besteht, weiß ich nicht (man kann eine neuere Signatur erzeugen, aber die wird ignoriert). Der RfC (Abschnitt 5.2.1) klärt das meines Erachtens nicht sauber. Man sollte sich nicht darauf verlassen, dass man eine widerrufene UID in allen Implementierungen wieder zum Leben erwecken kann.

präventives Sperrzertifikat

Man kann – und wird von gpg bei der Schlüsselerzeugung auch dazu ermuntert – sich allerdings bereits im voraus ein Sperrzertifikat für den Hauptschlüssel erzeugen, ohne es in Umlauf zu bringen. Das sollte man dann aber sicher verwahren (z.B. als Ausdruck oder stark symmetrisch verschlüsselt). Die Überlegung dahinter ist, dass man durch irgendeine IT-Panne seinen Hauptschlüssel verlieren (oder die Passphrase vergessen) könnte, so dass man auf regulärem Weg kein Sperrzertifikat mehr erzeugen kann.

Wenn man ein Sperrzertifikat ausdruckt, ist es hilfreich, das Auffinden von Tippfehlern zu erleichtern, denn in so einem Block einen Tippfehler zu finden, macht überhaupt keinen Spaß:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: A designated revocation certificate should follow

mI0EUC7pHgEEAL6l6e1en1AMacyb9zcpBp30qyccVnmguYzhsMJ0qAEhRlA+L2sA
kug0BGOb1/lp9DduONrummAVScEVhudijqSK4IDiePDIOGOVftv8e8bbHFiLLDET
[...]
YLQ1TI9MLuGleqWFvg==
=+BPg
-----END PGP PUBLIC KEY BLOCK-----

Das kann man z.B. so machen, dass man sich für jede Zeile des eigentlichen Codes einen Hashwert erzeugen lässt:

while read line; do echo "$line" | md5sum; done <inputfile

Das führt zu einer Datei, die so aussieht:

17395b0562f16139ecd91a9ea04c3c37  -
3a51bdb074e13664a85613aa39aa2df9  -
[...]

Das Kommando paste fügt die beiden Dateien zusammen, so dass der Codeblock dann folgendermaßen aussieht:

mI0EUC7pHgEEAL6l6e1en1AMacyb9zcpBp30qyccVnmguYzhsMJ0qAEhRlA+L2sA        17395b0562f16139ecd91a9ea04c3c37  -
kug0BGOb1/lp9DduONrummAVScEVhudijqSK4IDiePDIOGOVftv8e8bbHFiLLDET        3a51bdb074e13664a85613aa39aa2df9  -
21oFmh4DFzw0D/EgIr182+VSeSxdzdsAAAZx0cgWhljz1BqjRHieOA2NABEBAAGI        f9f3a6ebd0e2213e97e6dddcabad8852  -
nwQgAQIACQUCUC7uAAIdAAAKCRC9LohRo0H4FKOZBAC5LpB19k3oJxbcMsLYCoqK        cea2460a5d8c52c05a3704effcd133a2  -
923sUmlKYzXNVDQdNQIKRF+NLEUnpM67ZvEF6escstYGdCSoAq5v3p+DThVIvALx        f0ce88719c271f26ea4572f8a64b249f  -
Ft0svdkyYqL5VPlDF1pIJ4SJLgcS69in0vKm6bkvleDrTR3ir2oxgiY0FMwQjz9Q        c04e510e547080811faa090c747f1894  -
Ik+utxVY+dCWSbZre5JJ1Ii3BB8BAgAhBQJQLuwyFwzAAQ0hEosFfoAaI7yGLr0u        b561c841a1e046c4f5c6d22002364bb5  -
iFGjQfgUAgcAAAoJEC3dQaWRJVRB3RID/i5rB5yb5Mr4kcOwMFesSJun8ILgjw+d        c3c8b582dcc31f95cfa2d62204a6ea40  -
bkz+ckm0SQh8LUVR/1M+yKFyL6sBVOjT554tCY6IFpWxqipjMhQyPuwc3VLBTtXd        7b79c440bcfa8634095c7f310e8ef6f6  -
YUPS0t/34i+fOZr2BNewcsWfwmby/n+XE1v/9bmy0ElRWYMoM+LG4/zoX+MebolU        a9c449fbb8e091cac3d00b67ae4b26d5  -
cPrBdY6ARyXPtAh0ZXN0a2V5Moi4BBMBAgAiBQJQLukeAhsDBgsJCAcDAgYVCAIJ        11a99bcea6e8de63e8b37c1316739294  -
CgsEFgIDAQIeAQIXgAAKCRAt3UGlkSVUQQupA/967DpXj1ODI/OlpkbvQHth6Cvo        75ae409b5252f14fc66746950df1e729  -
rSl42mslCnvkPHm5O8iulBQFX8zwONAZD8HPKPK4oYh07JD360nR6JCphhXgq+tF        632de26606eb90fdb698195f92a8f3b8  -
3P0/qeDZyA1ZqS9Ft8pBq5/mHiqt6HHaqsw1hRhqIMe1iaCNF5Hb++S7DlcpRVpa        cf8fb5c470e127c9192768b6b7f62efe  -
YLQ1TI9MLuGleqWFvg==                                                    15492de8422a631c17abbdd51c5beb26  -
=+BPg                                                                   f12fb605fb1aca5ed0a60643a9a9e4a0  -

Nach dem Abtippen kann man dann im Fall von Fehlern für jede Zeile den Hashwert berechnen lassen und mit dem auf dem Ausdruck vergleichen.

Warum man die Aktivierung eines Hauptschlüssel-Sperrzertifikats (gegenüber der Öffentlichkeit) nicht zurücknehmen kann, erkennt man am Aufbau eines Zertifikats, zuerst ein Schlüssel, der komplett zurückgezogen wurde:

start cmd:> gpg --with-colons --list-sigs 0x75525FFD
pub:r:1024:1:5E95F07975525FFD:1352342315:::u:::esc:
rev:::1:5E95F07975525FFD:1352342673::::revoked key:20x:

In diesem Fall hängt das Widerrufszertifikat direkt am Hauptschlüssel. Der Hauptschlüssel hat außerdem im Gegensatz zu User-IDs und Unterschlüsseln keine Eigenbeglaubigung, die ihn erst gültig macht. Nun das Beispiel mit weiterhin gültigem Hauptschlüssel und widerrufener UID und widerrufenem Unterschlüssel:

start cmd:> gpg --with-colons --list-sigs 0x6AF2790A
pub:f:1024:1:C4F9E0DE6AF2790A:1303341480:::n:::scESC:

uid:-::::1352159551::6B0D1317D6808F75E48EF621F02F4CFEB09EED5C::Test Key (Passphrase\x3a foo) <test@key.invalid>:
rev:::1:BAAF6EF92D6AAED6:1352159005::::lokaler Signaturschlüssel:30l:
sig:::1:C4F9E0DE6AF2790A:1352159551::::Test Key (Passphrase\x3a foo) <test@key.invalid>:13x:

sub:r:1024:1:2FBEEE2A8B45BB85:1303344289:1304814827:::::s:
rev:::1:C4F9E0DE6AF2790A:1352266808::::Test Key (Passphrase\x3a foo) <test@key.invalid>:28x:
sig:::1:C4F9E0DE6AF2790A:1304728427::::Test Key (Passphrase\x3a foo) <test@key.invalid>:18x:

Hier hängen die Sperrzertifikate an den jeweiligen Komponenten. Der wesentliche Unterschied ist: Da der Hauptschlüssel weiterhin gültig ist, kann er prinzipiell auch weiterhin unbedenkliche Eigenbeglaubigungen für UIDs und Unterschlüssel erzeugen. Wenn der Hauptschlüssel aber selber widerrufen wurde, dann kann er keine Eigenbeglaubigung mehr erzeugen, die erfolgreich validiert werden könnte. Der sachliche Grund ist, dass jemand, der in den Besitz eines fremden privaten Hauptschlüssels gekommen ist, natürlich auch neue Eigenbeglaubigungen für diesen erzeugen könnte. Wird nur ein Unterschlüssel kompromittiert, kann er das nicht.

Die Vorgehensweise unterscheidet sich je nach Komponente:

designated revoker

Ein Grund für das Zurückziehen eines Schlüssels ist, dass einem der private Schlüssel abhanden gekommen ist. Dann kann man aber naturgemäß keine Sperrzertifikate mehr erzeugen. Entweder hat man das also präventiv erledigt, oder man steht dumm da. Zur Lösung dieses Problems gibt es das Konzept des designated revoker. Man kann andere Schlüssel berechtigen, Sperrzertifikate für den jeweiligen Schlüssel auszustellen. Das können weitere eigene Schlüssel, aber auch die von Dritten, denen man entsprechend vertraut, sein. Dieses Verfahren drängt sich dann auf, wenn man einen zentralen Zertifizierungsschlüssel hat, also quasi in OpenPGP eine CA nachbaut, etwa in einem Unternehmen. Jedenfalls dann, wenn man nicht Kopien der privaten Schlüssel verwahrt. Vermerkt werden die designated revoker mit dem Kommando --edit-key und addrevoker. Um mal die gpg-Warnung zu zitieren: Einen Schlüssel als vorgesehenen Widerrufer zu deklarieren, kann nicht rückgangig gemacht werden! (Das gilt strenggenommen aber erst dann, wenn irgendwem eine Version des Schlüssels mit diesem Eintrag zugänglich gemacht wurde.) Für den unwahrscheinlichen Fall, dass man seinen Schlüssel versehentlich mit dieser Berechtigung versehen (oder gleich komplett wiederrufen) hat und an den öffentlichen Schlüssel (in der neusten Version) nicht mehr herankommt, ist hier erklärt, wie man diesen Teil des Schlüssels auf die harte Tour loswird. gpgsplit funktioniert übrigens nicht mit Dateien, die mit der Option --armor erzeugt wurden (kann man notfalls mit --dearmor konvertieren).

Da möglicherweise nicht jeder sehen soll, dass es einen designated revoker gibt, kann man den mit dem erweiterten Kommando addrevoker sensitive anlegen; dann wird dieser Teil des Schlüssels standardmäßig (siehe --export-options export-sensitive-revkeys) nicht exportiert. Man muss dann aber einmal den öffentlichen Schlüssel mit dieser Berechtigung exportieren und diese entweder selber sicher verwahren (was man dann natürlich auch gleich mit einem Sperrzertifikat machen könnte) oder aber dem Berechtigten zukommen lassen.

Ob es designated revoker für einen Schlüssel gibt, kann man mit einem normalen --list-keys nicht sehen. Dafür benötigt man entweder --edit-key oder --with-colons --list-keys:

start cmd:> gpg --edit-key 0x6AF2790A
[...]
Dieser Schlüssel könnte durch DSA mit Schlüssel 0xECCB5814 Hauke Laging <hauke@laging.de>  widerrufen worden sein


start cmd:> gpg --with-colons --list-keys 0x6AF2790A
pub:-:1024:1:C4F9E0DE6AF2790A:1303341480:::q:::scESC:
rvk:::17::::::D44C6A5B71B0427CCED3025CBD7D6D27ECCB5814:80:

Grenzen der Effektivität des Zurückziehens

Es reicht natürlich nicht aus, dass man ein Sperrzertifikat erzeugt. Derjenige, der den ungültig gewordenen Schlüssel verwenden will, muss es rechtzeitig erhalten. Leider sind selbst engagierte Verwender von GnuPG oftmals schlampig, was das Aktualisieren ihrer Schlüssel angeht. Anders als bei X.509/SSL (und selbst da ist bzw. war es sehr lange in der Praxis richtig schlecht umgesetzt) ist das Zurückziehen von Schlüsseln in der OpenPGP-Welt nicht so verankert, wie man sich das wünscht. Es ist zudem schwierig, anderen Leuten eine (im kryptografischen Sinn) verlässliche Prüfung zu ermöglichen, ob der eigene Schlüssel noch aktuell ist. Das wäre innerhalb der Infrastruktur nur möglich, wenn man signierte Daten von den Keyservern bekäme, aber die meisten sprechen nicht mal SSL (aus Kostengründen). Als Ausweg bleibt, nur Schlüssel mit noch jungen Selbstsignaturen zu akzeptieren (was einen nicht vor kompromittierten Hauptschlüssel schützt), sei es (seitens des Schlüsselbesitzers) durch sehr kurze Gültigkeitszeiträume des Schlüssels (Tage, Wochen), sei es (seitens der Kommunikationspartner), indem man nur Schlüssel anderer Nutzer mit jungen Selbstsignaturen akzeptiert (mit gpg-Bordmitteln nicht erzwingbar, das muss man sich irgendwie basteln, etwa durch sehr kurze Gültigkeitszeiträume der Zertifizierungen für die Schlüssel anderer Leute (--ask-cert-expire), was natürlich nur dann praktikabel ist, wenn die Schlüsselbesitzer entsprechend häufig ihre Selbstsignatur erneuern.

Verschlüsseln / Entschlüsseln

wichtige Kommandos --encrypt --decrypt --sign --encrypt --symmetric --symmetric --encrypt
wichtige Optionen --recipient --encrypt-to --armor --multifile --output
Links zum Thema
spezielle Kommandos --edit-key (showpref)
spezielle Optionen --hidden-recipient --hidden-encrypt-to --group --cipher-algo --compress-algo --s2k-count --personal-cipher-preferences --personal-compress-preferences --default-preference-list --set-filename --throw-keyids
spezielle Links zum Thema

Wenn Daten für OpenPGP verschlüsselt werden, wird zuerst ein nur einmal verwendeter symmetrischer Schlüssel erzeugt, der sogenannte session key. Mit diesem Einmalschlüssel und einem konfigurierbaren Verschlüsselungsverfahren (Cipher) werden dann die Daten (eventuell nachdem sie signiert wurden) verschlüsselt. Der session key wird dann für jeden Empfängerschlüssel und / oder mit der Passphrase verschlüsselt; diese Mischung von asymmetrischen und symmetrischen Verfahren nennt man hybride Verschlüsselung. Deshalb wird das OpenPGP-Paket kaum größer, wenn man es an mehr Schlüssel adressiert (je nach Schlüssellänge ca. 128 bis 512 Byte pro Paket mit verschlüsseltem Sessionkey). Der folgende Ablauf entspricht diesem (ungewöhnlich komplizierten) Aufruf:

gpg --recipient empfaenger1 --recipient empfaenger2 --symmetric --sign --encrypt datei.txt

Einzelschritt
Ausgangslage Klartextdaten
Signierung Klartextdaten Klartextsignatur
eventuell Kompression der Daten
komprimierte Daten
Klartextsignatur
Fertigstellung des ersten OpenPGP-Pakets
OpenPGP-Paket mit signierten Daten
Verschlüsselung von Daten und Signatur
verschlüsselter Block
Verschlüsselung des session keys für den ersten Empfängerschlüssel enc(sessionkey,key1)
verschlüsselter Block
Verschlüsselung des session keys für den zweiten Empfängerschlüssel enc(sessionkey,key1) enc(sessionkey,key2)
verschlüsselter Block
Verschlüsselung des session keys für die Passphrase enc(sessionkey,key1) enc(sessionkey,key2) enc(sessionkey,passphrase)
verschlüsselter Block
Fertigstellung des gesamten OpenPGP-Pakets
OpenPGP-Paket mit verschlüsselten Daten

Daten werden mit gpg --encrypt (asymmetrisch, d.h. für einen öffentlichen Schlüssel) oder gpg --symmetric (symmetrisch, d.h. mit Passphrase, keine OpenPGP-Schlüssel erforderlich) verschlüsselt. Die Empfänger werden jeweils mit --recipient angegeben (zusätzliche Standardempfänger in der Konfigurationsdatei mit --encrypt-to oder --hidden-encrypt-to); die Möglichkeiten der Identifizierung von Schlüsseln sind im Abschnitt Schlüsselauswahl erläutert. Wenn man häufig (auch) für dieselbe Gruppe von Empfängern verschlüsselt, kann man mit --group (in der Konfigurationsdatei) die Gruppe abkürzen. Man kann Daten nur asymmetrisch, nur mit Passphrase oder (wie im obigen Beispiel) sowohl asymmetrisch als auch mit Passphrase verschlüsseln.

Ohne die Angabe von --output werden die ver- oder entschlüsselten Daten in eine Datei geschrieben, deren Name der Name der Quelldatei ergänzt um .gpg (bzw. .asc bei Angabe von --armor) ist; kommen die Daten von der Standardeingabe, wird auf die Standardausgabe geschrieben.

Es ist oftmals sinnvoll, eine Nachricht auch für sich selber zu verschlüsseln; vor allem dann, wenn man Daten verschlüsselt, verschickt, aber die verschickten Daten auch archiviert. Ohne einen eigenen Schlüssel als Standardempfänger kann man sich dann hinterher nicht mehr anschauen, was man selber verschickt hat, was oftmals unerwünscht sein dürfte. Das kann man in der Konfigurationsdatei mit den Optionen encrypt-to und hidden-encrypt-to und der Angabe der eigenen Schlüssel-ID einstellen.

Die Entschlüsselung verläuft umgekehrt: GnuPG prüft, ob der private Schlüssel einer der Empfängerschlüssel vorhanden ist und fragt (falls nötig) die Passphrase ab. Erst nach der Entschlüsselung kann die Signatur geprüft werden. Vor der Entschlüsselung kann man nicht einmal wissen, ob die Daten überhaupt signiert sind. Die Entschlüsselung ist vom Aufruf her einfacher als die Verschlüsselung:

gpg --decrypt datei.txt.gpg

gpg datei.txt.gpg

Wenn man kein Kommando angibt, versucht gpg in Abhängigkeit von den übergebenen Daten etwas Sinnvolles zu tun. Bei einer verschlüsselten Datei ist das deren Entschlüsselung. Bemerkenswerterweise verhält sich diese Standardoperation anders als --decrypt: Die Standardoperation schreibt die entschlüsselten Daten in eine Datei, --decrypt dagegen schreibt sie (ohne die Angabe von --output) auf die Standardausgabe, was nur bei Text und ähnlichen Daten sinnvoll ist. Allerdings kann man die Klartextdaten in der Shell mittels Ausgabeumlenkung bequem in eine Datei umleiten. Ob man das so oder mit --output macht, ist Geschmackssache. Die Standardoperation nimmt als Dateiname denjenigen, der in der verschlüsselten Datei eingetragen ist. Ist dort keiner eingetragen, nimmt es den Dateinamen der Quelldatei, ohne seine Endung. Hat die Quelldatei keine der Standardendungen (Binärdateien gpg, Dateien in ASCII-Armor asc), dann fragt GnuPG nach dem gewünschten Namen der Zieldatei. Mit gpg --list-packets kann man sich den ggf. enthaltenen Namen anzeigen lassen.

Verschlüsseln von E-Mails

Zumeist verschlüsselt man E-Mails; das erledigt dann der Mailclient für einen, mit gpg hat man da nicht zu tun (abgesehen davon, dass sich der Inhalt der Konfigurationsdatei auswirkt). Man wählt ggf. aus, dass diese Mail verschlüsselt werden soll, eventuell noch den zu verwendenden Schlüssel (den der Mailclient typischerweise anhand der Empfängeradresse(n) auswählt, und das war’s auch schon. Bei guten Mailprogrammen (und der Verwendung von PGP/MIME statt Inline-PGP) kann man für den Body der Mail und alle Attachments einzeln angeben, ob der jeweilige Teil verschlüsselt werden soll.

Siehe den Abschnitt zur Verwendung mit E-Mail.

Verschlüsseln mit ASCII-Armor

Die Option --armor sorgt dafür, dass die verschlüsselte Datei (fast) nur aus alphanumerischen Zeichen besteht. So kann man verschlüsselte Daten auch über Medien transportieren, die dafür nicht gedacht sind, etwa Chatprogramme oder Webseiten:

echo "$kompromittierende_aussage" | gpg --armor --encrypt --sign

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.15 (GNU/Linux)

hQEMA44903pRsnn6AQgAsac1BympF9+mLFGKshbWWawVKQucT+8LSHejFBdd5Tco
tN6Om3/e8gDXaze+CocMJ8/S5Seli1s6a5aamW2J+QW8w4kMU87+cdfGTQ3QRoge
6r08rCMzAYLq8AcO/fegpDVm6wTl9WPnjmNmEFcTeshVbFzxUbsaIFtFciD/nopV
GDhZW6111V+TafAHkvpwdwxFMMLIQpl/xe06wZTip/zJWVCSSpnYupQ4OzsFABvL
9GFGBXegXKTOBKcGpywO6hO9t51Q6JLuK+Gug/2Sd2D9G2kuWep+cnRX4D7KGa3n
P57XYzzk+Fk3JXug33aed8Nj19DnAUkS9TKm2+3fotLBAwH8TzR/jn914jkb7tfj
AfS3J/UIb7Q9Yr53BBQlR1v1LV8xpeYxlBNoFbD1XHrj0Iucpru6seTmxZJjnhml
l60DEFqt0RPwWIoApmZo5hgicwJHJP/JsNTU2tDjfxGc2uUnuHpr9Yg0D/KjO6+z
/fKTY/WK0OJ0fGq2h36LOY0/H8KQ7bo2VoyPuOxZGZ/WVYLtPSP3aX7oPELWsGeP
yQRELtCqN/ak/yvTONwUCaXm+Np+Zj+jX3SgcUPNHb9OHfQ9YnPIcd/WvVhUuKWz
a6TqRR+3LtgCkdMl37Aif2p5zcQYIgz3BIh153Cfm9oLQueseZWW/BIjWXqqHR9h
p6B8YE2ULnEsLtrjRd/nN11dBNQLW5mX5/a/Cae3in8cGnU9Jni1BIJbYLDJDGKM
wXy0COhvISRJ7Req81eUgapgHbEjeIheMhImLP3lOdTBJXx7B/isOEcOfyWBwUO0
6+vv6zxWMTB0TuUxMDPCgYjZyPFIuw4C0yJ1AcE49lg2Vj1J4yw0gZzDMdepBwDj
+D4PT7djKGrGTKkP+24Od/0TkSayH6NVCEv6+ia5aSwZIFHSvFah6iP73NxQuFic
HGvGAgI=
=GKpQ
-----END PGP MESSAGE-----

Ganz heikel, aber das sollte außer mir niemand lesen können... ;-)

Sessionkeys

Es wird nicht die ganze Nachricht asymmetrisch verschlüsselt; das wäre viel zu aufwendig. Für jede Nachricht wird ein zufälliger Schlüssel ermittelt, mit dem die Nachricht symmetrisch verschlüsselt wird. Nur dieser Einmalschlüssel wird asymmetrisch verschlüsselt. Deshalb kann man eine Nachricht auch mehrfach verschlüsseln: Der Zufallsschlüssel wird für jeden Empfänger verschlüsselt, und alle diese verschlüsselten Varianten werden in die Containerdatei geschrieben.

start cmd:> gpg --encrypt --cipher-algo AES192 --recipient 0x71FDC5CB --output test.html.AES192.gpg test.html

start cmd:> gpg --encrypt --cipher-algo AES256 --recipient 0x71FDC5CB --output test.html.AES256.gpg test.html

start cmd:> gpg --decrypt --show-session-key --output /dev/null test.html.AES192.gpg
[...]
gpg: session key: `8:6B56B66C5765209B279FA95ED23485BF22A4CF84082A7132'

start cmd:> gpg --decrypt --show-session-key --output /dev/null test.html.AES256.gpg
[...]
gpg: session key: `9:7E4C85F5D7805467FA2D05B4CECC9BD11144E20A836AE9BFA6416AAFD689461C'

Hier wurde die Datei test.html mit zwei unterschiedlichen Algorithmen (die unterschiedlich lange Schlüssel verwenden) verschlüsselt. Beim Entschlüsseln mit der Option --show-session-key wird der symmetrische Schlüssel angezeigt. Wegen der unterschiedlichen Algorithmen sind die beiden Zufallsschlüssel unterschiedlich lang. Das --output /dev/null sorgt dafür, dass die zum Testen uninteressanten Ausgabedaten weggeworfen werden (nicht über einen gpg-, sondern einen Linux-Mechanismus).

versteckte Empfänger

Wenn man nicht möchte, dass ersichtlich ist, für wen (also für welchen Schlüssel) Daten verschlüsselt wurden, kann man sich der Optionen --hidden-recipient (zur Verschleierung einzelner Empfänger) und --throw-keyids (aller Empfänger) bedienen. Der Empfänger muss dann alle seine geheimen Schlüssel ausprobieren (das macht gpg automatisch).

gpg schreibt zwar auch ohne diese Option nur die (long) ID des Empfängerschlüssels (ggf. nur die des Unterschlüssels) in den Header der verschlüsselten Nachricht (also insbesondere keine UID), es ist aber oftmals möglich, (z.B. über Keyserver) herauszufinden, welche E-Mail-Adresse zu dieser ID gehört.

Wie man die verschlüsselten Daten dann so zum Empfänger bekommt, dass nicht schon der Transportweg ihn verrät, ist dann eine andere Frage.

Festlegung des Verschlüsselungsverfahrens (Cipher)

GnuPG kann eine Reihe von Verfahren anwenden, um Daten symmetrisch zu verschlüsseln, deutlich mehr, als asymmetrische Verfahren (die Schlüsseltypen RSA, DSA, ElGamal). Welche das sind, kann man sich mit --version anzeigen lassen:

start cmd:> gpg --version
[...]
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA
Verschlü.: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, 
            CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

Irgendwie muss nun festgelegt werden, welcher Algorithmus verwendet wird. Einen zu wählen, den die OpenPGP-Software des Empfängers (bzw. aller Empfänger) nicht unterstützt, wäre natürlich nicht im Sinne des Erfinders. RfC 4880 (9.2) schreibt lediglich die Unterstützung von TripleDES zwingend vor und empfiehlt die von AES-128 and CAST5. Bei Kompression ist kein Verfahren vorgeschrieben und ZIP empfohlen.

Ausgewählt wird das Verfahren, indem die Präferenzen des Empfängers (im Zweifelsfall der adressierten UID; mehrere UIDs können unterschiedliche Präferenzen haben, auch wenn das eher selten beabsichtigt sein dürfte) mit denen des Absenders abgeglichen werden. Ich weiß nicht, wie die Präferenzen gegeneinander aufgerechnet werden (habe es nicht ausprobiert, und die Dokumentation geht nicht ins Detail), aber die Dokumentation erweckt den Eindruck, dass die Absenderpräferenzen Vorrang haben. Vermutlich wird also das höchstrangige Verfahren des Absenders gewählt, das der Empfänger akzeptiert (und als Notnagel TripleDES als kleinster gemeinsamer Nenner).

Die Präferenzen eines Schlüssels (bzw. die aller UIDs eines Schlüssels), also der eigenen Position als Empfänger, kann man sich mit --edit-key showpref anzeigen lassen. Ändern kann man sie mittels --edit-key setpref, was durch die Verwendung von --default-preference-list (in der Konfigurationsdatei; üblicherweise dürften die Präferenzen für alle eigenen Schlüssel gleich sein) bequemer ist, weil man setpref dann ohne Parameter aufrufen kann. --default-preference-list setzt außerdem den Standard für neu erzeugte Schlüssel (und neue UIDs in bestehenden Schlüsseln). In beiden Varianten muss man die Werte für Verschlüsselungsverfahren, Hash und Kompression gleichzeitig angeben:

default-preference-list AES,AES256,AES192,CAST5,3DES,SHA256,SHA512,SHA384,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP

start cmd:> gpg --edit-key 0x1a571df5 showpref quit
[...]
[ uneing.] (1). Hauke Laging (Standardschlüssel: siehe policy URL und signature notations)
     Verschlü.: AES, AES256, AES192, CAST5, 3DES
     Digest: SHA512, SHA384, SHA256, SHA1
     Komprimierung: ZLIB, BZIP2, ZIP, nicht komprimiert
     Eigenschaften: MDC, Keyserver no-modify
[...]

Die eigenen Präferenzen als Absender kann man mit --personal-cipher-preferences und --personal-compress-preferences festlegen; sinnvollerweise in der Konfigurationsdatei.

Signieren

Signaturen werden mit gpg --sign oder gpg --detach-sign erstellt.

Auch Signaturen betreffen zumeist E-Mails und sind dann komfortabel vom Benutzer abgeschirmt.

Wenn man mit gpg (oder einem GUI) normale Dateien (oder Datenströme) signiert, muss man wissen, dass es unterschiedliche Arten gibt, eine Signatur zu speichern (und natürlich auch unterschiedliche Arten von Signaturen):

Eine Signatur ist ein Hashwert der zu signierenden Daten, der mit dem privaten Schlüssel so verrechnet wird, dass mit Hilfe des öffentlichen Schlüssels nachgewiesen werden kann, dass der zugehörige private Schlüssel die Signatur erzeugt hat. Eine Signatur ist deshalb nur so sicher wie der verwendete Hash. Wenn für den Hashwert eine Kollision erzeugt werden kann, rettet einen der längste Schlüssel nicht. gpg unterstützt eine Menge Hashfunktionen, allerdings kann es beim Einsatz der OpenPGP-Smartcard zu Problemen kommen. SHA-1 (aktuelle Standardeinstellung) ist derzeit sicher (das gilt nur für Urbildangriffe, aber nicht mehr für Kollisionsangriffe; also mit SHA-1 nur selbsterzeugte (oder in einem inhaltlich irrelevanten Detail veränderte) Daten signieren) und funktioniert mit der Smartcard. Die Hash-Auswahl kann man mit der Option personal-digest-preferences steuern.

Speicherung von Daten und Signatur in einer oder mehreren Dateien

Man kann Daten und Signatur in dieselbe Datei schreiben. Das passiert bei Verwendung der Kommandos --sign. Wenn man die zu signierenden Daten als unveränderte Datei behalten will (ohne eine neue vergleichbar große Datei) oder mehrere Dateien auf einmal signieren will, verwendet man --detach-sign (kann mit --encrypt kombiniert werden; aber eine Signatur muss man normalerweise nicht verschlüsseln). Wenn man auf diese Weise mehrere Dateien signiert, dann kann man die Signatur auch nur über alle Dateien gleichzeitig (und in derselben Reihenfolge) prüfen!

Erzeugen einer signierten Datei test.html.gpg, die die Daten von test.html enthält:

start cmd:> l test*
-rw-r--r-- 1 hl hauke  18 11. Jun 02:09 test2.html
-rw-r--r-- 1 hl hauke 810 11. Jun 02:09 test.html 

start cmd:> gpg --sign test.html

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Hauke Laging <hauke@laging.de>"
2048-Bit RSA Schlüssel, ID 0x3A403251, erzeugt 2010-03-04 (Hauptschlüssel-ID 0xECCB5814)


start cmd:> l test*
-rw-r--r-- 1 hl hauke   18 11. Jun 02:09 test2.html
-rw-r--r-- 1 hl hauke  810 11. Jun 02:09 test.html
-rw-r--r-- 1 hl hauke 1,2K 11. Jun 02:10 test.html.gpg

Erzeugen einer Datei test.html.sig, die nur die Signatur von test.html enthält (also ohne die Bezugsdatei wertlos ist). Anschließend Überprüfung der Signatur.

start cmd:> gpg --detach-sign test.html

[...]

start cmd:> l test*
-rw-r--r-- 1 hl hauke   18 11. Jun 02:09 test2.html
-rw-r--r-- 1 hl hauke  810 11. Jun 02:09 test.html 
-rw-r--r-- 1 hl hauke 1,2K 11. Jun 02:10 test.html.gpg
-rw-r--r-- 1 hl hauke  335 11. Jun 02:11 test.html.sig

start cmd:> gpg test.html.sig
gpg: Signatur vom Fr 11 Jun 2010 02:11:01 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"

Erzeugen einer gemeinsamen Signaturdatei test.html.all.sig für die beiden Dateien test.html und test2.html. Überprüfung scheitert, wenn nicht beide angegeben werden:

start cmd:> gpg --detach-sign --output test.html.all.sig test.html test2.html

[...]

start cmd:> l test*
-rw-r--r-- 1 hl hauke   18 11. Jun 02:09 test2.html
-rw-r--r-- 1 hl hauke  810 11. Jun 02:09 test.html
-rw-r--r-- 1 hl hauke  335 11. Jun 02:11 test.html.all.sig
-rw-r--r-- 1 hl hauke 1,2K 11. Jun 02:10 test.html.gpg
-rw-r--r-- 1 hl hauke  335 11. Jun 02:11 test.html.sig

start cmd:> gpg --verify test.html.all.sig test.html
gpg: Signatur vom Fr 11 Jun 2010 02:11:50 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: FALSCHE Signatur von "Hauke Laging <hauke@laging.de>"

# Kommando beendet sich mit exit code 2

start cmd:> gpg --verify test.html.all.sig test.html test2.html
gpg: Signatur vom Fr 11 Jun 2010 02:11:50 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"

Signierte Dateien kann man nur dann verwenden, wenn die Zielapplikation weiß, was das ist (z.B. ein PGP-fähiger Mailclient). Abgetrennte Signaturen lassen sich dagegen immer problemlos verwenden. Auf diese Weise kann man beispielsweise Webseiten signieren. Mit dem Ergebnis von --sign und --clearsign kann ein Browser nichts anfangen, aber man kann eine angetrennte Signatur erzeugen und verlinken. Man speichert dann die Webseite (als z.B. openpgp.html) und die Signatur (als z.B. openpgp.html.sig) und prüft dann die Gültigkeit der Signatur.

Signaturcodierung

--sign erzeugt eine "binäre" Signatur, also eine Datei, die sowohl die Nutzdaten als auch die Signatur enthält und die man nicht problemlos mit einem normalen Editor lesen kann (weil sie – jedenfalls im Signaturteil – nichtdruckbare Zeichen enthält). Wenn man die Signatur prüfen will, muss man die gesamten Daten auspacken. --clearsign eignet sich für Textdateien (und Ausschnitte davon). Das Ergebnis kann normal mit einem Editor gelesen werden. Ein "Kompromiss" aus beidem ist die Option --armor. Damit werden Daten (sowohl Verschlüsselung als auch Signatur) in druckbaren ASCII-Zeichen codiert. Damit kann man als Mensch zwar nichts anfangen, aber man kann die Daten dann problemlos in Textmedien unterbringen (z.B. auf Webseiten). Dann sieht alles so aus wie die Signatur im folgenden clearsign-Beispiel:

echo hello world | gpg --clearsign

oder mit einer Datei, die den Text, also hier "hello world" enthält:

gpg --clearsign hello_world.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello world
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iQFMBAEBAgA2BQJMEXtrLxpodHRwOi8vd3d3LmhhdWtlLWxhZ2luZy5kZS9vcGVu
cGdwL3BvbGljeS5odG1sAAoJEFug+LU6QDJRiggH/2j23/ZzIOEoqjMWrcMbsI8/
Kfr7ikjIgrb1NfD+vVeDe7txQaDDN+/qKl18gPwNR4fjpVdg4gEmarFZ31R9bCJC
i1VtFTbRIdV5OXDpQ+vqYkG8x6AP6kOyUY6bEec8HKLD2M2FbBPgMjUMZ/d1hGlS
+ps5Pz1CutS1QsHn5lnRltvxsf8Fez3oJs811kq49gOd3YFkJycCGXBkRHM0OQcF
0NVwUSxDGKOlbQCDsCSPeTQo119MrC5u2bqs6svWQTiregHzUWsW93VA/fhZnX6j
956GMxoj4o6zDK8ZXbrClBBhywdwxcSxm8CGqFvGJQAggmYLpuBonsVTH6SWM1E=
=HCbr
-----END PGP SIGNATURE-----

Bei dem Kommandoaufruf habe ich --local-user 0xECCB5814 weglassen können, weil diese ID in der Konfigurationsdatei ~/.gnupg/gpg.conf-2 mit der Option default-key als Standard festgelegt ist. Dasselbe gilt für --recipient und encrypt-to.

Die clearsign-Variante hat allerdings ein Problem, das die normale Variante nicht hat: Die Signatur bezieht sich technisch nicht auf einen Text, sondern auf eine Bytefolge. Die Bytedarstellung von Text ist allerdings nicht eindeutig, sondern hängt von Zeichensatz und Codierung ab. Das ist deshalb problematisch, weil der verwendete Zeichensatz nicht in der Signatur vermerkt wird. Dadurch kann es passieren, dass eine Signatur ungültig wird, weil (unbemerkt) eine Konvertierung vorgenommen wurde oder bei E-Mail auf dem Transportweg das Encoding verändert wurde. Die Zeichensatzprobleme treten allerdings normalerweise nur dann auf, wenn Nicht-ASCII-Zeichen (also z.B. Umlaute) verwendet werden.

Es gibt auch Editoren mit GnuPG-Unterstützung. Bei denen erstellt man einfach den zu signierenden (oder zu verschlüsselnden) Text und ruft dann die entsprechende Funktion auf. Man erhält dann das Ergebnis im Editorfenster. gpa (Gnu Privacy Assistant) und kgpg (Linux/kde) haben einen eigenen Editor. Kleopatra bietet die Funktion über den Umweg der Bearbeitung der Zwischenanlage.

Signieren und Verschlüsseln

Man kann Daten gleichzeitig (d.h. von einem einzigen gpg-Aufruf) signieren und verschlüsseln lassen. Dafür werden einfach die entsprechenden Kommandos --encrypt, --symmetric und --sign kombiniert. Die Verwendung von --clearsign oder --detach-sign ist in dieser Variante allerdings nicht möglich.

Bei dieser Kombination wird immer zuerst die Signatur erzeugt und dann der signierte Datenblock verschlüsselt. Siehe den Abschnitt Reihenfolge von Verschlüsselung und Signatur.

Mehrfachsignatur

Man kann für eine Datei Signaturen mehrerer Schlüssel erzeugen und gemeinsam abspeichern. Das kann man einerseits erreichen, indem --local-user mehrfach angegeben wird, und andererseits, indem mehrere Signaturdateien zusammenkopiert werden (das funktioniert sowohl bei Textsignaturen als auch bei binären). Solche Dateien können aber nicht alle OpenPGP-Implementierungen verarbeiten.

start cmd:> cat test.html.1.sig test.html.2.sig > test.html.beide.sig

start cmd:> gpg --verify test.html.beide.sig test.html
gpg: Signatur vom Fr 23 Jul 2010 02:01:45 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"
gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html

gpg: Signatur vom Fr 23 Jul 2010 02:01:45 CEST
gpg:                mittels RSA-Schlüssel 0xBB8A54D2
gpg: Korrekte Signatur von "Test Key (Demo) <test@key.inv>"
gpg:                     alias "Neue UID (nach der Signierung hinzugefügt) <test2@key.inv>"
gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html

Reihenfolge von Verschlüsselung und Signatur

Prinzipiell kann man Daten sowohl erst signieren und dann verschlüsseln als auch erst verschlüsseln und dann signieren. gpg unterstützt aber nur den ersten Weg direkt. Auf diese Weise wird nicht enthüllt, wer die Daten signiert hat. Das mag in speziellen Fällen relevant sein. Für (zentrale) Virenscanner ist es dagegen ein Alptraum. Wenn man verschlüsselte Daten signieren möchte, muss man gpg zweimal aufrufen, erst für die Verschlüsselung (die natürlich selber auch eine Signatur enthalten kann) und dann zur Signierung der verschlüsselten Datei.

gpg --recipient empfaenger1 --recipient empfaenger2 --symmetric --encrypt datei.txt

gpg --sign datei.txt.gpg

Einzelschritt
Ausgangslage Klartextdaten
Verschlüsselung der Daten
verschlüsselter Block
Verschlüsselung des session keys für den ersten Empfängerschlüssel enc(sessionkey,key1)
verschlüsselter Block
Verschlüsselung des session keys für den zweiten Empfängerschlüssel enc(sessionkey,key1) enc(sessionkey,key2)
verschlüsselter Block
Verschlüsselung des session keys für die Passphrase enc(sessionkey,key1) enc(sessionkey,key2) enc(sessionkey,passphrase)
verschlüsselter Block
Fertigstellung des ersten OpenPGP-Pakets
OpenPGP-Paket mit verschlüsselten Daten
Signierung der Daten (des ersten OpenPGP-Pakets)
OpenPGP-Paket mit verschlüsselten Daten
Klartextsignatur
Fertigstellung des zweiten OpenPGP-Pakets
OpenPGP-Paket mit signierten Daten

GnuPG kann beliebige Daten signieren, also natürlich auch eine Datei mit OpenPGP-Daten. Das wird in diesem Fall ausgenutzt. Für die Signatur ist unerheblich, dass die signierten Daten Ciphertext (verschlüsselt) sind, denn sie werden nicht inhaltlich bearbeitet.

technische Details

Den folgenden Optionen begegnet man kaum einmal, aber auch sie haben ihren Sinn.

Policy URL

Eine digitale Signatur ist zunächst mal nur ein technischer Wert, dessen eindeutiger Aussagegehalt sich darauf beschränkt, dass der Signierende im Besitz des privaten Schlüssels und der signierten Daten (ganz genau: zumindest ihres Hashwerts) war. Auch wenn man unterstellt, dass der Signierende der legitime Besitzer des Schlüssels war, weiß man noch nicht, was diese Signatur zu bedeuten hat; vielleicht wollte der Signierer die Datei bloß gegen unerkannte Veränderungen sichern oder (für jemand anderen) bestätigen, dass sie zu einem bestimmten Zeitpunkt existiert hat. Man kann zweierlei tun, um dem Prüfer einer Signatur deren Interpretation zu erleichtern: Man kann die Information in eine zweite Datei packen und dann die Daten und diese Hilfsdatei gemeinsam signieren (die können dann auch nur gemeinsam geprüft werden, siehe die Signaturbeispiele oben). Die andere Möglichkeit, die sich vor allem für allgemein gültige Hinweise (wie bei der Zertifizierung von Schlüsseln) eignet, ist ein (Online-)Dokument, auf dessen URL von der Signatur aus verwiesen wird. Sinnvoll ist das natürlich nur, wenn das Dokument selber signiert ist. Bei Webseiten kann man das mit einem Link auf die abgretrennte Signatur (--detach-sign) der Datei realisieren.

Eine policy URL wird der Signatur mittels der Option --sig-policy-url URL angefügt. Die kann man sich, wenn alle Signaturen so einen Hinweis erhalten sollen, in die Konfigurationsdatei schreiben. Wenn man dieselbe URL für Schlüsselzertifizierungen und Datensignaturen verwendet, kann man statt --cert-policy-url und --sig-policy-url auch --set-policy-url verwenden.

Ablaufdatum (expire)

Man kann, in speziellen Fällen mag das sinnvoll sein, eine Signatur mit einem Ablaufdatum versehen, etwa für eine Art Ausweis (dann muss das Ablaufdatum nicht in den signierten Daten untergebracht werden) oder Signaturen, die regelmäßig erneuert werden sollen. Dies geht mit der Option --ask-sig-expire. Die gewünschte Gültigkeitsdauer wird dann von gpg abgefragt.

start cmd:> gpg --ask-sig-expire --detach-sign --local-user 0xeccb5814 test.html
[...]

start cmd:> gpg --verify test.html.sig test.html
gpg: Signatur vom Fr 23 Jul 2010 01:23:00 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"
gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html

gpg: Diese Signatur verfällt am Mo 02 Aug 2010 01:23:00 CEST.
eigene Zusatzinformationen

Man kann über die Option --sig-notation quasi beliebige Zusatzinformationen in einer Signatur unterbringen. Da ich dies bisher nicht gemacht habe, kann ich das nur der Vollständigkeit halber als Hinweis erwähnen, ohne darauf weiter einzugehen.

Signaturen prüfen

Signaturen werden mit gpg --verify geprüft.

Beim Prüfen einer Signatur prüft man mehrere Dinge:

  1. Passt die Signatur zu den Daten, das heißt:

    1. Haben die signierten Daten den Hashwert, der in der Signatur verwendet wurde?

    2. Ist die Unterschrift in der Signatur korrekt? Dies kann nur mit Hilfe des zugehörigen öffentlichen Schlüssels überprüft werden. Steht der nicht zur Verfügung, ist eine Signaturprüfung unmöglich.

  2. Ist die Signatur noch gültig? (Eine Signatur kann ein Verfallsdatum haben.)

  3. Ist der signierende Schlüssel noch gültig? (Ein Schlüssel kann ein Verfallsdatum haben und unabhängig davon zurückgezogen werden (revoke).)

  4. Wird dem Schlüssel vertraut? Warnung: Eine korrekte Signatur eines nicht vertrauenswürdigen Schlüssels ist selbstverständlich ebenfalls nicht vertrauenswürdig!

Eine korrekte Signatur eines nicht verifizierten Schlüssels sollte man im allgemeinen als wertlos betrachten.

Die Prüfung einer abgetrennten Signatur (--detach-sign) für eine einzelne Datei:

start cmd:> gpg --verify test.html.ECCB5814.sig test.html
gpg: Signatur vom Mo 21 Jun 2010 22:43:21 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"
gpg:                     alias "Hauke Laging <mail@hauke-laging.de>"
gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html

Wenn der Name der abgetrennten Signaturdatei der der signierten Datei plus eine der Standardendungen (.gpg, .sig, .asc) ist, dann reicht es aus, den Namen der signaturdatei anzugeben:

start cmd:> gpg --verify test.html.sig
gpg: Signatur vom Fr 23 Jul 2010 01:23:00 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: Verfallene Signatur von "Hauke Laging <hauke@laging.de>"
gpg:                     alias "Hauke Laging <mail@hauke-laging.de>"
gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html

Wenn eine Signatur über mehrere Dateien gleichzeitig gebildet wurde, müssen diese Dateien in derselben Reihenfolge wie beim Signieren angegeben werden:

start cmd:> gpg --verify test.html.all.sig test.html test2.html
gpg: Signatur vom Fr 11 Jun 2010 02:11:50 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: Korrekte Signatur von "Hauke Laging <hauke@laging.de>"

Es gibt zwei Möglichkeiten für technische Fehler bei der Signaturprüfung:

Die Signatur selber kann beschädigt worden sein. GnuPG erkennt dies:

start cmd:> gpg --verify test.html.ECCB5814mod.sig test.html
gpg: Prüfsummenfehler; 5d4714 - 2e894d
gpg: Keine Signatur gefunden
gpg: Die Signatur konnte nicht überprüft werden.

Die Daten können beschädigt worden sein (bzw. Daten und Signatur falsch kombiniert worden sein):

start cmd:> gpg --verify test.html.ECCB5814.sig test.mod.html
gpg: Signatur vom Mo 21 Jun 2010 22:43:21 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
gpg: FALSCHE Signatur von "Hauke Laging <hauke@laging.de>"

Bei abgelaufenen Schlüsseln oder Signaturen gibt es keinen Fehler, sondern eine Warnung. Das ist aber applikationsspezifisch (die vorige Aussage bezieht sich auf gpg); es gibt leider durchaus Programme, die bei der Handhabung dieser Umstände versagen.

Es liegt in der Natur von kryptografischen Hashwerten, dass es unmöglich ist zu sagen, ob es sich um eine komplett falsche Datei handelt oder z.B. in einer Textdatei nur ein Leerzeichen ergänzt wurde.

Damit überprüft werden kann, ob eine Signatur korrekt ist, wird der öffentliche Schlüssel benötigt:

start cmd:> gpg --verify test.html.0CBF5012.sig test.html
gpg: Signatur vom Do 26 Mai 2011 20:05:09 CEST
gpg:                mittels DSA-Schlüssel 0x0CBF5012
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

Wenn die Signatur korrekt ist, kann immer noch der Schlüssel unverifiziert sein:

start cmd:> gpg --verify test.html.0CBF5012.sig test.html
gpg: Signatur vom Do 26 Mai 2011 20:05:09 CEST
gpg:                mittels DSA-Schlüssel 0x0CBF5012
gpg: Korrekte Signatur von "testkey
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg:          Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck  = 1B52 3527 31F9 417D 5CBB  42F5 FEA6 4E07 0CBF 5012

Wie die diese Meldung loswerden, steht im Abschnitt über Schlüsselbeglaubigung.

Statusmeldungen der Signaturprüfung

Mit --status-fd und --status-file kann man sich detailliert ansehen, was gpg so macht:

start cmd:> gpg --status-fd 1 --verify test.html.sig
gpg: Signatur vom Fr 23 Jul 2010 01:23:00 CEST
gpg:                mittels RSA-Schlüssel 0x3A403251
[GNUPG:] SIG_ID s5eXj8BgkdL+kctyHtIBc0Jjfsw 2010-07-22 1279840980
[GNUPG:] EXPSIG 5BA0F8B53A403251 Hauke Laging <hauke@laging.de>
gpg: Verfallene Signatur von "Hauke Laging <hauke@laging.de>"
gpg:                     alias "Hauke Laging <mail@hauke-laging.de>"
gpg: Beglaubigungsrichtlinie: http://www.hauke-laging.de/openpgp/policy.html
[GNUPG:] POLICY_URL http://www.hauke-laging.de/openpgp/policy.html
[GNUPG:] VALIDSIG 8112FDF77EC342B0B125E0D55BA0F8B53A403251 2010-07-22 1279840980 1280704980 4 0 1 2 00 D44C6A5B71B0427CCED3025CBD7D6D27ECCB5814
[GNUPG:] TRUST_ULTIMATE

GnuPG kennt folgende Statusbezeichnungen für Signaturen:

  1. GOODSIG

  2. VALIDSIG

  3. EXPSIG (abgelaufene Signatur)

  4. EXPKEYSIG (abgelaufener Schlüssel)

  5. REVKEYSIG (zurückgezogener Schlüssel)

  6. BADSIG

  7. ERRSIG (nicht unterstützter Hashalgorithmus oder fehlender öffentlicher Schlüssel)

  8. NODATA (Signatur nicht erkannt, vermutlich beschädigt)

Siehe die Datei /usr/share/doc/packages/gpg2/DETAILS.

Zusammenspiel von gpg und gpg-agent

Version 1.4.x (seit der Veröffentlichung von 2.1.0 "classic" genannt) von gpg ist ein einzelnes Programm, das die gesamte benötigte Funktionalität enthält. 2.0.x ("stable") erfordert zwingend den (bei 1.4.x optionalen) Hilfsprozess gpg-agent für die Handhabung der Passphrase. Wenn gpg-agent vor gpg gestartet wird, kann man ihm zum Cachen der Passphrase nutzen (Dauer konfigurierbar). Wenn kein Dämon läuft, wird der Prozess von gpg gestartet, aber nach der Aktion automatisch beendet, so dass man dies normalerweise nicht einmal mitbekommt und natürlich auch kein Cachen hat.

Die 2.1.x-Versionen ("modern") lagern nicht nur die Passphrase-Handhabung, sondern auch die sensiblen Operationen in einen Serverprozess (gpg-agent) aus. Das hat zwar auch Nachteile, aber die folgenden Vorteile:

Die wichtigsten Aktionen, die gpg (über das Assuan-Protokoll) an gpg-agent auslagert:

Unter Linux sollte gpg-agent aus den Startdateien beim Login gestartet werden. Die Kommunikation mit den Clients wird dabei durch exportierte Umgebungsvariablen ermöglicht (siehe Doku von gpg-agent).

Zu Testzwecken ist es aber möglich, mehrere Instanzen von gpg-agent zu starten. Es ist dann sicherzustellen, dass die nicht versuchen, denselben Socket zu erzeugen (--no-use-standard-socket). Den Testclients muss dann natürlich noch der angepasste Wert für $GPG_AGENT_INFO (und/oder $SSH_AUTH_SOCK) übergeben werden.

Bedrohungen der Schlüssel und Gegenmaßnahmen

Schlüssel ziehen genauso wie Passwörter ihren Wert daraus, dass sie den bösen Jungs nicht bekannt sind. Dafür, dass sich das nicht ändert, sollte man sorgen. Das große Problem ist, dass wir unseren Rechnern nicht vertrauen können. Für alle relevanten Betriebssysteme und Internet-Anwendungen werden ständig Sicherheitslücken gefunden (und gestopft). Man kann nie sicher sein, dass ein normaler Rechner nicht gerade von Schadsoftware kompromittiert ist. Schadsoftware hat unter normalen Umständen alle Rechte des Benutzers, sie kann also alle Dateien lesen, auf die der Benutzer Zugriff hat. Spätestens wenn es dieser Schadsoftware gelingt, durch Ausnutzen von Sicherheitslücken in privilegierter Software (Kernel, grafische Oberfläche, Systemdämonen) höhere Rechte zu erlangen, dann kann sie im Regelfall auch Tastatureingaben mitlesen. Es kann also jederzeit passieren, dass der eigene Schlüssel samt Passphrase in die Hände eines Angreifers gelangt.

Warum dann überhaupt noch Schlüssel?

Auch wenn Schlüssel kompromittiert werden können, sind sie nützlich, denn meistens sind sie nicht kompromittiert. Gehen wir einfach mal davon aus. :-) Das liegt natürlich auch daran, dass Schlüssel bisher wenig verbreitet sind und es sich noch nicht lohnt, gezielt Jagd auf sie zu machen.

Sicherheit schafft man dadurch, dass man den Schutz der Schlüssel ihrer Bedeutung anpasst. Schlüssel, die triviale Absenderfälschungen bei E-Mails verhindern sollen (als Spamschutz), muss man nicht aufwendig schützen. Auch schlecht geschützte Schlüssel stellen für viele Störenfriede eine quasi unüberwindliche Hürde dar.

Schutz der Wichtigkeit anpassen

Wirklich wichtige Aktionen sind normalerweise selten; deshalb kann man ihren Aufwand erhöhen und dadurch den Schutz verbessern. Das mag die Signierung wichtiger Verträge oder die Zertifizierung eines Schlüssels (eines eigenen Unterschlüssels oder des Hauptschlüssels von jemand anderem) sein. Dafür kann man dann ein sicheres System booten (etwa Knoppix ohne Hardware für einen Internetzugang, also Netzwerkkabel raus) und nur auf diesem den wertvollen Schlüssel verwenden.

nichtautorisierte Signaturen

Den eigenen Schlüssel zu schützen ist nicht das einzige Problem. Man will außerdem, dass keine nichtautorisierten Signaturen erzeugt werden und ebensolche Entschlüsselungen stattfinden. Wie kann das passieren, ohne dass einem der Schlüssel geklaut wird? Auf zweierlei Art:

  1. unbemerkte Nutzung sicherer Schlüssel

    Wenn man eine Smartcard verwendet, kommt der Angreifer zwar nicht an den Schlüssel selber heran, aber er kann ihn benutzen, wenn er die Kontrolle über den Rechner hat. Solange die Smartcard im Leser steckt, entschlüsselt sie (die g10-Smartcard 2.0) munter alles, was man ihr vorwirft. Für Signaturen kann man dies unterbinden.

  2. Unterschieben von Daten

    Man weiß ja bei komplexen dokumenten letztlich nicht, was man signiert. Man hat eine Datei, etwa ein Office-Dokument. Man will wissen, was man signiert und öffnet die Datei deshalb mit der Office-Software. Wenn der Rechner kompromittiert ist (was auch erst durch das Öffnen der Datei passieren kann!), dann hat man nicht mehr die Gewissheit, dass einem auch das angezeigt wird, was in dem Dokument steht. Für Angriffe auf einzelne Opfer kann man Virenscanner leicht überwinden. Ein cleverer Angreifer würde dann noch die Schaddatei gegen eine harmlose mit dem gewünschten Inhalt austauschen, so dass man (jedenfalls mit der erzeugten Signatur) nicht einmal nachweisen kann, dass einem eine manipulierte Datei vorgelegt wurde. Auch gegen so etwas kann man sich schützen: Erst signieren, Signatur vom Rechner entfernen, dann erst die Datei öffnen. Und dann noch mal von der DVD booten und ein anderes Programm zur Anzeige verwenden (rettet einen nicht, wenn beide Programme den angegriffenen Code gemeinsam nutzen, etwa beim Umgang mit Bildern). Und dann auf sichere Weise die Signatur zerstören, wenn einem der angezeigte Dateiinhalt nicht gefällt. Dies mag an den Haaren herbeigezogen erscheinen. Es soll aber auch nur für das Problem sensibilisieren, dass echte Sicherheit auch mit großem Aufwand kaum zu bekommen ist.

    Auf einem kompromittierten System muss der Angreifer sich nicht mal die Mühe machen, die komplizierte Office-Software zu manipulieren. Es reicht, dass er andere Daten an die Smartcard schickt, als angezeigt werden. Beim Onlinebanking gibt es als Schutz davor Kartenleser mit Display. Das funktioniert aber nur deshalb, weil sich der Inhalt von Kontotransaktionen mit wenig Text komplett darstellen lässt. Das ist nicht einmal bei längeren Textdateien praktikabel.

Offline-Hauptschlüssel

Die einzelnen Teile eines Schlüssels sind zudem nicht gleich wichtig. Den größten Schaden kann man mit den Hauptschlüsseln anrichten, weil man damit neue Schlüssel (sowohl Unterschlüssel als auch Schlüssel anderer) signieren kann. Wenn andere den eigenen Schlüssel verifizieren (Fingerprintvergleich), bezieht sich das nur auf den Hauptschlüssel.

Der Offline-Hauptschlüssel wird im Alltag nicht für Signaturen oder Entschlüsselung genutzt; das machen die Unterschlüssel. Wenn es sich um einen normalen Schlüssel handelt, dann werden die Unterschlüssel zwangsläufig in vergleichsweise unsicheren Umgebungen eingesetzt. Der Offline-Hauptschlüssel kann deswegen ein sehr viel höheres Sicherheitsniveau haben. Man kann auf diese Weise mit demselben Schlüssel Daten sowohl mit hoher als auch mit reduzierter Sicherheit bearbeiten (siehe wie man Schlüssel direkt adressiert). Das bringt natürlich nur dann etwas, wenn die Kommunikationspartner das auch wissen und begreifen (also Haupt- von Unterschlüsselsignaturen unterscheiden können); die Vereinfachung, nur einen Schlüssel zu benötigen, geht mit einem gewissen Potential an Verwirrung einher, was bei sicherheitsrelevanter Software immer heikel ist.

Auf jeden Fall sinnvoll bei einem Schlüssel für normale Arbeitsumgebungen ist ein Offline-Hauptschlüssel mit Signaturfähigkeit. Der kann dann nämlich verwendet werden, um die Richtlinien für den Schlüssel zu signieren (so dass diese sensible Information nicht durch das geringe Sicherheitsniveau der Unterschlüssel kompromittiert wird); und an dieser Stelle kann man die Problematik und die technischen Aspekte erklären. Bei Schlüsseln, die generell nur in einer Hochsicherheitsumgebung eingesetzt werden, bringt eine Differenzierung zwischen Haupt- und Unterschlüssel nichts. Dementsprechend ist in dem Fall nicht wichtig, welche Fähigkeiten der Hauptschlüssel hat. Man kann ihn dann aufs Zertifizieren beschränken.

Aus diesem Umstand empfehle ich jedem dringend, die Hauptschlüssel nicht in derselben Weise wie die Unterschlüssel zu speichern. Das kann, muss aber nicht eine externe Speicherung (USB-Stick) sein; eine sicher verschlüsselte Datei auf einem unsicheren Speichermedium tut es auch. Sicher verschlüsselt heißt in diesem Fall, dass der Schlüssel nur dann verwendet, die sichere Passphrase nur dann eingegeben wird, wenn man ein sicheres System gebootet hat (z.B. von DVD). Auf diese Weise kann man den eigenen Zertifizierungen ein viel höheres Sicherheitsniveau ermöglichen als den eigenen Unterschlüsseln. Insbesondere sollte das Web of Trust idealerweise nur Zertifizierungen von sicheren Hauptschlüsseln verwenden...

Die Erklärung der einzelnen Schritte folgt am Ende des Codeblocks. Normalerweise sollte man nicht mehr die folgende Anleitung zur Erzeugung von Offline-Hauptschlüsseln nutzen, sondern diese Scriptsammlung.

start cmd:> gpg --list-secret-keys 0xeccb5814
Schlüsselbund: /home/hl/.gnupg/secring.gpg
-------------------------------------------
sec   1024D/0xECCB5814 2005-09-05
uid                    Hauke Laging <hauke@laging.de>
ssb   2048g/0xE623EF88 2005-09-05 [verfällt: 2010-04-03]
ssb   2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]
ssb   2048R/0x3A403251 2010-03-04 [verfällt: 2013-03-03]
ssb   2048R/0x2282921E 2010-03-08 [verfällt: 2013-03-07]


start cmd:> gpg --armor --export-secret-keys 0xeccb5814 > 0xECCB5814.sec.asc

start cmd:> gpg --armor --export-secret-subkeys 0xeccb5814 > 0xECCB5814.ssk.asc

start cmd:> gpg --delete-secret-key 0xeccb5814
gpg (GnuPG) 2.0.15; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


sec  1024D/0xECCB5814 2005-09-05 Hauke Laging <hauke@laging.de>

Diesen Schlüssel aus dem Schlüsselbund löschen? (j/N) j
Dies ist ein privater Schlüssel! - Wirklich löschen? (j/N) j

start cmd:> gpg --list-secret-keys 0xeccb5814
gpg: error reading key: Kein geheimer Schlüssel

# Kommando beendet sich mit exit code 2

start cmd:> gpg --list-keys 0xeccb5814
Schlüsselbund: /home/hl/.gnupg/pubring.gpg
-------------------------------------------
pub   1024D/0xECCB5814 2005-09-05
uid                    Hauke Laging <hauke@laging.de>
sub   2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]
sub   2048R/0x3A403251 2010-03-04 [verfällt: 2013-03-03]
sub   2048R/0x2282921E 2010-03-08 [verfällt: 2013-03-07]


start cmd:> gpg --import 0xECCB5814.ssk.asc
gpg: Schlüssel 0xECCB5814: geheimer Schlüssel importiert
gpg: Schlüssel 0xECCB5814: "Hauke Laging <hauke@laging.de>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1
gpg:              gelesene geheime Schlüssel: 1
gpg:            geheime Schlüssel importiert: 1

start cmd:> gpg --list-secret-keys 0xeccb5814
Schlüsselbund: /home/hl/.gnupg/secring.gpg
-------------------------------------------
sec#  1024D/0xECCB5814 2005-09-05
uid                    Hauke Laging <hauke@laging.de>
ssb   2048g/0xE623EF88 2005-09-05 [verfällt: 2010-04-03]
ssb   2048R/0x51B279FA 2010-03-04 [verfällt: 2013-03-03]
ssb   2048R/0x3A403251 2010-03-04 [verfällt: 2013-03-03]
ssb   2048R/0x2282921E 2010-03-08 [verfällt: 2013-03-07]

Erklärung

  1. gpg --list-secret-keys 0xeccb5814

    Status quo angucken. Wichtig ist das sec. Es steht kein # dahinter; das bedeutet, dass der geheime Schlüssel wirklich verfügbar ist.

  2. gpg --armor --export-secret-keys 0xeccb5814 > 0xECCB5814.sec.asc

    Alle geheimen Schlüssel (Hauptschlüssel und Unterschlüssel) in eine Datei exportieren. Wenn diese Datei nicht auf einem sicheren Laufwerk (USB-Stick exklusiv für diesen Zweck oder ein sicher verschlüsseltes Laufwerk) liegt, sondern auf dem Rechner, dann sollte sie anschließend sicher gelöscht (idealerweise mit z.B. wipe überschrieben) werden. Es sei denn, der Schlüssel hat vor dem Export eine Passphrase bekommen, die unknackbar ist (was natürlich auch für die Lagerung auf einem USB-Stick keine schlechte Idee ist).

  3. gpg --armor --export-secret-subkeys 0xeccb5814 > 0xECCB5814.ssk.asc

    Nur die Unterschlüssel exportieren. Hinweis: Diese Datei kann nur von neueren gpg-Versionen (ich weiß leider nicht, ab welcher) importiert werden und wohl nicht von anderen OpenPGP-Programmen.

  4. gpg --delete-secret-key 0xeccb5814

    Alle geheimen Schlüssel (also den des Hauptschlüssels und die der Unterschlüssel) im normalen keyring löschen.

  5. gpg --list-secret-keys 0xeccb5814

    Nachgucken.

  6. gpg --list-keys 0xeccb5814

    Öffentliche Schlüssel sind noch da.

  7. gpg --import 0xECCB5814.ssk.asc

    Die geheimen Unterschlüssel (ohne den Hauptschlüssel) in den normalen keyring importieren.

  8. gpg --list-secret-keys 0xeccb5814

    Da sind sie. Das sec# zeigt an, dass der Hauptschlüssel nicht zur Verfügung steht. ssb> würde übrigens anzeigen, dass der Unterschlüssel auf einer Smartcard ist.

Ownertrust-Anpassung

Wenn man einen Schlüssel generiert, setzt GnuPG den ownertrust dieses Schlüssels automatisch auf absolut (ultimate), damit er automatisch als gültig betrachtet wird und auch alle Schlüssel, die von ihm beglaubigt werden, als gültig angesehen werden. Sollte dieser Schlüssel für spezielle Zwecke verwendet werden und deshalb eher unsicher sein, sollte man den Wert auf vollständiges Vertrauen herabsetzen.

Wenn man einen geheimen Schlüssel aber nur importiert, ändert sich der ownertrust nicht! Im Fall eines Offline-Hauptschlüssels muss man also nach dem Importieren den ownertrust selber auf absolut (ultimate) setzen (mittels --edit-key trust oder --trusted-key).

Um Schlüssel zu signieren oder den eigenen Schlüssel zu verändern (z.B. Unterschlüssel oder UIDs hinzuzufügen oder zurückzuziehen), muss die Datei mit dem privaten Hauptschlüssel (0xECCB5814.sec.asc) importiert (oder mittels --no-default-keyring --secret-keyring direkt als Keyring verwendet) werden. Das sollte aber nur von einem sicheren System (DVD) aus geschehen. Und natürlich muss der Hauptschlüssel danach wieder gelöscht werden (wenn man von einer CD/DVD bootet, erledigt sich das von selbst, weil der Schlüssel dann nur im RAM gespeichert wird). Oftmals wird man den Offline-Hauptschlüssel mit einer fiesen Passphrase gesichert haben. Es bietet sich deshalb an, wenn man den Hauptschlüssel für mehrere Operationen genötigt, nach dem Import in einem sicheren System mittels gpg --edit-key 0xeccb5814 passwd die Passphrase auf etwas Gut-Handhabbares zu ändern; sonst ist man schnell genervt.

Was ist ein sicheres System?

Es wurde schon mehrfach angesprochen, dass bestimmte Operationen nur innerhalb eines sicheren Systems stattfinden sollen. Aber was ist das überhaupt, ein sicheres System? Diese Frage hat nicht speziell mit GnuPG zu tun, und man kann wahrscheinlich regelrecht eine Wissenschaft daraus machen.

Klar dürfte sein, dass dies eine vertrauenswürdige Softwareinstallation erfordert, die zudem nur so lange als sicher angesehen werden kann, wie sie keinen Angriffsmöglichkeiten ausgesetzt ist. Eine vertrauenswürdige Installation erfordert eine sichere oder überprüfbare Quelle. Ohne Überprüfung als sicher ansehen kann man die von den Herstellern gelieferten CDs/DVDs. Das gilt, was selten genug vorkommt, gleichermaßen für Windows und Linux. Allerdings kann man Windows aus diesen Quellen erst mal nur installieren, und für diesen Zweck wird wohl niemand eine Windows-Lizenz verbraten wollen. Außerdem ist in einer Windows-Installation im Gegensatz zu einer Linux-Installation GnuPG nicht enthalten. Es gibt zwar auch Windows als Live-CD, aber dann hat man gleich wieder das Problem der Vertrauenswürdigkeit der Software.

Praktisch bieten sich diese Möglichkeiten an:

  1. Man nutzt das Live-System oder Rettungssystem auf Hersteller-Medien (bei openSUSE gibt es dafür eine eigene DVD). Vermutlich ist es bei den meisten Distributionen alternativ möglich, die Installationsmedien dafür zu missbrauchen (also ohne eigentliche Installation).

  2. Wenn man einen Rechner über hat, den man nicht für andere Zwecke benötigt (z.B. einen alten Rechner), kann man sich ein Betriebssystem (sinnvollerweise Linux o.Ä.) installieren. Für diesen Rechner gilt dasselbe wie für die Bootmedien: Sicher ist er nur, solange er physikalisch sicher ist, also niemand den Rechner manipulieren oder die Medien austauschen kann. Das heißt auch, dass kein Netzwerkzugriff auf den Rechner möglich sein sollte. Ob das heißt, dass man das Netzwerkkabel zieht, oder nur, dass der Rechner nicht auf Anfragen reagiert, ist eine Frage der persönlichen Paranoia.

  3. Man nutzt eine Download-Distribution, deren Integrität man prüfen kann. Möglich ist das z.B. bei Knoppix, denn in der c’t ist der Fingerprint des Heise-Zertifizierungsschlüssels abgedruckt, der wiederum den Schlüssel zertifiziert hat, mit dem Knoppix signiert wird. Man braucht sich also nur mal eine c’t zu kaufen (oder im Laden den Fingerprint zu prüfen), den Knoppix-Schlüssel in einem sicheren System zu importieren und dort dann das Knoppix-Image oder die gebrannte CD zu prüfen. Wegen des rekursiven Elements ersetzt diese Varianten die vorigen nicht komplett, aber es mag vorteilhaft sein, als Alternative zu den Herstellermedien auch ein verifiziertes Knoppix zu haben. Wenn ich GnuPG-Schulungen halte, verteile ich dort Knoppix-CDs.

    Wie man Schritt für Schritt die Authentizität einer Knoppix-CD prüft, habe ich auf einer eigenen Seite auf www.openpgp-schulungen.de erklärt.

Wenn das System dann erst mal läuft, ist es nur so lange sicher, bis man es mit potentiell schädlichen Daten in Kontakt bringt. Das tut man z.B., wenn man komplexe Netzwerksoftware (Browser, Mailclient, Instant-Messenger) nutzt oder von lokalen Speichermedien komplexe Dokumente (PDF, Office-Dateien, HTML-Dokumente, die z.B. Bilder einbinden) lädt. Man kann mit allerlei Tricks dafür sorgen, dass es sehr schwierig für eine Schadsoftware wird, das ganze System (andere Benutzeraccounts, Kernel) in Mitleidenschaft zu ziehen, aber das ist anspruchsvoll und kann hier nicht erklärt werden.

Smartcards

Smartcards sind ein weitgehend sicherer Schutz für Schlüssel. Eine Smartcard ist ein kleiner Computer. Man schreibt den Schlüssel rein, aber sie rückt ihn nicht mehr heraus. Man kann den Schlüssel nur noch über die Smartcard verwenden. Entsprechend sicher (sowohl im Sinne von Verfügbarkeit als auch im Sinne von Schutz) sollte man das Backup des Schlüssels verwahren, sofern man eins gemacht hat (ansonsten hat man bei einem Defekt der Smartcard verloren).

Siehe das Smartcard-Howto für Details (insbesondere für die Smartcard-Kommandos und die udev-Konfiguration).

gpg (bzw. gpg-agent/scdaemon) schreibt die zu signierenden (Hash) oder zu entschlüsselnden (Sessionkey) Daten in die Smartcard und sie liefert das Ergebnis zurück. Wenn man an die Schlüssel heranwill, muss man die Smartcard mit einer Art Elektronenmikroskop zerlegen. Das kostet angeblich einen siebenstelligen Betrag.

Smartcards schützen die Schlüssel vor unbefugter Verwendung dadurch, dass man nach jedem "Einschalten" der Smartcard (auch konfigurierbar: bei jeder Signatur) eine PIN eingeben muss. Nach drei Fehlversuchen braucht man die Admin-PIN. Nach drei Fehlversuchen für diese sperrt sich die Karte und kann nur durch einen Reset auf ihre Standardwerte (also ein Löschen der Schlüssel) wieder verwendet werden.

Hohe Sicherheit entsteht nur dann, wenn man die PIN konsequent nur am Kartenleser eingibt und nicht am PC, denn der PC könnte kompromittiert sein, ein Angreifer könnte die PIN mitlesen. Das Setzen der PIN ist leider bisher nicht über einen Kartenleser möglich, sondern nur über den PC. Paranoide sollten deshalb für das Setzen der PIN (und natürlich auch der Admin-PIN) von einem sicheren Medium booten.

Smardcards erlauben den schmerzarmen Einsatz von Schlüsseln in unsicheren Umgebungen. Allerdings muss man sich darüber im Klaren sein, dass nur der Schlüssel selber geschützt wird; sein Missbrauch wird nicht allein durch die Verwendung einer Smartcard unterbunden.

Sobald die Smartcard einmal verwendet wurde, kann ein beliebiges Programm, das mit denselben Rechten (also normalen Benutzerrechten) läuft, beliebige Daten entschlüsseln und signieren lassen. Das bekommt man nicht einmal mit, außer vielleicht durch das Blinken am Kartenleser (und auch das wird schwierig, wenn der Zugriff des Angreifers unmittelbar nach dem eigenen erfolgt). Abschalten lässt sich nur die Signierung ohne Eingabe der PIN. Man kann allerdings nach jeder Verwendung die Karte aus dem Kartenleser ziehen. Zumindest bei einem Kartenleser mit PIN-Pad muss dann auch für Entschlüsselung die PIN erneut eingegeben werden. Das ist aber auch kein sicherer Schutz vor Missbrauch, dafür ist das nicht schnell genug möglich.

Man sollte sich außerdem davor hüten, Smartcards mit privaten Hauptschlüsseln an unsicheren Rechnern zu verwenden, denn damit kann ein Angreifer viel größeren Schaden anrichten: Er kann neue Unterschlüssel erzeugen (deren privaten Teil er dann kennt) und bestehende Zurückziehen (revoke).

Verwendung der Smartcard

Damit man eine Smartcard verwenden kann, muss gpg Lese- und Schreibrecht für den Kartenleser haben (das erreicht man per udev). Eine neue Karte muss erst mal mit einem Schlüssel versehen werden. Man kann sowohl einen bestehenden privaten Schlüssel auf eine Smartcard kopieren als auch einen neuen Schlüssel auf der Smartcard generieren lassen (nur bei dieser Gelegenheit ist es möglich, den Schlüssel von der Karte auszulesen, um ein Backup anzulegen). Beides erfolgt über das Kommando --edit-key

verfügbare Hardware

Man kann derzeit mindestens eine Sorte Smartcard mit GnuPG (für OpenPGP-Schlüssel) verwenden, nämlich die g10-Smartcard / OpenPGP card (von der eine spezielle Version an FSFE-Mitglieder ausgegeben wird). Kaufen kann man sie hier (ein dazu passendes Lesegerät). GnuPG unterstützt Kartenleser (mit und ohne PIN-Pad) nach den Standards CCID (Chip Card Interface Description) und PC/SC (Personal computer/Smart Card). Es gibt die Smartcard-Hardware auch mit USB-Anschluss (aber ohne PIN-Pad), so dass man keinen Kartenleser mit sich herumschleppen muss. PKCS11-Karten funktionieren nur mit einer (zumindest in einer früheren Version lizenzrechtlich fragwürdigen) Zusatzsoftware, die nicht von den GnuPG-Entwicklern ist.

Die Karten gibt es für etwa 15 €, einen Kartenleser mit PIN-Pad für etwa 50 €. Auch der Cryptostick kostet etwa 50 €.

Bedeutung von Signaturen: technische und organisatorische Maßnahmen

die größte Lücke ist das Missverständnis

Die technischen Probleme beim Schutz von Schlüsseln wurden schon erwähnt. In der Praxis mindestens gleichbedeutend ist aber das Verständnisproblem. Man kann Schlüssel zertifizieren und Daten signieren und verschlüsseln. Aber das ist ja nur Technik. Was bedeutet das? Wenn man mit verschlüsselten oder signierten Daten konfrontiert wird, hat man demgegenüber irgendeine Haltung. Auch wenn man selber Daten verschlüsselt oder signiert, verbindet man damit eine Änderung der Haltung ihnen gegenüber. Man muss an dieser Stelle sehr aufpassen, keine falschen Schlüsse zu ziehen.

Was bedeutet eine Signatur?

Eine Signatur bedeutet erst mal nur, dass jemand Zugriff auf den zugehörigen geheimen Schlüssel hatte und sich entschieden hat, ihn zu benutzen, sowie dass die signierten Daten nicht verändert wurden.

Die beiden wichtigsten Fragen in diesem Zusammenhang sind:

  1. Wie sicher verwahrt der Besitzer seinen Schlüssel? Dazu gehört auch: Wie sicher ist die Umgebung, in der er ihn einsetzt?

  2. Was will er mit seiner Signatur aussagen?

Es hat wenig Sinn, die eigenen Gewohnheiten auf andere zu übertragen, denn es gibt keinen allgemeinen Konsens über den Einsatz von Schlüsseln. Für rechtsgültige digitale Unterschriften gibt es eine klare Vorgabe (Namen druntersetzen (was immer das heißen mag), qualifizierte Signatur erzeugen), aber für den Einsatz von OpenPGP ist das unerheblich, da damit auf absehbare Zeit keine qualifizierten Signaturen erzeugt werden können.

Wenn man einer Signatur vertraut, dann vertraut man

  1. dem Willen des Unterzeichners, seinen Schlüssel und seine Signaturen ordentlich zu handhaben

  2. dem gemeinsamen Verständnis, was in der fraglichen Situation ordentlich ist

  3. seiner technischen Kompetenz, das zu tun

  4. seiner Disziplin (und im Moment der Unterschrift vorhandenen Hard- und Software-Ausstattung), das zu tun

  5. und der technischen Sicherheit des Signatursystems (typischerweise das kleinste Problem).

Signaturhäufigkeit

Es gibt Leute (wie den Autor dieses Textes), die fast alles signieren, was sie so verfassen und verschicken. Das hat, nach Meinung erfahrener OpenPGP-Nutzer, aber auch Nachteile. Das Argument ist, dass damit eine Allerwelts-E-Mail eine Bedeutung bekomme, die sie typischerweise nicht habe. Diese Fraktion signiert nur solche Dokumente, deren Bedeutung dadurch herausgehoben werden soll, und das auch nur nach entsprechend sorgfältiger Prüfung. Wenn man sich dieses Problems bewusst ist, kommt man zum nächsten: Woher soll man wissen, in welche Gruppe jemand fällt?

Sicherheit des Schlüssels

In engem Zusammenhang mit dem Einsatzzweck eines Schlüssels steht seine Sicherheit. Ein Schlüssel, der sehr oft verwendet wird, ist natürgemäß im allgemeinen weniger sicher als einer, der nur selten und gezielt eingesetzt wird. Wenn ich alle meine E-Mails signiere, dann muss ich den Schlüssel auf dem System verfügbar (oder jedenfalls von diesem System aus zugänglich) haben, auf dem ich Mails schreibe. Das ist üblicherweise das System, auf dem man Mails liest. Das stellt eine relevante obere Grenze für die Sicherheit dar. Selbst die Verwendung einer Smartcard rettet einen dabei nicht, weil die nur verhindert, dass einem der Schlüssel geklaut wird, nicht aber, dass man andere Daten signiert, als man signieren möchte. Das kann einem allerdings immer noch auffallen, wenn man den nötigen Aufwand treibt.

Wenn man Signaturen erzeugen will, die wirklich verlässlich sein sollen, dann sollte man sich mehrere Schlüssel zulegen, damit man einen auf die Erzeugung verlässlicher Signaturen beschränken und entsprechend besser schützen kann. Wie schützt man einen Schlüssel (oder besser, weiter gehend: die Verlässlichkeit einer Signatur)?

  1. Man schützt den Schlüssel selber.

    Das heißt, man verwahrt ihn auf Offlinemedien, idealerweise auf einer Smartcard. Man schützt ihn mit einer guten Passphrase (und vielen Iterationen, siehe -s2k-count).

  2. Man setzt den Schlüssel nur auf einem sicheren System ein.

    Also etwa einem von DVD gebooteten System. Dieses Spiel kann man immer weiter treiben: Woher bekommt man ein sicheres Bootmedium? Wie stellt man sicher, dass dieses Medium nicht manipuliert/ausgetauscht wurde? Kann man der Hardware vertrauen? Das größte Risiko diesbezüglich dürfte sein, dass Tastatureingaben mitgelesen (und gespeichert) werden.

  3. Man signiert nur "ungefährliche" Daten.

    Wir signieren vom Verständnis her nicht in erster Linie eine Datei. Was interessiert uns eine Datei? Wir signieren das, was uns am Bildschirm angezeigt oder ausgedruckt wird; also das, was wir für den Inhalt der Datei halten. Wenn das System, auf dem die Datei angezeigt wird, kompromittiert ist, haben wir keine Kontrolle darüber, was wir signieren. Selbst ohne Softwareangriffe kann es zu Problemen kommen. Komplexe Dokumente können auf unterschiedliche Art angezeigt werden. Notizen in einer Textverarbeitung werden nicht angezeigt oder nicht beachtet. Makros sind womöglich deaktiviert, verändern aber den Inhalt. Browser stellen komplizierte Webseiten unterschiedlich dar, binden in der Anzeige womöglich externe Inhalte ein (die nicht signiert werden, sondern nur der Verweis auf sie). Außer bei Softwareangriffen sollten diese Probleme allerdings reproduzierbar sein, so dass man sich hinterher immer noch aussichtsreich darüber streiten kann, was man denn nun eigentlich unterschrieben hat.

    Wenn man paranoid ist, erzeugt man brisante Signaturen nur auf einem von einem sicheren Medium gebooteten System, das (hardwaremäßig!) keinerlei Netzzugang hat. Wenn es um komplexe Dokumente geht (also um solche, die man sich nicht nur mit einem Editor in der Konsole anschaut), dann erzeugt man als erstes die Signatur, speichert die aber nicht in dem System, sondern auf einem Medium, das man dann von dem System trennt; etwa einem USB-Stick. Diese Signatur kann man für den Fall der Fälle natürlich auch verschlüsseln. ;-) Danach schaut man sich das Dokument an und entscheidet, ob man es signieren will. Diese Sichtung führt man dann am besten mit unterschiedlicher Software auf unterschiedlichen Systemen durch. Natürlich immer nur nach dem Booten von einem sicheren Medium... Möglich ist auch, den Inhalt des Dokuments in ein zweites, nach Möglichkeit technisch einfacheres Dokument zu kopieren (also etwa in eine Textdatei) und nur beides zusammen zu signieren, damit man auf die sichere Variante verweisen kann. Was der Empfänger davon hält, ist natürlich eine andere Frage. Grundsätzlich erscheint es sinnvoll, bedeutsame Dokumente, die signiert werden sollen, in einem einfachen Format zu erstellen (z.B. HTML ohne Code).

Vermeidung von Missverständissen: klare Ansage per Schlüsselrichtlinie (key policy)

Man kann Fehleinschätzungen leicht dadurch vermeiden, dass man für jeden erkennbar macht, was der eigene Maßstab ist (für jeden Schlüssel einzeln). Schlüsselrichtlinien können sehr unterschiedlich umfangreich sein. Eine reduzierte ist besser als gar keine. Man sollte deshalb (idealerweise schon vor der Schlüsselerzeugung, das macht es für einen selber einfacher, die Richtlinie durchzuhalten) folgendes aufschreiben:

Diese Richtlinie veröffentlicht man dann im Internet. Das hat natürlich nur dann einen Wert, wenn man sie auch signiert. Man kann die Signatur mit einem Ablaufdatum versehen (--ask-sig-expire); das mag hilfreich sein, wenn man irgendwann merkt, dass man in seiner Richtlinie dummes Zeug oder Missverständliches geschrieben hat und diejenigen, die wegen der policy URL auf dieses Dokument stoßen, technisch sicher auf diese Problematik hinweisen will. Auf keinen Fall sollte man die Richtlinie "unbemerkt" ändern. Wenn man anders verfahren will als bisher, sollte man, anstatt die Richtlinie zu ändern, eine neue Richtlinie erstellen, darin die alte referenzieren, ggf. die Unterschiede zur Vorversion explizit benennen, diese unter einer anderen URL (z.B. mit einer höheren Versionsnummer in der URL) verfügbar machen und die policy URL anpassen. Dabei sollte man bedenken, dass sich die Sicherheit eines Schlüssels im Zeitablauf nur verringern kann und dass die Sicherheit des Schlüssels und der Verifizierungsaufwand in einem gesunden Verhältnis stehen sollten. Es bringt wenig, besonders gut zu prüfen, wenn man (nur) mit einem eher unsicheren Schlüssel zertifiziert.

Woher kennt man die Richtlinie eines Schlüssels? Man kann mit den Optionen --cert-policy-url und --sig-policy-url (für deren Anzeige man allerdings --list-options show-policy-urls bzw. --verify-options show-policy-urls benötigt, sinnvollerweise in der Konfigurationsdatei) die URL des Dokuments in die jeweilige Signatur schreiben.

Leider stehen im Normalfall Schlüssel und das Dokument der Richtlinie in einer Kreisbeziehung: Das Dokument behauptet, dass der Schlüssel hochsicher sei, und diese Behauptung wird nun mit der Signatur des Schlüssels abgesichert, der üblicherweise nur so sicher ist, wie das Dokument behauptet? Schwierig. Ein (zu recht) unsicherer Schlüssel könnte geklaut werden; damit könnte dann eine Schlüsselrichtlinie signiert werden, die behauptet, dass der Schlüssel quasi in einem Bankschließfach liege. Wie soll man dieses Problem lösen? Dadurch, dass die Richtlinie immer zusammen mit dem Schlüssel signiert wird. Man lässt sich nicht nur den Fingerprint des Schlüssels bestätigen, sondern auch den des Richtliniendokuments (z.B. mit gpg --print-md SHA1 policy.html, gerne auch mit einem besseren Hash oder gleich mehreren) und signiert es dann selber. Wenn man einen Schlüssel über das web-of-trust verifiziert und ihm mehr als ein minimales Sicherheitsniveau attestieren will, sollte man idealerweise von allen für die Verifizierung dieses Schlüssels benötigten Schlüsseln eine Signatur für die Richtlinie dieses Schlüssels haben. Das ist allerdings gegenwärtig Wunschdenken; kaum jemand hat eine Schlüsselrichtlinie, ganz zu schweigen von Drittsignaturen dafür. Die Drittsignaturen für die Richtlinie wären nicht erforderlich, wenn sie von einem Offline-Hauptschlüssel signiert ist. Die Frage ist dann natürlich: Woher soll man sicher wissen, dass es sich um einen Offline-Hauptschlüssel handelt?

Es gäbe übrigens die viel elegantere Möglichkeit, über standardisierte signature notations (--sig-notation und --cert-notation im Zusammenspiel mit --list-options show-notations bzw. --verify-options show-notations) die relevanten Angaben direkt in den Schlüssel bzw. die Signatur zu schreiben. Der Verfasser regt dies ebenso regelmäßig wie erfolglos auf der GnuPG-Mailingliste an. Der Haupteinwand scheint zu sein, dass sich ja auch heute schon niemand um die saubere Verifizierung von Schlüsseln und Signaturen kümmere, deshalb sei es schlecht investierter Aufwand, diesen Teil zu verbessern.

Verwendung von OpenPGP für E-Mail

E-Mail dürfte die mit Abstand häufigste (aktive) Verwendung von OpenPGP sein (passiv haben jedenfalls die Linuxer u.Ä. bei der Softwareverteilung (Onlineupdates) damit zu tun). Wie schmerzfrei das ist, hängt sehr davon ab, welches Mailprogramm man verwendet. Webmail kann man dafür mehr oder weniger vergessen.

Das größte Problem im Zusammenhang mit PGP und E-Mail ist der Dreck, den Microsoft unter dem Namen Outlook (in allen Variationen) unters Volk kippt und dreist als Mailprogramm bezeichnet. Aber da Windows grundsätzlich nicht von Privatanwender genutzt wird und auch Outlook nicht für diese Zielgruppe gedacht ist und sinnvolle Lösungen Microsoft sowieso widerstreben, unterstützt dieses tolle Produkt vom Marktführer auch nach inzwischen 13 Jahren immer noch nicht den für Privatanwender maßgeblichen Standard. Aber der ist ja in Open-Source-Software implementiert, damit kommt Microsoft halt nicht klar.

Richtig Glück hat, wer das KDE-Programm (Linux) KMail verwendet, denn dafür hat das BSI mal die GnuPG-Integration bezahlt. Für alle(?) anderen FOSS-Programme gibt es Add-ons, siehe meine Download-Linkliste. Hier gibt es Infos zu Thunderbird.

Das Hauptproblem ist, dass Outlook nicht einmal normale Textmails korrekt anzeigt, wenn sie signiert sind. Outlook hält dann den Text für ein Attachment. Und zeigt die eigentliche Signatur natürlich als zweites Attachment, was den normalen Empfänger verwirrt.

Inline-PGP vs. PGP/MIME

Es gibt zwei Möglichkeiten, PGP mit E-Mails zu verwenden, Inline-PGP und MIME. Inline-PGP schreibt das PGP-Drumherum in den normalen Mailtext. Für Benutzer von Mailprogrammen, die PGP nicht kennen, sieht das zwar komisch aus, aber sie haben direkten Zugriff auf den Text. Bei der Verwendung von MIME verstecken brauchbare Mailprogramme das PGP-Drumherum und zeigen z.B. durch Einfärbung an, welche Teile der Mail signiert und/oder verschlüsselt sind. Attachments kann man auf direktem Weg nur mit MIME verschicken. Natürlich kann man außerhalb eines Mailprogramms eine Datei verschlüsseln und/oder signieren und das Ergebnis per Mail verschicken. Möglich, aber (für beide Seiten) unkomfortabel.

Hier sind einige Probleme von Inline-PGP erläutert (allerdings auf Englisch).

Diese Seite ist noch nicht fertig.