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. 😉

Werbeanzeigen

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!

Googlemail vs. Gmail: Auf die richtige Schreibweise kommt es bei Verschlüsselung an

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.

E-Mail-Verschlüsselung mit S/MIME

In diesem Artikel geht es um die Verschlüsselung und Signierung von E-Mails mit S/MIME (secure/multipurpose internet mail extensions) als Alternative zu OpenPGP. Viele der Grundprinzipien sind ähnlich, die Formate sind jedoch nicht zueinander kompatibel. Eine mit OpenPGP verschlüsselte Mail kann also nicht von jemandem gelesen werden, der nur S/MIME einsetzt und umgekehrt. Glücklicherweise ermöglichen alle in der Serie bisher besprochenen Lösungen eine Koexistenz beider Systeme, so dass man sich nicht entscheiden muss, sondern beide parallel betreiben kann. Dabei zeigt sich, dass S/MIME zwar das geschlossenere System von beiden ist, von der Benutzerfreundlichkeit und Integration jedoch einige Vorteile gegenüber OpenPGP bietet, die auch die in den letzten Jahren gemachten Fortschritte nicht ganz haben wett machen können.

Das wichtigste jedoch: S/MIME ist genauso sicher wie OpenPGP. Die Algorithmen zur Berechnung der Schlüssel sind sehr ähnlich, und auch die Privatheit des privaten Schlüssels ist gegeben (mehr dazu siehe unten). Es gibt allerdings einige Unterschiede, deren man sich bewusst sein sollte. Wer kein OpenPGP nutzen möchte, aber S/MIME, kann den folgenden Abschnitt überspringen und gleich zur Beantragung gehen.

Die wichtigsten Unterschiede

Der wichtigste Unterschied ist, dass bei OpenPGP die Beglaubigung oder Echtheit öffentlicher Schlüssel durch die Unterschriften verschiedener Benutzer bezeugt wird. Bei S/MIME-Zertifikaten hingegen wird diese Beglaubigung durch eine globale Zertifizierungsstelle (CA) ausgestellt. Viele globale Zertifizierungsstellen werden von Apple, Microsoft, Mozilla und anderen als Vertrauenswürdig eingestuft und die E-mail-Zertifikate daher als gültig anerkannt, wenn die Unterschrift auf dem öffentlichen Schlüssel verifiziert werden kann. Jeder öffentliche Schlüssel hat daher auch nur genau eine Unterschrift zur Beglaubigung, nämlich die der Zertifizierungsstelle.

Die S/MIME-Schlüssel werden nur immer genau auf eine E-Mail-Adresse ausgestellt. Hat man also fünf E-Mail-Adressen, mit denen man verschlüsselt kommunizieren möchte, muss man sich auch fünf Zertifikate besorgen.

Die Zertifikate werden im Falle kostenloser Varianten in der Regel nur auf die E-Mail-Adresse ausgestellt. Die Zertifizierungsstelle bestätigt also lediglich die Echtheit der E-Mail-Adresse, nicht die Identität der dahinter stehenden Person. Dies ist ein Zertifikat der Stufe 1. Zertifikate der Stufe 2 verifizieren auch den Namen der Person, indem z. B. Prüfungen des Personalausweises o. ä. durchgeführt werden, um die Echtheit der Personenangaben zu bestätigen. Die Stufe 3 letztendlich erwartet ein persönliches Erscheinen der Person zur Verifizierung, was in der Regel von Zertifikatsstellen gar nicht angeboten wird.

Ein Hinweis für Leser in Deutschland: Es ist gesetzlich verboten, eine Kopie des Personalausweises anzufertigen oder von dritten anfertigen zu lassen. Will man sich also für ein Zertifikat der Stufe 2 registrieren, muss man genau hinschauen, was erwartet wird und was man wie preisgeben kann und darf.

Es gibt keine Passphrase zur Ver- und Entschlüsselung, die abgefragt wird. E-Mails werden automatisch entschlüsselt, wenn für den Absender ein öffentlicher Schlüssel vorliegt. Erhält man eine nicht verschlüsselte, aber signierte E-Mail, importieren viele Mailer unter OS X und Windows die öffentlichen Schlüssel automatisch, so dass ab sofort verschlüsselt kommuniziert werden kann. Dies ist auch der übliche Verbreitungsweg für öffentliche Schlüssel im S/MIME-Verfahren: man schreibt nicht verschlüsselte, aber signierte Mails.

Beantragen eines kostenlosen Zertifikats

