WO2021175805A1 - Verfahren zur selektiven bereitstellung von daten - Google Patents

Verfahren zur selektiven bereitstellung von daten Download PDF

Info

Publication number
WO2021175805A1
WO2021175805A1 PCT/EP2021/055097 EP2021055097W WO2021175805A1 WO 2021175805 A1 WO2021175805 A1 WO 2021175805A1 EP 2021055097 W EP2021055097 W EP 2021055097W WO 2021175805 A1 WO2021175805 A1 WO 2021175805A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
blockchain
request
authorization
provision
Prior art date
Application number
PCT/EP2021/055097
Other languages
English (en)
French (fr)
Inventor
Markus JOSTOCK
Original Assignee
ARXUM 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 ARXUM GmbH filed Critical ARXUM GmbH
Publication of WO2021175805A1 publication Critical patent/WO2021175805A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9024—Graphs; Linked lists
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Definitions

  • a method for the selective provision of data is described here.
  • the selective provision of data takes place very regularly, for example, between different companies in a supply chain.
  • a typical use case is that a company wants to request information about individual parts from a supplier that it has built into its products. Such a case often occurs when, for example, problems arise with the individual parts of the supplier or at least indicate themselves and that the company processing the individual parts would like to receive the information about the individual parts available from the manufacturer.
  • the company that manufactured the individual parts is the company providing the data or the data provider and the company that has processed the supplied parts is the company requesting the data or the data requestor.
  • the data requestor has an interest in being able to receive the data he needs quickly and reliably (preferably automated) and without annoying waiting times.
  • the data provider has an interest in only providing the data that the data requester is actually entitled to receive.
  • the data provider also has an interest in knowing the exact level of detail of the requested data and, if necessary, only releasing data in the level of detail that the data requestor is actually entitled to receive.
  • the aim here is to describe a method for the selective provision of data from a confidential data store of a data provider with a data delivery module comprising the following steps: a) Receiving a request from a data requestor regarding the provision of partial data from the confidential data store, the request having at least one data identification parameter to identify the partial data; b) Using a blockchain to check whether the request was checked against a set of rules stored in the blockchain by the data provider and classified as legitimate; c) If the request was classified as legitimate, provision of the partial data requested for provision to the data requestor.
  • the method can be used, for example, for the relationships described above between manufacturers of individual parts as data providers and processors of these individual parts as supplier parts in higher production stages as data requesters.
  • the method can also be used in many other constellations.
  • the method can be used in supply chains in the automotive industry or comparable industries. In such supply chains there is often a need to request production data relating to purchased individual parts from a supplier in order, for example, to control processing processes for the individual parts as a function of such data.
  • the data provider and supplier has no interest in a buyer or data requestor of individual parts being able to receive production data on individual parts, that have been delivered to another buyer.
  • the procedure described here is extremely helpful. Both parties are very interested in exchanging data, for example to prove delivery of guaranteed quality and to differentiate between warranty claims.
  • the method described is carried out with a data provision module which is arranged in or on a confidential sphere of the data provider or which provides an access option to the confidential data memory.
  • the data provision module has communication interfaces to the outside via which inquiries relating to certain data can be received and via which data can also be made available.
  • the communication interfaces of the data provision module can be connected to the Internet, for example.
  • the data provision module can particularly preferably be implemented behind a kind of firewall or a comparable hardware component of the data provider or be directly connected to such a component, the communication interfaces of the data provision module then preferably being set up in such a way that they are via the firewall or the comparable Hardware components communicate with the environment.
  • the confidential data store is a data store that is under the (sole) responsibility and (sole) control of the data provider. It can be, for example, a data memory in a server on a factory site of the data provider, which is not accessible from the outside. Such a server can, however, also be arranged in a data center and protected against unauthorized access by means of standard security measures.
  • a request is received from the data requestor regarding the provision of partial data.
  • the request can be sent directly from the data requestor are received, for example via the communication interfaces described, in which case it is preferred that the data provider permanently listens to these communication interfaces to determine whether data is being provided.
  • the request can also be received indirectly from the data requestor. Indirect reception can be achieved, for example, in that the data requester permanently checks or listens at a certain location to see whether queries from the data requester that are directed to the respective data provider or to the respective data provision module are stored there.
  • Such a place can be, for example, a blockchain in which data requests from the data requestor are entered.
  • This blockchain is preferably, but not necessarily, a privately operated blockchain, which is publicly available in preferred versions and whose set of rules can be viewed and evaluated by the data requestor.
  • This blockchain is preferably operated on hardware that is completely independent of the data provision module and, in particular, is also independent of hardware on which the data provision module is operated.
  • the blockchain can be designed in such a way that each participant (data requestor and / or data provider) can create copies of the blockchain in order to be able to use these copies to carry out checks of inquiries and / or other validations.
  • the request in step a) can, for example, be written to the blockchain as a transaction. Detailed explanations are given below regarding the possibilities resulting from this.
  • step a) the request is made with at least one data identification parameter to identify the partial data.
  • a data identification parameter is preferably an ID via which the desired partial data can be identified.
  • Data identification parameters can include, for example, a part number and / or a serial number of a supplier part.
  • the partial data can include, for example, specific data (parameters from production, test data, or the like) for this supplier part.
  • the check on the basis of the blockchain as to whether the request was classified as authorized with a set of rules stored in the blockchain by the data provider in step b) is preferably carried out implicitly.
  • the check can already be implemented, for example, by determining that the respective data request from step a) has been successfully entered in the blockchain. If the data request was received directly from the blockchain, for example in which the blockchain is permanently monitored by the data provision module, the check can already be carried out implicitly by the fact that the request was successfully received from the blockchain.
  • This type of implicit check of a request based on a set of rules stored in the blockchain is carried out, for example, by assuming that a request entered in the blockchain has only been entered in the blockchain if this request has also been classified as authorized with the set of rules .
  • step b) includes the validation of this preliminary check.
  • the validation of this preliminary check can also be carried out by using the knowledge that data requests stored at the storage location (blockchain) basically had to be classified as legitimate on the basis of the set of rules.
  • the set of rules stored in the blockchain is preferably stored in the blockchain in the form of a smart contract.
  • the set of rules is preferably created by the data provider and written to the blockchain (in the form of a smart contract).
  • the set of rules cannot be changed and, in particular, cannot be changed by the data requestor. the bear.
  • the set of rules can at best be changed by means of a set of rules update, which is written to the blockchain by the data provider in the form of a new smart contract. Only the data provider has the necessary authorizations for a rule set update on the blockchain.
  • step c) The partial data requested in step c) are only provided if the request has been classified as legitimate. In the following, further details are given on how the data can be provided in an advantageous manner.
  • the type of data provision described here has far-reaching advantages:
  • the data can be checked using the blockchain or carried out by the blockchain itself. Upstream of the described process steps a) to c), which are carried out with the data provision module, the sent request or request transaction is verified as valid based on the set of rules (authorization check) stored in the smart contract and is only written to the blockchain in this case or included in a block.
  • the request is entered in the blockchain or in a block of the blockchain, the request is irrevocably persisted. In the event that the request could not be verified as valid because it violates the rules in the smart contract, the request is rejected.
  • This processing step preceding the method described here is preferably carried out completely outside of the data processing module and independently of the data processing module. As already described above, the test in step b) preferably relies on this preliminary test.
  • step b) relies completely on the processes in the block chain (preliminary check or successful entry of the request in a block of the blockchain), it can be achieved that no more checking of the authorization of a request in the data provision module is required. Only if the request has been checked as valid is it written to the blockchain as a request transaction.
  • step c) comprises the following subscrip- tions when requested partial data is provided: cl) reading in the requested partial data from the confidential data memory with the aid of the at least one data identification parameter; c2) Encryption of the partial data that has been read in, so that encrypted partial data arise and the provision of the encrypted partial data on a data transfer platform.
  • step cl in particular, an automated collection of the requested partial data in the company becomes possible. Due to the upstream check in step b) using the blockchain, the data provision module can rely 100 percent on the request received in step a). For this reason, new possibilities for automating the reading in of the desired partial data are made possible.
  • the reading in of partial data can in particular take place without manual processing steps controlled by a (human) operator. This is where there is great potential for economic savings.
  • Step c2) includes two sub-steps, namely the encryption and the provision of the encrypted (partial) data.
  • the encryption ensures that no third party can read the data provided.
  • the second step in the sense of a data “PUSH” process, leads from the secure company area to the data transfer platform, which preferably provides a public memory for the data. Because the data is made available on the data transfer platform, external partners (data requesters) never have to Access to the internal data in the confidential data store or another, possibly temporary, non-confidential internal data store can be granted. In this way, a considerable increase in the data security of the data in the confidential memory can be achieved.
  • a symmetric key is generated in step c2) and the requested partial data is encrypted with the symmetric key before being made available on the data transfer platform and the symmetric key is made available to the data requester via a secure channel.
  • the data requestor is not provided with the data directly, but the (secret) location is transmitted here, where the data was stored on the public data transfer platform.
  • the (secret) location is transmitted here, where the data was stored on the public data transfer platform.
  • the symmetrical key is encrypted with a public key of a key pair of the data requestor and made available in the block chain.
  • the public key of the key pair of the data requestor can be made available by the data requestor so that it can be called up by the data provider.
  • An electronic signature or similar measures can also ensure that the public key of the data requestor can be clearly assigned to the data requestor and that no identity forgery (or no man-in-the-middle attack) can take place here.
  • the symmetric key is preferred as a package consisting of the symmetric key and a checksum with the public key of the data encrypted and made available via the blockchain.
  • This package may also contain information about the storage location of the encrypted partial data.
  • the data requestor receives the encrypted symmetric key or this package via the blockchain, in which the data requestor listens to the blockchain or monitors the blockchain and reacts if the key or the package appears here with a reference to its previously placed request. With the content of this package, the data requestor can now find the requested partial data, decrypt it and, if necessary, check the authenticity of this data using the checksum.
  • the method is also advantageous if the set of rules contains at least one first authorization definition which defines the partial data that the data requestor is authorized to access and where a request is only classified as authorized if the at least one first authorization definition is fulfilled.
  • Such authorization definitions are also in the blockchain.
  • Such an authorization definition which defines partial data, can, for example, use the data identification parameter to identify whether a request is authorized.
  • the data identification parameter can be certain
  • Address number ranges with individual partial data packets being assigned to data identification parameters within this number range.
  • the number ranges can, for example, be assigned to individual customers of the data provider. For example, vendor parts with a part number starting with 1 can be assigned to a first customer, vendor parts for a second customer with a number starting with 2, and so on. The part number can serve as a data identification parameter for the customers.
  • the first authorization definition can stipulate that this customer only has partial data on vendor parts with customer number starting with 1.
  • customer number For the second customer as the data requestor, it can be customer numbers starting with 2 and so on.
  • the check with the first authorization definition ensures that the data requester can only request partial data from products that were also delivered to him.
  • the data requestor cannot request partial data from products that have been supplied to competitors, for example (and which may have a different quality or other different properties).
  • the method is also advantageous if the set of rules contains at least one second authorization definition which contains a maximum number of requests and / or a maximum amount of data that a data requestor may request in a predetermined time interval and a request is only classified as authorized if if the at least one second authorization definition is fulfilled.
  • a maximum number of data requests or a maximum amount of data per day, week or month can be specified.
  • Such a second authorization definition can in particular prevent systematic access to large amounts of data.
  • Such a second authorization definition greatly reduces manual effort, but also circumvents manual control.
  • the data provider since the data provider is interested in automatically transmitting partial data from his products to the data requestor, the data provider can limit the number of automated transmissions.
  • the limitation can, for example, be limited to a percentage of the products delivered or to a number that is in the usual statistical justifies a request for data.
  • Limitations stored in the second authorization definition can, if necessary, also be increased or even canceled upon explicit request if the data provider agrees to this.
  • the request for the increase and a possible declaration of consent or rejection of this request by the data requestor can also be made via the blockchain.
  • the procedure is particularly premature if the set of rules contains at least one third authorization definition that defines a level of detail of the partial data that a data requestor may call up and whereby a request is only classified as authorized if the at least one third authorization definition is met.
  • Such third authorization definitions enable an extended authorization function for certain partial data. For example, it could be that for a further level of detail of data with a higher data volume, higher resolution, lower data hierarchy, a different maximum amount of data is defined that a data requester is allowed to retrieve than for the standard detail level. For example, it can be defined that a data requestor may make 1,000 data requests with a low level of detail per week, but only 10 data requests with a high level of detail. Since the authorization definitions are on the blockchain, the data requestor alone (without the consent of the data provider) cannot influence the authorization definitions.
  • the authorization definitions may be on a public blockchain, but that does not mean that they can be interpreted. If, for example, the authorization function is implemented in such a way that it checks certain serial numbers for which a data requestor is authorized to request data (first authorization definitions), then one possible implementation is to store the authorized serial numbers in a list on the blockchain. This implicitly means that if the recipient is known, it would be publicly known which products with which serial numbers were delivered to this recipient. However, another method than an (open) list can also be used on a blockchain: The serial numbers can also be stored in a so-called cryptographic accumulator, which provides the response of a "membership" for a specific number / ID in a group, without disclosing the list of members of the group.
  • the authorization is checked in step b) using the blockchain by checking whether the request was validated by the blockchain and included in the blockchain.
  • This method has an enormous economic benefit: On the one hand, the transmission of protected data from an environment of the data provider can be fully automated, whereby a high cost saving potential can be realized. On the other hand, this process gives the data provider full control over the rules of automated data transmission.
  • data is automatically transmitted without manual checking, no data requestor can obtain data in an uncontrolled manner.
  • the data requests from the data requestor are actually checked in the blockchain by so-called block creators (often also block producers) who check every data request (as a transaction) or any other information (as a transaction) that is to be written to the blockchain . This request is only written to the blockchain if the data request meets all requirements and, in particular, the rules and regulations provided for the respective request.
  • the method is particularly advantageous if, apart from checking the authorization in step b) using the blockchain, there is no further authorization check.
  • the method is particularly preferred when requests are stored in the blockchain in encrypted form and / or with a hash value.
  • a data provision module set up to exchange data with a public blockchain and set up to carry out the described method is also to be described here.
  • the particular advantages and design features of the method described above can be used and transferred to the data provision module described. Details on the structure of the data provision module are disclosed in the fol lowing in connection with the figures.
  • Also to be described here is a computer program product comprising such a data supply module or a data supply module set up for carrying out the described method.
  • a storage medium on which such a computer program product is stored is also described.
  • the aim of the method described here is, in particular, not to store the broad data in question (e.g. documents relating to components) in blocks of the block chain. Rather, the blockchain actually only serves to regulate access here. Combined storage of access attributes and data in the blockchain is also not explicitly recorded with the method described here.
  • the blockchain itself is devoid of the data in question to which access is to be provided. It only contains authorization definitions for access to data and, if applicable, data relating to requests from data requesters to the data provider and their permissibility or also keys and / or addresses for access to data. For this reason, it is possible to work with a very compact blockchain whose total amount of data does not grow very rapidly even with the described method being operated over time.
  • authorization definitions are stored in the blockchain, which preferably do not make sense on their own, but rather develop a meaning or meaning in connection with the provision of data by the data provider to have.
  • authorization definitions stored in the blockchain can be extremely complex.
  • Such authorization definitions are preferably generated automatically according to the specifications with the help of special processes, these specifications including, in particular, framework conditions:
  • the confidential data memory that is used here is preferably structured in the classic way like a conventional database.
  • the confidential data Storage does not have any blockchain-specific features.
  • Data are stored in a structured manner, for example, in the form of partial data / data records and can be called up using IDs or data identification parameters.
  • data can also be stored in the form of a tree or folder structure.
  • To use the method described it is in particular not necessary for a data storage concept to be specially designed. Rather, with the method described, it is possible to use the security of the publicly available blockchain to which the data requestor can access, without having to use a special structure for storing the data in the confidential data memory.
  • the method described takes over the mediation between the blockchain and the confidential data memory.
  • what is meant in particular is the mediation between the type and structure of the authorization definitions stored in the blockchain and the structure of the data storage in the confidential data memory.
  • This enables the method described to be based in particular on an existing infrastructure (an existing confidential data memory).
  • no complete restructuring / adaptation of data that are stored in a confidential data memory is required in order to use the method described. Rather, it is only necessary to set up the data provision module accordingly.
  • the data in the confidential data store is (although confidential) usually not encrypted either. It is an advantage of the method that, due to the provision of data with the described data provision module, encrypted storage of the data can be dispensed with.
  • a blockchain is preferably used that is not validated or certified by a public certificate structure, but is preferably a blockchain that is provided by a private entity (possibly also the data provider himself or a consortium of several Data provider) has been started and is operated on public nodes.
  • the blockchain can be checked by any data inquirer and the blockchain is used in the process described as a technology to make data from the confidential data storage available in accordance with defined rules.
  • a certification structure is preferably not behind the blockchain.
  • the creation and provision of authorization definitions in the Blockhain is preferably carried out exclusively in accordance with the specifications of the data provider.
  • the data provider writes the authorization definitions in the blockchain.
  • the method described here preferably works independently of a consensus mechanism in the blockchain.
  • the purpose of the blockchain in the procedure described here is to provide the public with security against manipulation, but not to achieve consensus on the definition of authorizations.
  • FIG. 2 a second schematic flow diagram of a described method with the procedural actors involved.
  • the data provider 1 is shown above, which is arranged here next to the confidential data memory 2.
  • the confidential data memory 2 is arranged, for example, on a server or in a factory.
  • data 4 which, for example, can include a multiplicity of partial data 9, partial data 9 of the data 4 each being identifiable with a data identification parameter 12.
  • the data provider is the owner of the data 4 and thus also of the partial data 9 that make up the data 4.
  • the data provider 1 writes an authorization definition 6 in a blockchain 5.
  • the blockchain 5 consists of a large number of successive blocks 10 in which a large number of data can be stored in the form of transactions.
  • Transactions in blocks 10 can in particular be the rules 13 described, validated requests 14 or other data such as public keys 15 and symmetrical keys 17 for encrypting data.
  • the authorization definition 6 can be part of a set of rules 13 according to which data can be made available from the confidential data memory 2 and which can include, for example, first authorization definitions 18, second authorization definitions 19 or third authorization definitions 20.
  • a data requester 7 is shown below the blockchain.
  • the data requester 7 can transmit a request 8 for the provision of certain partial data 9 to the blockchain 5, such a request also containing a data identification parameter 12 with which the respective partial data can be identified.
  • This request 8 is written as a validated request 14 in the blockchain 5, provided that the request matches the set of rules 13.
  • the request 8 with the data identification parameter 12 arrives via the blockchain 5 to a data provision module which is arranged on the confidential data memory 2.
  • An authorization check 21 takes place, which can also take place implicitly in that the request 8 is only sent via the blockchain 5 to the data provision module 3 arrives when this has been written to blockchain 5 as a validated request.
  • the receipt of the request by the data provision module 3 corresponds to step a) of the method described. Checking whether the request complies with the set of rules (whether explicit or implicit) essentially corresponds to step b) of the method described.
  • Encrypted partial data 22 are sent to a data transfer platform 11, where they are available for retrieval by the data requestor 7.
  • a symmetrical key 17, with which the partial data 9 have been encrypted, can also be transmitted to the data requestor 7 via the blockchain 5 so that the latter can decrypt the encrypted partial data 22.
  • the symmetrical key 17 can be encrypted with a public key 15 of the data requester 7, which is also provided via the blockchain.
  • the data provision module 3 preferably has an encryption module 23. With the private (secret) key 16 of the data requestor, the latter can then first decrypt the symmetrical key 17 and the secret storage location (data transfer platform) 11 in order to then decrypt the encrypted partial data 22.
  • the provision of data described here corresponds to step c) of the described method with the individual sub-steps c1) and c2).
  • the described method is shown in a somewhat different representation, namely in the form of a flow chart.
  • the data requestor 7 first makes the request 8, which is then transferred to the blockchain 5 in which a request check 24 takes place.
  • the query test 24 can lead either to an accepted path 26 or to a rejected path 27, the rejected path ending with the termination 28 of the method. If the request 8 is accepted, the accepted path 26 is followed and the request was saved 25.
  • the request is then received by the data provider 1 or its data provision module 3. this takes place with the block "read request 29". An additional explicit validation of the request is not carried out. Due to the fact that the request comes from Blockhain 5, the request is trusted.
  • the partial data is then put together 30 with an encryption of the partial data.
  • the key packet storage 32 takes place in the blockchain 5.
  • the secure storage of the partial data 31 is carried out by the data provision module 3 on a data transfer platform (secret storage location) 11 not shown here.
  • the stored partial data 31 and the stored key packet 32 can now be processed by the data inquirer 7. Key packets are read in 33 and the data 34 are loaded and decrypted.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren zur selektiven Bereitstellung von Daten (4) aus einem vertraulichen Datenspeicher (2) eines Datenbereitstellers (1) mit einem Datenbereitstellungsmodul (3) aufweisend die folgenden Schritte: a) Empfangen einer Anfrage (8) von einem Datenanfrager (7) bezüglich der Bereitstellung von Teildaten (9) aus dem vertraulichen Datenspeicher (2), wobei die Anfrage mindestens einen Datenidentifzierparameter (12) zur Identifizierung der Teildaten (9) beinhaltet; b) Prüfen anhand einer Blockchain (5), ob die Anfrage (8) mit einem von dem Datenbereitsteller (1) in der Blockchain (5) hinterlegten Regelwerks (13) geprüft und als berechtigt eingestuft wurde; c) Sofern die Anfrage (8) als berechtigt eingestufte wurde, Bereitstellung der zur Bereitstellung angefragten Teildaten (9) an den Datenanfrager (7).

