Für vertrauliche und nicht manipulierbare E-Mail-Kommunikation gibt es keine Alternativen zur Ende-zu-Ende-Verschlüsselung mit S/MIME oder PGP. Aber sind die wirklich praxistauglich? Und wie funktionieren sie?

In einem Selbstversuch mit 4 Geräten, 3 Betriebssystemen/Mailprogrammen und 2 Mailaccounts wollte ich einmal probieren, komplett auf Ende-zu-Ende-Verschlüsselung umzustellen. Ein kurze Recherche über die möglichen Optionen führt jedoch bereits zur

Erkenntnis Nr. 1: Es gibt zwei Verfahren, S/MIME und PGP, die im Prinzip gleich funktionieren, aber nicht kompatibel sind.

Beides sind „asymmetrische“ oder „Public-Key“-Verfahren, sie verwenden also ein Schlüsselpaar aus einem (geheimen) privaten und einem öffentlichen Schlüssel. Beide Schlüssel gehören rechnerisch zusammen, und nur mit beiden Schlüsseln kann eine Nachricht ver- und wieder entschlüsselt werden. Das Prinzip ist also:

• Alice kann eine Nachricht an Bob mit ihrem privaten Schlüssel „verschlüsseln“ – und Bob kann sie mit Alices öffentlichem Schlüssel „entschlüsseln“. Natürlich ist das keine wirksame Verschlüsselung, denn was Bob kann, könnte jeder andere auch, Alices öffentlicher Schlüssel ist nun mal, naja, öffentlich. Warum sollte Alice also eine solche Nachricht verschicken? Weil sich die Nachricht nur mit ihrem öffentlichen Schlüssel wieder decodieren lässt, so dass Bob sicher sein kann, dass die Nachricht wirklich von Alice stammt: Alice hat die Nachricht „digital signiert“, um ihre Authentizität sicherzustellen.
• Damit niemand anderes mitlesen kann, muss Alice die Nachricht an Bob mit Bobs (!) öffentlichem Schlüssel verschlüsseln. So kann Alice die Vertraulichkeit der Kommunikation sicherstellen, denn nur Bobs geheimer Schlüssel (den er niemals aus der Hand geben darf) fördert wieder den Text der Nachricht zu Tage. Alle anderen Schlüssel passen nicht und liefern beim Entschlüsseln nichts als Zeichensalat. Außerdem ist die Integrität der übermittelten Nachricht sichergestellt, denn jede Manipulation des Mailinhalts würde auf der Empfängerseite ebenfalls zu Kauderwelsch führen. Das ist wirkliche Ende-zu-Ende-Verschlüsselung.
• Schließlich kann Alice die Nachricht auch mit ihrem privaten und Bobs öffentlichem Schlüssel nacheinander verschlüsseln, dann ist sichergestellt, dass die Nachricht sowohl von Alice kommt als auch nur von Bob gelesen werden kann.

Bei allen Varianten bleiben übrigens alle Mailheader (Betreff, Absender, Adressaten) unverschlüsselt, nur der Mailinhalt wird chiffriert.

Warum denn so kompliziert?

Einfacher wäre es natürlich, wenn Alice und Bob „symmetrische“ Verschlüsselung einsetzen würden, das heißt sie würden sich für die Kommunikation untereinander auf einen gemeinsamen Schlüssel einigen, diesen zur Ver- und Entschlüsselung einsetzen und natürlich vor anderen geheimhalten. Eigentlich ein einfaches Verfahren, aber leider in der Praxis nicht umsetzbar:

• Für jede E-Mail muss man einen neuen zufälligen Schlüssel verwenden, da er sonst geknackt werden kann.
• Der Schlüssel muss auf einem sicheren und vertraulichen Weg transportiert werden. In diesem Fall also keinesfalls per E-Mail, sondern etwa per Telefon, Einschreiben oder Kurier.
• Außerdem muss der Schlüssel ausreichend lang sein. 128 Bit gelten als gerade noch sicher (der Pass-Satz „Dieser Satz hat ~128 Bit.“ liefert etwa 128 Bit), besser sollten es 256 Bit sein. Nur dann kann er auch in absehbarer Zukuft nicht durch „brute force“, also Ausprobieren aller Möglichkeiten, geknackt werden.

