| Atos stellt Lösung für die Anbindung der Client-Security vor – dringende Sicherheitswarnung vor dem bisherigen Client – auch EGVP weist gravierende Schwachstellen auf | Abs. 1 |
| Maximilian Herberger sprach dem „Gesetz zur Förderung des elektronischen Rechtsverkehrs mit den Gerichten" 2013 „historische Bedeutung"[1] zu. Dies könnte sich nun – anders als erwartet – bewahrheiten. Die BRAK und die Anwaltschaft durchlaufen mit dem besonderen elektronischen Anwaltspostfach beA gerade einen dramatischen Lernprozess. Dieser Lernprozess tut weh – aber er könnte wegweisend für die Digitalisierung in Deutschland sein. | Abs. 2 |
| 1) Wo steht die BRAK mit dem beA jetzt? | Abs. 3 |
| a) Das beAgate | Abs. 4 |
| Was ist passiert? Es begann mit einem Zertifikat, welches falsch eingesetzt wurde. Es ging weiter mit einer Installationsanleitung, die https bei allen Anwälten unsicher machte, die ihr folgten, und nun stellt sich heraus, dass bereits die Installation der mit veralteten Bibliotheken bestückten Client-Security die Anwaltsrechner massiv verwundbar gemacht hat. Es hätte gereicht, eine infizierte Ad für die Zielgruppe der Anwälte auf einen Adserver zu legen und tausende Anwaltsrechner wären fernsteuerbar gewesen. Auch das EGVP ist unzureichend vor Angriffen geschützt. | Abs. 5 |
| b) Der beAthon | Abs. 6 |
| Ein Sprichwort sagt, aus Schaden wird man klug – und das ist tatsächlich die Chance, die in diesem Desaster liegt. Schaut man sich die jüngste Reaktion der BRAK an, so demonstrierte sie auf dem beAthon am Freitag, dass sie zuhören kann, dass sie nicht mehr ihren zertifizierten Dienstleistern blind vertraut, dass sie – sicher noch zu vorsichtig – Offenheit wagt und dass sie schneller reagiert. Wenn nicht nur die BRAK lernt, dass Zertifizierungen keine Kompetenz ersetzen, dass Geheimhaltung keine Sicherheit erzeugt und dass beschönigende Kommunikation die Sache nur noch schlimmer macht, dann war der Schaden schon für einige Klugheit gut. | Abs. 7 |
| Im Vorfeld wurde der „beAthon" sehr kritisch aufgenommen. Die BRAK lud eine Reihe von handverlesenen Experten ein. Die Wortschöpfung „beAthon" erinnert an einen „Hackathon" womit der beAthon aber nichts gemein hat. Die fehlende Öffentlichkeit leistete Spekulationen Vorschub. Wer deshalb den Verdacht hegte, dass die BRAK keine Kritiker einladen würde, wurde jedoch positiv enttäuscht. Die Moderation wurde von Stephan Ory, Vorstandsvorsitzender des EDV-Gerichtstags souverän durchgeführt. Der CCC-Darmstadt – der sicher nicht als Konformistenverein gelten kann – wurde gleich mit 3 Leuten eingeladen. Die Firma Secunet, die das neue Gutachten machen soll, war ebenfalls mit 3 Leuten zugegen. Kritische Anwälte, Anwaltverein, Mitglieder des EDV-Gerichtstags und Fachpresse und nicht zuletzt ein Vertreter des BMJV rundeten das Bild ab. | Abs. 8 |
| Sicherheitsproblem um Sicherheitsproblem wurden diskutiert. Nicht immer war man einer Meinung über das bestehende Risiko. Aber stets war der Dialog sachlich und offen und – es darf auch inhaltlich berichtet werden. So einen Dialog hätte man sich vor 2 Jahren vor dem Erststart des beA gewünscht. Damals schien dies zumindest in dieser Offenheit und Aufgeschlossenheit undenkbar. Das zeigt, dass sich einiges getan hat und die BRAK auf einem guten Weg ist. Das beA allerdings muss die Talsohle noch durchqueren. Wie konnte es soweit kommen? | Abs. 9 |
| 2) Prinzipielle Probleme | Abs. 10 |
| Wenn Anwälten eine Pflicht auferlegt wird, so ist Gegenwehr vorprogrammiert. Schnell wird die Berufsfreiheit beeinträchtigt gesehen. Es werden Exportverbote für Javakomponenten nach Kuba bemüht, um sich der Pflicht zur elektronischen Post zu entziehen[2] – als ob Briefpost dort zuverlässig und fristgerecht zugestellt würde. Dann wird auch gleich geklagt – vor dem Anwaltsgerichtshof[3], Bundesgerichtshof[4] und zuletzt vor dem Bundesverfassungsgericht[5]. Kritik am beA wurde als Angriff begriffen. Die Klagen führten zur Nachbesserung der gesetzlichen Grundlagen aber zu einer Wagenburgmentalität beim technischen Konzept. | Abs. 11 |
| Was läuft verkehrt beim elektronischen Rechtsverkehr in Deutschland? Reiht sich das beA ein in eine Folge von Projektpleiten von Tollcollect bis elektronischer Gesundheitskarte? Gibt es in Deutschland so ein schlechtes „Digitalisierungskarma", dass die BRAK damit nur scheitern konnte? Dabei existiert in Deutschland doch eine starke Softwarebranche. Das geht von den etablierten Softwareriesen wie SAP und Software AG bis zur florierenden Blockchain-Gründerszene in Berlin. Am fehlenden Software Know How in Deutschland scheint es also nicht zu liegen. | Abs. 12 |
| a) Wasserfallmodell statt agiler Entwicklung | Abs. 13 |
| Softwareprojekte scheitern insgesamt relativ häufig. Dies gilt besonders bei großen Projekten und bei Projekten, die nach dem Wasserfallmodell durchgeführt werden. Der Chaos-Report 2015 zählt in dieser Kategorie 42% der Projekte als gescheitert – bei agil durchgeführten Projekten waren dies immerhin nur noch 23%[6]. Das Wasserfallmodell ist das klassische Projektmanagementmodell, bei dem linear ein Schritt nach dem nächsten durchgeführt wird[7]. Von der Definition der Anforderungen über den Entwurf bis zur Implementation wird jeder Schritt nacheinander und isoliert durchgeführt. Dies funktioniert vielleicht, wenn alle Beteiligten ein ähnliches Projekt bereits mehrfach durchgeführt haben und daher in der Definitionsphase gut Dinge antizipieren können, die später auftreten könnten. Betritt man dagegen beim Projekt Neuland, führt diese Vorgehensweise dazu, dass man zu Projektbeginn Dinge festlegt, über die man noch zu wenig weiß, die eigentlich noch gar nicht festgelegt werden müssten und die sich später als problematisch erweisen. Das Wasserfallmodell blockiert dann häufig das Anpassen dieser verfrühten Festlegungen. Das Wasserfallmodell ist lernresistent und funktioniert daher nur dort, wo die Beteiligten bereits von Anfang an genug wissen, um nicht während des Projektes mitlernen zu müssen. | Abs. 14 |
| Schaut man sich das beA näher an, so könnte man sogar ein erweitertes Wasserfallmodell erkennen. Es beginnt nämlich nicht bei der BRAK, sondern beim Gesetzgeber. Dieser gibt vor und beauftragt die BRAK. Zwar sind die Details der Auftragsvergabe an Atos und Governikus nicht bekannt. Das Prinzip „stille Post", bei der der Subauftragnehmer Governikus mit der BRAK nicht reden darf, wenn Atos das nicht will, verschärft jedoch diese Situation. Ganz abseits von Bugs und problematischen Zertifikaten führte bereits diese Konstellation zu einer erhöhten Wahrscheinlichkeit, dass dieses Projekt scheitert. | Abs. 15 |
| b) Das Konzept | Abs. 16 |
| Beim Vergleich mit anderen Ländern fällt auf, dass mit dem beA nur das Hin- und Herschicken von Nachrichten zwischen Anwälten und Gerichten digitalisiert wird. Ganz so, als ob es nur darum ginge, ein wenig Porto zu sparen. Dabei werden weitergehende Konzepte durchaus auch in Deutschland diskutiert. Ein gerichtlicher elektronischer Datenraum[8] könnte Anwälten nicht nur Einblick in die Prozessakten geben, sondern direkt ermöglichen, Prozesshandlungen zu tätigen und Schriftsätze einzureichen. Ein daran angekoppelter anwaltlicher elektronischer Datenraum würde die relevanten Teile der Prozessakte für den Anwalt synchronisieren. | Abs. 17 |
| Die Fokussierung auf das beA ist jedoch vergleichbar damit, dass für das e-Banking ein spezielles e-Banking Postfach eingerichtet würde, über welches Bankbriefe ausgetauscht würden. Diese Bankbriefe wären dann PDFs, die etwa Überweisungsaufträge, Kontoauszüge oder geänderte AGB zum Inhalt haben würden. Diese PDFs würden in der Folge auf Bankseite manuell zur Kenntnis genommen und in manchen, noch nicht ausreichend digitalisierten Filialen zudem zur Weiterverarbeitung ausgedruckt. Gleichzeitig lässt man diese Post über eine spezielle Clearingstelle laufen. Diese sorgt dafür, dass Bankkunden im Falle ihrer Abwesenheit Vertreter bevollmächtigen können. Um Banktransaktionen besonders sicher zu machen, müssen alle Bankkunden zudem eine spezielle Signaturkarte erwerben, einen entsprechenden Kartenleser kaufen und die dazugehörige Software installieren. | Abs. 18 |
| Anhand dieses Vergleichs wird schnell deutlich, dass beim beA das Potential der Digitalisierung überhaupt nicht ausgeschöpft wurde. Gleichzeitig wurde aber durch eine komplexe Architektur ein sehr hoher Aufwand getrieben. | Abs. 19 |
| 3) Ende-zu-Ende-Verschlüsselung oder Abhörschnittstelle? | Abs. 20 |
| Ralph Hecksteden hatte schon früh darauf hingewiesen, dass die BRAK den Begriff „Ende-zu-Ende-Verschlüsselung" (E2EE) anders als üblich verwendet[9]. E2EE bedeutet, dass die Nachricht auf dem Rechner des Senders verschlüsselt und nur auf dem Rechner des Empfängers entschlüsselt werden kann. Ein Rechner auf dem Weg zwischen Sender und Empfänger, darf selbst dann die Nachricht nicht entschlüsseln können, wenn er mit Schadsoftware infiziert oder mit Überwachungssoftware versehen ist. E2EE fehlt also bereits dann, wenn ein fehlerhafter beA Server mit einem fehlerhaften Hardware Security Module (HSM) gebaut werden könnte, der die Entschlüsselung ermöglicht. Beim beA ist eine Entschlüsselung der Nachrichten durch einen böswilligen „man-in-the-middle" denkbar. Lediglich die korrekte Implementierung des beA-Servers und des HSM sowie deren sicherer Betrieb garantieren die Vertraulichkeit der übermittelten Nachrichten. Die Anwälte müssen der BRAK und Atos vertrauen. Bei einer echten E2EE wäre ein solches Vertrauen nicht erforderlich. Die Nachrichtenschlüssel wären nur auf den Rechnern der Kommunikationspartner vorhanden[10] und eine Entschlüsselung unabhängig von der Programmierung des Servers technisch unmöglich. Die BRAK betonte, dass niemand anders als der Postfachinhaber und die von ihm festgelegten Vertreter die Nachrichten entschlüsseln können.[11] Inzwischen hat sich dies jedoch als unwahr herausgestellt. Es gibt einen Generalschlüssel, der benötigt wird, um die Schlüssel von einem bestehenden HSM auf ein neues HSM zu übertragen. Dieser Generalschlüssel ist auf mehrere „Key-Custodians" verteilt, die nur gemeinsam den Generalschlüssel zusammensetzen können. Dabei gibt es auch Vertretungsregelungen, damit die Schlüsselrekonstruktion auch bei einzelnen nicht (mehr) erreichbaren Personen möglich bleibt. Wer diese Key-Custodians genau sind, blieb offen. Nur eins wurde klar: Es sind keine Mitarbeiter von Atos aber Mitarbeiter der BRAK darunter. Diese Vorgehensweise ist bei HSM durchaus state of the art. Das bedeutet, es gibt eine theoretische, mit hohen Hürden versehene Möglichkeit der Entschlüsselung der Nachrichten durch die BRAK. Ob es darüber hinaus weitere Zugriffsmöglichkeiten gibt, bleibt offen. Die Spezifikation ist nicht öffentlich und der Source Code erst recht nicht. Selbst ein Gutachten, welches die Sicherheit untersucht hat, wird von der BRAK als „streng vertraulich" bezeichnet.[12] Doch selbst wenn ein entsprechendes öffentliches Gutachten heute die Überwachungsfreiheit bescheinigen würde, bleibt das Risiko, dass eine entsprechende Überwachungsmöglichkeit später eingebaut wird. | Abs. 21 |
| Ob das ein Designfehler oder eine politische Vorgabe war, um nach/analog §§ 110ff. TKG eine Abhörmöglichkeit einzurichten, sollte geklärt werden. Haben denn Anwälte einen grundrechtlichen Anspruch vollständig überwachungsfrei zu kommunizieren? EGMR[13] und BVerfG[14] sehen das Abhören von Anwälten unter hohen Hürden als berechtigt an, wenn die Anwälte selbst im Verdacht des Begehens einer Straftat stehen. Für eine Überwachung braucht es aber eine klare gesetzliche Grundlage. Diese könnte im TKG vorliegen, sofern das beA Teil eines öffentlich zugänglichen Telekommunikationsdienstes (§ 3 Nr. 17a TKG) ist. Zwar steht das beA nur Anwälten und ihren Kanzleimitarbeitern offen. Doch könnte die öffentliche Zugänglichkeit dadurch entstehen, dass zwischen dem öffentlich zugänglichen EGVP und dem beA Nachrichten ausgetauscht werden können. Bei Telekommunikationsdiensten, die ein Arbeitgeber für seine Mitarbeiter erbringt, aber die Kommunikation mit öffentlichen Anschlüssen ermöglicht, wird dies kontrovers diskutiert[15] - aber überwiegend abgelehnt[16]. Zur Vertrauensbildung wäre es daher hilfreich, wenn BRAK und BMJV eine Stellungnahme abgeben, ob sie hier das TKG für anwendbar halten. Noch besser wäre es, wenn dies gesetzlich eindeutig festlegt würde. Aus dem Gesetzesvorbehalt der Einschränkung des Fernmeldegeheimnisses könnte man ein Gebot der Transparenz herleiten. Der Gesetzgeber hat eindeutig zu erklären, wo er eine Einschränkung für geboten hält, damit darüber öffentlich debattiert werden kann. | Abs. 22 |
| In dem Kontext ist vielleicht auch interessant, dass für das neue Gutachten mit Secunet eine Firma beauftragt wurde, die Erfahrung darin hat, Kommunikationssysteme zu begutachten, die gesetzlich vorgeschriebene Abhöreinrichtungen beinhalten. | Abs. 23 |
| Wir sollten uns auch den Kontext des beA ansehen. Der amtierende Bundesinnenminister de Maizière stellte die verfassungsrechtlich zumindest bedenkliche Forderung auf, dass alle elektronischen Geräte künftig mit Backdoors für staatliche Stellen ausgerüstet werden müssen[17]. Ist es da vorstellbar, dass eine halböffentliche Stelle wie die Bundesrechtsanwaltskammer vom Überwachungswahn verschont bleibt? | Abs. 24 |
| 4) Die Probleme in der Software | Abs. 25 |
| Bevor mit der Rettung des beA begonnen werden kann, muss zunächst geklärt werden, ob es noch zu retten ist. Aus dem Flughafen BER haben wir gelernt, dass es keinen Sinn macht nachzubessern, wenn die Nachbesserung länger dauert und teurer als ein Neubau wird. Die festgestellten Mängel in der Client-Software lassen auf eine schlampige Implementierung schließen. Die Vorgehensweise bei der kritischen Austauschanleitung des Zertifikats und die höchstwahrscheinlich falsche Auskunft zur aktuellen Gefährdung haben das Vertrauen in Atos als Firma und den von ihr verantworteten Programmcode auf ein Minimum reduziert. Die BRAK hat dies verstanden und den unabhängigen Dienstleister Secunet beauftragt vor einer erneuten Inbetriebnahme alle Komponenten einem unabhängigen Review zu unterziehen. Dann erst kann beurteilt werden, ob und was am Server ggf. auch repariert werden muss. | Abs. 26 |
| Atos hat ein Update für den Client bereitgestellt. Öffentliche Tests sind dazu noch nicht bekannt. Das Konzept zur Anbindung der Client-Security sieht valide aus. Es ist eine sicherheitstechnisch akzeptable Lösung für die unschöne Architektur der Anbindung der Client-Security. Weitere Sicherheitsprobleme seien behoben worden. Ob der Client damit sicher ist, wird eine Begutachtung ergeben – niemand mag da Atos noch blind vertrauen. | Abs. 27 |
| Für ein Problem wird explizit eine Lösung erst später in Aussicht gestellt: Jede Website kann prüfen, ob ein beA-Zugriff von dem verwendeten Rechner möglich ist und damit feststellen, dass es sich um einen Anwaltsrechner handelt. Fremde Websites können auch Login-Fenster öffnen oder die beA-Client Security beenden. Das kann nicht nur lästig sein, sondern auch die Bedienung des beA blockieren oder die Nutzer in Angriffssituationen zu unüberlegten Reaktionen verleiten. Atos hat hier eine Lösung angekündigt. Die Experten am beAthon begrüßten dies, äußerten sich jedoch uneinheitlich, ob dies bei der gewählten Architektur gelingen wird. | Abs. 28 |
| Auch beim EGVP wurden einige Schwachpunkte identifiziert. Diese können zu einer Blockade des Systems (Denial of Service) oder zum Verteilen von Malware führen. Auch das dem EGVP zugrundeliegende Protokoll ist angreifbar. Dies wurde bereits vor einigen Monaten demonstriert. Auf die entsprechende Fehlermeldung, wurde mit rechtlichen Schritten gedroht. Dies veranschaulicht, dass nicht nur die BRAK mit dem Sicherheitsmanagement überfordert ist.[18] | Abs. 29 |
| 5) Vertrauen | Abs. 30 |
| Das Vertrauen in das beA, in die BRAK und in die Dienstleister Atos und Governikus ist beeinträchtigt. Atos hat der BRAK eine Anleitung[19] geliefert, auf der auf 22 Seiten im Detail dazu angeleitet wird, die Sicherheit der https-Verschlüsselung auf dem eigenen Rechner zu beeinträchtigen. Es wird dazu kolportiert, dass Atos beteuert habe, dass dies nicht sicherheitsrelevant wäre. Auch die aktuelle Sicherheitswarnung zur Deaktivierung der Client-Security kam nicht von Atos, obwohl ihr die Problematik gemeldet wurde. In der Folge kann und darf sich die BRAK nicht mehr auf Atos verlassen und muss jede neue Softwareversion auf sicherheitskritische Mängel extern intensiv überprüfen lassen. Das wirft die Frage auf, ob der BRAK unter diesen Bedingungen noch die Zusammenarbeit mit Atos zugemutet werden kann und ob nicht eine fristlose Kündigung gerechtfertigt ist. | Abs. 31 |
| Die BRAK selbst versucht Vertrauen wiederaufbauen. Die bereits angekündigte[20] und hoffentlich umfassende Begutachtung durch externe Gutachter mit vollständiger Veröffentlichung des Ergebnisses ist ein wichtiger Schritt. Dazu sollte eine öffentliche Bug-Liste, der erkannten, aber noch nicht behobenen Bugs kommen. Ebenfalls bei Softwareprojekten üblich sind eine Roadmap, in der angegeben wird, welche Features und Bugfixes für wann vorgesehen sind. Das Maximalziel wird in einem öffentlichen Aufruf gefordert, der von der Free Software Foundation Europe (FSFE) initiiert ist: Der Quellcode soll Open Source gestellt werden.[21] Diesem Vorschlag schlossen sich viele Teilnehmer des beAthons an. Nachdem Atos verlautbart hat, dass die BRAK das Recht zur Veröffentlichung des Quellcodes hat[22], gibt es für die BRAK hier keinen Grund mehr zu zögern. | Abs. 32 |
| 6) Support | Abs. 33 |
| Fristsachen werden häufig erst kurz vor Mitternacht eingereicht. Daher wird auch Support nicht nur bis 20 Uhr, sondern bis Mitternacht benötigt. Der Support sollte sich hier an der Anwendergruppe ausrichten – nicht umgekehrt. Mindestens genauso wichtig wie der Support der direkten Anwender ist der Support der Schnittstelle. Diesen Support zu organisieren ist eine Pflicht, die sich direkt aus der professionellen Bereitstellung dieser Softwareschnittstelle ergibt. | Abs. 34 |
| 7) Partizipation | Abs. 35 |
| Die Anwender sollten weitestmöglich eingebunden werden. Das beginnt bei beta-Tests, bei denen interessierte Nutzer neue Versionen testen können und dabei besonders unterstützt werden. Dabei werden nicht nur Fehler gefunden, die dann vor dem Echtbetrieb behoben werden können. Auch gewinnt man dadurch direktes Nutzerfeedback zur Usability und kann damit die Nutzerfreundlichkeit verbessern. | Abs. 36 |
| Die BRAK sollte Usergroups einrichten, bei denen sie zusammen mit den Entwicklungspartnern den Nutzern Rede und Antwort steht. Dort sollten die Entwicklungsroadmap und die weiteren Entwicklungsschritte diskutiert werden. Eine spezielle Usergroup sollte für die Anbieter von Anwaltssoftware eingerichtet werden. Diese sind wichtige Multiplikatoren. Hätte die BRAK die Schnittstelle früher bereitgestellt und Unterstützung angeboten, dann gäbe es heute nicht nur die Einbindung in Anwaltssoftware sondern auch in zahlreiche E-Mail-Programme. Der beA-Client wäre dann nur einer von vielen und die Auswirkung von Mängeln im Client wären längst nicht so gravierend. Stattdessen sahen sich Softwareanbieter gezwungen, Reengineering der Schnittstelle zu betreiben, um sie in ihre Software einzubinden. | Abs. 37 |
| 8) Kommunikation | Abs. 38 |
| Ziel der Kommunikation über das BRAK sollte eine umfassende Information der Anwender sowie der Schnittstellenverwender sein. Vertrauen wird mit Offenheit gewonnen – nicht mit der Beschönigung von Problemen. Bei einem IT-System mit so vielen Nutzern bleibt nichts dauerhaft verborgen. Daher zahlt sich ein proaktives Eingehen auf Probleme aus. Neue Worte wie das „beAthon" zu schöpfen, welches dann entgegen der Nähe zum Wort „Hackathon" etwas anderes bedeutet, fördert dann eher die Häme als das Vertrauen. Auch sollte sich die BRAK der öffentlichen Diskussion auf Veranstaltungen stellen, statt bei der eigenen Veranstaltung auf Anonymität[23] zu bestehen. | Abs. 39 |
| 9) Management | Abs. 40 |
| In einem IT-Projekt gibt es viele Managementaufgaben. Das beginnt beim Projektmanagement, dem Anforderungs- und Produktmanagement über das Vertragsmanagement und das Qualitätsmanagement mit dem Change- und insbesondere dem Emergency Change-Management. Von außen lässt sich nur beurteilen, dass einige Managementaufgaben unzureichend erfüllt wurden. Ob diese überhaupt und wenn dann auf welche Personen übertragen aber nicht ausgefüllt wurden, muss intern geklärt werden. | Abs. 41 |
| 10) Wie schlimm ist es wirklich? | Abs. 42 |
| Wer heute mit Fax kommuniziert, welches abhörbar ist und keine sichere Identifizierung des Absenders ermöglicht, wird selbst mit einem schlechten beA nicht unsicherer kommunizieren. Damit sollten wir uns jedoch beim elektronischen Rechtsverkehr nicht zufriedengeben. Deshalb veranstaltet der EDV-Gerichtstag am 5. März eine Tagung für ein besseres beA – genannt „beA+".[24] | Abs. 43 |
| 11) Wie soll es weitergehen? | Abs. 44 |
| Wir brauchen eine Bestandanalyse, ob und wie weitergemacht werden kann. Dies betrifft die Software aber auch die Strukturen. Was muss sich bei der BRAK alles ändern, dass sie in der Lage ist, ein sicherheitskritisches Softwareprojekt gut zu managen? | Abs. 45 |
| Lässt sich in beiden Fragen eine tragfähige Basis erreichen, muss sich mit Atos auseinandergesetzt werden. Eine weitere Eskalation ist für das Projekt wenig hilfreich. Die BRAK hat die Zahlungen bereits eingestellt. Atos beschönigt massive Sicherheitsprobleme, verweigert die Zusammenarbeit mit externen Experten auf dem beAthon und kommuniziert per Pressemitteilung. Ein langwieriger Rechtstreit scheint vorprogrammiert und könnte die Lösung der Probleme zusätzlich beeinträchtigen. Mediation könnte hier eine zügige Lösung bringen, die Transition bis zu einer Neuvergabe regeln und das Projekt auch auf dieser Ebene retten. | Abs. 46 |
| Der Schritt der BRAK zu mehr Offenheit ist ausdrücklich zu begrüßen. Anwender werden zügig gewarnt, selbst wenn der eigene Dienstleister die Probleme herunterspielt. Die Sicherheit der Anwender geht nun ganz klar vor einem etwaigen Reputationsverlust – das ist gut so. Weitere Schritte können und müssen folgen. Die größten Herausforderungen wird die BRAK jedoch nur mit externem Rückenwind meistern können. Dies betrifft die Ende-zu-Ende-Verschlüsselung, das Kanzleipostfach, den Ausbau zu einem integrierten Gerichtssystem sowie den Aufbau eines professionellen Managements eines sicherheitskritischen IT-Services. | Abs. 47 |
|
|
|
| |
| |
| Fußnoten | |
| * Autor ist Jörn Erbguth, Jurist und Informatiker, Berater zu Blockchain, Smart Contracts sowie Legal Tech in Genf. Er ist Datenschutzbeauftrager (udis zert.) und Mitglied im Vorstand des EDV-Gerichtstags. |
| [1] Maximilian Herberger, Zehn Anmerkungen zum „Gesetz zur Förderung des elektronischen Rechtsverkehrs mit den Gerichten", JurPC Web-Dok. 81/2013 - DOI 10.7328/jurpcb2013285213 |
| [2] Michael Schinagl, Nutzung des beA setzt Installation von Software am Client-Rechner voraus, Blogeintrag vom 17.2.2016, http://fach-anwalt.de/aktuelles/aktuelles-bea/ |
| [3] AnwGH Berlin, Beschluss vom 6.6.2016 – II AGH 16/15, JurPC Web-Dok. 99/2016 - DOI 10.7328/jurpcb2016316100 |
| [4] BGH, Urteil vom 11.01.2016 – AnwZ (Brfg) 33/15, JurPC Web-Dok. 34/2016 - DOI 10.7328/jurpcb201631334 |
| [5] BVerfG, Beschluss vom 20. Dezember 2017 – 1 BvR 2233/17 |
| [6] Shane Hastie, Stéphane Wojewoda, Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch, InfoQueue 4.10.2015, https://www.infoq.com/articles/standish-chaos-2015 |
| [7] Wikipedia Wasserfallmodell, https://de.wikipedia.org/wiki/Wasserfallmodell |
| [8] Matthias Wellter, Ralf Köbler, Verfahrensgrundsätze und Modellregeln für die grundsätzlich elektronische Führung gerichtlicher Erkenntnisverfahren, Schriften der EBS Law School, S. 17 ff. |
| [9] Ralph Hecksteden, Die Ende-zu-Ende-Verschlüsselung des besonderen elektronischen Anwaltspostfach, veröffentlicht am 28.11.2016 auf seiner Homepage mit Update vom 28.12.2017, https://ejustice-anwalt.de/aJX1-bea-ende-zu-ende-verschluesselung.shtml |
| [10] Wikipedia End-to-end encryption, https://en.wikipedia.org/wiki/End-to-end_encryption |
| [11] BRAK, Newsletter zum besonderen elektronischen Anwaltspostfach, Ausgabe 3/2018 vom 24.1.2018, http://www.brak.de/zur-rechtspolitik/newsletter/bea-newsletter/2018/ausgabe-3-2018-v-24012018.news.html |
| [12] Ormar Kury, Schreiben der RAK Hamburg an ihre Mitglieder vom 18.1.2018, http://www.rak-hamburg.de/uploads/file/Mitglieder/Mitgliederservice/Kammerschnellbriefe/2018/20180118_beA-Rundschreiben.pdf |
| [13] EGMR, Urteil vom 16.6.2016 – 49176/11, NJW 2017,3577 |
| [14] BVerfG, Beschluß vom 4.7.2006 – 2 BvR 950/05, NJW 2006, 2974 |
| [15] Frank Koch, Rechtsprobleme privater Nutzung betrieblicher elektronischer Kommunikationsmittel, NZA 2008, 911, 915 |
| [16] Thüsing, Beschäftigtendatenschutz und Compliance, § 3. Zum System des Beschäftigtendatenschutzes Rn. 97 |
| [17] Sascha Lobo, De Maizière steuert Richtung Backdoor-Pflicht, Spiegel Online, 24.8.2016, http://www.spiegel.de/netzwelt/web/thomas-de-maiziere-steuert-richtung-backdoor-pflicht-kolumne-a-1109204.html |
| [18] Auf eine detaillierte Darstellung der Schwachstellen des EGVP soll hier aus Sicherheitsgründen verzichtet werden. Die entsprechenden Stellen sollen zunächst die Gelegenheit haben, die Probleme zu beheben. Es soll nur so viel gesagt werden, dass eine konkrete Warnung vor dem EGVP-Client deshalb nicht angebracht scheint. |
| [19] Anleitung der BRAK: Kurzfristige notwendige Änderung der beA Konfiguration, gesichert unter https://erbguth.ch/bea/anleitung.pdf |
| [20] Presseerklärung Nr. 2 vom 18.1.2018 der BRAK zur BRAK-Präsidentenkonferenz in Berlin, http://www.brak.de/fuer-journalisten/pressemitteilungen-archiv/2018/presseerklaerung-02-2018/ |
| [21] Max Mehl, Wie das besondere elektronische Anwaltspostfach (beA) noch zu retten ist, Free Software Foundation Europe, https://fsfe.org/news/2018/news-20180111-01.de.html |
| [22] Atos, Stellungnahme zum besonderen elektronischen Anwaltspostfach (beA), 26.1.2018, Veröffentlicht bei Carsten Hoenig, https://www.kanzlei-hoenig.de/2018/atos-stellungnahme-zum-besonderen-elektronischen-anwaltspostfach-bea/ |
| [23] Beim beAthon galten Chatham House Rules, https://www.chathamhouse.org/about/chatham-house-rule |
| [24] Tagung des EDV-Gerichtstag am 5.3. in Berlin, beA+ mit besserer Software und optimierter Ausrichtung auf den Kanzleialltag, https://www.edvgt.de/veranstaltung/save-the-date-bea-mit-besserer-software-und-optimierter-ausrichtung-auf-den-kanzleialltag/ |
| | |
|
|
|
| |
| | |
| |
| (online seit: 30.01.2018) |
| | |
| |
| Zitiervorschlag: Autor, Titel, JurPC Web-Dok, Abs. |
| | |
| |
