beA - Besonderes elektronisches Anwaltspostfach

Zum Jahreswechsel 2017/2018 macht ein weiteres Mailsystem durch eher negative Schlagzeilen auf sich aufmerksam. Die Anwälte sollten miteinander und den Gerichten "sicher" kommunizieren und SMTP und SMIME wurden wohl als nicht sicher genug angesehen und DE-Mail aus mir nicht weiter bekannten Gründen ebenfalls ausgeschlossen. Stattdessen wurde mit Atos ein großer Dienstleister beauftragt ein neues eigenständiges System zu entwickeln, welches Anfang 2018 live gehen sollte. Die Anwälte wurden verpflichtet diesen Dienst zu nutzen. Nur gut, dass kritische Lücken erkannt und gemeldet wurden und letztlich zu einer vorläufigen Abschaltung geführt haben.

Was ist passiert?

Es war ja nur eine Frage der Zeit, bis sich interessierte Fachleute an die Analyse der Software und Infrastruktur gemacht haben. Hier waren bei Chaos Darmstadt einige neugierige Personen (Markus Drenger, Felix Rohrbach und Alexander Druffel), die den verfügbaren Client unter die Lupe genommen, die Spezifikationen gelesen und letztlich die Schwachstellen aufgeführt haben. Wenn man die Liste anschaut, dann hat das durchaus das Potential anderer Großprojekte, bei denen der normale Bürger nicht versteht, wie schief so etwas laufen kann und warum für so mangelhafte Ausführung auch noch Geld bezahlt wird. Gilt hier auch das "to big to fail"-Prinzip, wie es anscheinen bei BER, Dieselskandal, Stuttgart 21, Toll Collect und privaten Autobahnen sichtbar wird?

Die Kommunikation beim BeA läuft von einem Client zu einer zentralen Dienst. Allerdings scheint der Client nicht direkt mit einer TLS-Verschlüsselung sondern der vom Anwender genutzt Client ist ein Browser, der per HTTPS mit einem lokal durch BeA gestarteten WebServer verbindet. Dieser WebServer dient als "Middleware" zur Kommunikation mit dem Backend.

Nun wissen wir alle, dass Browser bei einer HTTPS-Verbindung Zertifikate überprüft und daher muss der lokale WebServer natürlich ein gültiges Zertifikat vorweisen, dem der Client vertraut. Dazu sind zwei Dinge erforderlich:

  • Privater Schlüssel
    Damit ein lokaler Server Daten mit einem lokalen Client verschlüsselt übertragen kann, braucht er einen privaten Schlüssel. Wenn beides auf dem gleichen System läuft, ist es für einen Angreifer natürlich einfach, sich den privaten Schlüssel zu besorgen. Schlüssel exportieren ist nicht schwer.
  • Vertrauenswürdige Stamm-CA
    Damit der Browser keine Warnung anzeigt, muss das Zertifikat natürlich von einer "Vertrauenswürdigen Root" abgeleitet werde. BeA hat dazu ein öffentliches Zertifikat einer bekannten PKI gekauft und in die Software des Servers integriert. Die PKI fand das natürlich nicht lustig und hat das Zertifikat zurecht wieder zurückgezogen. Vor allem wenn der dazu passende private Key auch noch auf jedem PC mit verteilt wurde

Hier wurde also schon vom Design her ziemlich viel kaputt gemacht. Dass die Designer etwas missverstanden haben, sieht man auch in dem Versuch das Problem zu lösen. Anscheinend wurde das Zertifikat nun durch ein von einer privaten PKI signiertes Zertifikat ersetzt. Damit das funktioniert, muss aber die ausstellende PKI natürlich auch im "Trusted Store" des Computers oder Browsers sein. Ansonsten zeigt der Browser eine entsprechende Warnung an.

Aber würden Sie bei der Vorgeschichte nun dieser PKI vertrauen, die natürlich auch Zertifikate für jede andere beliebige URL ausstellen kann?.

Ich hätte mir maximal vorstellen könnten, dass jede Installation ein "SelfSigned"-Zertifikat ausstellen und als Trusted addiert, so dass nur dieser PC auf nur diesem Service damit arbeiten könnte. Das macht z.B. Fiddler um die Verbindung zu analysieren. Aber genau genommen ist das System so schon zum scheitern verurteilt, da auch Certificate-Pinning mit einem Browser (per HSTS) nicht geht.

Wenn ich mir das Chaos anschaue, dann kann das aktuelle System so nie produktiv gehen, da es grundlegende Anforderungen nicht erfüllt und ohne eine radikale Änderung des Designs die versprochene Sicherheit nicht möglich ist. Es zeigt sich wieder mal: Selbst machen ist bei Kryptografie fast immer der falsche Weg. Mit SMIME/PGP oder De-Mail gibt es entsprechende Systeme mit richtiger Ende zu Ende Verschlüsselung.

Bewertung beA

Es ist aber nicht nur die Sicherheitslücke bei dem Zugriff hier