Es gibt mehrere Anbieter für kostenlose S/MIME-Zertifikate der Stufe 1. Ich selbst habe sehr gute Erfahrungen mit den Zertifikaten von Comodo gemacht. Dieser Link führt direkt zum auszufüllenden Formular.

  1. Das Formular ausfüllen. Wichtig ist neben der korrekten E-Mail-Adresse und dem Namen hier das Revocation Password (Kennwort zum Zurückziehen des Schlüssels). Dieses unbedingt irgendwo sicher verwahren (z. B. sichere Notiz in 1Password), um das Zertifikat zurückziehen zu können, falls man das Gefühl bekommt, es könne kompromittiert worden sein.
  2. Nach Abschicken des Formulars bekommt man per E-Mail den Link zur Installation des Zertifikats.
  3. Den Link in der Mail anklicken. Es öffnet sich ein neuer Browser-Tab. Das Schlüsselpaar wird nun auf dem Computer generiert und der öffentliche Schlüssel danach an den Server von Comodo gesendet. Diese unterschreiben ihn nun und schicken den unterschriebenen öffentlichen Schlüssel, das Zertifikat, an uns zurück.
  4. Es findet nun ein Download einer Datei mit der Endung .p7s statt. Der Safari im Mac speichert die Datei automatisch im Downloads-Ordner, der Firefox installiert das Zertifikat automatisch in seiner Zertifikatsverwaltung.

Die folgenden Schritte werden nun getrennt für OS X und Windows behandelt.

Installation des Zertifikats

Mac OS X

Nachdem der Schlüssel heruntergeladen wurde, doppelklickt man die Datei bzw. öffnet sie mit Cmd+O. Das Schlüsselpaar wird nun in den Schlüsselbund importiert.

Nun Mail beenden und neu starten. Danach stehen bei neuen Mails zwei Schaltflächen bzw. Kontrollkästchen zur Verfügung. Die eine steht fürs Unterschreiben, die andere fürs Verschlüsseln der mail. Wer bereits OpenPGP einsetzt, kann nun mit Cmd+Wahltaste+P auf OpenPGP bzw. Cmd+Wahltaste+S auf S/MIME umschalten, also beide Verschlüsselungsverfahren nutzen.

Erhält man nun eine mit S/MIME unterschriebene Mail, speichert Mail den öffentlichen Schlüssel des Absenders automatisch. Ihr selbst solltet nun auch immer unterschreiben, wenn ihr eine neue Mail schreibt, um so anzuzeigen, dass ihr S/MIME unterstützt. Kommen beide Verfahren zum Einsatz, kann man ja an den gleichen Empfänger in einer Mail mit S/MIME, in der anderen mit OpenPGP unterschreiben.

Kommt jetzt eine verschlüsselte Mail an, wird diese automatisch entschlüsselt. Beantwortet man sie, wird auch die Antwort automatisch mit dem richtigen Verfahren verschlüsselt.

iOS

Möchte man das Zertifikat auch unter iOS nutzen, muss man wie folgt vorgehen:

  1. Im Ordner Programme/Dienstprogramme das Programm Schlüsselbundverwaltung öffnen.
  2. Nach der eigenen E-Mail-Adresse suchen und in den Ergebnissen den Eintrag mit dem Typ „Zertifikat“ auswählen.
  3. Diesen jetzt erweitern, dass der dahinter versteckte Eintrag „Privater Schlüssel“ sichtbar wird. VoiceOver-Nutzer drücken Ctrl+Wahltaste+Nummernzeichen.
  4. Diesen Eintrag „Privater Schlüssel“ jetzt rechtsklicken bzw. mit Ctrl+Option+Umschalt+M von VoiceOver das Kontextmenü aufrufen und Exportieren wählen.
  5. Namen vergeben, Ort wählen und sicherstellen, dass als Dateiformat Personal Information Exchange (P12) ausgewählt ist.
  6. Im nächsten Schritt ein Kennwort vergeben, mit dem die exportierte Datei geschützt wird.
  7. Diese P12-Datei jetzt per Mail an sich selbst schicken. Andere Wege werden von iOS leider nicht unterstützt, z. B. AirDrop.
  8. Auf dem iPhone oder iPad die Mail öffnen und den Anhang antippen.
  9. Es öffnen sich die Einstellungen. Jetzt oben rechts auf Installieren tippen und mit dem Geräte-Code bzw. Kennwort bestätigen.
  10. Man wird nun gewarnt, dass das Zertifikat noch unbekannt sei. Mit nochmaligem Drücken auf Installieren bestätigen, und das gleiche im darauf erscheinenden Sicherheits-Abfrage-Hinweis.
  11. Jetzt das eben vergebene Kennwort eingeben und auf Weiter tippen.
  12. Das Zertifikat ist nun installiert. Auf Fertig tippen, und man gelangt wieder in die E-Mail.
  13. In die Einstellungen zurückkehren und den Punkt E-Mail, Kalender … wählen.
  14. Das E-Mail-Konto wählen, unter dem die E-Mail-Adresse des Zertifikats geführt wird.
  15. Das Konto bearbeiten und ganz unten auf Erweitert tippen.
  16. Ganz nach unten scrollen und S/MIME aktivieren.
  17. Sowohl Signieren als auch Verschlüsseln aktivieren. Das richtige Zertifikat sollte jeweils ausgewählt sein.
  18. Zurück wählen und oben rechts auf Fertig. Da keine anderen Änderungen am Konto vorgenommen wurden, sollte sich das Fenster einfach schließen, und wir können die Einstellungen verlassen.

