Email-Verschlüsselung

Die Datenschutzkonferenz hat im Juni 2021 eine neue Orientierungshilfe zur Emailverschlüsselung veröffentlicht. Darin unterscheidet sie

• Obligatorische Transportverschlüsselung (5.1)
• Qualifizierte Transportverschlüsselung (5.2)
• Ende-zu-Ende-Verschlüsselung (5.3) — mit S/MIME oder (Open)PGP

Sie erwähnt nicht

• Opportunistische Transportverschlüsselung
• E-Mail made in Germany
• Die Technische Richtlinie „Sicherer E-Mail-Transport“ (BSI TR-03108)
• DomainKeys Identified Mail (DKIM)
• DE-Mail, eIDAS und Elektronischer Rechtsverkehr
• Andere Möglichkeiten der Emailverschlüsselung

was zum Verständnis von Email-Sicherheit hilfreich wäre.

Geschichte der Email-Verschlüsselung

Vielleicht hilft ein Blick in die Geschichte der Email und des Internets. Das Protokoll SMTP wurde lange Zeit unverschlüsselt benutzt, wie auch der Rest des Internets ganz überwiegend unverschlüsselt benutzt wurde. Bei http hat sich das ab 1994 geändert, weil man nicht nur statische Inhalte anbieten wollte, sondern auch Produkte verkaufen und vor allem bezahlt haben wollte. Anfangs wurde fast nur die Abfrage der Kreditkartendaten verschlüsselt. Bis heute hat sich das radikal geändert, der allermeiste Verkehr wird inzwischen verschlüsselt — insbesondere Dank Snowden der die Überwachungspraktiken der USA öffentlich gemacht hat. Auch bei Email hat sich über die Zeit geändert, was Stand der Technik ist. Schon seit längerem ist es üblich, die Kommunikation zwischen dem Email-Client und dem eigenen Email-Server zu verschlüsseln — dabei wurden SMTP über TLS (meist Port 465) und SMTP mit STARTTLS (meist Port 587) standardisiert. Um 2010 durfte ich mitverfolgen, dass die ersten Anbieter angefangen haben, verschlüsselte Verbindungen zwischen Email-Servern zu verwenden. Da das damals aber nur von wenigen Servern unterstützt wurde und man im Fehlerfall dann auf unverschlüsselte Kommunikation zurückfiel, wenn der empfangende Server das nicht unterstützt hat, nannte man das opportunistische Verschlüsselung — wenn es halt geht, sonst eben auch nicht. Inzwischen hat sich auch bei Emailservern die Verschlüsselung auf Transportebene durchgesetzt, es ist in aller Regel nur eine Frage der Konfiguration ob der Server sich „opportunistisch“ verhält oder die Übertragung abbricht, wenn Verschlüsselung nicht möglich ist. Konfiguriert man richtig, dann hat man Verschlüsselung erzwungen und damit die obligatorische Transportverschlüsselung umgesetzt. Auf meinem Emailserver ist diese Konfiguration aktiv, und ich hatte seit der Aktivierung keine einzige gescheiterte Übertragungen. E-Mail made in Germany macht auch nicht mehr als dass die Verschlüsselung zwischen den beteiligten Unternehmen garantiert verschlüsselt ist – aber das war schon beim Entstehen mehr Marketing als etwas besonderes, und heute kann man fast mit jedem verschlüsselt kommunizieren. (02.09.2021: Oder leider doch nicht: Digitalisierung-in-Deutschland-Wahlleitung-im-E-Mail-Test – da scheint der öffentliche Bereich Nachholbedarf zu haben.)

Qualifizierte Transportverschlüsselung

Qualifizierte Transportverschlüsselung unterscheidet sich bei der Transportverschlüsselung überhaupt nicht von der obligatorischen Transportverschlüsselung. Auf Transportebene wird auch nur TLS verwendet. Der Unterschied besteht darin, dass die für den Emailempfang notwendigen DNS-Einträge über DNSSEC signiert/gesichert sind, und dem sendenden Emailserver – sofern er auch DNSSEC verwendet – daher kein anderer Emailserver als Empfänger untergejubelt werden kann. Leider unterstützen nicht alle deutschen Registrare DNSSEC und auch dann, wenn DNSSEC funktionieren würde — zu viele Organisationen ignorieren DNSSEC. Aktuell sind weniger als 2% der deutschen Domains mit DNSSEC geschützt, in den Niederlanden und Schweden sind es etwa die Hälfte. Manchmal ist der Registrar das Problem. Nachdem ich fast fünf Jahre lang vergeblich IONOS nach DNSSEC gefragt habe, habe ich den Registrar gewechselt. Danach dauerte es eine halbe Stunde und DNSSEC war live. Obwohl qualifizierte Transportverschlüsselung durchaus als Stand der Technik gesehen werden kann – hier besteht eindeutig Nachholbedarf.

