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.

Es ist jetzt schon zweimal vorgekommen, dass mich E-Mails erreicht haben, die signiert waren, deren Signatur aber als ungültig angezeigt wurde. Das Problem war in beiden Fällen, dass die Schlüssel bzw. Zertifikate auf eine E-Mail-Adresse ausgestellt wurden, die auf @gmail.com endete. Der Absender der Mails hatte aber in beiden Fällen eine Adresse in seinem Mailer stehen, die auf @googlemail.com endete.

Die Folge davon ist, dass weder die Überprüfung der Signatur hinhaut, noch dass ich verschlüsselt hätte antworten können. Obwohl es sich um denselben Provider handelt, sind @gmail.com und @googlemail.com für die Schlüsselverwaltungen aller Mailprogramme und OpenPGP- und S/MIME-Tools zwei völlig unterschiedliche Paar Schuhe.

Die Lösung dieses Problems liegt darin, seine E-Mail-Adressen idealerweise auf @gmail.com zu vereinheitlichen. Zunächst gilt es zu überprüfen, ob man, wenn man in Deutschland mit einer @googlemail.com-Adresse gestartet ist, diese per Google bereits auf @gmail.com umgestellt hat. Auf dieser Seite könnt ihr mehr darüber lesen und es für euren Account gleich überprüfen.

Ist die Umstellung bereits erfolgt oder durch die oben stehende Überprüfung angestoßen worden, gilt es nun, in allen Mail-Programmen alle Vorkommen von @googlemail.com auf @gmail.com zu ändern. Nichts anderes braucht verändert werden, aber der Login für die Server, die Absender-E-Mail-Adresse und ggf. „Identität“ müssen angepasst werden.

In Thunderbird findet man alle diese Einstellungen unter Extras/Konteneinstellungen, das Gmail-Konto auswählen und auf der Hauptseite, unter „Identitäten“ und in den Servereinstellungen die Vorkommen ändern. Auch ganz unten bei den SMTP-Servern sollte wegen der Vereinheitlichung die Einstellung angepasst werden.

In Apple Mail findet man alle passenden Einstellungen unter Mail/Einstellungen auf der Registerkarte Konten, in den Kontoeigenschaften und bei den Servern für ausgehende E-Mails.

Unter iOS ändert man die Einstellung in Einstellungen/Mail, Kontakte… unter dem jeweiligen Konto einmal auf der Hauptseite und einmal im Fenster für den Postausgangsserver.

Das ist einmal ein bisschen Fummelarbeit, aber wenn das einmal gemacht wurde, ist nicht nur das Angeben der E-Mail-Adresse einfacher (gmail.com spricht sich einfacher als googlemail.com), sondern jetzt stimmt auch alles mit dem Zertifikat überein, so dass von nun an das korrekte Signieren klappen sollte, und der Empfänger kann auch verschlüsselt antworten.

Heutzutage möchte man E-Mails nicht mehr nur auf dem Desktop- oder Laptop-Computer lesen und schreiben. Der mobile Zugriff per Smartphone oder Tablet sind inzwischen mindestens genauso wichtig. Das gilt natürlich auch für verschlüsselte E-Mails.

In diesem Artikel geht es um die Einrichtung und Nutzung von OpenPGP-Verschlüsselung unter iOS. Und wie heißt es so schön in einem sozialen Netzwerk? „Es ist kompliziert.“ Nun ja, nicht so kompliziert, dass es eine unüberwindliche Hürde wäre, aber doch eher umständlich. Dies liegt vor allem daran, dass das iOS-Mail-Programm keine Erweiterungen unterstützt und selbst keine Unterstützung für OpenPGP mitbringt.

Man muss also auf Apps von findigen Entwicklern zurückgreifen, die die Funktionalität zur Verfügung stellen und die Inhalte zwischen sich und der Mail-App hin und her reichen. Die umfassendsten und gangbarsten Lösungen, die ich bei meinen Recherchen gefunden habe, sind die kostenpflichtigen Apps iPGMail und oPenGP (beides iTunes Partner-Links). Ich werde anhand von iPGMail die Vorgehensweise erläutern, oPenGP ist ähnlich aufgebaut. Beide Apps sind für iPhone und iPad gedacht.

Grundsätzlicher Aufbau

iPGMail ist in fünf Tabs (Register) unterteilt:

Keys enthält die Schlüssel. Oben kann man die Anzeige nach öffentlichen (public) oder privaten Schlüsseln umschalten. Ein Tippen auf einen Schlüssel zeigt dessen Details an.

Decode dient zum Entschlüsseln von Text in der Zwischenablage oder aus Mail heraus übertragenen Anhängen (siehe unten).

Compose dient zum Erstellen von Mails.

Files beinhaltet die lokal gespeicherten heruntergeladenen oder aus iTunes übertragenen Dateien und bietet Zugriff auf Dropbox und iCloud. Hier können entschlüsselte Mails gelesen, Keys importiert, Dateien verschlüsselt o. ä. werden.

Settings enthält alle Einstellungen. Hier kann man das Entsperren per PIN und/oder Fingerabdruck (iPhone 5s, 6, 6 Plus oder iPad Air 2) einrichten, Dropbox und iCloud an- und abschalten, einstellen, wie oft nach der Passphrase gefragt werden soll usw.

Ersteinrichtung