Jetzt werden unterstützte Empfänger automatisch mit verschlüsselten Mails versorgt, und alle anderen Mails werden mit S/MIME unterschrieben. Erhält man eine unterschriebene Mail, kann man beim Absender direkt auf die Details tippen und das Zertifikat (den öffentlichen Schlüssel) installieren. Ein automatisches Importieren von öffentlichen Schlüsseln findet im Gegensatz zu OS X leider nicht statt, wenn man eine unterschriebene Mail erhält.

Wie man aber sieht, ist das Behandeln von S/MIME-verschlüsselten E-Mails im Vergleich zu OpenPGP deutlich einfacher und direkt in die Mail-App integriert. Es ist nicht nötig, Apps von Drittherstellern zu verwenden.

Windows

Hat man sich das Zertifikat mit Hilfe von Firefox erstellt, also den Link in der E-Mail angeklickt, wird das Zertifikat automatisch in Firefox installiert. Man bekommt darüber auch eine Meldung. Um es nun in Thunderbird nutzen zu können, geht man wie folgt vor:

  1. Man öffnet Extras, Einstellungen (bzw. Optionen) und wechselt aufs Register Erweitert.
  2. Hier wählt man das Unter-Register Zertifikate aus und klickt auf Zertifikate Anzeigen.
  3. Im folgenden Fenster wechselt man aufs Register Eigene Zertifikate, wählt das gerade installierte Zertifikat von Comodo CA aus und klickt auf Backup.
  4. Man vergibt einen Dateinamen, wählt ggf. einen Zielordner und belässt das Dateiformat tunlichst auf P12.
  5. Im nächsten Schritt vergibt man ein Kennwort zum Schützen der exportierten Datei. Danach wird die Datei gespeichert und dies bestätigt. Man kann nun die Dialoge schließen.
  6. Jetzt wechselt man zu Thunderbird und öffnet Extras/Konteneinstellungen. Man wählt das Konto für die E-Mail-Adresse aus, für die man eben ein Zertifikat erstellt hat und wechselt auf den Eintrag Sicherheit.
  7. Hier wählt man wieder Zertifikate anzeigen und wechselt auf das Register Eigene Zertifikate.
  8. Auf Import klicken, die in Schritt 4 gespeicherte Datei wählen, das in Schritt 5 vergebene Passwort eingeben, und das Zertifikat wird importiert. Der Zertifikatmanager kann nun auch durch Klick auf OK geschlossen werden.
  9. Jetzt für die Signierung von E-Mails den Schalter „Wählen“ betätigen und das soeben importierte Zertifikat wählen.
  10. Thunderbird fragt nun nach, ob dieses Zertifikat auch für das Verschlüsseln von Mails verwendet werden soll. Dies wird bejaht.
  11. Nun noch einstellen, dass E-Mails standardmäßig signiert werden sollen, und bei Verschlüsselung „notwendig“ auswählen. Mit OK die Konteneinstellungen schließen.

Nun kann man mit S/MIME verschlüsselte Mails senden und empfangen. Hat man zusätzlich OpenPGP mit Enigmail installiert, fragt Enigmail im Zweifel nach, ob die Verschlüsselung mit PGP/MIME oder S/MIME passieren soll. Auch hier ist also eine Koexistenz beider Systeme möglich.

Auch Thunderbird importiert automatisch S/MIME-Zertifikate bei Erhalt digital unterschriebener Mails. Man muss also auch hier keine öffentlichen Schlüssel von Hand importieren. Man kann sogar direkt verschlüsselt antworten, vorausgesetzt, man hat dem Empfänger schon mal eine digital signierte Mail geschickt und dessen Client hatte die Chance, den öffentlichen Schlüssel abzurufen.

Hat man iOS-Geräte, kann man mit derselben Datei, die man aus Firefox per Backup exportiert hat, so vorgehen, wie im vorigen Abschnitt ab Schritt 7 beschrieben, also dem Punkt, an dem man sich seine Backup-Datei selbst per Mail zuschickt.

Die Optionen zum Einstellen, ob man eine S/MIME-Mail signiert und/oder verschlüsselt, finden sich entweder im Popup-Menü der oberen Symbolleiste oder im Menü Optionen als unterste zwei Menüpunkte.

Fazit

