Teil 1: Wie funktioniert das?

Grundlagen der E-Mail-Verschlüsselung
Keine Kommentare

Eine E-Mail ist wie eine Postkarte in der Briefpost: Wer sie sieht, kann sie lesen. Deshalb sollte man eigentlich nur verschlüsselte E-Mails verschicken, die das unbefugte Lesen verhindern. Zusätzlich (aber auch unabhängig davon) kann man seine Mails mit einer digitalen Signatur vor unerkannten Manipulationen schützen und seine Identität als Absender beweisen.

Generell gibt es für die Mailverschlüsselung zwei Ansätze:

  1. Die klassische E-Mail-Verschlüsselung und -Signatur erfolgen von Client zu Client (Ende-zu-Ende-Verschlüsselung). Das ist auch die sicherste Lösung, da die E-Mail außerhalb der Rechner von Sender und Empfänger nur verschlüsselt vorliegt.
  2. Clientbasierte Lösungen sind für viele Organisationen zu komplex, sodass man dort auf eine serverbasierte Lösung zurückgreift: Der Mailserver des Absenders oder ein spezialisiertes Verschlüsselungsgateway verschlüsselt und signiert die Mails im Namen des jeweiligen Absenders und sendet das Ergebnis an den Empfänger. Beim Empfang einer E-Mail läuft das Ganze analog in der anderen Richtung ab: Mailserver oder Verschlüsselungsgateway entschlüsseln die Mail und liefern sie als Klartext zusammen mit dem Ergebnis der Signaturprüfung an den Empfänger aus. Dabei ist es egal, ob die jeweilige Gegenseite selbst eine Client- oder Serverlösung einsetzt.

Serverbasierte Lösungen haben den Nachteil, dass die Nachrichten auf dem Server unverschlüsselt und beim Senden auch unsigniert vorliegen und dort ausgespäht oder manipuliert werden können. Relativiert wird dies dadurch, dass im Allgemeinen nur die eigenen Admins Zugriff auf den Server haben, und man denen generell vertrauen muss.

Artikelserie

Teil 1: Grundlagen der E-Mail-Verschlüsselung
Teil 2: EFAIL

Im Folgenden werde ich von der klassischen Clientlösung ausgehen. Mit Servern funktioniert das Beschriebene aber im Grunde genauso. Der Server verhält sich technisch gesehen gegenüber dem Kommunikationspartner wie ein normaler Client. Sofern es dem Kommunikationspartner nicht explizit oder indirekt (z. B. durch Headereinträge etc.) mitgeteilt wird, kann er auch gar nicht erkennen, ob die Mails auf der Gegenseite schon im Mailclient oder erst auf dem Mailserver ver- bzw. entschlüsselt werden und wo Signatur und Signaturprüfung stattfinden.

De-Mail ist keine Verschlüsselung

An dieser Stelle ein Hinweis auf die De-Mail: Laut Gesetz soll sie „einen sicheren, vertraulichen und nachweisbaren Geschäftsverkehr für jedermann im Internet sicherstellen“ (De-Mail-Gesetz, §1). Das tut sie aber nicht. Sie kennen vielleicht noch den Vorspann vom A-Team, über das es heißt: „Sie wollen nicht ganz ernst genommen werden, aber ihre Gegner sollten sie ernstnehmen“. Bei der De-Mail ist es genau anders rum: Sie möchte ernst genommen werden, aber als Benutzer sollte man es nicht tun. Jedenfalls nicht im Sinne einer E-Mail-Verschlüsselung.

De-Mail-Nachrichten werden nur während des Transports verschlüsselt übertragen und liegen zwischendurch auf den Servern als Klartext vor, sodass sie dort ausgespäht werden können. Auch die Signatur erfolgt gegebenenfalls durch die Server. Im Unterschied zur oben vorgestellten Serverlösung sind diese Server aber nicht Bestandteil des eigenen abgeschotteten Netzes, sondern werden von „vertrauenswürdigen Dritten“ im Internet betrieben. Egal, wie sehr diese Server abgesichert werden, und egal, wie viele Zertifizierungen die Betreiber brauchen, diese Server sind ein dermaßen verlockendes Ziel für sämtliche Geheimdienste und Cyberkriminellen, dass man darum einen großen Bogen machen sollte.

