Das beA, die eAkte und der elektronische Rechtsverkehr – Sicherheitsarchitektur auf dem Prüfstand

Der elektronische Rechtsverkehr in Deutschland ruht auf drei Säulen: dem besonderen elektronischen Anwaltspostfach (beA), dem elektronischen Gerichts- und Verwaltungspostfach (EGVP) und der elektronischen Akte (eAkte). Alle drei sind auf eine funktionssichere, vertrauliche und integre digitale Kommunikation zwischen Anwälten, Gerichten und Behörden angewiesen. Die Sicherheitsgeschichte dieser Systeme gibt Anlass, die zugrunde liegende Architektur kritisch zu betrachten – umso mehr, als KI-gestützte Werkzeuge die Bedrohungslage verändern.

Die beA-Krise 2017/2018: Mehr als eine Panne

Im Dezember 2017 entdeckte der Chaos Computer Club Darmstadt eine schwerwiegende Sicherheitslücke in der Client-Software des beA: Der private Schlüssel eines TLS-Zertifikats konnte aus dem Speicher der Anwendung extrahiert werden. Damit war die gesamte Transportverschlüsselung zwischen Anwalt und beA-Server kompromittierbar.

Die BRAK reagierte mit einem Schnellschuss, der die Lage verschlimmerte: Alle Anwälte wurden aufgefordert, ein von der BRAK selbst generiertes Root-Zertifikat zu installieren. Der CCC warnte, dass dies selbst ein enormes Sicherheitsrisiko darstelle, weil es der BRAK – oder einem Angreifer, der Zugang zu dem Zertifikat erlangt – ermöglicht hätte, jede verschlüsselte Verbindung abzufangen.

Das beA ging für neun Monate offline. Erst nach einem Secunet-Audit 2018 und einem Secuvera-Audit 2020 wurde es wieder in Betrieb genommen. Seit dem 1. Januar 2022 besteht die aktive Nutzungspflicht für alle Rechtsanwälte.

Die architektonische Grundkritik: Keine echte Ende-zu-Ende-Verschlüsselung

Die Kritik am beA geht über einzelne Sicherheitslücken hinaus. Sie betrifft die Architektur selbst. Das beA nutzt keine echte Ende-zu-Ende-Verschlüsselung im kryptographischen Sinne. Nachrichten werden nicht ausschließlich mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und erst bei diesem entschlüsselt. Stattdessen findet eine serverseitige Umschlüsselung über Hardware Security Modules (HSM) statt.

Der Grund ist funktionaler Natur: Das beA muss eine Vertretungsregelung ermöglichen. Wenn ein Anwalt erkrankt, muss sein Vertreter Zugang zu den Nachrichten erhalten. Eine reine Ende-zu-Ende-Verschlüsselung mit personengebundenen Schlüsseln würde das verhindern. Die Lösung über HSM-Module ermöglicht diese Flexibilität.

Die Kehrseite: Die HSM-Module bilden eine zentrale Angriffsstelle. Wer Zugang zu ihnen erlangt – sei es durch einen technischen Angriff, sei es durch eine staatliche Anordnung – kann alle Nachrichten entschlüsseln. Sicherheitsforscher bezeichnen diese Architektur als Sollbruchstelle. Der BGH hat das beA dennoch als sicher im Rechtssinne eingestuft – eine Formulierung, die Kritiker als Zirkelschluss bewerten: Das System ist sicher, weil das Gesetz es als sicher definiert.

Open Source vs. proprietärer Code

Der Quellcode des beA ist proprietär. Weder Sicherheitsforscher noch die Anwaltschaft selbst können den Code unabhängig prüfen. Der CCC, die Free Software Foundation Europe und mehrere Rechtsanwaltskammern haben wiederholt die Veröffentlichung als Open Source gefordert.

Die Argumentation ist nicht ideologisch, sondern sicherheitstechnisch: Proprietärer Code verhindert eine breite, unabhängige Sicherheitsüberprüfung. Schwachstellen, die einem einzelnen Auftragnehmer entgehen, könnten von der Community entdeckt werden. Die Sicherheitspannen von 2017/2018 wären bei öffentlich einsehbarem Code möglicherweise früher aufgefallen.

