Sichere E-Mail - jetzt

Der Charme der asymmetrischen Kryptographie liegt nun darin, dass das Schlüsselpaar auch umgekehrt eingesetzt werden kann: wird die Nachricht mit dem privaten Schlüssel verschlüsselt, kann jeder sie mit dem zugehörigen öffentlichen Schlüssel entschlüsseln (Abb. 2).  Somit bleibt die Nachricht zwar nicht vertraulich.  Wohl aber wird ein anderer Mehrwert erzielt, nämlich die Sicherung von Authentizität und Integrität: durch eine erfolgreiche Entschlüsselung, die einen lesbaren Klartext liefert, wird verifiziert, dass der Sender tatsächlich der Inhaber des zugehörigen privaten Schlüssels ist und dass der Nachrichtentext nicht unterwegs verändert wurde.  In der Praxis wird die Nachricht nicht verschlüsselt, sondern nur signiert: ein Hashcode der Nachricht (d.i. eine kondensierte Version) wird verschlüsselt, und das Resultat wird an den Klartext als digitale Unterschrift (auch Digitale Signatur, engl. digital signature) angehängt. Im übrigen ist es natürlich auch möglich, die Nachricht sowohl zu signieren als auch zu verschlüsseln.

Zwei seit Jahren etablierte und bewährte Ausprägungen asymmetrischer Verfahren für sichere E-Mail sind S/MIME (Secure Multipurpose Internet Mail Extensions) und PGP (Pretty Good Privacy). Sie unterschieden sich kaum in den eingesetzten Algorithmen, wohl aber in den verwendeten Datenformaten, und sind daher nicht miteinander kompatibel.  Jedes standardkonforme Mail-Programm unterstützt S/MIME. Für PGP gibt es entsprechende Programmerweiterungen, vorwiegend auf der Basis der GnuPG Software.  Komfortable Mail-Programme (ja, die gibt es) erledigen Ver- und Entschlüsselung sowie Signierung und Verifizierung selbsttätig, ohne weiteres Zutun des Benutzers, sobald die benötigten Schlüssel bereitstehen.  Die Erzeugung und Installation des Schlüsselpaars ist allerdings bei einigen Systemen wenig benutzerfreundlich, was der Hauptgrund für die mangelnde Akzeptanz der Verschlüsselung sein dürfte.  Es muss aber betont werden, dass es durchaus Lösungen gibt, die einen innerhalb von 5 Minuten in die Lage versetzen, am sicheren E-Mail-Verkehr teilzunehmen.

Die Sicherheit beim Einsatz der asymmetrischen Verschlüsselung steht und fällt damit, dass der jeweils verwendete öffentliche Schlüssel tatsächlich der des gewünschten Kommunikationspartners ist.  Gelingt es einem Angreifer, seinen eigenen öffentlichen Schlüssel als den meines Partners auszugeben, ist eine mit dem zugehörigen privaten Schlüssel signierte Nachricht nicht von diesem Partner – auch wenn sie so aussehen sollte.  Und eine verschlüsselt gesendete Nachricht an diesen Partner kann vom Angreifer abgefangen und entschlüsselt werden.  Täuscht der Angreifer in gleicher Weise meinen Partner, kann er sich unbemerkt in jeden gesichert erscheinenden Nachrichtenaustausch zwischen mir und meinem Partner einklinken (man-in-the-middle-Angriff).  Deshalb muss ich mich unbedingt davor schützen, dass mir für die Kommunikation mit meinem Partner ein falscher öffentlicher Schlüssel untergeschoben wird.  Mit anderen Worten: ich muss der Echtheit des öffentlichen Schlüssels vertrauen können.

