Verschlüsseln ist sinnvoll, heißt es überall. Doch fast niemand nutzt PGP oder S/MIME. Wir untersuchen, wie benutzerfreundlich die Krypto-Unterstützung der drei großen Mailer KMail, Thunderbird und Evolution ist.
Die wenigsten Internet-Nutzer sind sich dessen bewusst, wie unsicher eine E-Mail auf dem Weg vom Sender zum Empfänger ist. Durchläuft der klassische Brief eine prinzipiell nachvollziehbare Kette vom Briefkasten bis hin zum Empfänger, geht eine E-Mail unvorhersagbare Wege. Jeder, der ein Stück des Weges bereitstellt, hat Zugriff auf die Daten und kann mitlesen oder sie verändern.
Dabei ist es einfach, sowohl das Mitlesen zu verhindern, als auch die Unversehrtheit der Nachricht sicherzustellen. Verschlüsseln sorgt für Vertraulichkeit, Signieren dient als Identitätsnachweis und sorgt dafür, dass niemand die Nachricht unbemerkt verändern kann. Dafür existieren zwei freie Standardverfahren, PGP und S/MIME – doch kaum jemand nutzt sie.
Dieser Artikel untersucht, wo die Probleme beim Verschlüsseln liegen und wie gut die E-Mail-Programme Evolution 1.4, Thunderbird 0.73 und KMail 1.7 sie lösen.
Kompliziertes Prinzip
Ein zentrales Problem bei PGP und S/MIME ist das schwer verständliche Prinzip der asymmetrischen Schlüssel (siehe Kasten “Kryptographie mit PGP und S/MIME”). Fragen Sie fünf Bekannte, wie die Verschlüsselung und die Signierung funktionieren. Mit viel Glück werden Sie, nach langem Nachdenken, einige richtige Antworten bekommen.
Auch die Begrifflichkeiten sind eher irreführend. Ein normaler Schlüssel kann auf- und zuschließen – die asymmetrische Kryptographie funktioniert jedoch mit zwei Schlüsseltypen: öffentlichen zum Verschlüsseln (Zuschließen) und geheimen zum Entschlüsseln (Aufsperren).
Für Verwirrung sorgt auch der Begriff “Signatur”: Er bezeichnet einerseits die kryptographische Signatur, eine mit dem geheimen Schlüssel des Absenders aus dem E-Mail-Text generierte Prüfsumme, andererseits die Absenderdaten, die viele Anwender ans Ende ihrer Mails setzen.
Bei solchen Verständnisproblemen hilft bessere Aufklärung der Nutzer. Mail-Programme sollten durch verständliche Benutzeroberflächen und Hilfetexte die Nutzer für das Thema sensibilisieren und Fehler durch geeignete Voreinstellungen verhindern. Die Oberflächen müssen den Nutzer unaufdringlich über die Möglichkeiten und Konsequenzen seines Tuns aufklären.
E-Mails verschlüsseln in der Praxis
Eine der größten Einstiegshürden entsteht, wenn die Verschlüsselungs-Tools standardmäßig nicht mitinstalliert werden. Für “normale Nutzer” ist die Erfolgschance dann sehr gering, die Sicherheitsfunktionen überhaupt nutzen zu können. Dies ist im Wesentlichen die Entscheidung der Distributoren. Es ist wünschenswert, dass notwendige Programme wie eine Schlüsselverwaltung in jedem Fall mitgeliefert und installiert werden.
Idealerweise sollte die Verwaltung der Schlüssel dort erreichbar sein, wo sie relevant ist, in unserem Fall also bei der Einrichtung eines E-Mail-Kontos oder bei der Konfrontation mit Schlüsseln bzw. Zertifikaten. Dazu gehört auch, dass man öffentliche und private Schlüssel importieren kann.
Thunderbird
Bei Thunderbird ist die S/MIME-Integration vergleichsweise gut gelöst, sie ist über die zentrale Konfiguration erreichbar. Dort kann man nicht nur Zertifikate importieren, sondern auch die bereits erhaltenen öffentlichen Schlüssel einsehen und bearbeiten. Öffentliche S/MIME-Schlüssel speichert Thunderbird automatisch, eigene lassen sich per Auswahldialog hinzufügen.
Für PGP muss man zunächst die Erweiterung Enigmail herunterladen und installieren. Dies erwies sich auf einigen Testrechnern mit einer älteren, später aktualisierten Thunderbird-Version als problematisch.
Nach der Installation erscheint ein eigenes Enigmail-Menü in der Hauptleiste. Trotzdem muss man in den Einstellungen einen Pfad zur GPG-Anwendung setzen. Wo diese zu finden ist, wird nicht erklärt. Hier wäre z. B. eine automatische Erkennung über den Befehl which gpg sinnvoll. Eine Übersicht der verfügbaren Schlüssel ist über das Menü überhaupt nicht zu erreichen. Öffentliche Schlüssel übernimmt Enigmail nicht automatisch. Erst durch Zufall stellt man fest, dass unter den Konteneinstellungen ein weiterer Eintrag OpenPGP Sicherheit aufgetaucht ist. Dort kann man immerhin den eigenen Schlüssel über eine Liste auswählen.
Enigmail bietet auch das Erzeugen eines neuen Schlüsselpaars an. Das Dialogfeld ist jedoch ein Beispiel dafür, wie sicherheitskritische Benutzerführung nicht sein sollte (Abbildung 1). Weder erklärt es das Konzept von asymmetrischen Schlüsseln (es gibt keine Hilfe), noch vermittelt es grundlegende Sicherheitsvorkehrungen. Die Sicherheit eines Schlüssels hängt wesentlich davon ab, wie leicht er zu “knacken” ist. Entscheidend dafür ist unter anderem die Länge der so genannten Passphrase, für die der Anwender am besten einen ganzen Satz wählt. Enigmail beschriftet das Feld dagegen mit Passwort und weckt so falsche Vorstellungen. Auch Informationen zu Schlüsseltiefe oder Algorithmus fehlen. “Einfachheit” wurde hier falsch verstanden.