Optional ist eine Ende-zu-Ende-Verschlüsselung der Nachrichten durch die Nutzer möglich, aber die kann man unabhängig von der De-Mail genau so gut erreichen. Der einzige Vorteil der De-Mail-Nachrichten ist der Nachweis, dass eine Nachricht angekommen ist.

Zurück zur Mail

Die Verschlüsselung von E-Mails ist eigentlich schon seit ihrer Erfindung möglich. Alles, was man braucht, sind ein Kryptoverfahren und passende Schlüssel. Die Kryptoverfahren sind im Kasten „Kryptoverfahren im Überblick“ beschrieben, symmetrische Verfahren gab es schon lange bevor es E-Mails gab.

Kryptoverfahren im Überblick

Symmetrische Verschlüsselungsverfahren

Die klassischen Verschlüsselungsverfahren sind symmetrische Verfahren: Es gibt einen Schlüssel, der sowohl zur Ver- als auch zur Entschlüsselung dient (Abb. 1).

Abb. 1: Symmetrische Verschlüsselung

Abb. 1: Symmetrische Verschlüsselung

Die symmetrische Verschlüsselung für zwei Teilnehmer können Sie sich als einen undurchsichtigen Kasten mit einem Schloss vorstellen, zu dem es zwei gleiche Schlüssel gibt. Jeder, der einen Schlüssel besitzt, kann etwas in den Kasten hineinlegen (= verschlüsseln) oder herausnehmen (= entschlüsseln). Gibt es mehr Teilnehmer, bekommt jeder weitere ebenfalls einen Schlüssel. Das bekannteste symmetrische Verfahren ist der Advanced Encryption Standard AES.

So viele Schlüssel …

Die großen Nachteile symmetrischer Verfahren sind der Austausch der geheim zu haltenden Schlüssel und deren große nötige Anzahl.

Der Schlüsselaustausch ist kein Problem, wenn sich die Kommunikationspartner persönlich treffen und dabei den Schlüssel austauschen können. Ohne direkte Begegnung wird ein sicherer Austausch jedoch schwierig, auch wenn es auch dafür sichere kryptografische Verfahren gibt.

Schwerwiegender ist die große Anzahl auszutauschender Schlüssel: Damit n Teilnehmer miteinander kommunizieren können, müssen n(n-1)/2 Schlüssel ausgetauscht werden, bei zehn Teilnehmern also bereits 45. Für E-Mails ist das doch ziemlich unpraktisch.

Theoretisch könnte auch ein gemeinsamer Schlüssel verwendet werden. Das geht aber nur, wenn alle Teilnehmer alle Nachrichten lesen dürfen. Sobald zwei (oder auch mehr) Teilnehmer unbeobachtet von den anderen kommunizieren wollen, benötigen sie jeweils eigene Schlüssel. Daher müssen im Allgemeinen alle Teilnehmer mit allen anderen individuelle Schlüssel austauschen.

Asymmetrische Verschlüsselungsverfahren

Asymmetrische Verfahren wurden entwickelt, um die Schlüsselverteilung zu vereinfachen. Zum Ver- und Entschlüsseln werden verschiedene Schlüssel c und d verwendet, die mathematisch voneinander abhängen. Nur der Dechiffrierschlüssel d muss geheim gehalten werden, der Chiffrierschlüssel c kann (und soll) veröffentlicht werden (Abb. 2), weshalb man asymmetrische Verfahren auch als Public-Key-Verfahren bezeichnet.

Abb. 2: Asymmetrische Verschlüsselung bzw. Public-Key-Verschlüsselung

Abb. 2: Asymmetrische Verschlüsselung bzw. Public-Key-Verschlüsselung