Das Erstellen, der tägliche Umgang und die Integration ist mit S/MIME deutlich einfacher als mit OpenPGP. Welches Verschlüsselungsverfahren man nimmt, oder ob man zweigleisig fährt, ist eine Geschmacks- und Glaubensfrage. Manche werden der Unterschrift einer Firma, auch wenn diese sich CA nennt, niemals so sehr vertrauen wie den Unterschriften ihnen persönlich bekannter Personen und von daher OpenPGP vorziehen. Andere werden vielleicht die einfachere Handhabung von S/MIME bevorzugen, gerade wenn sie auch unter iOS arbeiten, und von daher diese Variante bevorzugen. Beide Verfahren sind bisher nicht geknackt worden. Von dieser Seite herrscht also eher kein Unterschied.

Ich selbst habe mich dazu entschieden, beide Verfahren einzusetzen und dadurch mit beiden erreichbar zu sein. So kann jeder selbst entscheiden, wie er/sie mit mir verschlüsselt kommunizieren möchte. Wer also meinen öffentlichen S/MIME-Schlüssel möchte, schickt mir einfach eine Mail mit der Bitte um Zusendung einer signierten Antwort. Idealerweise enthält diese Anfrage schon gleich die eigene Signatur, dann ist sofortige verschlüsselte Kommunikation möglich.

Viel Spaß beim verschlüsselten Kommunizieren, mit welchem Verfahren auch immer!

OpenPGP unter iOS einrichten

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! 😉

OpenPGP im täglichen Einsatz – ein paar Hinweise

Nachdem ihr nun die Anleitungen für Windows und Mac OS X durchgearbeitet habt, habt ihr hoffentlich die letzte Woche genutzt, euch vielleicht schon mal selbst eine verschlüsselte E-Mail zu schicken oder Kontakt zu Freunden aufzunehmen, die OpenPGP ebenfalls einsetzen. Ich habe erfreulicherweise mehrere Mails von Lesern dieses Blogs erhalten, die sich die Verschlüsselung erfolgreich eingerichtet haben. Es gab natürlich auch ein paar Nachfragen, deren Beantwortung ich in Updates zu den Artikeln durch Klarstellungen oder Erweiterungen vorgenommen habe.

Allgemein ist zu sagen, dass die E-mail-Programme nun einige weitere Elemente im Fenster zur Erstellung von Nachrichten enthalten als vorher. In Apple Mail sind dies zwei Kontrollkästchen zwischen dem Betreff- und dem Absender-Feld. In Thunderbird sind dies zum einen ein weiteres Menü in der Menüleiste namens OpenPGP und einige weitere Schaltflächen in der Symbolleiste. Beide haben ähnliche Funktionen: man stellt ein, ob die E-Mail, die man gerade schreibt, verschlüsselt und/oder unterschrieben werden soll. Dabei ist das Unterschreiben standardmäßig aktiviert, das Verschlüsseln hingegen nicht. Das ist eine durchaus sinnvolle Einstellung, denn unterschriebene Mails sind weiterhin von allen lesbar, verschlüsselte hingegen nur für die Empfänger mit den passenden privaten Schlüsseln. Daher ermöglichen beide E-Mail-Programme das Verschlüsseln auch nur für solche E-Mail-Empfänger, für die sie im Schlüsselbund des Gnu Privacy Guard auch einen passenden öffentlichen Schlüssel finden.

Das Unterschreiben von E-Mails kann auch als Verbreitungsweg für die Neuigkeit dienen, dass man nun OpenPGP-Verschlüsselung eingerichtet hat und verschlüsselte Mails empfangen kann. Also auch jemand, der bisher nicht wusste, dass man nun OpenPGP „versteht“, bekommt so signalisiert, dass dem so ist und kann den öffentlichen Schlüssel abrufen, um zukünftig verschlüsselt zu kommunizieren.

Denn auch beim lesen sind ein paar Dinge neu hinzugekommen. Erhält man eine unterschriebene E-Mail, ist im Bereich der Mailkopfzeilen ein entsprechender Hinweis zu finden. Hat man den öffentlichen Schlüssel des Absenders bereits im eigenen Schlüsselbund, wird die Signatur dann in der Regel als gültig angezeigt, während Absender, deren Schlüssel man noch nicht hat, als „unbekannter Signaturgeber“ angezeigt werden. Ruft man den Schlüssel dann ab, ändert sich dies bei korrekter Signatur natürlich. Praktischerweise unterstützt Apple Mail bzw. die GPGTools das automatische Abrufen von Schlüsseln bei neuen/unbekannten Absendern mit OpenPGP-Fähigkeit. Hat derjenige also einen öffentlichen Schlüssel auf dem Schlüsselserver hinterlegt, holt Apple mail den automatisch ab und verifiziert. Ab sofort ist dann mit diesem Absender verschlüsselte Kommunikation möglich, ohne dass man irgend etwas weiteres tun muss. Diese Funktion ist übrigens in den Systemeinstellungen/GpgTool-Preferences abschaltbar (Kontrollkästchen ganz unten im Fenster). Thunderbird und Enigmail unterstützen den automatischen Abruf von Schlüsseln in dieser Form leider nicht.