Im Kontext von KI-gestützter Schwachstellensuche gewinnt dieses Argument zusätzlich an Gewicht. Claude Mythos und vergleichbare Werkzeuge können Quellcode systematisch nach Schwachstellen durchsuchen. Wenn der beA-Code nicht öffentlich ist, können nur die BRAK und ihr Auftragnehmer solche Werkzeuge einsetzen. Ist der Code öffentlich, steht er der gesamten Sicherheitsforschungsgemeinschaft zur Verfügung.

Die eAkte: Digitalisierung erhöht die Angriffsfläche

Die elektronische Akte war gesetzlich zum 1. Januar 2026 vorgeschrieben. Nach der vom Bundestag im November 2025 beschlossenen Übergangsregelung wird eine flächendeckende Verfügbarkeit erst 2027 erwartet. Die Verzögerung hat vielfältige Gründe: personelle und finanzielle Engpässe, uneinheitliche IT-Infrastruktur der Länder und ungeklärte Sicherheitsfragen.

Aus Sicherheitsperspektive vergrößert die eAkte die Angriffsfläche der Justiz erheblich. Solange Akten auf Papier geführt werden, erfordert ihr Diebstahl physischen Zugang zum Gericht. Eine digitale Akte kann von jedem Punkt der Welt aus angegriffen werden, der eine Netzwerkverbindung hat. Ein einzelner erfolgreicher Angriff könnte alle Verfahrensakten eines Gerichts offenlegen.

Der Kammergericht-Vorfall von 2019 hat gezeigt, was geschieht, wenn ein Gericht mit mangelhafter Netzwerksicherheit betroffen ist. Die eAkte potenziert dieses Risiko: Statt einzelner Dokumente auf einzelnen Rechnern werden gesamte Verfahrensbestände zentral gespeichert und über Netzwerke zugänglich.

EGVP und die Transportschicht

Das EGVP bildet das Rückgrat des elektronischen Rechtsverkehrs zwischen Gerichten, Behörden und Anwälten. Es nutzt das OSCI-Transportprotokoll, das eine Punkt-zu-Punkt-Verschlüsselung zwischen Absender und Empfänger implementiert. Die Sicherheit des EGVP hängt von der Integrität der Endpunkte ab: Wenn der Rechner des Absenders oder des Empfängers kompromittiert ist, hilft die Transportverschlüsselung nicht.

Die Qualität der Endpunktsicherheit variiert erheblich. Während große Kanzleien und Bundesgerichte über professionelle IT-Infrastruktur verfügen, arbeiten kleine und mittlere Kanzleien häufig mit Standardkonfigurationen, die nicht gehärtet sind. Die Kette ist so stark wie ihr schwächstes Glied.

KI-gestützte Schwachstellensuche und die Justizsoftware

Claude Mythos und vergleichbare Werkzeuge haben Schwachstellen in allen gängigen Betriebssystemen und Browsern gefunden. Die nächste Frage liegt auf der Hand: Was geschieht, wenn solche Werkzeuge gezielt auf Justizsoftware angesetzt werden? Auf das beA, auf eAkte-Systeme, auf die Fachanwendungen der Länderjustiz?

Justizsoftware ist Software. Sie unterliegt denselben Fehlermustern wie jede andere Software. Der Unterschied liegt in den Konsequenzen: Eine Schwachstelle in einer eAkte-Anwendung betrifft nicht nur den Betreiber, sondern alle Verfahrensbeteiligten – Kläger, Beklagte, Zeugen, Richter, Anwälte.

Bisher gibt es kein öffentlich bekanntes Programm, in dem Justizsoftware systematisch auf Schwachstellen geprüft wird. Die BRAK lässt das beA anlassbezogen auditieren. Ein kontinuierliches Sicherheitsaudit, wie es für kritische Infrastruktur zunehmend Standard wird, existiert für die Justiz-IT nicht.

Was BRAK, Länder und Bund tun müssten

Die Sicherheitsarchitektur des elektronischen Rechtsverkehrs braucht eine Neubetrachtung. Die beA-Architektur mit ihrer serverseitigen Umschlüsselung sollte gegenüber echten Ende-zu-Ende-Verschlüsselungslösungen abgewogen werden, die Vertretungsregelungen kryptographisch sauber abbilden. Der beA-Quellcode sollte veröffentlicht werden, damit die Sicherheitsforschungsgemeinschaft ihn prüfen kann.

