OpenPGP: Probleme und Unzulänglichkeiten bei der Benutzbarkeit und mögliche Linderung durch Keybase.io

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.

Schutz der Privatsphäre bei E-Mail-Providern betrachtet

Bisher haben wir uns in der Serie zur Verschlüsselung um die Verschlüsselung des eigentlichen Mailtextes gekümmert. Es gibt aber noch einen weiteren wichtigen Bestandteil von E-mails, nämlich die sogenannten Kopfzeilen inklusive Absender, Empfänger, Betreff und eventuell in Kopie oder Blindkopie gesetzte Empfänger. Auch hier findet die Übertragung inzwischen bei sehr vielen E-Mail-Diensteanbietern verschlüsselt statt, so dass auch diese Daten auf dem Transportweg nicht mehr oder nur noch in einer eventuellen fernen Zukunft entschlüsselt werden können. Diese sogenannten Metadaten, also Daten des wer an wen, wann und warum, sind für Geheimdienste und Kriminelle ebenso interessant auszuspähen wie die eigentlichen Mailinhalte. Durch die Wahl des richtigen Providers kann man aber noch mehr Sicherheit erhalten und auch diese Schnüffeleien mindestens erheblich erschweren.

Voraussetzung 1: E-Mail überhaupt verschlüsselt versenden

Über einen ganz langen Zeitraum bestand der E-mail-Verkehr im Internet aus unverschlüsselter Kommunikation. Auch wenn man den mailtext mit OpenPGP oder S/MIME verschlüsselt hatte, wurden die Kopfzeilen trotzdem weiterhin unverschlüsselt übermittelt, und zwar nicht nur vom Mailprogramm des Absenders zu dessen E-mail-Anbieter, sondern auch von diesem auf dem weiteren Weg durchs Internet bis zum Empfänger. Auch der Abruf der Mails per älterem POP3-Verfahren fand bis weit in die 2000er Jahre standardmäßig unverschlüsselt statt. Erst später kam eine Möglichkeit der verschlüsselten Kommunikation hinzu. Bei der Alternative IMAP, bei der die Mails auf dem server verbleiben und man ein Abbild in sein Mailprogramm lädt, war Verschlüsselung schon eher vorgesehen. IMAP brauchte aber eine ganze Zeit, bis es sich durchsetzte, manche Anbieter bieten es selbst heute nur gegen Bares an.

E-mails auf dem Transportweg verrieten also weit mehr als der Brief im Umschlag, selbst wenn der Mailtext verschlüsselt war. Man konnte nicht nur Absender, Empfänger und „Datum des Poststempels“ sehen, sondern auch den Betreff immer einsehen, und auch ob diese mail noch in Kopie an jemand anderes ging. Man brauchte sich nur an den Rand der Internetleitung postieren und fleißig abschnorcheln.

Erst mit den Enthüllungen des NSA-Whistleblowers Edward Snowden fand auch die Verschlüsselung des Transportweges die Aufmerksamkeit, die sie eigentlich schon immer hätte haben sollen. Die erste Voraussetzung ist, dass Mails vom Mailprogramm des Absenders zum Server des E-Mail-Providers verschlüsselt versendet werden können. Viele Anbieter bieten dies schon länger, aber erst seit den Snowden-Enthüllungen ist den meisten providern in den Sinn gekommen, diese Verschlüsselung zu erzwingen, nicht nur optional anzubieten. Interessanterweise hatte eine der größten Datenkraken des Internets, nämlich Google mit seinem Maildienst Gmail, schon immer nur verschlüsselten Versandt im Angebot.

Seit den Snowden-Enthüllungen ist auch klar, dass E-Mail-Anbieter untereinander beim Weiterreichen der Mails unbedingt Verschlüsselung einsetzen müssen. Microsoft war mit Outlook.com der letzte große Anbieter, der dies endlich auch Mitte 2014 umsetzte.

Voraussetzung 2: SSL/TLS-Verkehr mit Perfect Forward Secrecy absichern