Description

Verfahren zur selektiven Bereitstellung von Daten
Hier beschrieben wird ein Verfahren zur selektiven Bereitstellung von Daten. Die selektive Bereitstellung von Daten erfolgt beispielsweise sehr regelmäßig zwischen verschiedenen Unternehmen in einer Lieferkette. Ein typischer Anwendungsfall ist, dass ein Unternehmen Informationen über Einzelteile eines Zuliefe rers anfordem will, welche es in seinen Produkten verbaut hat. Ein solcher Fall kommt häufig vor, wenn beispielsweise Probleme mit den Einzelteilen des Zulieferers auftreten oder sich zumindest andeuten und dass die Einzelteile verarbeitende Unternehmen die beim Hersteller verfügbaren Informationen über die Einzel teile erhalten möchte. In diesem Fall ist das Unternehmen, welches die Einzelteile hergestellt hat, das Daten bereitstellende Unternehmen bzw. der Datenbereitsteller und das Unternehmen, welches die Zulieferteile verarbeitet hat, das Daten anfragende Unternehmen bzw. der Datenanfrager.
In dieser Beziehung hat der Datenanfrager ein Interesse daran, die von ihm benötigten Daten schnell und zuverlässig (am besten automatisiert) und ohne lästige Wartezeiten erhalten zu können. Der Datenbereitsteller hat ein Interesse daran, nur die Daten bereitzustellen, die der Datenanfrager tatsächlich berechtigt ist zu erhalten. Der Datenbereitsteller hat ebenfalls ein Interesse daran, die Detailtiefe der angefragten Daten genau zu kennen und gegebenenfalls auch nur Daten in der Detailtiefe herauszugeben, die der Datenanfrager tatsächlich berechtigt ist zu er halten.
Es sind sehr viele unterschiedliche Situationen denkbar, in denen vergleichbare Interessen des Datenbereitstellers und des Datenanfragers einander gegenüber stehen und in welchen ein Verfahren zur selektiven Bereitstellung von Daten hilf reich ist, mit welchem diese Interessen berücksichtigt werden können. Hiervon ausgehend ist es Aufgabe der vorliegenden Erfindung ein Verfahren zur selektiven Bereitstellung von Daten zu beschaffen, welches die sich aus der Be ziehung von Datenbereitsteller und Datenanfrager ergebenden Herausforderungen in innovativer Weise löst.
Hier beschrieben werden soll ein Verfahren zur selektiven Bereitstellung von Da ten aus einem vertraulichen Datenspeicher eines Datenbereitstellers mit einem Datenbereitstellungsmodul aufweisend die folgenden Schritte: a) Empfangen einer Anfrage von einem Datenanfrager bezüglich der Bereitstellung von Teildaten aus dem vertraulichen Datenspeicher, wobei die Anfrage mindestens einen Datenidentifizierparameter zur Identifizierung der Teildaten beinhaltet; b) Prüfen anhand einer Blockchain, ob die Anfrage mit einem von dem Datenbereitsteller in der Blockchain hinterlegten Regelwerks geprüft und als berech tigt eingestuft wurde; c) Sofern die Anfrage als berechtigt eingestufte wurde, Bereitstellung der zur Bereitstellung angefragten Teildaten an den Datenanfrager.
Das Verfahren ist beispielsweise für die weiter oben beschriebenen Beziehungen zwischen Herstellern von Einzelteilen als Datenbereitsteller und Verarbeitern dieser Einzelteile als Zuliefererteile in höheren Produktionsstufen als Datenanfrager anwendbar. Das Verfahren ist auch in vielen anderen Konstellationen anwendbar. Insbesondere ist das Verfahren in Lieferketten der Automobilindustrie oder vergleichbarer Industrien anwendbar. In solchen Lieferketten besteht häufig der Bedarf, Produktionsdaten bezüglich eingekaufter Einzelteile von einem Zulieferer anzufragen, um in Abhängigkeit derartiger Daten beispielsweise auch Verarbei tungsprozesse der Einzelteile zu steuern. In diesen Anwendungsfällen hat der Da tenbereitsteller und Zulieferer allerdings kein Interesse daran, dass ein Käufer bzw. Datenanfrager von Einzelteilen Produktionsdaten über Einzelteile erhalten kann, die an einen anderen Käufer geliefert wurden. In dieser Konstellation ist das hier beschriebene Verfahren äußerst hilfreich. Beide Parteien haben ein hohes Interesse an einem Datenaustausch, um z.B. die Lieferung zugesicherter Qualität nachzu weisen und Gewährleistungsansprüche gegeneinander abzugrenzen.
Das beschriebene Verfahren wird mit einem Datenbereitstellungsmodul ausgeführt, welches in bzw. an einer vertraulichen Sphäre des Datenbereitstellers ange ordnet ist bzw. welches eine Zugangsmöglichkeit zu dem vertraulichen Datenspeicher bereitstellt. Das Datenbereitstellungsmodul hat allerdings Kommunikationsschnittstellen nach außen, über die Anfragen bezüglich bestimmter Daten empfangen werden können und über die auch die Bereitstellung von Daten erfolgen kann. Die Kommunikationsschnittstellen des Datenbereitstellungsmoduls können beispielsweise an das Internet angeschlossen sein. Das Datenbereitstellungsmodul kann besonders bevorzugt hinter einer Art Firewall oder einer vergleichbaren Hardware-Komponente des Datenbereitstellers implementiert sein oder unmittel bar an eine solche Komponente angeschlossen sein, wobei dann bevorzugt die Kommunikations Schnittstellen des Datenbereitstellungsmoduls derart eingerichtet sind, dass diese über die Firewall bzw. die vergleichbare Hardwarekomponente mit der Umgebung kommunizieren.
Der vertrauliche Datenspeicher ist in üblichen Ausführungsvarianten des beschriebenen Verfahrens ein Datenspeicher, der unter der (alleinigen) Verantwortung und (alleinigen) Kontrolle des Datenbereitstellers steht. Es kann sich beispielsweise um einen Datenspeicher in einem Server in einem Werksgelände des Datenbereitstellers handeln, der von außen nicht zugänglich ist. Ein solcher Server kann aber auch in einem Rechenzentrum angeordnet sein und über übliche Sicherheitsmaßnahmen gegen unberechtigte Zugriffe geschützt sein.
In Schritt a) wird eine Anfrage von dem Datenanfrager bezüglich der Bereitstellung von Teildaten empfangen. Die Anfrage kann direkt von dem Datenanfrager empfangen werden, beispielsweise über die beschriebenen Kommunikationsschnittstellen, wobei dann bevorzugt ist, dass der Datenbereitsteller an diesen Kommunikations Schnittstellen permanent horcht, ob Daten bereitgestellt werden. Die Anfrage kann auch indirekt von dem Datenanfrager empfangen werden. Ein indirekter Empfang kann beispielsweise dadurch erreicht werden, dass der Datenanfrager permanent an einem bestimmten Ort prüft bzw. horcht, ob Anfragen des Datenanfragers dort abgelegt werden, die an den jeweiligen Datenbereitsteller bzw. an das jeweilige Datenbereitstellungsmodul gerichtet sind.
Ein solcher Ort kann beispielsweise eine Blockchain sein, in welcher Datenanfragen des Datenanfragers eingetragen werden.
Bei dieser Blockchain handelt es sich bevorzugt aber nicht notwendigerweise um eine privat betriebene Blockchain, die in bevorzugten Ausfährungsvarianten öffentlich verfügbar ist und deren Regelwerk für den Datenanfrager einsehbar und auswertbar ist. Diese Blockchain wird bevorzugt auf einer Hardware betrieben, die komplett unabhängig von dem Datenbereitstellungsmodul ist und insbesondere auch unabhängig ist von einer Hardware, auf der das Datenbereitstellungsmodul betrieben wird. Die Blockchain kann so ausgeführt sein, dass jeder Teilneh mer (Datenanfrager und/oder Datenbereitsteller) sich Kopien der Blockchain erstellen kann, um anhand dieser Kopien, Prüfungen von Anfragen und/oder sonstige Validierungen vornehmen zu können.
Die Anfrage in Schritt a) kann beispielsweise als eine Transaktion in die Blockchain geschrieben werden. Zu den sich hierdurch ergebenden Möglichkeiten folgen weiter unten noch detaillierte Erläuterungen.
In Schritt a) erfolgt die Anfrage mit mindestens einem Datenidentifizierparameter zur Identifikation der Teildaten. Ein solcher Datenidentifizierparameter ist bevorzugt eine ID, über die die gewünschten Teildaten identifizierbar sind. Ein solcher Datenidentifizierparameter kann beispielsweise eine Teilenummer und/oder eine Seriennummer eines Zuliefererteils umfassen. Die Teildaten können beispielsweise bestimmte Daten (Parameter aus der Herstellung, Prüfdaten, oder Ähnliches) für dieses Zuliefererteil umfassen.
Die Prüfung anhand der Blockchain, ob die Anfrage mit einem von dem Datenbereitsteller in der Blockchain hinterlegten Regelwerk als berechtigt eingestuft wur de in Schritt b) erfolgt bevorzugt implizit. Die Prüfung kann beispielsweise schon dadurch realisiert werden, dass festgestellt wurde, dass die jeweilige Datenanfrage aus Schritt a) erfolgreich in die Blockchain eingetragen wurde. Wenn die Datenanfrage unmittelbar aus der Blockchain empfangen wurde, bspw. in dem die Blockchain von dem Datenbereitstellungsmodul permanent überwacht wird, kann die Prüfung implizit bereits schon dadurch erfolgen, dass die Anfrage erfolgreich aus der Blockchain empfangen wurde. Diese Art der impliziten Prüfung einer Anfrage anhand eines in der Blockchain hinterlegten Regelwerks erfolgt beispiels weise dadurch, dass davon ausgegangen wird, dass eine in die Blockchain eingetragene Anfrage nur dann in die Blockchain eingetragen wurde, wenn diese Anfrage auch mit dem Regelwerk als berechtigt eingestuft wurde. Es erfolgt also zunächst eine Vorprüfung der Anfrage in der Blockchain anhand des hinterlegten Regelwerks und die Prüfung in Schritt b) umfasst das Validieren dieser Vorprüfung. Dabei kann die Validierung dieser Vorprüfung auch dadurch erfolgen, dass auf das Wissen darüber zurückgegriffen wird, dass an dem Ablageort (Blockchain) hinterlegte Datenanfragen grundsätzlich als anhand des Regelwerks als berechtigt eingestuft werden mussten.
Das in der Blockchain hinterlegte Regelwerk ist bevorzugt in Form eines Smart- Contracts in der Blockchain hinterlegt. Bevorzugt ist das Regelwerk von dem Da tenbereitsteller erstellt und (in Form des Smart-Contracts) in die Blockchain ge schrieben worden. Als in die Blockchain geschriebener Smart-Contract ist das Regelwerk nicht abänderbar und insbesondere für den Datenanfrager nicht abän- derbar. Das Regelwerk ist allenfalls durch ein Regelwerkupdate, welches vom Datenbereitsteller in Form eines neuen Smart-Contracts in die Blockchain geschrieben wird, abänderbar. Ausschließlich der Datenbereitsteller hat die notwendigen Berechtigungen für ein Regelwerkupdate auf der Blockchain.
Die Bereitstellung der angefragten Teildaten in Schritt c) erfolgt nur, sofern die Anfrage als berechtigt eingestuft wurde. Im Folgenden werden weitere Details dazu ausgeführt wie die Bereitstellung der Daten in vorteilhafter Weise erfolgen kann.
Die hier beschriebene Art der Bereitstellung von Daten hat weitreichende Vorteile: Die Überprüfung der Daten wird anhand der Blockchain möglich bzw. durch die Blockchain selbst durchgeführt. Vorgelagert zu den beschriebenen Verfahrensschritten a) bis c), die mit dem Datenbereitstellungsmodul ausgeführt werden, wird die gesendete Anfrage bzw. Anfragetransaktion anhand des im Smart- Con- tract hinterlegten Regelwerks (Berechtigungsüberprüfung) als valide verifiziert und nur in diesem Fall in die Blockchain geschrieben bzw. in einen Block aufgenommen. Mit dem Eintrag der Anfrage in die Blockchain bzw. in einen Block der Blockchain wird die Anfrage unwiderruflich persistiert. In dem Fall, dass die An frage nicht als valide verifiziert werden konnte, weil sie gegen das Regelwerk in dem Smart-Contract verstößt, wird die Anfrage verworfen. Dieser dem hier beschriebenen Verfahren vorgelagerte Verarbeitungsschritt wird bevorzugt komplett außerhalb des Datenverarbeitungsmoduls und unabhängig von dem Datenverar beitungsmodul ausgeführt. Wie schon weiter oben beschrieben verlässt sich die Prüfung in Schritt b) bevorzugt auf diese Vorprüfung.
Wenn die Prüfung in Schritt b) sich vollständig auf die Vorgänge in der Block chain (Vorprüfung bzw. erfolgreiche Eintragung der Anfrage in einen Block der Blockchain verlässt), kann erreicht werden, dass keinerlei Überprüfung der Berechtigung einer Anfrage in dem Datenbereitstellungsmodul mehr erforderlich ist. Nur wenn die Anfrage als valide geprüft wurde, wird sie als Anfragetransaktion in die Blockchain geschrieben.
Dies eröffnet die Möglichkeit weitreichender Vereinfachungen und, wenn dies gewünscht ist, auch gesteigerter Transparenz bei der Bereitstellung von Daten.
Besonders bevorzugt ist das Verfahren, wenn Schritt c) die folgenden Unterschrit te umfasst, wenn eine Bereitstellung von angefragten Teildaten erfolgt: cl) Einlesen der angefragten Teildaten aus dem vertraulichen Datenspeicher mit Hilfe des mindestens einen Datenidentifizierparameters; c2) Verschlüssen der eingelesenen Teildaten, so dass verschlüsselte Teilda ten entstehen und Bereitstellung der verschlüsselten Teildaten auf einer Datentransferplattform.
Mit Schritt cl) wird insbesondere eine automatisierte Sammlung der angefragten Teildaten im Unternehmen möglich. Aufgrund der vorgelagerten Prüfung in Schritt b) anhand der Blockchain kann sich das Datenbereitstellungsmodul auf die mit Schritt a) empfangene Anfrage zu 100 Prozent verlassen. Aus diesem Grund werden neue Möglichkeiten zur Automatisierung des Einlesens der gewünschten Teildaten ermöglicht. Das Einlesen von Teildaten kann insbesondere ohne manuelle und von einem (menschlichen) Operator kontrollierte Verarbeitungsschritte erfolgen. Darin liegt ein großes ökonomisches Einsparpotential.
Der Schritt c2) beinhaltet zwei Unterschritte, nämlich das Verschlüsseln und die Bereitstellung der verschlüsselten (Teil)-Daten. Das Verschlüsseln stellt sicher, dass keine dritte Partei die bereitgestellten Daten lesen kann. Der zweite Schritt führt im Sinne eines Daten „PUSH“ Verfahrens aus dem gesicherten Firmenbe reich hinaus an die Datentransferplattform, die bevorzugt einen öffentlichen Spei cher für die Daten bereitstellt. Dadurch, dass die Daten auf der Datentransferplattform bereit gestellt werden, muss niemals externen Partnern (Datenanfragem) Zugang zu den internen Daten im vertraulichen Datenspeicher oder einem anderen, ggf. temporären, nicht vertraulichen internen Datenspeicher gewährt werden. Hierdurch kann eine beachtliche Erhöhung der Datensicherheit der Daten im ver traulichen Speicher erreicht werden.
Besonders bevorzugt, ist, wenn in Schritt c2) zunächst ein symmetrischer Schlüssel generiert wird, und die angefragten Teildaten mit dem symmetrischen Schlüs sel vor der Bereitstellung auf der Datentransferplattform verschlüsselt werden und der symmetrische Schlüssel dem Datenanfrager über einen sicheren Kanal bereit gestellt wird.
Mit diesem Verfahren werden dem Datenanfrager nicht die Daten direkt zur Verfügung gestellt, sondern hier wird der (geheime) Ort übermittelt, an dem die Daten auf der öffentlichen Datentransferplattform abgelegt wurden. Durch die Verwendung eines symmetrischen Schlüssels zur Verschlüsselung der eigentlichen Daten (Teildaten) kann die (gegebenenfalls umfangreiche) Menge an Daten effizient verschlüsselt werden. Symmetrische Verschlüsselungsverfahren sind häufig effizienter als asymmetrische Verschlüsselungsverfahren.
Weiterhin vorteilhaft ist, wenn der symmetrische Schlüssel mit einem öffentlichen Schlüssel eines Schlüsselpaars des Datenanfragers verschlüsselt und in der Block- chain bereitgestellt wird. Der öffentliche Schlüssel des Schlüsselpaars des Datenanfragers kann von dem Datenanfrager für den Datenbereitsteller abrufbar bereit gestellt werden. Durch eine elektronische Signatur oder ähnliche Maßnahmen kann auch sichergestellt werden, dass der öffentliche Schlüssel des Datenanfragers eindeutig dem Datenanfrager zuordenbar ist und hier keine Identitätsfälschung (bzw. kein man-in-the-middle- Angriff) erfolgen kann.
Bevorzugt wird der symmetrische Schlüssel als Paket bestehend aus dem symmetrischen Schlüssel und einer Prüfsumme mit dem öffentlichen Schlüssel des Da- tenanfragers verschlüsselt und über die Blockchain bereitgestellt. Gegebenenfalls ist Bestandteil dieses Pakets auch eine Information über den Speicherort der verschlüsselten Teildaten. Der Datenanfrager erhält den verschlüsselten symmetri schen Schlüssel bzw. dieses Paket über die Blockchain, in dem der Datenanfrager an der Blockchain horcht bzw. die Blockchain überwacht und reagiert, wenn der Schlüssel bzw. das Paket hier mit Referenz zu dessen zuvor platzierter Anfrage auftaucht. Mit dem Inhalt dieses Pakets kann nun der Datenanfrager die angefrag ten Teildaten finden, entschlüsseln und gegebenenfalls anhand der Prüfsumme auch die Echtheit dieser Daten überprüfen.
Weiterhin vorteilhaft ist das Verfahren, wenn das Regelwerk mindestens eine ers te Berechtigungsdefinition enthält, die Teildaten definiert, für deren Zugriff der Datenanfrager berechtigt ist und wobei die Einstufung einer Anfrage als berechtigt nur dann erfolgt, wenn die mindestens eine erste Berechtigungsdefinition er- füllt ist.
Als Teil des Regelwerks liegen solche Berechtigungsdefinitionen auch in der Blockchain. Eine solche Berechtigungsdefmition, die Teildaten definiert, kann beispielsweise anhand des Datenidentifizierparameters erkennen, ob eine Anfrage berechtigt ist. Beispielsweise kann der Datenidentifizierparameter bestimmte
Nummemkreise ansprechen, wobei einzelne Teildatenpakete Datenidentifizierpa- rametem innerhalb dieser Nummemkreises zugeordnet sind. Die Nummemkreise können beispielsweise jeweils einzelnen Kunden des Datenbereitstellers zugeord net sein. Beispielsweise können Zulieferteile mit einer Teilenummer beginnend mit 1 einem ersten Kunden zugeordnet sein, Zulieferteile für einen zweiten Kunden mit einer Nummer mit 2 und so weiter. Die Teilenummer kann als Datenidentifizierparameter für die Kunden dienen.
Wenn der erste Kunde als Datenanfrager auftritt, kann die erste Berechtigungsde- finition vorgeben, dass dieser Kunde nur Teildaten zu Zulieferteilen mit Kunden- nummem beginnend mit 1 erhält. Für den zweiten Kunden als Datenanfrager kann es sich um Kundennummem beginnend mit 2 handeln und so weiter.
Die Überprüfung mit der ersten Berechtigungsdefinition stellt also in diesem Fall sicher, dass der Datenanfrager nur Teildaten von Produkten anfragen kann, die auch an ihn geliefert wurden. Der Datenanfrager kann keine Teildaten von Produkten erfragen die z.B. an Mittbewerber geliefert wurden (und welche gegebe nenfalls eine andere Qualität oder sonstige unterschiedliche Eigenschaften) haben. Außerdem vorteilhaft ist das Verfahren, wenn das Regelwerk mindestens eine zweite Berechtigungsdefinition enthält, die eine maximale Anzahl von Anfragen und/oder eine maximale Datenmenge enthält, die ein Datenanfrager in einem vorgegebenen Zeitintervall anfragen darf und wobei eine Einstufung einer Anfrage als berechtigt nur dann erfolgt, wenn die mindestens eine zweite Berechtigungsde- finition erfüllt ist.
Mit dieser Definition kann beispielsweise eine maximale Anzahl von Datenanfragen oder eine maximale Datenmenge pro Tag, Woche oder Monat festgelegt sein. Es können auch mehrere derartige Limits existieren, die gestuft zueinander abge- fragt werden, wobei weder das eine oder das andere Limit für das jeweilige Zeitintervall überschritten werden darf. Durch eine solche zweite Berechtigungsdefinition kann insbesondere der systematische Zugriff auf große Datenmengen verhindert werden. Durch eine solche zweite Berechtigungsdefinition wird manueller Aufwand stark reduziert, aber auch eine manuelle Kontrolle umgangen. Da der Datenbereitsteller aber Interesse daran hat, dem Datenanfrager Teildaten seiner Produkte automati siert zu übermitteln, kann der Datenbereitsteller die Anzahl der automatisierten Übermittlungen begrenzen. Die Begrenzung kann z.B. auf einen Prozentsatz der gelieferten Produkte beschränkt sein oder auf eine Anzahl, die im üblichen statis- tischen Maß eine Anfrage von Daten rechtfertigt. In der zweiten Berechtigungsdefinition hinterlegte Begrenzungen können gegebenenfalls auf explizite Anfrage hin auch angehoben oder sogar aufgehoben werden, wenn der Datenbereitsteller hiermit einverstanden ist. Die Anfrage zur Anhebung sowie eine mögliche Einverständniserklärung oder Ablehnung dieser Anfrage durch den Datenanfrager kann ggf. auch über die Blockchain erfolgen.
Außerdem besonders voreilhaft ist das Verfahren, wenn das Regelwerk mindestens eine dritte Berechtigungsdefmition enthält, die eine Detailtiefe der Teildaten definiert, die ein Datenanfrager abrufen darf und wobei eine Einstufung einer Anfrage als berechtigt nur dann erfolgt, wenn die mindestens eine dritte Berechti gungsdefmition erfüllt ist.
Solche dritte Berechtigungsdefinitionen ermöglichen eine erweiterte Berechtigungsfunktion für bestimmte Teildaten. Es könnte z.B. sein, dass für eine weitere Detailstufe von Daten mit einem höheren Datenvolumen, höherer Auflösung, tieferer Datenhierarchie ggf. eine andere maximale Datenmenge definiert ist, die ein Datenanfrager abrufen darf als für die Standard-Detailstufe. So kann zum Beispiel definiert sein, dass ein Datenanfrager bspw. 1.000 Datenanfragen geringer Detailstufe in der Woche stellen darf aber nur 10 Datenanfragen hoher Detailstufe. Da die Berechtigungsdefinitionen auf der Blockchain liegen, kann der Datenanfrager alleine (ohne Einverständnis des Datenbereitstellers) die Berechtigungsdefmi- tionen nicht beeinflussen.
Die Tatsache, dass die verschiedenen Berechtigungsdefinitionen für einen automatisierten Datenaustausch auf einer ggf. öffentlichen Blockchain abgelegt werden, führt nicht zu einer Veröffentlichung von Informationen, die der Datenbereit steller geheim halten möchte. Der Datenbereitsteller möchte i.A. Informationen als vertraulich behandeln, die z.B. betreffen:
- die Qualität seiner Produkte;
- Effizienz der Produktion (Produktivität, Qualitätsrate, Verfügbarkeit); - Anzahl produzierter Einheiten;
- Anzahl gelieferter Produkte für bestimmte Kunden;
- Marktanteile;
- oder andere.
Die Berechtigungsdefinitionen liegen ggf. auf einer öffentlichen Blockchain, das bedeutet aber nicht, dass sie interpretierbar sind. Wird z.B. die Berechtigungsfunktion so implementiert, dass sie bestimmte Seriennummem überprüft, für die ein Datenanfrager berechtigt ist Daten anzufragen (erste Berechtigungsdefinitionen), dann ist eine mögliche Implementierung, die berechtigten Seriennummem in einer Liste auf der Blockchain abzulegen. Dies bedeutet implizit, wenn der Empfänger bekannt ist, wäre öffentlich bekannt, welche Produkte mit welchen Seriennummem an diesen Empfänger geliefert wurden. Auf einer Blockchain kann aber auch ein anderes Verfahren als eine (offene) Liste verwendet werden: Die Serien nummem können auch in einem sog. kryptographischen Akkumulator abgelegt werden, der die Antwort einer „Mitgliedschaft“ für eine bestimmte Nummer / ID in einer Gruppe liefert, ohne die Liste der Mitglieder der Gruppe offenzulegen.
In besonders bevorzugten Ausführungsvarianten des Verfahrens erfolgt eine Prü fung der Berechtigung in Schritt b) anhand der Blockchain dadurch, dass geprüft wird, ob die Anfrage von der Blockchain validiert und in die Blockchain aufgenommen wurde.
Dieses Verfahren hat einen enormen wirtschaftlichen Nutzen: Einerseits kann die Übertragung von geschützt liegenden Daten aus einer Umgebung des Datenbereitstellers völlig automatisiert werden, wodurch ein hohes Kosteneinsparpotential realisiert werden kann. Andererseits hat der Datenbereitsteller durch dieses Ver fahren die volle Kontrolle über die Regeln der automatisierten Datenübermittlung. Obwohl Daten ohne manuelle Prüfung automatisiert übertragen werden, kann kein Datenanfrager unkontrolliert Daten beziehen. Die Prüfung der Datenanfragen des Datenanfragers erfolgt in der Blockchain tatsächlich durch sogenannte Block-Ersteller (häufig auch Block Producer), die jede Datenanfrage (als Transaktion) oder auch jede andere Information (als Transakti on), die in die Blockchain geschrieben werden soll, überprüfen. Nur wenn die Datenanfrage sämtliche Anforderungen erfüllt und insbesondere auch die für die jeweilige Anfrage vorgesehenen Regelwerke, wird diese Anfrage in die Blockchain geschrieben.
Besonders vorteilhaft ist das Verfahren, wenn außer der Prüfung der Berechtigung in Schritt b) anhand der Blockchain keine weitere Prüfung der Berechtigung erfolgt.
Durch die Verwendung der Blockchain kann auf jede weitere Prüfung der Berechtigung verzichtet werden. Dies macht das beschriebene Verfahren besonders effizient. Es ist allerdings nicht ausgeschlossen, das zusätzliche Überprüfungen mög lich sind.
Besonders bevorzugt ist das Verfahren, wenn Anfragen in der Blockchain in verschlüsselter Form und/oder mit einem Hash-Wert hinterlegt werden.
Auf diese Art- und Weise kann insbesondere verhindert werden, dass Informationen, die über die Blockchain zwischen einem bestimmten Datenanfrager und einem bestimmten Datenbereitsteller oder umgekehrt, übertragen werden, an Dritte abfließen.
Hier auch beschrieben werden soll ein Datenbereitstellungsmodul eingerichtet zum Austausch von Daten mit einer öffentlichen Blockchain und eingerichtet zur Durchführung des beschriebenen Verfahrens. Die weiter oben beschriebenen besonderen Vorteile und Ausgestaltungsmerkmale des Verfahrens sind auf das beschriebene Datenbereitstellungsmodul anwendbar und übertragbar. Details zum Aufbau des Datenbereitstellungsmoduls sind im Fol genden im Zusammenhang mit den Figuren offenbart.
Hier auch beschrieben werden soll ein Computerprogrammprodukt umfassend ein derartiges Datenbereitstellungsmodul oder ein Datenbereitstellungsmodul einge richtet zur Durchführung des beschriebenen Verfahrens.
Außerdem beschrieben wird ein Speichermedium, auf dem ein derartiges Computerprogrammprodukt gespeichert ist.
Ziel des hier beschriebenen Verfahrens ist insbesondere nicht die fraglichen breitgestellten Daten (bspw. Dokumente betreffend Bauteile) in Blöcken der Block- chain abzulegen. Vielmehr dient die Blockchain hier tatsächlich nur zur Regelung der Zugänge. Auch eine kombinierte Ablage von Zugriffsattributen und Daten in der Blockchain ist mit dem hier beschriebenen Verfahren explizit nicht erfasst. Die Blockchain selbst ist frei von den fraglichen Daten, auf die der Zugriff bereitgestellt werden soll. Sie enthält nur Berechtigungsdefinitionen für den Zugriff auf Daten und gegebenenfalls Daten bezüglich Anfragen von Datenanfrager an den Datenbereitsteller und deren Zulässigkeit oder auch Schlüssel und/oder Adressen für den Zugriff auf Daten. Aus diesem Grund kann mit einer sehr kompakten Blockchain gearbeitet werden, deren Gesamtdatenmenge auch mit einem zeitlich fortgesetzten Betrieb des beschriebenen Verfahrens nicht sehr stark wächst. Dies ist insbesondere wichtig, weil in der hier beschriebenen Anwendung (dem hier beschriebenen Datenbereitstellungsmodul) regelmäßig sehr große Mengen von Daten bereitgestellt werden. Wenn es sich beispielsweise um Dokumentationen von Zuliefererteilen im Automobilbereich handelt, können schnell viele Gigabytes an Daten Zusammenkommen, wenn bspw. sämtliche während der Herstellung angefallenen Messdaten/Prüfprotokolle jedes einzelnen Zuliefererteils aus einer umfangreichen Serie von einzelnen Zuliefererteilen angefragt wird.
Dies ist abzugrenzen von Verfahren und Technologien, in denen es beispielsweise darum geht, Ausweisdokumente, Tokens zu real existieren Gegenständen oder ähnliche Parameter in einer Blockchain zu hinterlegen. Bei solchen Verfahren und Technologien stellen die Ausweisdokumente oder Tokens selbst die zu verwalten den Daten dar, weil sie letztlich eine Repräsentation der Daten sind. In dem hier beschriebenen Verfahren erfolgt in der Blockchain keine Ablage von Datenrepräsentationen.
Sie werden in der Blockchain abgelegt, um einfach eine Identitätsprüfung anhand von Ausweisdokumenten oder eine Eigentumsprüfung anhand von Tokens vornehmen zu können. Bei der Anwendung des hier beschriebenen Verfahrens bzw. für das hier beschriebene Verfahren werden Berechtigungsdefinitionen in der Blockchain hinterlegt, die bevorzugt aus sich selbst heraus keinen Sinn ergeben, sondern in Zusammenhang mit den der Bereitstellung von Daten durch den Datenbereitsteller eine Bedeutung entwickeln bzw. einen Sinn haben. Diese in der Blockchain hinterlegten Berechtigungsdefinitionen können eine erhebliche Kom plexität aufweisen. Bevorzugt werden solche Berechtigungsdefinitionen mit Hilfe von speziellen Verfahren automatisiert nach den Vorgaben generiert, wobei diese Vorgaben insbesondere Rahmenbedingungen umfassen:
- Aufbau des Datenbereitstellungsmoduls,
- Struktur der Daten im vertraulichen Datenspeicher, und
- Gewünschte Zugriffsmöglichkeiten auf die Daten durch die Datenant- frager.
Der vertrauliche Datenspeicher, der hier verwendet wird, ist bevorzugt klassisch aufgebaut wie eine übliche Datenbank. Insbesondere hat der vertrauliche Daten- Speicher keine Blockchain-spezifischen Besonderheiten. Daten sind beispielsweise in Form von Teildaten/Datensätzen strukturiert abgelegt und können über IDs oder Datenidentifizierparameter aufgerufen werden. In dem Datenspeicher können Daten auch in Form von einer Baum- oder Ordnerstruktur abgelegt sein. Zur Anwendung des beschriebenen Verfahrens ist es insbesondere nicht erforderlich, dass ein Konzept der Datenablage besonders gestaltet ist. Vielmehr ist es mit dem beschriebenen Verfahren möglich, die Sicherheit der öffentlich verfügbaren Blockchain auf die der Datenanfrager zugreifen kann, zu nutzen, ohne dass eine spezielle Struktur der Ablage der Daten in dem vertraulichen Datenspeicher erfolgen muss. Das beschriebene Verfahren (bzw. das für die Durchführung des beschriebenen Verfahrens, wie hier vorgeschlagen, eingerichtete Datenbereitstel lungsmodul) übernimmt die Vermittlung zwischen der Blockchain und dem vertraulichen Datenspeicher. In diesem Zusammenhang ist insbesondere die Vermittlung zwischen der Art- und Struktur der in der Blockchain hinterlegten Berechti- gungsdefmitionen und der Struktur der Datenablage in dem vertraulichen Daten speicher gemeint. Dies ermöglicht es das beschriebene Verfahren insbesondere auch auf bestehende Infrastruktur (einen bestehenden vertraulichen Datenspeicher) aufzusetzen. Es ist insbesondere keine komplette Umstrukturierung/ Adaptierung von Daten erforderlich, die in einem vertraulichen Datenspeicher hinterlegt sind, um das beschriebene Verfahren anzuwenden. Dafür ist vielmehr nur die entsprechende Einrichtung des Datenbereitstellungsmoduls erforderlich. Die Daten in dem vertraulichen Datenspeicher sind (obwohl vertraulich) üblicherweise auch nicht verschlüsselt. Es ist ein Vorteil des Verfahrens, dass durch die Datenbereit stellung mit dem beschriebenen Datenbereitstellungsmodul auf eine verschlüsselte Ablage der Daten verzichtet werden kann.
Mit dem hier beschriebene Verfahren wird bevorzugt eine Blockchain verwendet, die nicht durch eine öffentliche Zertifikatsstruktur validiert bzw. zertifiziert ist, sondern es handelt sich bevorzugt um eine Blockchain, die von einer privaten Instanz (ggf. auch dem Datenbereitsteller selbst oder einem Konsortium mehrerer Datenbereitsteller) gestartet wurde und auf öffentlichen Knoten betrieben wird. Die Blockchain kann von jedem Datenanfrager geprüft werden und die Block- chain dient in dem beschriebenen Verfahren als Technologie um Daten aus dem vertraulichen Datenspeicher gemäß definierten Regeln zur Verfügung zu stellen. Eine Zertifizierungs Struktur steht bevorzugt nicht hinter der Blockchain.
Die Erstellung und Bereitstellung von Berechtigungsdefinitionen in der Blockhain erfolgt bevorzugt ausschließlich gemäß den Vorgaben des Datenbereitstellers. Der Datenbereitsteller schreibt die Berechtigungsdefinitionen in die Blockchain. Das hier beschriebene Verfahren funktioniert bevorzugt unabhängig von einem Konsensmechanismus der Blockchain. Der Zweck der Blockchain in dem hier be schriebenen Verfahren ist die Gewährung der Öffentlichkeit bei gleichzeitiger Manipulationssicherheit, nicht jedoch die Erzielung von Konsens bezüglich der Berechtigungsdefinitionen.
Die Erfindung und das technische Umfeld wird im Folgenden anhand der Figuren näher erläutert. Es ist darauf hinzuweisen, dass die Figuren nur schematisch sind und die Prinzipien der hier behandelten Erfindung erläutern sollen. Einzelne beschriebene Merkmale oder Funktionen des Ausführungsbeispiels können auch in anderer als der dargestellten Weise sinnvoll im Rahmen der Erfindung miteinander kombiniert werden. Es zeigen
Fig. 1: ein erstes schematisches Ablaufdiagramm eines beschriebenen Verfah rens mit den beteiligten Verfahrensakteuren; und
Fig. 2: ein zweites schematisches Ablaufdiagramm eines beschriebenen Verfahrens mit den beteiligten Verfahrensakteuren. Im dem Ablaufdiagramm des Verfahrens gemäß Fig. 1 ist oben zunächst der Datenbereitsteller 1 dargestellt, der hier neben dem vertraulichen Datenspeicher 2 angeordnet ist. Der vertrauliche Datenspeicher 2 ist beispielsweise auf einem Server oder in einer Fabrik angeordnet. In dem vertraulichen Datenspeicher 2 befinden sich Daten 4, die beispielsweise eine Vielzahl von Teildaten 9 umfassen können, wobei Teildaten 9 der Daten 4 jeweils mit einem Datenidentifizierparameter 12 identifizierbar sind. Der Datenbereitsteller ist der Inhaber der Daten 4 und damit auch der Teildaten 9, aus denen die Daten 4 bestehen. Der Datenbereitsteller 1 schreibt eine Berechtigungsdefmition 6 in eine Blockchain 5. Die Blockchain 5 besteht aus einer Vielzahl von aufeinanderfolgenden Blöcken 10 in welchen eine Vielzahl von Daten in Form von Transaktionen hinterlegt sein kann. Transaktio nen in den Blöcken 10 können insbesondere die beschriebenen Regelwerke 13, validierte Anfragen 14 oder auch weitere Daten wie öffentliche Schlüssel 15 und symmetrische Schlüssel 17 zur Verschlüsselung von Daten sein. Die Berechtigungsdefmition 6 kann Teil eines Regelwerks 13 sein, gemäß welchem Daten aus dem vertraulichen Datenspeicher 2 zur Verfügung gestellt werden können und welches beispielsweise erste Berechtigungsdefinitionen 18, zweite Berechtigungs- defmitionen 19 oder dritte Berechtigungsdefinitionen 20 umfassen kann.
Ein Datenanfrager 7 ist unterhalb der Blockchain dargestellt. Der Datenanfrager 7 kann eine Anfrage 8 zur Bereitstellung bestimmter Teildaten 9 an die Blockchain 5 übermitteln, wobei eine solche Anfrage auch einen Datenidentifizierparameter 12 beinhaltet, mit welchem die jeweiligen Teildaten identifizierbar sind.
Diese Anfrage 8 wird als validierte Anfrage 14 in die Blockchain 5 geschrieben, sofern die Anfrage mit dem Regelwerk 13 übereinstimmt. Die Anfrage 8 mit dem Datenidentifizierparameter 12 gelangt über die Blockchain 5 an ein Datenbereit stellungsmodul, welches an dem vertraulichen Datenspeicher 2 angeordnet ist. Es erfolgt eine Berechtigungsprüfung 21, die auch implizit dadurch erfolgen kann, dass die Anfrage 8 nur dann über die Blockchain 5 zu dem Datenbereitstellungs- modul 3 gelangt, wenn diese als validierte Anfrage in die Blockchain 5 geschrieben wurde. Der Empfang der Anfrage durch das Datenbereitstellungsmodul 3 entspricht Schritt a) des beschriebenen Verfahrens. Die Prüfung, ob die Anfrage dem Regelwerk entspricht (ob explizit oder implizit), entspricht im wesentlichen Schritt b) des beschriebenen Verfahrens.
Verschlüsselte Teildaten 22 werden an eine Datentransferplattform 11 geschickt, wo sie zum Abruf durch den Datenanfrager 7 zur Verfügung stehen. Ein symmetrischer Schlüssel 17, mit welchem die Teildaten 9 verschlüsselt worden sind, kann über die Blockchain 5 ebenfalls an den Datenanfrager 7 übermittelt werden, damit dieser die verschlüsselten Teildaten 22 entschlüsseln kann. Der symmetri sche Schlüssel 17 kann dazu mit einem ebenfalls über die Blockchain bereitgestellten öffentlichen Schlüssel 15 des Datenanfragers 7 verschlüsselt werden. Für Verschlüsselungsaufgaben hat das Datenbereitstellungsmodul 3 bevorzugt ein Verschlüsselungsmodul 23. Mit dem privaten (geheimen) Schlüssel 16 des Daten anfragers kann dieser dann zunächst den symmetrischen Schlüssel 17 und den geheimen Ablageort (Datentransferplattform) 11 entschlüsseln, um anschließend die verschlüsselten Teildaten 22 zu entschlüsseln. Die hier beschriebene Bereitstellung von Daten entspricht Schritt c) des beschriebenen Verfahrens mit den einzelnen Unterschritten cl) und c2).
In der Fig. 2 ist das beschriebene Verfahren noch in einer etwas anderen Darstellung aufgeführt, nämlich in Form eines Flussdiagramms. Der Datenanfrager 7 stellt zunächst die Anfrage 8, die dann an die Blockchain 5 übergeben wird in welcher eine Anfrageprüfung 24 erfolgt. Die Anfrageprüfung 24 kann entweder in einen akzeptierten Pfad 26 oder in einen abgelehnten Pfad 27 münden, wobei der abgelehnte Pfad mit der Beendigung 28 des Verfahrens endet. Wenn die Anfra ge 8 akzeptiert wird, wird der akzeptierte Pfad 26 beschritten und es erfolgte eine Anfragespeicherung 25 der Anfrage. Anschließend wird die Anfrage durch den Datenbereitsteller 1 bzw. dessen Datenbereitstellungsmodul 3 empfangen. Dies erfolgt mit dem Block „Anfrage lesen 29“. Eine zusätzliche explizite Validierung der Anfrage wird nicht durchgeführt. Aufgrund der Tatsache, dass die Anfrage aus der Blockhain 5 stammt, wird der Anfrage vertraut. Dann erfolgt das Teildaten zu sammenstellen 30 mit einer Verschlüsselung der Teildaten. Die Schlüsselpaket- Speicherung 32 erfolgt in der Blockchain 5. Das sichere Ablegen der Teildaten 31 wird von dem Datenbereitstellungsmodul 3 auf einer hier nicht dargestellten Datentransferplattform (geheimer Ablageort) 11 durchgeführt. Die abgelegten Teil daten 31 und das gespeicherte Schlüsselpaket 32 können nun von dem Datenan- frager 7 verarbeitet werden. Es erfolgt ein Schlüsselpaketeinlesen 33 und ein La- den und Entschlüsseln der Daten 34.
Bezugszeichenliste
I . Datenbereitsteller 2. vertraulicher Datenspeicher
3. Datenbereitstellungsmodul
4. Daten
5. Blockchain
6. Berechtigungsdefinition 7. Datenanfrager
8. Anfrage
9. Teildaten
10. Block
I I . Datentransferplattform 12. Datenidentifizierparameter
13. Regelwerk
14. validierte Anfrage
15. öffentlicher Schlüssel
16. privater Schlüssel 17. symmetrischer Schlüssel
18. erste Berechtigungsdefinition
19. zweite Berechtigungsdefinition
20. dritte Berechtigungsdefinition
21. Berechtigungsprüfung 22. verschlüsselte Teildaten
23. Verschlüsselungsmodul
24. Anfrageprüfung
25. Anfragespeicherung
26. akzeptierter Pfad 27. abgelehnter Pfad 28. Beendigung
29. Anfrage lesen
30. Teildaten zusammenstellen
31. Teildaten sicher ablegen 32. Schlüsselpaket speichern
33. Schlüsselpaket lesen
34. Daten laden und entschlüsseln