Der öffentliche (Chiffrier-)Schlüssel heißt auch Public Key bzw. öffentlicher Schlüssel, der geheime (Dechiffrier-)Schlüssel auch Private oder Secret Key bzw. privater Schlüssel.

Ein asymmetrisches Verschlüsselungsverfahren können Sie sich als einen undurchsichtigen Kasten mit einem Schnappschloss vorstellen, zu dem es nur einen Schlüssel gibt. Jeder kann etwas hineinlegen, aber nur der Besitzer des einzigen Schlüssels kann es wieder herausnehmen.

Das bekannteste asymmetrische Verfahren ist das nach den Initialen der Nachnamen seiner Erfinder Ronald L. Rivest, Adi Shamir und Leonard Adleman benannte RSA-Verfahren.

Symmetrische Authentifikationssysteme

Authentifikationssystem stellen sicher, dass eine Nachricht nicht unbemerkt manipuliert werden kann, sie schützen also die Integrität der Nachricht. Die Nachricht wird um einen Prüfwert erweitert, den sogenannten Message Authentication Code (MAC), der in Abhängigkeit von einem geheimen Schlüssel aus der Nachricht berechnet wird. Bei einem symmetrischen Authentifikationssystem berechnet der Empfänger seinerseits den MAC mit seiner Kopie des Schlüssels und vergleicht ihn mit dem übertragenen Wert. Stimmen beide überein, wurde die Nachricht nicht verändert (Abb. 3).

Abb. 3: Symmetrische Authentifikation

Abb. 3: Symmetrische Authentifikation

Ein symmetrisches Authentifikationssystem können Sie sich als einem Glaskasten mit Schloss vorstellen, zu dem es zwei gleiche Schlüssel gibt. Jeder, der einen Schlüssel besitzt, kann etwas hineinlegen bzw. durch Aufschließen prüfen, ob das Schloss noch intakt ist, also kein Dritter den Inhalt ausgetauscht und das zu diesem Zweck aufgebrochene Schloss durch ein anderes ersetzt hat.

Asymmetrische Authentifikationssysteme

Symmetrische Authentifikationssysteme haben dieselben Nachteile beim Schlüsselaustausch wie symmetrische Verschlüsselungsverfahren. Asymmetrische Authentifikationssysteme vereinfachen den Schlüsselaustausch analog zu asymmetrischen Verschlüsselungsverfahren, indem sie einen geheimen Schlüssel zur Berechnung des MACs verwenden, der dann mit dem zugehörigen öffentlichen Schlüssel geprüft werden kann (Abb. 4).

Abb. 4: Asymmetrische Authentifikation bzw. digitales Signatursystem

Abb. 4: Asymmetrische Authentifikation bzw. digitales Signatursystem

Ein asymmetrisches Authentifikationssystem können Sie sich als einen Glaskasten mit Schloss vorstellen, zu dem es nur einen Schlüssel gibt: Nur der Besitzer des Schlüssels kann etwas hineinlegen. Jeder Dritte kann prüfen, ob der Kasten korrekt verschlossen wurde. Ist das der Fall, wurde der Inhalt vom Schlüsselinhaber hineingelegt und danach von niemandem verändert.

Digitale Signaturen

Asymmetrische Authentifikationssysteme können nicht nur verwendet werden, um die Integrität einer Nachricht zu prüfen, sondern auch die Identität des Absenders. Bei einem asymmetrischen Authentifikationssystem kann nur derjenige den MAC berechnen, der den geheimen Schlüssel kennt. Asymmetrische Authentifikationssysteme werden daher auch als (digitale) Signatursysteme bezeichnet.

Hybride Verfahren