Das Problem herkömmlicher SSL/TLS-Verschlüsselung ist, dass diese nachträglich entschlüsselt werden kann, sollte Geheimdiensten oder Kriminellen der private Schlüssel des Zertifikatinhabers irgendwie in die Hände fallen. So kann abgehörter Verkehr noch Jahre später entschlüsselt werden. Ist der Mailtext selbst nicht verschlüsselt, liegt dem Entschlüsseler also in diesem Moment alles im Klartext vor.

Das Rezept dagegen heißt Perfect Forward Secrecy. Die beiden Gesprächspartner, also z. B. zwei mailprovider untereinander, handeln bei der ersten Kontaktaufnahme nicht nur gegenseitig ihre öffentlichen Schlüssel aus, sondern auch über mehrere Berechnungsstufen eine weitere Verschlüsselungsebene, deren Schlüssel nach erfolgreicher Übertragung weggeworfen werden. Selbst wenn also jemand diesen Verkehr abhört, kann er zum einen den Schlüssel nicht aus der Unterhaltung rekonstruieren, und zum zweiten ist es unmöglich, diese Daten hinterher zu entschlüsseln, weil es die Schlüssel dafür nicht mehr gibt. Sie wurden ja nach Ende der Übertragung verworfen. Für tiefer in die Materie einsteigen wollende Leser hat Heise Security eine gut lesbare Erklärung vorrätig.

Gute E-Mail-Provider sollten also mindestens Perfect Forward Secrecy beherrschen, wofür natürlich SSL/TLS-Verschlüsselung allein schon die Voraussetzung ist. Und zwar bitte schön sowohl beim Kommunizieren mit anderen Servern als auch beim Kommunizieren mit dem E-mail-Client des Kunden und beim Aufruf des Webmail-Interfaces per Browser. Die Stiftung Warentest veröffentlichte am 04.02.2015 einen ausführlichen Test verschiedener Provider auf diese Punkte hin.

Weitere Sicherheit mit DANE/TLSA

Trotz der oben genannten Absicherungen ist es im Design dieser Protokolle immer noch möglich, dass ein unbefugter Dritter sich als der Server ausgibt, den man erreichen will, und dann E-Mails abfängt, die eigentlich gar nicht für ihn bestimmt waren. Dies hat u. a. mit der sogenannten Zertifikatskette zu tun, also der Tatsache, dass Browser und andere Programme bestimmten Zertifizierungsstellen vertrauen und im Standardfall ein als gültig erkanntes Zertifikat ab einem bestimmten Punkt nicht mehr weiter hinterfragen.

Um dies zu verhindern, wurde der offene Standard DANE/TLSA entwickelt. DANE steht für „DNS-based Authentication of Named Entities“. Wikipedia beschreibt diesen Standard hier sehr gut. Die Kurzfassung ist, dass im „Telefonbuch des Internets“, den sogenannten Domain Name Servern (DNS) ein Ausweis hinterlegt ist, der ganz klar bezeichnet, wie das Zertifikat beim Verifizieren einer verschlüsselten Verbindung auszusehen hat. Das Telefonbuch kennt also die richtigen Zertifikate für eine Domain, so dass ein böser Dritter diese nicht mehr so einfach fälschen kann. Das Verfahren ist recht aufwendig zu implementieren, aber immer mehr Anbieter tun dies, um unbefugten Zugriff und Zertifikatsfälschungen einen Riegel vorzuschieben. In Deutschland sind die Vorreiter die kleinen Anbieter Posteo, Mailbox.org und Tutanota. FastMail plant die Einführung.<

Die Mogelpackung E-Mail Made In Germany

