Dienstag, 2. Januar 2018

Wie man EGVP richtig macht ? Teil 1: Einleitung

Diese Artikel-Reihe beschreibt eine Reihe Vorschläge um die Aufgabenstellung von EGVP und dessen Ableger wie zB. beA richtig zu lösen (beA, beN, etc werden im Folgenden lediglich als Zugangsweise bzw. Teilsysteme der EGVP-Infrastruktur betrachtet). Darunter verstehen wir einerseits höchstmögliche Sicherheit, andererseits aber auch praktische Benutzbarkeit und den effizienten Betrieb.
Selbstverständlich wird hier noch kein geschlossenes Systemkonzept geliefert.

In der Analyse / Konzeption müssen wir uns zunächst klar werden, welche konkreten Anforderungen gestellt werden bzw. wo genau klassischen Mailing-Systeme für unseren Anwendungsfall unzureichend sind.


Zustellbestätigung:



Klassische Email bietet keine verläßliche Zustellbestätigung - die Abstreitbarkeit des Empfangs ist stets gegeben. In der materiellen Welt lösen wir das über einen vertrauenswürdigen Dritten, dessen Aussage wir vertrauen.

Beim Einschreiben-Rückschein muß der Empfänger den Eingang vor Erhalt der Sendung (bevor er vom Inhalt Kenntnis nehmen kann) quittieren. Die Annahmeverweigerung wird vom Boten protokolliert.

Eine solche Quittierung läßt sich mittels Cryptographischer Signaturen in bestehende Übertragungsprotokolle (SMTP, IMAP, POP3) nachrüsten. Wir müssen lediglich einige Faktoren sicher stellen:


  • alle beteiligten Server und Clients auf dem Nachrichtenweg müssen die entsprechenden Protokoll-Erweiterungen implementieren
  • die Server-Infrastrukturen und deren Betreiber bedürfen eine besonderen öffentlichen Vertrauensstellung (analog zu Hoheitsträgern) - das Personal muß technisch und juristisch befähigt sein (analog zu amtlich bestellten Gutachtern) - das Gesamtsystem muß kontinulierlicher öffentlicher Überprüfung unterzogen werden
  • die jeweiligen Vorgänge (Übertragungsschritte) müssen fälschungssicher protokolliert werden (einfache Logfiles oder Datenbankeinträge sind leicht zu fälschen)
  • die signierenden Systeme müssen besonders gesichert werden, sodaß zB. manipulierte Zustellbestätigungen wirksam unterbunden und Versuche schnell erkannt werden
  • bei extern eingespeisten Nachrichten oder externen Empfängern - sofern überhaupt zulässig - müssen die hier fehlenden Sicherungsfunktionen klar (auch innerhalb der einzelnen Transaktionen) kommuniziert und protokolliert werden
  • saubere Unterscheidung der beteiligten Rollen (zB. hat der RA selbst oder nur die Sekretärin in Empfang genommen ?) - dh. zB. für eine Mailbox sind prinzipiell mehrere User mit verschiedenen Berechtigungen vorzusehen.
  • vor einem wirksamen Empfang muß der Empfänger auch die technische Verarbeitungsmöglichkeit (Dateiformate, etc) prüfen und aus diesem Grunde zurückweisen können. Die für den Zusteller sichtbaren Metadaten müssen Auskunft hierüber geben und protokolliert werden, damit im Nachgang auch eine rechtliche Prüfung möglich ist. 


Vertraulichkeit des Inhalts:


Einfache eMails im Klartext bieten keinerlei Vertraulichkeit. Hierzu gibt es aber seit Jahrzehnten gute technische Lösungen, zB. GPG/PGP oder auch S/MIME. Die eigentliche Kunst besteht hier vorallem in der Schlüsselverwaltung. Das überschneidet sich auch mit der Verwaltung der Addressaten.

Hierbei gilt es auch verschiedene Vertreter mit einzubeziehen in den unterschiedlichen Rollen mit einzubeziehen. (auch Sekretärin vertritt den Anwalt, allerdings nur in der Büroverwaltung, nicht in prozessualen Fragen). Dies läßt sich durch parallele Addressierung (im Addressverzeichnis verwaltete Verteilerlisten) abbilden - jedoch ist hier zwischen technischem Empfängern (zB. die Kanzlei als Organisation) und Leseberechtigten (zB. dem bestimmten Anwälten selbst) zu unterscheiden. Die Befugnisse und Verantwortlichkeiten der Beteiligten müssen klar definiert und nachvollziehbar sein.

Digitale Unterschrift:


Für die digitale Signatur sind entsprechende Technologien (zB. GPG) schon seit langem vorhanden. Wichtig ist jedoch, daß diese von der Zustellung und Leseberechtigung strikt zu unterscheiden ist. Die persönliche Key-Cards des Anwalts kann sowohl die Signatur-Keys als auch Empfangs-Keys enthalten, allerdings sollten diese dennoch stets unterschieden werden - niemals ein Key für alles !
Bildlich gesprochen: mehre Karten in einem Stück Plastik, aber niemals eine Karte für alles.

Dies ist wichtig sowohl für die Veränderungen der Rollen / Befugnisse einzelner Personen, als auch zur Minimierung von Störungen bei Verlust oder Defekt der Karten notwendig.

Problemkreis Vertretung:


In den allermeisten Fällen ist die Vertretung - bzw. vom einzelnen Anwalt selbst abweichende Empfänger/Leser im Vorraus planbar. So geht die Post üblicherweise an die Kanzlei als solche.
Hier lassen sich im Vorfeld entsprechende Addressaten über Verteiler festlegen: die Kanzlei als solche stellt einen Verteiler dar, welcher die internen Empfänger (Anwälte, Sekretariat, etc).

Hier ist aber auch die Empfangs-/Leseberechtigung von der prozessualen Vertretung zu unterscheiden.

Selbst bei einem blitzartigem Ausscheiden (zB. fristlose Kündigung bei schwerwiegenden Fällen) kann zB. über eine Hotline eine sofortige Zertifikat-/Karten-Sperrung veranlaßt werden. Hier kann es ohnehin nur noch um Schadensbegrenzung gehen, da solcher Kündigungen üblicherweise ganz andere schwere Verstöße vorausgehen.

Bei prozessualen Vertretungen innerhalb von Sozietäten sind die Vertreter üblicherweise vorher bekannt bzw. können dem Sender (zB. Gericht) zeitnah bekannt gegeben werden. Bereits empfangene Dokumente kann vertetende Anwalt bzw. das Sekretariat dem Vertreter zur Verfügung stellen - wie das auch schon bei der Papier-Post der Fall ist. Abgesehen von Aktualisierung des Kanzlei-Verteilers sind hier keine weiteren Maßnahmen im EGVP nötig.

Härtefälle wie zB. Tod des Anwalts (und damit ggf. Verlust auschließlich an ihn selbst gesandter Dokumente) stellen extreme Ausnahmefälle dar, mit denen die Justiz auch heute schon umgehen muß. Hier muß so oder so ein neuer Anwalt bestellt, Fristen zurückgestellt und Dokumente ggf. neu versandt werden. Entsprechende Mechanismen hiefür müssen ohnehin existieren, die Postzustellung ist nur ein kleiner Aspekt dabei, sodaß besondere Maßnahmen - etwa sogar "Umschlüsseln" im EGVP nicht erforderlich sind.