Vor allem weil sich die sichere Übermittlung der Schlüssel nicht bewerkstelligen lässt, gilt

Erkenntnis Nr. 2: An asymmetrischer Verschlüsselung führt kein Weg vorbei.

Mit asymmetrische Verschlüsselung kann das Problem der Schlüsselverteilung elegant gelöst werden, denn es müssen nur noch öffentliche Schlüssel verteilt werden (was auf beliebigen „unsicheren“ Wegen geschehen kann), die geheimen (privaten) Schlüssel bleiben bei ihrem Besitzer. Freilich müssen die Schlüssel länger sein, um die gewünschte Sicherheit zu bieten – aktuell werden mindestens 2048 Bit empfohlen. Und die Verschlüsselung selbst ist rechenaufwändiger, weshalb man in der Praxis einen Trick anwendet (nämlich die hybride Verschlüsselung).

Asymmetrische Verschlüsselung bedeutet aber auch, und das ist

Erkenntnis Nr. 3: Wenn Alice verschlüsselt kommunizieren will, muss Bob die Vorarbeit leisten.

Alice kann nicht einfach für sich entscheiden, dass sie ihre Nachrichten an Bob verschlüsseln will, ohne Bobs Mithilfe geht da nämlich gar nichts. Bob muss zunächst ein Schlüsselpaar erstellen und Alice seinen öffentlichen Schlüssel geben. Und er muss sorgfältig auf seinen geheimen Schlüssel aufpassen, denn wer den privaten Schlüssel hat, kann alle verschlüsselten Nachrichten an Bob lesen. Wenn Bob unvorsichtig ist, könnte Chris dann doch erfahren, dass Alice nur Bob zu ihrer Party eingeladen hat. Also: Alices Geheimnis bleibt nur gewahrt, wenn Bob alles richtig macht. Das ist anders als bei mündlich mitgeteilten Geheimnissen, da reicht es, dass der Geheimnisempfänger die Klappe hält oder einfach nur vergesslich ist.

Apropos: Wenn Chris ein Böser ist, klinkt er sich als „Man-In-The-Middle“ in die Kommunikation zwischen Alice und Bob ein, aber das (und wie sich Alice und Bob dagegen schützen) ist wieder eine andere Geschichte.

Sicher e-mailen mit jedermann – Test ab!

Schön, Alice und Bob haben es geschafft, Bob hat alles richtig gemacht und nun mailen beide verschlüsselt. Aber ist das, was Alice und Bob können, auch etwas für jedermann? Wie alltagstauglich ist Ende-zu-Ende-Verschlüsselung in meat life? Vor allem, wenn man nicht weiß, mit welchem Mailprogramm, Betriebssystem und Endgerät die Kommunikationspartner unterwegs sind? Und wenn man über die eigene Community oder sonst ein geschlossenes Ökosystem (Firmennetz) hinaus E-Mail-Verschlüsselung einsetzen will?

„Wir wollten das machen und haben es wieder fallen lassen, es war nicht praktikabel.“, sagte mir neulich ein ungenannter IT-Sicherheitsexperte. Kann das sein? Das wollte ich genauer wissen! Am Start sind:

• ein dienstlicher Exchange-Mailaccount
• ein privater Mail-Account (imap + STARTTLS)

Beide Accounts werden unter anderem auf folgenden Endgeräten genutzt:

• einem Firmen-Laptop mit Windows 7 und Outlook (2007)
• einem iPhone und einem iPad mit Zugang auf das private und das dienstliche E-Mail-Konto (iOS, Mail)

Und natürlich soll auch die Kommunikation mit anderen Geräten möglich sein, deshalb soll der imap-Account auch auf folgenden Geräten gelesen werden:

• einem privaten PC mit Linux und Thunderbird
• private PCs mit Windows XP / Windows 7 und Thunderbird
  

Diese Auswahl ist zwar nicht repräsentativ, aber immerhin breit gefächert und ergibt schon eine stattliche Anzahl an Kombinationen. Die Ausgangsidee war ja, dass „jeder mit jedem“ verschlüsselt kommunizieren soll, egal ob der andere S/MIME oder PGP einsetzt. Im Klartext also

Erkenntnis Nr. 4: Wer mit beliebeigen Partner mailen möchte, muss S/MIME und PGP (OpenPGP, PGP/MIME) unterstützen.

Also dann, frisch ans Werk.

Die Vorarbeiten

Client-Software

S/MIME wird von allen eingesetzten Mail-Clients serienmäßig unterstützt, da gibt es zunächst nichts zu tun. Anders PGP: Hier stolpert man zunächst über die verschiedensten Implementierungen und Varianten, Spielarten wie „Inline PGP“ und „PGP/MIME“, zum Glück gibt es unterdessen aber auch den Internetstandard OpenPGP – und mit Enigmail ein passendes und potentes Thunderbird-Plugin dafür. Outlook bringt man mit Gpg4Win auf Trab, beide Pakete enthalten auch eine Schlüsselverwaltung. Nur die iOS-Plattform zeigt sich gegenüber PGP eher verschlossen: Der Mail-Client lässt sich nicht erweitern, PGP nicht in den regulären Mailworkflow integrieren – stattdessen benötigt man separate Apps, die mal schlecht, mal schlechter integriert sind. Verschlüsselte Mails schreibt und liest man damit in der PGP-App, unverschlüsselte weiter im normalen Postfach – alltagstauglich ist das nicht.

Schlüssel und Zertifikate

Nun müssen noch die Schlüsselpaare vorbereitet werden: Bei PGP erzeugt man diese einfach in der Schlüsselverwaltung bzw. im Plugin, sichert den privaten Schlüssel mit einem Passwort und exportiert ihn auf mehrere sichere Medien (gerne auch als Ausdruck auf Papier…). Den öffentlichen Schlüssel signiert man und lädt ihn auf einen Schlüsselserver oder gibt ihn seinen Kommunikationspartnern (für den Test also: sich selbst). Die importieren ihn und stufen ihn als vertrauenswürdig ein. Dieser Schritt geht mit allen getesten Programmen und Apps einfach und intuitiv von statten.

Für S/MIME werden öffentliche Schlüssel in Form von Zertifikaten verteilt. Ein S/MIME-Zertifikat enthält den öffentlichen Schlüssel, der von einer vertrauenswürdigen Stelle (einer certification authority, kurz CA) signiert wurde. Da die Zertifikate der CA die in den gängigen Betriebssystemen bereits hinterlegt sind, kann die Schlüsselüberprüfung damit vollautomatisch erfolgen (wenn man der CA vertraut). Für den Test verwende ich selbst-signierte (self signed) Zertifikate, die sich (wie auch selbst signierte CAs) mit X Certificate and Key management leicht erstellen und verwalten lassen. Nun muss ich „nur noch“ meine öffentlichen und privaten Schlüssel auf den Clients installieren: Auf Windows dient dazu der Windows-Zertifikatsmanager, Thunderbird auf Linux bringt einen eigenen Zertifikatsmanager mit. Unter iOS allerdings brauche ich einerseits das Apple-Konfigurationstool (für die privaten Schlüssel) und dann noch ein paar Tricks, um öffentliche Schlüssel als vertrauenswürdig einzustufen. Praktisch alle Tipps dazu beginnen mit „man sende sich den Schlüssel per E-Mail zu“ (z. B. als signierte E-Mai), dann kann man ihn mit wenigen Handgriffen installieren und als vertrauenswürdig einstufen. Wohlgemerkt: mit wenigen Handgriffen pro Kommunikationspartner. Dann muss ich „nur noch“ die Mailaccounts die jeweiligen privaten Schlüssel zugeteilen (was wieder auf allen Geräten unterschiedlich funktioniert).