Claims

Ansprüche
1. Verfahren zur selektiven Bereitstellung von Daten (4) aus einem vertrauli chen Datenspeicher (2) eines Datenbereitstellers (1) mit einem Datenbereitstellungsmodul (3) aufweisend die folgenden Schritte: a) Empfangen einer Anfrage (8) von einem Datenanfrager (7) bezüglich der Bereitstellung von Teildaten (9) aus dem vertraulichen Datenspeicher (2), wobei die Anfrage mindestens einen Datenidentifizierparameter (12) zur Identifizierung der Teildaten (9) beinhaltet; b) Prüfen anhand einer Blockchain (5), ob die Anfrage (8) mit einem von dem Datenbereitsteller (1) in der Blockchain (5) hinterlegten Regelwerks (13) geprüft und als berechtigt eingestuft wurde; c) Sofern die Anfrage (8) als berechtigt eingestufte wurde, Bereitstellung der zur Bereitstellung angefragten Teildaten (9) an den Datenanfrager (7).
2. Verfahren nach Anspruch 1, wobei Schritt c) die folgenden Unterschritte umfasst, wenn eine Bereitstellung von angefragten Teildaten (9) erfolgt: cl) Einlesen der angeffagten Teildaten (9) aus dem vertraulichen Datenspeicher mit Hilfe des mindestens einen Datenidentifizierparameters (12); c2) Verschlüssen der eingelesenen Teildaten (9), so dass verschlüsselte Teildaten (22) entstehen und Bereitstellung der verschlüsselten Teildaten (22) auf einer Datentransferplattform (11).
3. Verfahren nach Anspruch 2, wobei in Schritt c2) zunächst ein symmetrischer Schlüssel (17) generiert wird, und die angefragten Teildaten mit dem symmetrischen Schlüssel (17) vor der Bereitstellung auf der Datentransferplattform (11) verschlüsselt werden und der symmetrische Schlüssel (17) dem Datenan frager (7) über einen sicheren Kanal bereit gestellt wird.
4. Verfahren nach Anspruch 3, wobei der symmetrische Schlüssel (17) mit einem öffentlichen Schlüssel (15) eines Schlüsselpaars des Datenanfragers (7) verschlüsselt und in der Blockchain (5) bereitgestellt wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Regelwerk (13) mindestens eine erste Berechtigungsdefinition (18) enthält, die Teildaten (9) definiert für deren Zugriff der Datenanfrager (7) berechtigt ist und wobei die Einstufung einer Anfrage (8) als berechtigt nur dann erfolgt, wenn die mindestens eine erste Berechtigungsdefinition (18) erfüllt ist.
6. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Regelwerk (13) mindestens eine zweite Berechtigungsdefinition (19) enthält, die eine maximale Anzahl von Anfragen (8) und/oder eine maximale Datenmenge enthält, die ein Datenanfrager (7) in einem vorgegebenen Zeitintervall anfragen darf und wobei einer Einstufung einer Anfrage (8) als berechtigt nur dann er folgt, wenn die mindestens eine zweite Berechtigungsdefinition (19) erfüllt ist,
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Regelwerk (13) mindestens eine dritte Berechtigungsdefinition (20) enthält, die eine De tailtiefe der Teildaten (9) definiert, die ein Datenanfrager (7) abrufen darf und wobei eine Einstufung einer Anfrage (8) als berechtigt nur dann erfolgt, wenn die mindestens eine dritte Berechtigungsdefinition (20) erfüllt ist.
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei eine Prüfung der Berechtigung in Schritt b) anhand der Blockchain (5) dadurch erfolgt, dass geprüft wird, ob die Anfrage (8) von der Blockchain (5) validiert und in die Blockchain (5) aufgenommen wurde.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei außer der Prüfung der Berechtigung in Schritt b) anhand der Blockchain (5) keine weitere Prüfung der Berechtigung erfolgt.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei Anfragen (8) in der Blockchain (5) in verschlüsselter Form und/oder mit einem Hash-Wert hinterlegt werden.
11. Datenbereitstellungsmodul (3) eingerichtet zum Austausch von Daten mit einer öffentlichen Blockchain (5) und eingerichtet zur Durchführung eines
Verfahrens gemäß einem der Ansprüche 1 bis 10.
12. Computerprogrammprodukt umfassend ein Datenbereitstellungsmodul (3) nach Anspruch 11 oder eingerichtet zur Durchführung eines Verfahrens ge- mäß einem der Ansprüche 1 bis 10.
13. Speichermedium, auf dem ein Computerprogrammprodukt nach Anspruch 11 gespeichert ist.
PCT/EP2021/055097 2020-03-02 2021-03-02 Verfahren zur selektiven bereitstellung von daten WO2021175805A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020105529.3A DE102020105529A1 (de) 2020-03-02 2020-03-02 Verfahren zur selektiven Bereitstellung von Daten
DE102020105529.3 2020-03-02