Für die eAkte müssen verbindliche IT-Sicherheitsstandards gelten, die länderübergreifend einheitlich sind und regelmäßig überprüft werden. Kontinuierliche Sicherheitsaudits – nicht nur anlassbezogene – sollten verpflichtend sein. Die Justizministerkonferenz ist der richtige Ort, um diese Standards zu vereinbaren.

Die Geschwindigkeit, mit der sich die Bedrohungslage verändert, erfordert, dass diese Maßnahmen nicht in Jahren, sondern in Monaten umgesetzt werden. Der nächste Angriff auf die Justiz-IT wird nicht warten, bis die eAkte flächendeckend eingeführt ist. Er kann jederzeit stattfinden.

---

FAQ

1. Was war das Problem mit dem beA 2017/2018?

Im Dezember 2017 entdeckte der Chaos Computer Club eine schwerwiegende Sicherheitslücke in der Client-Software des beA: Der private Schlüssel eines TLS-Zertifikats konnte aus dem Speicher der Anwendung extrahiert werden. Die gesamte Transportverschlüsselung war damit kompromittierbar. Die BRAK verschlimmerte die Lage, indem sie alle Anwälte zur Installation eines selbst generierten Root-Zertifikats aufforderte – was selbst als Sicherheitsrisiko eingestuft wurde. Das beA ging für neun Monate offline und wurde erst nach umfangreichen externen Audits wieder in Betrieb genommen. Die aktive Nutzungspflicht besteht seit dem 1. Januar 2022.

2. Warum hat das beA keine echte Ende-zu-Ende-Verschlüsselung?

Das beA nutzt serverseitige Hardware Security Modules (HSM) zur Umschlüsselung von Nachrichten. Der Grund ist die Vertretungsregelung: Wenn ein Anwalt erkrankt oder verhindert ist, muss sein Vertreter Zugang zu den Nachrichten erhalten. Eine reine Ende-zu-Ende-Verschlüsselung mit personengebundenen Schlüsseln würde das verhindern. Die HSM-Architektur ermöglicht diese Flexibilität, schafft aber eine zentrale Angriffsstelle. Wer Zugang zu den HSM-Modulen erlangt, kann alle Nachrichten entschlüsseln. Kryptographisch saubere Lösungen, die sowohl Ende-zu-Ende-Verschlüsselung als auch Vertretungsregelungen abbilden, sind technisch möglich, wurden aber bei der beA-Entwicklung nicht umgesetzt.

3. Ist das beA jetzt sicher?

Der BGH hat das beA als sicher im Rechtssinne eingestuft. Technisch bleibt die Architektur umstritten. Die serverseitige Umschlüsselung bildet weiterhin eine zentrale Angriffsstelle. Der Quellcode ist proprietär und nicht öffentlich einsehbar. Die Sicherheitsaudits durch Secunet (2018) und Secuvera (2020) haben keine kritischen Schwachstellen mehr ergeben, beruhen aber auf anlassbezogenen Prüfungen. Ein kontinuierliches Sicherheitsaudit, wie es für kritische Infrastruktur zunehmend Standard wird, existiert nicht. Die Formulierung sicher im Rechtssinne bedeutet: Das System erfüllt die gesetzlichen Mindestanforderungen. Ob es einem gezielten Angriff standhält, ist eine andere Frage.

4. Welche Risiken schafft die elektronische Akte?

Die eAkte bedeutet, dass sämtliche Verfahrensakten dauerhaft digital gespeichert und über Netzwerke zugänglich werden. Ein erfolgreicher Angriff könnte alle Urteile, Entscheidungsentwürfe, Gutachten und persönlichen Daten eines gesamten Gerichts offenlegen – einschließlich archivierter Verfahren. Die föderale Fragmentierung führt dazu, dass 16 Bundesländer jeweils eigene Systeme mit unterschiedlichen Sicherheitsniveaus betreiben. Verbindliche einheitliche Sicherheitsstandards fehlen. Der Kammergericht-Vorfall von 2019 zeigte, dass die Justiz-IT bereits gegen herkömmliche Angriffe nicht ausreichend gewappnet war. Die eAkte potenziert dieses Risiko erheblich.

