E-Mail Signatur und Verschlüsselung

Die DS-GVO fordert in Art. 25 "Datenschutz durch Technikgestaltung".

Es steht an keiner Stelle eine klare Vorschrift zur Verschlüsselung, aber naheliegend ist diese Auslegung schon.
Verschlüsselung sichert die Integrität und die Vertraulichkeit der Daten.
 
E-Mail Verschlüsselung ist nichts Neues, hat es aber bisher nicht aus der Freak-Ecke heraus geschafft.Das hat mehrere Gründe. Die gängige Mailsoftware macht es den Nutzern nicht leicht.
Aber versuchen wir es trotzdem.
 
Prinzipiell unterscheidet man zwischen Transportverschlüsselung und Inhaltsverschlüsselung.
Transportverschlüsselung verschlüsselt den Transportweg bis zum nächsten Mailserver. (ich fahre meinen Brief gepanzert zur Post)
Inhaltsverschlüsselung verschlüsselt die eigentliche Nachricht.
Nur die Inhaltsverschlüsselung sichert die Integrität und Vertraulichkeit auf der gesamten Übertragungskette.
Die Transportverschlüsselung versteckt zusätzlich die Metadaten.
 
1. Transportverschlüsselung
Bei diesem Verfahren wird die E-Mail vom Client bis zum Mailserver TLS/SSL-verschlüsselt.
Die meisten deutschen Provider unterstützen das Verfahren oder fordern es inzwischen.
Problem: die Nachricht ist vom Client bis zum ersten Mailserver verschlüsselt. Meist läuft der Nachrichtenfluß über eine unbekannte Anzahl von Mailservern. Hier ist die Transportverschlüsselung nicht überprüfbar.
Transportverschlüsselung bringt also keine absolut verlässliche Sicherheit im Internet.
Für die Verbindung vom Gateway oder lokalen Server zum Client (Web, Handy, Mailclient) ist sie aber ein Muss.
 
2. Inhaltsverschlüsselung
Man unterscheidet 3 gängige Verfahren.
 
2.1. S/MIME
S/MIME arbeitet mit asynchronen Schlüsseln.
Jeder Anwender bekommt bzw. hinterlegt seinen öffentlichen Schlüssel von bzw. bei einem Zertifikatsprovider.
Der Zertifikatsanbieter prüft die Identität des Anwenders.
In Kombination mit dem privaten Schlüssel ist eine Ende-zu-Ende Verschlüsselung oder Signatur der E-Mail gewährleistet.
Dieses Verfahren ist am weitesten verbreitet und nach der Einrichtung sehr einfach bedienbar.
Die Signierung von E-Mails ist auch bei Gegenstellen möglich, die keine S/MIME Verschlüsselung nutzen.
Problem1: Man muß den Zertifikatsstellen vertrauen. CAs wurden schon gehackt und verifizieren teilweise oberflächlich. Diese Betrachtung ist eher theoretisch und bietet nur Angriffsfläche für staatliche und ähnlich professionelle Angreifer.
Problem2: Wenn die Gegenseite kein S/MIME nutzt, funktioniert die Verschlüsselung nicht.
  In meinem Postausgang werden aktuell (10/2018) nur ca. 3% der Nachrichten erfolgreich S/MIME-verschlüsselt.
Problem3: Verfügbarkeit und Archivierung. Dazu später mehr.
 
S/MIME Verschlüsselung läßt sich zentral im Gateway für ganze Domänen oder lokal im Client für jede einzelne Mailadresse anwenden.
 
 
2.2. PGP
PGP funktioniert ähnlich, arbeitet aber ohne eine zentrale Zertifikatsstelle.
Anwender tauschen ihre Schlüssel direkt aus und können anschließend verschlüsseln oder signieren.
Die Identität des Gegenübers muß der Anwender selbst prüfen.
Das geschieht auf Crypto-Partys oder durch Fachjournale wie Heise auf der CBit durch Authentifizierung per Ausweis.
Das Verfahren ist per se sicherer als S/MIME, aber der Schlüsselaustausch ungleich schwerer.
Aus diesem Grund ist PGP eher ein Verfahren für Freaks, Hacker und Sicherheitsprofis.
Problem1: funktioniert nur mit PGP-Gegenstellen, und die sind rar.
Problem2: Verfügbarkeit, Archivierung siehe unten.
 