6 Kommentare:

  1. Nur mal zur Diskussion:

    Was spräche z.B. gegen einen speziellen Mail-Server mit S/MIME-Basis. Dieser Mailserver kommuniziert sowieso per https. Die Nachrichten werden Ende-zu-Ende verschlüsselt. Der Mailserver hält nach, welche Nachrichten abgerufen wurden und kann bei Nichtabruf eine Erinnerung per SMS senden. Der Mail-Client kann automatisch oder manuell darüber hinaus eine Empfangsbestätigung senden. Erfolgt diese Empfangsbestätigung nicht trotz technischem Empfang kann ebenfalls eine SMS als Erinnerung gesendet werden.
    Etwas schwieriger ist die Vertretung zu lösen. Um Vertretung und Ende-zu-Ende Verschlüsselung zu vereinen, muss die Vertretung beim Absenden der Nachricht bekannt sein. Dies könnte mit einem Verzeichnisdienst erfolgen, in dem die Anwaltskanzleien, die Anwälte und die Vertretungen aufgeführt sind. Wer seine Vertretung nicht offen legen möchte, kann lokal sein Zertifikat auf einem Server installieren und dort eine Weiterleitung einrichten. Damit gibt er zwar auch ein Stück Sicherheit auf - macht dies jedoch selbstbestimmt.
    Daneben kann man noch einen Webclient anbieten.
    Der Vorteil eines solchen Verfahrens ist
    a) keine Signaturkarte
    b) Funktioniert mit Standardsoftware auf allen Clients (auch mobil) ohne Installation einer Software - lediglich das persönliche Zertifikat muss installiert werden.
    c) keine spezielle teure Software, die anfällig für Sicherheitslücken ist

    Nachteil: Mit der Integration in Outlook & Co wird diese Lösung anfällig von Nachrichtendiensten, die dafür Hintertüren haben.

    AntwortenLöschen
    Antworten
    1. > Was spräche z.B. gegen einen speziellen Mail-Server mit S/MIME-Basis

      Dem Mailserver selbst kann es egal sein, ob wir S/MIME oder GPG verwenden - das betrifft nur die Clients.

      Aber die Mailserverver auf der Strecke brauchen noch eine verläßliche Protokollierung.

      > Dieser Mailserver kommuniziert sowieso per https

      Mailserver kommunizieren üblicherweise per SMTP (bzw. IMAP zum Client). Natürlich per TLS, aber sind nur die jeweiligen Einzelstrecken - reicht nicht für eine Ende-zu-Ende-Sicherheit. (der Betreiber liest mit).

      > Der Mailserver hält nach, welche Nachrichten
      > abgerufen wurden und kann bei Nichtabruf eine
      > Erinnerung per SMS senden

      Ja, aber das Ganze muß natürlich auch manipulationssicher protokolliert werden. Theoretisch haben wir die Daten auch im Logfile, aber das ist trivial zu fälschen. Wir brauchen eine Art "elektronischen Rückschein" mit entsprechenden Signaturen (incl. Fingerprint der Mail)

      > Der Mail-Client kann automatisch oder manuell
      > darüber hinaus eine Empfangsbestätigung senden.

      Es braucht zumindest im Protokoll eine Bestätigung des finalen Downloads - schon allein, damit festgestellt werden kann, wenn etwas nicht ankam und nochmal geholt werden muß. Hier müssen auch anhaltende Übertragungsprobleme organisatorisch behandelt werden (evtl. Rückmeldung an den Absender) Das ist natürlich etwas anderes als eine inhaltliche Empfangsbestätigung.

      > Um Vertretung und Ende-zu-Ende Verschlüsselung zu
      > vereinen, muss die Vertretung beim Absenden der
      > Nachricht bekannt sein. Dies könnte mit einem
      > Verzeichnisdienst erfolgen, in dem die
      > Anwaltskanzleien, die Anwälte und die Vertretungen
      > aufgeführt sind

      Genau mein Vorschlag. Das dürfte zumindest alle Fälle außer einer Notvertretung (zB. Anwalt gestorben) abdecken - und die anderen müssen sowiso organisatorisch abgefangen werden.

      > Wer seine Vertretung nicht offen legen möchte, kann
      > lokal sein Zertifikat auf einem Server installieren
      > und dort eine Weiterleitung einrichten.

      IMHO muß die sowiso dem angezeigt werden. Das muß ja nicht für jedermann abrufbar sein. Die Vertretungen wären ohnehin an bestimmte Rollen gebunden, also zB. gegenüber dem Gericht.

      > Daneben kann man noch einen Webclient anbieten.

      Das ist genau das womit die BRAK auf die Nase gefallen ist. Hatte das 2013 schonmal in einer Studie für die BNotK analysiert (damals gings um eine Integration in Zimbra) - ist ein heikles Spiel, der Webserver ist eine große Schwachstelle, aber auch XSS !

      > Der Vorteil eines solchen Verfahrens ist
      > a) keine Signaturkarte

      Das ist ein großer Nachteil !

      SW-Zertifikate können leicht gestohlen werden, wenn der Angreifer nur mal kurzzeitig Zugriff auf den Rechner hat. Deshalb sind sie für die qeS nicht ausreichend.

      > c) keine spezielle teure Software, die anfällig für Sicherheitslücken ist

      Die Client-Software soll ohnehin FOSS sein, sonst ist sie nicht vertrauenswürdig prüfbar. Überhaupt müssen wir beim Client generell nochmal sehr sorgfältig nachdenken - das ist die ganz große Schwachstelle.

      > Nachteil: Mit der Integration in Outlook & Co wird
      > diese Lösung anfällig von Nachrichtendiensten, die
      > dafür Hintertüren haben.

      Outlook hat in sicherheitskritischen Umgebungen ohnehin nichts verloren.

      --mtx

      Löschen
  2. Dieser Kommentar wurde vom Autor entfernt.

    AntwortenLöschen
  3. Achtung!!!
    der Betreiber liest - zumindest theoretisch möglich und damit nicht ausgeschlossen - bei beA auch mit!

    Ein duplizierter Datenstream ist bei dieser Architektur grundsätzlich möglich.

    AntwortenLöschen
  4. Achtung!!!
    der Betreiber liest - zumindest theoretisch möglich und damit nicht ausgeschlossen - bei beA auch mit!

    Ein duplizierter Datenstream ist bei dieser Architektur grundsätzlich möglich.

    AntwortenLöschen
  5. Achtung!!!
    der Betreiber liest - zumindest theoretisch möglich und damit nicht ausgeschlossen - bei beA auch mit!

    Ein duplizierter Datenstream ist bei dieser Architektur grundsätzlich möglich.

    AntwortenLöschen