DE102018002466A1

DE102018002466A1 - Verfahren und Anordnung zum Herstellen einer sicheren Datenübertragungsverbindung

Info

Publication number: DE102018002466A1
Application number: DE102018002466.1A
Authority: DE
Inventors: Leif-Nissen Lundbaek; Michael Reiner Huth; Robert Steiner
Original assignee: Xain AG
Current assignee: Xain AG
Priority date: 2018-03-16
Filing date: 2018-03-16
Publication date: 2019-09-19

Abstract

Ein Verfahren zum Herstellen einer sicheren Datenübertragungsverbindung zwischen einem ersten und einem zweiten Teilnehmer eines Bockchain-Netzwerks oder einem anderen verteilten System (DLT) weist die Schritte auf: Erzeugen von wenigstens zwei Private Keys für den ersten und wenigstens einem Private Key für den zweiten Teilnehmer; Herleiten eines Public Keys für jeden der erzeugten Private Keys; Registrieren des ersten Teilnehmers in wenigstens einem Teilnehmer-Smart Contract des verteilten Systems mit einem Werte Tupel aus wenigstens zwei seiner Public Keys oder die Public Keys repräsentierenden Werten; Austauschen jeweils eines der Public Keys zwischen dem ersten und dem zweiten Teilnehmer; Verifizieren der Registrierung des ersten Teilnehmers in dem Teilnehmer-Smart Contract durch den zweiten Teilnehmer und Zwischenspeichern von wenigstens einem weiteren Wert aus dem zu dem ersten Teilnehmer gehörigen Werte Tupel; Erzeugen eines Datensatzes durch den ersten Teilnehmer; Verschlüsseln des Datensatzes durch den ersten Teilnehmer mit einem der Private Keys des ersten Teilnehmers und dem durch den Austausch erhaltenen Public Key des zweiten Teilnehmers; Übertragen des verschlüsselten Datensatzes an den zweiten Teilnehmer; und Entschlüsseln des Datensatzes durch den zweiten Teilnehmer mit dem zu dem durch Austausch erhaltenen Public Key des zweiten Teilnehmers zugehörigen Private Key des zweiten Teilnehmers und dem zu dem durch Austausch erhaltenen Public Key des ersten Teilnehmers.

Description

Technisches Gebiet
Die Erfindung betrifft ein Verfahren und eine Anordnung zum Herstellen einer sicheren Datenübertragungsverbindung zwischen einem ersten und einem zweiten Teilnehmer eines Bockchain-Netzwerks oder einem anderen verteilten System (DLT).
Stand der Technik
Unter dem Begriff „Blockchain-Technologie“ wird eine Technologie verstanden, bei welcher viele Teilnehmer ein Netzwerk bilden. Die Blockchain ist eine kontinuierlich erweiterbare Liste von Datensätzen, welche mittels kryptographischer Verfahren miteinander verkettet sind. Da jeder Teilnehmer die komplette Kette kennt, ist eine Manipulation von Datensätzen in der Kette praktisch nicht möglich.
Bekannte Verwendungen der Blockchain-Technologie sind Kryptowährungen, wie etwa Bitcoin. Es ist ferner bekannt, die Blockchain-Technologie als Audit-Log für Auditing zu verwenden. Dabei werden sicherheitskritische Operationen von Softwareprozessen aufgezeichnet. Bekannte Auditing-Systeme sind für medizinische Informationen, Verträge, Geldtransaktionen, militärische Geheimnisse, Gesetzgebung, elektronische Stimmabgabe und das Sicherheitsmanagement kritischer Anlagen oder Daten bekannt.
WO 2017/060816 A1 offenbart ein Ressourcen Transfersystem im Finanzbereich. US 2017/0331635 A1 offenbart die Verwendung eines Zeitstempels in einer Blockchain. EP 3 236 401 A1 offenbart einen Authentifizierungsprozess zum Auslösen eines Prozesses. DE102017 107 147 A1 offenbart eine betrugssichere Autorisierung und Authentifizierung für sichere Interaktionen mit Smartphones. GB 2548802A offenbart ein Verfahren zum Verifizieren einer elektronischen Nutzeridentität. DE 10 2016 007 472 A1 offenbart die Verwendung von Blockchain zur Registrierung von Fahrzeugdaten, wie den Kilometerstand, und Sicherung gegen nachträgliche Änderungen.
Typischerweise arbeiten alle Verfahren online, d.h. sie benötigen einen Netzwerkzugang zur Identifizierung.
Offenbarung der Erfindung
Es ist Aufgabe der Erfindung, eine Herstellung einer sicheren Datenübertragungsverbindung zwischen einem ersten und einem zweiten Teilnehmer eines Bockchain-Netzwerks oder einem anderen verteilten System (DLT) auch offline, d.h. ohne Netzwerkzugang zu ermöglichen.
Erfindungsgemäß wird die Aufgabe mit einem Verfahren der eingangs genannten Art gelöst, das gekennzeichnet ist durch die Schritte:

(a) Erzeugen von wenigstens zwei Private Keys für den ersten und wenigstens einem Private Key für den zweiten Teilnehmer;
(b) Herleiten eines Public Keys für jeden der Teilnehmer und eines Public Keys oder eines daraus erzeugten Hashwertes oder anderen Wertes, welcher den Public Key repräsentiert, aus dem zweiten Private Key des ersten Teilnehmers;
(c) Registrieren des ersten Teilnehmers in wenigstens einem Teilnehmer-Smart Contract des verteilten Systems mit einem Werte Tupel aus wenigstens zwei seiner Public Keys oder die Public Keys repräsentierenden Werten;
(d) Austauschen jeweils eines der Public Keys zwischen dem ersten und dem zweiten Teilnehmer;
(e) Verifizieren der Registrierung des ersten Teilnehmers in dem Teilnehmer-Smart Contract durch den zweiten Teilnehmer und Zwischenspeichern von wenigstens einem weiteren Wert aus dem zu dem ersten Teilnehmer gehörigen Werte Tupel;
(f) Erzeugen eines Datensatzes durch den ersten Teilnehmer;
(g) Verschlüsseln des Datensatzes durch den ersten Teilnehmer mit einem der Private Keys des ersten Teilnehmers und dem aus Schritt (d) durch den Austausch erhaltenen Public Key des zweiten Teilnehmers;
(h) Übertragen des in Schritt (g) verschlüsselten Datensatzes an den zweiten Teilnehmer; und
(i) Entschlüsseln des Datensatzes durch den zweiten Teilnehmer mit dem zu dem in Schritt (d) durch Austausch erhaltenen Public Key des zweiten Teilnehmers zugehörigen Private Key des zweiten Teilnehmers und dem zu dem durch in Schritt (d) durch Austausch erhaltenen Public Key des ersten Teilnehmers.

Beispielsweise kann ein erster Teilnehmer ein mobiles Endgerät, etwa ein Mobilfunkendgerät (Smartphone) sein. Es ist aber auch möglich, herkömmliche Computer mit entsprechenden Eigenschaften als ersten Teilnehmer zu verwenden. Der zweite Teilnehmer kann beispielsweise ein Steuergerät oder ein anderer Micro Controller in einem Kraftfahrzeug sein. Es ist aber natürlich auch möglich, beispielsweise ein anderes Fahrzeug zu Wasser, zu Land oder in der Luft, eine Maschine oder ein anderes technisches Gerät mit einem geeigneten Micro Controller als zweiten Teilnehmer zu versehen. Auch herkömmliche Computer sind als zweiter Teilnehmer geeignet.
Ziel des Verfahrens ist es, eine Verbindung zwischen den beiden Teilnehmern herzustellen, die gegenüber Angreifern von außen sicher sind. Die Verbindung kann beispielsweise dazu dienen, dass der erste Teilnehmer Daten aus einem Speicher des zweiten Teilnehmers ausliest, bzw. den zweiten Teilnehmer dazu veranlasst Daten an den ersten Teilnehmer zu übertragen. Die Verbindung kann aber auch zum Steuern des zweiten Teilnehmers mittels eines Steuerbefehls dienen. Ein solcher Steuerbefehl ist beispielsweise das Öffnen und Verschließen des Türschlosses eines Fahrzeugs. Es muss sichergestellt sein, dass kein Dritter unbefugten Zugriff auf das Türschloss des Fahrzeugs erhält.
Es hat sich herausgestellt, dass die Sicherheit üblicher Verschlüsselungen, beispielsweise symmetrischer Verschlüsselungen, bei der Datenübertragung nicht hinreichend sicher sind. Erfindungsgemäß bilden daher die beiden Teilnehmer, zwischen denen eine Verbindung hergestellt werden soll, Teil eines verteilten Systems, auch als DLT (Distributed Ledger Technology) bezeichnet.
Der erste Teilnehmer, der einen Zugriff auf den zweiten Teilnehmer durch Herstellung einer Verbindung erhalten möchte, muss zunächst in einem Smart Contract - hier als „Teilnehmer-Smart Contract“ bezeichnet - in dem verteilten System registriert sein. Mit anderen Worten: der erste Teilnehmer ist in dem Smart Contract, beispielsweise einem Key Value Store, registriert und daher allen Teilnehmern des verteilten Systems bekannt. Zur Registrierung können ein Public Key (öffentlicher Schlüssel) des ersten Teilnehmers oder ein anderer geeigneter Wert, über welchen der erste Teilnehmer eindeutig identifizierbar ist, hinterlegt sein. Ein solcher Wert ist beispielsweise ein zugehöriger Hashwert. Zusätzlich zu dem ersten Wert ist ein weiterer Public Key, beispielsweise eine Adresse des ersten Teilnehmers in dem Teilnehmer-Smart Contract hinterlegt.
Zum Herstellen der Verbindung wird jeweils einer der Public Keys zwischen dem ersten und dem zweiten Teilnehmer ausgetauscht. Mit dem ausgetauschten Public Key des ersten Teilnehmers wird verifiziert, ob dieser in dem Teilnehmer-Smart Contract registriert ist. Falls ja, wird der weitere Public Key in dem Teilnehmer-Smart Contract, auf den der erste Public Key zeigt, zwischengespeichert. Der erste Teilnehmer kann nun einen Datensatz, beispielsweise mit einem Befehl, mit dem zu dem zwischengespeicherten Public Key gehörigen Private Key verschlüsselt an den zweiten Teilnehmer übertragen. Der zweite Teilnehmer kann den Datensatz entsprechend mit dem anderen Public Key des ersten Teilnehmers entschlüsseln. Dabei erfolgt die Verschlüsselung nicht nur mit dem Private Key des ersten Teilnehmers, sondern auch mit dem ausgetauschten Public Key des zweiten Teilnehmers.
Es werden also zwei Schlüsselpaare aus Public und Private Key verwendet. Das eine Schlüsselpaar dient der Verifizierung der Berechtigung mittels Smart Contract und das andere Schlüsselpaar zur verschlüsselten Übertragung des zu übertragenden Datensatzes. Welcher Schlüssel bei der Übertragung zur Entschlüsselung zu verwenden ist, ergibt sich aus dem in dem Teilnehmer-Smart Contract praktisch unmanipulierbar gespeicherten Wertepaar der beiden Public Keys des ersten Teilnehmers.
Die Übertragung kann insbesondere direkt zwischen den Teilnehmern erfolgen und erfordert keine Umwege über Server oder andere Netzwerkteilnehmer. Die Speicherung der Schlüssel, sowohl der Private Keys als auch der Public Keys kann in einem Wallet, beispielsweise HD Wallet bei dem ersten Teilnehmer erfolgen.
Bei einer weiteren Ausgestaltung der Erfindung enthält der übertragene Datensatz wenigstens einen Befehl, der vom zweiten Teilnehmer ausgeführt wird. Dann ist es vorteilhaft, wenn vorgesehen ist, dass

(k) ein oder mehrere Befehle in wenigstens einem Befehls-Smart Contract des verteilten Systems registriert werden,
(l) wenigstens ein ausgewählter Befehl mit dem zu einem zwischengespeicherten Wert des Werte Tupels des Teilnehmer-Smart Contracts gehörigen Private Key des ersten Teilnehmers signiert wird,
(m) der Datensatz den signierten Befehl und den gleichen, unsignierten Befehl umfasst; und
(n) der signierte Befehl mit dem zwischengespeicherten Wert des Werte Tupels des Teilnehmer-Smart Contracts des ersten Teilnehmers in dem Befehls-Smart Contract des verteilten Systems verifiziert und durch den zweiten Teilnehmer ausgeführt wird.

Es kann nicht irgendein Befehl ausgeführt werden, sondern lediglich solche Befehle, die in einem Befehls-Smart Contract des verteilten Systems hinterlegt sind. Der Zugriff auf den zweiten Teilnehmer kann nur durch wohl definierte Befehle erfolgen. Die Authentizität des Befehls wird durch eine Signatur sichergestellt. Die Signatur des Befehls erfolgt mit einem Privat Key des ersten Teilnehmers. Dieser Private Key gehört zu dem Public Key, auf den der ausgetauschte Public Key des ersten Teilnehmers in dem Teilnehmer-Smart Contract zeigt und der nach der Verifizierung zwischengespeichert wurde. Der zwischengespeicherte Wert wird nun zum Entschlüsseln des Datensatzes und zur Authentifizierung des ersten Teilnehmers verwendet. Mit anderen Worten: Die Verschlüsselung und Verifizierung des Datensatzes erfolgt mit einem anderen Schlüssel als die Akkreditierung des Teilnehmers.
Besonders vorteilhaft ist das Verfahren, wenn der Datenaustausch und die Ausführung des Befehls in dem verteilten System propagiert und geloggt wird. Dadurch wird eine nachträgliche Manipulation verhindert.
Bei einer vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die Private Keys eines Teilnehmers aus einem Seed erzeugt werden. Der Teilnehmer braucht nur den Seed-Wert schützen und kann alle Keys falls erforderlich wieder herstellen.
Eine weitere Sicherung des Verfahrens gegen Manipulation und Angriffe erfolgt, wenn

(o) für den zweiten Teilnehmer wenigstens zwei Private Keys und daraus zwei Public Keys erzeugt werden, von denen der erste Teilnehmer einen in Schritt (d) erhält;
(p) der zweite Teilnehmer eine Zufallszahl (nonce) erzeugt,
(q) die Zufallszahl mit einem der Private Keys des zweiten Teilnehmers und dem in Schritt (d) ausgetauschten Public Key des ersten Teilnehmers verschlüsselt wird;
(r) die so verschlüsselte Zufallszahl an den ersten Teilnehmer übertragen wird;
(s) die Zufallszahl vom ersten Teilnehmer entschlüsselt wird mit dem in Schritt (d) ausgetauschten Public Key des zweiten Teilnehmers und dem zu dem in Schritt (d) ausgetauschten Public Key des ersten Teilnehmers gehörigen Private Key des ersten Teilnehmers;
(t) die Zufallszahl in definierter Weise verändert wird;
(u) die so veränderte Zufallszahl dem Datensatz aus (f) beigefügt wird; und
(v) die aus dem entschlüsselten Datensatz von dem zweiten Teilnehmer erhaltene veränderte Zufallszahl mit der Zahl verifiziert wird, die der zweite Teilnehmer selber aus der Zufallszahl durch gleiche Veränderung bestimmt.

Die Veränderung kann beispielsweise die Erhöhung der Zahl um 1 oder einen anderen Wert sein. Es kann aber auch jede beliebige andere Funktion an der Zufallszahl ausgeübt werden. Die Rechnung „Zufallszahl plus eins“ wird bei beiden Teilnehmern unabhängig voneinander durchgeführt. Wenn der Datensatz manipuliert wird, stimmen die Zahlen nicht mehr überein. Nur, wenn auch die veränderte Zufallszahl auf beiden Seiten übereinstimmt, wird die Verbindung aufrecht erhalten und beispielsweise ein Befehl ausgeführt.
Bei einer besonders vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die Übertragung von Daten zwischen den Teilnehmern über eine Bluetooth Low Energy-Verbindung oder auf andere Weise drahtlos erfolgt. Eine Bluetooth Low Energy Verbindung, auch BLE genannt, erfordert wenig Energie, kann aber nur kleine Datenmengen übertragen und ist keine sichere Verbindung. Durch das erfindungsgemäße Verfahren sind diese Nachteile jedoch unerheblich, denn die Sicherheit wird durch die Verschlüsselungen bei beiden Teilnehmern gewährleistet.
Bei der Erfindung kann insbesondere vorgesehen sein, dass das verteilte System eine Serie mit einer Vielzahl von Paaren aus erstem und zweiten Teilnehmer umfasst. Dies kann beispielsweise eine Serie von Kraftfahrzeugen mit zugehörigen Mobilfunkendgeräten sein. Dabei ist es nicht erforderlich, dass alle Kraftfahrzeuge vom gleichen Hersteller sind. Es ist nämlich, anders als bei bekannten Systemen, kein zentraler Server bei einem Hersteller erforderlich. Vielmehr kann jedes Kraftfahrzeug mit geeignet eingerichtetem Micro Controller und Übertragungsgeräten Teil des verteilten Systems werden.
Bei einer weiteren Ausgestaltung der Erfindung ist der Befehl ein Befehl zur Übertragung von gespeicherten Daten. Der zweite Teilnehmer erlaubt also quasi einen Lesezugriff auf die bei ihm gespeicherten Daten. Dies ist insbesondere für die Hersteller interessant, die auf diese Weise ihre Flotte technisch optimieren können. Die Daten sind aber auch beispielsweise im Bereich Carsharing oder Versicherung wichtig.
Bei einer besonders vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die die Public Keys repräsentierenden Werte in dem Teilnehmer-Smart Contract durch einen sha3 oder einen anderen Hashwert gebildet sind. Beispielsweise kann der eine Public Key eines ersten Teilnehmers in Form eines Hashwerts und ein zweiter Public Key als Adresse in einer Key Value Store hinterlegt sein. Bei der Verifizierung des ersten Teilnehmers wird aus dem ausgetauschten Public Key der Hashwert, etwa sha3, gebildet und dieser Hashwert in dem Smart Contract gesucht. Andere, ansonsten nicht beteiligte Teilnehmer des verteilten Systems haben dann keinen Zugang zum Public Key des ersten Teilnehmers. Dadurch wird die Sicherheit gegenüber Angriffen weiter erhöht.
Vorteilhafterweise ist der Teilnehmer-Smart Contract ein Key Value Store. Es ist aber auch jeder andere geeignete Smart Contract möglich.
Besonders vorteilhaft ist es, wenn der weitere Wert in jedem Werte Tupel in dem Teilnehmer-Smart Contract ein Public Key ist, der nicht in Schritt (d) mit dem zweiten Teilnehmer ausgetauscht wurde. Der Public Key kann insbesondere eine Adresse sein. Bei dieser Ausgestaltung zeigt ein sha3 Hashwert auf eine Adresse.
Eine weitere Verbesserung der Sicherheit der Verbindung ergibt sich, wenn vorgesehen ist, dass der Befehl zusammen mit einer Zeit- und/oder Positionsinformation verschlüsselt wird. Dabei kann insbesondere vorgesehen sein, dass der Befehl durch den zweiten Teilnehmer nur ausgeführt wird, wenn die Zeitverzögerung zwischen der mitverschlüsselten Zeitinformation und der Empfangszeit beim zweiten Teilnehmer kleiner als ein Schwellwert ist. Es kann aber auch vorgesehen sein, dass ein Zugriff nur erlaubt ist, wenn die Position des ersten Teilnehmers in einem ausgewählten Bereich liegt.
Die erfindungsgemäße Aufgabe wird ferner gelöst durch ein Blockchain-Netzwerk oder ein anderes verteiltes System (DLT) mit den Merkmalen des Anspruchs 18.
Das verteilte System enthält eine Serie mit einer Vielzahl von Paaren aus einem ersten und zweiten Teilnehmer. Ein Beispiel für eine solche Serie ist eine Kraftfahrzeugflotte und mobile Endgeräte ihrer Eigentümer. Auf den mobilen Endgeräten kann ein Wallet, beispielsweise HD Wallet vorgesehen sein. In dem Wallet werden wenigstens zwei Private Keys und wenigstens zwei zugehörige Public Keys gespeichert. Jeder zweite Teilnehmer weist wenigstens einen Private Key und einen zugehörigen Public Key. In einem Teilnehmer-Smart Contract sind alle ersten Teilnehmer, beispielsweise alle mobilen Endgeräte mit ihren Public Keys hinterlegt. Diese erlauben die Verifizierung der Registrierung eines ersten Teilnehmers in dem Teilnehmer-Smart Contract durch den zweiten Teilnehmer. Jeder zweite Teilnehmer weist geeignete Mittel zum Ausführen eines an ihn übertragenen Befehls auf.
Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche. Ein Ausführungsbeispiel ist nachstehend unter Bezugnahme auf die beigefügten Zeichnungen näher erläutert.
Definitionen
In dieser Beschreibung und in den beigefügten Ansprüchen haben alle Begriffe eine dem Fachmann geläufige Bedeutung, welche der Fachliteratur, Normen und den einschlägigen Internetseiten und Publikationen, insbesondere lexikalischer Art, beispielsweise www.Wikipedia.de, www.wissen.de oder

• „Blockchain Basics, A Non-Technical Introduction in 25 Steps“ von Daniel Drescher, erschienen 2017 bei Apress Frankfurt am Main, ISBN-13(pbk): 978-1-4848-2603-2,
• „Bitcoin, Blockchain und Kryptoassets, Eine umfassende Einführung“ von Aleksander Berentsen und Fabian Schär, Erschienen 2017 bei BoD Norderstedt, Universität Basel, ISBN: 978-3-7386-5392-2

Weiterhin werden hier folgende Bedeutungen für die verwendeten Begriffe zugrunde gelegt:

Wallet	ermöglicht das verschlüsselte Speichern von Informationen, beispielsweise digitaler Währung, Passwörtern oder Bordkarten. Beispiele für Wallets sind „HD Wallet“ von BitGo oder „Wallet“ von Apple.
Seed	ist ein Startwert zur Erzeugung von Schlüsseln zur Verschlüsselung von Daten.
Private Key	ist der geheime Schlüssel bei asymmetrischer Verschlüsselung. Aus einem Private Key lässt sich ein Public Key generieren. Ein mit einem Public Key verschlüsselter Datensatz kann mit dem Private Key entschlüsselt werden. Ein mit dem Private Key verschlüsselter Datensatz kann mit dem Public Key entschlüsselt werden.
Public Key	ist der öffentliche Schlüssel bei asymmetrischer Verschlüsselung. Aus einem Private Key lässt sich ein Public Key generieren. Ein mit einem Public Key verschlüsselter Datensatz kann mit dem Private Key entschlüsselt werden. Ein mit dem Private Key verschlüsselter Datensatz kann mit dem Public Key entschlüsselt werden.
Hashwert	Wert, welcher einen Schlüssel oder einen anderen Wert repräsentiert. Der Hashwert kann aus dem Schlüssel oder Wert, aber der Schlüssel nicht aus dem Hashwert hergeleitet werden. Hashwerte, die nach herkömmlichen Hashverfahren erzeugt werden, können auch gekürzt werden. Diese gekürzten Hashwerte werden hier als Adresse oder ebenfalls als Hashwert bezeichnet.
verteiltes System	basiert auf der Distributed Ledger Technology (DLT) und ist eine Technologie für vernetzte Computer, die zu einer Übereinkunft (Konsensus) über die Reihenfolge von bestimmten Transaktionen kommen und darüber, dass diese Transaktionen Daten aktualisieren. Das verteilte System dient zur Verwaltung von Daten insbesondere im Internet ohne proprietäre Plattform. Ein Beispiel für eine DLT Technologie ist Blockchain.
Bluetooth Low Energy	BLE ist ein Funktechnik, mit der sich Geräte vernetzen lassen. Es hat eine geringere Übertragungsrate und einen erheblich schnelleren Verbindungsaufbau. Ein gesondertes Pairing ist nicht erforderlich.
Verschlüsseln	Überführen eines Datensatzes in einen verschlüsselten Datensatz mit Hilfe eines Schlüssels
Entschlüsseln	Überführung eines verschlüsselten Datensatzes in einen lesbaren Datensatz mit Hilfe eines Schlüssels
Signieren	erzeugen einer Signatur, die durch eine eindeutige Rechenvorschrift zusammen mit einem Datensatz oder einem zuvor ermittelten Hashwert des Datensatzes und dem Private Key berechnet wird. Mit der Signatur kann die Echtheit und/oder Herkunft des Datensatzes verifiziert werden.
Smart Contract	Computerprotokoll, das einen Vertrag abbildet oder überprüft. Ein Beispiel für einen Smart Contract ist ein Key Value Store.
Key Value Store	Schlüssel-Werte-Datenbank ist ein Smart Contract und dient zur elektronischen Datenverwaltung in Computersystemen. Sie basiert auf dem Schlüssel-Werte-Datenmodell um assoziative Datenfelder zu speichern. Im einfachsten Fall ist eine Key Value Store eine zweispaltige Datenbank.
Adresse	Wert, der aus dem Hashwert eines Public Keys durch Kürzen, d.h. Weglassen von Daten erzeugt wurde.

Figurenliste

1 ist eine schematische Übersicht über die Teilnehmer und ihrer Komponenten zwischen denen eine sichere Verbindung aufgebaut wird.
2 illustriert die Schritte zum Aufbau einer sicheren Verbindung zwischen zwei Teilnehmern.
2a illustriert die Verifizierung eines Teilnehmers anhand eines Smart Contracts.
2b illustriert die Verschlüsselung eines zu übertragenden Befehls.
2c illustriert die Entschlüsselung und Ausführung eines übertragenen Befehls.

Beschreibung der Ausführungsbeispiele
1 zeigt ein Ausführungsbeispiel, bei dem ein Smartphone 10 zum Auf- und Zuschließen eines Kraftfahrzeugs verwendet wird. Das Kraftfahrzeug weist einem Single-Board Computer (SBC) 12 auf. Der Single Board Computer 12 besteht im Wesentlichen aus einer Platine, die in einer elektronischen Steuereinheit 14 (ECU) vorgesehen ist. Neben dem Single Board Computer 12 weist die elektronische Steuereinheit 14 einen CAN Bus 16 auf, der die Verbindung zu den Fahrzeugsystemen, d.h. den Aktuatoren und Sensoren des Fahrzeugs herstellt. Zu den Fahrzeugsystemen gehört auch das im vorliegenden Ausführungsbeispiel anzusteuernde Türschloss. Es versteht sich, dass jedes beliebige Fahrzeugsystem über den CAN Bus 16 oder einen anderen Bus ansteuerbar ist und die Erfindung nicht auf den Einsatz mit Türschlössern beschränkt ist.
Auf dem Single Board Computer 12 ist ein Client 18 vorgesehen. Der Client 18 ist für die Verarbeitung von Daten, insbesondere zum Mining und zum Speichern von Informationen vorgesehen. Der Single Board Computer 12 speichert ferner ein Fahrzeug-Wallet 20 mit verschlüsselten Private Keys zum Signieren von Transaktionen und zum Verschlüsseln von Kommunikation.
Für die Kommunikation ist ein Bluetooth Low Energy (BLE) Modul 22 auf dem Single Board Computer 12 vorgesehen. Das BLE-Modul 22 dient der Implementierung eines Transaktionsprotokolls für die Kommunikation mit dem Smartphone 10. Dies ist durch einen Pfeil 24 repräsentiert.
Zusätzlich ist in dem Client 18 ein LTE-Modul vorgesehen, über welches die Kommunikation des Clients 18 mit einem Blockchain-Netzwerk 28 erfolgt. Dies ist durch einen Pfeil 30 repräsentiert. Ein CAN Bus Modul 32 dient als Interface zwischen dem Single Board Computer 12 und dem CAN Bus 16 und den daran angeschlossenen Fahrzeugsystemen 34. Es versteht sich, dass statt eines CAN Bus-Systems auch jeder andere BUS verwendet werden kann.
Auf dem Smartphone 10 ist eine Applikation 40 installiert, welche ein digitales Wallet in Form eines HD Wallets 36 aufweist. Statt eines HD Wallets 36 kann auch jede andere Applikation zum sicheren Speichern von Daten verwendet werden. Das Wallet 36 bildet einen initialen Client und speichert verschlüsselt Private Keys, die zum Signieren von Transaktionen und zur Verschlüsselung von Kommunikation über BLE und eventuell weiteren Schlüsseln dienen. Das Wallet 36 erlaubt die Wiederherstellung aller Schlüssel über einen Mnemonic Seed 38. Es versteht sich, dass alle Daten verloren sind, wenn der Seed 38 verloren ist. Dies ist eine Anforderung an Sicherheit und Privatheit, insbesondere unter dem Gesichtspunkt der General Data Protection Regulation (GDPR).
Die Applikation 40 umfasst ferner ein BLE Modul 42 für die Kommunikation mit dem BLE Modul 22 im Fahrzeug. Es kann ein Modul für die Kommunikation der Applikation 40 mit weiteren Clients, etwa Prozessoren oder Datenloggern, etwa für Smart Contracts vorgesehen sein. Das Blockchain-Netzwerk 28 umfasst eine Vielzahl von Nodes 46. Die Nodes 46 können unterschiedliche Eigenschaften haben und auf unterschiedlichen Wegen miteinander kommunizieren. Wichtig ist lediglich, dass es sich um ein Blockchain-Netzwerk oder ein anderes verteiltes System (DLT) handelt.
Das Smartphone 10 bildet einen ersten Teilnehmer des Netzwerks 28. Die Steuereinheit 14 bildet einen zweiten Teilnehmer des Netzwerks 28. Beide Teilnehmer haben eine drahtlose Verbindung 24, die auch ohne Verbindung zum Internet, Telefonnetz oder einem anderen Netzwerk hergestellt werden kann. Im vorliegenden Ausführungsbeispiel wurde eine BLE-Verbindung verwendet. Es versteht sich, dass auch andere Verbindungen möglich sind.
Im vorliegenden Ausführungsbeispiel wurden mehrere Smart Contracts 50, 52 verwendet. Zu den Smart Contracts zählen „UserRegister“ 50 und „VehicleState“ 52. Im vorliegenden Ausführungsbeispiel wurden mehrere Smart Contracts verwendet. Die Verwendung weiterer Smart Contracts ist möglich und hängt von der konkreten Anwendung ab. Es ist aber auch möglich, alle Zusammenhänge in weniger Smart Contracts, insbesondere auch in nur einem einzigen Smart Contract festzulegen.
Das UserRegister 50 listet alle Nutzer des Systems auf. Es erlaubt Anfragen ob eine Adresse einen Nutzer repräsentiert und schafft die Möglichkeit Nutzer aus dem System auszuschließen. Das UserRegister 50 ist somit eine sogenannte Whitelist, von der Nutzer gestrichen werden können.
Der in 2c gezeigte VehicleState 52 ist ein Smart Contract und repräsentiert den Fahrzeugzustand. Dazu gehören die Auflistung der möglichen mit einem Befehl verbundenen Rechte, eine Zuordnung zu einem Nutzer und das Zuordnen von Adressen 68, z.B. zu Rechten, z.B. 100. Die Rechte bestimmen, für welche Nutzer welche Rechte an dem jeweiligen Fahrzeug 66 bestehen. Beispiele für solche Rechte 100 sind das Öffnen der Türen, des Kofferraums oder das Recht das Fahrzeug zu starten. Die Rechte 100 sind nicht fest, sondern durch Identifier, z.B. einen Hashwert oder den Namen des Rechtes repräsentiert, die durch die oben beschriebenen Applikationen, nämlich den Client 18 interpretiert werden. Die Rechte (Autorisierungen) können mit einem Ablaufdatum versehen sein, können aber auch jederzeit manuell entzogen werden.
Anhand von 2 wird nachfolgend die Zugangskontrolle beschrieben. Dabei werden asymmetrische Verschlüsselungsverfahren verwendet, die bekannt sind und hier daher nicht im Detail beschrieben werden. Bei einem asymmetrischen Verschlüsselungsverfahren hat ein Nutzer einen Private Key (geheimer Schlüssel), der nur diesem Nutzer bekannt ist. Der Empfänger eines Datensatzes hat einen Public Key (öffentlichen Schlüssel). Ein Public Key lässt sich aus dem zugehörigen Private Key herleiten. Entsprechend bilden der Public Key und der Private Key ein Schlüsselpaar für das asymmetrische Verschlüsselungsverfahren. Ein Datensatz, der mit einem Public Key verschlüsselt wurde, lässt sich nur mit dem zugehörigen Private Key entschlüsseln. Ein Datensatz, der mit einem Private Key verschlüsselt wurde, lässt sich mit dem zugehörigen Public Key verschlüsseln. Dies bildet die Basis für den Aufbau einer sicheren Verbindung 24 zwischen dem ersten Teilnehmer, d.h. dem Smartphone 10, und dem zweiten Teilnehmer, d.h. dem Micro Controller 12 in einem Fahrzeug 66.
Die Verbindung wird aufgebaut und der Zugang gewährt, wenn der erste Teilnehmer 10 geeignet und verifizierbar nachweist, dass er die entsprechende Rechte hat. Das bedeutet, der erste Teilnehmer 10 muss nachweisen, dass seine Identität als Teilnehmer berechtigt ist und dass er die zur Durchführung der angefragten Aktion erforderlichen Rechte hat.
Zum Erreichen einer hohen Sicherheit werden verschiedene Paare aus Private Keys und Public Keys für unterschiedliche Anfragen des gleichen Nutzers verwendet. Der Nutzer kann beispielsweise das Smartphone, ein Micro Controller in einem Fahrzeug oder ein anderer Systemteilnehmer sein.
Die kryptographischen Berechtigungsnachweise, wie etwa Public Keys, werden in Smart Contracts 50, 52 registriert. Dabei handelt es sich um eine sichere Public Key Infrastruktur die gegenüber Angriffen genauso gesichert ist, wie Smart Contracts gegenüber unauthorisierten Änderungen gesichert ist.
Die Private Keys für ein Wallet in einem Smartphone 10, die einem Menschen gehören, der Zugriff auf ein Fahrzeug haben möchte, sind von einem Mnemonic Seed 38 bestimmt. Dadurch wird ein guter Ausgleich zwischen Sicherheit und Anwenderfreundlichkeit geschaffen. Es schafft ferner die einzige und einfache Quelle, deren Zerstörung auch die Kenntnis über die Private Keys zerstört.
Das Kommunikationsprotokoll für die Verbindung 24 wird nachstehend anhand von 2 näher erläutert. Der Nutzer kann durch Verwendung der Smartphone Applikation, BLE Modul 42, verschlüsselt über die BLE-Verbindung 24 mit seinem Fahrzeug 66 kommunizieren. Dabei können beispielsweise das Fahrzeug 66 geöffnet und geschlossen werden oder der Kofferraum des Fahrzeugs geöffnet werden. Der Nutzer hat zwei Private Keys 58 und 60. Das Fahrzeug hat zwei Private Keys 62 und 64. Jeweils einer der Private Keys, nämlich der Private Key 60 bzw. 64 wird für die verschlüsselte Kommunikation über die Verbindung 24 verwendet. Dieser Schlüssel 60, 64 wird Typ 1-Schlüssel bezeichnet. Der jeweils andere Schlüssel 58, 62 wird nur zum Signieren von Transaktionen und Nachrichten, also von Datensätzen verwendet. Dieser Schlüssel 58, 62 wird als Typ 2-Schlüssel bezeichnet. Zu jedem der Private Keys 58, 60, 62 und 64 gehört jeweils ein Public Key, die mit 68, 70, 72 und 74 bezeichnet sind. Statt eines Public Keys 68 bzw. 72 wird im vorliegenden Ausführungsbeispiel sein gekürzter Hashwert verwendet, der auch als Adresse 68 bezeichnet werden kann. Die Schlüssel 70 und 74 sind entsprechend Typ 1 - Schlüssel. Die Schlüssel 68 und 72 sind Typ 2 Schlüssel.
Das Transferprotokoll, das Anfragen in Aktionen wandelt, arbeitet wie folgt: Der Nutzer verbindet das Fahrzeug sicher über die Smartphone Applikation 40. Mit dem Begriff „Fahrzeug“ wird im Folgenden das Fahrzeug 66 mit der darin befindlichen Steuerung 14 bezeichnet. Die Smartphone Applikation 42 und das Fahrzeug tauschen ihre Typ 1 Public Keys 70 und 74 aus. Der Public Key 70 wird vom Smartphone an das Fahrzeug übertragen. Dies ist durch einen Pfeil 80 repräsentiert. Der Public Key 74 wird vom Fahrzeug an das Smartphone übertragen. Dies ist durch einen Pfeil 82 repräsentiert.
Nachdem das Fahrzeug den Typl-Schlüssel, d.h. den Public Key 70 vom Smartphone 10 erhalten hat, prüft es, ob der Schlüssel 70 in dem UserRegister Smart Contract 50 enthalten ist. Dies erfolgt bei 78 und ist in 2a durch einen Pfeil 82 repräsentiert. Der Public Key 70 selber ist in dem UserRegister 50 nicht enthalten, sondern ein SHA3 Hashwert 76 des Public Keys 70. Der Public Key 70 ist also anderen Teilnehmern 46 des Blockchain Netzwerks 28 nicht bekannt. Wenn der zu dem Public Key 70 gehörige Hashwert 76 im Smart Contract 50 existiert, liefert das UserRegister 50 eine Adresse 68 zurück, welche einem gekürzten SHA3 Hashwert des Public Key 68 entspricht. Dies ist durch einen Pfeil 84 in 2a repräsentiert.
Anschließend wird von dem Fahrzeug eine Zufallszahl 86, auch als Nonce bezeichnet, erzeugt. Im vorliegenden Ausführungsbeispiel ist die Zufallszahl siebenstellig, beispielsweise 6999999. Es versteht sich, dass jede beliebige Zufallszahl in jedem beliebigen Zahlenraum verwendet werden kann. Mit der Zufallszahl 86 können Replay-Angriffe verhindert werden, denn die Kommunikation verwendet naturgemäß jedes Mal eine andere Zufallszahl. Die Zufallszahl wird mit dem Private Key 64 des Fahrzeugs und dem Public Key 70 des Smartphones, d.h. mit den Typ 1-Schlüsseln verschlüsselt. Dies ist durch den Wert mit Symbol 88 in 2a repräsentiert. Der so erhaltene, verschlüsselte Wert 88 wird über die Verbindung 24 an das Smartphone 10 übertragen. Dies ist durch einen Pfeil 90 repräsentiert.
2b zeigt den Kasten 92, der angibt, wie ein Befehl von der Smartphone Applikation verarbeitet wird, bevor er an das Fahrzeug übertragen wird. Zunächst wird die Zufallszahl mit dem Private Key 60, d.h. dem Typ 1-Schlüssel des Smartphones und dem Public Key 74, d.h. dem ausgetauschten Public Key und Typ 1 - Schlüssel des Fahrzeugs entschlüsselt. Dies ist durch einen Pfeil 94 repräsentiert. Die nun im Smartphone vorliegende Zufallszahl 86 wird um 1 hochgezählt. Dies ist durch einen Pfeil 96 repräsentiert. Es ergibt sich die um 1 erhöhte Zufallszahl 98.
Mit dem Smartphone 10 wird ein Befehl 100, beispielsweise, dass das Fahrzeug 66 geöffnet werden soll (unlock vehicle) aus einer Liste 102 mit verfügbaren Befehlen ausgewählt. Der Befehl 100 wird mit einem Zeitstempel 104 versehen. Anschließend wird der Datensatz aus dem Hashwert des Befehls 100 und dem Zeitstempel 104 mit dem Private Key 58 des Smartphones 10 signiert. Dies ist durch einen Pfeil 106 in 2b repräsentiert. Es ergibt sich ein gehashter und signierter Befehl 108. Der eigentliche Befehl 100 lässt sich diesem gehashten und signierten Befehl 108 nicht mehr entnehmen. Mit dem gehashten und signierten Befehl 108 kann die Echtheit des Befehls 100 überprüft werden.
Der gehashte und signierte Befehl 108 bildet zusammen mit der um 1 erhöhten Zufallszahl 98, dem unsignierten Befehl 100 und dem Zeitstempel 104 einen Datensatz 110. Der Datensatz 110 wird mit dem Private Key 60 des Smartphones 10 und dem zuvor ausgetauschten Public Key 74, also Typ-1-Schlüsseln, verschlüsselt. Dies ist durch einen Pfeil 112 repräsentiert. Der so verschlüsselte Datensatz ist in 2b mit 114 bezeichnet.
Der verschlüsselte Datensatz 114 wird, wie in 2 erkennbar, an das Fahrzeug 66 übertragen. Dort erfolgt die weitere Verarbeitung, die durch den Kasten 116 repräsentiert ist. Die weitere Verarbeitung ist in 2c näher erläutert.
Im Fahrzeug wird zunächst mit dem Public Key 70 und dem Private Key 64 entschlüsselt. Dies ist in 2c durch einen Pfeil 118 repräsentiert. Anschließend wird geprüft, ob der Zufallswert erfolgreich um 1 erhöht wurde. Dies ist durch den Vorgang 120 repräsentiert. Es versteht sich, dass jeder andere Operator ebenfalls verwendet werden kann. Anschließend wird geprüft, ob die Signatur, d.h. der Public Key 68, bzw. die Adresse, dem Schlüssel aus dem UserRegister 50 bzw. der Netzwerk-Adresse 68 entspricht.
Anschließend wird geprüft, ob der Zeitstempel 104 innerhalb eines vorgegebenen Zeitintervalls liegt. Anhand des VehicleState 52 wird geprüft, ob der Nutzer mit der Adresse 68 zur Ausführung des signierten Befehls 108 berechtigt ist. Dies ist durch einen Pfeil 122 repräsentiert. Wenn dies der Fall ist, so wird der unsignierte Befehl 100 ausgeführt. Das Ergebnis der Verifizierung wird mit dem Private Key 62, also einem Typ-2 Schlüssel des Fahrzeugs signiert und in dem Smart Contract VehicleState 52 im Blockchain-Netzwerk 28 gespeichert. Dies ist durch einen Pfeil 124 in 2c repräsentiert.
Auch wenn die Teilnehmer, z.B. das Fahrzeug 66 und/oder das Smartphone 10 offline sind, kann die Verbindung herstellt werden. Die Blockchain 28 läuft aber auch während dieser Zeit weiter. Entsprechend stimmen die Daten nicht mehr mit den in der Blockchain 28 gespeicherten Daten überein, weil sie bei der nächsten Verbindung mit der Blockchain 28, wenn die Teilnehmer wieder online, veraltet sind. Durch die Aufzeichnung der Transaktionen kann aber zum Zeitpunkt des Wiedereintretens in die Blockchain 28 nachgewiesen werden, dass die Daten echt sind. Dies wird als „Eventual Consistency“ bezeichnet. Die Eigenschaft „Eventual Consistency“ der Blockchain macht die Vorgänge verfügbar, auch wenn das Fahrzeug keine Internetverbindung hat.
Die vorstehende Erfindung wurde hier anhand eines konkreten Ausführungsbeispiels beschrieben. Die Beschreibung dient jedoch nur zur Illustration der Erfindung. Der Umfang der Erfindung lässt eine Vielzahl von Variationen zu, die ausschließlich vom Schutzbereich der beigefügten Ansprüche bestimmt werden. So sind bestimmte Merkmale hinsichtlich Anordnung und Aufbau des Ausführungsbeispiels, Verwendung von Funktionen und Operatoren, Bildung von Hashwerten und Übertragungsprotokollen lediglich sinnvolle Ausgestaltungen. Es können statt einer BLE Verbindung auch andere geeignete Verbindungen hergestellt werden. Auch können statt SHA3 andere Verfahren eingesetzt werden. Statt der Hashwerte können auch die zugehörigen Schlüssel verwendet werden. Statt eines Smartphones können beliebige andere Rechner verwendet werden. Auch kann die Erfindung bei anderen Arten von Teilnehmern, etwa anderen Fahrzeugen und Maschinen. Die Erfindung ist nicht auf die Art der Erzeugung bestimmter Public und Private Keys beschränkt. Hierzu können beliebige geeignete Verfahren verwendet werden.
Dies gilt für alle Merkmale und deren Kombinationen, solange in den Ansprüchen nicht eine bestimmte Kombination von Merkmalen als erfindungswesentlich offenbart ist.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

WO 2017/060816 A1 [0004]
US 2017/0331635 A1 [0004]
EP 3236401 A1 [0004]
DE 102017107147 A1 [0004]
GB 2548802 A [0004]
DE 102016007472 A1 [0004]

Claims

Verfahren zum Herstellen einer sicheren Datenübertragungsverbindung zwischen einem ersten und einem zweiten Teilnehmer eines Bockchain-Netzwerks oder einem anderen verteilten System (DLT) mit den Schritten: (a) Erzeugen von wenigstens zwei Private Keys für den ersten und wenigstens einem Private Key für den zweiten Teilnehmer; (b) Herleiten eines Public Keys für jeden der Teilnehmer und eines Public Keys oder eines daraus erzeugten Hashwertes oder anderen Wertes, welcher den Public Key repräsentiert, aus dem zweiten Private Key des ersten Teilnehmers; (c) Registrieren des ersten Teilnehmers in wenigstens einem Teilnehmer-Smart Contract des verteilten Systems mit einem Werte Tupel aus wenigstens zwei seiner Public Keys oder die Public Keys repräsentierenden Werten; (d) Austauschen jeweils eines der Public Keys zwischen dem ersten und dem zweiten Teilnehmer; (e) Verifizieren der Registrierung des ersten Teilnehmers in dem Teilnehmer-Smart Contract durch den zweiten Teilnehmer und Zwischenspeichern von wenigstens einem weiteren Wert aus dem zu dem ersten Teilnehmer gehörigen Werte Tupel; (f) Erzeugen eines Datensatzes durch den ersten Teilnehmer; (g) Verschlüsseln des Datensatzes durch den ersten Teilnehmer mit einem der Private Keys des ersten Teilnehmers und dem aus Schritt (d) durch den Austausch erhaltenen Public Key des zweiten Teilnehmers; (h) Übertragen des in Schritt (g) verschlüsselten Datensatzes an den zweiten Teilnehmer; und (i) Entschlüsseln des Datensatzes durch den zweiten Teilnehmer mit dem zu dem in Schritt (d) durch Austausch erhaltenen Public Key des zweiten Teilnehmers zugehörigen Private Key des zweiten Teilnehmers und dem zu dem durch in Schritt (d) durch Austausch erhaltenen Public Key des ersten Teilnehmers.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass (k) ein oder mehrere Befehle in wenigstens einem Befehls-Smart Contract des verteilten Systems registriert werden, (1) wenigstens ein ausgewählter Befehl mit dem zu einem zwischengespeicherten Wert des Werte Tupels des Teilnehmer-Smart Contracts gehörigen Private Key des ersten Teilnehmers signiert wird, (m) der Datensatz den signierten Befehl und den gleichen, unsignierten Befehl umfasst; und (n) der signierte Befehl mit dem zwischengespeicherten Wert des Werte Tupels des Teilnehmer-Smart Contracts des ersten Teilnehmers in dem Befehls-Smart Contract des verteilten Systems verifiziert und durch den zweiten Teilnehmer ausgeführt wird.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Datenaustausch und die Ausführung des Befehls in dem verteilten System propagiert und geloggt wird.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass die Private Keys eines Teilnehmers aus einem Seed erzeugt werden.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass (o) für den zweiten Teilnehmer wenigstens zwei Private Keys und daraus zwei Public Keys erzeugt werden, von denen der erste Teilnehmer einen in Schritt (d) erhält; (p) der zweite Teilnehmer eine Zufallszahl (nonce) erzeugt, (q) die Zufallszahl mit einem der Private Keys des zweiten Teilnehmers und dem in Schritt (d) ausgetauschten Public Key des ersten Teilnehmers verschlüsselt wird; (r) die so verschlüsselte Zufallszahl an den ersten Teilnehmer übertragen wird; (s) die Zufallszahl vom ersten Teilnehmer entschlüsselt wird mit dem in Schritt (d) ausgetauschten Public Key des zweiten Teilnehmers und dem Private Key des ersten Teilnehmers; (t) die Zufallszahl in definierter Weise verändert wird; (u) die so veränderte Zufallszahl dem Datensatz aus (f) beigefügt wird; und (v) die aus dem entschlüsselten Datensatz von dem zweiten Teilnehmer erhaltene veränderte Zufallszahl mit der Zahl verifiziert wird, die der zweite Teilnehmer selber aus der veränderten Zufallszahl durch gleiche Veränderung bestimmt.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass die Übertragung von Daten zwischen den Teilnehmern über eine Bluetooth Low Energy-Verbindung oder auf andere Weise drahtlos erfolgt.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass der erste Teilnehmer ein mobiles Endgerät ist.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass der zweite Teilnehmer ein Steuergerät oder ein anderer Micro Controller in einem Fahrzeug zu Wasser, zu Land oder in der Luft, in einer Maschine oder einem anderen technischen Gerät ist.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass das verteilte System eine Serie mit einer Vielzahl von Paaren aus erstem und zweiten Teilnehmer umfasst.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass der Befehl ein Befehl zur Übertragung von gespeicherten Daten ist.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass die die Public Keys repräsentierenden Werte in dem Teilnehmer-Smart Contract durch einen sha3 oder einen anderen Hashwert gebildet sind.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass der Teilnehmer-Smart Contract ein Key Value Store ist.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass der weitere Wert in jedem Werte Tupel in dem Teilnehmer-Smart Contract ein Public Key ist, der nicht in Schritt (d) mit dem zweiten Teilnehmer ausgetauscht wurde.
Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass der Befehl zusammen mit einer Zeit- und/oder Positionsinformation verschlüsselt wird.
Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass der Befehl durch den zweiten Teilnehmer nur ausgeführt wird, wenn die Zeitverzögerung zwischen der mitverschlüsselten Zeitinformation und der Empfangszeit beim zweiten Teilnehmer kleiner als ein Schwellwert ist.
Verfahren zum Herstellen einer sicheren Datenübertragungsverbindung zwischen einem ersten und einem zweiten Teilnehmer eines Bockchain-Netzwerks oder einem anderen verteilten System (DLT), wobei ein verschlüsselter Datensatz von dem ersten zum zweiten Teilnehmer übertragen wird, dadurch gekennzeichnet, dass: (o) für den zweiten Teilnehmer wenigstens zwei Private Keys und daraus zwei Public Keys erzeugt werden, von denen der erste Teilnehmer einen erhält, und für den ersten Teilnehmer wenigstens ein Private Key erzeugt wird und daraus ein wenigstens ein Public Key erzeugt wird, den der zweite Teilnehmer erhält; (p) der zweite Teilnehmer eine Zufallszahl (nonce) erzeugt, (q) die Zufallszahl mit dem Private Key des zweiten Teilnehmers und dem Public Key des ersten Teilnehmers verschlüsselt wird; (r) die so verschlüsselte Zufallszahl an den ersten Teilnehmer übertragen wird; (s) die Zufallszahl vom ersten Teilnehmer entschlüsselt wird mit dem ausgetauschten Public Key des zweiten Teilnehmers und dem Private Key des ersten Teilnehmers; (t) die Zufallszahl in definierter Weise verändert wird; (u) die so veränderte Zufallszahl dem Datensatz beigefügt wird; und (v) die aus dem entschlüsselten Datensatz von dem zweiten Teilnehmer erhaltene veränderte Zufallszahl mit der Zahl verifiziert wird, die der zweite Teilnehmer selber aus der veränderten Zufallszahl durch gleiche Veränderung bestimmt.
Verfahren zum Übertragen wenigstens eines Befehls von einem ersten zu einem zweiten Teilnehmer eines Bockchain-Netzwerks oder einem anderen verteilten System (DLT), wobei der Befehl in einem verschlüsselten Datensatz von dem ersten zum zweiten Teilnehmer übertragen wird, dadurch gekennzeichnet, dass (k) ein oder mehrere Befehle in wenigstens einem Befehls-Smart Contract des verteilten Systems registriert werden, (1) wenigstens ein ausgewählter Befehl mit einem Private Key des ersten Teilnehmers signiert wird, (m) der Datensatz den signierten Befehl und dem gleichen, unsignierten Befehl umfasst und (n) der signierte Befehl mit dem zum Private Key gehörigen Public Key des ersten Teilnehmers in dem Befehls-Smart Contract des verteilten Systems verifiziert und durch den zweiten Teilnehmer ausgeführt wird.
Bockchain-Netzwerk oder ein anderes verteiltes System (DLT) enthaltend eine Serie mit einer Vielzahl von Paaren aus einem ersten und zweiten Teilnehmer, dadurch gekennzeichnet, dass (a) jeder erste Teilnehmer wenigstens zwei Private Keys und wenigstens zwei zugehörige Public Keys aufweist und jeder zweite Teilnehmer wenigstens einen Private Key und einen zugehörigen Public Key aufweist; (b) zumindest alle zweiten Teilnehmer der Serie einen Smart Contract mit einem Werte Tupel aus wenigstens zwei Public Keys oder Public Keys repräsentierenden Werten aller ersten Teilnehmer aufweisen; (c) jeder Teilnehmer Mittel zum Übertragen von Keys, Befehlen und anderen Daten an wenigstens einen anderen Teilnehmer des verteilten Systems und Mittel zum Verschlüsseln, Entschlüsseln und Signieren von Befehlen und anderen Daten aufweist; (d) Mittel zum Verifizieren der Registrierung eines ersten Teilnehmers in dem Teilnehmer-Smart Contract durch den zweiten Teilnehmer und Zwischenspeichern von weiteren Werten aus dem zu dem ersten Teilnehmer gehörigen Werte Tupel vorgesehen sind; und (e) jeder zweite Teilnehmer Mittel zum Ausführen eines an ihn übertragenen Befehls aufweist.
Bockchain-Netzwerk oder ein anderes verteiltes System (DLT) nach Anspruch 18, dadurch gekennzeichnet, dass zumindest die zweiten Teilnehmer wenigsten einen Befehls-Smart Contract mit wenigstens einem Befehl zum Verifizieren eines erhaltenen Befehls vor der Ausführung aufweisen.
Bockchain-Netzwerk oder ein anderes verteiltes System (DLT) nach Anspruch 18 oder 19, dadurch gekennzeichnet, dass zumindest die zweiten Teilnehmer Mittel zur Erzeugung einer Zufallszahl und alle Teilnehmer Mittel zum Verändern der von dem zweiten Teilnehmer erzeugten Zufallszahl aufweisen.
Bockchain-Netzwerk oder ein anderes verteiltes System (DLT) nach einem der Ansprüche 18 bis 20, dadurch gekennzeichnet, dass die Mittel zum Übertragen von Keys, Befehlen und anderen Daten an wenigstens einen anderen Teilnehmer des verteilten Systems eine Bluetooth Low Energy Übertragung bewirken.
Bockchain-Netzwerk oder ein anderes verteiltes System (DLT) nach einem der Ansprüche 18 bis 21, dadurch gekennzeichnet, dass die ersten Teilnehmer mobile Endgeräte sind.
Bockchain-Netzwerk oder ein anderes verteiltes System (DLT) nach einem der Ansprüche 18 bis 22, dadurch gekennzeichnet, dass die zweiten Teilnehmer Steuergeräte oder andere Micro Controller in einem Fahrzeug zu Wasser, zu Land oder in der Luft, in einer Maschine oder anderen technischen Geräten sind.
Bockchain-Netzwerk oder ein anderes verteiltes System (DLT) nach einem der Ansprüche 18 bis 23, dadurch gekennzeichnet, dass zumindest in den ersten Teilnehmern ein Zeit- und/oder Positionsgeber vorgesehen ist.