Technische Richtlinie „Sicherer E-Mail-Transport“ (BSI TR-03108)

Die Technische Richtlinie „Sicherer E-Mail-Transport“ (BSI TR-03108) fordert neben einem IT-Sicherheitskonzept eine qualifizierte Transportverschlüsselung, aber während in der Orientierungshilfe zur Emailverschlüsselung in Abschnitt 5.2. Nr 4 DANE optional ist („auf ein vertrauenswürdiges Wurzelzertifikat bzw. einen via DANE publizierten Vertrauensanker zurück“), erwartet TR-03108 in EMLREQ_4 (Inbound) und EMLREQ_5 (Outbound) die Verwendung von DANE. Während eine DANE Prüfung in EMLREQ_5 von vielen Mailern (z.B. postfix) umgesetzt wird, ist EMLREQ_4 mit den zunehmend kurzlebigen Zertifikaten schwierig – siehe z.B. Let´s Encrypt certificates for mail servers and DANE. Warum man hier nicht übereinstimmend auch vertrauenswürdige Wurzelzertifikate erlaubt — ein Rätsel. Warum teure Zertifikate nach BSI TR-03145 besser sein sollen als die üblichen Wurzelzertifikate bleibt auch unklar — aber diese Anforderung EMLREQ_6 ist wenigstens nur empfohlen und damit optional. Schön wäre natürlich, wenn die Datenschutzkonferenz und das Bundesamt für Sicherheit in der Informationstechnik (BSI) gemeinsame Kriterien finden würden. Dann wäre die Nutzung von Email konform zur Orientierungshilfe, wenn die beteiligten Emailsysteme die TR-03108 Section 3.2 (ohne DANE) erfüllen, und das wiederum könnten Verbraucher am geplanten IT-Sicherheitskennzeichen ablesen. Allerdings ist das vorgesehene Zertifizierungsverfahren im wesentlichen eine Selbsterklärung mit einer dafür meiner Meinung nach abschreckend hohen Gebühr — das ist allenfalls für die großen Anbieter wie z.B. United Internet interessant.

DomainKeys Identified Mail (DKIM)

Leider wird DomainKeys Identified Mail (DKIM) weder von der Datenschutzkonferenz noch in der TR-03108 erwähnt oder gefordert — obwohl das eine sinnvolle Anforderung wäre. DKIM entstand wie auch SPF um Spam besser erkennen und verhindern zu können. Die Idee ist, dass der sendende Emailserver die Emails digital signiert und der empfangende Emailserver diese Signatur mit Hilfe der im DNS veröffentlichten öffentlichen Schlüssel prüft. Ist diese Prüfung erfolgreich, dann kannte der sendende Emailserver den privaten Schlüssel und kann daher als vertrauenswürdig angesehen werden, andernfalls ist er möglicherweise eine Spam-Schleuder. Auch hier hilft natürlich DNSSEC um die Verwendung eines falschen Schlüsselpaars zu verhindern. Wenn mir eine Email verdächtig vorkommt, dann sehe ich mir die Header an. Fehlt eine DKIM-Signatur, wandert sie meist in den Papierkorb.

DE-Mail, eIDAS und Elektronischer Rechtsverkehr

DE-Mail ist ein ursprünglich deutscher, inzwischen mit der eIDAS-Verordnung europäischer Sonderweg, der rechtssichere Kommunikation ermöglicht. „Rechtssicher“ und „sicher“ im Sinne der IT-Sicherheit sind zwei verschiedene Begriffe, ob es im Sinne der IT-Sicherheit sicher ist, das wissen allenfalls die Betreiber oder das Bundesamtes für Sicherheit in der Informationstechnik (BSI) – denn von dem müssen die Betreiber sich zertifizieren lassen. Immerhin ist Verschlüsselung sowohl beim Transport als auch beim Speichern obligatorisch, ob sie auch als qualifiziert anzusehen ist im Sinne der Orientierungshilfe, ist leider nicht definiert. Mit „rechtssicher“ kommt vor allem eine Zustellbestätigung vergleichbar zum alten Einschreiben mit Rückschein der Post. Die wäre bei der klassischen Email zwar möglich, hat sich aber nie durchgesetzt – vielleicht weil das bei leichtsinniger Anwendung zu einer Verdopplung der Mailanzahl geführt hätte. Bei DE-Mail ist ein Einschreiben daher kostenpflichtig. Ende-zu-Ende-Verschlüsselung ist optional möglich, man muss dabei aber den Betreibern und den Browser-Plugins vertrauen, und weder bei der Telekom (hier) noch bei dem gerne verwendeten Browser-Plugin Mailvelope findet sich eine Anleitung, wie man das Schlüsselpaar auf einen neuen Rechner bringt. Da ist der Schlüsselverlust und damit der Gedächtnisverlust fast schon vorprogrammiert.

