E-Mail-Verschlüsselung

E-Mail-Verschlüsselung wird verwendet, um vertrauliche Informationen per E-Mail verschlüsselt zu versenden. Hierfür gibt es zwei verschiedene Prinzipien, die unabhängig voneinander zum Einsatz kommen. Erstens, bei der Ende-zu-Ende-Verschlüsselung wird eine E-Mail durchgehend zwischen Absender und Empfänger verschlüsselt. Zweitens, bei der Punkt-zu-Punkt- oder auch Transportverschlüsselung wird die Übertragungsstrecke einer E-Mail zwischen zwei Komponenten im E-Mail-System verschlüsselt, beispielsweise zwischen Absender und E-Mail-Anbieter oder zwischen verschiedenen Anbietern untereinander.

Die Ende-zu-Ende-Verschlüsselung geht oft einher mit der digitalen Signatur und wird in Standards wie S/MIME oder PGP standardmäßig kombiniert eingesetzt. Das Ziel einer digital signierten E-Mail ist es, Informationen so vom Absender zum Empfänger zu schicken, dass der Sender eindeutig feststellbar ist und niemand die E-Mail unbemerkt auf dem Weg vom Sender zum Empfänger manipulieren kann. Die E-Mail-Signatur gewährleistet somit Authentizität und Integrität, während Vertraulichkeit durch Verschlüsselung sichergestellt wird.

Für die Transportverschlüsselung wird TLS oder STARTTLS eingesetzt, was die Integrität und Vertraulichkeit einer Übertragungsstrecke sicherstellt. Um zusätzlich eine Ende-zu-Ende-Sicherheit zu gewährleisten, können Transportverschlüsselung und Ende-zu-Ende-Verschlüsselung auch zusammen eingesetzt werden, da sie auf unterschiedlichen Ebenen und unabhängig voneinander arbeiten.

Anwendungsformen im Vergleich

Für E-Mail-Verschlüsselung und E-Mail-Signatur gibt es verschiedene Anwendungsformen.

Client-basierte E-Mail-Verschlüsselung und -Signatur

Die klassische E-Mail-Verschlüsselung und -Signatur erfolgt von Client zu Client (Ende-zu-Ende-Verschlüsselung).

Beispiel: Alice schickt eine verschlüsselte und signierte Nachricht per E-Mail an Bob.

1. Die Verschlüsselung und Signatur der Nachricht übernimmt der E-Mail-Client von Alice. Zur Verschlüsselung wird der öffentliche Schlüssel von Bob verwendet. Die Signatur erfolgt mit dem privaten Schlüssel von Alice.
2. Die Entschlüsselung und Signaturprüfung der Nachricht übernimmt der E-Mail-Client von Bob. Die Entschlüsselung erfolgt mit dem privaten Schlüssel von Bob. Die Prüfung der Signatur erfolgt mit dem öffentlichen Schlüssel von Alice.

Client-basierte Lösungen haben den Nachteil, dass sie für viele Organisationen (Unternehmen, Vereine, …) zu komplex sind. Weil entsprechende IT-Infrastrukturen nicht vorhanden sind, ist die Versuchung groß, in der Organisation ganz auf E-Mail-Verschlüsselung und Signatur zu verzichten.

Server-basierte E-Mail-Verschlüsselung und -Signatur

Um die Nachteile der clientbasierten Verschlüsselung zu vermeiden, sind Server-basierte Lösungen das Mittel der Wahl. Die Arbeit der Verschlüsselung und Signatur wird dabei nicht von Clients, sondern von Servern erledigt.

Beispiel 1: Alice arbeitet in einem Unternehmen A und schickt eine verschlüsselte und signierte Nachricht per E-Mail an Bob.

1. Die Verschlüsselung und Signatur der Nachricht von Alice übernimmt ein E-Mail-Server (ein sogenanntes Verschlüsselungs-Gateway), der sich im Unternehmen A befindet.
2. Die Entschlüsselung und Signaturprüfung der Nachricht übernimmt der E-Mail-Client von Bob.

Beispiel 2: Alice arbeitet in einem Unternehmen A und schickt eine verschlüsselte und signierte Nachricht per E-Mail an Bob. Bob arbeitet in einem Unternehmen B.

1. Die Verschlüsselung und Signatur der Nachricht von Alice übernimmt ein E-Mail-Server, der sich im Unternehmen A befindet.
2. Die Entschlüsselung und Signaturprüfung der Nachricht bei Bob übernimmt ein E-Mail-Server, der sich im Unternehmen B befindet.

Die Vorteile einer Server-basierten Lösung sind also folgende:

• Die Mitglieder der Organisation (z. B. die Mitarbeiter im Unternehmen) müssen sich mit dem Thema Verschlüsselung und Signatur nicht beschäftigen. Die Arbeit macht der Administrator, der den zentral aufgestellten Server wartet.
• Trotzdem kann sämtlicher E-Mail-Verkehr verschlüsselt und signiert ablaufen, sofern die internen Benutzer es wollen und die externen Kommunikationspartner mitmachen.