Abbildung 1: Im Dialog, in dem man einen neuen Schlüssel in Thunderbird/Enigmail erzeugt, fehlen grundlegende Informationen, etwa zum “Passwort”, Ort der Schlüssel, oder der Funktionsweise asymmetrischer Schlüssel.
Signierte und verschlüsselte Mails stellt Thunderbird im Allgemeinen vorbildlich mit einem kleinen Icon über der E-Mail dar. Bestimmte PGP-Signaturen präsentiert es jedoch mit der für Anfänger paradoxen Meldung: “UNVERTRAUT Korrekte Unterschrift von …”. Hinter dem vermeintlichen Widerspruch steckt das Konzept des Web of trust (siehe Kasten), in dem Nutzer zum Beispiel auf Keysigning-Partys gegenseitig ihre Schlüssel signieren und sich damit ihr “Vertrauen” aussprechen. Das vermittelt Enigmail dem Neuling nicht – und um den Schlüssel selbst zu signieren, muss er auf die Kommandozeile ausweichen.
Evolution
Der Mail-Client Ximian Evolution 1.4 unterstützt kein S/MIME, jedoch “theoretisch” PGP. Allerdings ist die Konfiguration für den normalen Nutzer äußerst schwierig. Die Konteneinstellung Sicherheit konfrontiert ihn mit einer Eingabemaske, bei der er kaum verstehen kann, was von ihm verlangt wird. Tatsächlich muss er die ID seines PGP-Schlüssels eintragen, eine Beschreibung oder ein Hilfe-Link fehlt (Abbildung 2). Optionen wie Beim Verschicken verschlüsselter E-Mails immer vor mir selbst verschlüsseln verwirren noch mehr. Sucht man intensiv in der Evolution-Hilfe, findet man schließlich eine kleine Anleitung, wie man Schlüssel generiert und benutzt – auf der Kommandozeile. Diese erklärt auch, wie man die Schlüsselnummer erfährt.