Im April 2014 wurde mit großem Brimborium E-Mail Made in Germany angekündigt. Ursprünglich wurde diese von Gmx, Web.de und der Deutschen Telekom ins Leben gerufen, inzwischen haben sich ihr auch Freenet, 1&1 und Strato angeschlossen. Es wird mit einer vollständig sicheren Kommunikation geworben, damit, dass die E-mails Deutschland beim Versandt untereinander nicht verlassen würden und dass man in den Webmailern sofort sehen würde, wenn man mit anderen E-Mail-Made-In-Germany-Teilnehmern kommuniziert. Es wurde weiterhin verlautbart, dass der TÜV Rheinland ab Ende April 2014 weitere Anbieter zertifizieren würde.

An dieser Initiative gibt es mehrere Punkte auszusetzen. Zum einen nutzen die Teilnehmer ein proprietäres, nicht offen gelegtes Verfahren zur gegenseitigen Vertrauensstellung mit Namen Inter-Mail Provider-Trust. Dieses igelt die Teilnehmer in ein Silo ein, an das kein anderer herankommt. Anstatt wie Posteo, Mailbox.org oder Tutanota auf DANE zu setzen, das ebenfalls abgefragt und sofort als sicher gekennzeichnet werden könnte, bauten die Teilnehmer sich eine hübsche Insellösung, die andere vertrauenswürdige Provider ausschließt, es sei denn, diese sind bereit, viel Geld an den TÜV Rheinland zu zahlen, um eine Zertifizierung zu bekommen. Voraussetzung ist natürlich, dass die Anfragen interessierter Provider überhaupt beantwortet werden. Ich teile hier durchaus die Meinung des Geschäftsführers von Mailbox.org, dass das als wettbewerbsverzerrend gewertet werden könnte.

Dies bedingt den zweiten Kritikpunkt: Das Verfahren ist für außenstehende nicht transparent und nicht offen gelegt. Die werkeln also wunderbar im Geheimen, und eine unabhängige Kontrolle ist nicht möglich.

Ach und übrigens: Nicht mal das Bundesamt für Sicherheit in der Informationstechnik (BSI) vertraut E-Mail Made In Germany, sondern setzt für bund.de und dessen Subdomains lieber auf DANE/TLSA. Das spricht für sich, würde ich sagen!

Dies bedeutet nicht, dass T-Online, web.de oder GMX oder irgendeiner der anderen Teilnehmer zwangsläufig schlechte E-Mail-Provider sind. Wie der Test der Stiftung Warentest zeigt, sind bis auf bei Freenet die Bedingungen durchaus als in Ordnung zu bezeichnen. Nur sollte man sich nicht von dem Marketing-Sprech der Initiatoren von E-Mail Made In Germany ins Bockshorn jagen lassen. Selbst mit Gmail-Teilnehmern kommuniziert man heute mit per Forward Secrecy abgesicherten Verbindungen.

De-Mail: Finger weg!

Überrascht es hier irgendjemanden, dass De-Mail, der angeblich so sichere „Briefersatz“ ebenfalls von Telekom, Gmx und Web.de angeboten wird? Ja, das sind genau die gleichen, die E-mail Made In Germany initiiert haben. Was für ein Zufall aber auch! Dabei sind die Verfahren, die Bei De-Mail zum Einsatz kommen, noch wesentlich weniger transparent als bei EMIG. Vor allem soll es hier sogar Standard sein, die Mails auf dem Weg zu entschlüsseln, um sie einer Prüfung auf Schadsoftware hin zu unterziehen. Oho, das wäre genauso als würde jeder Brief schon im Postamt geöffnet, um sicherzustellen, dass kein Vanillezucker drin ist. Und neben dran steht der freundliche BND-Agent und macht sich Notizen. Denn im Gegensatz zu S/MIME oder OpenPGP unterliegen die bei De-Mail eingesetzten Verschlüsselungsverfahren vollständig der Kontrolle der Anbietergemeinschaft, und da ist nichts quelloffen. Mein Rat: Finger weg von De-Mail, wenn es sich irgendwie vermeiden lässt!

Ein persönlicher Tipp

