Das Logbuch Spezial zum besonderen elektronischen Anwaltspostfach Das besondere elektronische Anwaltspostfach soll eigentlich eine elegante Lösung sein, die sichereren E-Mail-Verkehr zwischen deutschen Anwälten und deutschen Gerichten realisieren kann. Nach einer…
Das Logbuch Spezial zum besond…
Hier folgen meine Gedanken zu den Problemen bei der Umsetzung des „elektronischen Anwaltpostfachs“, wie sie im „Logbuch Netzpolikt 242“ (Podcast) dargestellt werden. Ich habe sie dort auch als Kommentar veröffentlicht.
Hier nur noch kurz der Kontext: was ist das „beA“: „Das besondere elektronische Anwaltspostfach (beA) ermöglicht Rechtsanwälten die sichere elektronische Kommunikation mit der Justiz und untereinander. Jeder in Deutschland zugelassene Rechtsanwalt verfügt über ein solches elektronisches Postfach.“ Markus Drenger (CCC) hat mehrere Sicherheitslücken in der Implementierung gefunden (Talk).
Hier nun mein Kommentar.
In meiner Wahrnehmung werden mittlerweile überwiegend Webanwendungen entwickelt. Ich weiß nicht, wie es konkret bei Atos aussieht, aber das Wissen um das Bauen von nativen Anwendungen scheint mir mittlerweile nicht mehr so weit gestreut zu sein wie bei Webanwendungen. Letztere haben ja auch unbestrittene Vorteile: eine zentrale Installation auf einer bekannten Umgebung statt vieler dezentraler Installationen auf unbekannten Umgebungen. Ein Patch ist da eingespielt oder nicht eingespielt
, bei nativen Anwendungen gibt es immer was dazwischen.
Beim beA ist jedoch eine lokale Installation notwendig, um auf die Smartcard zugreifen zu können. Also wird ein Server installiert, um mit der Smartcard zu kommunizieren, und auf eher abenteuerliche Weise mit einem Zertifikat ausgestattet. Wie machen denn das andere Lösungen? Die z.B. mit dem ePerso kommunizieren? Nun hat man sich dann doch eine lokale Installation ins Boot geholt und muss gleichzeitig Kopfstände machen, um damit zu kommunzieren. Ein lokaler Server … da merkt doch der Nutzer viel weniger, wenn da was schief läuft, der z.B. nicht startet. Ich stimme zu, dass hier eine lokale Anwendung passender wäre. Die Unterstützung von mindestens Windows und MacOS, mglw. auch Linux, in diversen Versionen ist jedoch sicherlich nicht einfach.
Die Sache mit den Terminalservern scheint mir ja die Vorteile der Smartcards zu nichte zu machen. Wie oft werden die eingesetzt? War das der BRAK vor Beginn des Projektes bekannt?
Die „Vertretungsregel“ begründet die Einführung des HSM, das die „Umschlüsselung“ durchführt. Damit ist die Ende-zu-Ende-Verschlüsselung kaputt. Fachlich finde ich die Anforderung nachvollziehbar. Muss denn wirklich der Rechtsanwalt persönlich adressiert werden, oder reicht es, seine Kanzlei zu adressieren? Bei den Gerichten wird man doch wohl auch nicht einzelne Personen adressieren, oder? Wenn man eine ganze Kanzlei oder Teile davon adressieren kann und die betreffenden Mitarbeiter Zugriff auf das Postfach haben, bräuchte niemand umschlüsseln. Dito bei den Absendern.
Dann könnte man auch fast schon De-Mail einsetzen. Aber halt, die Kommunikation erfolgt über OSCI. Das ist aber nur ein Transport-Protokoll. Ist die Payload weiter strukturiert? Wird z.B. ein Aktenzeichen angegeben, damit die Nachricht im Gericht gleich einer elektronischen Akte zugeordnet werden kann? Das geht dann auch in die Richtung „wir bräuchten einfach mal eine Open-Source-Komponente, die E2E-Verschlüsselung zwischen Alice und Bob ermöglicht“ – was wird genau ausgetauscht?
Das habe ich auch nicht verstanden: man kann sich als einfacher Bürger anmelden, wie kann man dann kommunizieren? Braucht man dann auch beA?
Zu guter Letzt: PDF. Ja, PDF ist nicht sicher. Ich vermisse jedoch einen Gegenvorschlag. Nur Text und JPG/PNG? Unrealistisch. Statt PDF ginge PDF/A, aber wer erklärt allen RechtsanwältInnen, dass statt PDF PDF/A zu erzeugen ist und wie man das im Programm der Wahl macht? Habe ich übrigens auch schon gehen: eingehende PDFs mittels Ghostscript in PDF/A wandeln wg. IT-Sicherheit.
Über das beA ließe sich also mindestens nochmal 2 Stunden diskutieren.