Symmetrische Verfahren lassen sich im Allgemeinen einfacher und damit schneller berechnen als asymmetrische Verfahren. Dafür ist dort der Schlüsselaustausch viel einfacher. Bei einem hybriden Verfahren werden ein symmetrisches und ein asymmetrisches Verfahren kombiniert, um in den Genuss der Vorteile beider Verfahren zu kommen. Das funktioniert folgendermaßen (Abb. 5):

  1. Die Nachricht wird mit einem zufällig erzeugten Sitzungsschlüssel mit einem symmetrischen Verfahren, im Beispiel AES, verschlüsselt.
  2. Der Sitzungsschlüssel wird danach mit dem öffentlichen Schlüssel eines asymmetrischen Verfahrens, im Beispiel RSA, verschlüsselt und zur verschlüsselten Nachricht hinzugefügt.
  3. Der Empfänger verwendet seinen geheimen Schlüssel des asymmetrischen Verfahrens, um den Sitzungsschlüssel zu entschlüsseln.
  4. Danach kann er damit die eigentliche Nachricht entschlüsseln.
Abb. 5: Ein hybrides Verschlüsselungsverfahren, aufgebaut aus AES und RSA

Abb. 5: Ein hybrides Verschlüsselungsverfahren, aufgebaut aus AES und RSA

Ein Problem bei symmetrischen Verfahren ist also der Austausch der Schlüssel. Die asymmetrischen Verfahren lösen dieses Problem. Deren öffentlicher Schlüssel muss nicht geheim gehalten werden und kann z. B. in einem Verzeichnis hinterlegt werden. Wenn sich dann auch noch jemand Vertrauenswürdiges findet, der bestätigt, dass ein bestimmter öffentlicher Schlüssel zu einer bestimmten Person gehört, macht das das Ganze noch einfacher.

Da ja ohnehin ein asymmetrisches Verfahren verwendet wird, das auch als Signatursystem dienen kann, könnte dieser vertrauenswürdige Dritte z. B. eine Bestätigung wie „Dieser öffentliche Schlüssel gehört John Doe“ signieren. Jeder, der den öffentlichen Schlüssel des Dritten kennt, kann diese Signatur prüfen. Vertraut er dem Dritten, kann er danach sicher sein, wirklich den echten öffentlichen Schlüssel von John Doe vor sich zu haben, damit dann Nachrichten an John Doe verschlüsseln und Signaturen von ihm prüfen. Dieses Vertrauen ist wichtig, weil man wirklich sicher sein muss, dass ein bestimmter öffentlicher Schlüssel auch wirklich demjenigen gehört, dem er gehören soll. Sonst könnte ein Cyberkrimineller gefälschte öffentliche Schlüssel verbreiten und sich als die betreffende Person ausgeben. Ohne Identitätsprüfung kann man es also lassen.

Bist Du Dagobert?

Nehmen wir mal an, in Entenhausen gibt es den Freemailer duckmail.example, der natürlich Dagobert Duck gehört. Die Panzerknacker registrieren für sich dort die Adresse dagobert.duck@ duckmail.example und verbreiten einen Schlüssel, der angeblich Dagobert Duck mit dieser E-Mail-Adresse gehört.

Danach können sie E-Mails mit diesem Schlüssel signieren und jeder, der dem Schlüssel vertraut, ist der Meinung, diese Mail käme von der reichsten Ente der Welt. Das funktioniert auch in die andere Richtung: Verschlüsselt jemand eine vertrauliche Nachricht mit diesem Schlüssel und schickt sie an die angegebene Adresse, landet die E-Mail bei den Panzerknackern. Die könnten sie dann mit dem zugehörigen geheimen Schlüssel entschlüsseln, während der Absender der festen Überzeugung ist, seine Mail sei bei Dagobert Duck gelandet und der könne sie als einziger entschlüsseln.

Ohne Identitätsprüfung keine Sicherheit!

Das eigentliche Problem bei der Mailverschlüsselung besteht also nicht in der Verschlüsselung (und natürlich Signatur) der Nachricht, sondern darin, den richtigen Schlüssel zu verwenden. Für diese Prüfung der Identität der Schlüsselinhaber gibt es zwei Möglichkeiten: Das Web of Trust, wie es von Pretty Good Privacy/PGP und dem GNU Privacy Guard/GnuPG/GPG verwendet wird, und hierarchische Zertifizierungssysteme, wie sie von S/MIME verwendet werden.