2.3. Anlagen-Verschlüsselung mit Fremdsoftware
Wenn die Gegenstelle weder S/MIME noch PGP unterstützt, bleibt nur diese Variante "Verschlüsselung für Arme".
Mit diversen Programmen können ZIP-, PDF- oder selbstentpackende EXE- Archive mit Passworten geschützt werden.
Das Passwort muß auf separatem Weg übermittelt werden, das Entpacken funktioniert auf jedem beliebigen Standard-PC.
Problem1: es wird nicht die eigentliche Mail, sondern nur die Anlage verschlüsselt.
Problem2: der Einsatz erfordert einige zusätzliche Handgriffe und ist kein Automatismus.
Viele Mailgateways lösen dieses Problem und bieten außer den o.g. Verschlüsselungsverfahren auch automatisierte Anlagen-Verschlüsselung mit Passwort an, um die Mails über eine SSL-verschlüsselte Postbox abzuholen oder selbstextrahierend als PDF, ZIP oder EXE zu verschlüsseln.
 
Problem Verfügbarkeit
S/MIME- oder PGP verschlüsselte E-Mails sind nur auf den Geräten lesbar, auf denen der private, aktuelle Schlüssel installiert ist.
Mal schnell auf dem Handy oder per WEB-Client Mails checken geht nicht.
S/MIME Zertifikate können prinzipiell auch unter Android installiert werden.
Die Google-App GMAIL unterstützt das aber nicht.
Datenrettung von verschlüsselten E-Mails bei einem Crash ist deutlich komplexer und der Erfolg unsicherer als ohne Verschlüsselung.
Gatewaybasierende Verschlüsselung kennt diese Probelme nicht.
 
Problem Archivierung
E-Mail Archive, die per Proxy die Mails abgreifen, erhalten nur verschlüsselten Datenmüll.
Auch SMTP-Virenscanner der Provider oder auf dem eigenen PC greifen ins Leere.
Im Prinzip ist das ja der Sinn der Verschlüsselung.
 
Greift die Archivsoftware auf den Mailclient zu, kann sie die verschlüsselten Mails korrekt archivieren.
Lesen der verschlüsselten Mails geht allerdings nur durch Rücksicherung in den Mailclient mit dem jeweils gültigen Zertifikat.
Eine Suche im Nachrichtentext oder eine schnelle Voransicht im Archiv ist nicht möglich.
 
S/MIME-Zertifikate sind meist ein oder zwei Jahre gültig.
Sucht man im Mailarchiv nach einer Nachricht aus vergangen Jahren, muss zum Lesen das damals aktuelle Zertifikat installiert sein.
Gatewaybasierende Verschlüsselung kennt diese Probelme nicht.

Verschlüsselung / Signatur von E-Mail

Bei der E-Mail Verschlüsselung und Signatur unterscheidet man Client-basierende und Server-basierende Verschlüsselung.
Klassische Lösungen arbeiten Client-basiert. Das ist für Unternehmen zu unhandlich.

Zu den Unterschieden zwischen Transportverschlüsselung (TLS/SSL) und Inhaltsverschlüsselung (S/MIME, PGP..) siehe diesen Beitrag.

Die Inhalts-Verschlüsselung kann durch Key (Zertifikate) oder Passwort erfolgen.
Passwort-Verschlüsselung ist eine Notlösung, die keine Zertifikatsinfrastruktur erfordert und mit jedem Empfänger funktioniert.
Das ist lösbar mit automatischen Portallösungen oder ganz einfach mit verschlüsselten Anlagen im .ZIP oder .PDF-Format.

S/MIME

E-Mails werden mit dem öffentlichen Zertifikat des Empfängers verschlüsselt oder signiert.
Nur er hat den privaten Key und kann die E-Mails entschlüsseln.
Bei S/MIME werden die X.509-Zertifikate (SSL-Zertifikate) durch eine zentrale Zertifikatsstelle geprüft, signiert und verwaltet.
Zertifikate haben eine begrenzte Laufzeit. Alte Zertifikate sollten unbedingt aufbewahrt bzw. im System installiert bleiben, weil sonst alte verschlüsselte E-Mails nicht mehr geöffnet werden können.

Bei E-Mail-Signaturen benötigt jeder User ein User-Zertifikat nach dem Schema: user@domain.tld.
Gateway-Zertifikate bzw. Domain-Zertifikate sind gültig für alle E-Mail-Adressen unterhalb einer E-Mail-Domäne (@unternehmen.de).
Team-Zertifikate stellt man für Mailadressen aus, die nicht von einzelnen Personen verwaltet werden, wie z. B. info@unternehmen.de oder bewerbung@unternehmen.de.