Wer einen der in Deutschland und somit den wirklich guten strengen deutschen Datenschutzrichtlinien unterworfenen Provider sucht, ist mit Posteo oder Mailbox.org sehr gut bedient. Beide Dienste sind kostenpflichtig, bieten dafür aber auch einen erheblichen Gegenwert. Posteo.de ist besonders auf Anonymität bedacht und erlaubt nur Posteo-E-Mail-Adressen. Mailbox.org hat ein umfangreicheres Portfolio, in dem auch eine quelloffene Office-Anwendung zur Textverarbeitung und Tabellenkalkulation enthalten ist, wenn man dies braucht. Die zum Einsatz kommende Open-Xchange App Suite ist sogar ziemlich barrierefrei für Screen-Reader-Benutzer, und die Punkte, an denen es hakt, werde ich in nächster Zeit mal mit den Machern besprechen.

Wer seine Daten lieber in der Schweiz beheimatet haben möchte, findet mit KolabNow (ehemals MyKolab) eine gute Alternative.

„aber halt!“ mag jetzt jemand fragen, „Was ist denn mit FastMail, für den Du in Deinem Post darüber, wie Du Google-frei wirst, geworben hast?“ Ich halte FastMail nach wie vor für einen sehr sicheren Dienst. Die Maßnahmen zum Schutz der Benutzerdaten (englisch) klingen sehr gründlich. Allerdings macht mir die Tatsache, dass die primären Server in den USA stehen, doch etwas Sorgen, denn im Zweifelsfall ist nicht zu 100% geklärt, unter welche Jurisdiktion die Daten letztendlich fallen würden. Daher werde ich im Laufe der nächsten zeit meine E-Mail-Angelegenheiten umziehen, und zwar unter das Dach deutschen Datenschutzrechts. Ich habe auch schon ein wahrscheinliches Ziel im Visier, das mir nicht nur E-Mails mit eigenen Domains, sondern sogar ein Online Office bietet, was mir FastMail nicht bieten konnte, und mich somit noch näher an eine Google- und Microsoft-Alternative bringt. Aufmerksame Leser können sich denken, welchen Provider ich meinen könnte. 😉

Der Gnu Privacy Guard braucht unsere Hilfe! Jetzt spenden!

Der Gnu Privacy Guard (GnuPG) ist das Herzstück aller in der Serie zur E-Mail-Verschlüsselung behandelter OpenPGP-Lösungen. Er ist die einzige Instanz einer wirklich offenen und transparenten E-Mail-Verschlüsselung, die vollkommen von irgendwelchen Firmen unabhängig ist.

So ein Projekt braucht nicht nur Nutzer, sondern auch Menschen, die die Software weiterentwickeln, die Webseiten am laufen halten usw. Der Gnu Privacy Guard wird seit 1997 in der Hauptsache von Werner Koch aus Erkrath entwickelt und am Leben gehalten. 1999 und 2005 erhielt er zwei projektbezogene Unterstützungen von der deutschen Bundesregierung, das zweite Projekt lief aber 2010 aus und wurde nicht erneuert. Diese und weitere Hintergrundinformationen zu Werner Koch und dem Projekt enthält dieser englischsprachige Artikel bei ProPublica.

Die aktuelle Spendenkampagne hat 120.000 Euro zum Ziel und bisher knapp 55.000 Euro davon geschafft (Stand 05.02.2015 ca. 19:00 Uhr). Ich möchte alle Leserinnen und Leser dieses Blogs eindringlich bitten, eine Spende zu leisten und vielleicht bei der Gelegenheit mit E-Mail-Verschlüsselung anzufangen, wenn ihr dies nicht eh schon getan habt. In der Seitenleiste findet ihr die Einstiegsseite zum Thema. Auch Mehrfachspenden sind sicher möglich, ich versuche gerade herauszufinden, wie ich eine regelmäßige Spende automatisiert leisten kann.

Lasst uns gemeinsam mithelfen, nicht nur einmalig, sondern nachhaltig dafür zu sorgen, dass wir auch in Zukunft sicher kommunizieren können!