Ich kommentiere mal ein paar Punkte, die ich recherchiert habe:

  • Zentral statt Dezentral
    Das beA basiert anders als die klassische SMTP-Mails mit verteilten dezentralen Servern auf zentral bereit gestellten Diensten. Das kann für kleine Anwaltskanzleien ein Vorteil sein, da sie nur einen "leichten Client" benötigen. Eine zentrale Instanz ist natürlich auch ein leichteres Ziel.
  • Spam und DoS-Schutz
    Per Definition wird gefordert, dass der Client eine Mail an immer nur ein Gericht senden und keine Massenmail versendet. Zudem darf die Mail nicht größer als 30/60MB sein. Die Umsetzung wird durch den Client durchzuführen und größere Mails werden nicht sicher transportiert.
  • Polling statt Zustellung (egvp-Spec)
    Anscheinend muss der Clients immer wieder nachfragen und darf das nicht häufiger als alle 15 Minuten machen. Damit soll eine Überlastung des Servers verhindert werden.
  • Popup-Fenster im Browser müssen erlaubt werden
    Der Browser als Client muss Popup-Meldungen erlauben. Sicher kann man das auf die eine Domain beschränken aber für ein modernes GUI-Design spricht das nicht.
  • Ende zu Ende-Verschlüsselung
    Die versprochene Verschlüsselung ist aus meiner Sicht nicht garantiert, da eine Umschlüsselung der Inhalte durchgeführt wird. Auf dem Weg zwischen Sender und Empfänger gibt es eine Komponente, die eine Nachricht an ein Postfach entschlüsselt und dann pro "Leser" wieder neu verschlüsselt. Das entspricht der klassischen "Poststelle/Verteilerstelle" mit Postverteilung. Wenn meine Nachricht aber schon in der Poststelle verschlüsselt angekommen ist, dann ist sie ja schon "inhouse" und müsste nicht mehr erneut für jeden Leser verschlüsselt werden. Der Empfänger kann bei so einer Umsetzung nicht erkennen, ob die Mail auf dem Übertragungsweg zur Poststelle verschlüsselt war.
  • Zentrale Schlüssel
    Damit ein Anwender verschlüsselt senden kann, werden alle Server an einer zentralen Stelle bereit gestellt. Das ist soweit schon mal interessant. Erlaubt aber natürlich auch ein "Probing" welche Adressen gültig sind. Ich hoffe dass der zentrale Server hier "sicher" genug ist.
  • Veraltete Software
    Nicht nur, dass auf der Client-Seite nur alte Seiten als unterstützt gelistet werden. Auch auf dem Server sind alte Libraries in Verwendung, die schon vor der Auftragsvergabe als veraltet gegolten haben und bekannte Lücken enthalten.

Mit drängt sich der Verdacht auf, dass die Spezifikation vor 10 Jahren geschrieben und nicht laufend angepasst wurde. Denn heute sind viel größere Datenmengen unterwegs und Zustellzeiten von mehreren Minuten werden beim normalen Mailverkehr schon nicht mehr toleriert.

Chaos Darmstadt - elektronisches Anwaltspostfach - einfach. digital. kaputt.
https://www.youtube.com/watch?time_continue=1&v=I_tyTYAVYDo

Talk von Markus Drenger auf dem 34C3 zum beA
https://www.youtube.com/watch?v=Od5WAah-ktk

beA - Wie geht es weiter?
https://www.youtube.com/watch?v=IZkPvqBgQ4w
https://digital.anwaltverein.de/de/bea-elektronischer-rechtsverkehr/bea-wie-geht-es-weiter

Übrigens: Es gibt neben dem beA das Gleiche noch mal als „beN“ bei den Notaren.
https://dejure.org/gesetze/BNotO/78n.html

Gerichte als Empfänger?

Kennen Sie den Spruch "aus gut unterrichteten Kreisen"? Es hat nicht mal einen Tag gedauert und ich wurde gleich von mehreren Personen angesprochen, die sich sehr positiv über den Artikel geäußert haben. Zudem gab es auch Hinweise auf damit zusammenhängende weitere Probleme.

Es ist ja schön, dass Anwälte ihre Akten nun elektronische an die Gerichte senden können. Dazu ist es natürlich erforderlich, dass die Gerichte entsprechend diese Informationen auch annehmen und verarbeiten können. Anscheinend ist das aber noch gar nicht oder zumindest nicht flächendeckend möglich. Dazu müsste nämlich auch die "digitale Akte", also die Speicherung dieser Dokumente, entsprechend verfügbar sein. Ich nehme nicht an, dass ein Richter in der Verhandlung ein "Postfach" nach den passenden Akten durchsucht. Seit einer Veröffentlichung am 5. Juli 2017 im Bundesgesetzblatt (BGBl. 2017 I 2208) ist es zumindest verbindlich, dass diese Akte bis Anfang 2026 verpflichtend ist.

In den verbleibenden 8 Jahren dürften all die nun beschafften Drucker sicher abgeschrieben sein, mit der die per beA übersandten Dokumente erst mal gedruckt und wieder als "Papierakte" abgeheftet werden. Das Volumen wird sicher nicht gering sein.

Zukunft und Einschätzung

Es gibt in einer Marktwirtschaft die Wahlfreiheit, wenn man eine Lösung für eine eigene Problemstellung sucht. Die Wahlfreiheit wird allerdings durch geltende Gesetze beschränkt. Sie können jedes Auto kaufen und fahren, solange Sie sich ein "zugelassenes" Fahrzeug beschaffen und sich an die Straßenverkehrsordnung halten. Sie können sogar selbst in den Markt der Automobilhersteller einsteigen, wenn Sie mit den vorhandenen Lösungen nicht zufrieden sind. Das hat schon die Deutsche Post/DHP  mit ihrem Streetscooter (https://www.streetscooter.eu/) gezeigt.

Etwas anders ist es aber bei so kritischen Komponenten wie der Verschlüsselung. Hier etwas "Neues" zu schaffen ist an Komplexität nicht zu unterschätzen. Schon andere Firmen haben sich die Finger an "selbst entwickelten" Kryptoalgorithmen verbrannt. Dass natürlich auch beim Systemdesign etwas grundlegend falsch laufen kann, zeigt das BeA in der oben skizzierten Umsetzung. Ich bin gespannt zu sehen, wie das Problem grundsätzlich gelöst werden kann.

Ich bin vor allem neugierig, wie sich hier die finanzielle und rechtliche Situation darstellt, denn auch wenn ich kein "Sachverständiger" vor einen Gericht bin, würde ich als Bürger schon mal hinterfragen ...

  • ...wie das Bundesverfassungsgericht seine Entscheidung überdenkt
    "Erfolglose Verfassungsbeschwerde gegen die Einführung des elektronischen Anwaltspostfachs"
    https://www.bundesverfassungsgericht.de/SharedDocs/Pressemitteilungen/DE/2017/bvg17-114.html
    Wer definiert eigentlich "Ende zu Ende"-Verschlüsselung ?
  • ... welchen Wert ein Security Audit hat?
    Der "Auftrag" an Sec Consult ist natürlich genau so Geschäftsgeheimnis, so dass man nicht weiß, was beauftragt, geprüft und letztlich testiert wurde. Aber ein Designfehler kann man schon anhand des obigen Bildes beschreiben.
  • ... wie der Dienstleister Atos seine Rolle sieht
    Als Dienstleister habe ich doch ein Eigeninteresse meinen Kunden auch zu beraten. Jeder ist zu Kompromissen bereit aber bei Sicherheit gibt es Grenzen, die nicht überschritten werden dürfen. Und für 38 Mio€ kann man schon viel schaffen.

Ich bin ja immer noch der Meinung, dass man die Umgebung viel einfacher, skalierbarer und stabiler aus Basis von SMIME o.ä. hätte erreichen könnte.

  • Man betreibt einfach eine eigene Mailserverplattform
    Da kann man einfach abschauen, wie 1und1, GMX, u.a. das machen
  • Man ergänzt die Plattform um einen Key-Service
    Die Plattform stellt SMIME-Schlüssel aus und stellt diese z.B.: per LDAP bereit
  • IMAP4/SMTP Clients mit SMIME-Support und LDAP-Adressbuch
    Der Anwender kann dann einen beliebigen Mailclient nutzen, der sich aber z.B.: mit dem Zertifikat per IMAP o.ä. anmeldet und seine Mails signiert. Mit den bewährten Protokollen könnten auch die Entwickler von Branchenlösungen sich einfach integrieren.

Natürlich könnte man auch einfach z.B.: die staatlich geförderte DE-Mail-Plattform nutzen und selbst ein einfaches SMIME-System basierend auf den ehr schon (dezentralen) vorhandenen Postfächern der Teilnehmer wäre aus meiner Sicht allemal besser.

Nun geht es aber erst mal um Scherben zusammenkehren und schauen, wie man die Kuh aus dem See, in dem Sie eingebrochen ist, wieder heraus holt. Vielleicht ist die Kuh aber auch schon gestorben und es wird Zeit für einen Neuanfang. Dann wäre nur noch zu klären, wie die aktuell aufgelaufenen Kosten übernommen werden.

Bis dahin sollten die Anwälte wohl weiter beim Postbrief und dem schon lange eingeführten Fax bleiben. Wobei auch gerade Fax durchaus interessante Optionen zur Weiterentwicklung bietet. So können Faxgeräte per Fax over IP durchaus auch TLS verschlüsseln oder sogar PDF-Dokumente etc dantiv übertragen. Ferrari Electronic hat dazu ein passendes Statement beschrieben:

Und natürlich funktionieren auch alle SMIME/PGP-Lösungen wie z.B.: NoSpamProxy ebenfalls mit der gewohnten und versprochenen Sicherheit.

Weitere Links