Nachteil dieser Lösung ist, dass der Administrator oder Dritte den Weg zwischen dem sendenden E-Mail-Client und dem internen Mail-Server (Verschlüsselungs-Gateway) abhören und damit E-Mails lesen und verändern können.

Server-basierte Lösungen können dem Administrator folgende Leistungen anbieten:

• geheime und öffentliche Schlüssel der internen Nutzer automatisch generieren, verwalten und bei Bedarf auch publizieren (z. B. bei öffentlichen LDAP-Verzeichnissen)
• die Zertifikate externer Kommunikationspartner automatisch abfragen, validieren und eventuell für eine spätere Nutzung speichern
• vollautomatisiert Zertifikate ausstellen

PKI-basierte E-Mail-Verschlüsselung und -Signatur

Die häufig angetroffene Methode, bei der E-Mail Vertraulichkeit und Authentizität zu erreichen, ist die PKI-basierte E-Mail-Verschlüsselung und -Signatur. PKI steht für Public-Key-Infrastruktur. Bei der PKI-basierten E-Mail-Verschlüsselung und -Signatur kommt fast immer einer der zwei folgenden Standards zum Einsatz:

1. S/MIME: Secure / Multipurpose Internet Mail Extensions
2. OpenPGP: Open Pretty Good Privacy

PKI-basierte E-Mail-Verschlüsselung und -Signatur kommt sowohl bei Client-basierten Lösungen als auch bei Server-basierten Lösungen zum Einsatz.

Passwort-basierte E-Mail-Verschlüsselung

Die Passwort-basierte E-Mail-Verschlüsselung ist eine Option, die von Server-basierten Lösungen angeboten werden kann. Sie löst dabei folgendes Problem:

• Wenn Server-basierte Lösungen PKI-basiert arbeiten, dann können sie zwar die internen Kommunikationspartner der betreibenden Organisation von komplizierter PKI entlasten, nicht jedoch die externen Kommunikationspartner. Die externen Kommunikationspartner müssen entweder selbst eine Server-basierte Lösung in ihrer Organisation betreiben oder, wenn dies nicht möglich ist, ihre PKI Client-basiert betreiben. Können sie beides nicht, dann ist eine E-Mail-Verschlüsselung zumindest PKI-basiert nicht möglich.

Um zu vermeiden, dass gar nicht verschlüsselt wird, können Server-basierte Lösungen neben PKI-basierter E-Mail-Verschlüsselung auch Passwort-basierte E-Mail-Verschlüsselung anbieten. Bei externen Kommunikationspartnern, die über eine PKI verfügen, wird dann PKI-basiert verschlüsselt. Bei Kommunikationspartnern, die über keine PKI verfügen, kann Passwort-basiert verschlüsselt werden.

Funktionsprinzip

Es gibt verschiedene Möglichkeiten, eine Passwort-basierte E-Mail-Verschlüsselung zu realisieren.

Beispiel für eine von vielen Möglichkeiten:

• Alice arbeitet in einem Unternehmen mit einer Server-basierten Lösung. Bob verfügt über keinerlei PKI.
• Alice schickt eine Nachricht per E-Mail an Bob.
• Die Server-basierte Lösung findet keine Zertifikate für Bob und entscheidet sich automatisch für eine Passwort-basierte Zustellung der Nachricht an Bob.
• Die Nachricht von Alice kommt in eine Warteschleife.
• Bob erhält eine Benachrichtigung per E-Mail, dass eine Nachricht auf ihn wartet.
• Bob richtet sich auf einem Web-Server einen Account ein und vergibt für sich ein Passwort.
• Anschließend wird die in der Warteschleife befindliche Nachricht automatisch in eine PDF-Datei umgewandelt, der Inhalt der PDF-Datei mit dem von Bob angegebenen Passwort verschlüsselt und das so geschützte PDF per E-Mail (als Attachment) an Bob ausgeliefert.
• Bob öffnet das PDF, gibt in den PDF-Reader sein Passwort ein und kann so die Nachricht von Alice lesen.
• Jede weitere Nachricht aus dem Unternehmen, in dem Alice arbeitet, wird ab sofort automatisch Passwort-verschlüsselt als PDF an Bob verschickt.

Vorteile für die externen Kommunikationspartner

• Es sind keine Zertifikate auf Empfängerseite erforderlich.
• Das automatisierte Passwortmanagement ersetzt für den externen Kommunikationspartner den komplexen Zertifikats-Ausstellungsprozess bei Trustcentern. Einzige Voraussetzung ist, dass er über Standard-Software (z. B. Web-Browser oder PDF-Reader) verfügt.

S/MIME-basierte E-Mail-Verschlüsselung und -Signatur im Detail

→ Hauptartikel: Hybride Verschlüsselung und Digitale Signatur

Wie bei der reinen hybriden Verschlüsselung auch, muss sich jeder Kommunikationspartner ein Schlüsselpaar erzeugen, bevor er E-Mails signieren oder verschlüsselte E-Mails empfangen kann. Ohne eigenes Schlüsselpaar ist lediglich das Verifizieren fremder Signaturen und das Verschlüsseln von Nachrichten möglich.