Abbildung 2: Evolution “unterstützt” zwar PGP, mit der Oberfläche lässt es den Nutzer jedoch allein. Erklärungen oder ein Hilfelink fehlen.
PGP-Signaturen stellt Evolution als Klammer um den eigentlichen Nachrichtentext dar. Erhält der Nutzer eine verschlüsselte Nachricht, fordert der Mailer ihn auf, seine Passphrase einzugeben. Nach drei Fehlversuchen fehlt ein Hinweis, wie er nochmals die Eingabe vornehmen kann: Ein Doppelklick auf die Mail ist die Antwort.
Insgesamt ist Verschlüsselung in Evolution schwach integriert. Man muss sehr genau wissen, was man erreichen will. Grundlegende Funktionen, zum Beispiel zur Verwaltung des Schlüsselbunds, fehlen im Menü, so dass der Anwender oft auf die Kommandozeile zurückgreifen muss. Das kann aber für viele Nutzer nur eine Übergangslösung sein.
KMail
Die aktuelle KMail-Version aus KDE 3.3 unterstützt mittlerweile auch S/MIME, braucht dazu jedoch eine neuere GPGME-Bibliothek als die bei vielen Distributionen mitgelieferte. Ansonsten sind die Punkte im Einstellungsmenü ausgegraut. PGP hingegen ist seit langem integriert, wenngleich der Nutzer auch hier für manche Funktionen die Kommandozeile oder ein Schlüsselverwaltungs-Tool bemühen muss. Es gibt zwar einen Button zum Einlesen des privaten Schlüssels, so dass man diesen wenigstens nicht von Hand eintragen muss, doch öffentliche Schlüssel automatisch aus empfangenen E-Mails zu importieren, ist nicht möglich.
Mit PGP verschlüsselte und signierte Mails stellt KMail ähnlich wie Evolution dar. Mit auffälligen, flächigen Farben weist es auf eine gültige, aber nicht verifizierbare Signatur hin. Dies ist prinzipiell sehr sinnvoll, weil es die Aufmerksamkeit des Nutzers weckt.

Abbildung 4: Nicht zu übersehen: Auf PGP-signierte E-Mails, die KMail wegen fehlender öffentlicher Schlüssel nicht überprüfen kann, weist es den Nutzer mit einer Warnfarbe hin.
Fazit
Verschlüsseln und Signieren dürfte für viele Anwender mit den drei aufgeführten E-Mail-Programmen gegenwärtig schwierig bis unmöglich sein. Dies liegt unter anderem an der mangelnden Integration von Backend und E-Mail-Applikation. Hier wird sich mit hoher Wahrscheinlichkeit in den nächsten Versionen zumindest von Evolution und KMail etwas tun.
Doch neben diesen technischen Herausforderungen muss sich auch die Benutzerführung deutlich verbessern. Zu oft wird der Nutzer gerade bei einem solch komplexen Thema mit unverständlichen Dialogen oder Meldungen konfrontiert. In dieser Situation bleibt E-Mail-Sicherheit etwas für Experten, die sowohl fundierte Linux-Kenntnisse haben, als auch die Funktionsweise der Verschlüsselung bereits vorher verstanden haben.
Kryptographie mit PGP und S/MIME
Sowohl S/MIME als auch PGP verwenden asymmetrische Schlüssel: einen privaten (private oder secret key) und einen öffentlichen (public key). Den durch eine Passphrase geschützten privaten Schlüssel sollte jeder Anwender sicher verwahren. Den öffentlichen Schlüssel verteilt er bei PGP per E-Mail oder über einen öffentlichen Keyserver an alle, die ihm verschlüsselt mailen wollen. Bei S/MIME verwaltet ein Verzeichnisdienst zentral die öffentlichen Schlüssel.
Zum Verschlüsseln benutzt der Absender den öffentlichen Schlüssel des Empfängers. Dessen privater Schlüssel verwandelt den Zeichensalat zurück in eine lesbare Nachricht.
Signiert wird eine E-Mail mit dem eigenen privaten Schlüssel. Der Empfänger verifiziert die Signatur dann mit dem öffentlichen Schlüssel des Absenders.
Verschlüsselt und signiert man eine E-Mail, so wird zunächst mit dem eigenen privaten Schlüssel signiert, und dann mit dem öffentlichen Schlüssel des Empfängers verschlüsselt.
Der zentrale Unterschied zwischen PGP und S/MIME besteht darin, wie sie die Authentizität der Schlüssel gewährleisten, also die Frage beantworten: Woher weiß ich, dass ein Schlüssel wirklich zu einer Person gehört?
Bei S/MIME gibt eine autorisierte Zertifizierungsstelle (Certificate Authority, CA) aufgrund verschiedener Überprüfungsstufen einen Schlüssel heraus (“Zertifikat”). Die oberste CA legitimiert weitere CAs dazu, Schlüssel herauszugeben. Letztlich steht dahinter also ein hierarchisches System von Zertifikaten.
Bei PGP wird ein Schlüssel durch die Signaturen anderer PGP-Schlüssel vertrauenswürdig. Wer einen Schlüssel signiert, bestätigt damit, dass er die Identität des Schlüsselträgers überprüft hat. Dies geschieht zum Beispiel auf so genannten “Key signing parties”. Damit entsteht ein “Web of trust” (Vertrauensnetz), dessen Glaubwürdigkeit von der Verlässlichkeit der Teilnehmer und der gewissenhaften wechselseitigen Überprüfung der Identität abhängt.