Beides sind schon ziemlich alte Lösungen: Phil Zimmermanns Pretty Good Privacy wurde 1991 veröffentlicht, der S/MIME-Standard 1995. Die erste Version von GnuPG stammt aus dem Jahr 1997, der zu Grunde liegende OpenPGP-Standard wurde erstmals 1996 veröffentlicht. Und damit haben wir auch schon die beiden üblichen Lösungen für die E-Mail-Verschlüsselung: PGP/GnuPG und S/MIME.

Web of Trust

Das Web of Trust kommt ohne hierarchische Institutionen aus. Die Benutzer signieren im ersten Schritt ihre eigenen öffentlichen Schlüssel und verteilen sie, z. B. durch das Heraufladen auf einen Keyserver oder den direkten Austausch mit anderen Benutzern.

Möchte Alice eine Signatur von Bob prüfen, beschafft sie sich Bobs öffentlichen Schlüssel und prüft ihn, indem sie sich von Bob alle zur Identifikation des Schlüssels nötigen Informationen (bei PGP/GnuPG insbesondere den Fingerprint) geben lässt. Dies muss über einen sicheren Kanal geschehen, also in der Regel bei einem persönlichen Treffen. Nachdem Alice Bobs öffentlichen Schlüssel erfolgreich geprüft hat, kann sie ihm vertrauen und die Signatur prüfen.

Um ihr Vertrauen in den Schlüssel auszudrücken, signiert sie ihn mit ihrem geheimen Schlüssel. Damit erklärt sie, dass sie sich sicher ist, dass dies der öffentliche Schlüssel von Bob ist. Wenn sie diesen von ihr signierten Schlüssel an den Keyserver sendet, können auch Dritte von ihrer Prüfung profitieren.

Möchte danach Carol eine Signatur von Bob prüfen, erhält sie vom Keyserver Bobs Schlüssel mit Alices Signatur. Vertraut sie Alice vollkommen, kann sie auf eine eigene Prüfung des Schlüssels verzichten, da die Prüfung ja bereits von Alice durchgeführt wurde.

Bis hierhin kennt das Verfahren nur Ja/Nein-Aussagen: Vertraut Carol Alice vollkommen, kann sie auf die Prüfung verzichten. Andernfalls muss sie den Schlüssel selbst prüfen. Im realen Leben gibt es beim Vertrauen Abstufungen: Vielleicht traut Carol Alice zwar im Allgemeinen, weiß aber, dass sie bei der Prüfung von Schlüsseln manchmal etwas schlampig ist. Vielleicht wurde Bobs Schlüssel ja außerdem von Dave unterschrieben, dem Carol auch halbwegs vertraut. Nach dem Motto „Zwei halbe Vertrauen sind so gut wie ein ganzes“ könnte sie dann trotzdem Bobs Schlüssel vertrauen und auf eine eigene Prüfung verzichten. So ergibt sich nach und nach das „Web of Trust“ (Abb. 6).

Abb. 6: Ausschnitt aus dem „Web of Trust“

Abb. 6: Ausschnitt aus dem „Web of Trust“

Die Abstufungen in das Vertrauen werden in PGP/GnuPG durch den Faktor „Vertrauen in den Schlüsselinhaber“ (Owner-Trust) dargestellt, der folgende Wert haben kann:

  • unknown für Benutzer, über deren Verhalten gar nichts bekannt ist,
  • not trusted für Benutzer, die einen fremden Schlüssel vor dem Signieren nicht oder nicht ausreichend prüfen,
  • marginal für Benutzer, denen nicht vollkommen vertraut wird,
  • complete für Benutzer, denen vollkommen vertraut wird sowie
  • ultimate für die eigenen Schlüssel.