Publications (1)

Publication Number Publication Date
WO2021175805A1 true WO2021175805A1 (de) 2021-09-10

Family

ID=75396683

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/055097 WO2021175805A1 (de) 2020-03-02 2021-03-02 Verfahren zur selektiven bereitstellung von daten

Country Status (2)

Country Link
DE (1) DE102020105529A1 (de)
WO (1) WO2021175805A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3511851A1 (de) * 2018-01-12 2019-07-17 Siemens Healthcare GmbH Speichern von und zugreifen auf medizinische datensätze auf der blockchain
WO2019234426A1 (en) * 2018-06-05 2019-12-12 Data Signals Limited Blockchain based access control using time-dependent obfuscation of access tokens

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016215917A1 (de) 2016-08-24 2018-03-01 Siemens Aktiengesellschaft Gesichertes Verarbeiten einer Berechtigungsnachweisanfrage
DE102018200100A1 (de) 2018-01-04 2019-07-04 Bundesdruckerei Gmbh Persönliche Dokumentenblockchain-Struktur
US10756883B2 (en) 2018-01-19 2020-08-25 Trist Technologies, Inc. Systems and methods for data collection with blockchain recording
US10742397B2 (en) 2018-04-26 2020-08-11 Jonathan Sean Callan Method and system for managing decentralized data access permissions through a blockchain
US10929352B2 (en) 2018-05-29 2021-02-23 Oracle International Corporation Securing access to confidential data using a blockchain ledger

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3511851A1 (de) * 2018-01-12 2019-07-17 Siemens Healthcare GmbH Speichern von und zugreifen auf medizinische datensätze auf der blockchain
WO2019234426A1 (en) * 2018-06-05 2019-12-12 Data Signals Limited Blockchain based access control using time-dependent obfuscation of access tokens

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ALEVTINA DUBOVITSKAYA ET AL: "Secure and Trustable Electronic Medical Records Sharing using Blockchain", AMIA ... ANNUAL SYMPOSIUM PROCEEDINGS. AMIA SYMPOSIUM, 1 January 2017 (2017-01-01), United States, pages 650, XP055572864, Retrieved from the Internet <URL:https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5977675/pdf/2730257.pdf> *
KIRAN ADYA ET AL: "Blockchain based Data Access Control using Smart Contracts", TENCON 2019 - 2019 IEEE REGION 10 CONFERENCE (TENCON), IEEE, 17 October 2019 (2019-10-17), pages 2335 - 2339, XP033672609, DOI: 10.1109/TENCON.2019.8929451 *
MEHDI SOOKHAK ET AL: "Blockchain and smart contract for access control in healthcare: A survey, issues and challenges, and open issues", JOURNAL OF NETWORK AND COMPUTER APPLICATIONS, 1 March 2020 (2020-03-01), pages 1 - 22, XP055765559, Retrieved from the Internet <URL:https://www.sciencedirect.com/science/article/pii/S1084804520304045> [retrieved on 20210115] *

Also Published As

Publication number Publication date
DE102020105529A1 (de) 2021-09-02

Similar Documents

Publication Publication Date Title
EP2304642B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3452941B1 (de) Verfahren zur elektronischen dokumentation von lizenzinformationen
EP1209579A1 (de) System zur automatisierten Abwicklung von Transaktionen durch aktives Identitätsmanagement
EP2332313A2 (de) Verfahren zur speicherung von daten, computerprogrammprodukt, id-token und computersystem
EP3637345A1 (de) Verknüpfung von identitäten in einer verteilten datenbank
EP3688928A1 (de) Dataculestruktur und verfahren zum manipulationssicheren speichern von daten
EP1967976A2 (de) Verfahren zur authentisierten Übermittlung eines personalisierten Datensatzes oder programms an ein Hardware-Sicherheitsmodul, insbesondere einer Frankiermaschine
WO2019229031A1 (de) Verfahren und system zum steuern einer freigabe einer ressource
EP1287655B1 (de) Verfahren zur authentizitätssicherung von hard- und software in einem vernetzten system
WO2021175805A1 (de) Verfahren zur selektiven bereitstellung von daten
EP1652337B1 (de) Verfahren zum signieren einer datenmenge in einem public-key-system sowie ein datenverarbeitungssystem zur durchführung des verfahrens
EP3966723B1 (de) Verfahren und anordnung zur bereitstellung von daten einer industriellen automatisierungsanordnung zu einer externen anordnung
WO2020064132A1 (de) Datenbanksystem für ein soziales netzwerk mit verwendung von blockchain-technologie
WO2018130426A1 (de) Anonymisierung einer blockkette
EP3232640B1 (de) Gültigkeitsprüfung und sperrung von zertifikaten
DE102014204812A1 (de) Attributwertspezifische Vertrauensniveaus
DE102021129047B4 (de) Selektiv anonymisierende Überweisung einer Kryptowährung
WO2023046317A1 (de) Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit
DE102021005040A1 (de) Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit
DE10061102B4 (de) System zur Statusabfrage von digitalen Zertifikaten
WO2022063851A1 (de) Server zur abwicklung von transaktionen
DE102021106261A1 (de) Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikationsnetz, Verarbeitungseinrichtung, Kraftfahrzeug und Infrastruktureinrichtung
DE102019202381A1 (de) Verfahren zum Transfer von Daten
EP4250146A1 (de) Interaktion physischer entitäten
WO2023011756A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

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: 21716599

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 21716599

Country of ref document: EP

Kind code of ref document: A1