English version below

Schlüsselrichtlinie für 0xNEU (Alltagsschlüssel)

über dieses Dokument

• Version

  Version 1, 03.10.2012, URL: http://www.hauke-laging.de/openpgp/policy__0xNEU.1.html

• Autor und Schlüsseleigentümer

  Hauke Laging, geboren am 21.03.1977 in Kiel

  knapp 1,90 m, blaue Augen, Rechtshänder

• Lizenz

  Diese Schlüsselrichtlinie darf, auch in Teilen oder verändert, übernommen werden. Ich möchte ausdrücklich dazu ermuntern.

  Dieses Werk bzw. 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 (insbesondere Zertifikaten für Schlüssel Dritter) von mir konfrontiert werden oder mir etwas verschlüsselt schicken wollen, die Einschätzung ermöglichen oder wenigstens im Rahmen des Mir-Möglichen erleichtern, was von dem verwendeten Schlüssel und seiner Sicherheit zu halten ist.

• Sicherheit

  Die Sicherheit dieses Dokuments resultiert aus diesen Effekten:

  1. Dieses Dokument ist von dem zugehörigen Schlüssel signiert, und zwar mit dem Offline-Hauptschlüssel, nicht mit dem üblicherweise für Signaturen verwendeten Unterschlüssel.

     Dass eine Signatur von einem Hauptschlüssel ist, kann man daran erkennen, dass zumindest das Konsolenprogramm gpg die ID des unterschreibenden Schlüssels anzeigt; ob die GUIs das auch tun, weiß ich nicht.

  2. Ich lasse diejenigen, die meinen Schlüssel zertifizieren, auch dieses Dokument signieren. Dies ist die Datei mit den gesammelten Signaturen Dritter, und dies ist meine Signatur dieser Datei. Es gibt keine technische Sicherheit dafür, dass keine manipulierte (alte) Version dieser Datei auf meiner Webseite liegt. Das kann aber schlimmstenfalls dazu führen, dass derjenige diesem Dokument nicht vertraut, also gewissermaßen DoS statt Sicherheitsloch. Dieses Problem könnte man dadurch reduzieren, dass ich die Sammeldatei in kurzen Abständen jeweils neu signiere (und womöglich sogar die Signaturen nach dieser Zeit ungültig werden lasse), aber dafür bin ich zu bequem.

  3. Ich verteile bei passender Gelegenheit kleine Zettel mit dem Fingerprint meines Schlüssels. Die enthalten auch den Fingerprint dieses Dokuments (bzw. der jeweils aktuellen Version davon).

  4. Dieses Dokument ist per policy URL in allen meinen Signaturen (sogar bei den E-Mails) verlinkt, also auch bei meinen Zertifikaten für die Schlüssel anderer. Dass gpg – warum auch immer – policy URLs standardmäßig nicht anzeigt (GUIs: GPA und Kleopatra versagen diesbezüglich, ausgerechnet KMail kriegt es hin, auch wenn man auf Details klicken muss) und deshalb die weitaus meisten OpenPGP-Verwender davon vermutlich nichts mitbekommen, steht auf einem anderen Blatt.

  5. Dieses Dokument verlinkt zwar externe Inhalte, bindet aber keine ein. Die CSS-Formatierungen stehen alle in dieser Datei, die Bilder als data-URLs ebenfalls.

• Änderungen

  Ich strebe an, diese Richtlinie nicht zu ändern. Es wäre sehr heikel, im nachhinein das Sicherheitsniveau eines Schlüssels zu ändern, egal in welche Richtung. Im Moment erscheint mir eine Überarbeitung meiner signature-notation-Liste als der wahrscheinlichste Grund für ein Update; denkbar wäre auch ein erklärender Text für das Zurückziehen des Schlüssels. Um sicherzugehen, dass man die richtige Version dieses Dokuments verwendet, ist die policy URL der jeweiligen Signatur mit der oben unter Version genannten URL zu vergleichen.

• weiterführende Informationen

  Umfangreiche Informationen zum Thema OpenPGP gibt es auf meiner Webseite.

über den Schlüssel