5. Was ist EGVP und wie sicher ist es?

Das Elektronische Gerichts- und Verwaltungspostfach bildet das Rückgrat des elektronischen Rechtsverkehrs zwischen Gerichten, Behörden und Anwälten. Es nutzt das OSCI-Transportprotokoll mit Punkt-zu-Punkt-Verschlüsselung. Die Sicherheit des EGVP hängt von der Integrität der Endpunkte ab: Wenn der Rechner des Absenders oder Empfängers kompromittiert ist, hilft die Transportverschlüsselung nicht. Die Endpunktsicherheit variiert erheblich zwischen großen Kanzleien mit professioneller IT und kleinen Kanzleien mit Standardkonfigurationen. Das Gesamtsystem ist so sicher wie sein schwächstes Glied.

6. Warum wird die Veröffentlichung des beA-Quellcodes gefordert?

Die Forderung nach Open Source kommt vom Chaos Computer Club, der Free Software Foundation Europe und mehreren Rechtsanwaltskammern. Die Argumentation ist sicherheitstechnisch: Proprietärer Code verhindert eine breite, unabhängige Überprüfung. Schwachstellen, die einem einzelnen Auftragnehmer entgehen, könnten von der Sicherheitsforschungsgemeinschaft entdeckt werden. Die Pannen von 2017/2018 wären bei öffentlichem Code möglicherweise früher aufgefallen. Im Kontext von KI-gestützter Schwachstellensuche gewinnt das Argument zusätzlich an Gewicht: Wenn der Code öffentlich wäre, könnten Sicherheitsforscher KI-Werkzeuge einsetzen, um systematisch nach Fehlern zu suchen.

7. Was bedeutet KI-gestützte Schwachstellensuche für die Justizsoftware?

Justizsoftware unterliegt denselben Fehlermustern wie jede andere Software. Claude Mythos und vergleichbare Werkzeuge haben Schwachstellen in allen gängigen Betriebssystemen und Browsern gefunden. Es gibt keinen Grund anzunehmen, dass beA-Software, eAkte-Systeme oder Fachanwendungen der Länderjustiz frei von Schwachstellen sind. Bisher existiert kein öffentlich bekanntes Programm zur systematischen Schwachstellenprüfung von Justizsoftware. Die BRAK lässt das beA anlassbezogen auditieren. Ein kontinuierliches Sicherheitsaudit, wie es für kritische Infrastruktur Standard wird, fehlt. Angesichts der sich verändernden Bedrohungslage ist das eine Lücke, die geschlossen werden muss.

8. Wann kommt die flächendeckende eAkte?

Die elektronische Akte war gesetzlich zum 1. Januar 2026 vorgeschrieben. Der Bundestag hat im November 2025 eine Übergangsregelung beschlossen, die eine flächendeckende Verfügbarkeit auf 2027 verschiebt. Die Verzögerung hat personelle, finanzielle und technische Gründe. Ungeklärte Sicherheitsfragen spielen ebenfalls eine Rolle. Die Verzögerung ist aus Sicherheitsperspektive ambivalent: Einerseits wird die Angriffsfläche noch nicht in vollem Umfang eröffnet. Andererseits fehlt der Druck, verbindliche Sicherheitsstandards zu schaffen, die bei einer flächendeckenden Einführung zwingend erforderlich wären.

9. Was sollte die BRAK tun?

Drei Maßnahmen wären vordringlich: Erstens die Veröffentlichung des beA-Quellcodes als Open Source, um eine breite, unabhängige Sicherheitsüberprüfung zu ermöglichen. Zweitens die Prüfung einer echten Ende-zu-Ende-Verschlüsselungsarchitektur, die Vertretungsregelungen kryptographisch sauber abbildet. Drittens die Einführung eines kontinuierlichen Sicherheitsaudits, das über anlassbezogene Prüfungen hinausgeht. Diese Maßnahmen erfordern Investitionen. Angesichts der Tatsache, dass das beA die zentrale Kommunikationsinfrastruktur der deutschen Anwaltschaft ist und mandatsbezogene Daten transportiert, sind diese Investitionen nicht optional.