Dateinamen und Content-Typen:
smime.p7m (signierte oder verschlüsselte Daten), smime.p7c (Zertifikat), smime.p7s (Signatur)

Formate:

  • PFX/P12/PKCS#12 (Personal Information Exchange Standard)
  • PKCS#12 oder PFX/P12 stellt ein binäres Format für die Aufbewahrung des Zertifikats (samt seinem Intermediate) mit dem privaten Schlüssel dar. Die Zertifikate und der private Schlüssel sind in der PFX-Datei mit einem Passwort geschützt. PFX war der Vorgänger von PKCS#12.
  • Die meistgenutzte Endung des Formates ist .pfx und .p12.
  • PKCS#12 wird oft auf den Windows-Geräten für das Import und Export der Zertifikate zusammen mit dem privaten Schlüssel genutzt.
  • Die in PFX gespeicherten Zertifikate dienen auch zum Signieren in Microsoft Authenticode.
  • Format P7B/PKCS#7
  • Das Format PKKS#7 oder P7B repräsentiert ein oder mehrere Zertifikate im Base64 ASCII-Format, das in einer Datei mit der Endung .p7b oder .p7c gespeichert ist.
  • Die Datei P7B enthält das Zertifikat und seine Kette (die Intermediate-Zertifikate), aber der private Schlüssel ist in ihr nicht vorhanden.
  • Am häufigsten werden die P7B Dateien unter Windows und auf der Plattform Java Tomcat eingesetzt.
  • .DER-Binärformat (KEIN Textformat) zum Import in Anwendungen (Mail, Broser..)
  • In DER können alle Zertifikatstypen und der private Schlüssel gespeichert sein.
  • Die Endung der DER-Zertifikate ist meistens .cer oder .der.
  • Private Schlüssel oder der Zertifizierungspfad können mit diesem Format nicht gespeichert werden.
  • Das DER-Format wird auf den Java Plattformen genutzt.
  • .PEM - ASCII-Format
  • ein in Base64 codiertes Format mit ASCII-Zeichen.
  • Es kann neben dem reinen Zertifikat auch Intermediate-Zertifikate, Root-CAs und private Schlüssel beinhalten.
  • Die Dateierweiterung .pem kommt meist zum Einsatz, wenn sowohl Zertifikate und der Privatschlüssel in einer Datei gespeichert werden.
  • Für PEM- Zertifikate werden auch die Endungen .cer, .cert, .crt oder .key (für den privaten Schlüssel) genutzt.
  • Von diesem Format gehen Apache und alle Server auf Unix/Linux OS aus.
  • CSR
  • Ein Certificate Signing Request (deutsch: Zertifikatsignierungsanforderung) ist ein standardisiertes Format (PKCS#10) zum Anfordern eines digitalen Zertifikats.
  • CSR enthält den öffentlichen Schlüssel und weiteren Angaben über den Antragsteller des Zertifikats.
  • Die Zertifizierungsanfrage kann anschließend von einer Zertifizierungsstelle (CA) signiert werden und man erhält ein digitales Zertifikat zurück.

Zertifikatstypen: https://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file

Zertifikate konvertieren:

Mit Hilfe von OpenSSL lassen sich viele Formate schnell und einfach in ein anderes Format konvertieren.

.p7b-Dateien können einfach in .spc umbenannt werden.

LetsEncrypt Wildcard-Zertifikate müssen zwingend per DNS validiert werden.

Tobit David kann S/MIME Zertifikate zentral im Server oder lokal im Client verwalten.

PGP

Auch PGP arbeitet mit unsymmetrischer Verschlüsselung, also mit einem öffentlichen und einem privaten Schlüssel.
Im Gegensatz zu S/MIME gibt es keine zentrale Zertifikatsinstanz,- jeder Nutzer sammelt also die öffentichen Zertifikate der Gegenseite selbst ein.
Damit ist das Verfahren nicht über die Zertifikatsstelle zu kompromittieren.
Das Einsammeln und Verwalten der öffentlichen Schlüssel ist aber entsprechend mühsam.

 

Mail-Gateway OpenSource: Ciphermail.
Hardware Appliance made in germany: Zertificon
Secure E-Mail Gateway: SeppMail
Nutzung von OpenSSL, Zertifikats-Formate: https://www.msxfaq.de/signcrypt/openssl.htm

Quellen und Links:

von Uwe Kernchen

Kommentare

Einen Kommentar schreiben

Bitte rechnen Sie 8 plus 5.