• Schlüsselerzeugung

  Der Schlüssel wurde am FIXME in einer sicheren Softwareumgebung erzeugt. Die Hardware war nicht gegen Manipulation oder z.B. TEMPEST-Angriffe geschützt. Die short ID des Schlüssels ist 0xNEU, der Fingerprint FIXME. Der Hauptschlüssel hat eine Länge von 4096 Bit, die Unterschlüssel von 2048. Alle Schlüssel sind RSA-Schlüssel.

  Der Schlüssel hat einen Offline-Hauptschlüssel, der gleich nach der Erzeugung sicher gespeichert wurde (d.h. mit einer sicheren Passphrase, die nur in einer sicheren Softwareumgebung eingegeben wird). Der Hauptschlüssel kann signieren, was von mir aber nur in speziellen Fällen (wie etwa für dieses Dokument) genutzt wird. Er kann auch entschlüsseln, was für den Fall gedacht ist, dass mir jemand wirklich vertrauliche Daten zukommen lassen will, aber keinen insgesamt sichereren Schlüssel von mir dafür verwenden kann. Das sollte nur in begründeten Fällen passieren, weil es etwas dauern kann, bis ich mir solche Daten ansehe.

• Sicherheit

  Die Unterschlüssel werden auf meinem normalen Arbeitsrechner für allerlei Alltagsaufgaben verwendet, insbesondere für das standardmäßige Signieren meiner E-Mails. Auf anderen Rechnern verwende ich die Unterschlüssel nur mittels Smartcard, und auch das nur auf halbwegs sicheren Systemen. Dieser Rechner dürfte weit weniger gefährdet sein als der Durchschnitt, aber er ist keine Burg.

  Bezüglich des Wertes von Signaturen und des Schutzes von Verschlüsselung ist also zu konstatieren: Man muss dafür meinen Rechner knacken. Für die meisten Fälle reicht das aus, aber "richtige" Verträge würde ich damit nicht unterzeichnen, und Informationen, bei deren Bekanntwerden echter Ärger droht, sollte man nicht für diesen Schlüssel verschlüsseln (die sollten sowieso nicht auf einem "normalen" Rechner entschlüsselt werden).

  Der Hauptschlüssel dagegen ist sehr sicher, ausreichend für alles unterhalb von Paranoia. Zertifikate dieses Schlüssels sind also jedenfalls auf der technischen Ebene sicher (man beachte aber die inhaltlichen Anmerkungen). Mit dem Hauptschlüssel würde ich auch Verträge unterzeichnen, und für ihn verschlüsselte Daten sind sicher (dabei aber keine Fehler machen!).

• Gültigkeit

  Ich begrenze die Gültigkeitsdauer des Hauptschlüssels und der Unterschlüssel auf etwa ein Jahr und verlängere sie gegebenenfalls.