Ein DE-Mail-Anbieter kann gleichzeitig auch ein Vertrauensdienstanbieter im Sinne der eIDAS-Verordnung sein. Da gibt es aber auch noch andere Alternativen, und im Moment ist nicht erkennbar, dass die interoperabel werden, auch wenn das die eIDAS Verordnung in Artikel 12 vorsieht. Die neueste Variante davon ist der Elektronische Rechtsverkehr, mit den Spielarten Elektronisches Gerichts- und Verwaltungspostfach (EGVP), besonderes elektronisches Anwaltspostfach (beA), und demnächst sollen auch Bürger über den Portalverbund des Online-Zugangsgesetzes rechtsverbindlich kommunizieren können. Beim Elektronischen Rechtsverkehr ist meines Wissens Ende-zu-Ende-Verschlüsselung zumindest bisher nicht vorgesehen.

Bei all diesen Varianten muss ich einem der „Vertrauensdienst“-Betreiber vertrauen — normale Email hingegen kann man selbst betreiben oder einen Anbieter seines Vertrauens wählen. Vertrauen kann man auch über Verträge bilden – aber eine sinnvolle Zusammenstellung der vereinbarten technischen und organisatorische Maßnahmen habe ich weder im Vertrag noch in der Leistungsbeschreibung der Telekom gefunden. Was man da findet ist leider wie oft bei Auftragsverarbeitung sehr lückenhaft. Die Telekom meint auch, sie bräuchte keinen Auftragsverarbeitungsvertrag, weil alles im DE-Mail-Gesetz geregelt sei — bin gespannt ob die Aufsicht das genauso sieht. (31.8.2021: Heise meldet den Ausstieg der Telekom aus DE-Mail)

Ende-zu-Ende-Verschlüsselung mit S/MIME oder (Open)PGP

Bei Ende-zu-Ende-Verschlüsselung werden die Emails meist durch den Benutzer oder seine Client-Software verschlüsselt und mit dem normalen Emailprotokoll übertragen, möglichweise auch noch zusätzlich auf Transportebene verschlüsselt. Es gibt aber auch Dienste die das für den Benutzer durchführen – dazu unten mehr. Von „Ende-zu-Ende“ kann man dann aber eigentlich nicht mehr reden.

Die Vorteile nennt die Datenschutzkonferenz in Ihrer Orientierungshilfe – die Nachteile aber nicht. Daher zu den Nachteilen von S/MIME und PGP:

• Zunächst muss man festhalten, dass die Unterstützung von S/MIME und PGP in gängigen Emailclients eher rudimentär als komfortabel ist. Immer wieder gibt es Situationen in denen die Software nicht mitspielt oder sich aufhängt. Wie das auf den Weboberflächen gehen soll, ist ein Rätsel. Vermutlich gibt man seinen privaten Schlüssel aus der Hand, aber dann kann man ihn nicht mehr privat nennen.
• Im Unterschied zu Web- und Emailservern, bei denen sich X.509 Zertifikate mit einer begrenzten Anzahl von vertrauenswürdigen Ausstellern durchgesetzt haben, gibt es für Benutzer von S/MIME oder PGP keine vergleichbare vertrauenswürdige Infrastruktur. Auch die Datenschutzkonferenz bestätigt das indirekt in 5.3. Ohne eine Infrastruktur zur Verteilung und Prüfung von Schlüsseln oder Zertifikaten ist die Verwendung von S/MIME oder PGP aber im Massenbetrieb nicht umsetzbar, weil sie regelmäßig am Schlüsselaustausch scheitert und damit auf Nischen wie das Melden von Sicherheitsproblemen begrenzt ist. Fast schon boshaft muss ich feststellen, dass noch nicht einmal der öffentliche Schlüssel des BfDIs die in der Orientierungshilfe gesetzten Anforderungen erfüllt, oder nur indirekt durch Veröffentlichung oder Widerruf auf der Website — aber das kann man schlecht automatisieren und eignet sich eben nicht für den Masseneinsatz.
• Selbst wenn eine Organisation Schlüssel oder Zertifikate bereitstellt, wird sie das entweder auf wenige Ausnahmen beschränken, sie wird zentrales Schlüsselmanagement betreiben, oder sie wird ein Gateway einsetzen, das zentral verschlüsselt, entschlüsselt oder signiert. Sie wird das tun, weil Mitarbeiter auch mal krank werden oder die Organisation verlassen — und auch dann will und muss die Organisation auf Emails zugreifen können — nicht zuletzt auch um Auskunftsansprüche Betroffener erfüllen zu können. Also besagt eine PGP oder S/MIME Verschlüsselung oder Signatur in der Regel nur etwas über die Organisation und nicht über den Mitarbeiter — und ist damit nicht aussagefähiger als eine Transportverschlüsselung und DKIM. Den Einsatz eines Gateways kann man vermuten, wenn alle Emailadressaten einer Organisation den gleichen Schlüssel verwenden, z.B. „poststelle@bfdi.bund.de“.
• Auf das Problem Schlüsselverlust insbesondere bei unbedarften Privatanwendern habe ich schon oben bei DE-Mail hingewiesen.

