Schlüsselrichtlinie für Fingerprint 1234 5678 1234 5678 1234 5678 1234 5678 1234 5678

Dies ist nur ein Entwurf! Im Quelltext alle FIXME suchen, um die Stellen zu finden, die auf jeden Fall angepasst werden müssen.

Kurzfassung: Dies ist ein Schlüssel mit normalem Sicherheitsniveau (Alltagsschlüssel), aber einem Offline-Hauptschlüssel.

über dieses Dokument

Zweck dieses Schlüssels

Sinn dieses Schlüssels ist es primär, das triviale Mitlesen oder Fälschen von E-Mails usw. zu unterbinden. Bedeutsame Aussagen (etwa Verträge) werde ich nicht (nur) mit diesem Schlüssel (d.h. einem Unterschlüssel) unterschreiben, sondern mit dem Hauptschlüssel oder einem anderen Schlüssel, der insgesamt ein höheres Sicherheitsniveau hat.

Sicherheit des Schlüssels

Erzeugung des Schlüssels

Dieser Schlüssel ist unter der Anleitung eines Experten auf einem System erzeugt worden, das von einem sicheren Medium gebootet wurde (z.B. gepresste Linux-DVD oder mittels der c't geprüftes Knoppix-Image) und auf nicht extra geprüfter, aber grundsätzlich vertrauenswürdiger Hardware lief. Der Hauptschlüssel ist mit einer (nach kryptografischen Maßstäben) sicheren Passphrase versehen worden, bevor er diese sichere Umgebung verlassen hat. Schutzmaßnahmen gegen TEMPEST-Angriffe (Mitlesen der Tastatureingaben durch Funkabstrahlung) wurden nicht ergriffen.

Verwendung des Hauptschlüssels

Der Hauptschlüssel wird nur in einer sicheren Umgebung (s.o.) verwendet. Seine Signaturen für andere Schlüssel oder Daten (wie dieses Dokument) sind deshalb sehr vertrauenswürdig. Schlüssel können nur mit dem Hauptschlüssel signiert werden. Bei der Prüfung einer Datensignatur ist es dagegen wichtig, erkennen zu können, ob die Signatur vom Haupt- oder einem Unterschlüssel erzeugt wurde, wenn man der Signatur das Sicherheitsniveau des Hauptschlüssels zurechnet:

Ausgabe von gpg --verify datei.asc
gpg: Signatur vom Mi 28 Aug 2013 19:21:54 CEST
gpg:                mittels RSA-Schlüssel 0x12345678
gpg: Korrekte Signatur von "Test User <test.user@example.org>"
gpg: Signatur vom Mi 28 Aug 2013 19:21:54 CEST
gpg:                mittels RSA-Schlüssel 0x87654321
gpg: Korrekte Signatur von "Test User <test.user@example.org>"

Mit gpg oder jeder anderen Schlüsselverwaltungssoftware kann man sich dann anzeigen lassen, dass 0x12345678 der Hauptschlüssel und 0x87654321 ein Signatur-Unterschlüssel ist. Man kann gpg aber auch etwas gesprächiger machen:

Ausgabe von gpg -v --verify datei.asc
Version: GnuPG v2.0.19 (GNU/Linux)
gpg: ASCII-Hülle: 
gpg: Signatur vom Mi 28 Aug 2013 19:21:54 CEST
gpg:                mittels RSA-Schlüssel 0x12345678
gpg: verwende Vertrauensmodell PGP
gpg: Korrekte Signatur von "Test User <test.user@example.org>"
Version: GnuPG v2.0.19 (GNU/Linux)
gpg: ASCII-Hülle: 
gpg: Signatur vom Mi 28 Aug 2013 19:22:13 CEST
gpg:                mittels RSA-Schlüssel 0x87654321
gpg: der Unterschlüssel 0x87654321 wird anstelle des Hauptschlüssels 0x12345678 verwendet
gpg: verwende Vertrauensmodell PGP
gpg: Korrekte Signatur von "Test User <test.user@example.org>"

Es ist möglich, für den Hauptschlüssel zu verschlüsseln. Derart verschlüsselte Daten sind sehr viel sicherer als solche, die für einen Unterschlüssel verschlüsselt wurden. Allerdings eignet sich dieses Vorgehen nicht für E-Mails, sondern nur für E-Mail-Anhänge, und vor allem muss man wissen, wie man eine Verschlüsselung für den Hauptschlüssel erzwingt, und darf dabei keine Fehler machen; also vor dem Versenden lieber einmal zu viel prüfen, ob die Verschlüsselung wie geplant verlaufen ist:

Ausgabe von gpg --list-only --list-packets file.asc
:pubkey enc packet: version 3, algo 1, keyid AAAAAAAA12345678
        data: [2047 bits]
:encrypted data packet:
        length: 445
        mdc_method: 2
:pubkey enc packet: version 3, algo 1, keyid FFFFFFFF87654321
        data: [2047 bits]
:encrypted data packet:
        length: 445
        mdc_method: 2

Im ersten Fall ist die long ID des Hauptschlüssels eingetragen, im zweiten die des Verschlüsselungs-Unterschlüssels. Ganz wichtig ist dabei auch, dass nicht versehentlich für weitere (weniger sichere) Schlüssel verschlüsselt wurde (etwa, weil man automatisch alles auch für den eigenen Schlüssel verschlüsseln lässt). Falls mehr als ein :pubkey enc packet:-Block vorhanden ist, sollte man sich das also ganz genau anschauen.

Sollte ich später über einen Schlüssel verfügen, der insgesamt ein hohes Sicherheitsniveau hat, wäre es auf jeden Fall einfacher und damit sicherer, für kritische Daten diesen zu verwenden.

Verwendung der Unterschlüssel

Die Unterschlüssel dienen dem alltäglichen Signieren und Entschlüsseln von Daten; sie werden auf einem normalen, also nicht besonders gesicherten System gespeichert und verwendet. Verschlüsselte Daten und Signaturen sind also nur so sicher wie dieses System, das von einem qualifizierten Angreifer sicherlich online zu knacken ist.

Ich bin derzeit noch OpenPGP-Anfänger. Das bringt gewisse Risiken mit sich, aber dadurch, dass ich den Hauptschlüssel sicher verwahre und nur in einer sicheren Umgebung (und im Zweifelsfall mit Unterstützung kompetenterer Leute) verwende, gefährdet meine geringe Kenntnis der Materie zumindest nicht den Kern des Schlüssels (die Verifizierung meines Fingerprints und meiner UIDs; meine Zertifizierungen anderer Schlüssel; die Integrität der Metadaten meiner Unterschlüssel (v.a. die Gültigkeitsdauer); die Integrität zukünftiger Unterschlüssel).

Zertifizierungen (Signaturen für Schlüssel)

Ich habe mich noch nicht für eine Zertifizierungsrichtlinie entschieden. Deshalb erzeuge ich noch keine Zertifizierungen für die Öffentlichkeit, nehme also noch nicht aktiv am Web of Trust teil. Sobald ich das nachgeholt habe, werde ich eine neue Version dieses Dokuments erstellen. Sollte in der Zwischenzeit jemand auf eine Schlüsselbeglaubigung von mir angewiesen sein (z.B. ist die Wahrscheinlichkeit hoch, dass ich die Schlüssel für mich zertifiziert habe, die meinen Schlüssel öffentlich zertifiziert haben), kann ich den Fingerprint und weitere Angaben gern auf andere Weise als eine formale Zertifizierung bestätigen.