-
Die vorliegende Erfindung betrifft ein Verfahren zum Bereitstellen eines Zustandskanals (sog. state channel) sowie ein Rechensystem, ein Netzwerk und ein Computerprogramm zu dessen Durchführung.
-
Hintergrund der Erfindung
-
Der Begriff „Distributed-Ledger-Technologie“ bezeichnet eine Form von Datenbanksystemen, welche sich durch gemeinsame und synchronisierte Datenhaltung in einem Peer-to-peer-Netzwerk sowie fortlaufende, kryptografische Verkettung der Daten auszeichnen. Blockchain stellt eine konkrete Ausgestaltungsform dieser Technologie dar. Andere Ausgestaltungsformen sind bspw. gerichtete, azyklische Graphen. Die Informationen werden dabei in Blöcken gespeichert („Block“), über kryptografische Methoden miteinander verkettet („Chain“) und in jedem Knoten des Netzwerks mittels Peer-to-peer-Protokollen redundant gespeichert, d. h., bei jedem Teilnehmer am Netzwerk liegen dieselben Informationen bzw. Daten vor. Das verteilte Netzwerk unabhängiger Rechner (Knoten), die dafür miteinander kommunizieren und sich synchronisieren, verifiziert und bestätigt diese Blöcke über einen sogenannten Konsensmechanismus. Der derzeit gebräuchlichste Konsensmechanismus, der in der Bitcoin- und Ethereum-Blockchain verwendet wird, wird als „Proof of Work“ bezeichnet. Daneben existieren mittlerweile mehrere alternative Konsensmechanismen, die jeweils abhängig von der spezifischen Ausgestaltung des DLT-Netzwerks gewisse Vor- und Nachteile mit sich bringen.
-
Zudem bieten DLT-Lösungen der zweiten Generation meist die Möglichkeit, sogenannte „Smart Contracts“ zu definieren und zu nutzen. Als Smart Contracts wird Programmcode bezeichnet, der in die DLT geschrieben und entsprechend von allen Teilnehmern am DLT-Netzwerk redundant bzw. verifizierbar ausgeführt werden kann. Dadurch können DLT nicht nur zur sicheren Speicherung von Daten genutzt werden, sondern darüber hinaus Geschäftslogiken abbilden und ausführen. Mit Hilfe von sog. „State Channels“, hierbei handelt es sich um (sichere) Kommunikationsverbindungen, ist es möglich, solche „Smart Contracts“ ohne Kommunikation mit einer betreffenden Datenbasis („Ledger“) auszuführen und trotzdem die zugesicherten Eigenschaften zu behalten. Sobald ein „State Channel“ erstellt bzw. hergestellt ist, können „Smart Contracts“ effizient (bestenfalls sogar in Echtzeit) zwischen den erstellenden Parteien geschlossen und ausgeführt werden.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Bereitstellen eines Zustandskanals sowie ein Rechensystem, ein Netzwerk und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
-
Die Erfindung beschäftigt sich mit dem Bereitstellen eines Zustandskanals und darüber einer sicheren Kommunikationsverbindung, insbesondere eines eingangs erwähnten „State Channels“, zwischen einer ersten Entität und einer zweiten Entität in einem (z.B. dezentralen) Netzwerk zum Austauschen von Nachrichten betreffend Transaktionen einer Distributed-Ledger-Technologie unter Verwendung eines Peer-to-Peer-Protokolls für dezentrale Kennungen, insbesondere gemäß einem SSI-Mechanismus („Self-Sovereign Identity“).
-
In anderen Worten kann vom „State Channel“ als einem Zustandskanal gesprochen werden, der einen Austausch von Nachrichten enthaltend Zustände bzw. Zustände charakterisierende Informationen zwischen wenigstens zwei Parteien bzw. Entitäten ermöglicht insbesondere ohne Verwendung eines bzw. des DLT-Systems. Der „State Channel“ ist eine logische Verbindung, welche als technische Verbindung den SSI-Kanal verwendet. Daher können über den Zustandskanal vergleichsweise schnell unterschiedliche Zustände bzw. entsprechende Informationen ausgetauscht werden, ohne dass hierfür entsprechende Transaktionen des DLT-Systems erforderlich sind. Daher können die über den Zustandskanal ausgeführten Transaktionen auch als „off-chain“-Transaktionen bezeichnet werden. Es werden z.B. neue Statusaktualisierungen ausgetauscht; z.B. im Falle eines Payment-Channels ist dies die digitale Buchführung.
-
Inspiriert durch DLT sind dezentralisierte Lösungen für digitale Kennungen oder Identitäten entwickelt worden einschließlich wichtiger Standards wie sog. „Verifiable Credentials“ (VC) und sog. „Decentralized Identifiers“ (DID, hierbei handelt es sich um dezentrale Kennungen). Diese Technologien können unter dem Begriff SSI („Self-Sovereign Identity“) subsummiert. Hauptcharakteristikum eines SSI ist ein durch Kryptographie mit öffentlichen und privaten Schlüsseln abgesicherter Peer-to-Peer-Ansatz, was einen Paradigmenwechsel weg von einem Nutzerkontenansatz mit zentralisierten oder föderierten Identitätsmodell darstellt.
-
Bei den vorhandenen dezentralen Kennungen kann es sich insbesondere um „Decentralized Identifiers“ (DID) handeln, die Eigenschaften und Schnittstellen enthalten, insbesondere von sog. SSI-Agenten. Dieser fungiert dabei z.B. als Treuhänder einer Entität (bzw. eines Inhabers einer Kennung bzw. Identität), enthalt z.B. kryptographische Schlüssel, die die delegierte Autorisierung verkörpern und interagiert z.B. mit geeigneten Protokollen. Nachfolgend soll die Erfindung auch anhand dieser speziellen Art von Kommunikationsverbindung, dezentralen Kennung und Netzwerk beispielhaft näher erläutert werden.
-
Bei den Entitäten kann es sich z.B. um Rechensysteme oder Recheneinheiten wie Computer handeln, aber auch solche, die Geräte im Rahmen des Internets der Dinge (loT) zugeordnet sind. Die Kommunikation im (dezentralen) Netzwerk erfolgt mit einer Kommunikationsschnittstelle z.B. über Transport-Layer wie Bluetooth, WLAN, NFC, E-Mail oder sonstige geeignete Protokolle.
-
Im Rahmen der vorliegenden Erfindung werden gemäß einem Peer-to-Peer-Protokoll für dezentrale Kennungen für die erste und die zweite Entität jeweils eine neue dezentrale Kennung als Teilnehmerkennung und ein öffentlicher Schlüssel für die jeweilige Teilnehmerkennung zwischen der ersten und zweiten Entität ausgetauscht. Die Teilnehmerkennungen und die öffentlichen Schlüssel sind dabei bevorzugt jeweils Bestandteil eines Datensatzes für die dezentrale Kommunikation, die z.B. die jeweilige Entität kennzeichnen und bei dem es sich z.B. um ein sog. „DID Document“ handeln kann, und werden insbesondere auch ausgetauscht, indem die betreffenden Datensätze ausgetauscht werden. Mittels der Teilnehmerkennungen und der öffentlichen Schlüssel wird dann der Austausch von Nachrichten enthaltend Zustände charakterisierende Informationen zwischen der ersten und der zweiten Entität abgesichert, was dann komplett verschlüsselt abläuft.
-
Als Peer-to-Peer-Protokoll kommt hier insbesondere die sog. „Peer DID Method“ in Betracht, einem Protokoll, das auf den erwähnten DID aufbaut und speziell für die Peer-to-Peer-Kommunikation zwischen zwei Entitäten, also ohne Zwischenschaltung einer anderen oder zentralen Instanz, vorgesehen ist. Jeder Teilnehmer - im vorliegenden Fall die erste und die zweite Entität - sollen dann auch nach den Regeln dieses Protokolls vorgehen. In diesem Zusammenhang kann von dem Datensatz dann auch als „DID:peer Document“ gesprochen werden.
-
Insbesondere gemäß der „Peer DID Method“, aber auch allgemein bei einem Peer-to-Peer-Protokoll, kann zunächst von der ersten Entität eine (zunächst noch unverschlüsselte) Einladung zum Bereitstellen eines Zustandskanals bzw. einer Kommunikationsverbindung an die zweite Entität gestellt werden. Die zweite Entität sendet daraufhin eine - dann verschlüsselte - Verbindungsanfrage, z.B. umfassend den vorstehend erwähnten Datensatz für die zweite Entität, an die erste Entität. Die erste Entität wiederum sendet dann eine Verbindungsannahme als Antwort hierauf, z.B. umfassend den vorstehend erwähnten Datensatz für die erste Entität. Als Teilnehmerkennung kann hierbei jeweils der zugehörige öffentliche Schlüssel verwendet werden.
-
Auf diese Weise können sich die Entitäten auf eine sichere Kommunikationsverbindung, insbesondere mit einer bestimmten Kennung, z.B. eine sog. „State Channel ID“ (SCID), einigen und dabei z.B. den initialen State erstellen. Der initiale State enthält insbesondere die Ausgangssituation bei einem State Channel, z.B. bei einem Payment Channel die initiale Balance über beide Entitäten bzw. Parteien, welche es im „Funding Protocol“ zu erheben gilt. Beide Entitäten führen das entsprechende Einrichtungsprotokoll bzw. „Funding Protocol“ der Kommunikationsverbindung bzw. des „Channels“ aus. Dies kann durchaus unabhängig von der verwendeten SSI-Infrastruktur bzw. dem verwendeten dezentralen Netzwerk sein, da hier eine Kommunikation mit dem verwendeten DLT-Netzwerk benötigt wird.
-
Beide Entitäten können die auf diese Weise etablierte, sichere Kommunikationsverbindung, z.B. den „DID:peer“-Kommunikationskanal nutzen, um mit dem jeweiligen Schlüssel signiere Informationen oder „States“ verschlüsselt austauschen zu können. Hiermit (insbesondere mit dem erwähnten „DID:peer“) kann sichergestellt werden, dass der Inhalt nur von der jeweils anderen Entität entschlüsselt und mit betreffenden Schlüssel validiert werden kann.
-
Der sichere Kommunikationskanal bzw. der „State Channel“ kann, wenn er nicht mehr benötigt wird, z.B. von einer der Entitäten geschlossen bzw. beendet werden, z.B. direkt über die DLT mithilfe eines „Smart Contracts“, gleiches gilt für sog. „Dispute Handling“. Diese Kommunikation findet nicht über den sicheren Kommunikationskanal bzw. das „DID:peer“ zwischen den Entitäten statt.
-
Die vorliegende Erfindung nutzt somit das SSI, das eine dezentrale Basis für Identitäten darstellt, welche somit als sog. „Common Trust Layer“, d.h. als eine Schicht oder Basis für gemeinsame, sichere Kommunikation fungiert, und zwar für verschiedenste Anwendungen. Da über SSI grundsätzlich schon die Möglichkeit besteht, eine sogenannte „permanente Verbindung“ zwischen zwei Entitäten aufzubauen (vgl. hierzu auch „Preukschat, Dreed (2020): Self-Sovereign Identity, Manning“), die kryptographisch abgesichert und eindeutig sind, bieten diese schon „out-of-the-box“ bzw. vorgefertigte Eigenschaften, die für die sichere Kommunikationsverbindung bzw. die sog. „State-Channels“ verwendet werden, wie z.B. eindeutige Teilnehmer-Kennungen. State Channels sind - im Vergleich zu einer permanenten Verbindung - eine logische direkte Verbindung mit der Möglichkeit, Transaktionen direkt zu schicken anstatt über eine DLT. State Channels benötigen einen Transport Layer, in vorliegendem Fall z.B. das DID:Peer von SSI.
-
Zudem sind die SSI-basierten Kommunikationsverbindungen oder Kommunikationskanäle als direkte Verbindung zwischen den Entitäten realisiert, was auch einen Mehrwert für die „State-Channels“ bietet, da diese die bestehende Verbindung nutzen können und somit bereits abgesichert sind. Zudem können über den SSI-Mechanismus schon gewisse Eigenschaften, wie z.B. Privacy, Scaling (vgl. hierzu auch „Daniel Hardman et al (2020): Peer DID Method Specification“) oder auch „Know-Your-Customer“ (KYC), zwischen den Entitäten sichergestellt werden.
-
Gleichzeitig ist durch die spezifische Generierung z.B. einer „DID:peer“ für jede gewünschte Kommunikationsverbindung von außen schwieriger nachvollziehbar, wer mit wem eine sichere Kommunikationsverbindung bzw. einen „State Channel“ unterhält, da die Teilnehmerkennung jeder Verbindung eindeutig ist. Dies stellt eine Art „Key Rotation“ dar. Dieser Mechanismus kann genutzt werden, um den Schutz von Privatsphäre mit durch kryptographische Methoden erreichten Sicherheitsgarantien unter einen Hut zu bekommen. Hierzu können - bisherdedizierte Schlüssel für unterschiedliche Anwendungsszenarien genutzt oder die Schlüssel über die Zeit geändert werden, um eine Verbindung zwischen Schlüssel und Kennung (bzw. Identität) zu verhindern. Man spricht dabei von „Key Rotation“, wenn über die Zeit an definierter Stelle ein neues Schlüsselpaar in einer bestimmten Anwendung genutzt wird.
-
Im Speziellen betrifft die Erfindung also den Ansatz, einen „State Channel“ zwischen einer ersten Entität und einer zweiten Entität unter Verwendung eines Peer-DID-Verfahrens zu etablieren und dann Nachrichten betreffend Transaktionen einer DLT über diesen „State Channel“ auszutauschen. Insbesondere wird dazu eine Schnittstelle zwischen einem „State Channel Framework“ und dem eingesetzten Peer-DID-Verfahren bereitgestellt.
-
Eine solche Schnittstelle setzt sich aus insbesondere zwei Teilen zusammen: einer „Interface integration“, um mit dem SSI-Agent zu kommunizieren, um Nachrichten schicken und empfangen zu können, sowie einer Integration der aktuellen „DID:peer“-Parameter, wie eine eindeutige „public ID“, welche im DID:doc (einer Spezifikation) enthalten ist, für einen State Channel. Diese kann als „Participant ID“ (Teilnehmerkennung) im „State Channel“ verwendet werden. Somit ist sichergestellt, mit wem ein „State Channel“ aufgebaut wird.
-
Über die Schnittstelle werden dann für den „State Channel“ spezifische Nachrichten ausgetauscht, wie z.B. der initiale Zustand (State), welcher auch beschreibt, was jede Partei über eine DLT bereitstellen muss. Zudem können auch neue Zustände (States) ausgetauscht werden, welche entstehen und von beiden Parteien signiert werden müssen.
-
Ein „State Channel Framework“ setzt sich insbesondere aus den Smart Contracts zusammen, welche auf der DLT oder ähnlichem laufen. Diese implementieren das spezifische Protokoll und Abläufe, wie ein „State Channel“ etabliert wird, und decken auch Disput-Fälle usw. ab. Auf der anderen Seite werden die benötigten Parameter spezifiziert, welche einen Status betreffen, der von beiden Parteien signiert werden muss, um als gültig angesehen zu werden.
-
Das „State Channel Framework“ führt die Nachrichten zur DLT aus, um den Kanal zu etablieren. Zudem schickt es benötigte Nachrichten, wie z.B. einen neuen Status, der bestätigt werden muss, an die andere Entität über den „DID:peer“-Kanal.
-
Die Erfindung betrifft auch ein Rechensystem mit Kommunikationsschnittstelle, das eine dezentrale Kennung und Instruktionen zum Handhaben der dezentralen Kennung in einem dezentralen Netzwerk besitzt, das dazu eingerichtet ist, einen Zustandskanal bzw. eine sichere Kommunikationsverbindung mit einem anderen Rechensystem mit Kommunikationsschnittstelle über ein dezentrales Netzwerk bereitzustellen, wobei das andere Rechensystem ebenfalls eine dezentrale Kennung und Instruktionen zum Handhaben der dezentralen Kennung im dezentralen Netzwerk besitzt. Dabei ist das Rechensystem zum Herstellen des Zustandskanals dazu eingerichtet, gemäß einem Peer-to-Peer-Protokoll für dezentrale Kennungen eine neue dezentrale Kennung als Teilnehmerkennung und einen öffentlichen Schlüssel für die Teilnehmerkennung zu erzeugen und an das andere Rechensystem zu übermitteln, und eine dezentrale Kennung als Teilnehmerkennung und einen öffentlichen Schlüssel des anderen Rechensystems zu empfangen, und mittels der Teilnehmerkennung und dem öffentlichen Schlüssel einen Nachrichtenaustausch betreffend den Zustandskanal mit dem anderen Rechensystem abzusichern. Insbesondere kann das Rechensystem dabei sämtliche weitere, von einer der Entitäten gemäß vorstehender Erläuterungen durchgeführte Schritte ausführen.
-
Ein erfindungsgemäßes (dezentrales) Netzwerk umfasst zwei Rechensysteme mit Kommunikationsschnittstelle, und ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
-
Die Erfindung eignet sich zur Bereitstellung einer abgesicherten Kommunikation zwischen zwei Teilnehmern bzw. zur Bereitstellung jeglicher Art von Kommunikationsverbindungen, bei denen ein sicherer Austausch von Nachrichten gewünscht oder nötig ist. Die Erfindung eignet sich auch zur Bereitstellung einer abgesicherten Kommunikation z.B. bei einer ökonomischen Interaktion zwischen Entitäten, bei der eine Bezahlung stattfinden muss.
-
Je nach der Art der Implementierung können notwendige Vorgänge teilweise manuell erfolgen oder automatisiert über einen sog. Agenten, welchem nur mitgeteilt werden muss, mit wem ein Zustandskanal aufgebaut werden soll. Dann wird als erstes das „DID:peer“-Protokoll ausgeführt und dann das übrige „State Channel“-Protokoll. Ein solcher Agent kann in einer beliebigen Recheneinheit als Software implementiert werden, z.B. in einem Steuergerät einer beliebigen Vorrichtung (in einem Smart Device wie z.B. Mobiltelefon, Tablet-PC, in Haushaltsgeräten wie Kühlschränke usw., in Unterhaltungselektronik, aber auch in Maschinen und Anlagen oder Fahrzeugen).
-
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Figurenliste
-
- 1 zeigt schematisch ein Netzwerk, bei dem ein erfindungsgemäßes Verfahren durchführbar ist.
- 2 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.
-
Ausführungsform(en) der Erfindung
-
In 1 ist schematisch ein Netzwerk 100 dargestellt, bei dem ein erfindungsgemäßes Verfahren durchführbar ist und das auch als ein erfindungsgemäßes Netzwerk in bevorzugter Ausführungsform ausgebildet sein kann. Das dezentrale Netzwerk 100 umfasst beispielhaft zwei Rechensysteme 110 und 120, die mittels geeigneter Kommunikationsschnittstellen 111 bzw. 121 und entsprechender Kommunikationsverbindungen 130 in den gesamten Verbund des Netzwerks 100 eingebunden sind. Auch wenn die Rechensysteme 110, 120 hier separat dargestellt sind, gehören sie zum - hier nur schematisch angedeuteten - Netzwerk 100.
-
Bei dem Netzwerk 100 kann es sich um ein sog. DLT-Netzwerk bzw. „Distributed Ledger Technology“-Netzwerk handeln bei den Kommunikationsverbindungen 130 handelt es sich dann entsprechend um DLT-Kommunikationsverbindungen.
-
Die Rechensysteme 110 und 120, die im Sinne der vorliegenden Erfindung als erste Entität 110 und zweite Entität 120 angesehen werden können, besitzen jeweils eine sog. DID als dezentrale Kennung 112 bzw. 122 sowie Instruktionen bzw. einen Agenten 113 bzw. 123 zum Handhaben der jeweiligen dezentralen Kennung im Netzwerk 100, um einen SSI-Mechanismus zu implementieren. Die DID hat hierbei nicht notwendigerweise etwas mit dem zu verwendeten DLT-Netzwerk zu tun; die DID kann in einem Identity Netzwerk verankert werden, was eine DLT sein kann, aber nicht muss. Die gezeigte DLT ist z.B. relevant für die State Channels oder Smart Contracts. Auf den Rechensystemen wird hierzu z.B. jeweils eine geeignete Software ausgeführt, um diese Funktionen bereitstellen bzw. darstellen zu können. Diese Software kann z.B. auch verwendet werden, um ein Peer-to-Peer-Protokoll 115 bzw. 125 ausführen bzw. implementieren zu können.
-
Weiterhin besitzt jedes Rechensystem jeweils einen Datensatz mit zumindest einem öffentlichen Schlüssel 116 bzw. 126 sowie geeigneten „Service Endpoints“ 117 bzw. 127. Hierbei handelt es sich z.B. um eine Netzwerkadresse (z.B. eine HTTP-URL), unter der ein Dienst für die Entität ausgeführt wird.
-
Unter Verwendung dieser Peer-to-Peer-Protokolle 115 bzw. 125 können die Rechensysteme 110 und 120 nun einen Zustandskanal bzw. eine sichere Kommunikationsverbindung 140 bzw. einen sog. „State Channel“ aufbauen bzw. bereitstellen, über die eine direkte und verschlüsselte Kommunikation von Nachrichten betreffend den Zustandskanal möglich ist. Hier wird z.B. das DID:peer-Protokoll ausgeführt, um eine direkte Kommunikation aufzubauen. Wenn diese etabliert ist, wird diese Verbindung als State Channel etabliert, d.h. die für den Zustandskanal relevanten Nachrichten werden über diesen Kanal ausgetauscht.
-
In 2 ist hierzu ein Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform dargestellt, und zwar insbesondere im Hinblick auf das Herstellen der erwähnten sicheren Kommunikationsverbindung bzw. des Zustandskanals. Beispielhaft wird von der ersten Entität bzw. dem Rechensystem 110 eine Einladung 200 an die zweite Entität bzw. das Rechensystem 120 übermittelt, mit dem der Aufbau einer sicheren Kommunikationsverbindung angefragt bzw. gewünscht wird. Diese Einladung kann ungesichert bzw. unverschlüsselt übermittelt werden.
-
Von der zweiten Entität bzw. dem Rechensystem 120 wird, wenn dem Wunsch bzw. der Einladung entsprochen werden soll, eine Verbindungsanfrage 210 an die erste Entität bzw. das Rechensystem 110 übermittelt. Hiermit wird dann insbesondere der Datensatz der zweiten Entität umfassend den öffentlichen Schlüssel, der zugleich als Teilnehmerkennung der zweiten Entität verwendet wird, übermittelt.
-
Die erste Entität bzw. das Rechensystem 110 empfängt diese Verbindungsanfrage 210 und übermittelt daraufhin eine Antwort 220. Hiermit wird dann insbesondere der Datensatz der ersten Entität umfassend den öffentlichen Schlüssel, der zugleich als Teilnehmerkennung der ersten Entität verwendet wird, übermittelt.
-
Auf diese Weise kann die sichere Kommunikationsverbindung hergestellt werden, über die anschließend abgesichert und verschlüsselt kommuniziert werden kann. Hierzu werden dann die betreffenden Schlüssel verwendet, wobei jede Entität ja den öffentlichen Schlüssel der jeweils anderen Entität erhalten hat und damit kennt.