In der S/MIME-Welt ist es üblich, dass neue Kommunikationspartner ihren öffentlichen Schlüssel von einer Zertifizierungsstelle signieren lassen. Dazu wird der öffentliche Schlüssel an die Zertifizierungsstelle geschickt. Je nach Sicherheitsklasse prüft die Zertifizierungsstelle mehr oder weniger streng, ob der öffentliche Schlüssel tatsächlich der Person gehört, die das behauptet. Nach Bestehen der Prüfung erstellt die Zertifizierungsstelle ein Zertifikat des Schlüssels, indem sie ihn mit ihrem geheimen Signaturschlüssel unterschreibt. Das Zertifikat besteht dabei aus dem öffentlichen Schlüssel selbst, der Signatur und Verwaltungsdaten. Zu dem für das Signieren verwendeten Signaturschlüssel gibt es einen öffentlichen Verifikationsschlüssel, mit dem die Signatur überprüft werden kann. Zu diesem Verifikationsschlüssel der Zertifizierungsstelle gibt es ebenfalls ein Zertifikat, das CA-Zertifikat, das wiederum von einer Zertifizierungsstelle signiert wurde. Auf diese Weise entsteht eine Kette aus CA-Zertifikaten. Das letzte Glied einer solchen Kette wird Root-CA-Zertifikat genannt. Das Root-CA-Zertifikat wurde mit sich selbst signiert, so dass in der Praxis weitere Wege beschritten werden, um sicherzustellen, dass das Root-CA-Zertifikat echt ist.

Nachrichten können sowohl signiert als auch verschlüsselt werden. Eine Signatur stellt sicher, dass eine Nachricht nicht verändert wurde, und gibt Auskunft über die Identität des Verfassers. Die Verschlüsselung garantiert die Vertraulichkeit der Nachricht, wobei üblicherweise sichergestellt wird, dass der Absender und alle Empfänger einer Nachricht diese entschlüsseln können.

Anwendungsgebiete

E-Mail-Verschlüsselung und -Signierung kommt unter anderem in folgenden Situationen zum Einsatz:

• Wahrung der Privatsphäre
• Sicherstellung der Integrität des E-Mail-Inhaltes
• Einhaltung von gesetzlichen Datenschutzvorschriften in Behörden und Instituten

Literatur

• Bruce Schneier: Applied Cryptography. Protocols, Algorithms, and Source Code in C, Second Edition. 1996, ISBN 0-471-11709-9. 
• Niels Ferguson und Bruce Schneier: Practical Cryptography. 2003, ISBN 0-471-22357-3. 
• Bruce Schneier: E-mail Security. How to Keep Your Electronic Messages Private. 1995, ISBN 0-471-05318-X. 

Weblinks

• B. Kaliski: RFC 2315 – PKCS #7: Cryptographic Message Syntax Version 1.5. März 1998 (englisch).
• R. Housley: RFC 3852 – Cryptographic Message Syntax (CMS). Juli 2004 (löst RFC 3369 ab, englisch).
• R. Housley: RFC 5652 – Cryptographic Message Syntax (CMS). September 2009 (löst RFC 3852 ab, englisch).
• J. Callas, L. Donnerhacke, H. Finney, R. Thayer: RFC 2440 – OpenPGP Message Format. November 1998 (englisch).
• J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer: RFC 4880 – OpenPGP Message Format. November 2007 (löst RFC 2440 ab, englisch).
• M. Elkins, D. Del Torto, R. Levien, T. Roessler: RFC 3156 – MIME Security with OpenPGP. August 2001 (löst RFC 2015 ab, englisch).
• M. Nystrom, B. Kaliski: RFC 2986 – PKCS #10: Certification Request Syntax Specification Version 1.7. November 2000 (löst RFC 2314 ab, englisch).
• J. Galvin, S. Murphy, S. Crocker, N. Freed: RFC 1847 – Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. Oktober 1995 (englisch).
• B. Ramsdell: RFC 3851 – Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. Juli 2004 (löst RFC 2633 ab, englisch).
• J. Linn: RFC 1421 – Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. Februar 1993 (löst RFC 1113 ab, englisch).
• S. Kent: RFC 1422 – Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. Februar 1993 (löst RFC 1114 ab, englisch).
• D. Balenson: RFC 1423 – Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. Februar 1993 (löst RFC 1115 ab, englisch).
• B. Kaliski: RFC 1424 – Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services. Februar 1993 (englisch).
• selbstdatenschutz.info → E-Mail verschlüsseln (PGP/GnuPG)
• elektronikinfo.de → E-Mail-Verschlüsselung mit PGP
• verbraucher-sicher-online.de → Schwerpunkt E-Mail-Verschlüsselung
• Quis custodiet custodes? Anleitung zur Nutzung von S/MIME und PGP unter Windows in Mozilla Thunderbird, Microsoft Outlook 2013 und Android
• BSI für Bürger: De-Mail Ende-zu-Ende-Verschlüsselung

Einzelnachweise

1. Archiviert vom Original; abgerufen am 6. März 2020.