Das Vertrauen in die Schlüsselinhaber überträgt sich automatisch auf die von ihnen signierten fremden öffentlichen Schlüssel:

  • Selbstsignierten, fremden, öffentlichen Schlüsseln wird complete
  • Hat Carol den öffentlichen Schlüssel von Alice selbst signiert (ohne gezwungenermaßen den signierten Schlüssel an einen Keyserver geschickt zu haben) und vertraut sie ihr complete oder marginal, bekommt Bobs von Alice signierter Schlüssel automatisch den entsprechenden Wert.
  • In allen anderen Fällen bekommt er automatisch den Wert not trusted.

Zusätzlich zu den oben genannten Werten werden für die Schlüssel weitere Werte für ungültige (z. B. abgelaufene oder zurückgezogene) Schlüssel verwendet.

Vertrauen ist relativ

„Vertrauen in den Schlüssel“ ist eine rein technische Angabe: Es geht darum, ob der Schlüssel vom angeblichen Besitzer stammt oder nicht. Ob der Besitzer vertrauenswürdig ist oder nicht, ist eine andere Frage. Es ist also durchaus möglich, dass einem Schlüssel vollkommen vertraut wird, dessen Inhaber aber wenig oder gar nicht. Wenn Carol im obigen Beispiel den Schlüssel von Alice geprüft und signiert hat, weiß sie mit Sicherheit, dass es der Schlüssel von Alice ist, das heißt, signierte Dokumente also von Alice signiert wurden. Trotzdem traut sie Alice selbst und damit ihren Signaturen unter fremden Schlüsseln nur bedingt, da sie weiß, dass Alice blind alle Schlüssel signiert, die ihr unter die Finger kommen.

Der große Vorteil des Web of Trust gegenüber einem hierarchischen Aufbau ist, dass die Benutzer nicht blind einer zentralen Institution vertrauen müssen. Ein Nachteil ist, dass ein Schlüsselwechsel schwierig ist, da niemand weiß, wo die Schlüssel überall gespeichert und damit auszutauschen sind. Während bei einem hierarchischen Ansatz eine zentrale Liste ungültiger Schlüssel geführt werden kann, muss beim Web of Trust immer damit gerechnet werden, dass Benutzer inzwischen ungültige Schlüssel verwenden. Das ist besonders kritisch, wenn dadurch eine gefälschte Signatur mit einem zurückgezogenen, kompromittierten Schlüssel als gültig erkannt wird.

Außerdem verträgt sich das Web of Trust schlecht mit Unternehmenshierarchien. Dieser Nachteil kann aber durch lokale Zertifizierungsstellen ausgeglichen werden, die sowohl die Schlüssel ihrer jeweiligen lokalen Benutzer als auch sich untereinander gegenseitig zertifizieren. Damit endet man aber eigentlich wieder bei einem (zumindest teilweise) hierarchischen System wie den X.509-Zertifikaten, die für TLS und S/MIME verwendet werden.

Hierarchische Zertifizierungssysteme

Während sich die Benutzer beim Web of Trust gegenseitig zertifizieren, geschieht das bei einem hierarchischen System ausschließlich durch extra dafür eingerichtete, vertrauenswürdige Instanzen. Diese Zertifizierungsstellen (Certificate Authority, CA) zertifizieren sich zusätzlich untereinander gegenseitig und bestätigen damit die Vertrauenswürdigkeit des jeweils anderen. Zumindest in der Theorie.

Benutzer können daher den von einer beliebigen CA signierten Schlüsseln vertrauen, sofern deren Zertifikat von einer in ihren Augen vertrauenswürdigen CA signiert wurde. Das Ganze kann als Baumstruktur betrachtet werden, in der das eigene Zertifikat jeder CA sowohl von den über als auch den unter ihr liegenden CAs signiert wurde. An der Spitze kann eine Master-CA stehen, sodass im Idealfall jeder Benutzer die Zertifikate jedes anderen Benutzers prüfen kann.