Der wesentliche Unterschied zwischen S/MIME und PGP besteht nun im Vertrauensmodell: Worauf gründe ich mein Vertrauen in die Echtheit des öffentlichen Schlüssels eines Kommunikationspartners?  S/MIME arbeitet grundsätzlich mit Zertifikaten nach dem X.509-Standard, wie sie auch bei SSL/TLS-gesicherten Webseiten eingesetzt werden (mit dem https-Protokoll).  Ein Zertifikat umfasst im wesentlichen einen öffentlichen Schlüssel und eine Identitätsangabe des Schlüsselinhabers (im einfachsten Fall die E-Mail-Adresse, siehe Abb. 3).  Durch Hinzufügung der digitalen Unterschrift einer Zertifizierungsstelle (certification authority, CA) wird das Ganze fälschungssicher gemacht.  Für die Prüfung der Authentizität des Zertifikats ist daher die sichere Kenntnis des öffentlichen Schlüssels der Zertifizierungsstelle erforderlich; somit muss ein Zertifikat für die Zertifizierungsstelle vorliegen.  Damit das Ganze nicht in einen Teufelskreis mündet, muss es Wurzel-Zertifizierungsstellen (root CAs) geben, die als a priori vertrauenswürdig – d.h. in jedem Fall korrekt arbeitend – postuliert werden.  Deren sogenannte Stammzertifikate werden üblicherweise herstellerseitig in die Software eingebaut.  Jede Zertifizierungsstelle ist demnach direkt oder indirekt von einer Wurzel-Zertifizierungsstelle zertifiziert, so dass sich insgesamt eine hierarchisch strukturierte Zertifizierungs-Infrastruktur (public-key infrastructure, PKI) ergibt.  Zu beachten ist, dass ein gültiges, korrekt signiertes Zertifikat durchaus eine falsche Bindung Schlüssel↔Inhaber beinhalten kann, dass der Schlüssel also nicht echt ist – wenn nämlich der Aussteller des Zertifikats betrügerisch (oder technisch nachlässig) arbeitet.  Daher kann ich mich letztlich nur dann auf ein Zertifikat verlassen, wenn ich allen Zertifizierungsstellen in der Kette bis zur Wurzel vertrauen kann.

Sollte ich einer privatwirtschaftlich betriebenen Zertifizierungstelle vertrauen?  Immerhin könnte man positiv argumentieren, dass eine solche Stelle „bei Strafe des Untergangs“ korrekt arbeiten muss. Sollte ich einer staatlich betriebenen Stelle vertrauen?  Ist eine der Stellen vielleicht von der NSA unterwandert?  Reale Vorfälle haben gezeigt, dass Skepsis angebracht ist [1].  Es gibt mannigfache Gründe, das Vertrauensmodell der hierarchischen PKI grundsätzlich abzulehnen und stattdessen auf persönliches Vertrauen zu setzen.  PGP basiert auf einem Vertrauensmodell, das als Web of Trust (WoT) bezeichnet wird.  Wenn ich vorsichtig bin, glaube ich an die Echtheit eines öffentlichen Schlüssels nur dann, wenn er mir von jemandem, dem ich in dieser Hinsicht vertraue, als sein Schlüssel „persönlich“ übergeben wurde (dafür gibt es verschiedene technische Varianten).  Größere Flexibilität wird dadurch erreicht, dass globale Schlüsselverzeichnisse bereitgestellt werden und Zertifikate ähnlich wie bei einer PKI zum Einsatz kommen; diese werden aber nicht von Zertifizierungsstellen, sondern von individuellen Teilnehmern ausgestellt.  Der Grad meines Vertrauens in ein solches Zertifikat hängt dann von zweierlei ab: Wie hoch ist mein Vertrauen in die Echtheit des öffentlichen Schlüssels des Signierenden?  Wie hoch ist mein Vertrauen in die Rechtschaffenheit und Sorgfalt des Signierenden?  Das WoT hat zudem noch weitere Probleme, weshalb PGP auch nicht gerade als Ideallösung gelten kann [5].

Eine erschöpfende Diskussion der jeweiligen Vor- und Nachteile der beiden Vertrau-ensmodelle würde den Rahmen dieses Beitrags sprengen.  Es liegt auf der Hand, dass S/MIME zwar einfacher zu benutzen ist als PGP mit seinem WoT, den Benutzer aber zwingt, sich auf Zertifizierungsstellen zu verlassen, deren Vertrauenswürdigkeit er schwer einschätzen kann.  Das betrifft nicht nur die Zertifikatserstellung, sondern auch die vorangehende Schlüsselgenerierung.  Typische Zertifizierungsstellen erlauben eine Web-basierte Erzeugung von Schlüsselpaar und Zertifikat.  Dabei werden die Schlüssel zwar auf dem Gerät des Benutzers erzeugt und „der private Schlüssel verlässt nie Ihr Gerät!“.  Der Nichtexperte kann das aber nicht überprüfen; er muss sich auf den Aussteller verlassen.  Bei PGP dagegen liegt alles in der Hand des Benutzers: typi-scherweise erzeugt er mit quelloffener Software lokal das Schlüsselpaar, und auch für den weiteren Umgang mit dem öffentlichen Schlüssel ist er zunächst selbst zuständig.

