Wer meine Serie zur Verschlüsselung verfolgt hat, hat es sicher an der einen oder anderen Stelle gemerkt: Gerade OpenPGP ist nicht immer die Benutzerfreundlichkeit in Person. Die Front-Ends wie Enigmail und vor allem GPGTools federn viel ab, können aber auch nicht alles ausmerzen, was im Design von OpenPGP hakt.

Dies betrifft vor allem die Schlüsselverwaltung. Ist man nur mit einem Rechner unterwegs, ist das alles noch gut zu verwalten. Sobald aber schon ein handy dazukommt, merkt man, dass das Synchronisieren der Schlüssel, die man hat, nur manuell geht, und das schließt nicht nur öffentliche Schlüssel von anderen, sondern auch Aktualisierungen des eigenen Schlüsselpaares (z.B. mit neuen E-Mail-Adressen) ein.

Ein weiteres Problem ist, dass gerade bei den viel verwendeten Schlüsselservern nicht kontrolliert werden kann, dass der Schlüssel, den man für einen Empfänger dort gerade gefunden hat, tatsächlich von diesem auch dort abgelegt wurde. Es ist durchaus möglich, dass ein Scherzbold im Namen einer anderen Person, deren E-Mail-Adresse er kennt, ein Schlüsselpaar erzeugt und den öffentlichen Schlüssel dann auf den Schlüsselserver hochlädt. OpenPGP fragt nicht ab, ob die E-Mail-Adresse tatsächlich gültig ist. Und der Schlüsselserver auch nicht.

Die Folge ist, dass ich als Absender vielleicht einen solchen gefälschten Schlüssel erwische, meinem E-Mail-Empfänger eine verschlüsselte Mail schicke, dieser sie aber nicht entschlüsseln kann. Warum nicht? Natürlich weil er den passenden geheimen Schlüssel zu diesem von mir verwendeten öffentlichen Schlüssel nicht besitzt. Für mich war aber in diesem Moment gar nicht feststellbar, dass der öffentliche Schlüssel nicht von ihm stammt. Klar hätte ich ihn in diesem Fall zunächst z. B. anrufen oder ihm eine unverschlüsselte Mail schicken sollen, um den Fingerabdruck oder wenigstens die acht- oder sechzehnstellige Schlüssel-ID zu vergleichen. Spätestens dann wäre uns aufgefallen, dass da ein falscher Schlüssel von ihm auf dem Server liegt.

Das alles ist aber verdammt umständlich. Es führt sogar dazu, dass Autoren wie der c’t-Redakteur Jürgen Schmidt im Editorial der c’t 6/2015 fordern, PGP sterben zu lassen. Als Beispiel nennt Herr Schmidt unter anderem Apple’s iMessage, welches einfach transparent ende zu ende verschlüsselt und der Anwender davon gar nichts mitbekommt. Herr Schmidt lässt aber die Frage offen, welche Alternativen er denn sieht. Denn eine Neuentwicklung wäre zwar wünschenswert, aber bis die marktreif ist, vergehen wieder mehrere Jahre, im schlimmsten Fall.

Und was macht man in der Zwischenzeit? S/MIME ist gerade nach dem Lenovo-Skandal mit der Werbe- und Schadsoftware Superfish keine wirklich vertrauenswürdige Alternative, weil dieses auf demselben todkranken Prinzip der Zertifikatsverkettung aufbaut, auf dem auch SSL fußt. Wer sich irgendwie als CA, (Certificate Authority oder zertifikatsautorität) ausweist und es in die Liste der Browser oder des Betriebssystems schafft, wird klaglos akzeptiert, selbst wenn die dahinter stehende Firma nur Böses im Sin hat. S/MIME vertraut also einem System, das eben durchaus mit sehr leichten Mitteln angreifbar ist. Man braucht nur einmal an den falschen Computerhersteller geraten.

Eine Mögliche Lösung für den „Dinosaurier PGP“ könnte ein Dienst wie Keybase.io sein, welcher die Verantwortung des Echtheitsnachweises für öffentliche PGP-Schlüssel dorthin überträgt, wo sie hin gehört, nämlich zum Besitzer des Schlüsselpaares. Keybase.io funktioniert so, dass man seinen öffentlichen Schlüssel dort hinterlegt und dann mittels verschiedener beliebig kombinierbarer Verfahren nachweist, dass man tatsächlich der Inhaber dieses öffentlichen Schlüssels ist. Dies kann ein Tweet auf Twitter, eine kleine Datei im Github-Konto, ein Posting auf Reddit oder auch eine Datei auf dem eigenen Webserver oder ein DNS-Eintrag für die eigene Domain sein. Wer sich mein Keybase.io-Profil anschaut, wird dort vorfinden, dass ich mich per Twitter, Github und Nachweis des Besitzes von mehreren Domains, u. a. auch dieser, als Inhaber meines öffentlichen Schlüssels ausweise. Der Schlüssel ist – oh Wunder – tatsächlich der, den ich auch im Laufe der Serie mehrmals verlinkt und im Impressum hinterlegt habe.

Wer den Fingerabdruck abgleicht oder mich dort sucht, um meinen öffentlichen Schlüssel zu erhalten, kann also relativ sicher sein, dass ich der bin, der ich vorgebe zu sein. Denn einen Account zu hacken ist vielleicht möglich, aber mehrere, und gerade auch Zugriff auf die Namensserver der Domains zu erlangen, und das alles gleichzeitig, ist schon viel unwahrscheinlicher. Eine Fälschung eines Schlüssels ist so also zumindest mal erschwert.

Zur Unterstützung ist zu sagen, dass iPGMail unter iOS die Schlüsselsuche per Keybase.io bereits unterstützt. GPGTools hat bereits ein offenes Ticket, für Enigmail habe ich eines eingereicht, um die Unterstützung zu integrieren.

Wie Nico Brünjes in seinem Beitrag schreibt, übernimmt Keybase.io in gewissen Grenzen die Funktion einer Krypto-party, auf der man sich gegenseitig seine Schlüssel unterschreibt. Hier sind es die vom Besitzer selbst hinterlegten Nachweise, die ihn als höchstwahrscheinlich echt ausweisen.

Keybase.io ist noch in der Beta-Phase und nimmt Neuregistrierungen nur nach einer Warteliste oder per Einladung durch bereits registrierte Mitglieder entgegen. Meine Einladungen sind zur Zeit leider erschöpft, es gab einige interessierte Blogleser, die mein in der ursprünglichen Fassung eingestelltes Angebot angenommen haben.