Eine weitere allgemeine Faustregel ist, dass man bei Standardeinstellungen verschlüsselt antwortet, wenn man eine verschlüsselte Mail erhält. Voraussetzung ist natürlich, dass man bereits den öffentlichen Schlüssel des Absenders in seinem Schlüsselbund hat. So ist eine einmal begonnene verschlüsselte Mailkonversation durchgehend verschlüsselt.

Das Abfragen der Passphrase

Einigen von euch ist sicher aufgefallen, dass oft nach der Passphrase zum Ver- und Entschlüsseln und/oder Signieren gefragt wird. Den einen oder die andere von euch wird dies vielleicht schnell nerven. Man kann sowohl in den GPGTools als auch in Enigmail einstellen, dass die Passphrase länger zwischengespeichert wird als die vorgegebenen 10 Minuten. In Enigmail findet man diese Einstellung in den OpenPGP-Einstellungen. In GPGTools befindet sich diese Einstellung in den bereits erwähnten Systemeinstellungen/GPGTool-Preferences. Hier ist allerdings das Umrechnen von Sekunden in Minuten oder Stunden nötig, um den richtigen Wert einzugeben. Um z. B. die Passphrase für eine Stunde zwischenzuspeichern, muss man 3600 Sekunden angeben, Standardwert sind 600, also 10 Minuten. Unter OS X kann man die Passphrase auch wahlweise noch im Schlüsselbund des Betriebssystems abspeichern, so wird sie bei der Eingabeaufforderung automatisch eingetragen, und man muss nur noch mit Druck Auf Eingabe bestätigen. Bei Verlorengehen des Computers ist dies aber sehr risikobehaftet und sollte nur mit Vorsicht eingesetzt werden!

Angeblich ungültige E-mails

Eine Frage, die im Laufe der letzten Woche aufkam, betraf eine angeblich ungültig formatierte E-Mail, nachdem ein Leser versucht hatte, jemand anderem eine verschlüsselte E-Mail zu schicken. Das Problem war, dass der Empfänger kein PGP/MIME zuließ oder dessen Client dieses Format nicht unterstützte. So etwas kann leider vorkommen, sollte aber die Ausnahme bleiben. Da kommt es dann darauf an, das Gegenüber davon zu überzeugen, PGP/MIME als inzwischen etabliert anzuerkennen. Auch die Auswahl eines anderen Clients oder ein Update desselbigen sollte der Empfänger in diesem Fall in Erwägung ziehen, um kompatibel zu bleiben. 😉

Synchronisieren von Schlüsselbunden

Wer E-Mail-Clients auf mehreren Rechnern (z. B. Desktop und Notebook, oder Privat- und Arbeitsrechner) einsetzt, dem wird schnell aufgefallen sein, dass es keine leichte Möglichkeit gibt, die Schlüsselbunde für den GnuPG synchron zu halten. Mir ist auch nach längerer Recherche keine automatisierte Möglichkeit zum Abgleich von GnuPG-Schlüsselbunden in die Hände gefallen.

Um seine Schlüsselbunde möglichst synchron zu halten, sollte man sich also angewöhnen, einen auf einem Rechner neu importierten öffentlichen Schlüssel gleich in der Schlüsselverwaltung zu exportieren und z. B. in einem Ordner seiner Dropbox oder anderen Cloudspeicher der Wahl zu speichern. Die anderen Rechner bekommen diese dann bei der nächsten Synchronisierung übertragen und man kann sie dann in die dortige Schlüsselbundverwaltung importieren.

Lediglich wenn man ausschließlich mit Mac-Computern und GPGTools arbeitet, übernimmt das Mail-Plugin die Synchronisation durch das automatische Abrufen von neuen öffentlichen Schlüsseln bei Erhalt von E-Mails. Eine Synchronisation über z. B. iCloud wird bisher nicht unterstützt.

Updates

Ein wichtiger Aspekt ist, seine Software (wie auch allgemein üblich) auf dem neuesten Stand zu halten. Unter OS X ist dies mal wieder recht einfach, da alle Teile der GPGTools anbieten, automatisch nach Updates zu suchen und diese zu installieren. Auch Thunderbird selbst und seine Erweiterungen werden in der Regel automatisch aktualisiert, wenn Updates verfügbar sind. Lediglich der Gnu Privacy Guard bzw. GPG4Win unter Windows hat keinen automatischen Update-Mechanismus. Hier muss man also regelmäßig auf der Website vorbeischauen, den RSS-Feed der Neuigkeiten abonnieren oder eine andere Möglichkeit finden, sich regelmäßig über Updates informieren zu lassen und diese dann einzuspielen.

Fazit