Es gibt eine ganze Reihe von Gründen – vor allem historischer Natur – für die aktuell größere Sichtbarkeit von PGP gegenüber S/MIME.  Ausschlaggebend ist wohl, dass PGP dem technisch versierten Informatiker die vollständige Hoheit über sichere Verschlüsselung gibt und ihn nicht von undurchsichtigen Zertifizierungsstellen abhängig macht (die zudem womöglich Geld verlangen).  Dies hat zu der unglücklichen Entwicklung geführt, dass die Informatiker mit PGP eine für den Normalbürger schwie-riger zu handhabende Technik verbreitet haben, anstatt auf die Propagierung vertrauenswürdiger und kostenloser Zertifizierungsstellen für S/MIME zu setzen. 

Aber wie wichtig ist sichere E-Mail überhaupt für den „Normalbürger“?  Edward Snowden ist es zu verdanken, dass die Unsicherheiten im Netz ins allgemeine Bewusstsein gerückt sind.  Vor allem die Sorge um den Schutz der Privatsphäre vor illegalen Lausch-angriffen und globaler Überwachung ist stark gewachsen.  Es reift die Erkenntnis, dass die grundgesetzlich geschützte Vertraulichkeit der Kommunikation im Netz [4][2] auf technischer Ebene keineswegs geschützt ist.  Für E-Mail liegt es auf der Hand, wie ein verfassungskonformer Zustand hergestellt werden könnte – durch flächendeckende Verschlüsselung.  Es kann nicht darum gehen, ob der Einzelne „nichts zu verbergen“ hat, ob E-Mail mehr einer Postkarte als einem Brief entspricht, ob es demzufolge dem Einzelnen überlassen bleiben soll, sich von Fall zu Fall für oder gegen Verschlüsselung zu entscheiden.  Es geht darum, ob wir dem Sammeln von Big Data aus E-Mail-Inhalten und -Metadaten unter Verletzung von Grundrechten (und für welche Zwecke auch immer) grundsätzlich einen Riegel vorschieben wollen.  Wenn wir das für die Metadaten mit existierender Technologie heute noch nicht können, sollten wir es jedenfalls für die Inhalte tun.

Das Ziel einer flächendeckenden E-Mail-Verschlüsselung auf der Basis existierender Standards ist nur dann zu erreichen, wenn alles, was mit der E-Mail-Sicherung zusammenhängt, für Erika Mustermann einfachstmöglich zu handhaben ist.  Dies spricht dafür, S/MIME den Vorzug gegenüber PGP zu geben:  

1. Interoperabilität zwischen allen gängigen Mail-Programmen muss ohne Modifikationen und Add-ons gewährleistet sein; der Einsatz von S/MIME erlaubt dies.
2. Die Mail-Programme müssen so gestaltet sein, dass sie Verschlüsselung und Signierung gemäß S/MIME im Normalfall vollautomatisch handhaben; im Fehlerfall müssen sie benutzerfreundlich reagieren.  Positive Beispiele für solche Mail-Programme gibt es.
3. Die Schlüsselerzeugung und -zertifizierung sowie die Installation der Schlüssel im Gerät muss dem Ideal eines „Ein-Klick-Dienstes“ nahekommen.  Auch hierfür gibt es positive Beispiele.
4. Dieser Dienst muss über eine Web-basierte, quelloffene Software kostenlos von neutralen Zertifizierungsstellen angeboten werden, die vertrauenswürdig organisiert sind (das Wahllokal mag als Analogon dienen).

Im Hinblick auf Punkt 4 bleiben zwei offene Fragen: Wie werden die gewünschten Zertifizierungsstellen eingerichtet und betrieben, und wer trägt eine bundesweite (europa-weite?) Kampagne, die die Bürger darauf aufmerksam macht und sie zum Handeln be-wegt?  Die natürliche Antwort darauf wäre:  Die Regierung ist hier in der Pflicht, denn sie muss die Grundrechte der Bürger schützen.  Dort, wo der Bürger selbst etwas dazu tun muss (hier: Zertifikat erwerben und E-Mail sichern), muss sie es ihm so einfach wie möglich machen.  Und die notwendige Überzeugungsarbeit (Analogon: „Gehen Sie wählen!“) wäre Aufgabe sowohl der Politik als auch der Bildungsinstitutionen und der Medien. 