Möchte Alice Bobs signierte Nachricht prüfen, besorgt sie sich seinen öffentlichen Schlüssel und prüft das Zertifikat. Dazu benötigt sie den öffentlichen Schlüssel der ausstellenden CA und muss sowohl ihr als auch dem Schlüssel vertrauen. Trifft beides zu, kann sie Bobs Schlüssel danach sofort verwenden. Andernfalls muss sie eine andere CA finden, die ein Zertifikat für die von Bob verwendete CA ausgestellt hat und der sie vertraut (Abb. 7).

Abb. 7: Ausschnitt aus einem hierarchischen Zertifizierungssystem

Abb. 7: Ausschnitt aus einem hierarchischen Zertifizierungssystem

Im Beispiel in Abbildung 7 wurde Alice’ Schlüssel von CA A zertifiziert, Bobs von CA B. Sowohl Alice als auch Bob kennen die Schlüssel der jeweils eigenen CA und vertrauen den damit signierten Zertifikaten.

CA A hat CA 1 zertifiziert, sodass Alice Zertifikaten vertrauen kann, die von CA 1 ausgestellt wurden. Jetzt muss sie sich in der Hierarchie nach oben durcharbeiten, bis sie eine CA findet, von der aus sie zu CA B gelangt. In der Abbildung ist dies CA 5: Deren Zertifikaten vertraut CA 3, und CA 5 selbst vertraut CA 4. Dem Schlüssel von CA 3 vertraut Alice, nachdem sie das zugehörige Zertifikat mit der Signatur von CA 1 geprüft hat. Nachdem Alice also CA 3 ihr Vertrauen geschenkt hat, kann sie der Reihe nach die Zertifikate von CA 5, CA 4, CA 2 und schließlich CA B prüfen.

Es ist durchaus möglich, dass es keinen Weg von Alice zu Bob gibt, da niemand bereit ist, die Vertrauenswürdigkeit von CA B zu bezeugen. Dann muss entweder Bob ein Zertifikat einer anderen CA vorweisen, deren Vertrauenswürdigkeit von Alice geprüft werden kann, oder Alice muss sich selbst davon überzeugen, dass sie CA B für vertrauenswürdig hält. Ist beides erfolglos, darf Alice Bobs Signatur nicht trauen.

Und in der Praxis?

Soweit die Theorie. In der Realität wurde das Ganze stark vereinfacht und dabei auch verschlechtert. Beim Einsatz im Rahmen von S/MIME und HTTPS ist das Durchhangeln durch den CA-Baum im Allgemeinen nicht nötig, da die aktuellen Betriebssysteme sowie Mailclients und Browser sehr vielen CAs von Haus aus vertrauen. Es kommt also sehr selten vor, dass ein Benutzer auf ein Zertifikat einer CA stößt, dem sein System oder Mailclient/Browser nicht von Haus aus vertrauen. Nur in diesen vereinzelten Sonderfällen kommt die Zertifizierung der CAs untereinander zum Tragen. Falls auch darüber die CA und ihr öffentlicher Schlüssel nicht überprüft werden können, muss der Benutzer das selbst übernehmen.

Die Verschlechterung besteht darin, dass man als Benutzer nicht immer der gleichen Ansicht wie die Hersteller ist, was die Vertrauenswürdigkeit einer CA betrifft. Die Hersteller prüfen nur, ob die CAs den für sie aufgestellten Regeln entsprechen und eventuell auch noch, ob sie in der Vergangenheit nicht negativ aufgefallen sind.

Als Benutzer hat man aber ein Interesse daran, nur den CAs zu vertrauen, die dieses Vertrauen wirklich verdienen und die man wirklich nutzt. Jedes von einer als vertrauenswürdig eingestuften CA ausgestellte Zertifikat wird automatisch als gültig akzeptiert, auch wenn es widerrechtlich ausgestellt wurde, z. B. weil die CA falsch spielt oder kompromittiert wurde.

Auf der Liste der vertrauenswürdigen CAs sind viele, denen man als Westeuropäer wohl nie begegnen wird, beispielsweise staatliche asiatische CAs. Die sind zwar für die Bürger der jeweiligen Länder sehr wichtig, weil darüber der Zugriff auf staatliche Angebote abgesichert wird, für den Rest der Weltbevölkerung aber völlig irrelevant.

