Shark Contracts – digitale Verträge schließen in Peer-to-Peer Ad-hoc-Netzwerken

Shark Contracts – digitale Verträge schließen in Peer-to-Peer Ad-hoc-Netzwerken Bachelorarbeit Name des Studiengangs Angewandte Informatik Fachbereich 4 vorgelegt von Jannis Hilric Scheibe Datum: Berlin, 08.02.2025 Erstgutachter: Prof. Dr. Thomas Schwotzer Zweitgutachterin: Prof. Dr. Adrianna Alexander I Kurzbeschreibung In dieser Arbeit wird die Entwicklung von SharkContracts beschrieben. Dies ist eine Java-SoftwareBibliothek, die Vertragserstellung zwischen mehreren Parteien in einem dezentralen P2P-Netzwerk ermöglicht. Für die nötige Kommunikation wird ASAP/Shark eingesetzt. Es wird an das Thema durch einen Blick auf die theoretischen und technischen Grundlagen für diese Arbeit herangeführt. Außerdem wird das Konzept von SharkContracts genau beschrieben und begründet, wie man zu dieser Lösung gekommen ist. Dafür werden Schlussfolgerungen aus dem Grundlagen-Teil herangezogen, um daraus Anforderungen zu formulieren. Danach wird die prototypische Implementierung anhand von Code-Beispielen erklärt. Die Beispiele demonstrieren, dass die entwickelte Software funktioniert, aber manche Probleme im Bezug auf Vertragserstellung und Handhabung offen bleiben, wie z.B. Impersonation oder eingeschränkte Vertraulichkeit durch Metadaten-Attacken. Die Bibliothek kann Grundlage für weitere Arbeiten an diesem Thema sein. II Inhaltsverzeichnis 1 Einführung....................................................................................................................................... 1 1.1 Hintergrund................................................................................................................................1 1.2 Problemstellung......................................................................................................................... 1 1.3 Aufbau der Arbeit.......................................................................................................................2 2 Grundlagen......................................................................................................................................3 2.1 Vertrag........................................................................................................................................3 2.2 Digitaler Vertrag........................................................................................................................3 2.2.1 Merkmale eines digitalen Vertrags.....................................................................................4 2.2.2 Anforderungen...................................................................................................................5 2.3 Signatur......................................................................................................................................5 2.3.1 Informationssicherheit.......................................................................................................5 2.3.2 Verund Entschlüsselung...................................................................................................6 2.3.3 Signieren und Verifizieren..................................................................................................6 2.3.4 Anforderungen...................................................................................................................7 2.4 P2P-Netzwerke..........................................................................................................................7 2.5 ASAP/Shark...............................................................................................................................8 2.6 SharkPKI....................................................................................................................................9 2.7 ASAPAndroid............................................................................................................................9 3 Konzeption von SharkContracts..................................................................................................10 3.1 Methodologie...........................................................................................................................10 3.2 API nach Außen....................................................................................................................... 10 3.2.1 Anforderungen.................................................................................................................10 3.2.2 Definition des Interfaces..................................................................................................10 3.2.3 Persistenz.........................................................................................................................12 3.3 Protokoll zum Aushandeln der Verträge..................................................................................13 3.4 Datenstrukturen........................................................................................................................15 3.4.1 Vertrag..............................................................................................................................15 3.4.2 Unterschrift......................................................................................................................16 3.4.3 Signaturen........................................................................................................................16 3.5 Verund Entschlüsselung.........................................................................................................17 3.6 ContractContents.....................................................................................................................18 3.7 SharkContractsSample.............................................................................................................20 III 4 Implementierung...........................................................................................................................21 4.1 SharkContracts.........................................................................................................................21 4.1.1 Initialisierung...................................................................................................................21 4.1.2 Erstellen eines Vertrags....................................................................................................22 4.1.3 Unterschreiben eines Vertrags..........................................................................................23 4.1.4 Empfangen eines Vertrags................................................................................................24 4.1.5 Verund Entschlüsselung des Vertragsinhalts..................................................................25 4.1.6 Persistenz.........................................................................................................................26 4.1.7 Tests..................................................................................................................................26 4.2 ContractContents.....................................................................................................................28 4.3 SharkContractsSample.............................................................................................................29 4.3.1 Screenshots.......................................................................................................................29 4.3.2 Vertrag erstellen...............................................................................................................30 4.3.3 Persistenz.........................................................................................................................31 4.3.4 ASAPAndroid und Modifikation davon...........................................................................31 5 Bewertung der Ergebnisse............................................................................................................ 33 5.1 Zusammenfassung...................................................................................................................33 5.2 Mögliche Attacken...................................................................................................................33 5.2.1 Nachahmung....................................................................................................................33 5.2.2 Lauschangriff...................................................................................................................33 5.2.3 Nicht unterschriebene Verträge........................................................................................34 5.2.4 Implementierungsfehler...................................................................................................34 5.3 Mögliche Anwendungen und Ausblick....................................................................................35 Literaturverzeichnis...........................................................................................................................I Anhang A – Quellcode-Links..........................................................................................................III Eigenständigkeitserklärung............................................................................................................IV IV Abbildungsverzeichnis Abbildung 1: UML-Klassendiagramm SharkContracts.....................................................................11 Abbildung 2: UML-Klassendiagramm ContractsListener.................................................................12 Abbildung 3: Übersicht ContractStorage...........................................................................................13 Abbildung 4: Sequenzdiagramm Vertrag unterschreiben mit zwei Parteien......................................14 Abbildung 5: UML-Klassendiagramm Contract und ContractParty..................................................16 Abbildung 6: UML-Klassendiagramm ContractSignature.................................................................16 Abbildung 7: Übersicht Hashes, Signaturen und deren Abhängigkeiten...........................................17 Abbildung 8: Schema Vertrags-Verschlüsselung................................................................................18 Abbildung 9: Schema Vertrags-Entschlüsselung................................................................................18 Abbildung 10: Übersicht ContractContents.......................................................................................19 Abbildung 11: Übersicht ContractPackage........................................................................................19 Abbildung 12: ContractContent Hierarchie........................................................................................20 Abbildung 13: Erster App-Start..........................................................................................................30 Abbildung 14: Übersicht....................................................................................................................30 Abbildung 15: Vertrag unterschreiben................................................................................................30 Abbildung 16: Vertrag erstellen – Parteien wählen............................................................................31 Abbildung 17: Vertrag erstellen – Inhalt definieren...........................................................................31 V Quellcode-Verzeichnis Listing 1: Initialisierung von SharkContracts.....................................................................................21 Listing 2: Aufruf - Vertrag erstellen...................................................................................................22 Listing 3: Implementierung createContract (1/3)...............................................................................22 Listing 4: Implementierung createContract (2/3)...............................................................................22 Listing 5: Implementierung createContract (3/3)...............................................................................23 Listing 6: Aufruf - Vertrag unterschreiben.........................................................................................23 Listing 7: Implementierung signContract (1/2)..................................................................................23 Listing 8: Implementierung signContract (2/2)..................................................................................24 Listing 9: Registrieren als ASAPMessageReceivedListener..............................................................24 Listing 10: Empfangen von ASAP-Nachrichten (asapMessagesReceived).......................................24 Listing 11: Empfangen von Verträgen (onContractReceived)............................................................25 Listing 12: Kommentierter Code zum Verschlüsseln eines Vertrags..................................................26 Listing 13: testContractsSign (1/4) - Initialisierung...........................................................................27 Listing 14: testContractsSign (2/4) – Vertrag erstellen......................................................................27 Listing 15: testContractsSign (3/4) – Vertrag unterschreiben............................................................28 Listing 16: testContractsSign (4/4) – Vertragsabschluss verifizieren.................................................28 Listing 17: ContractContents Serialisierung (1/2)..............................................................................29 Listing 18: ContractContents Serialisierung (2/2)..............................................................................29 Listing 19: Serialisierter Vertragsinhalt des Typs text........................................................................29 Abschnitt 1 Einführung 1 1 Einführung Dieser erste Abschnitt soll in das Thema einführen, die fachlichen und technischen Hintergründe erklären und beschreiben, worum es in dieser Arbeit geht. Außerdem wird für ein besseres Verständnis kurz der Aufbau dieser schriftlichen Ausarbeitung dargelegt. 1.1 Hintergrund ASAP [1] (kurz für: „Asynchronous Semantic Ad-hoc Protocol“) ist ein Protokoll für P2P Ad-hocNetzwerke, dessen Entwicklung an der HTW Berlin vorangetrieben wird. Mit der bereits bestehenden Android-Implementierung ASAPAndroid [2] lassen sich Nachrichten z.B. über Bluetooth, Wifidirect oder TCP zwischen Geräten austauschen. Das Protokoll ASAP und die bestehenden Implementierungen davon werden in dieser Arbeit als Basis zur Informationsübertragung genutzt. In verschiedenen Anwendungen können mit der Schließung von digitalen Verträgen Probleme gelöst werden. Mehr dazu im Abschnitt 5.3 Mögliche Anwendungen und Ausblick. 1.2 Problemstellung Ziel der Arbeit ist die Konzeption und prototypische Implementierung einer Bibliothek, die man praktisch benutzen kann, um digitale Verträge zu erzeugen, zu signieren und um ihre Gültigkeit zu überprüfen. Beim Design der Datenmodelle und der API der Bibliothek soll auf Anforderungen acht gelegt werden, die ein Anwender haben könnte. Die Bibliothek soll nicht nur Lösungen zur Handhabung von Vertragsgegenständen bieten, sondern auch die erforderliche Kommunikation zwischen den Vertragspartnern unterstützen. Dazu sollen ASAP-Nachrichten genutzt werden, die diese Kommunikation ermöglichen. Für die bei digitalen Verträgen erforderliche Funktionalität zum Verwalten von Schlüsseln und zum Signieren von Daten wird die SharkPKI [3] genutzt. Diese Arbeit ordnet sich in das bestehende Ökosystem um ASAP herum ein, das unter anderem z.B. den SharkMessenger [4] für sichere Nachrichten-Kommunikation, SharkHedwig [5] als Protokoll für die Lieferung von Paketdrohnen oder SharkCreditMoney [6], einem dezentralisierten Zahlungssystem, umfasst. Die Arbeit hat auch das Ziel, dieses Ökosystem um einen wertvollen Baustein zu ergänzen. Möglicherweise dient diese Arbeit als Grundlage für darauf aufbauende Arbeiten oder Anwendungen. Da- Abschnitt 1 Einführung 2 her ist die Dokumentation sowie die Verständlichkeit der Bibliothek und Einfachheit in der Benutzung sehr wichtig. 1.3 Aufbau der Arbeit Für eine bessere Verständlichkeit dieser Arbeit sei erläutert, wie die Arbeit aufgebaut ist: Zuerst werden die Grundlagen der Arbeit in Abschnitt 2 aufgegriffen. Dabei geht es um Begriffe wie Vertrag, Signatur und P2P-Netzwerke. Auch die technischen Grundlagen werden beschrieben, auf die diese Arbeit aufbaut, also vor allem ASAP/Shark, die SharkPKI und ASAPAndroid. Aus einer Analyse der Grundlagen werden teilweise direkt Anforderungen für die Software-Bibliothek SharkContracts ermittelt, die dann im folgenden Abschnitt aufgegriffen werden. Im Abschnitt 3 zur Konzeption von SharkContracts wird das Design und Konzept der Bibliothek aufgeschlüsselt und begründet. Dies wiederum endet im Abschnitt 4 zur Implementierung, in dem die prototypische Implementierung von SharkContracts anhand von Code-Beispielen genau erklärt wird. Sicherheit ist ein wichtiger Aspekt dieser Arbeit, weswegen der letzte Abschnitt 5 Bewertung der Ergebnisse mögliche Attacken auf die ausgearbeitete Software beschreibt. Weiterhin werden auch praktische Beispiele gezeigt, wie man SharkContracts einsetzen kann. Im Anhang A – Quellcode-Links findet man die Links zum Quellcode der verschiedenen Teile der Arbeit. Abschnitt 2 Grundlagen 3 2 Grundlagen In diesem Abschnitt geht es um die theoretischen und technischen Grundlagen, die die Basis für diese Arbeit sind. Angefangen wird mit den theoretischen Grundlagen über digitale Verträge, die notwendige Kryptografie und P2P-Netzwerke. Danach geht es um die technische Basis, auf die die Arbeit aufbaut, also die verschiedenen ASAP-Komponenten wie ASAPJava, SharkPeer, die SharkPKI und ASAPAndroid. 2.1 Vertrag Ein Vertrag im deutschen Recht ist kurz formuliert eine verbindliche Vereinbarung zwischen Menschen, Organisationen oder Staaten. „Diejenigen, die einen Vertrag schließen, nennt man ‚Vertragsparteien‘“. [7] Eng damit zusammenhängend gilt die Vertragsfreiheit. Darunter versteht man unter anderem die Freiheit, Verträge schließen zu dürfen. Dazu gehören außerdem die drei folgenden Freiheiten [8]: 1. Abschlussfreiheit: Alle Vertragsparteien können frei wählen, ob und mit wem ein Vertrag geschlossen wird. 2. Inhaltsund Gestaltungsfreiheit: Der Inhalt des Vertrags ist frei bestimmbar. 3. Formfreiheit: Die Form des Vertrags ist nicht vorgegeben. Davon ausgenommen sind Sonderfälle, bei denen die Form durch das Gesetz eingeschränkt sind. Eine wichtige Voraussetzung für Verträge ist die Feststellbarkeit ihrer Gültigkeit. Wenn nicht feststellbar ist, dass ein Vertrag gilt, würden die Vertragsparteien ihre Leistungen nicht erfüllen. [9] 2.2 Digitaler Vertrag Der elektronische Vertrag bzw. digitale Vertrag ist eine spezielle Ausprägung des Vertrags, bei der digitale Infrastrukturen verwendet werden, um diesen zu schließen und zu speichern. Wenn in dieser Arbeit von „Vertrag“ gesprochen wird, ist nicht unbedingt ein rechtlich gültiger Vertrag gemeint, sondern vielmehr das abstrakte Konzept, das dahintersteht: eine verbindliche Vereinbarung zwischen Parteien. Die Parteien können anders als bei rechtlich gültigen Verträgen z.B. auch Geräte sein. Dabei ist auch zu beachten, dass es im deutschen Recht keine einseitigen („unilateralen“) Verträge gibt. Damit sind Verträge gemeint, die nur von einer Partei unterschrieben werden. Im normalen Abschnitt 3 Konzeption von SharkContracts 10 3 Konzeption von SharkContracts SharkContracts soll als Bibliothek Anwendungen erlauben, Verträge mit ASAP auszutauschen. Beim Design liegt ein besonderer Wert vor allem auf die nach außen sichtbare API, also die verwendete Datenstruktur der Verträge und Unterschriften, sowie das Protokoll zum Austauschen der Daten. 3.1 Methodologie Bei der Entwicklung wurde iterativ vorgegangen. Das erste Konzept von Datenmodell und API wurde prototypisch entwickelt. Erkenntnisse daraus wurden genutzt, um das Datenmodell zu verfeinern und neue Methoden zur API hinzuzufügen. Diese Änderungen wurden wiederum im Prototypen ergänzt. 3.2 API nach Außen Die zu entwickelnde Bibliothek soll von weiteren Anwendungen verwendbar sein. Daher soll sie ein Interface nach außen anbieten, das die Funktionalität der Bibliothek definiert. Da die Bibliothek für das ASAP-Ökosystem entwickelt wird, wird sie als SharkComponent designt. Das bedeutet, dass sie flexibel als Komponente neben anderen SharkComponents einsetzbar ist wie in Abschnitt 2.5 ASAP/Shark beschrieben und dass sie die Standards einer SharkComponent erfüllt. 3.2.1 Anforderungen Nach außen hin soll die Bibliothek ermöglichen, Verträge zu erstellen und diese zu unterschreiben. Außerdem soll es mit ihr möglich sein, zu prüfen, ob Verträge und Unterschriften gültig sind. Weiterhin soll die Bibliothek eine Möglichkeit bereitstellen, sich mit einem Listener zu registrieren, der neue Verträge und Unterschriften erhält, sobald diese in SharkContracts eingegangen sind und verifiziert wurden, damit die Anwendung darauf reagieren kann, z.B. um den Nutzer über einen neuen Vertrag zu informieren. 3.2.2 Definition des Interfaces SharkContracts soll folgende Methoden implementieren: •getKnownPeers: Liefert eine Liste der verfügbaren Peers zurück, mit denen Verträge abgeschlossen werden können. •listContracts: Liefert eine Liste aller bekannten Verträge Abschnitt 3 Konzeption von SharkContracts 11 •listSignatures: Liefert eine Liste aller bekannten Unterschriften •createContract: Erstellt einen neuen Vertrag und veröffentlicht diesen via ASAP •signContract: Erstellt eine Unterschrift und veröffentlicht diese via ASAP •verifyContract: Verifiziert die Gültigkeit eines Vertrags anhand seiner Signatur, ohne erforderliche Unterschriften zu beachten •verifySignature: Verifiziert die Gültigkeit einer Unterschrift durch Prüfung der Signatur •isSignedByAllParties: Prüft, ob ein Vertrag von allen Parteien unterschrieben wurde und damit tatsächlich gültig ist •registerListener: Registriert einen ContractsListener, der daraufhin neue Verträge und Unterschriften erhält, sobald diese eintreffen und verifiziert sind •unregisterListener: Entfernt einen zuvor registrierten ContractsListener Ein ContractsListener hat folgende Methoden zu implementieren: •onContractReceived: Wird aufgerufen, wenn ein neuer Vertrag eingegangen ist •onSignatureReceived: Wird aufgerufen, wenn eine neue Unterschrift eingegangen ist Abbildung 1: UML-Klassendiagramm SharkContracts Abschnitt 3 Konzeption von SharkContracts 12 Die beiden Methoden werden nur aufgerufen, wenn externe Verträge und Unterschriften eingegangen sind und nicht, wenn sie von dieser SharkContracts-Instanz erzeugt werden wie etwa mit createContract(). 3.2.3 Persistenz SharkContracts liefert Methoden nach außen, die auf bekannte Verträge und Unterschriften zurückgreifen, wie z.B. listContracts(). Außerdem muss die Bibliothek Unterschriften und Verträge zueinander zuordnen können, z.B. um zu prüfen, ob ein Vertrag von allen Parteien unterschrieben wurde in isSignedByAllParties(). Diese Funktionalitäten brauchen daher Zugriff zu einer Datenpersistenz, wo die bekannten Datenobjekte abgelegt sind. Da SharkContracts aber in verschiedenen Umgebungen funktionieren soll, wird die Persistenz als Interface definiert und nicht in SharkContracts selbst implementiert. In Abbildung 3 sieht man eine Übersicht mit den notwendigen Methoden. Bei der Initialisierung von SharkContracts muss dann eine Instanz von ContractStorage mitgegeben werden. Abbildung 2: UML-Klassendiagramm ContractsListener Abschnitt 3 Konzeption von SharkContracts 13 3.3 Protokoll zum Aushandeln der Verträge ASAP arbeitet mit Datenpaketen, die von Peer zu Peer weitergetragen werden. Wenn sich zwei Peers treffen, synchronisieren die beiden ihre bekannten Datenpakete. Das Protokoll zum Erstellen eines Vertrags sieht so aus: Alice erstellt einen Vertrag mit folgenden Informationen: Sender, Inhalt, die anderen Vertragsparteien und Signatur. Der Vertrag wird signiert und über ASAP als Message/Datenpaket veröffentlicht. Die anderen Vertragsparteien können anschließend den Vertrag unterschreiben, indem sie eine Unterschrift erstellen, die folgendes enthält: Hash des Vertrags als Referenz und die eigene Signatur. Die Unterschrift wird dann über ASAP veröffentlicht und kann durch den Vertrags-Hash eindeutig dem Vertrag zugeordnet werden. Da die unterschreibende Partei bereits über den Vertrag Bescheid weiß, wird sie neuen Peers neben der Unterschrift immer auch den Vertrag selbst über ASAP weitertragen. Die weiteren beteiligten Vertragsparteien werden in einer Liste im Vertrag gespeichert. Dabei handelt es sich um alle Parteien bis auf den Autor selbst. Die Signatur des Autors unter dem Vertrag gilt gleichzeitig als dessen Unterschrift. Die Anzahl der zusätzlichen Vertragsparteien ist dabei beliebig und wenn die Liste leer ist, handelt sich es um einen unilateralen Vertrag, der keine weitere Zustimmung benötigt und von sich aus mit der Signatur des Autors gültig ist. Ansonsten wird ein Vertrag als gültig angesehen, sobald die Unterschriften aller Parteien vorliegen. Ein alternativer Ansatz wäre, dass man erst eine Vertragsanfrage sendet, die dann unterschrieben zurückgesendet wird. Davon wurde jedoch abgesehen, da über ASAP gesendete Datenpakete unveränderbar sind. Außerdem muss bei dem gewählten Ansatz der Vertragsinhalt nur einmal gesendet werden. Abbildung 3: Übersicht ContractStorage Abschnitt 3 Konzeption von SharkContracts 14 In Abbildung 4 wird der Ablauf einer Vertragserstellung und Unterschrift gezeigt, sodass beide Parteien am Ende einen unterschriebenen Vertrag vorliegen haben. Die Darstellung ist vereinfacht, soll aber vor allem den Ablauf und das Zusammenspiel zwischen Anwender, SharkContracts und den ASAP-Bibliotheken verdeutlichen. Anfangs erzeugt Alice einen neuen Vertrag mit dem Aufruf von createContract(). SharkContracts erstellt den Vertrag und sendet ihn als ASAP-Nachricht. Im Vertrag ist vermerkt, dass auch Bob unterschreiben muss, damit dieser gültig ist. Wenn die Nachricht im ASAPPeer von Bob angekommen ist, wird SharkContracts über die neue Nachricht informiert. Dort wird außerdem verifiziert, dass der Vertrag von Alice stammt und der Inhalt entschlüsselt, falls dieser verschlüsselt übertragen wurde. Nun wird Bob über die Listener-Methode onContractReceived() über den neuen Vertrag informiert. Bob kann nun entscheiden, ob er den Vertrag unterschreiben möchte. In diesem Fall tut er dies und ruft signContract() auf, was in SharkContracts wieder dafür sorgt, dass eine ASAP-Nachricht gesendet wird. So gelangt die Unterschrift schließlich zu Alice auf gleichem Wege, wie der Vertrag zu Bob gelangte. Bob kann nun zusätzlich die Unterschrift verifizieren oder prüfen, ob alle Unterschriften für den Vertrag vorliegen, um zu bestimmen, ob der Vertrag gültig ist. Das Verifizieren von Verträgen und Unterschriften vom Anwender ist nicht unbedingt notwendig, da SharkContracts dies intern schon beim Empfang tut und ungültige Daten verwirft. Falls dem AnAbbildung 4: Sequenzdiagramm Vertrag unterschreiben mit zwei Parteien Abschnitt 3 Konzeption von SharkContracts 15 wender jedoch ein Vertrag auf anderem Wege bekannt wurde, kann der Vertrag mit verifyContract() verifiziert werden. Wie dieser Ablauf praktisch in Programmcode aussieht, wird in Abschnitt 4.1.7 Tests gezeigt. 3.4 Datenstrukturen Da das Protokoll zum Aushandeln von Verträgen im Grunde nur aus dem Senden der Verträge und Unterschriften besteht, müssen alle Informationen dazu in den beiden Datentypen „Vertrag“ und „Unterschrift“ vorliegen. Bei einem Papier-Vertrag stehen auf dem einen Dokument alle Informationen: Inhalt, Parteien und deren Unterschriften. Alles in der Gesamtheit bildet den „Vertrag“. In SharkContracts ist das aufgrund technischer Gegebenheiten anders. Der „Vertrag“ enthält unter anderem den Inhalt, Parteien und die Unterschrift des Autors. Weitere „Unterschriften“ sind als getrennte Datensätze vorhanden, aber beziehen sich eindeutig auf einen Vertrag durch dessen Hash-Wert. 3.4.1 Vertrag Der Vertrag enthält folgende Informationen: •Autor: ID des Vertragsautors •Inhalt: frei wählbarer Inhalt des Vertrags •weitere Vertragsparteien: eine Liste aller zusätzlichen Vertragsparteien neben dem Vertragsautor selbst. Bei verschlüsselten Verträgen wird zu jeder Partei auch der verschlüsselte Schlüssel hinterlegt. •Verschlüsselung: Information darüber, ob ein Vertrag verschlüsselt ist •Hash: Ein Hash des Vertrags: das sind alle obigen Informationen zusammen (Autor, Inhalt, ASAP-IDs der anderen Parteien). Der Hash ist wichtig zur Identifikation des Vertrags •Signatur: der Hash wird mit dem privaten Schlüssel des Autors signiert, um die Echtheit des Vertrags zu beweisen und gilt außerdem als eigene Unterschrift des Autors für den Vertrag Abschnitt 3 Konzeption von SharkContracts 16 3.4.2 Unterschrift Eine Unterschrift wird von den zusätzlichen Vertragsparteien eines Vertrags erzeugt und enthält: •Autor: ID der unterschreibenden Partei •Hash des Vertrags: Referenz zum Vertrag, der unterschrieben wird •Signatur: signiert Autor und Hash mit dem privaten Schlüssel der unterschreibenden Partei, um die Echtheit der Unterschrift zu beweisen 3.4.3 Signaturen In Abbildung 7 kann wird verdeutlicht, wie die Signaturen von Vertrag und Unterschrift gebildet werden und von welchen anderen Werten sie abhängen. Der Hash eines Vertrags wird aus Autor, unverschlüsseltem Inhalt und den IDs der beteiligten Vertragsparteien gebildet. Die Signatur wird mit diesem Hash und dem privaten Schlüssel des Autors erzeugt. Abbildung 5: UML-Klassendiagramm Contract und ContractParty Abbildung 6: UML-Klassendiagramm ContractSignature Abschnitt 3 Konzeption von SharkContracts 17 Eine Unterschrift enthält unter anderem den Hash des Vertrags, den sie unterschreibt. Dies ist wichtig, damit die Unterschrift eindeutig einem Vertrag zugeordnet werden kann und dieser original ist. Die Signatur der Unterschrift wird mit dem Autor und Hash des Vertrags gebildet. Wenn der Inhalt des Vertrags geändert und vom Autor neu unterschrieben würde, wäre der Vertrag zwar valide, aber hätte einen neuen Hash und der veränderte Vertrag wäre damit ein neuer Vertrag. Bisher getätigte Unterschriften würde nur für den alten, unveränderten Vertrag gelten, denn sie enthalten dessen Hash. Damit das Konstrukt funktioniert, müssen die IDs den richtigen Identitäten zugeordnet werden können. D.h., dass die richtigen öffentlichen Schlüssel der beteiligen Vertragsparteien untereinander bekannt sein müssen, damit Verträge und Unterschriften richtig verifiziert werden können. Die öffentlichen Schlüssel sind nämlich nicht in den Verträgen und Unterschriften selbst vorhanden. Dort sind nur die mit den Schlüsseln erzeugten Signaturen. 3.5 Verund Entschlüsselung Informationssicherheit (siehe 2.3.1 Informationssicherheit) schließt unter anderem auch die Vertraulichkeit ein. Um diese zu gewährleisten, soll es möglich sein, die Vertragsinhalte zu verschlüsseln. Dazu wird der Inhalt mittels eines zufälligen synchronen Schlüssels verschlüsselt. Damit die anderen Vertragsparteien den Vertrag entschlüsseln können, wird der synchrone Schlüssel für jede Vertragspartei mittels asynchroner Verschlüsselung verschlüsselt. Dabei werden deren bekannte öffentliche Schlüssel genutzt. Der Ablauf ist in Abbildung 8 schematisch dargestellt. Abbildung 7: Übersicht Hashes, Signaturen und deren Abhängigkeiten Abschnitt 3 Konzeption von SharkContracts 18 Im Vertrag wird dann ein Flag gesetzt, um anzuzeigen, dass der Inhalt verschlüsselt ist und bei Empfang erst wieder in Klartext umgewandelt werden muss. Zusätzlich wird im Vertrag für jede Partei der verschlüsselte AES-Key hinterlegt. Um den Vertrag wieder entschlüsseln zu können, zieht sich der Empfänger den verschlüsselten AES-Key heran und entschlüsselt diesen mit dem eigenen privaten Schlüssel, sodass nun der AESKey bekannt ist. Diesen kann der Empfänger nutzen, um den synchron verschlüsselten Inhalt zu entschlüsseln. Der Ablauf ist in Abbildung 9 schematisch dargestellt. 3.6 ContractContents Ein Merkmal eines Vertrages allgemein und auch bei Verträgen in SharkContracts ist die Formfreiheit des Inhalts. Das bedeutet, dass die Bibliothek der Anwendung erlaubt, jegliche Form von Daten als Inhalt zu verwenden, solange dieser zu einem Byte-Array serialisierbar ist. Da digitale Verträge aber den Vorteil haben, von Computern automatisiert verarbeitet werden zu können, stellt eine zweite Komponente namens „ContractContents“ ein Werkzeug bereit, um Vertragsinhalte einfacher programmatisch verarbeiten zu können. D.h. insbesondere wird dadurch eine Vorgehensweise geschaffen, um Vertragsformen zu definieren und diese einfach zu serialisieren/deserialisieren. Abbildung 8: Schema Vertrags-Verschlüsselung Abbildung 9: Schema Vertrags-Entschlüsselung Abschnitt 3 Konzeption von SharkContracts 19 Die Komponente stellt dabei ein Interface zur Verfügung, wie in Abbildung 10 dargestellt. Hier ist eine kurze Übersicht der Methoden: •extract: Diese beiden Methoden lesen die Daten aus einem Vertragsinhalt/Byte-Array und deserialisieren sie zu einem ContentPackage, was unten näher erläutert wird. •pack: Serialisiert einen Vertragsinhalt zu einem Byte-Array, der dann in einem Vertrag genutzt werden kann. •registerType: Informiert ContractContents über einen neuen Vertragsinhalts-Typ, der dann später zur Serialisierung verfügbar ist. ContractPackage enthält hierbei die Metadaten zum Inhalt und den Inhalt selbst, wie in Abbildung 11 zu sehen. ContractContent kann dabei jede mögliche Klasse sein, die von ContractContent erbt und als einfaches Data Transfer Object [18] formuliert ist, also einen öffentlichen Konstruktor mit allen Parametern und öffentlichen Gettern enthält. Das ist wichtig für die automatische Serialisierung. In Abbildung 12 sind zwei Beispiele dafür zu sehen, die auch in der Bibliothek vorgegeben sind. Abbildung 10: Übersicht ContractContents Abbildung 11: Übersicht ContractPackage Abschnitt 4 Implementierung 26 4.1.6 Persistenz SharkContracts implementiert selbst nicht die Persistenz, die in Endanwendungen genutzt werden sollte, sondern definiert das Interface ContractsStorage (siehe 3.2.3 Persistenz). Zur Initialisierung wird der SharkContractsFactory eine Instanz davon mitgegeben. Um die Entwicklung einer Anwendung zu vereinfachen und für Tests gibt es die Klasse TemporaryInMemoryStorage, die die Persistenz implementiert und die Datenobjekte temporär im RAM in Listen hält. Ein Beispiel einer vollständigen Implementierung findet sich in der Beispiel-App SharkContractsSample im Package persistance. 4.1.7 Tests Im Code-Repository sind diverse Tests zu den verschiedenen Klassen von SharkContracts hinterlegt. In diesem Abschnitt wird der ContractsSignTest genauer erklärt, weil er ein typisches Szenario durchläuft. Es ist das selbe wie das in Abbildung 4 in Abschnitt 3.3 Protokoll zum Aushandeln der Verträge beschriebene. Es besteht aus einem vollständigen Vertragsabschluss zwischen zwei Parteien, hier Alice und Bob genannt. Im ersten Schritt, der in Listing 13 gezeigt ist, werden die ASAPPeers und SharkPeers vorbereitet. Hier wird ASAPTestPeerFS genutzt, das später benötigte Funktionalität bietet, um einen Encounter – also ein Treffen/Austausch – zwischen den Peers zu imitieren. Listing 12: Kommentierter Code zum Verschlüsseln eines Vertrags private Contract encryptContract(Contract contract) throws ASAPSecurityException, NoSuchAlgorithmException { if(contract.isEncrypted()) return contract; // bereits verschlüsselt Log.writeLog(this, "Encrypting contract " + contract.getHash()); // Symmetrischen Schlüssel erzeugen SecretKey secretKey = KeyGenerator.getInstance(SYMMETRIC_ALGORITHM).generateKey(); byte[] keyBytes = secretKey.getEncoded(); // Vertragsinhalt symmetrisch verschlüsseln byte[] encryptedContent = ASAPCryptoAlgorithms.encryptSymmetric( contract.getContent(), secretKey, pki.getASAPKeyStore() ); // Asymmetrische Verschlüsselung für jede Vertragspartei List<ContractParty> parties = new ArrayList<>(); for(ContractParty party : contract.getOtherParties()){ byte[] encryptedKey = ASAPCryptoUtilsExtension.encryptAsymmetric( keyBytes, party.getId(), pki.getASAPKeyStore() ); // Verschlüsselten AES-Schlüssel zugeordnet zur Vertragspartei speichern parties.add(new ContractParty(party.getId(), encryptedKey)); } // Schlussendlich den verschlüsselten Vertrag zurückgeben return new Contract(contract.getAuthorId(), encryptedContent, parties, true, contract.getHash(), contract.getSignature()); } Abschnitt 4 Implementierung 27 Die Methode getPreparedPeer() liefert dabei einen SharkPeer mit den Komponenten SharkPKIComponent und SharkContracts. Außerdem wird in autoAcceptCerts() ein Listener in der SharkPKI erzeugt, der alle eingehenden Credentials akzeptiert. Das ist wichtig, damit sich Alice und Bob in diesem Test „kennenlernen“ können, sich gegenseitig vertrauen und den Public-Key des anderen speichern. Nun sind die Peers vorbereitet. Durch den Aufruf von startEncounter() „treffen“ sich die Peers virtuell über einen Socket und tauschen ihre ASAPMessages aus. Die SharkPKI sorgt automatisch für den Austausch von den Public-Keys der beiden Peers, siehe Listing 14. Im zweiten Schritt wird der Vertrag von Alice erstellt. Dazu wird die ID, mit der Alice Bob sieht, als zweite Vertragspartei eingetragen und es wird spezifiziert, ob der Vertrag verschlüsselt übertragen werden soll. Der Test existiert nämlich in beiden Varianten (verschlüsselt/unverschlüsselt). Zudem wird verifiziert, dass im Vertragsspeicher von Alice zunächst keiner und dann genau ein Vertrag bekannt ist. Im nächsten Schritt wird nach einem weiteren Encounter geprüft, dass Bob den Vertrag erhalten hat. Dieser Vertrag wird von Bob unterschrieben, wie in Listing 15 gezeigt. Listing 14: testContractsSign (2/4) – Vertrag erstellen // Encounter starten, sodass sich beide Parteien gegenseitig kennen aliceASAP.startEncounter(AppTests.getPortNumber(), bobASAP); Thread.sleep(1000); // Vertrag als Alice erstellen List<String> knownPeers = aliceContracts.getKnownPeers(); Assertions.assertEquals(1, knownPeers.size()); Assertions.assertEquals(TestUtils.BOB, knownPeers.get(0)); byte[] testContent = "Hello world!".getBytes(StandardCharsets.UTF_8); Assertions.assertEquals(0, aliceContracts.listContracts().size()); aliceContracts.createContract(testContent, aliceContracts.getKnownPeers(), encrypted); Assertions.assertEquals(1, aliceContracts.listContracts().size()); Listing 13: testContractsSign (1/4) - Initialisierung // ASAP/Shark Setup mit SharkContracts ASAPTestPeerFS aliceASAP = new ASAPTestPeerFS(TestUtils.ALICE, TestUtils.supportedFormats); ASAPTestPeerFS bobASAP = new ASAPTestPeerFS(TestUtils.BOB, TestUtils.supportedFormats); SharkPeer alicePeer = getPreparedPeer(TestUtils.ALICE); SharkPeer bobPeer = getPreparedPeer(TestUtils.BOB); alicePeer.start(aliceASAP); bobPeer.start(bobASAP); SharkContracts aliceContracts = (SharkContracts) alicePeer.getComponent(SharkContracts.class); SharkContracts bobContracts = (SharkContracts) bobPeer.getComponent(SharkContracts.class); SharkPKIComponent alicePKI = (SharkPKIComponent) alicePeer.getComponent(SharkPKIComponent.class); SharkPKIComponent bobPKI = (SharkPKIComponent) bobPeer.getComponent(SharkPKIComponent.class); autoAcceptCerts(alicePKI); autoAcceptCerts(bobPKI); Abschnitt 4 Implementierung 28 Zum Schluss wird ein weiterer Encounter durchgeführt, damit Alice die Unterschrift von Bob bekommt. Geprüft wird unter anderem, ob die Unterschrift angekommen ist, sie gültig ist und ob SharkContracts nun meldet, dass der Vertrag von allen Parteien unterschrieben wurde. Dieser Test beschreibt einen vollständigen Vertragsabschluss. Es wurde festgestellt, dass der Test trotzdem fehlschlägt, wenn bei einem Encounter die Informationen nicht übertragen wurden und das relativ häufig passiert. Um diesem Effekt entgegenzuwirken, wird im realen Test der Encounter mehrmals durchgeführt, um die Wahrscheinlichkeit zu erhöhen, dass die Nachrichten zwischen Alice und Bob ausgetauscht werden. Vermutlich handelt es sich bei diesem Problem um eine RaceCondition [19] innerhalb von ASAPJava, die nur manchmal auftritt und dann verhindert, dass der Nachrichten-Austausch erfolgreich verläuft. 4.2 ContractContents ContractContents nutzt intern die Bibliothek Gson [20], um Vertragsinhalte zu serialisieren. Hier wird kurz die Serialisierung aus ContractContentsImpl.pack() erläutert, die in zwei Schritten erfolgt. Im ersten Schritt wird der Inhalt (Subklasse von ContentContent) mit Gson zu einem JSON serialisiert und außerdem geprüft, ob der Inhalts-Typ bekannt ist. Listing 15: testContractsSign (3/4) – Vertrag unterschreiben // Encounter starten, sodass Bob den Vertrag kennt aliceASAP.startEncounter(AppTests.getPortNumber(), bobASAP); Thread.sleep(1000); // Vertrag mit Bob unterschreiben Assertions.assertEquals(1, bobContracts.listContracts().size()); Contract contract = bobContracts.listContracts().get(0); Assertions.assertArrayEquals(testContent, contract.getContent()); bobContracts.signContract(contract); Listing 16: testContractsSign (4/4) – Vertragsabschluss verifizieren // Encounter starten, sodass Alice die Unterschrift bekommt aliceASAP.startEncounter(AppTests.getPortNumber(), bobASAP); Thread.sleep(1000); // Prüfen, dass Alice die Unterschrift bekommen hat Contract contract2 = aliceContracts.listContracts().get(0); List<ContractSignature> signatures = aliceContracts.listSignatures(contract2); Assertions.assertFalse(signatures.isEmpty()); Assertions.assertTrue(aliceContracts.verifySignature(signatures.get(0))); Assertions.assertTrue(aliceContracts.isSignedByAllParties(contract2)); alicePeer.stop(); bobPeer.stop(); Abschnitt 4 Implementierung 29 Im zweiten Schritt wird der Inhalt zusammen mit den Metadaten – also Typ-Kennung und Zeitstempel – noch einmal zu einem JSON serialisiert. Das Ergebnis bei Ausgabe als String sieht dann z.B. so aus: Der Grund, warum die Serialisierung in zwei Stufen geschieht, liegt darin, dass auf diese Weise bei der Deserialisierung nach der ersten Stufe die Metadaten bekannt sind, bevor letztendlich der Inhalt deserialisiert wird. Die Metadaten sind daher wichtig, weil sie unter anderem die Typ-Kennung enthalten, eine Information, die zur Deserialisierung des Inhalts bekannt sein muss. 4.3 SharkContractsSample Die Beispiel-App wird hier kurz erklärt, aber eher von außen und nicht so ausführlich wie SharkContracts selbst. Um die App elegant zu gestalten und gleichzeitig effizient entwickeln zu können, wurde als UITechnologie Android Jetpack Compose [21] eingesetzt und dazugehörig Kotlin [22] als Sprache. 4.3.1 Screenshots In Abbildung 13 ist ein Screenshot zu sehen, der den ersten App-Start zeigt. Der Benutzer wird dazu aufgefordert, einen einzigartigen Namen zu wählen, der intern als ASAPPeer-ID genutzt wird. Die Übersichtsseite in Abbildung 14 zeigt alle bekannten Verträge und deren Inhalte und Zustände. Auf dem Screenshot sieht man einen Vertrag, der von Alice erzeugt wurde mit dem Titel „Hello Listing 17: ContractContents Serialisierung (1/2) String type = typesReversed.get(content.getClass()); if(type == null) throw new UnknownContentTypeException( "Unknown content class: " + content.getClass().getName() ); String contentJSON = gson.toJson(content); Listing 18: ContractContents Serialisierung (2/2) InternalContentPackage contentPackage = new InternalContentPackage( type, new Date(), contentJSON ); String packageJSON = gson.toJson(contentPackage); return packageJSON.getBytes(StandardCharsets.UTF_8); Listing 19: Serialisierter Vertragsinhalt des Typs text { "type": "text", "date":"2025-01-22T11:15:14.992+0100", "content":"{\"title\":\"Title\",\"text\":\"Test\"}" } Abschnitt 4 Implementierung 30 World“ und der ID „#A6eViU“. Bei der ID handelt es sich um die ersten 6 Zeichen des VertragsHashes. Bob ist rot eingefärbt, da er noch nicht unterschrieben hat, weswegen der Zustand des Vertrags auch mit „Pending“ beschrieben wird. Im Screenshot aus Abbildung 15 sieht man, dass Bob den ersten Vertrag unterschrieben hat. Er ist nun grün markiert und der Vertrags-Zustand hat sich auf „Valid“ geändert. Außerdem ist ein zweiter Vertrag aufgetaucht, der von Bob erstellt wurde. Dieser kann nun durch Klick auf die blaue Schaltfläche unterschrieben werden. 4.3.2 Vertrag erstellen Um einen neuen Vertrag hinzuzufügen, klickt man in der Übersicht oben rechts auf das Plus-Symbol. Man gelangt auf einen neuen Screen, auf dem man Vertragsparteien, Verschlüsselung und Inhalt definieren kann. Die App sucht automatisch andere Peers über Bluetooth. Wenn ein neuer Peer gefunden wurde, tauscht die SharkPKI die Credentials zwischen den Peers aus. Alle bekannten Peers kann man nun als zusätzliche Vertragsparteien wählen, wie in Abbildung 16 zu sehen. Es ist auch möglich, einen Vertrag ohne zusätzliche Parteien zu erstellen. Abbildung 14: Übersicht Abbildung 13: Erster AppStart Abbildung 15: Vertrag unterschreiben Abschnitt 4 Implementierung 31 Hat man mindestens eine weitere Partei ausgewählt, kann man den Inhalt verschlüsseln lassen durch das Anhaken des Kontrollkästchens. Wie in Abbildung 17 gezeigt, kann man darunter einen Titel und Text als Vertrags-Inhalt angeben. Der Inhalt wird intern mit ContractContents als TextContent serialisiert. 4.3.3 Persistenz Um Verträge über App-Starts hinweg zu persistieren, implementiert die SharkContractsSample das Interface ContractStorage mithilfe der Datenbank-Bibliothek Android Room [23] in der Klasse RoomContractStorage. Diese übersetzt die Datenobjekte Contract und ContractSignature in RoomDatenobjekte und kümmert sich um das Speichern und Laden von der lokalen Datenbank. 4.3.4 ASAPAndroid und Modifikation davon Die App nutzt eine modifizierte Version von ASAPAndroid [2], um ASAP-Nachrichten zwischen den Geräten zu übertragen. In diesem Beispiel geschieht diese Übertragung per Bluetooth. Damit die App mit ASAPAndroid richtig funktioniert, musste eine Erweiterung von ASAPAndroid vorgenommen werden, bei der unter anderem Transient-Nachrichten implementiert wurden. Dies Abbildung 16: Vertrag erstellen – Parteien wählen Abbildung 17: Vertrag erstellen – Inhalt definieren Abschnitt 4 Implementierung 32 sind ASAP-Nachrichten, die nicht dauerhaft gespeichert und an dritte weitergetragen werden, sondern nur von einem Peer zum nächsten übertragen werden. Sie werden dort sofort verarbeitet und dann gelöscht. Die aktuelle Version von ASAPAndroid unterstützt diese Art von ASAP-Nachrichten nicht, werden aber von der SharkPKI gebraucht, um die Credentials wie z.B. Public-Keys zwischen den Geräten auszutauschen. Abschnitt 5 Bewertung der Ergebnisse 33 5 Bewertung der Ergebnisse In diesem letzten Abschnitt soll die Arbeit noch einmal zusammenfassend beleuchtet werden. 5.1 Zusammenfassung Im Zuge dieser Arbeit wurde SharkContracts entwickelt: eine Bibliothek, die das Erstellen und Unterschreiben von Verträgen in P2P-Netzwerken mit ASAP ermöglicht. Die Android-Anwendung SharkContractsSample zeigt, dass die Bibliothek in praktischen Anwendungen dafür eingesetzt werden kann. 5.2 Mögliche Attacken SharkContracts versucht die im Abschnitt 2.3.1 Informationssicherheit genannten Faktoren zur Informationssicherheit möglichst umzusetzen. In diesem kritischen Blick auf die Arbeit wird versucht, mögliche Angriffsflächen aufzuzeigen. 5.2.1 Nachahmung Authentizität ist ein Faktor der Informationssicherheit, bei dem es darum geht, dass man mit den richtigen Personen kommuniziert bzw. dass die Personen, mit denen man kommuniziert, auch die Personen sind, für die sie sich ausgeben. Um diese Sicherheit kümmert sich SharkContracts nicht und gibt das Problem damit an die Anwendung weiter, die die Bibliothek verwendet. Konkret bedeutet es, dass SharkContracts nicht sicherstellt, dass die sichtbaren IDs den richtigen Public-Keys zugeordnet werden. Z.B. gibt es ein Netzwerk mit den Teilnehmern Alice und Bob, die jeweils ein Schlüsselpaar mit Privateund Public-Key besitzen. Nun kommt aber Mallory dazu, bevor Alice und Bob gegenseitig ihre Public-Keys ausgetauscht haben. Mallory kommuniziert mit Alice, gibt sich aber als Bob aus und sendet ihr ihren Public-Key. Wenn Alice diesen Public-Key ohne zusätzliche Überprüfung akzeptiert, kann Mallory permanent verschlüsselte Nachrichten von Alice an Bob entschlüsseln und sich vor Alice als Bob ausgeben. Damit wäre die gesamte Verschlüsselung und Signierung hinfällig, auf der SharkContracts aufbaut. Um dieses Problem zu lösen, muss eine Anwendung Optionen zur Verifizierung von Identitäten anbieten. 5.2.2 Lauschangriff Eine weitere Angriffsfläche bilden Lauschangriffe. Sie sind weniger kritisch, können aber dennoch problematisch sein, wenn dadurch Informationen bekannt werden, die geheim gehalten werden sollen. In SharkContracts wird ausschließlich der Vertrags-Inhalt verschlüsselt. Dies ist vermutlich Abschnitt 5 Bewertung der Ergebnisse 34 meist die interessanteste Information, aber auch die anfallenden Metadaten können genutzt werden, um vertrauliche Informationen zu erhalten. Z.B. Informationen darüber, wie oft wer mit welchen anderen Personen Verträge abschließt – also Kontaktinformationen. Durch die Länge des verschlüsselten Inhalts könnte man eventuell auch auf den verwendeten Vertragstypen schließen. Mögliche Lösungen für das Problem wären die Verschlüsselung von sensitiven Metadaten und die Einführung eines Paddings. Padding bedeutet, dass Nachrichten um zufällige Daten mit zufälliger Länge ergänzt werden, die es einem Lauscher schwieriger machen, die Daten über die Länge zu interpretieren. 5.2.3 Nicht unterschriebene Verträge Noch ein Problem stellen Vertragsanfragen dar, die nicht direkt unterschrieben werden. Z.B. könnte eine böswillige Person bei einem Tauschhandel einen Vertrag absichtlich nicht unterschreiben, um eine Forderung nicht sofort erfüllen zu müssen. Einige Zeit später unterschreibt diese Person plötzlich doch und die Forderungen im Vertrag werden gültig, obwohl die andere Partei längst nicht mehr damit rechnet. Dieses Problem gibt es auch im normalen Rechtsverkehr, wenn z.B. Verträge über E-Mail geschlossen werden. SharkContracts stellt zwar eine Infrastruktur zum Vertragsabschluss bereit, löst dieses Problem aber nicht und es sollte bei Verwendung der Bibliothek beachtet werden. Im Rechtsverkehr wird dieses Problem dadurch abgemildert, indem Vertragsanträge bei abwesenden Parteien laut BGB §147 „nur bis zu dem Zeitpunkt angenommen werden [können], in welchem der Antragende den Eingang der Antwort unter regelmäßigen Umständen erwarten darf“ [24]. Im Kontext von digitalen Verträgen könnte man eine Annahmefrist bestimmen, die die Annahme zeitlich einschränkt, jedoch können aufgrund der asynchronen Kommunikation in einem Ad-hoc P2PNetzwerk Erstellungszeiten von Paketen leicht gefälscht werden. Eine Fälschung kann auch nicht nachgewiesen werden, da es keine Autorität gibt, die Zeitstempel verifizieren könnte. Da solche Fristen das Problem in P2P-Netzwerken nicht löschen, wurde in dieser Arbeit auch von Implementierung dieser Lösung abgesehen. 5.2.4 Implementierungsfehler Eine letzte Angriffsfläche sind Implementierungsfehler, mit denen man vor allem die Funktion und Stabilität der Software angreifen kann. Ein Beispiel dafür wäre eine Attacke auf die Serialisierung, bei der Byte-Arrays verwendet werden, die eine definierte Länge haben. Ein Angreifer könnte nun Pakete schicken, die eine sehr lange definierte Länge haben und somit versuchen, dass das Pro- Abschnitt 5 Bewertung der Ergebnisse 35 gramm sehr viel Speicher alloziert und schlussendlich abstürzt. Eine Implementierung, die im Produktiv-Betrieb eingesetzt werden soll, müsste auf solche Lücken geprüft werden und es müssten entsprechende Gegenmaßnahmen in die Bibliothek aufgenommen werden. 5.3 Mögliche Anwendungen und Ausblick SharkContracts wurde als Bibliothek gebaut, um in anderen Anwendungen verwendet zu werden. In diesem Abschnitt sollen kurz ein paar mögliche Anwendungen beschrieben werden, die man damit als Grundlage entwickeln könnte. Mit der Nutzung von ASAP zur Informationsübermittlung würden diese Anwendungen kein Internet benötigen, um zu funktionieren. Eine mögliche Anwendung wäre z.B. Paketlieferung mit Drohnen. Dabei treffen sich die Drohne und ein Gerät des Empfängers, das dann den Erhalt des Pakets unterschreiben kann. Außerdem könnte man Zug-basierte Spiele wie „Schach“ damit realisieren, wobei jeder Zug durch einen Vertrag abgebildet wird. Durch das Weitertragen von Paketen können sogar Spieler miteinander interagieren, die sich nicht direkt treffen. Eine weitere Möglichkeit, SharkContracts zu verwenden, wären Schuldverschreibungen oder sog. Bonds. Das sind Verträge die ein Schuldverhältnis mit Schuldner und Gläubiger definieren. Ein weiterer Vertragstyp könnte aussagen, dass eine bisherige Schuld aufgelöst wird. Dabei würde der ursprüngliche Schuldvertrag im Auflösungsvertrag referenziert werden. Das kann man noch erweitern mit zusätzlichen Vertragstypen, die z.B. das Anrecht des Gläubigers auf Begleichung der Schuld an andere Personen übertragen und somit eine Art Geldsystem aufbauen, wobei Wert aus der Schuld geschöpft wird. Ein Geldsystem könnte man mit SharkContracts auch so aufbauen, indem jemand einen initialen Geldbetrag durch einen Vertrag erzeugt und diesen ähnlich wie bei einem Blockchain-Bezahlsystem transferieren kann, indem jede Transaktion durch einen signierten Vertrag dargestellt wird.