Und dann kann es „schon“ losgehen.

Die erste Test-Mail, verschlüsselt

Um eine verschlüsselte Mail zu versenden, benötigt man den öffentlichen Schlüssel des Kommunikationspartners. Mit OpenPGP ist das Installieren und als vertrauenswürdig Einstufen zwar Handarbeit, aber es geht einfach und intuitiv. So sind mit Thunderbird und dem Enigmail-Plugin schnell die ersten verschlüsselten Mails ausgetauscht. Outlook bleibt bei diesem Test leider außen vor: Gpg4Win unterstützt zwar diverse Konstellationen, aber genau die des Autors (Outlook 2007 am Exchange-Server) wird nicht unterstützt. Und auch iOS kann nicht wirklich mitlesen: Die erforderlichen Zusatz-Apps können sich nicht ins Mailprogramm einklinken, verschlüsselte Mails müssen also zum Lesen einzeln in die Apps übernommen werden – das bedeutet doppelte Buchführung für verschlüsselte und unverschlüsselte Mails, und das ist im Alltagseinsatz indiskutabel. Für Android-Nutzer sieht das freilich besser aus, die offenere Betriebssystemplattform lässt hier bessere Apps zu – der Autor aber hat mit seiner Ausstattung hier leider Doppelpech.

Anders die Mailverschlüsselung mit S/MIME: Outlook, Thunderbird und iOS unterstützen dies von Haus aus, die Zertifikate sind schnell installiert, und es kann losgehen. Leider folgt auch hier Ernüchterung auf die Euphorie: So erfolgversprechend die ersten Versuche sind, Thunderbird stellt sich bei der Zertifkatsüberprüfung so pingelig an, dass einige der selbst signierten Zertifikate lakonisch als „nicht vertrauenwürdig einstufbar“ qualifiziert werden – genauere Hinweise gibt es nicht, manuell lässt sich das auch nicht übersteuern, und damit scheitert die verschlüsselte Kommunikation. Apples iOS patzt hier nicht, sorgt aber auf andere Weise dafür, dass kaum jemand die verschlüsselte Kommunkation auf Anhieb zustande bringt: Schon am Importieren der öffentlichen Schlüssel der Kommunikationspartner werden viele scheitern, praktikabel ist es allemal nicht. Dass man es darüber hinaus dann nicht mehr in der Hand hat, ob Mails verschlüsselt werden oder nicht, und dass beim Mailen aus anderen Apps die Verschlüsselung gar nicht zur Verfügung steht – alle diese Nachteile fallen demgegenüber kaum noch ins Gewicht. Mag die S/MIME-Unterstützung bei iOS auch gut gemeint sein, die Umsetzung erweckt den Eindruck, als wolle Apple die Mailverschlüsselung mit allen Mitteln verhindern. Also leider auch hier: Alltagstauglichkiet ungenügend.

Nur noch verschlüsselt mailen? − Leider nein.

Alice und Bob sind in einer guten Lage: Sie haben Konsens über die Verschlüsselung, benutzen die selben ausgewählten Anwendungen, kommunizieren nur untereinander, und sind fähige Computer-Nerds, die auch die ganzen kleinen Stolpersteine geschickt umgehen können. In ihrem abgeschotteten Kreis funktioniert Ende-zu-Ende-Mailverschlüsselung, und mit OpenPGP fahren sie wahrscheinlich besser als mit S/MIME: Es ist einfacher und intuitiver im täglichen Einsatz, und in dieser speziellen Konstellation bieten zentrale CA-Zertifkate keinen Vorteil, schaffen aber zusätzliche Arbeit.

