Im Kontext der aktuellen Berichterstattung über bekannt gewordene Sicherheitsmängel des von der BRAK betriebenen besonderen elektronischen Anwaltspostfachs beA (vgl. heise, Golem), dessen Nutzung ab dem 1. Januar 2018 verpflichtend für alle Rechtsanwälte werden sollte, erhielten wir Nachfragen verunsicherter Kunden, ob dort aufgedeckte Probleme auch für die von uns betriebene Kommunikationsplattform für Rechtsanwälte und Mandanten (MavoRA) von Relevanz sind. Dies ist nicht der Fall, wie wir im Folgenden kurz darlegen möchten.

MavoRA steht in keinerlei Beziehung zum beA, sondern ist ein eigenständig entwickeltes Softwareprodukt. Es basiert auf von uns am CISPA bzw. der Universität des Saarlandes durchgeführten Forschungsprojekten im Bereich angewandter Kryptographie und verwendet anerkannte und verbreitete kryptographische Verfahren und Open-Source-Bibliotheken. Die Sicherheit für unsere Kunden hat für uns stets höchste Priorität, was zu einer Reihe von Entwurfsentscheidungen führt, die unsere Produkte von vergleichbaren Lösungen abheben.

Verzicht auf Softwareinstallation

Auslöser der aktuellen Berichterstattung zum beA war ein privater Schlüssel zu einem Zertifikat, der als Teil des von allen beA-Nutzern lokal zu installierenden beA-Clients ausgeliefert wurde. Das Zertifikat sollte eine TLS-geschützte, vermeintlich sichere Kommunikation zwischen dem Browser des Nutzers und dem lokal installierten beA-Client ermöglichen. Wie heise berichtete, wurde das Zertifikat nach Bekanntwerden der Veröffentlichung des privaten Schlüssels, die diese Sicherheit unterwanderte, von der ausstellenden Zertifizierungsstelle zurückgezogen und somit die Kommunikation zwischen Browser und beA-Client unterbunden. Der Betreiber des beA empfahl daraufhin (vgl. Golem), das betroffene Zertifikat als Root-Zertifikat zu installieren, womit zwar die Nutzbarkeit des beA-Clients wiederhergestellt war, das Sicherheitsproblem aber auf sämtlichen HTTPS/TLS-Datenverkehr ausgeweitet wurde. (Ob Ihr System dadurch verwundbar ist, können Sie hier prüfen.) Aber auch über dieses konkrete Problem hinaus gibt es in jüngster Berichterstattung Kritik an dem zu installierenden beA-Client, etwa in Hinblick auf Gefährdungspotential durch veraltete Software (vgl. Golem).

Im Gegensatz zum beA erfordert MavoRA keinerlei Softwareinstallation oder sonstige Veränderungen an Endgeräten von Nutzern. Wir setzen ausschließlich auf Technologien, die in allen gängigen, modernen Browsern standardmäßig bereits verfügbar sind. So wird ein Gefährdungspotential durch veraltete oder fehlerhafte Softwarekonfigurationen auf Nutzerseite im Vorfeld ausgeschlossen. Da keine zusätzlichen Berechtigungen benötigt werden, ist die Nutzung von MavoRA nicht gefährlicher als der Besuch einer herkömmlichen Webseite.

Echte Ende-zu-Ende-Verschlüsselung

Beim beA werden – auf einem Hardware Security Module (HSM) – betreiberseitig Kopien privater Nutzerschlüssel vorgehalten, um eine Umschlüsselung von Nachrichten für andere Nutzer zu ermöglichen (Golem berichtet). Eine solche Funktion gibt es bei MavoRA nicht: Nutzerschlüssel liegen hier ausschließlich in den Browsern der jeweiligen Nutzer vor und werden unter keinen Umständen an uns als Betreiber übertragen. Auch eine gegebenenfalls erforderliche Umverschlüsselung etwa beim Gewähren von Zugriffsrechten an andere Nutzer wird bei uns konsequent im Browser berechtigter Nutzer durchgeführt.

Zur Sicherheit der Verschlüsselung im Browser

Einzig die Nutzung des Browsers zur Ver- und Entschlüsselung ausgetauschter Dokumente haben das beA und MavoRA gemein. Der für die Kryptographie zuständige JavaScript-Code ist dazu Teil des Webinterfaces und wird beim Aufruf der Kommunikationsplattform vom Anbieter bereitgestellt. Auch diese Vorgehensweise wird von Golem kritisiert – mit der Begründung, dass dadurch ein Vertrauen in den Betreiber der Serverinfrastruktur nötig sei.

Grundsätzlich gilt, dass bei Verwendung einer Verschlüsselungslösung ein Vertrauen in den jeweiligen Entwickler bzw. Anbieter erforderlich ist. Jedoch ist diese Einschränkung nicht speziell für die beschriebene und auch von uns verwendete Webinterface-Lösung. Auch bei Einsatz eines lokal zu installierenden Softwareprodukts, das die Verschlüsselung implementiert, müsste darauf vertraut werden, dass die Verschlüsselung korrekt durchgeführt wird. Ein zu installierendes Softwareprodukt, das regelmäßig oder gar automatisch mit Aktualisierungen versorgt wird (worauf aus Sicherheitsgründen nicht verzichtet werden sollte), würde sich aus dieser Sicherheitsperspektive nur marginal von einer webbasierten Verschlüsselungslösung unterscheiden.

Um uns Ihr Vertrauen zu verdienen, betreiben wir unsere technische Infrastruktur nach höchsten Sicherheitsstandards. Wir passen unsere Software fortlaufend an technische Entwicklungen an und unsere Prozesse umfassen auch eine regelmäßige Aktualisierung verwendeter Bibliotheken. Unsere Webserver übertragen ausschließlich gesichert via TLS; auf Einbindung von Daten (JavaScripts, Stylesheets, o.ä.) aus externen Quellen verzichten wir gänzlich. Nur so kann eine Manipulation durch Dritte effektiv ausgeschlossen werden, sodass ein Vertrauen lediglich in uns als Betreiber erforderlich ist. Die von uns eingesetzten Rechenzentren befinden sich zudem in Deutschland und sind zertifiziert nach ISO 27001 und ISO 27018.

• alle Artikel