Im Zuge des Projekts Bürgerportale wurde auf dem IT-Gipfel angekündigt, mit De-Mail einen rechtsverbindlichen Maildienst zu erstellen. Der Dienst wird vom Bundesministerium des Innern und der Deutschen Telekom implementiert - das klingt zu Zeiten von Bundestrojaner und BKA-Gesetz und immer weiteren Bespitzelungs-Skandalen nach einer unheiligen Allianz für so ein Vorhaben. Entsprechend kritisch sind die Stimmen auf der zugehörigen "E-Konsultation" (von Isotopp und
Erster berechtigter Einwand: Wozu eine neue Technik, es gibt doch GnuPGP und kostenlose SMIME-Zertifikate über CACert, Verisign oder Thawte. Ich habe versucht, die Features von De-Mail (aufgrund der Langfassung der Beschreibung) zusammenzuschreiben, die zugehörige Implementierung zusammenzufassen und das mit den erwähnten vorhandenen Alternativen zu vergleichen.
De-Mail-Features
Feststellung der Identität: Um eine De-Mail-Adresse zu beantragen, muß man sich geeignet ausweisen. Dies kann beispielsweise in den lokalen Bürgerzentren oder beim Einwohnermeldeamt geschehen - oder aber der Bund holt sich hier die Post oder Banken mit ins Boot, welche die Überprüfung der Identität und die Entgegennahme des Antrags übernehmen. Den Providern soll es so möglich sein, im Falle eines Rechtsstreits jedem Account eine Realperson zuordnen zu können.
Sowohl natürliche als auch juristische Personen können eine De-Mail-Adresse beantragen. Juristische Personen können dabei nochmals entsprechend ihrer Organisation untergliedert werden (z.B. separate Adressen für Geschäftsleitung, Vertrieb, Buchhaltung, etc.).
Transparenz: De-Mail soll (zumindest in der Grundfunktionalität) für den Bürger vollkommen transparent sein, d.h. er soll weder zusätzliche Hardware noch besondere Software hierfür benötigen.
Adress-Struktur: Die De-Mail-Adresse bekommt eine wohldefinierte Struktur:
<em>empfaenger</em>@<em>providername</em>.de-mail.de
Durch die Aufnahme des Providers als Subdomain wird ermöglicht, De-Mail über verschiedene Provider anzubieten. Der Empfänger hat die Struktur "vorname.nachname[.nummer]"; es soll den Benutzern jedoch möglich sein, pseudonyme Mailadressen zu erstellen. Um diese von den regulären Adressen zu unterscheiden, wird ihnen ein "ps_" vorangestellt.
Authentisierungsstufen: Für eine "einfache" Authentisierung soll ein Paßwort genügen, für die beiden weiteren Authentisierungsformen "hoch" und "sehr hoch" ist eine Zweifaktor-Authentisierung (Authentisierung durch Besitz und Wissen) erforderlich. Die Art der Authentisierung wird - so vermute ich - beim Versand von Mails zusätzlich vermerkt.
Versandoptionen: Der normale "De-Mail-Versand" ist gegen Mitlesen Unberechtigter und Änderungen an Nachrichteninhalt und Metadaten geschützt. Beim "De-Mail-Einschreiben" erhält der Sender zusätzlich (kryptographisch signierte) Meldungen über den Versand der Nachricht und die Zustellung im Empfänger-Postfach.
Weiterhin kann durch die Option "persönliche Zustellung" eine besondere Authentisierung des Empfängers (mindestens "hoch") erfordert werden. Umgekehrt erzwingt die Option "verbindliche Zustellung" eine solche Authentisierung durch den Absender.
Implementierung von De-Mail
Die durch die Subdomänen skizzierte Struktur und die Anforderung, im Falle der normalen Authentisierung ohne weitere Hard- oder Software auszukommen, läßt meiner Meinung nach nur eine mögliche Architektur zu: Die Bildung eines "trusted core". Alle De-Mail-Provider werden darauf eingeschworen, sich an vereinbarte Verhaltensweisen und Sicherheitsvorschriften zu halten.
Das Absenden einer De-Mail kann nur über einen De-Mail-Provider geschehen. Dieser nimmt die Mail (nach erfolgreicher Authentisierung) via ESMTP/SMTPS über eine mit TLS verschlüsselte Verbindung entgegen. Der Austausch der Mail zwischen den De-Mail-Servern geschieht ebenfalls ausschließlich über verschlüsselte Kanäle, so daß "Mitlesen Unberechtigter und Änderungen an Nachrichteninhalt" unmöglich ist (und die De-Mail-Provider sind ja "die Guten" und tun so etwas nicht). Der Empfänger ruft schließlich die Mails ebenfalls ausschließlich über eine TLS-verschlüsselte Verbindung ab - so entsteht eine Sicherheits-Kette gegen Angreifer von außen.
Die Versand- und Empfangsbestätigungen sind in den De-Mail-Servern trivial zu implementieren.
Vergleich zu PGP/SMIME
Auch PGP und SMIME bieten durch Verschlüsselung und digitale Signatur, die Möglichkeit der Identifizierung des Absenders. PGP bindet den öffentlichen Schlüssel an eine reale Identität durch das "Web-of-trust" in Form von Bestätigungen (Signaturen) des Schlüssels, SMIME-Identitäten werden durch die Zertifizierer der Public-Key-Infrastruktur (PKI) bestätigt. Was diese beiden Ansätze nicht bieten können, sind die authentischen Versand- und Zulieferungsbestätigungen sowie die Unterscheidung verschiedener Authentisierungs-Mechanismen.
Sowohl PGP/SMIME als auch De-Mail setzen eine Infrastruktur voraus, um ihren Dienst erfüllen zu können: Im Falle von PGP/SMIME ist diese nur offline benötigt (die Schlüssel/Zertifikate müssen einmal bereitgestellt werden und werden dann lokal gespeichert), De-Mail benötigt sie jedoch "online", also aktiv bei jeder Benutzung - die Sicherheit von De-Mail liegt inhärent und einzig im Aufbau der Infrastruktur.
Bewertung und Kritik
De-Mail erfüllt die gestellten Anforderungen - jedoch nur, so lange man sich innerhalb des Systems bewegt. Dazu kommt, daß man den Providern blind vertrauen muß - auch ohne Schäuble-Beißreflex wird einem da mulmig zumute, insbesondere, wenn man sich die vergangenen Projekte von Telekom, T-Systems und Co. ansieht. Für etwas paranoider veranlagte Zeitgenossen stellt diese Infrastruktur (so sie sich etabliert) die zentrale Schnüffelstelle für E-Mails dar (es muß ja noch nicht einmal der Saat sein, der schnüffeln will; die Telekom hat sich da ja mit dem aktuellen Skandal auch einen Name gemacht).
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.
Ein technisches Problem wird der "Grenzübertritt" zur restlichen E-Mail-Welt sein: Eine reine Insellösung, ohne die Möglichkeit, von nicht-De-Mail-Sendern Mails zu empfangen (oder an diese zu verschicken), wird sich sicherlich nicht etablieren. Mails, die von einem Nicht-De-Mail-Mailserver zugestellt werden, müssen also in irgendeiner Form als nicht authentisiert markiert werden. Mails mit einer De-Mail-Absender-Adresse, die von außen kommen, sollten sogar abgewiesen werden. Allgemein stellt sich die Frage, wie die Markierung der Mails (Authentisch, verbindliche Zustellung) RFC-konform geschehen soll; zusätzliche "X-Header" wären eine Möglichkeit, doch von diesen bekommt der Benutzer eines nichtmodifizierten Mailprogramm nichts mit. Die einzige verbleibende Möglichkeit ist die Modifikation des Mail-Bodys - und das ist eine Büchse der Pandora: Zum einen kann ich aus eigener leidvoller Erfahrung sagen, daß das Modifizieren von Mails ein ziemliches Gefummel ist (es gibt immer einen Mailclient, der sich nur "so in etwa" an die RFCs hält). Zum anderen muß sichergestellt werden, daß die entsprechende Anmerkung nicht schon vom Absender getätigt wurde. Entsprechende Textpassagen/Anhänge müssen also ausgefiltert werden. Was aber, wenn der Angreifer "absichtlich unabsichtlich" Tippfehler (die auf den ersten Blick nicht auffallen) einbaut? Oder Unicode-Zeichen verwendet, die dem normalen Zeichen zum Verwechseln ähnlich sehen?
Das ganze ist - vorsichtig ausgedrückt - mit glühend heißer Nadel gestrickt (etwas polemischer könnte man auch laut "Snake Oil!" rufen). Ein Kartenhaus, das beim kleinsten Fehler in sich zusammenstürzen droht. Allein schon die Gefahr durch Provider-Insider oder -Fuckup ist zu groß. Rechtsverbindliche E-Mails? Da sollte man keine Experimente machen, sondern auf bewährte Techniken wie S/MIME (oder PGP) zurückgreifen. S/MIME wird von faktisch jedem aktuellen Browser unterstützt, für PGP gibt es inzwischen ebenfalls viele vernünftige Plugins.
Wieso steckt man das Geld nicht in Weiterentwicklung von Open-Source-Plugins (und/oder -Mailclients) sowie den Aufbau einer geeigneten CA? Gängiger Vorwurf ist die Speicherung des Secret Keys auf dem Rechner, der potentiell virengefährdet ist; bei der Eingabe des De-Mail-Kennworts (Sicherungsstufe "normal") verhält es sich jedoch genau gleich.
Weiterer Vorteil von PGP/SMIME: Echte Ende-zu-Ende-Verschlüsselung und harte überprüfbare Signaturen. Diese lassen sich auch nach der Zustellung der Mail noch prüfen (sogar wenn man sie ausdruckt ;-) ). Die Beweiskette ist bei De-Mail beim hauseigenen Postfach unterbrochen; eine entsprechende Mail zu fingieren ist kein Problem. Die einzige Möglichkeit wäre das Überprüfen der Mail-Log-Files, und diese werden (hoffentlich!) nicht allzu lange aufbewahrt.
Noch ein Vorteil: Weiterverwendbarkeit bestehender Mailadressen (bei "vertrieb@firmenname.de" und ähnlichem ebenfalls ein nicht zu vernachlässigen).
Man fragt sich also ernsthaft, wieso man diesen Weg beschreitet. Mit ein wenig Phantasie kann man De-Mail als PR-Aktion für die aktuelle Sicherheitspolitik sehen:
- Das Abhören von Mails wird einfacher, da so ein Teil des Mailverkehrs gebündelt wird
- Die Sicherheitsstufen "hoch" und "sehr hoch" verlangen zur Authentisierung nach dem Beweis von "Wissen und Besitz". Das könnte der elektronische Personalausweis plus die PIN zu dessen Aktivierung sein - man muß ja irgendwie den Beweis antreten, daß dieses Teil für irgendetwas gut ist!
- So ein Dienst will erst einmal aufgebaut werden, und auch der Unterhalt kostet Geld. Und dafür soll der Absender e-Porto zahlen. Ist das die heimliche staatliche Finanzspritze für die Telekom? Wer hat da nochmal über die Internet-Noobs gelästert, die nach dem Schreiben einer Mail gefragt haben, wo man nun die Briefmarke aufklebt? Zukünftig sehen die Mailprogramme wohl wirklich so aus:
