Empfangsbekenntnis 3.0 (STP LabsDay 2019)

Am vergangenen Donnerstag und Freitag (14.-15. November 2019) habe ich wieder am STP LabsDay teilgenommen. Diesen internen 24h-Hackathon veranstaltet STP jedes Jahr. Die Idee des LabsDays ist es, in kleinen Gruppen an einer eigenen Idee zu arbeiten. Wer kennt es nicht? Man wollte schon immer einmal Framework X oder Bibliothek Y ausprobieren, aber irgendwie ist man nie dazu gekommen. Genau dafür ist der LabsDay der perfekte Rahmen. Außerdem übernimmt STP an diesen beiden Tagen komplett die Verpflegung.

Insgesamt haben sechs Teams teilgenommen. Mein Kollege und ich bildeten eines dieser Teams. Während die anderen Teams sich primär mit künstlichen Intelligenzen beschäftigten, haben mein Kollege und ich uns einem Thema gewidmet, über das ich schon länger nachgedacht hatte: das Empfangsbekenntnis. Nach der §174 Zivilprozessordnung sind Anwälte, Gerichte und alle Personen und Institutionen, deren Arbeit besonders zuverlässig sein muss, dazu verpflichtet, den Erhalt von entsprechenden Dokumenten zu bestätigen. Auf die klassische Art und Weise passiert das mit der Post. Das Empfangsbekenntnis 1.0 ist ein spezielles Dokument, welches vom Anwalt unterzeichnet und dann an den Sender des ursprünglichen Dokuments zurückgeschickt werden muss. Der Hauptnachteil dieser Lösung liegt auf der Hand. Die Anwälte und Gerichte versinken in einer immer größer werdenden Papierflut. Deswegen wurde vor einigen Jahren das Empfangsbekenntnis 2.0 eingeführt. Mit beA- und EGVP-Postfächern wird eine digitale Empfangsbekenntnis automatisiert erstellt und verschickt, sobald der Anwalt das Dokument in seinem Software Client erhalten hat. Wenn ein digitales Empfangsbekenntnis auf einem zentralen Server oder einem Client gespeichert ist, besteht die große Gefahr eines Datenverlusts. Im Falle eines Brandes im Datenzentrum oder einer Sicherheitspanne bei den Betreibern sind die Daten gefährdet.

Wir wollten diese Situation verbessern. Meine Mission bei STP ist es, unseren Partnern, Kunden und Kollegen die Vorteile der modernen Technologien zu ermöglichen. Moderne Technologien sind zum Beispiel Cloud, Mobile, Artificial Intelligence und die Blockchain. Beim STP LabsDay haben wir deswegen das Empfangsbekenntnis 3.0 als Decentralized Application (DAPP) in Form eines Smart Contracts auf der Ethereum Blockchain realisiert. Mein Kollege hatte zu dem Thema Blockchain bereits seine Bachelor Thesis geschrieben und auch mir waren einige theoretische Konzepte bereits bekannt. Erwähnenswerte praktische Erfahrung hatte ich aber bisher noch keine. Also haben wir uns ein Tutorial gesucht und uns diesem Projekt spielerisch genährt. Schließlich wollten wir am Ende des Hackathons eine funktionsfähige Lösung präsentieren.

Der Prozess ist eigentlich ziemlich einfach. Ein Sender registriert sein Dokument und gibt es danach an den Empfänger weiter, welcher den Erhalt bestätigt. Diesen Prozess konnten wir problemlos in Form einer Abstract State Maschine in Solidity, der Programmiersprache der Ethereum Virtual Machine (EVM), implementieren. Dabei wollten wir nicht nur digitale Dokumente in unserer Lösung verwalten, sondern auch physikalische. Wir brauchten also eine Abstraktion von physikalischen und digitalen Dokumenten, um für diese Abstraktion ein Empfangsbekenntnis zu speichern. Unsere Abstraktion nennen wir Document Link. Wenn das Dokument bereits ein digitaler Datensatz ist, können wir den Document Link ganz einfach als Hash des digitalen Datensatzes erzeugen. Ist das Dokument allerdings ein physikalisches Dokument, können wir eine Zufallszahl generieren und diese in Form eines QR-Codes auf den Brief drucken. Natürlich können wir auch eine URL als Document Link verwenden. Damit haben wir die Möglichkeit geschaffen, um in einer vereinheitlichten Form sowohl digitale als auch physikalische Dokumente zu verwalten.