• Zertifizierungskriterien

  Ich bin davon überzeugt, dass das Web of Trust nur dann einen Sinn hat, wenn man weiß, was von den Signaturen und den signierten Schlüsseln zu halten ist. OpenPGP stellt für ersteres bisher nur eine völlig schwammige (subjektive) und daher unbrauchbare Angabe zur Verfügung, für letzteres gar nichts. Es gibt die technische Möglichkeit, alle relevanten Informationen in einem Zertifikat unterzubringen, aber es gibt bisher keinerlei inhaltliche Standardisierung.

  Die Zertifizierungskriterien betreffen mehrere Aspekte:

  • Sicherheit der Identität der Person

    Dass jemand mir einen Personalausweis zeigt, sagt im Zweifelsfall mehr über kriminelle Energie als über die Identität der Person aus, denn ich würde einen gefälschten Ausweis vermutlich nicht als solchen erkennen, ganz zu schweigen von ausländischen Ausweisen. Natürlich ist die Überprüfung eines Ausweises immer noch besser als nichts. Ob das ausreicht, muss letztlich derjenige Entscheiden, der den von mir zertifizierten öffentlichen Schlüssel verwenden will. Ich trage jedenfalls über die unten beschriebenen signature notations ins Zertifikat ein, wie verlässlich ich die Identität der Person kenne.

  • User-IDs (UIDs)

    Bei OpenPGP werden nie rohe Schlüssel zertifiziert, sondern immer der öffentliche Schlüssel zusammen mit einer UID. Wenn ein Schlüssel mehrere UIDs hat, muss man ggf. für jede UID einzeln eine Signatur erzeugen. Aber was sagt diese UID aus? Minimal, dass man den Namen geprüft hat. Wenn denn ein richtiger Namen in der UID steht... (Im Signaturgesetz ist festgelegt, dass man qualifizierte Zertifikate auch für Pseudonyme bekommen kann!) Neben dem Namen kann eine klassisch aufgebaute UID noch eine E-Mail-Adresse und einen Kommentar enthalten; beides kann von großer Bedeutung sein (der Kommentar kann z.B. eine berufliche Position behaupten). Es ist deshalb relevant, ob das Zertifikat eine Aussage darüber macht, ob die E-Mail-Adresse oder der Kommentar korrekt ist. Auch die Art der Überprüfung ist nicht egal. Typischerweise wird die so realisiert, dass man das Zertifikat erzeugt (für jede UID einzeln), für den Schlüssel verschlüsselt und dann an die jeweilige E-Mail-Adresse schickt. Diese Art der Prüfung ist von ihrer Verlässlichkeit her aber nicht einmal ansatzweise mit der Sicherheit von Schlüsseln vergleichbar:

    • Die Zugangsdaten der Mailbox können geraten werden.

    • Der Mailserver kann gehackt werden.

    • Der Client des Empfängers kann gehackt werden.

    • Der Versand der Mail kann (falls unverschlüsselt) abgehört oder per man-in-the-middle-Angriff trotz Verschlüsselung gelesen werden (bei der Verschlüsselung des Mailversands spielt die Absicherung durch X-509-Zertifikate keine Rolle).

    • Die Mail kann durch einen Angriff auf den Versender (DNS spoofing) zum Angreifer umgeleitet werden.

    • Wenn die Mail einige Zeit beim Versender gespeichert wird (üblich, wenn ein normaler Mailclient zum Versand genutzt wird), kann der Angreifer sich das Zertifikat auch durch einen Hack des Versender-PCs besorgen, durch den er nicht automatisch auch den Hauptschlüssel unter seine Kontrolle bekommt. Durch so einen Angriff könnte er sich das Zertifikat wahrscheinlich auch ganz einfach aus dem Schlüsselbund der öffentlichen Schlüssel besorgen.

    • Und zu guter letzt, wie immer: Durch social engineering kann der Besitzer der E-Mail-Adresse dazu gebracht werden, die verschlüsselte Mail mit dem Zertifikat an den Angreifer weiterzuleiten.

  • certification level

  • Sicherheit der Identität des Schlüssels

    Eine andere Frage ist, wie man die Echtheit eines Schlüssels überprüft. Treffe ich den Besitzer und sagt oder gibt er mir den Fingerprint schriftlich? Würde er es merken, wenn er mir den falschen gäbe? ;-) (Ja, ich weiß meinen auswendig.) Oder haben wir nur telefoniert, was schwierig, aber nicht unmöglich zu fälschen ist? Auch das vermerke ich per signature notation.

  • Sicherheit des Schlüssels

    Die Sicherung der Identität sagt noch nichts über die Sicherheit des zertifizierten Schlüssels. Strenggenommen kann ich über die Sicherheit eines Schlüssels fast nichts Entscheidendes wissen, selbst wenn ich bei seiner Erzeugung dabei war, denn mit Ausnahme der Erzeugung des Schlüssels auf einer Smartcard ohne Backup kann jede Sicherheitsmaßnahme später unterlaufen werden (primär unabsichtlich). Ich kann nur wissen, was ein Schlüsseleigentümer mir über seine Verwendung des Schlüssels sagt, aber das ist schon mal viel wert, denn daran muss sich der Schlüsseleigentümer messen lassen.

  • Gültigkeit meiner Zertifikate

    Standardmäßig erzeuge ich Zertifikate, die unbegrenzt gültig sind. Auf Wunsch würde ich zeitlich begrenzte erzeugen. Das mag im Web of Trust eine last line of defense gegen mächtige Angriffe sein, die verhindern, dass jemand ein Rückzugszertifikat erhält. Bei Ablauf eines Zertifikats kann ich problemlos ein neues erzeugen. Aber wie lasse ich mir in über jeden Zweifel erhabener Weise bestätigen, dass der Schlüssel nicht kompromittiert ist, wenn ich seinen Eigentümer nicht persönlich treffen kann? ;-)

meine signature notations

Meine signature notations haben das Format ${bezeichner}@hauke-laging.de=${wert}. Der Namensraum ohne @domain ist solchen Bezeichnern vorbehalten, die vielleicht irgendwann einmal von der IETF standardisiert werden (bisher keine...). Es ist nichts dagegen einzuwenden, dass jemand meine kompletten notations (inklusive Domain) übernimmt.