Der Autor dieser Zeilen hat leider die „falschen“ Softwareversionen und die falschen Betriebssysteme, und betriebliche Vorgaben lassen da auch keine Gestaltungsmöglichkeiten. S/MIME wäre hier zwar die Option der Wahl, aber selbst da scheitert der Alltagseinsatz, trotz vordergründig umfassender und guter Unterstützung, an den vielen kleinen Hindernissen und Inkonsistenzen und nicht zuletzt auch daran, dass die Kommunikationspartner weder mit Verschlüsselung arbeiten noch dass deren Software und Systemumfeld bekannt ist.

Schon von daher gilt leider

Das ernüchternde Fazit: Für „Normalos“ ist Ende-zu-Ende-Mailverschlüsselung keine Option

Und das vor allem, weil sie leider nicht praxistauglich ist. Und weil man über die Inkompatibilitäten und Unbequemlichkeiten hinaus noch weitere Nachteile in Kauf nehmen muss:

• Webmailer können nicht mehr genutzt werden (außer, man gibt seinen privaten Schlüssel aus der Hand und legt ihn auf den Server des Providers – dann kann man aber auch gleich unverschlüsselt kommunizieren).
• Alle Mailprogramme legen die verschlüsselten Mails auch verschlüsselt auf der Festplatte ab, wohlgemerkt: Einzeln pro E-Mail verschlüsselt (so, wie sie empfangen wurden), nicht unverschlüsselt in einem passwortgeschützen Gesamtarchiv. Die Mails können daher nicht indiziert werden, und damit ist die Volltextsuche nicht mehr möglich. Für Viel-Mailer ist das ein k.-o.-Kriterium.
• Vor allem bei mehreren Empfängern kommt als Risiko hinzu, dass man seine Sicherheit in fremde Hände gibt. Man muss nicht nur selbst sorgfältig sein, auch der kleinste Fehler eines einzigen Empfängers (etwa ein schlecht geschützter privater Schlüssel) reicht, um die Verschlüsselung angreifbar zu machen – womit dann die Vertraulichkeit der gesamten Kommunikation und die Sicherheit meiner verschlüsselungswürdigen Daten gefährdet sind.
• Weitere Knackpunkte, etwa das Verwalten, Sichern und Aufheben der privaten Schlüssel, muss man auch irgendwie realisieren – wer seine Kommunikation komplett elektronisch organisiert, muss ja auch in ein paar Jahren noch an seine verschlüsselten Mails herankommen.

Das Verschlüsseln von Mails würde Geheimdiensten und anderen Schnüfflern das Mitlesen (etwas) schwerer machen, selbst wenn die Mailheader (quasi die Verbindungsdaten) weiter unverschlüsselt bleiben. In vielen Fällen aber wiegt der Sicherheitsgewinn den eklatanten Komfortverlust nicht auf. Oft wird die verschlüsselte Mail-Kommunikation wahrscheinlich ganz scheitern, sei es aus den beschriebenen technischen Gründen oder an den Kommunikationspartnern. Wer im Alltag sicher vertraulich kommunizieren will, muss also sehr oft auf E-Mail verzichten und stattdessen auf andere Anwendungen (wie verschlüsselte Chats) oder Tricks (PGP-verschlüsselte Dateien/Archive) ausweichen. Oder er schickt einen Brief…

Schade.

 

Linktipps für eigene Versuche

• S/MIME Zertifikatserstellung und -Signierung, kann als eigene self-signed-CA betrieben werden: XCA (cross-platform)
• Thunderbird kann sowohl S/MIME als auch PGP (Enigmail-Plugin) umgehen (cross-platform)
• GnuPG enthält alles, was man für die PGP-Schlüsselerzeugung und -Verwaltung braucht (Linux). Es gibt auch MacOS- und Windows-Pakete. Gpg4win kann auch mit S/MIME bzw. X.509-Zertifikaten umgehen und ist insofern eine Universallösung für Windows, es enthält außerdem ein Outlook-Plugin. Die Software-Entwicklung wurde vom Bundesamt für Sicherheit in der Informationstechnik (BSI) initiiert und gefördert.