Das “besondere elektronische Anwaltspostfach” – gut gemeint, nicht gut gemacht

Zum Jahreswechsel soll es so weit sein: Das besondere elektronische Anwaltspostfach (kurz beA) soll verpflichtend für alle Rechtsanwälte in Deutschland werden. Darüber soll künftig der E-Mail-Verkehr mit Gerichten, Behörden und anderen Rechtsanwälten laufen.

Wie muss man sich das technisch vorstellen?
Um das beA zu nutzen, muss der Anwalt neben der Installation des beA-Client – also dem Programm auf dem eigenen Rechner – auch eine beA-Smartcard bestellen, mit der er sich dem System gegenüber ausweisen kann. Der Datenaustausch innerhalb des Rechners zum Auslesen der Smartcard wird verschlüsselt. Für diese Verschlüsselung wird ein Zertifikat mit privatem Schlüssel auf dem Rechner abgelegt. So weit ist das auch alles in Ordnung.

Wo liegt jetzt das Problem?
Hersteller Atos hat es sich sehr einfach gemacht und bei allen Installationen das gleiche Zertifikat verwendet, das von T-Systems für die IP-Adresse des eigenen Rechners 127.0.0.1 (localhost) ausgestellt wurde. Da so etwas regulär überhaupt nicht möglich ist, hat Atos zu einem Trick gegriffen: es wurde die Domain bealocalhost.de registriert, zu dieser das Zertifikat beantragt, und dann diese Domain auf die localhost-Adresse umgestellt. Dieses Zertifikat inklusive des privaten Schlüssels wurde dann an die Rechtsanwälte verteilt.

Dies trägt zum einen ein gewisses Angriffsrisiko in sich, zum anderen widerspricht es vor allem den Regeln der meisten Zertifizierungsstellen, inklusive denen von T-Systems. Jemand könnte sich durch einen “Man in the Middle”-Angriff in die Kommunikation eines Anwaltes einklinken und die Adressauflösung von bealocalhost.de manipulieren, um diese auf ein eigenes System umzuleiten. So könnte er mit dem bekannten privaten Schlüssel eine vertrauenswürdige Seite vortäuschen und unbemerkt die Daten zwischen den Komponenten des beA mitlesen und manipulieren.

Wird da jetzt was unternommen?
Den Verstoß gegen die Regeln der Zertifizierungsstelle hat der CCC Darmstadt aufgegriffen und bei T-Systems gemeldet. Diese hatten damit keine andere Wahl, als das Zertifikat zu widerrufen. Daraufhin war das beA am 22.12.2017 funktionsunfähig.

Der Hersteller musste nun schnell reagieren, um die Pflichtnutzung zum 01.01.2018 abbilden zu können. Als schnelle Lösung hätte Atos zum Beispiel eine eigene Zertifizierungsstelle starten und bei jedem Client ein eigenes Zertifikat erzeugen lassen können. Bei jeder Installation wäre ein eigener privater Schlüssel vorhanden, es gäbe eine zentrale Stelle, die die Echtheit dieser Zertifikate bestätigt. Bei der Installation müsste nur einmal eine Warnung bestätigt werden, dass diesem Zertifikat vertraut wird, und alles würde funktionieren.

Wurde das so umgesetzt?
Leider nein. Statt dessen wurde ein selbst-signiertes Zertifikat als Ersatz für das von T-Systems generiert und wieder auf jedem Rechner das gleiche Zertifikat mit dem dazugehörigen privaten Schlüssel installiert. Um zu vermeiden, dass beim Aufruf einer solchen Seite der Browser eine Warnung ausgibt, wurde eine Anleitung verteilt, dieses Zertifikat als Root-Zertifikat auf dem Rechner zu installieren. Nach Befolgen dieser Anleitung wird der Rechner jedem Zertifikat vertrauen, welches durch das unsichere Zertifikat bestätigt wurde. Während beim ersten Fehler “nur” die Kommunikation zwischen beA-Komponenten potentiell unsicher war, kann nun keiner HTTPS-Verbindung dieses Rechners mehr vertraut werden. Es betrifft also jetzt auch Datenaustausch, der überhaupt nichts mehr mit beA zu tun hat.

Inzwischen ist diese Anleitung zurückgezogen, eine Warnung an diejenigen, die dieser eventuell bereits gefolgt sind, wurde aber vom Hersteller nicht ausgesprochen. Diese Warnung wird anderen überlassen.

Wie hätte es einfacher gehen können?
Man hätte eine Lösung “von der Stange” nehmen können. Eine sichere Kommunikation per E-Mail ist ja nun nicht wirklich neu. So gibt es das bei privaten Nutzern immer mehr verwendete PGP (Pretty Good Privacy) oder das eher im geschäftlichen Bereich genutzte S/MIME. Letzteres wird z.B. von der DATEV beim Austausch sensibler Buchhaltungsdaten seit Jahren erfolgreich verwendet.

Während bei PGP die Echtheit der Schlüssel durch ein Web of Trust bestätigt wird (also: ich kenne jemanden, der jemanden kennt, der den Schlüssel bestätigt hat), wird bei S/MIME auf Zertifizierungsstellen zurückgegriffen. Die Zertifikate können auch auf einer Smartcard abgelegt werden, wodurch eine erhöhte Sicherheit hergestellt wird. Wenig aufwändig und sehr sicher wäre also einfach die Ernennung einer oder mehrerer Zertifizierungsstellen für den Rechtsverkehr, die Zertifikate mit hinreichend sicherer Identifizierung des Inhabers herausgeben und die Vorgabe für Rechtsanwälte, eine E-Mailadresse mit Verschlüsselung und qualifizierter elektronischer Signatur mittels eines solchen Zertifikates vorzuhalten. Eine solche Lösung muss auch nicht über 10 Millionen Euro im Jahr kosten wie beA.