Nach der zumindest für Windows etwas komplizierteren Einrichtung von OpenPGP zeigt sich in der Regel, dass im täglichen Umgang wenig bis gar keine Hürden bei der Benutzung auftreten sollten. Die Benutzbarkeit hat sich in den letzten Jahren deutlich verbessert, und man muss nicht mehr wie früher mit Kommandozeilen und super komplizierten Abläufen über die Zwischenablage arbeiten, um verschlüsselt kommunizieren zu können.

Wer in der Hauptsache seine E-Mails unter Mac OS X oder Windows macht, hat mit der bisherigen Serie inklusive diesem Beitrag nun das nötige Rüstzeug erhalten, um in Zukunft verschlüsselt kommunizieren zu können. Ich hoffe, dass sich mir viele von euch anschließen und dies in Zukunft selbstverständlich tun und nicht nur bei „besonderen Anlässen“. Denn je mehr selbstverständlich verschlüsselt wird, desto schwerer wird es für Geheimdienste und andere Regierungsorganisationen, mit der Annahme „wer verschlüsselt, ist kriminell“ eine Massenüberwachung zu rechtfertigen, die jeden unter Generalverdacht stellt. Gerade wir unbescholtenen Bürger, die nichts zu verbergen haben, müssen vor dem Staat keinen Daten-Striptease durchführen und Dinge preisgeben, die wir nie auf eine Postkarte schreiben würden!

In den nächsten Beiträgen zum Thema geht es um die Einrichtung von OpenPGP unter iOS, und wir werfen einen Blick auf die OpenPGP-Alternative S/MIME sowie die Chat-Verschlüsselung per Off-The-Record-Messaging.

Änderung im Blog: Alle Verbindungen sind nun verschlüsselt

Hier ein schneller Hinweis für alle Leser: Dieses Blog verwendet ab sofort verschlüsselte Verbindungen, also solche, deren Adressen mit „https“ beginnen. Auch Links zu meinen Beiträgen, die ihr euch vielleicht als Lesezeichen gespeichert habt, werden automatisch auf ihre verschlüsselten Äquivalente umgeleitet, so dass ihr nichts weiter tun müsst.

Für euch bedeutet dies vordergründig zweierlei:

Erstens könnt ihr in der Adresszeile eures Browsers überprüfen, dass ihr euch tatsächlich auf meiner Seite befindet und nicht auf irgendeiner betrügerischen Website, die sich als meine ausgibt und meinen Inhalt kopiert hat.

Zweitens werden alle Daten, die ihr beim Hinterlassen von Kommentaren an mein Blog übertragt, u. a. ja auch die E-Mail-Adresse, nun verschlüsselt übertragen. Dadurch kann nicht mehr ohne weiteres jeder, der irgendwo am Rand der Leitung sitzt, die Daten einfach abschnorcheln.

Dies ist mein Beitrag dazu, Verschlüsselung als die Norm zu etablieren und nicht mehr als Ausnahme zu betrachten. Je mehr Leute dies tun, desto unwahrscheinlicher ist es, dass man von Geheimdiensten allein aufgrund der Tatsache, dass man Verschlüsselung benutzt, als verdächtig eingestuft wird.

Sollte es wider Erwarten Probleme geben, lasst es mich bitte wissen!

OpenPGP in Apple Mail mit GPGTools einrichten

In diesem Artikel geht es darum, die Funktionalität von OpenPGP in Apple Mail unter Mac OS X nachzurüsten. Wer OS X kennt, wird nicht enttäuscht werden, denn die Integration ist sozusagen nahtlos und sehr einfach. Dieser Artikel setzt die Grundlagen voraus, die ich in diesem Artikel eingeführt habe.

Die Installation der GPGTools

Die Installation ist denkbar einfach:

  1. Ladet euch von der GPGTools-Seite das Installationspaket herunter. Auch wenn ihr noch nicht Yosemite verwendet, also die neueste Version von Mac OS X, wird inzwischen empfohlen, die aktuelle Beta zu installieren. Nach meiner Erfahrung kann dies problemlos geschehen, da die Beta sehr stabil läuft.
  2. Nachdem das Disc Image (.DMG-Datei) heruntergeladen wurde, dieses im Finder doppelklicken bzw. mit Cmd+O öffnen.
  3. Im Festplatten-Image befindet sich ein Installationspaket und ein Deinstallationsprogramm. Das Festplatten-Image also nach der Installation am besten nicht löschen, sonst müsst ihr es bei einer eventuell gewollten Deinstallation erneut laden. Jetzt einfach per Doppelklick oder Cmd+O das Installationspaket ausführen.
  4. Es handelt sich um eine Standardinstallation, wie es sie unter OS X häufig gibt. Es sind alle Einstellungen richtig getroffen. Also einfach auf Fortfahren, 2x Akzeptieren, Installieren klicken und dann das Computerkennwort eingeben, das ihr auch bei anderen Installationen eingebt.
  5. Eventuell werdet ihr aufgefordert, Mail zu beenden, falls dieses gerade gestartet ist. Dies ist nötig, weil das Installationsprogramm die Unterstützung für OpenPGP gleich in mail installiert.
  6. Am Ende einfach auf Schließen klicken.