Ein Sender ermittelt den Document Link aus seinem Dokument und persistiert diesen in der Blockchain. Ein Empfänger des Dokuments kann dann den Document Link mit dem Empfangsbekenntnis ebenfalls in der Blockchain persistieren. Um sicherzustellen, dass nur die Person, die das Dokument tatsächlich erhalten hat und jetzt besitzt, das Empfangsbekenntnis ausstellen kann, nutzen wir eine Hashfunktion. Der Sender ermittelt den Hash des Document Links und persistiert diesen auf der Blockchain. Der Empfänger muss jetzt genau den Document Link auf der Blockchain speichern, der zu dem vom Sender persistierten Hash passt. Versucht er einen Document Link zu persistieren, dessen Hash nicht bereits vorher registriert wurde, wird die Transaktion abgelehnt.

Wenn das Dokument von einer zweiten Person gelesen wird, wird auch eine zweite Empfangsbekenntnis in der Blockchain gespeichert. Wenn ein Empfänger das gleiche Dokument, also mit dem selben Document Link, an eine weitere Person sendet, tritt der Empfänger jetzt als Sender auf und persistiert den Hash des Document Links. In diesem Fall wurde das gleiche Dokument von zwei unterschiedlichen Sendern registriert. Das ist auch für alle Beobachter erkennbar. Wenn jetzt eine dritte Person dieses Dokument empfängt, werden zwei Empfangsbekenntnisse ausgestellt, die jeweils einem Sender zugeordnet werden. Ein Sender kann also jederzeit feststellen, 1) wer sein Dokument wann empfangen hat und 2) wer es ebenfalls verschickt oder weitergeleitet hat.

Diese Prozesslogik lief nun in einem Smart Contract auf der Blockchain. Dazu haben wir noch ein Frontend mit React und Web3 gebaut und auf Azure gehostet. Unser Frontend listet alle getrackten Dokumente mit sämtlichen Empfangsbekenntnissen auf. Den Smart Contract selbst haben wir dann in das Ethereum Testnetzwerk Kovan deployt. Anschließend haben wir uns Szenarien für die Präsentation unserer Ergebnisse überlegt. Um die ganze Sache einfach demonstrieren zu können, hatten wir uns überlegt, dass wir auf ein Papier zwei QR-Codes drucken. Den einen QR-Code scannen wir um dieses Dokument zu registrieren und den anderen QR-Code scannen wir um das Dokument zu empfangen. Genauso haben wir es auch im Rahmen der Ergebnispräsentation demonstriert. Dazu öffneten wir die URLs hinter den QR-Codes jeweils mit MetaMask for iOS und konnten so die Transaktionen mit unseren Mobiltelefonen signieren. Natürlich würden Software Clients diesen Vorgang automatisiert im Namen des Anwalts durchführen.

Die Vorteile von Empfangsbekenntnis 3.0 verdanken wir der Blockchain. Das Empfangsbekenntnis ist unveränderlich, unabstreitbar und für alle sichtbar für immer persistiert. Dass wir uns bei unserem Prototypen für das öffentliche Ethereum Testnetz entschieden haben, hat die Konsequenz, dass Transaktionen nicht kostenlos sind. Wir müssen die Miner incentivieren, damit sie unsere Transaktionen in Blocks verpacken und der Blockchain hinzufügen. Dafür müssen wir bei jedem Schreibvorgang etwas Geld in der Ethereum-Kryptowährung namens Ether bezahlen (Gas). Wenn viele Transaktionen in die Blockchain gespeichert werden sollen, steigt außerdem die Latenz. Das bedeutet, dass wir ein paar Sekunden bis Minuten warten müssen, bis unsere Transaktion bestätigt und tatsächlich persistiert ist. Diese beiden Nachteile haben Consortium Blockchains nicht. Deswegen würden wir für einen real life Einsatz unserer Lösung eine Consortium Blockchain der Public Ethereum Blockchain vorziehen.
Ein weiterer Nachteil ist die komplizierte Weiterentwicklung von Smart Contracts. Genau wie Daten, ist auch der Code unveränderlich auf der Blockchain gespeichert. Das bedeutet, dass wir einen Fehler nicht einfach korrigieren können. Mit jeder Fehlerkorrektur müssen wir das Programm neu auf der Blockchain installieren und allen Verwendern mitteilen, dass sie jetzt diese neue Version verwenden sollen. Zusätzlich müssen natürlich die Daten aus der alten in die neue Version migriert werden. Idealerweise würde die alte Version abschließend auch deaktiviert werden, allerdings müssten wir den Smart Contract von Begin an dementsprechend fehlerfrei programmieren. Das macht das Weiterentwickeln von Smart Contracts umständlich. Im Rahmen des 24h-Projekts haben wir zwei Versionen deployen müssen.

