Kaum daß de-Mail offiziell an den Start gehen soll, sind die einschlägigen Webseiten voll mit Meldungen wie De-Mail ist unsicher. Kurze Durchsage: Die (an einem Teil des Systems geäußterter) Kritik ist kalter Kaffee und war bereits nach einem kurzen Blick auf das Design zu erkennen.

Fleißige Leser dieses Blogs konnten bereits vor anderthalb Jahren hierzu lesen:

"Die Provider sind die Achillesferse des Systems. Durch die Hop-by-Hop-Verschlüsselung liegt die Mail bei jedem De-Mail-Provider, den eine De-Mail durchläuft, im Klartext und ohne irgendeine digitale Signatur vor. Wird einer davon kompromittiert, gleicht das einem dammbruchartigen Zwischenfall - das Ziel ist ja nicht weniger als rechtsverbindliche E-Mails zu schaffen, und wer in der Rolle eines der Provider steckt, kann solche E-Mails nach Belieben selbst erzeugen oder verändern. Auch hier gilt, daß es nicht einmal der böse Angreifer von außen sein muß: Konzerne wie die Telekom sind zu groß, als daß nicht früher oder später irgendein Mitarbeiter mit Zugriff seine Privilegien mißbrauchen wird."

Die inzwischen veröffentlichte Dokumentation zu De-Mail bestätigt die Architektur, die bei meinem letzten Blogartikel ja nur im Freitext beschrieben war. In einer Übersichtsgrafik sieht sie folgendermaßen aus:

De-Mail Architekturübersicht

Kai Raven äußert sich in seinem Blog kritisch über die Berichterstattung, die De-Mail als per-se unsicher darstellt. In einem Punkt hat er recht: Von Anfang an waren verschiedene Autentisierungsstufen geplant, die sich auch in der technischen Richtlinie wiederfinden:

"Das Authentisierungsniveau, mit dem der Nutzer sich am BP-Account anmeldet, wird sowohl beim Versand einer Nachricht als auch beim Lesen von empfangenen Nachrichten berücksichtigt.
(...)
Möchte der Sender seine Nachricht bzw. Nachrichteninhalte elektronisch signieren und/oder verschlüsseln, so kann er dies mit einer lokalen Signaturanwendungskomponente (SAK) bzw. mit einer lokalen Verschlüsselungskomponente durchführen. Diese Komponenten können auch in dem lokalen Web- bzw. Nachrichten-Client, mit dem er die Nachrichten editiert, integriert sein. So signierte und/oder verschlüsselte Nachrichten kann der Empfänger mit lokalen Komponenten entschlüsseln und vorhandene Signaturen prüfen."

De-Mail sieht also zwei weitere Sicherungsmaßnahmen vor: Eine Anmeldung mit sichereren Verfahren als Benutzername und Paßwort sowie Eine Ende-zu-Ende-Verschlüsselung mit Hilfe einer "Signaturanwendungskomonente". Beides läßt sich nur mit lokal installierter Clientsoftware (und nicht über das Webinterface) bewerkstelligen und - wenn man es wirklich vernünftig machen will - wird auch entsprechende Hardware dafür benötigt. Letzteres wird mit an Sicherheit grenzender Wahrscheinlichkeit der elektronische Personalausweis (ePA) und ein entsprechendes Lesegerät sein.

Die harsche Kritik ist meiner Meinung nach hingegen berechtigt - immerhin war die De-Mail mit dem Vorsatz angetreten, eben keine solche Zusatzhardware zu benötigen:

"Diese Bürgerportale sollen möglichst ohne dedizierte Client-Software und ohne zusätzliche Hardware nutzbar sein."

Die Varianten mit dedizierter Krypto-Hardware sollten lediglich erweiterte Zusatzfunktion für besonders sensible Kommunikation sein. Genau diese Ziele werden aber verfehlt, wenn man nicht der skizzierten Problematik anheim fallen will. Entweder ist De-Mail von der Sicherheit her ziemlich lausig - oder aber De-Mail wird seinen eigenen Ansprüchen nicht gerecht; und wenn man schon entsprechende Hardware nutzt, kann man das ganze auch vernünftig machen und qualifizierte Signaturen nach dem Signaturgesetz verwenden. Damit ist man auch das proprietäre abgeschlossene Mailsystem mit seinen elektronischen Briefmarken los.

Umgekehrt stellt die Kombination aus Authentisierungsniveau und reiner webbasierter De-Mail ein weiteres Sicherheitsproblem dar, sofern diese möglich ist und dem Authentisierungsniveau eine besondere rechtliche Bedeutung zuteil wird: In diesem Fall ist auch das Authentisierungsniveau komplett vom De-Mail-Provider manipulierbar.

Ich fasse nochmal zusammen:

• Jeder De-Mail-Provider kann ein-, aus- oder durchgehende De-Mails, die rein über das Webinterface erstellt wurden bzw. keine Ende-zu-Ende-Sicherung erhalten haben, lesen oder nach Belieben manipulieren.
• Ein Provider kann De-Mails von Kunden, die ihre De-Mail-Adresse bei ihm beheimatet haben, beliebige neue Mails generieren (zusammen mit allen anderen nötigen Logeinträgen wie dem An- und Abmelden am Webinterface sowie den Mailserver-Logs)
• Ein Provider kann De-Mails seiner Kunden löschen bzw. Empfangs- und Lesebestätigungen fälschen (auch hier wieder inklusive aller dafür nötigen Logeinträge vom Webinterface und Mailserver)
• Sofern das Authentisierungsniveau nicht in irgendeiner Form eine Ende-zu-Ende-Sicherung erfährt, kann es ebenfalls vom Provider manipuliert werden, die Tatsache, daß sie "sowohl beim Versand einer Nachricht als auch beim Lesen von empfangenen Nachrichten berücksichtigt" (sprich: angezeigt) wird, wäre somit Makulatur.

De-Mail ist damit nicht nur der gelangweilte Briefträger, der die Postkarten der Einwohner seines Bezirks liest; das ist ein Postbote, der durch einen Teil der (vermeintlich undurchsichten) Briefumschläge hindurchsieht und Unterschriften perfekt fäschen kann.