Ein Hinweis: Das GPGTools-Team hat angekündigt (englischer Artikel), dass die GPGTools nach Ende der Betatest-Phase kostenpflichtig werden. Das Spenden-Modell bei quelloffener Software funktioniert leider nicht immer. Ich finde aber, dass die Tools ihr Geld definitiv Wert sind und ein erheblicher Aufwand betrieben wurde, die Integration so nahtlos wie möglich zu gestalten.

Ein Überblick

Das Installationsprogramm für die GPGTools-Suite hat mehrere Komponenten installiert:

  • Die Mac-Version des Gnu Privacy Guard. Dieser werkelt im Hintergrund, ist aber jederzeit über das Terminal per Kommandozeile auch aufrufbar. Für die Hartgesottenen und Fortgeschrittenen, die auch das letzte Feature herauskitzeln wollen. 😉 Die meisten von uns bekommen von ihm nicht mehr mit als die Abfrage der Passphrase.
  • Das Programm GPG Keychain. Dieses findet sich neu im Programme-Ordner des Finder oder im Launchpad. Dieses werdet ihr viel verwenden, um Schlüssel zu suchen, sie zu verwalten und auch neue zu generieren (siehe unten).
  • Eine neue Seite GPGPreferences in den Systemeinstellungen, die einige grundlegende programmübergreifende Einstellungen verwaltet. Hier wird z. B. festgelegt, welcher private Schlüssel standardmäßig verwendet werden soll, wie lange sich die Tools die eingegebene Passphrase merken sollen, bevor sie erneut abgefragt wird (Passphrase-Zwischenspeicher oder -Cache genannt) und weitere. Diese muss man nur selten aufsuchen.
  • Das Plugin für Apple Mail. Dies sorgt für einen neuen Reiter in den Einstellungen, in dem einige wenige spezifische Einstellungen für Mail vorgenommen werden können. Hier wird unter anderem festgelegt, ob neue Mails standardmäßig verschlüsselt und/oder signiert werden sollen. Weiterhin sorgt es dafür, dass Mails ver- und entschlüsselt werden, bei entschlüsselten mails die Signatur im Kopfbereich angezeigt wird usw. Neben der GPG Keychain ist dies der Teil der GPGTools-Suite, mit dem ihr wohl am meisten zu tun haben werdet.

Für jedes der oben genannten Module kann man aktivieren, dass automatisch nach Updates gesucht wird. Da es sich hier nicht um einen Download über den Mac App Store handelt, werden Updates für die GPGTools nicht von diesem erfasst. Ich empfehle aus Gründen der Sicherheit und Kompatibilität, die Updates zu aktivieren und bei Erscheinen auch umgehend einzuspielen.

Bei großen OS-X-Updates wie von 10.9 „Mavericks“ zu 10.10 „Yosemite“ sollte vorher auch überprüft werden, ob die GPGTools schon für das neue Betriebssystem verfügbar sind (wenigstens in einer Beta), damit man beim Upgrade des Systems nicht die Verschlüsselungsfunktion verliert und dann vorübergehend Teile seiner Mails nicht mehr lesen kann.

Erzeugen des Schlüsselpaares

Diese Aufgabe übernimmt das Programm GPG Keychain. Es befindet sich im Programme-Ordner und im Launchpad. Startet der Assistent nicht automatisch, klickt man in der Symbolleiste oder im Menü „Ablage“ auf „Neu…“.

Ohne viel Schnörkeleien werden sämtliche wichtigen Informationen in einem einzigen Fenster abgefragt:

  • Vollständiger Name: Der eigene Name. Ist in der Regel schon vorausgefüllt.
  • E-Mail-Adresse: Wird aus den in Mail vorhandenen Adressen ausgefüllt. Bei mehreren kann man hier diejenige wählen, mit der man den Schlüssel als Hauptadresse erzeugen möchte.
  • Öffentlichen Schlüssel hochladen: Besagt, ob der öffentliche Schlüssel nach Erzeugen gleich auf einen öffentlichen Server hochgeladen werden soll. Dies ist standardmäßig deaktiviert, und es ist vom eigenen Geschmack abhängig, ob man dies hier gleich aktiviert oder nicht. Gerade wenn man hinterher weitere User-IDs, also E-Mail-Adresse-/Name-Kombinationen hinzufügen möchte, sollte man dies deaktiviert lassen und ihn erst am Ende der Konfiguration von Hand hochladen.
  • Es folgt nun die zweimalige Eingabe der Passphrase.

Die voreingestellten erweiterten Optionen sind für den täglichen Bedarf und die meisten Nutzer vollkommen ausreichend und können in der Regel eingeklappt bleiben. Einfach auf Schlüssel Erstellen klicken, und schon hat man sein Schlüsselpaar erzeugt.