Was bleibt dann von den Vorteilen? Die Orientierungshilfe erwähnt in 5.3 „Dieser Schutz erstreckt sich dabei nicht nur auf den eigentlichen Transportweg, sondern auch auf die Zwischenspeicherung und -verarbeitung auf den an der Übermittlung beteiligten Servern“. Nun, Email war mal ein sogenanntes Store-and-Forward-System. Man konnte Email fast bei jedem Server aufgeben und der Emailserver hat die dann weitergeleitet. Mit dem Aufkommen von Spam ist das Weiterleiten von Emails aber eher die Ausnahme geworden und wird fast nur noch innerhalb einer Organisation verwendet. Die Übertragung findet also fast immer direkt zwischen zwei Organisationen oder den von ihnen beauftragten Auftragsverarbeitern statt — und da kann die Organisation auch durch Verschlüsselung der Emailablage oder auch der Datenträger einen vergleichbaren Schutz erreichen. Einen Unterschied kann ich nur dann erkennen, wenn die Organisation ihren eigenen Sicherheitsmaßnahmen oder denen ihrer Auftragsverarbeitern nicht vertraut — aber sollte man dann nicht lieber da nachbessern als die Komplexität nach oben zu treiben?

Es ist mir unverständlich, warum die Datenschutzkonferenz Ende-zu-Ende-Verschlüsselung gewissermaßen als Goldstandard ausgibt, anstelle DNSSEC und DKIM oder ggfs. auch DE-Mail zu propagieren.

Andere Möglichkeiten der Emailverschlüsselung

Was kann man sonst tun?

Nicht erwähnt wird die Verschlüsselung von Anhängen mit einem Passwort. Man kann vertrauliche Dokumente z.B. in ein passwortgeschütztes Zip packen und das als Anhang verschicken. Analog kann man PDFs mit einem Passwort schützen. Das Passwort übermittelt man dann aber bitte nicht per Email sondern auf einem anderen Kanal. Mit dieser Technik schaffen es in aller Regel auch ungeübte Benutzer, eine verschlüsselte Email zu verschicken — S/MIME oder PGP ist da eine ganz andere Herausforderung. Oder noch besser — wie auch Fußnote 4 in der Orientierungshilfe vorschlägt: man packt Dokumente auf einen Webserver und lässt seine Mitarbeiter oder Kunden nach Anmeldung auf diese zugreifen.

Was sollte man eher nicht tun?

• Nachdem ich mir PGP angesehen und mich dagegen entschieden habe, schickt mir das BfDI bei jeder Auskunftsanfrage eine CD per Postzustellurkunde und das Passwort separat per Email. Einmal das Passwort per Postzustellurkunde, dann verschlüsselte Anhänge oder Dokumente auf einem Webserver — das wäre deutlich effizienter.
• Eine Lebensversicherung hat mich erst aufgefordert, meine Einverständnis zur Kommunikation per Email zu erteilen, mit dem folgenden Passus: „Ich habe den ausdrücklichen Hinweis der ... zur Kenntnis genommen und verstanden, dass Bedenken gegen die Versendung von Vertragsdetails per unverschlüsselte Email bestehen. Mir ist bewusst, dass auf diesem Wege auch ohne Verschulden von ... unbefugte Dritte die in den Emails stehenden Details zu meinem Vertrag einsehen könnten.“. Ich habe der unverschlüsselten Kommunikation widersprochen, aber darauf hingewiesen dass ich gerne verschlüsselt kommunizieren kann, denn mein Emailserver kann qualifizierte Transportverschlüsselung. Daraufhin erhielt ich Post mit der Mitteilung „Im übrigen bitten wir um Verständnis, dass eine Korrespondenz zu Ihrem Vertrag durch uns grundsätzlich nicht per E-Mail, sondern ausschließlich per Post erfolgt, da wir als Lebensversicherungsunternehmen besonders schützenswerte Daten verarbeiten, welche nach Auffassung der Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder nicht auf transportverschlüsseltem Wege per E-Mail versendet werden dürfen.“ — da scheint links nicht zu wissen, was rechts tut.

Anfragen über FragDenStaat

Ich habe inzwischen sowohl beim BSI (https://fragdenstaat.de/a/228518) als auch bei der Datenschutzkonferenz (https://fragdenstaat.de/a/229010) Anfragen dazu laufen.