WO2020169502A1 - Verfahren zum transfer von daten - Google Patents

Verfahren zum transfer von daten Download PDF

Info

Publication number
WO2020169502A1
WO2020169502A1 PCT/EP2020/054021 EP2020054021W WO2020169502A1 WO 2020169502 A1 WO2020169502 A1 WO 2020169502A1 EP 2020054021 W EP2020054021 W EP 2020054021W WO 2020169502 A1 WO2020169502 A1 WO 2020169502A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
consent
owner
interested party
provider
Prior art date
Application number
PCT/EP2020/054021
Other languages
English (en)
French (fr)
Inventor
Brian PFRETZSCHNER
Dominic Woerner
Fabian FRANK
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2020169502A1 publication Critical patent/WO2020169502A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the invention relates to a method for transferring data according to claim 1.
  • the most common consent mechanisms are the General Terms and Conditions, End User License Agreements (EULAs) and Terms of Use (ToS). Especially when using software or electronic applications, the user normally only has to click on the "I agree” button in order to agree to declarations of consent. Few of the users actually pause to read what is written in these consent forms. Most users forget the moment of consent, even if they have consented to continued use of their personal data.
  • EULAs End User License Agreements
  • ToS Terms of Use
  • a current implementation which enables the user to manage his consent with regard to the use of his data, is the CarData platform from BMW.
  • the user can manage the consents in order to allow third parties access to vehicle data.
  • Conventional methods for transferring data are based on consent data, which is managed centrally by the data provider. Due to the strong centralization of the first data or the user data, as well as the consent data with individual consent agreements with a single data provider, these are often disadvantageous for the data owner and a data interested party.
  • the invention according to independent claim 1 enables the first data and the consent data to be separated in order to make the management of the declarations of consent in the form of consent data clearer for the data owner, the data provider and for those interested in data designed.
  • the inventive method enables the data owner to have increased control over their first data and makes the data owner's consent data clearer, more flexible and more independent of individual data providers.
  • a data marketplace is a specific scenario in which consent data is used.
  • the current situation is that a data owner gives the data provider his consent to sell the first data to the data market.
  • This is a simple and clear consent scenario, but in reality the data market sells this data on to customers to whom the data owner has not given consent.
  • the existing methods for data transfer are not flexible enough to deal with such a scenario with several parties requesting resources via an intermediary (e.g. a data marketplace).
  • the inventive method for transferring data comprises the following steps: a) a data provider receives a request from a data interested party, the request containing a reference to an account of the data owner and to an account of the data interested party in the blockchain,
  • the data provider transfers the data of the data owner and / or carries out the requested action if the validation has led to a positive result.
  • Filtering for consent data in the smart contract through the reference to the account of the data owner and the account of the data interested party is advantageous because it can be done quickly and efficiently.
  • the data provider carries out an identity check with regard to the data interested party as part of the validation, since this can be used to ensure that the data interested party has given a correct identity.
  • An identity check using a challenge-response method offers a particularly high level of security.
  • an identity check is also possible via a signature in the request from the data interested party.
  • Figure 1 is a schematic view of the proposed invention
  • Figure 2 is a flow chart of the inventive method.
  • FIG. 1 shows a schematic view of the proposed invention with a data owner (20), a data interested party (30) and a data provider (40).
  • the data owner (20), the data interested party (30) and a data provider (40) are different servers, which are directly connected to one another via an interface (14), via a network or a blockchain (12 ) can communicate with each other.
  • the data provider (40) has stored first data (22) from the data owner (20) on an electrical storage medium (21).
  • These first data (22) from the data owner (20) can for example be data about the driving behavior of the data owner (20) received by the control unit of a vehicle. This can be directly obtained data such as the mileage or data relating to acceleration values or fuel consumption depending on driving behavior.
  • the first data (22) of the data owner (20) can also provide an overview of purchases made by the data owner (20) on a special sales portal on the Internet.
  • consent data (25) for example in the form of contracts or consents from the data owner (20) with regard to the use, release and / or transfer of the first data (22), are stored in a smart contract (10) .
  • the smart contract (10) is part of a blockchain (12).
  • the data owner (20), the data interested party (30) and the data provider (40) need at least one account the blockchain (12).
  • Each blockchain account (12) has a public key and a private key in the form of a key pair.
  • the public key is part of the blockchain network and is known to every account owner of the blockchain (12), the private key may only be known to the owner of a single account.
  • the consent data (25) of the data owner (20) consist at least of a reference to the account of the data provider (40) and the data interested party (30) in the blockchain (12).
  • Many other properties are also possible, e.g. B. what type of first data (22) are permitted, what terms of use have been accepted and how long the consent is valid.
  • FIG. 2 shows a flow diagram of an inventive method.
  • the data provider (40) receives a request from a data interested party (30) who is interested in the first data (22) of a data owner (20).
  • the request (100) must have a reference to the account of the data owner (20) and to the account of the data interested party (30) in the blockchain (12).
  • the data provider (40) validates the request with the aid of the smart contract (10) based on the request.
  • a filtering for consent data (25) in the smart contract (10) is carried out using the reference to the account of the data owner (20) and the account of the data interested party (30).
  • the consent data (25) are checked with regard to their agreement with the individual request and / or their current validity.
  • an identity check can also be carried out with respect to the data interested party (30) in order to ensure that the data interested party (30) has correctly indicated his identity.
  • the identity check can be carried out by a challenge-response authentication.
  • the data provider (40) sends the data interested party (30) a random number N.
  • the data interested party (30) encrypts or signs this number N with his private one Key.
  • the result (response) is in turn sent to the data provider (40), who can verify with the public key of the data interested party that the random number N selected by him has been encrypted or signed. If the results of the two calculations are identical, the authentication of the data interested party (40) was successful, since only this party has the corresponding private key.
  • the identity check can also be carried out via a signature in the request from the data interested party (30), for example on the basis of the current time.
  • the data provider (40) sends the first data (22) from the data owner (20) to the data interested party (30) if the validation has led to a positive result.
  • a requested action can also be carried out by the data provider (40).
  • a possible requested action can be the automatic opening of a locked door (car door, entrance door, locker, etc.), for example to enable a parcel deliverer to store a package in a safe place or to enable access to a rental vehicle.
  • the first data (22) of the data owner (30) can be sent encrypted to the data interested party (30).
  • the first data (22) of the data owner (20) can be encrypted, for example, with the public key of the data interested party (30), so that only this person can decrypt the first data (22) with his private key. Encryption means that confidential data can also be transmitted via an insecure communication channel.
  • the data interested party (30) can in the optional method step (50) before submitting a request to the data provider (40), filtering for consent data (25) in the smart contract ( 10) through the reference to the account of the data owner (20) and to the account of the data interested party (30). In this way, he can avoid unnecessary queries to the data owner (20) and the data provider (40), since he can check in advance whether a data owner (20) has consent to the transfer of the first data (22) has given.
  • the data interested party (30) determines that the required consent data (25) is missing or not available in the smart contract (10)
  • he can send a request to the data owner (20) regarding a change the consent data (25) stored in the smart contract (10).
  • a request in relation to a change in the consent data (25) stored in the smart contract (10) can be sent via the blockchain (12) or via an alternative communication channel.
  • the data provider (40) can also use the blockchain (12) to send a request to the data owner (20) with regard to a change to the consent data (25) stored in the smart contract (10) if he is interested in changing the consent data (25). This can be the case, for example, when he receives a request from the data interested party (30) and determines that the consent data (25) required for the data transfer are missing in the smart contract (10).
  • the consent data (25) in the smart contract (10) are secured against changes by the fundamental properties of the blockchain (12). Due to the protection within the blockchain, for example by a hash value that is assigned to the respective consent data (25), the consent data (25) cannot be changed afterwards. If they are changed anyway, they automatically become invalid if the data owner (20) does not agree to the new consent data (25).
  • the Ethereum blockchain can be used as the blockchain (12).
  • the blockchain (12) is characterized by its security against manipulation, its security against failure, its transparency and verifiability, which enables a new approach for data transfer based on consent data (25).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Verfahren zum Transfer von Daten, wobei erste Daten (22) eines Daten-Eigentümers (20) auf einem elektrischen Speichermedium (21) eines Daten-Anbieters (40) abgelegt sind und Einwilligungs-Daten (22) des Daten-Eigentümers (20) in Bezug auf die Benutzung, Freigabe und den Transfer der ersten Daten in einem Smart Contract (10) abgelegt sind, welcher Bestandteil einer Blockchain (12) ist, wobei folgende Schritte durchgeführt werden: a) ein Daten-Anbieter (40) erhält eine Anfrage eines Daten-Interessenten (30), wobei die Anfrage eine Referenz zu einem Account des Daten-Eigentümer (20) und zu einem Account des Daten-Interessent (30) in der Blockchain (12) enthält, b) der Daten-Anbieter (40) führt eine Validierung der Anfrage mit Hilfe des Smart Contracts (10) durch, c) der Daten-Anbieter (40) transferiert die Daten des Daten-Eigentümers (20) an den Daten-Interessenten (30), falls die Validierung zu einem positiven Ergebnis geführt hat.

Description

Beschreibung
Titel
Verfahren zum Transfer von Daten
Stand der Technik
Die Erfindung betrifft ein Verfahren zum Transfer von Daten gemäß dem Anspruch 1.
Die häufigsten Einwilligungsmechanismen sind die Allgemeinen Geschäftsbedingun gen, Endbenutzer-Lizenzvereinbarungen (EULAs) und Nutzungsbedingungen (ToS). Gerade bei der Nutzung von Software oder von elektronischen Applikationen muss der Benutzer normalerweise nur auf eine Schaltfläche "Ich stimme zu" klicken, um Einwilli gungserklärungen zuzustimmen. Wenige der Benutzer pausieren tatsächlich, um zu lesen, was in diesen Einwilligungserklärungen geschrieben ist. Die meisten Benutzer vergessen den Moment der Zustimmung, auch wenn Sie einer fortwährenden Verwen dung ihrer personenbezogenen Daten zugestimmt haben.
Bestehende Systeme zum Transfer von Daten, welche auf Einwilligungs-Daten zugrei fen, ermöglichen es Einzelpersonen zu bestimmen, auf welche Informationen oder Ak tionen Dritte Zugriff haben. Diese Systeme haben ihren Ursprung im Gesundheitswe sen, wo die Erlaubnis für den Zugriff auf persönliche medizinische Informationen einer Einzelperson von entscheidender Bedeutung ist und eine umfassende Überwachung erfordert.
Eine aktuelle Implementierung, welche es dem Benutzer ermöglicht seine Einwilligun gen in Bezug auf die Benutzung seiner Daten zu verwalten ist, die CarData- Plattform von BMW. Der Benutzer kann die Einwilligungen verwalten kann, um Dritten den Zu griff auf Fahrzeugdaten zu ermöglichen.
Aktuelle Einwilligungsverwaltungssysteme sind Teil der Architektur des Datenanbie ters. Diese Datenanbieter sind sowohl für die persönlichen Benutzerdaten als auch für die den Daten entsprechenden individuellen Einwilligungsvereinbarungen verantwort lich. Die daraus resultierende Zentralisierung der Verantwortlichkeiten entspricht oft nicht den Anforderungen eines Benutzers und erhöht das Bedürfnis in ein hohes Ver trauen an den Datenanbieter. Darüber hinaus ist es Dritten nicht möglich, auf die Zu stimmung einzelner Benutzer zuzugreifen und diese zu überprüfen.
Offenbarung der Erfindung
Es ist eine Aufgabe der Erfindung ein Verfahren zum Transfer von Daten gemäß dem unabhängigen Anspruch 1 bereitzustellen. Herkömmliche Verfahren zum Transfer von Daten beruhen auf Einwilligungs-Daten, welche zentral vom Daten-Anbieter verwaltet werden. Aufgrund der starken Zentralisierung der ersten Daten bzw. der Benutzerdaten, als auch der Einwilligungs-Daten mit individuellen Einwilligungsvereinbarungen bei ei nem einzelnen Daten-Anbieter, sind diese für den Daten- Eigentümer und einen Daten interessenten oft nachteilig.
Die Erfindung gemäß dem unabhängigen Anspruch 1 ermöglicht eine Trennung der ers ten Daten und der Einwilligungs-Daten, um die Verwaltung der Einwilligungserklärungen in Form von Einwilligungs-Daten sowohl für den Daten- Eigentümer, den Daten-Anbieter als auch für Daten-Interessenten übersichtlicher zu gestallten. Das erfindungsgemäße Verfahren ermöglicht dem Daten- Besitzer eine erhöhte Kontrolle über seine ersten Da ten zu haben und macht die Einwilligungs-Daten des Daten- Besitzers übersichtlicher, flexibler und unabhängiger von einzelnen Daten-Anbietern.
Ein Datenmarktplatz ist ein spezifisches Szenario, in dem Einwilligungs-Daten zum Ein satz kommen. Die gegenwärtige Situation ist, dass ein Daten- Eigentümer dem Daten- Anbieter seine Zustimmung erteilt, um die ersten Daten an den Datenmarkt zu verkau fen. Dies ist ein einfaches und klares Einwilligungsszenario, in Wirklichkeit verkauft der Datenmarkt diese Daten jedoch weiter an Kunden, denen der Daten- Eigentümer keine Einwilligung erteilt hat. Die vorhandenen Verfahren zum Daten-Transfer sind nicht flexi bel genug, um mit einem solchen Szenario mit mehreren Parteien umzugehen, die über einen Vermittler (z. B. einen Datenmarktplatz) Ressourcen anfordern.
Das erfinderische Verfahren zum Transfer von Daten, wobei erste Daten eines Daten- Eigentümers auf einem elektrischen Speichermedium eines Daten-Anbieters abgelegt sind und Einwilligungs-Daten (Einwilligungserklärungen) des Daten- Eigentümers in Be zug auf die Benutzung, Freigabe und den Transfer der ersten Daten in einem Smart Contract abgelegt werden, welcher Bestandteil einer Blockchain ist, umfasst die folgen den Schritte: a) ein Daten-Anbieter erhält eine Anfrage eines Daten-Interessenten, wobei die Anfrage eine Referenz zu einem Account des Daten- Eigentümer und zu einem Account des Daten-Interessent in der Blockchain enthält,
b) der Daten-Anbieter führt eine Validierung der Anfrage mit Hilfe des Smart Contracts durch,
c) der Daten-Anbieter transferiert die Daten des Daten- Eigentümers und/oder führt die angeforderte Aktion aus, falls die Validierung zu einem positiven Ergebnis geführt hat.
Ein weiterer Vorteil ergibt sich, weil niemand einer zentralen Partei vertrauen muss, wel che die ersten Daten und die Einwilligungs-Daten verwaltet. Jede beteiligte Partei kann sicher sein, dass die Einwilligungs-Daten für den konkreten Antrag und die konkrete Ak tion erteilt wurden.
In den abhängigen Ansprüchen sind vorteilhafte Ausgestaltungen und Weiterbildungen der erfindungsgemäßen Vorrichtung angegeben.
Eine Filterung nach Einwilligungs-Daten im Smart Contract durch die Referenz zu dem Account des Daten- Eigentümers und dem Account des Daten-Interessenten ist vorteil haft, da sie schnell und effizient erfolgen kann.
Es ist von Vorteil, wenn der Daten-Anbieter im Rahmen der Validierung eine Identitäts prüfung in Bezug auf den Daten-Interessenten durchführt, da auf diese Weise sicher gestellt werden kann, dass der Daten-Interessent eine korrekte Identität angegeben hat. Hierbei bietet eine Identitätsprüfung durch ein Challenge-Response-Verfahren eine besonders hohe Sicherheit. Es ist aber auch eine Identitätsprüfung über eine Sig natur in der Anfrage des Daten-Interessenten möglich.
Es ist vorteilhaft, wenn über die Blockchain eine Anfrage des Daten-Interessenten oder des Daten- Anbieters an den Daten- Eigentümer in Bezug auf eine Änderung der im Smart Contract abgelegten Einwilligungs-Daten gestellt wird, da kein zusätzlicher Kom munikationskanal genutzt werden muss.
Ausführungsbeispiele Bevorzugte Ausführungsbeispiele der Erfindung sind in der Zeichnung dargestellt und in der nachfolgenden Beschreibung näher erläutert.
Es zeigen:
Figur 1 eine schematische Ansicht der vorgeschlagenen Erfindung,
Figur 2 ein Flussablaufdiagramm des erfinderischen Verfahrens.
Ausführungsformen der Erfindung
Figur 1 zeigt eine schematische Ansicht der vorgeschlagenen Erfindung mit einem Da ten- Eigentümer (20), einem Daten-Interessenten (30) und einem Daten-Anbieter (40). Bei dem Daten- Eigentümer (20), dem Daten-Interessenten (30) und einem Daten-An bieter (40) handelt es sich um unterschiedliche Server, welche durch ein Interface (14) direkt miteinander, über ein Netzwerk oder eine Blockchain (12) miteinander kommuni zieren können.
Der Daten-Anbieter (40) hat erste Daten (22) des Daten- Besitzers (20) auf einem elektri schen Speichermedium (21) abgelegt. Diese ersten Daten (22) des Daten- Eigentümer (20) können beispielsweise durch die Steuereinheit eines Fahrzeuges empfangene Da ten über das Fahrverhalten des Daten- Eigentümers (20) sein. Hierbei kann es sich um direkt gewonnene Daten wie den Kilometerstand oder Daten in Bezug auf Beschleuni gungswerte oder den Benzinverbrauch abhängig vom Fahrverhalten handeln. Die ers ten Daten (22) des Daten- Eigentümer (20) können aber auch eine Übersicht von Ein käufen des Daten- Eigentümers (20) auf einem speziellen Verkaufsportal im Internet dar stellen.
Des Weiteren sind Einwilligungs-Daten (25), beispielsweise in Form von Verträgen oder Einwilligungen des Daten- Eigentümers (20) in Bezug auf die Benutzung, Freigabe und/oder den Transfer der ersten Daten (22) in einem Smart Contract (10) abgelegt. Der Smart Contract (10) ist Bestandteil einer Blockchain (12). Um auf den Smart Contract (10) und die darin abgelegten Einwilligungs-Daten (25) zugreifen zu können, benötigen der Daten- Eigentümer (20), der Daten-Interessenten (30) und der Daten-Anbieter (40) mindestens einen Account auf der Blockchain (12). Jeder Account der Blockchain (12) besitzt einen öffentlichen Schlüssel und einem pri vaten Schlüssel in Form eines Schlüsselpaares. Der öffentliche Schlüssel ist Teil des Blockchain- Netzwerkes und ist jedem Account- Besitzer der Blockchain (12) bekannt, der private Schlüssel darf nur dem Besitzer eines einzelnen Accounts bekannt sein.
Auf diese Weise kann der öffentliche Schlüssel eines Accounts zur Verschlüsselung von Daten verwendet werden, um sicherzustellen, dass nur derjenige Zugriff auf die Daten hat, der den entsprechenden privaten Schlüsseln besitzt. Dies ist eine Grundle gende Eigenschaft der Blockchain (12), mit welcher sich der Schlüsselaustausch für die Datenverschlüsselung im Rahmen der Blockchain (12) zuverlässig und vertrauens würdig macht.
Auf die weiteren Funktionsweisen eines Smart Contract (10) und einer Blockchain (12) wird im Rahmen der Anmeldung nicht im Detail eingegangen, da davon ausgegangen wird, dass die grundlegenden Eigenschaften und Funktionsweisen dem Leser bekannt sind.
Die Einwilligungs-Daten (25) des Daten- Eigentümers (20) bestehen mindestens aus einem Verweis auf den Account der Daten-Anbieter (40) und der Daten-Interessenten (30) in der Blockchain (12). Es sind auch viele andere Eigenschaften möglich, z. B. welche Art von ersten Daten (22) zulässig sind, welche Nutzungsbedingungen akzep tiert wurden und wie lange die Zustimmung gültig ist.
In der Figur 2 ist ein Flussablaufdiagramm eines erfinderischen Verfahrens dargestellt. Im Verfahrensschritt (100) erhält der Daten-Anbieter (40) eine Anfrage eines Daten-In teressenten (30), welcher Interesse an den ersten Daten (22) eines Daten- Eigentü mers (20) hat. Die Anfrage (100) muss eine Referenz zu dem Account des Daten- Ei gentümer (20) und zu dem Account des Daten-Interessent (30) in der Blockchain (12).
Im Verfahrensschritt (200) führt der Daten-Anbieter (40) aufgrund der Anfrage eine Va lidierung der Anfrage mit Hilfe des Smart Contracts (10) durch. Hierbei wird in einem ersten Schritt eine Filterung nach Einwilligungs-Daten (25) im Smart Contract (10) durch die Referenz zu dem Account des Daten- Eigentümers (20) und dem Account des Daten-Interessenten (30) durchgeführt. Die Einwilligungs-Daten (25) werden in Be zug auf Ihre Übereinstimmung mit der individuellen Anfrage und/oder ihrer aktuellen Gültigkeit überprüft. Im Rahmen der Validierung kann auch eine Identitätsprüfung in Bezug auf den Daten interessenten (30) durchführt werden, um sicherzustellen, dass der Daten-Interessent (30) seine Identität korrekt angegeben hat.
Die Identitätsprüfung kann durch eine Challenge-Response-Authentifizierung erfolgen. Hierfür gibt es im Detail unterschiedliche Methoden, die auf folgendem Grundprinzip beruhen: Der Daten-Anbieter (40) sendet dem Daten-Interessenten (30) eine Zufalls zahl N. Der Daten-Interessent (30) verschlüsselt oder signiert diese Zahl N mit seinem privaten Schlüssel. Das Ergebnis (Response) wird wiederum an den Daten-Anbieter (40) gesendet, welcher mit dem öffentlichen Schlüssel des Daten-Interessenten verifi zieren kann das die von ihm gewählte Zufallszahl N verschlüsselt oder signiert wurde. Sind die Ergebnisse der beiden Berechnungen identisch, so war die Authentifizierung des Daten-Interessenten (40) erfolgreich, da nur dieser den entsprechenden privaten Schlüssel hat.
Alternativ kann die Identitätsprüfung auch über eine Signatur in der Anfrage des Daten interessenten (30) erfolgen zum Beispiel auf Basis der aktuellen Zeit.
Im Verfahrensschritt (300) sendet der Daten-Anbieter (40) die ersten Daten (22) des Daten- Eigentümers (20) an den Daten-Interessenten (30), falls die Validierung zu ei nem positiven Ergebnis geführt hat.
Im Verfahrensschritt (300) kann auch durch den Daten-Anbieter (40) eine angeforderte Aktion ausgeführt werden. Eine mögliche angeforderte Aktion kann das automatische Öffnen einer verschlossenen Tür (Autotür, Eingangstür, Schließfach usw.) sein, um beispielsweise einem Packet-Boten die Ablage eines Paketes an einem sicheren Ort zu ermöglichen oder um den Zugang zu einem Mietfahrzeug zu ermöglichen.
Die ersten Daten (22) des Daten- Eigentümers (30) können verschlüsselt an den Da ten-Interessenten (30) gesendet werden. Eine Verschlüsselung der ersten Daten (22) des Daten- Eigentümers (20) kann beispielsweise mit dem öffentlichen Schlüssel des Daten-Interessenten (30) erfolgen, so dass nur dieser die ersten Daten (22) mit seinem privaten Schlüssel entschlüsseln kann. Durch die Verschlüsselung können auch ver trauliche Daten über einen unsicheren Kommunikationskanal übertragen werden. In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens kann der Da- ten-lnteressent (30) im optionalen Verfahrensschritt (50) bevor er eine Anfrage an den Daten-Anbieter (40) stellt, eine Filterung nach Einwilligungs-Daten (25) im Smart Contract (10) durch die Referenz zu dem Account des Daten- Eigentümer (20) und zu dem Account des Daten-Interessent (30) durchführen. Auf diese Weise kann er unnö tige Anfragen an den Daten- Eigentümer (20) und den Daten-Anbieter (40) vermeiden, da er im Vorfeld bereits überprüfen kann, ob ein Daten- Eigentümer (20) eine Einwilli gung zum Transfer der ersten Daten (22) gegeben hat.
Wird durch den Daten-Interessenten (30) festgestellt, dass im Smart Contract (10) die benötigten Einwilligungs-Daten (25) fehlen oder nicht vorhanden sind, kann er eine An frage an den Daten- Eigentümer (20) in Bezug auf eine Änderung der im Smart Contract (10) abgelegten Einwilligungs-Daten (25) stellen. Eine solche Anfrage in Be zug auf eine Änderung der im Smart Contract (10) abgelegten Einwilligungs-Daten (25) kann über die Blockchain (12) oder über einen alternativen Kommunikationskanal ge sendet werden.
In einem weiteren Ausführungsbeispiel kann auch der Daten-Anbieter (40) über die Blockchain (12) eine Anfrage an den Daten- Eigentümer (20) in Bezug auf eine Ände rung der im Smart Contract (10) abgelegten Einwilligungs-Daten (25) stellen, wenn er an einer Änderung der Einwilligungs-Daten (25) interessiert ist. Dies kann beispiels weise der Fall sein, wenn er eine Anfrage des Daten-Interessenten (30) erhält und fest stellt, dass im Smart Contract (10) die für den Daten-Transfer benötigten Einwilligungs- Daten (25) fehlen.
Die Einwilligungs-Daten (25) im Smart Contract (10) sind durch die fundamentalen Ei genschaften der Blockchain (12) vor Veränderungen gesichert. Durch die Absicherung innerhalb der Blockchain, beispielsweise durch einen Hash-Wert der den jeweiligen Einwilligungs-Daten (25) zugeordnet ist, können die Einwilligungs-Daten (25) im Nach hinein nicht verändert werden. Werden sie dennoch geändert, werden sie automatisch ungültig, falls der Daten- Eigentümer (20) nicht den neuen Einwilligungs-Daten (25) zu stimmt. Als Blockchain (12) kann die Ethereum-Blockchain eingesetzt werden. Die Blockchain (12) zeichnet sich durch Ihre Manipulationssicherheit, ihre Ausfallsicherheit, ihre Transparenz und Überprüfbarkeit aus, welche einen neuen Ansatz für den Daten- Transfer basierend auf Einwilligungs-Daten (25) ermöglicht.

Claims

Patentansprüche
1. Verfahren zum Transfer von Daten, wobei erste Daten (22) eines Daten-Eigen- tümers (20) auf einem elektrischen Speichermedium (21) eines Daten-Anbieters (40) abgelegt sind und Einwilligungs-Daten (25) des Daten- Eigentümers (20) in Bezug auf die Benutzung, Freigabe und den Transfer der ersten Daten (22) in einem Smart Contract (10) abgelegt werden, welcher Bestandteil einer Blockchain (12) ist, dadurch gekennzeichnet, dass
a) ein Daten-Anbieter (40) eine Anfrage eines Daten- Interessenten (30) erhält, wo bei die Anfrage eine Referenz zu einem Account des Daten- Eigentümer (20) und zu einem Account des Daten-Interessent (30) in der Blockchain (10) ent hält,
b) der Daten-Anbieter (40) eine Validierung der Anfrage mit Hilfe des Smart
Contracts (10) durchführt,
c) der Daten-Anbieter (40) die Daten des Daten- Eigentümers (20) an den Daten interessenten (30) transferiert und/oder eine angeforderte Aktion ausführt, falls die Validierung zu einem positiven Ergebnis geführt hat.
2. Verfahren nach Anspruch 1, wobei im Rahmen der Validierung eine Filterung nach Einwilligungs-Daten (25) im Smart Contract (10) durch die Referenz zu dem Ac count des Daten- Eigentümer (20) und dem Account des Daten-Interessent (30) erfolgt.
3. Verfahren nach Anspruch 1, wobei der Daten-Anbieter (40) im Rahmen der Va lidierung eine Identitätsprüfung in Bezug auf den Daten-Interessenten (30) durchführt.
4. Verfahren nach Anspruch 3, wobei die Identitätsprüfung durch ein Challenge- Request-Verfahren durchgeführt wird.
5. Verfahren nach Anspruch 3, wobei die Identitätsprüfung über eine Signatur in der Anfrage des Daten-Interessenten (40) erfolgt.
6. Verfahren nach Anspruch 1, wobei die ersten Daten (22) des Daten- Eigentü mers (20) verschlüsselt an den Daten-Interessenten (30) gesendet werden.
7. Verfahren nach Anspruch 6, wobei die ersten Daten (22) des Daten- Eigentü mers (20) mit dem öffentlichen Schlüssel des Daten-Interessenten (30) verschlüsselt werden, so dass sie nur durch dessen privaten Schlüssel entschlüsselbar sind. 8. Verfahren nach Anspruch 1, wobei vor dem Schritt a) durch den Daten-Interes- senten (30) eine Filterung nach Einwilligungs-Daten (25) im Smart Contract (10) durch die Referenz zu dem Account des Daten- Eigentümer (20) und dem Account des Daten interessent (30) erfolgt. 8. Verfahren nach Anspruch 1, wobei über die Blockchain (10) eine Anfrage des
Daten-Interessenten (30) oder des Daten-Anbieters (40) an den Daten- Eigentümer (20) in Bezug auf eine Änderung der im Smart Contract (10) abgelegten Einwilligungs-Daten (25) gestellt wird. 9. Verfahren nach einem der vorherigen Ansprüche, wobei die Einwilligungs-Daten
(25) innerhalb des Smart Contract (10) vor nachträglichen Veränderung ohne die Zu stimmung des Daten- Eigentümers (30) gesichert sind.
10. Verfahren nach einem der vorherigen Ansprüche, wobei als Blockchain (12) die Ethereum-Blockchain eingesetzt wird.
PCT/EP2020/054021 2019-02-21 2020-02-17 Verfahren zum transfer von daten WO2020169502A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019202381.9A DE102019202381A1 (de) 2019-02-21 2019-02-21 Verfahren zum Transfer von Daten
DE102019202381.9 2019-02-21

Publications (1)

Publication Number Publication Date
WO2020169502A1 true WO2020169502A1 (de) 2020-08-27

Family

ID=69593698

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/054021 WO2020169502A1 (de) 2019-02-21 2020-02-17 Verfahren zum transfer von daten

Country Status (2)

Country Link
DE (1) DE102019202381A1 (de)
WO (1) WO2020169502A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018019364A1 (en) * 2016-07-26 2018-02-01 NEC Laboratories Europe GmbH Method for controlling access to a shared resource
US20180060496A1 (en) * 2016-08-23 2018-03-01 BBM Health LLC Blockchain-based mechanisms for secure health information resource exchange
CN108134822A (zh) * 2017-12-15 2018-06-08 成都链网络科技有限公司 基于区块链的存储系统的下载方法
US20180248880A1 (en) * 2017-02-24 2018-08-30 Verizon Patent And Licensing Inc. Permissions using blockchain

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018019364A1 (en) * 2016-07-26 2018-02-01 NEC Laboratories Europe GmbH Method for controlling access to a shared resource
US20180060496A1 (en) * 2016-08-23 2018-03-01 BBM Health LLC Blockchain-based mechanisms for secure health information resource exchange
US20180248880A1 (en) * 2017-02-24 2018-08-30 Verizon Patent And Licensing Inc. Permissions using blockchain
CN108134822A (zh) * 2017-12-15 2018-06-08 成都链网络科技有限公司 基于区块链的存储系统的下载方法

Also Published As

Publication number Publication date
DE102019202381A1 (de) 2020-08-27

Similar Documents

Publication Publication Date Title
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
DE102012110499B4 (de) Sicherheitszugangsverfahren für elektronische Automobil-Steuergeräte
EP2332313B1 (de) Verfahren zur speicherung von daten, computerprogrammprodukt, id-token und computersystem
DE102015202308A1 (de) Computerimplementiertes Verfahren zur Zugriffskontrolle
EP3748521B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3649625B1 (de) Verfahren zur delegation von zugriffsrechten
EP1209579A1 (de) System zur automatisierten Abwicklung von Transaktionen durch aktives Identitätsmanagement
DE102016104530A1 (de) Verfahren zur Kontrolle des Zugriffs auf Fahrzeuge
AT504581B1 (de) Verfahren und system zum auslesen von daten aus einem speicher eines fernen geräts durch einen server
EP3295354A1 (de) Verfahren und vorrichtung zur authentifizierung eines dienstnutzers für eine zu erbringende dienstleistung
DE102010010760B4 (de) Verfahren zur Vergabe eines Schlüssels an ein einem drahtlosen Sensor-Aktor-Netz neu hinzuzufügendes Teilnehmergerät
WO2018166942A1 (de) Verfahren zur zugangskontrolle
WO2020169502A1 (de) Verfahren zum transfer von daten
EP3298526B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP2491513B1 (de) Verfahren und system zum bereitstellen von edrm-geschützten datenobjekten
EP3117359B1 (de) Id-provider-computersystem, id-token und verfahren zur bestätigung einer digitalen identität
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
EP3186741B1 (de) Zugriffsschutz für fremddaten im nichtflüchtigen speicher eines tokens
EP3283999B1 (de) Elektronisches system zur erzeugung eines zertifikats
EP1054364A2 (de) Verfahren zur Erhöhung der Sicherheit bei digitalen Unterschriften
DE102014014109A1 (de) Transaktionsverfahren
EP3977371A1 (de) Verfahren und kontrollgerät zur sicheren überprüfung eines elektronischen tickets
DE202021100647U1 (de) Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token
DE102012106081A1 (de) Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien
DE102020105529A1 (de) Verfahren zur selektiven Bereitstellung von Daten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20705696

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20705696

Country of ref document: EP

Kind code of ref document: A1