Erweiterte Optionen

Wer neugierig ist oder erfahren genug, um die Optionen anzupassen, kann die erweiterten Optionen ausklappen und findet darunter noch folgende Einstellungen:

  • Schlüsselart: Die Art, wie der Schlüssel erzeugt wird. Voreingestellt ist das weithin übliche „RSA und RSA“, und man braucht dies in der Regel nicht zu ändern.
  • Länge: Die Menge der in einem Schritt verschlüsselten Bits. Im Gegensatz zum im letzten Artikel beschriebenen Enigmail erzeugt GPGTools standardmäßig die noch schwerer zu knackenden längeren Schlüssellängen von 4096 Bit. Es werden also 512 Zeichen (1 Zeichen = 8 Bit) in einem Rutsch verschlüsselt.
  • Schlüssel läuft ab: Die von GPGTools erzeugten Schlüssel haben standardmäßig eine Lebensdauer von vier Jahren, und sie können vor Ablauf verlängert werden.
  • Kommentar: Wenn man es braucht, kann man seinen Schlüssel noch kommentieren.

Wie oben bereits geschrieben, sollte es eigentlich nicht nötig sein, hier Änderungen vorzunehmen.

Weitere Benutzer-IDs hinzufügen

Möchte man mit mehr als einer E-Mail-Adresse aus Mail heraus verschlüsselt senden und empfangen, muss man dem eigenen Schlüsselpaar nun von Hand weitere Benutzer-IDs hinzufügen. Man macht dazu einen Rechtsklick auf das eigene Schlüsselpaar, wählt Details und dann den Reiter Benutzer-IDs. Hier fügt man nun alle gewünschten Namen/E-Mail-Adressen hinzu, die verwendet werden soll. Hat man den öffentlichen Schlüssel bereits auf den Schlüsselserver hochgeladen, sollte man dies nach Abschluss dieses Schritts wiederholen, damit die auf dem Server hinterlegte Kopie die aktuellsten Informationen zu den Benutzer-IDs anzeigt. Auch der öffentliche Schlüssel auf der eigenen Webseite muss natürlich erneuert werden, wenn man dort einen hinterlegt hat.

Und das war’s schon!

Ja, mehr gibt’s hierzu nicht zu sagen! Klar, man kann mit dem Kontextmenü seines Schlüssels ein Zertifikat zum Widerruf des Schlüssels erstellen (dringend empfohlen!) und diesen und andere Schlüssel beglaubigen. Das ist aber alles so selbsterklärend und logisch aufgebaut, wie im Apple-Universum allgemein üblich, dass es euch sicher Freude bereiten wird, hier selbst auf Entdeckungstour zu gehen.

Im Gegensatz zum eher doch noch etwas technischeren Enigmail des vorhergehenden Artikels wird hier auch nicht mit verschiedenen Formaten „herumgedoktert“. Es werden immer PGP/MIME-Nachrichten erzeugt, weil dies das aktuellste Format ist und heute eigentlich von allen Implementierungen unterstützt werden sollte.

Im nächsten Artikel geht es dann um den täglichen Einsatz von sowohl Enigmail als auch GPGTools in Apple Mail, da sich die grundlegenden Konzepte ähneln.

OpenPGP in Thunderbird mit Enigmail einrichten

Jetzt geht’s ans Eingemachte! In diesem Artikel knöpfen wir uns gleich die – zumindest unter Windows – aufwendigste Installation von OpenPGP zur Verschlüsselung von E-Mails vor. Der Artikel setzt Wissen voraus, das ich im vorangegangenen Artikel vermittelt habe. Am Ende werden wir das E-Mail-Programm Thunderbird mit der Erweiterung Enigmail zur Verschlüsselung von Mails verwenden. Weiterlesen OpenPGP in Thunderbird mit Enigmail einrichten

Grundlagen zur E-Mail-Verschlüsselung mit OpenPGP

Das Thema, um das es in der Serie zuerst gehen soll, ist die Verschlüsselung von E-Mails mit Hilfe des Standards OpenPGP. In diesem Beitrag beleuchte ich einige Konzepte, die bei allen Installationen von OpenPGP-Software gleich oder zumindest sehr ähnlich sind. In den weiteren Beiträgen geht es dann um die Installation von OpenPGP für verschiedene Anwendungen unter diversen Desktop- und mobilen Betriebssystemen. Wer jetzt erst in die Serie einsteigt, ist gut beraten, den vorigen Beitrag zu lesen, in dem ich erkläre, was Verschlüsselung eigentlich genau ist. Dieses Wissen wird vorausgesetzt, um diesem und allen weiteren Beiträgen folgen zu können. Weiterlesen Grundlagen zur E-Mail-Verschlüsselung mit OpenPGP