Nach der Installation der App hat man zwei Möglichkeiten. Entweder man fängt ganz frisch an, weil man OpenPGP bisher noch nicht eingesetzt hat und erstellt ein neues Schlüsselpaar. Die Vorgehensweise ähnelt stark der Einrichtung unter Windows oder OS X: Man gibt Namen und E-Mail-Adresse an, wählt ggf. die Verschlüsselungsstärke, wobei der Standardwert OK ist, und lässt das iOS-Gerät den Schlüssel generieren. Die Option findet sich unter „Add“ auf dem Register „Keys“ der Anwendung.

Oder man hat seine Schlüssel schon unter Windows oder OS X erzeugt und möchte sie auch unter iOS nutzen. Dann muss man zuerst die Schlüssel in der jeweiligen Schlüsselverwaltung inklusive privatem Schlüssel exportieren (letzteres ist ganz entscheidend!) und diese dann per iTunes-Dateiübertragung oder notfalls per iCloud oder Dropbox auf das iOS-Gerät übertragen. Aus Sicherheitsgründen empfehle ich hier den Weg über iTunes: Gerät anschließen, in iTunes das Gerät auswählen, Register Apps, iPGMail auswählen und die Datei(en) des Exports hierher kopieren. Dann synchronisieren, so dass sie auf dem Gerät landen.

Alternativ speichert man sie in Dropbox, aktiviert dieses über den Settings-Tab auf dem Gerät, geht auf Files, wählt unter „Folders“ Dropbox aus, tippt die Datei an und wählt „Download“. Sie landet dann im lokalen Speicher und sollte danach umgehend aus der Dropbox gelöscht werden.

Nun öffnet man die Datei und wählt unter Actions dann „Decode“. Man wird nach der Passphrase des privaten Schlüssels gefragt, und danach sind die Schlüssel unter Keys im Reiter „Public“ und „Private“ zu finden.

Tipp: Beim Exportieren kann man auch alle anderen öffentlichen Schlüssel gleich mit auswählen, die man von Kontakten bekommen hat. So kann man den aktuellen Stand einmal in einem Rutsch in iPGMail importieren.

Empfangene E-Mail entschlüsseln

Empfängt man nun eine verschlüsselte mail in der iOS Mail App, gibt es zwei Möglichkeiten:

Die Mail ist mit Inline-PGP, also dem verschlüsselten Text im Mailtext verfasst. In diesem Fall muss man den kompletten Mailtext markieren und in die Zwischenablage kopieren. Dann geht man nach iPGMail, wählt die Registerkarte „Decode“ und wählt oben links den Schalter „Import“. Ggf. wird man nach der Passphrase gefragt, und die decodierte Mail landet dann in den Files.

Die bequemere Variante ist, dass man eine Mail im PGP/MIME-Format bekommen hat. In diesem Fall enthält die Mail zwei Anhänge. Der wichtige Anhang ist derjenige mit Namen encrypted.txt. Diesen lange antippen (VoiceOver-User: Doppeltippen und halten). Es öffnet sich dann ein Menü „Öffnen mit“, und man wählt hier iPGMail aus.

Der Mailtext wird nun automatisch decodiert und landet in den Files. Ggf. wird man nach der Passphrase gefragt. Spätestens jetzt zeigt sich noch ein großer Vorteil von PGP/MIME, denn das Umgehen hiermit ist wesentlich bequemer als das Markieren vielleicht mehrere Bildschirmseiten langer Mailtexte.

Erstellen oder Beantworten von Mails

Verschlüsselte Mails werden in iPGMail erstellt und dann an die Mail-App zum Versenden übergeben. Eine neue Mail erstellt man über das Register „Compose“. Auf eine Mail antwortet man, indem man die entschlüsselte Version unter „Files“ öffnet und dann oben rechts auf „Reply“ drückt.

In beidem Fällen öffnet sich ein Fenster zum Erstellen einer Mail. Man wählt die Absender-ID aus, gibt ggf. Empfänger ein (entfällt normalerweise bei Antworten), fügt ggf. Anhänge hinzu, die dann ebenfalls verschlüsselt werden, und schreibt seine Mail. Im Fall einer Antwort ist die ursprüngliche Mail im Klartext zum Zitieren schon vorhanden.

Zum Abschluss überträgt man mit dem Send-Schalter die Mail an die Mail-App. Sie wird verschlüsselt und dann als PGP/MIME-Mail in einer neuen Mail geöffnet. Nach Überprüfung des Absenders kann man hier einfach auf Senden drücken, und raus geht die Mail!

Fazit

Das war’s im Prinzip schon! Es ist wegen der Beschränkungen von iOS leider nicht möglich, die Ver- und Entschlüsselung von Mails direkt in der Mail-App vorzunehmen. Hier bleibt die Hoffnung, dass Apple sein Erweiterungssystem in Zukunft vielleicht dahingehend erweitert, dass solche Mail-Plugins möglich werden. So muss man sich eben immer vergegenwärtigen, Mails erst in iPGMail zu schreiben und dann an Mail zu übertragen. Und das Lesen der entschlüsselten Mail findet eben auch in iPGMail statt, nicht in der Mail-App selbst.

Wie sich andere Mailprogramme wie die App für Gmail oder Gmx mit iPGMail vertragen, habe ich nicht getestet. Fest steht, dass die Übergabe einer geschriebenen Mail immer an die interne Mail-App erfolgt. Ob man aus anderen Mail-Apps die Anhänge von PGP/MIME-Mails ebenfalls so öffnen kann, entzieht sich meiner Kenntnis.

Wie ich oben schon schrieb: OpenPGP in iOS zu nutzen ist möglich, aber komplizierter als unter Windows oder OS X, weil man immer mit zwei Apps hantieren muss. Aber es ist eben nicht unmöglich, und das ist heute ja nicht ganz unwichtig! 😉