Es ginge aber auch anders.  Nichts hindert potente Organisationen und/oder Einzelpersonen daran, selbst eine Zertifizierungsstelle mit den gewünschten Eigenschaften einzurichten.  Vielleicht findet sich ja ein staatsbürgerlich engagierter Mäzen, der hier in die Bresche springt, eine Zertifizierungsstelle schafft und eine Kampagne organisiert.

Sind vielleicht auch noch völlig andere Ansätze denkbar?  Es gibt viel berechtigte Kritik an S/MIME und PGP, und tatsächlich ist der Einsatz dieser traditionellen Techniken keineswegs alternativlos für die Sicherung von Nachrichten im Netz.  Es ist sogar davon auszugehen, dass wir diesbezüglich bereits in wenigen Jahren mit einer sehr heterogenen Szene konfrontiert sein werden.  Zunächst gibt es bekanntlich – jenseits der klassischen E-Mail –  unter den Apps für Smartphones zunehmend solche mit mehr oder weniger guten Sicherungsmöglichkeiten.  Sodann hat es auch bei der eigentlichen E-Mail in jüngster Zeit – wohl durch Snowden beschleunigt – etliche Versuche gegeben, auf einem entstehenden Markt für sichere Varianten Fuß zu fassen.  Fast allen diesen Versuchen ist gemein

1. der kommerzielle Ansatz,
2. der Anspruch guter Benutzerfreundlichkeit,
3. der Anspruch hoher Sicherheit,
4. die Inkompatibilität mit S/MIME und PGP.

  Die Bedeutung von Punkt 2 ist augenfällig angesichts der Schwächen existierender Mail-Programme bei der Unterstützung von S/MIME bzw. PGP.  Beim Punkt 3 versucht man vor allem, das oben erläuterte Vertrauens-Management entbehrlich zu machen.  Jedes System mit der Eigenschaft 4 hat natürlich mit dem Problem zu kämpfen, dass es nur innerhalb einer darauf eingeschworenen Gemeinschaft einsetzbar ist.  Im übrigen gibt es auch zahlreiche nichtkommerzielle Projekte, die teilweise radikal mit existierenden Ansätzen brechen.  Der interessierte Leser kann sich im Netz z.B. über Qabel, Pond (imperialviolet), pEp (pretty easy privacy), Dark Mail u.v.a. informieren.  Die Szene ist stark in Bewegung, und es ist davon auszugehen, dass wir durch immer neue Ansätze überrascht werden.  Angesichts der damit weiter zunehmenden Heterogenität wäre die Politik aufgerufen, Rahmenbedingungen zur zügigen Beförderung flächendeckender E-Mail-Sicherheit zu schaffen – bundesweit und europaweit.  Es bleibt zu hoffen, dass die Regierungen hier nicht länger zögern.

Für hilfreiche Anregungen danke ich Jochen Ludewig (Universität Stuttgart) und Volker Roth (Freie Universität Berlin).

Genaueres über S/MIME und Public-Key-Zertifikate sowie über OpenPGP und das Web of Trust kann man schnell und gut bei Wikipedia erfahren.  Die Gesellschaft für Informatik hat Fragen und Antworten sowie weitere Links zur E-Mail-Sicherheit und zu konkreten Anleitungen zur Verschlüsselung unter www.gi.de/e-mail-sicherheit bereitgestellt.

1. Arnbak A, Asghari H, van Eeten M, van Eijk N (2014)  Security Collapse in the HTTPS Market.  Comm. of the ACM 57(10):47-55
2. Bundesverfassungsgericht (2008)  (Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme)  www.bundesverfassungsgericht.de/entscheidungen/rs20080227_1bvr037007.html  (12.12.2014)
3. Ferguson N, Schneier B, Kohno T (2010)  Cryptography Engineering – Design Principles and Practical Applications.  John Wiley & Sons, Hoboken
4. Grundgesetz, Art. 10 (Briefgeheimnis). www.gesetze-im-internet.de/gg/art_10.html (12.12.2014).  Siehe auch Telekom-munikationsgesetz, Teil 7, Abschnitt 1 (Fernmeldegeheimnis).  www.gesetze-im-internet.de/tkg_2004/  (12.12.2014)
5. Perry M (2013)  Why the Web of Trust Sucks.  lists.torproject.org/pipermail/tor-talk/2013-September/030235.html  (12.12.2014)
6. Schmeh K (2013)  Kryptographie: Verfahren, Protokolle, Infrastrukturen.  dpunkt.verlag, Heidelberg

Klaus-Peter Löhr

Freie Universität Berlin

E-Mail

© Springer Verlag Berlin Heidelberg 2015