Das gesamte System aus digitalen Zertifikaten zur Zuordnung von öffentlichen Schlüsseln und ihren Benutzern, Zertifizierungsstellen zum Ausstellen der Zertifikate, Registrierungsstellen, bei denen die Zertifikate beantragt werden können, einem Verzeichnisdienst für die Zertifikate und Möglichkeiten zum Rückruf von ungültigen Zertifikaten wird als Public-Key-Infrastruktur (PKI) bezeichnet. Der bekannteste Standard für eine PKI ist der X.509-Standard der ITU-T.

Fassen wir mal zusammen…

Jetzt haben wir alles zusammen, was wir für die Verschlüsselung von E-Mails brauchen:

  • symmetrische Verschlüsselungsverfahren wie AES zum Ver- und Entschlüsseln der Mails mit einem Session Key;
  • digitale Signatursysteme wie RSA zum Signieren der Mails und dem Prüfen der Signatur;
  • asymmetrische Verschlüsselungsverfahren wie RSA zum Ver- und Entschlüsseln des Session Keys der symmetrischen Verschlüsselung;
  • zwei Möglichkeiten zur Identitätsprüfung: Das Web of Trust und die bereits für SSL/TLS verwendete X.509-PKI.

Und mit PGP/GnuPG und S/MIME stehen Implementierungen bereit, über die jeder Benutzer relativ problemlos seine Mails verschlüsseln und signieren kann sowie natürlich empfangene Mails entschlüsseln und ihre Signatur prüfen.

Und wie sicher ist das?

Das ist der große Witz an der Sache: Das ist sehr sicher, solange man

  1. wirklich den richtigen öffentlichen Schlüssel des Empfängers zur Verschlüsselung und des Absenders zur Signaturprüfung verwendet und
  2. niemand die E-Mail während des Transports manipuliert. Denn dann sind Angriffe möglich, wie seit Mai bekannt ist.

Vermutlich haben Sie schon von EFAIL gehört, der Schwachstelle, nach deren Bekanntwerden überall vor dem Versenden vertraulicher Daten per E-Mail gewarnt wurde, selbst wenn das verschlüsselt erfolgt. Das ist etwas übertrieben, mit Workarounds kann man sich vor den Angriffen schützen, und die meisten Mailclients und Verschlüsselungs-Plug-ins wurden inzwischen entsprechend gepatcht.

Wie der Angriff funktioniert, erkläre ich im nächsten Entwickler Magazin. Dabei werden Sie sehen, dass vieles, was hier beschrieben wurde, nicht ganz so funktioniert, wie es gedacht ist.

Fazit

Die Infrastruktur zur E-Mail-Verschlüsselung ist vorhanden. Das einzige, was fehlt, sind Schlüssel dafür. Kaum jemand hat einen PGP/GnuPG- oder S/MIME-Schlüssel. Und wenn man kaum Empfänger kennt, denen man verschlüsselte Mails schicken kann, hat man auch keinen Grund, sich selbst einen Schlüssel zu besorgen, um verschlüsselte Mails zu empfangen.

Wie viele Personen kennen Sie, die E-Mail-Verschlüsselung nutzen? Oder überhaupt einen Schlüssel haben? Nicht viele, richtig? Darum nutzt kaum jemand E-Mail-Verschlüsselung. Trotzdem (oder gerade deshalb) sind die im nächsten Entwickler Magazin beschriebenen EFAIL-Angriffe ein großes Problem. Denn wer heutzutage E-Mail-Verschlüsselung nutzt, hat meist gute Gründe dafür. Was bedeutet: Wo verschlüsselt wird, lohnt sich ein Angriff mit großer Wahrscheinlichkeit.

Zum Glück erfordern die EFAIL-Angriffe eine Manipulation der Mails vor dem Empfang. NSA und Co. können ihre gehorteten Berge verschlüsselter E-Mails darüber also nach wie vor nicht entschlüsseln.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -