Kurzfassung: Dies ist ein Schlüssel mit normalem Sicherheitsniveau (Alltagsschlüssel), aber einem Offline-Hauptschlüssel.
Version
Version 1, 02.10.2018, URL: https://www.barthm.net/openpgp/0x08E19EB0__policy.1.html
Identität des Schlüsseleigentümers
Martin Barth, geboren am 04.08.1974 in Freistadt, Österreich, wohnhaft ebenda
176 cm; mitteleuropäischer Typ
Beruf: IT Systemorganisator von Block-Storagesystemen, Storage Area Networks (SAN), Network Attached Storage (NetApp NAS) und Backup-Software (Spectrum Protect/TSM)
Bild
Lizenz
Diese Schlüsselrichtlinie darf, auch in Teilen oder verändert, übernommen werden.
Dieses Werk bzw. dieser Inhalt steht unter einer Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz. Konkretisierung: Namensnennung ist nicht erforderlich.
Zweck
Diese Richtlinie soll es denjenigen, die mit Signaturen (auch Zertifikaten für Schlüssel Dritter) von mir konfrontiert werden oder mir etwas verschlüsselt schicken wollen, die Einschätzung erleichtern, was von diesem Schlüssel zu halten ist.
Sicherheit
Die Sicherheit dieses Dokuments resultiert aus diesen Effekten:
Dieses Dokument ist von dem zugehörigen Schlüssel signiert, und zwar mit dem sicheren Offline-Hauptschlüssel, nicht mit dem üblicherweise für Signaturen verwendeten Unterschlüssel.
Ich lasse (in Zukunft) auch andere dieses Dokument signieren. Dies ist (oder wird später mal sein) die Datei mit den gesammelten Signaturen Dritter.
Die von mir erzeugten Signaturen und Zertifizierungen beinhalten eine policy URL, die auf die jeweils aktuelle Version dieses Dokuments verweist. Jede Version bekommt eine eigene URL. Die Version und URL werden außerdem oben in diesem Dokument genannt.
Dieses Dokument verlinkt zwar externe Inhalte, bindet aber keine ein. Die CSS-Formatierungen stehen alle in dieser Datei, die Bilder als data-URLs ebenfalls.
Dieses Dokument besteht (leicht überprüfbar) nur aus einfachem HTML (ohne aktive Elemente). Es kann auch mit einfachsten Browsern (Textbrowsern) und sogar mit Texteditoren u.Ä. gelesen werden.
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 je nach Anwendungsfall 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.
Dieser Schlüssel ist unter Berücksichtigung der Angaben und Verwendung der (vorher auf Integrität geprüften) Scripts von Hauke Laging von www.openpgp-schulungen.de 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.
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:
gpg: Signatur vom Mi 28 Aug 2013 19:21:54 CEST
gpg: mittels RSA-Schlüssel 0x123456788
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:
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:
: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.
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).
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.