Am Ende war unser Projekt ein ganzer Erfolg. Unser Smart Contract hat sehr gut funktioniert und unsere Präsentation hat einen guten Eindruck hinterlassen. Wir haben für unsere Arbeit den Vorstandspreis gewonnen. Der Kundenpreis und der Zuschauerpreis gingen an das Projekt unseres anderen geschätzten Kollegen, dessen Modell automatisiert Fristen in Dokumenten erkennen konnte.

Auch wenn nicht alle Teams einen Preis gewonnen haben, haben wir alle viel dazugelernt. Alle Projekte haben die Firma merklich motiviert und inspiriert. Wie jedes Jahr war der STP LabsDay ein echtes Highlight. Um 16 Uhr hatten wir uns das Wochenende dann auch redlich verdient. Ich freue mich jetzt schon auf den nächsten STP LabsDay. Ein großartiges Event!

 

Weiterentwicklung?

Unser Prototyp funktioniert. Doch bevor wir unseren Code produktiv einsetzen würden, müssten wir noch eine Sicherheitserweiterung einbauen. Damit die Miner unsere Daten in Form von Transaktionen in Blöcke verpacken können, müssen wir ihnen den Input für unsere Smart Contract Funktionen schicken. Aktuell muss ein Empfänger den Document Link im Klartext an den Miner schicken, damit der Smart Contract den Hash bilden und mit dem vom Sender gespeicherten Hash vergleichen und persistieren kann. Diesen Klartext des ersten Empfängers könnte eine andere Partei mitlesen und ebenfalls persistieren. Dadurch können nach einem ersten Empfangen weitere Parteien ein Empfangsbekenntnis für ein Dokument ausstellen, obwohl sie es gar nicht tatsächlich besitzen. Durch die Signatur der Transaktion ist jederzeit erkennbar, wer die Anfrage gestellt hat, sodass das System nicht gespooft werden kann. Dennoch schwächt dies die Sicherheit des Empfangsbekenntnis. Das Problem ist die Verwendung der Hashfunktion. Nachdem der entsprechende Klartext einmal bekannt ist, kann ihn jeder nutzen um den Hash zu berechnen. Um diesem Verhalten entgegen zu wirken, dürfte der Document Link niemals im Klartext an die Miner geschickt werden. Ihn einfach zu signieren oder mit der Adresse des Empfängers zu prefixen und anschließend zu hashen reicht leider nicht, da der Smart Contract den Klartext nicht kennt und die Signatur oder den Hash deswegen nicht validieren kann.

Die Idee ist, den Document Link wie einen Private Key zu verwenden. Mit diesem Private Key müsste ein Empfänger seine durch die Blockchain eindeutige Adresse signieren und diese anstelle des Klartexts an den Miner schicken. Nur die Parteien, die das Dokument tatsächlich besitzen und deswegen den Private Key kennen, können dies tun. Würde eine signierte Adresse von einer anderen Partei wiederverwendet werden, würde die Signatur nicht zur tatsächlichen Adresse des vermeintlichen Empfängers passen. In diesem Fall ist der Smart Contract nämlich in der Lage die Signatur mit dem vom Sender persistierten Public Key zum Private Key aka Document Link zu überprüfen.

Den Code unseres Prototypen finden Sie im Kovan Testnetz (0xf41930b233137f37b7cd770c3b36eaa51d38c8e2) oder auf Github.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s