EP3830781A1 - Verknüpfung von identitäten in einer verteilten datenbank - Google Patents
Verknüpfung von identitäten in einer verteilten datenbankInfo
- Publication number
- EP3830781A1 EP3830781A1 EP19786503.3A EP19786503A EP3830781A1 EP 3830781 A1 EP3830781 A1 EP 3830781A1 EP 19786503 A EP19786503 A EP 19786503A EP 3830781 A1 EP3830781 A1 EP 3830781A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- identity
- distributed database
- transaction
- data
- user
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Classifications
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital 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 present disclosure relates to methods, devices and computer programs for providing or operating a distributed database.
- EP18156308 document EP17201758, document EP18156511, document EP18159485, document EP17203573, document EP 17175275, document EP17186826, document WO 2018069271 A1, document PCT / EP2017 / 082508, document EP17179823, document WO 2017050348 Al, document WO
- a distributed database typically uses cryptographic methods and consensus methods in order to protect information stored in the distributed database against manipulation.
- a distributed database can be implemented, for example, as a blockchain (or blockchain)
- the technology of blockchains and distributed ledgers is currently used in a growing variety of application areas.
- applications for decentralized payment systems e.g. Bitcoin
- new application options are being developed in the financial industry, for example.
- transactions between companies can be done without intermediaries This enables new business models without a trustworthy intermediary, reduces transaction costs, and new digital services can be offered flexibly without the need for a specially set up infrastructure and the like nd having to establish trust relationships.
- a transaction data record (or transaction for short) protected by a blockchain includes e.g. B.
- Program code which can also be referred to as a so-called "smart contract”.
- the public keys of the users are generated in a distributed database without further metadata by the users themselves and are therefore anonymous or pseudonymous.
- One example that is relevant to industry is that not all goods are exported to all countries be allowed, so that the identity of the contractual partner must be checked before concluding a contract.
- PKI public key infrastructure
- the identity linked to the cryptographic public key e.g. a natural or legal person
- This confirmation of an identity can, for. B. gene by a certificate that is digitally signed by the trustworthy entity.
- this task can also be delegated by the trustworthy entity to another entity, which is typically referred to as the Registration Authority (RA).
- the RA only verifies the alleged authenticity of the identity and transfers the result of its verification to an entity called the Certification Authority (CA), which, if the authenticity has been confirmed, confirms the authenticity of the identity by signing the certificate.
- CA Certification Authority
- the use of a PKI shown leads to a comparatively high level of complexity, since e.g. In addition to the distributed database, functions for managing certificates must also be provided.
- this object is achieved by a device according to claim 1, by a device according to claim 4, by a method according to claim 10, by a method according to claim 12 and by a computer program according to claim 14.
- the dependent claims define further embodiments.
- a first device for providing a distributed database can, for example, implement a node of a distributed database system.
- the first device is designed for:
- the first identity can be linked to the second identity in an efficient and tamper-proof manner.
- the first identity comprises a public cryptographic key, which can be used to sign a transaction in the distributed database.
- the transaction data of this transaction can include the public cryptographic key, a hash value of the public cryptographic key and / or an identifier of the public cryptographic key.
- the transaction for linking the identities can be initiated exclusively by one or more users of the distributed database classified as trustworthy. That way for example, the authenticity of the second identity is ensured.
- the first device is further configured to:
- the further transaction Storing transaction data of at least one further transaction in the distributed database, the further transaction breaking the link between the first identity of the user and the second identity of the user.
- the further transaction can also be initiated exclusively by one or more users of the distributed database classified as trustworthy, e.g. by the same user who initiated the transaction to link the identities. In this way, the previously created linking of the first and second identities can be broken again in an efficient and tamper-proof manner.
- Unlinking the two identities can be necessary or useful for various reasons. This can partly be due to the fact that a legal relationship has ended. This can be the case, for example, when an employee leaves a company or when a motor vehicle is sold. In the latter case, for example, it should not be possible for the
- the user can be identified via the second identity outside of the distributed database. Anonymous or pseudonymous use of the first identity can thus be avoided.
- the second identity comprises one or more pieces of information which identify the user as a natural person, legal person, organizational identification, machine or physical object.
- the information can contain, for example, a name, for example personal name, organization name, device name, product name or manufacturer name. Furthermore, such information can also include other labeling information, for example a product number, or address data.
- Identification as a natural person or a legal person can, for example, also enable the enforcement of legal claims. This can be advantageous, for example, if the first identity is used in a business transaction between the user and another user, for example to sign a corresponding transaction in the distributed database.
- a second device for providing a distributed database can, for example, implement a node of a distributed database system or provide access to one or more nodes of a distributed database system.
- the second device is designed for:
- the first identity comprises a public cryptographic key which can be used by the user to sign a transaction in the distributed database.
- the checking of the second identity can include a confirmation of the authenticity of the second identity by a trustworthy entity, for example a Registration Authority (RA).
- a trustworthy entity for example a Registration Authority (RA).
- the second device can interact with the trusted entity via the distributed database or can be implemented as part of the trusted entity.
- the user can be identified via the second identity outside the distributed database. Anonymous or pseudonymous use of the first identity can thus be avoided.
- the second identity comprises one or more information which identify the user as a natural person, legal person, machine or physical object.
- the information can, for example, be a name, e.g. Include personal names, organization names, device names, product names or manufacturer names.
- such information can also include other labeling information, e.g. include a product number or address data.
- Identification as a natural person or a legal person can also enable legal claims to be enforced, for example. This can e.g. be advantageous if the first identity is used in a business transaction between the user and another user, e.g. to sign a corresponding transaction in the distributed database.
- the transaction for linking the identities can be initiated exclusively by one or more users of the distributed database classified as trustworthy. In this way, for example, the authenticity of the second identity can be ensured.
- the second device is further configured to:
- the further transaction breaking the link between the first identity and the second identity.
- the further transaction can likewise be initiated exclusively by one or more users of the distributed database classified as trustworthy, for example by the same user. User who initiated the transaction to link the identities. In this way, the previously created linking of the first and second identities can be broken again in an efficient and tamper-proof manner.
- a first method includes:
- the first identity of the user comprises a public cryptographic key, which can be used to sign a transaction in the distributed database.
- the transaction data of this transaction can include the public cryptographic key, a hash value of the public cryptographic key and / or an identifier of the public cryptographic key.
- the transaction for linking the identities can be initiated exclusively by one or more users of the distributed database classified as trustworthy. In this way, for example, the authenticity of the second identity can be ensured.
- the user can be identified via the second identity outside of the distributed database.
- the second identity comprises one or more pieces of information which identify the user as a natural person, legal person, machine or physical object.
- the information can include, for example, a name, for example personal name, organization name, device name, product name or manufacturer Include steep names.
- such information can also include other labeling information, for example a product number, or address data.
- the first method further comprises:
- the further transaction can also be initiated exclusively by one or more users of the distributed database classified as trustworthy, e.g. by the same user who initiated the transaction to link the identities.
- a second method includes:
- the first identity of the user comprises a public cryptographic key used to sign the first transaction.
- the first transaction data can include the public cryptographic key, a hash value of the public cryptographic key and / or an identifier of the public cryptographic key.
- the checking of the second identity can include a confirmation of the authenticity of the second identity by a trustworthy entity, for example a Registration Authority (RA).
- a trustworthy entity for example a Registration Authority (RA).
- RA Registration Authority
- the user can be identified via the second identity outside the distributed database.
- the second identity comprises one or more information which identify the user as a natural person, legal person, organization, machine or physical object.
- the information can for example be a name, e.g. Include personal names, organization names, device names, product names or manufacturer names.
- such information can also contain other labeling information, e.g. include a product number, or address information.
- the transaction for linking the identities can be initiated exclusively by one or more users of the distributed database classified as trustworthy.
- the second method further comprises:
- the further transaction can also be initiated exclusively by one or more users of the distributed database classified as trustworthy, e.g. by the same user who initiated the transaction to link the identities.
- a computer program or computer program product is provided, for example in the form of a machine-readable data medium such as a CD, a DVD, a magnetic tape, a hard disk or a USB stick, which comprises program code which, when executed by one or more processors, comprises one Programmable device effects that the device the first method and / or second method according to one of the above execution examples.
- the program code can be a source code (for example in a programming language such as C or C ++) that still has to be compiled and bound or interpreted, or it can be an executable program code.
- the user can be an entity about which information is stored in the distributed database.
- entities are: a natural person, a legal person, a machine, e.g. an IoT device (IoT: "Internet of Things” or Internet of Things), or a physical object, e.g. a product.
- IoT Internet of Things
- a product e.g. a product.
- the use of the distributed database which can be implemented, for example, as a blockchain, enables the link between the first identity and the second identity to be stored in an efficient manner with high integrity and to be accessible to other users of the distributed database without this requires a separate PKI infrastructure.
- the transaction data can be stored in different nodes of a distributed database system, which can be spatially separated from one another.
- the nodes of the distributed database system can compare the transaction data with one another, so that it is ensured that the transaction data are stored redundantly in different nodes of the distributed database. Manipulation of a single node or a few nodes in the distributed database can thus be reliably identified by the comparison between the nodes. Any discrepancy in the transaction data between two nodes that was detected by the comparison can also be corrected by the comparison.
- FIG. 1 schematically illustrates a distributed database according to an embodiment.
- FIG. 2 schematically shows a distributed database system according to an exemplary embodiment.
- FIG. 3 shows a flowchart to illustrate a method according to an exemplary embodiment.
- FIG. 4 shows a flowchart to illustrate a further method according to an exemplary embodiment.
- the distributed database 100 comprises a number of data blocks 101-103 which are linked in the form of a chain or sequence of data blocks 101-103.
- Each data block 101-103 has a checksum 111-113 which, for example, represents a hash value.
- the checksum 111-113 is determined depending on the respective previous data block within the sequence of data blocks 101-103.
- the checksum 112 of the data block 102 is formed as a function of the data block 101, which is represented by the corresponding arrow in FIG. 1.
- the checksum 112 or 113 of the data block 102 or 103 can, for example, be a hash value which is calculated on the basis of the data stored in the respectively previous data block 101 or 102. As a result, an (unauthorized) modification of the data block 101 or 102 can be detected by comparing the data block 101 or 102 with the checksum 112 or 113.
- Transactions 120 may be stored in each data block 101-103. Each transaction 120 can contain corresponding data or refer to corresponding data by storing a corresponding reference or a corresponding additional information or a corresponding checksum etc.
- the data relating to a specific transaction 120 stored in the distributed database 100 is also referred to herein as transaction data.
- the transaction data stored in the data blocks 101-103 may include data on a contract between two or more users of the distributed database 100, for example.
- the transactions 120 stored in the data blocks 101, 102, 103 can in particular contain program code implemented as a smart contract.
- This program code can include information as to whether a transaction 120 is permitted.
- different business transactions such as contracts or the like can be implemented in a flexible and can be organized in a secure manner using a shared, distributed database structure.
- a hash tree, a Merkle tree or a Patricia tree can be used to secure the contents of the respective data blocks 101, 102, 103.
- FIG. 2 shows a distributed database system 200 that can be used to implement the distributed database 100.
- the distributed database system comprises a plurality of nodes 210, 230, 250, 260, 280 which transactions in the distributed database 100 can execute.
- each of the nodes 210, 230, 250, 260, 280 has at least one processor 211, 231, 251, 261, 281 and a memory 212, 232, 252, 262, 282.
- program code can be executed which is stored in the memory 212, 232, 252, 262, 282.
- this can be program code of the transactions of the distributed database 100, e.g. Smart contract program code.
- At least some of the nodes 210, 230, 250, 260, 280 store the transaction data 120 of the distributed database 100 as explained above and take part in a consensus process in order to compare the stored transaction data 120 with one another and thus to protect them against manipulation.
- the nodes 210, 230, 250, 260, 280 can each be assigned to a user of the distributed database 100 and can accordingly also be referred to as a user node or subscriber node.
- Each user of the distributed database is assigned a first identity. This first identity can be used in particular to sign transactions initiated by the user. The first identity can thus correspond to a blockchain identity of the user.
- the first identity includes in particular a public cryptographic key.
- the public cryptographic key can be stored as part of the transaction data 120 in the distributed database. It is also possible to refer to the public cryptographic to store graphical keys in the transaction data 120, for example in the form of a hash value or another type of identifier.
- the node 250 is assigned to a user who is classified as trustworthy.
- certain types of transactions can thereby be initiated via the node 250 which are not available to other users of the distributed database 100.
- these serve to link the first identity of a user of the distributed database 100 to a second identity.
- the first identity is to be linked to a second identity.
- the user of the node 230 initiates a corresponding transaction in the distributed database 100.
- the node 230 need not be a participant in the distributed database 100, i.e. it is not necessary for the node 230 itself to store transaction data from the distributed database 100 or to participate in the consensus process of the distributed database 100.
- the second identity can in particular be information which identifies the user outside the distributed database as a natural person, legal person, organization, machine or physical object.
- the second identity preferably enables a unique identification of the user.
- the second identity can thus be used to identify the respective user outside of the distributed database 100.
- the first identity of the user can be used anonymously or pseudonymously, whereas the linking of the first identity with the second identity cancels the anonymous or pseudonymous character of the first identity.
- the link is made in which a data structure called a certificate in the distributed database 100, ie as part of the transaction data 120 is saved.
- the certificate can in particular be stored in the distributed database 100 as the state of a smart contract.
- the node 250 which initiates the link can thus also be referred to as a “certification authority” (CA) or CA node.
- CA certification authority
- the node 250 which initiates the link can thus also be referred to as a “certification authority” (CA) or CA node.
- the CA node 250 interacts via the distributed database 100 with a further node 260, which supports the CA node 250 in checking the second identity of the user.
- the further node 260 can confirm the authenticity or legality of the second identity to the CA node. This can be done in a manner similar to that of a "Registration Authority"
- the node 260 can therefore also be referred to as an RA node.
- the RA node 260 confirms the authenticity or legality of the second identity through a transaction in the distributed database 100.
- program code which is stored in the memory 262 can be executed by means of the at least one processor 261 of the RA node. In particular, this can be program code to implement typical RA functions.
- the RA node 260 need not be a member of the distributed database 100, ie it is not necessary that the RA node 260 itself be transaction data distributed database 100 stores or participates in the consensus process of the distributed database 100.
- one or more access nodes 280 can also be provided in the distributed database system 200, via which queries to the distributed database 100 are possible.
- the access node 280 may send a request for a particular transaction to the distributed database 100 and then receive a response indicating whether the transaction is allowed or not and also indicating the second identity of the user who initiated the transaction .
- a request can also be made to the distributed database 100 via the node 280 in order to verify the second identity of the user.
- the access node 280 need not be a participant in the distributed database 100, i.e. it is not necessary for the access node 280 itself to store transaction data from the distributed database 100 or to participate in the consensus process of the distributed database 100.
- CA node 250 and one RA node 260 are shown in FIG. 2, it is understood that, in some implementations, several CA nodes 250 and / or several RA nodes 260 could also be provided. Likewise, a plurality of nodes 230 can be provided, via which a user can initiate a link between his first identity and a second identity. Furthermore, any number of access nodes 280 can also be provided, or separate access nodes which are not participants in the distributed database 100 could be completely dispensed with.
- a smart contract program code for implementing the functionalities explained above can have the following functions:
- the basic data structure can be defined in a certificate as shown in Table 1.
- blockchainld stands for the address in the blockchain that corresponds to the above-mentioned first identity
- commonName for the second identity that is to be linked with the first identity from the blockchain
- startDate and "endDate” define the start or end of a validity period of the certificate.
- a state of the certificate is indicated by “state” and can assume the values "Requested”, “Approved”, “Certified” and “Revoked”, which are normally run through in succession at least until “Certified”.
- mapping In the smart contract language "Solidity”, a mapping called “certificates” can be used as the data structure for collecting the certificates.
- mapping is a data structure in which other data can be accessed via any index , with each key value in the mapping being assigned exactly one date.
- comparable data structures are also are available and could be used in other languages.
- Python and Smalltalk languages for example, a data structure comparable to the mapping of solidity is called “dictation”, in Perl “Hash” and in Java “Hashtable”, which indicates the technique of hash tables used for their implementation.
- Javascript and Wolfram Language is a comparable data structure called "associative array”.
- the keys are blockchain addresses, the values are certificates. Because mappings in Solidity cannot be iterated, additional lists of addresses for which certificates have been applied for or set to "Approved” can be used.
- a user can request a certificate in the blockchain by calling the "requestCertificate" function, giving the second identity as a parameter with which the user wants to be certified.
- the smart contract first checks whether there is already a certificate for the calling blockchain address If this is the case, you cannot apply for a new one.
- the new certificate is entered with the status "Requested” under the blockchain address of the applicant in the "certificates” mapping, and this address is also added to the list of requested certificates.
- the certificate is valid for one year fixed from creation.
- the "approveEntity" function may only be used by the RA.
- the RA can also have tasks that go beyond the functionality implemented in the example shown. Under certain circumstances, these tasks can also include processes that have to be carried out manually, for example, when authenticating The RA processes all entries in the list of requested certificates. If the RA confirms the identity and determines that a certificate can be issued, the RA causes the "approveEntity" function to increase the status of the certificate in the "certificates" mapping to "Approved". The address of the applicant is removed removed from the list of requested certificates and attached to the "approved certificates" list.
- the "certifyEntity” function may only be used by the CA.
- the CA processes all the entries in the "approved Certificates” list.
- the CA sets the status of the corresponding certificate in the “certificates” mapping to "Certified” and removes the address from the "appro vedCertificates” list.
- any user of the blockchain now wants to check whether another identity actually belongs to a specific blockchain address, he calls the "verifyEntity” function, which receives the blockchain address and the other identity encoded as a string as parameters. The function checks whether the given address in “certificates” there is an entry with the status "Certified” and the specified string. If this is the case and the certificate has not yet expired, the answer is “true”, in all other cases the answer is " false ".
- the CA can use the "revokeCertificate” function to set the status of a certificate in the "certificates” mapping to "Revoked” in order to revoke the certificate, or delete a certificate from the "certificates" mapping using the "deleteCertificate” function.
- FIG. 3 shows a flowchart to illustrate a method that can be used to implement the illustrated concepts in a node 210, 230, 250, 260, 280 of the distributed database system 200.
- the procedure can for example, implemented by program code, which is stored in a memory of the node 210, 230, 250, 260, 280, by one or more processors 211, 231, 251, 261, 281 of the node 210, 230, 250, 260, 280 is running.
- the node 210, 230, 250, 260, 280 can optionally store first transaction data 120 of a first transaction in the distributed database 100.
- the first transaction is initiated by a user of the distributed database 100. This can be a node 210, 230,
- a first identity is assigned to the user.
- the transaction can be linked to a first identity.
- the first transaction may be a request from the user to link the first identity to a second identity, e.g. by calling the "request certificate" function mentioned above.
- the first identity comprises a public cryptographic key of the user used to sign the first transaction.
- the first identity can be a public cryptographic key of the user used to sign the first transaction.
- the first transaction data can contain the public cryptographic key, a hash value of the public cryptographic key and / or another identifier of the public cryptographic key.
- node 210, 230, 250, 260, 280 stores second transaction data 120 of a second transaction in distributed database 100.
- the second transaction links the first identity to a second identity. This can include, for example, that a corresponding certificate, which assigns the first identity to the second identity, is stored in the distributed database 100.
- the second transaction can in particular be initiated by a user of the distributed database 100 that is classified as trustworthy, for example via the above-mentioned CA node 250.
- the user can be identified outside of the distributed database via a second identity.
- An anonymous or pseudonymous character of the first identity can thus be removed by the link.
- the second identity can include, for example, one or more information which identify the user as a natural person, legal person, organization, machine or physical object, e.g. in the form of a name or an address.
- node 210, 230, 250, 260, 280 may optionally further store third transaction data 120 of a third transaction in distributed database 100.
- the third transaction has the effect that the link between the first identity of the user and the second identity of the user is broken. This can include that a certificate already stored in the distributed database 100, which assigns the first identity to the second identity, is declared revoked or deleted from the distributed database 100.
- the third transaction can be initiated in particular by a user of the distributed database 100 who is classified as trustworthy, e.g. via the above CA node 250.
- FIG. 4 shows a flowchart to illustrate a method that can be used to implement the concepts shown in the CA node 250 and / or RA node 260 of the distributed database system 200.
- the method can be implemented, for example, in that program code, which is stored in a memory of the CA node 250 or RA node 260, by one or more processors 251 of the CA node 250 or one or more processors 261 of the RA- Node 260 is executed.
- a user of the distributed database 100 who has a first identity becomes a second identity. This can include, for example, that the CA node 250 interacts with the RA node 260 via the distributed database 100 in order to receive confirmation from the RA node 260 of the authenticity or legality of the second identity.
- the RA node 260 in the distributed database 100 can initiate a transaction that confirms the authenticity or legality of the second identity of the user.
- the CA node can then initiate a transaction that links the first identity with the second identity.
- the CA node 250 it would also be possible for the CA node 250 to interact with the RA node 260 without involving the distributed database 100, for example by the CA node 250 sending a request to the RA node 260, whereupon the RA node 260 confirms or does not confirm the authenticity or legality of the second identity with a response to the CA node 250.
- the first identity is a public cryptographic key of the user that can be used to sign transactions in the distributed database.
- the transaction data of such transactions can be the public cryptographic key, a hash value of the public cryptographic key and / or another identifier of the public cryptographic key
- the CA account 250 which is associated with a trusted user of the distributed database 100, initiates a transaction in the distributed database 100.
- the transaction links the first identity of the user to the second identity of the user. This can include, for example, that a corresponding certificate, which assigns the first identity to the second identity, is stored in the distributed database 100.
- the functions of blocks 410 and 420 can also be standardized in a transaction which can be initiated, for example, by the CA node or the RA node 260.
- the user can be identified outside of the distributed database via a second identity.
- An anonymous or pseudonymous character of the first identity can thus be removed by the link.
- the second identity can contain, for example, one or more pieces of information which identify the user as a natural person, legal person, organization, machine or physical object.
- Such information can include, for example, a name, e.g. Include personal names, organization names, device names, product names or manufacturer names.
- such information can also include other labeling information, e.g. include a product number or address data.
- a further transaction can optionally be initiated in the distributed database 100, which removes the link between the first identity of the user and the second identity of the user.
- This can include, for example, that the CA node 250 declares a corresponding certificate, which assigns the first identity to the second identity, as revoked or deletes it from the distributed database 100.
- a link between two identities of a user of the distributed database 100 via the distributed database 100 can thus be realized without the need for a dedicated PKI infrastructure, for example.
- Transaction partners in the distributed database 100 certified or authenticated identities are available.
- the linking of the first identity with the second identity can be done in a simple and simple manner by means of the distributed database 100 tamper-proof manner can be realized. Furthermore, good verifiability and traceability of any changes to such a link can be achieved.
- a program code used for implementation for example a smart contract program code, can be created with little effort and complexity, which also enables the program code to be checked more easily. Through an implementation using program code, which is itself stored in the distributed database 100, for example as a smart contract program code, the program code can still be easily updated.
- distributed database 100 As a blockchain, various other implementations are also possible, e.g. as a "distributed ledger", which is not based on a linear
- Block structure based. Furthermore, various types of devices or systems can be used to implement the nodes 210, 250 of the distributed database system 200.
- the expression “computer” or “device” should be interpreted as broadly as possible, in particular to cover all electronic devices with data processing properties.
- Computers can thus, for example, personal computers, servers, programmable logic controllers (PLC), handheld computer systems, Pocket PC devices, cellular devices and other communication devices that can process computer-supported data, processors and other electronic devices for data processing.
- Computer-aided can be understood in connection with the present disclosure, for example, to be an implementation of the method in which, in particular, a processor carries out at least one method step of the method.
- a processor can be understood in connection with the present disclosure, for example, a machine or an electronic circuit.
- a processor can in particular be a main processor.
- CPU Central Processing Unit
- a processor may also be, for example, an IC (integrated circuit), in particular an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit, application-specific integrated circuit) ), or a DSP (digital signal processor, English Digital Signal Processor) or a graphics processor GPU (Graphic Processing Unit).
- a processor can also be understood to mean a virtualized processor, a virtual machine or a soft CPU.
- it can also be a programmable processor which is equipped with configuration steps for executing a method disclosed herein or is configured with configuration steps such that the programmable processor has the disclosed features of methods, components, modules or other aspects and / or partial aspects of the present disclosure.
- a volatile storage device in the form of memory beits Appendix (RAM) or permanent storage such as a hard drive or a data carrier can be understood.
- RAM memory beits Appendix
- permanent storage such as a hard drive or a data carrier
- Provision in particular with regard to data and / or information, can be understood in connection with the present disclosure to mean, for example, a computer-assisted provision.
- provision is made via an interface (eg a database interface, a network interface) , an interface to a storage unit.) Via this interface, for example, appropriate data can be provided
- “provide” can also be understood to mean, for example, loading or storing, for example a transaction with corresponding data. This can be done, for example, on or from a memory module. “Providing” can also be used, for example, to transfer (or sending or transmitting) corresponding data from one node to another node of the distributed database system.
- “smart contract process” can in particular be understood to mean executing a program code (for example the control commands) in a process through the distributed database or its infrastructure.
- a “checksum”, for example a data block checksum, a data checksum, a node checksum, a transaction checksum, a chaining checksum or the like, can be understood in the context of the present disclosure, for example, to be a cryptographic checksum or cryptographic hash or hash value, which in particular by means of a cryptographic hash function via a data record and / or data and / or one or more of the Transactions and / or a partial area of a data block (e.g. the block header of a block of a blockchain or data block header of a data block of the distributed database or only part of the transactions of a data block) are formed or calculated.
- a cryptographic checksum or cryptographic hash or hash value which in particular by means of a cryptographic hash function via a data record and / or data and / or one or more of the Transactions and / or a partial area of a data block (e.g. the block header of a block of a blockchain or data block header of
- a checksum can in particular be a checksum or hash value (s) of a hash tree (e.g. Merkle Baum, Patricia-Baum). Furthermore, this can in particular also be understood to mean a digital signature or a cryptographic message authentication code.
- cryptographic protection / manipulation protection for the transactions and the data (records) stored therein can be implemented at different levels of the distributed database. For example, if a high level of security is required, the checksums are generated and checked at the transaction level. If less security is required, the checksums are generated and checked at the block level (e.g. over the entire data block or only over part of the data block and / or part of the transactions).
- a “data block checksum” can be understood to mean a checksum that is calculated, for example, over part or all transactions of a data block.
- a node can then, for example, check the integrity / authenticity of the corresponding part of a data block by means of the data block checksum
- the data block checksum can in particular also have been formed via transactions of a previous data block / predecessor data block of the data block.
- the data block checksum can in particular also be by means of a hash tree, for example a Merkle tree [1]. or a Patricia tree, where the data block checksum is in particular the root checksum of the Merkle tree or a Patricia tree or a binary hash tree Tree removed secures (e.g.
- the data block checksum can thus secure the transactions, for example, by forming the root checksum from the further checksums.
- the data block checksum can be calculated in particular for transactions of a specific data block of the data blocks.
- such a data block checksum can be included in a subsequent data block of the specific data block in order to concatenate this subsequent data block with its previous data blocks, for example, and in particular thus to make it possible to check the integrity of the distributed database.
- the data block checksum can, for example, take on the function of the chaining checksum or be included in the chaining checksum.
- the header of a data block (e.g. a new data block or the data block for which the data block checksum was formed) can comprise, for example, the data block checksum.
- transaction checksum can be understood to mean a checksum which is formed in particular via a transaction of a data block.
- a calculation of a data block checksum for a corresponding data block can be accelerated, since for this purpose transaction checksums already calculated, for example, equal to Leaves, for example, of a Merkle tree can be used.
- a “chaining checksum” can be understood to mean a checksum which, in particular, specifies or references a respective data block of the distributed database to the previous data block of the distributed database (frequently in the specialist literature as “previous block hash”) designated)
- a corresponding chaining checksum is formed, in particular for the corresponding previous data block.
- a transaction checksum or the data block checksum of a da- tenblocks can be used to link a new data block with an (existing) data block of the distributed database.
- a checksum it is also possible, for example, for a checksum to be formed via a header of the previous data block or over the entire previous data block and to be used as a chaining checksum. This can also be calculated for several or all of the previous data blocks, for example. It is also feasible, for example, that the chaining checksum is formed via the header of a data block and the data block checksum.
- a respective data block of the distributed database preferably comprises a chaining checksum, which was calculated for a previous data block, in particular even more preferably the directly preceding data block, of the respective data block or refer to it.
- a corresponding chaining checksum it is also possible for a corresponding chaining checksum to be formed only over part of the corresponding data block (for example, previous data block).
- a data block can be realized which comprises an integrity-protected part and an unprotected part. This could be used, for example, to implement a data block whose integrity-protected part cannot be changed and whose unprotected part can also be changed later.
- integrity-protected means in particular that a change in integrity-protected data can be determined by means of a checksum.
- the data which are stored, for example, in a transaction of a data block, can in particular be provided in different ways.
- the data e.g. B. user data such as measurement data or Da
- a transaction of a data block can only include the checksum for this data.
- the corresponding checksum can be implemented in different ways. This can e.g. B. a corresponding data block checksum of a data block (with the corresponding data) from another database or the distributed database system, a transaction checksum of a data block with the corresponding data (from the distributed database or another database) or a data checksum that was formed from the data.
- the corresponding transaction can contain a reference or an indication of a storage location (e.g. an address of a file server and details of where the corresponding data can be found on the file server; or an address of another distributed database which contains the data includes) to include.
- the corresponding data could then, for example, also be made available in a further transaction of a further data block of the distributed database (for example if the corresponding data and the associated checksums are contained in different data blocks).
- this data is made available via another communication channel (eg via another database and / or a cryptographically secured communication channel).
- an additional data record (for example a reference or an indication of a storage location) can also be stored in the corresponding transactions, which in particular indicates a storage location where the data can be called up. This is particularly advantageous in order to keep the data size of the distributed database as small as possible.
- security can be understood to mean, for example, data protection which is implemented in particular by a cryptographic process. For example, this can be done by using the distributed database for the provision or transmission or transmission of corresponding data / transactions can be realized. this is preferably a combina tion of the various (cryptographic) checksums, it extends by this particular usammen felmen feline Z, for example to improve security or cryptographic security for transaction data.
- security-protected in connection with the invention can also be understood to mean “cryptographically protected” and / or “manipulation-protected”, wherein “manipulation-protected” can also be referred to as "integrity-protected”.
- chaining / of data blocks can be understood, for example, to mean that data blocks each comprise information (for example chaining checksum) which refer to another data block or to several other data blocks in the distributed database or to these refer to [1] [4] [5].
- information for example chaining checksum
- “inserting into the distributed database”, “storing data in the distributed database” “storing in the distributed database” or the like can be understood to mean, in particular, that in particular a transaction or transactions or the like a data block with its transactions is transmitted to one or more nodes of a distributed database system, for example, if these transactions are successfully validated (eg by the node (s)), these transactions are in particular a new data block with at least one existing data block of the distributed database chained
- a trustworthy node e.g. a mining node, a blockchain oracle or a block grove platform
- a blockchain platform can be understood to mean a blockchain as a service (or “blockchain as a service”), as is proposed, for example, by Microsoft or IBM.
- a trustworthy node and / or a node can each be a node.
- Store checksum e.g. a digital signature
- a data block e.g.
- This node checksum specifies which node, for example, has linked the corresponding data block to at least one other data block in the distributed database.
- transaction or “transactions” can be understood to mean, for example, a smart contract [4] [5], a data structure or a transaction data record, each of which in particular comprises one of the transactions or a plurality of transactions.
- transaction or “transactions” can also be understood to mean, for example, the data of a transaction of a data block of a blockchain.
- a transaction can include a program code that, for example, implements a smart contract.
- a transaction can also be understood to mean a tax transaction and / or a confirmation transaction.
- a transaction can be, for example, a data structure that stores data (e.g. control commands and / or contract data
- “Saving transactions in data blocks”, “storing transactions” and the like can be understood to mean direct storage or indirect storage.
- Direct storage can be understood, for example, to mean that the corresponding data block or the corresponding transaction comprises the respective data.
- Indirect storage can be understood here, for example, to mean that the corresponding data block or the corresponding transaction comprises a checksum and optionally an additional data record (for example a reference or an indication of a storage location) for corresponding data and thus the corresponding data not directly in the data block (or the Transaction) (i.e. only a checksum for this data instead).
- these checksums can be validated, for example, as is explained, for example, under “inserting into the distributed database”.
- a “program code” (for example a smart contract) can be understood to mean, for example, one program command or a plurality of program commands which are stored in particular in one or more transactions.
- the program code can be executed in particular and becomes, for example This can be implemented, for example, by means of an execution environment (for example a virtual machine), the programming language used being preferably Turing-complete.
- the program code is preferably executed by the infrastructure of the distributed database system [4] [5]
- a virtual machine is implemented through the infrastructure of the distributed database system.
- a “smart contract” can be understood to mean, for example, an executable program code [4] [5] (see in particular definition “program code”).
- the smart contract is preferably stored in a transaction of a distributed database (e.g. a blockchain), for example in a data block of the distributed database.
- a distributed database e.g. a blockchain
- proof-of-work proof can be understood, for example, to mean the solving of a computation-intensive task that is to be solved in particular depending on the content of the data block / content of a specific transaction [1] [4] [ 5].
- Such a computationally intensive Task is also known as a cryptographic puzzle, for example.
- a “distributed database” can include, for example, a decentrally distributed database, a blockchain or blockchain, a distributed ledger, a distributed storage system, a distributed ledger technology (DLT) -based system (DLTS), an audit-proof one Database system, a cloud, a cloud service, a blockchain in a cloud or a peer-to-peer database can also be understood, for example, different implementations of a blockchain or a DLTS can be used, such as a blockchain or a DLTS using a Directed Acylic Graph (DAG), a cryptographic puzzle, a hash graph or a combination of the implementation variants mentioned [6] [7].
- DAG Directed Acylic Graph
- Cryptographic puzzle a hash graph or a combination of the implementation variants mentioned [6] [7].
- Different consensus algorithms can also be implemented, for example. This can be, for example, a consensus method using a cryptographic puzzle, gossip about gossip, virtual voting or a combination of the methods mentioned
- a “distributed database system” can be understood to mean a system for implementing a distributed database or its infrastructure.
- a distributed database system can also be understood, of which at least part of its nodes, devices and / or infrastructure can be implemented by means of a cloud.
- the corresponding components can be implemented as virtual components in the cloud (for example as a virtual node or a virtual machine). This can be done, for example, using VM goods, Amazon Web Services or Microsoft Azure.
- a hash graph is used as a blockchain.
- B. can also be blockless.
- DAG Directed Acylic Graph
- IOTA Directed Acylic Graph
- Tangle a Directed Acylic Graph
- transactions or blocks or nodes of the graph are connected to one another via directed edges.
- Acyclic means in particular that there are no loops when the graph is run through. The directional edges and the acyclicity can ensure that the chronological order of many transactions is clearly established.
- the distributed database can be, for example, a publicly distributed database (e.g. a public blockchain) or a closed (or private) distributed database (e.g. a private blockchain).
- a publicly distributed database e.g. a public blockchain
- a closed (or private) distributed database e.g. a private blockchain
- new nodes and / or devices may need, for example, a valid proof of authorization and / or valid authentication information and / or valid credentials and / or valid registration information, in order to use the distributed database system can join or be accepted by him.
- the distributed database system can, for example, also be a distributed communication system for data transmission. act in exchange. This can be, for example, a network or a peer-2-peer network.
- the distributed database (or the database system) can be a DLTS or a blockchain and a data block can be a block of the blockchain or the DLTS for the size (data size in bytes) of the data block, a data block header.
- Block header a transaction counter and one or more transactions [1].
- the data block header can include a version, a chaining checksum, a data block checksum, a time stamp, a proof-of-work proof and a nonce (one-time value, random value or counter used for the proof-of-work proof) [1] [4] [5].
- a data block can, for example, also be only a specific memory area or address area of the total data which are stored in the distributed database. This allows, for example, blockless distributed databases, such as. B. implement the IoT Chain (ITC), IOTA, and Byteball.
- ITC IoT Chain
- IOTA IOTA
- Byteball the functionalities of the blocks of a blockchain and the transactions are combined with each other in such a way that, for. B.
- a data block can also comprise one or more transactions, for example, in the simplest case a data block corresponding to a transaction.
- nonce can be understood to mean, for example, a cryptographic nonce (abbreviation for: “used only once” [2] or “number used once” [3]).
- a nonce denotes individual numbers or a letter combination that is preferably used once in the respective context (e.g. transaction, data transfer).
- previous data blocks of a (certain) data block can be understood to mean, for example, the data block of the distributed database, which in particular immediately precedes a (certain) data block.
- “previous data blocks of a (certain) data block” in particular, all data blocks of the distributed database that precede the specific data block are understood.
- Such preceding data blocks can also be referred to as “predecessor data blocks”.
- the chaining checksum or the transaction checksum can in particular only be used via the data block directly preceding the specific data block (or its transactions) or via all data blocks preceding the first data block (or their transactions) are formed.
- a “node” in connection with the present disclosure can be understood to mean, for example, devices (for example field devices, mobile telephones), computers, personal computers, smartphones, clients or subscriber devices which carry out operations with or in the distributed database
- Such nodes can, for example, execute transactions of the distributed database or their data blocks or insert or chain new data blocks with new transactions into the distributed database.
- this can Validation and / or chaining are carried out by a trustworthy node (e.g. a mining node) or exclusively by trustworthy nodes.
- a trusted node is, for example, a node that has additional security measures (e.g.
- a trustworthy node can store a node checksum (for example a digital signature or a certificate) in the new data block. In particular, this can be used to provide evidence that indicates that the corresponding data block was inserted by a specific node or indicates its origin.
- a node typically includes at least one processor to e.g. B. perform its functions computer-based or compu terimplementiert.
- a “blockchain oracle” can be understood to mean, for example, nodes, devices or computers which, for example, have a security module which, for example, uses software protection mechanisms (for example cryptographic methods), mecha niche protective devices (e.g. a lockable housing) or electrical protective devices (e.g. tamper protection or a protection system that includes the data of the security module in the event of improper use / treatment of the block chain oracle) can, for example, include cryptographic keys that are necessary for the calculation of the checksums (e.g. transaction checksums or node checksums).
- software protection mechanisms for example cryptographic methods
- mecha niche protective devices e.g. a lockable housing
- electrical protective devices e.g. tamper protection or a protection system that includes the data of the security module in the event of improper use / treatment of the block chain oracle
- cryptographic keys that are necessary for the calculation of the checksums (e.g. transaction checksums or node checksums).
- a “device” can be understood to mean, for example, a computer (system), a client, a smart phone, a server or a similar device.
- a device can be arranged outside the distributed database system or no participant in the distributed database (e.g. the block chain) (i.e. do not perform any operations in the distributed database yourself and, for example, only query them without, however, carrying out transactions, inserting data blocks or calculating proof-of-work evidence).
- a device can also implement a node of the distributed database system.
- a device can in particular be understood to mean a node of the distributed database system or also a device outside the distributed database system.
- a device outside the distributed database system can, for example, access the data (e.g. transactions) of the distributed database and / or be controlled by nodes (e.g. by means of smart contracts and / or blockchain oracles). If, for example, a control of a device outside of the distributed database system is implemented by a node of the distributed database system, this can be done, for. B. by means of a smart contract, which is stored in particular in a transaction of the distributed database.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Storage Device Security (AREA)
Abstract
Für einen Benutzer einer verteilten Datenbank (100), welcher eine erste Identität aufweist, werden Transaktionsdaten (120) einer Transaktion in der verteilten Datenbank (100) gespeichert. Die Transaktion verknüpft die erste Identität mit einer zweiten Identität.
Description
Beschreibung
Verknüpfung von Identitäten in einer verteilten Datenbank
Die vorliegende Offenbarung betrifft Verfahren, Vorrichtungen und Computerprogramme zur Bereitstellung bzw. Betrieb einer verteilten Datenbank.
Aus dem Stand der Technik sind das Dokument US 8,531,247 B2, das Dokument US 8,892,616 B2, das Dokument US 8,300,811 B2, das Dokument US 9,147,088 B2, das Dokument US 9584311 B2, das Dokument EP 2976707 Bl, das Dokument EP 2 605 445 Bl, das Do kument EP 2 870 565 Al, das Dokument EP 2 891 102 Al, das Do kument WO 2017137256 Al, das Dokument EP 2870565 Bl, EP
2891266 Bl, das Dokument EP 2961091 Al, das Dokument EP
2961093 Al, das Dokument EP 3028140 Bl, das Dokument EP
2930610 Bl, das Dokument EP 2940620 Bl, das Dokument EP
2899714 Al, das Dokument EP 2981926 A0, das Dokument EP
3125492 Bl, das Dokument EP17195125, das Dokument EP17211075, das Dokument EP18178316, das Dokument EP18156084, das Doku ment EP18151345, das Dokument EP18167702, das Dokument
EP18153594, das Dokument EP18162050, das Dokument EP18178498, das Dokument EP18152117, das Dokument EP18150133, das Doku ment EP18169145, das Dokument EP17210647, das Dokument
EP18150146, das Dokument EP18167486, das Dokument EP18168670, das Dokument EP18162049, das Dokument EP17203819, das Doku ment EP18157168, das Dokument EP18169421, das Dokument
EP17210253, das Dokument EP17205224, das Dokument EP18169269, das Dokument EP18169254, das Dokument EP17210288, das Doku ment EP18153025, das Dokument EP17200614, das Dokument
EP18156308, das Dokument EP17201758, das Dokument EP18156511, das Dokument EP18159485, das Dokument EP17203573, das Doku- ment EP 17175275, das Dokument EP17186826, das Dokument WO 2018069271 Al, das Dokument PCT/EP2017/082508, das Dokument EP17179823, das Dokument WO 2017050348 Al, das Dokument WO
2018068965 Al und das Dokument US 8 843 761 B2 bekannt.
Eine verteilte Datenbank, mitunter auch als „Distributed Led- ger" bezeichnet, nutzt typischerweise kryptographische Ver fahren und Konsensusverfahren, um in der verteilten Datenbank abgelegte Informationen gegen Manipulation zu schützen. Eine solche verteilte Datenbank kann beispielsweise als Blockchain (bzw. Blockkette) implementiert sein. Die Technologie von Blockchains bzw. Distributed Ledgers wird derzeit in einer wachsenden Vielfalt von Anwendungsgebieten genutzt. Neben An wendungen für dezentrale Bezahlsysteme (z. B. Bitcoin) werden z.B. in der Finanzindustrie neue Anwendungsmöglichkeiten ent wickelt. Insbesondere können Transaktionen zwischen Firmen dadurch ohne Vermittler bzw. Clearing-Stelle manipulationsge schützt realisiert werden. Dies ermöglicht neue Geschäftsmo delle ohne einen vertrauenswürdigen Vermittler, es reduziert die Transaktionskosten, und es können flexibel neue digitale Dienste angeboten werden, ohne eine dafür speziell eingerich tete Infrastruktur und Vertrauensbeziehungen einrichten zu müssen. Ein durch eine Blockchain geschützter Transaktionsda tensatz (oder kurz Transaktion) umfasst z. B. Programmcode, der auch als sogenannter „Smart Contract" bezeichnet werden kann .
Zur Absicherung von Transaktionen in der verteilten Datenbank ist es bekannt, die Identität eines Benutzers an einen öf fentlichen kryptographischen Schlüssel zu binden. Durch Sig natur mit einem zu diesem öffentlichen Schlüssel gehörigen privaten kryptographischen Schlüssel, der im Normalfall nur dem Benutzer zugänglich ist, kann der Benutzer nachweisen, dass eine Transaktion in der verteilten Datenbank tatsächlich von ihm veranlasst wurde.
Typischerweise werden in einer verteilten Datenbank die öf fentlichen Schlüssel der Benutzer ohne weitere Metadaten durch die Benutzer selbst erzeugt und sind somit anonym bzw. pseudonym. Bei manchen Anwendungsfällen kann es jedoch erfor derlich sein, dass die mit einer Transaktion verknüpfte Iden tität bekannt ist. Als industriell relevantes Beispiel sei etwa genannt, dass nicht alle Güter in alle Länder exportiert
werden dürfen, so dass vor dem Abschluss eines Vertrages die Identität des Vertragspartners geprüft werden muss. Je nach Anwendungsszenario kann es also notwendig sein, sicherzustel len, dass ein öffentlicher Schlüssel, einer bestimmten natür lichen oder juristischen Person zugeordnet ist. Hierdurch kann beispielsweise ermöglicht werden, dass gegen diese na türliche oder juristische Person auch Ansprüche mit gericht lichen Mitteln durchgesetzt werden können.
Zur Authentifizierung eines kryptographischen öffentlichen Schlüssels, z.B. eines öffentlichen Teils eines asymmetri schen Schlüsselpaares, ist es bekannt, eine so genannte
Public-Key-Infrastruktur (PKI) zu nutzen, bei welcher die mit dem kryptographischen öffentlichen Schlüssel verknüpfte Iden tität, z.B. eine natürliche oder juristische Person, durch eine vertrauenswürdige Instanz bestätigt wird. Diese Bestäti gung einer Identität kann z. B. durch ein Zertifikat erfol gen, das von der vertrauenswürdigen Instanz digital signiert ist. Hierbei ist erforderlich, dass die vertrauenswürdige In stanz sicherstellt, dass die verknüpfte Identität authentisch ist, z.B. anhand eines Ausweisdokuments. Diese Aufgabe kann jedoch von der vertrauenswürdigen Instanz auch an eine weite re Instanz delegiert werden, welche typischerweise als Re- gistration Authority (RA) bezeichnet wird. Die RA überprüft lediglich die behauptete Authentizität der Identität und übergibt das Ergebnis ihrer Überprüfung an eine als Certifi- cation Authority (CA) bezeichnete Instanz, die dann, wenn die Authentizität bestätigt wurde, durch Signatur des Zertifikats die Authentizität der Identität bestätigt. Im Zusammenhang mit einer verteilten Datenbank führt die dargestellte Nutzung einer PKI jedoch zu einer vergleichsweise hohen Komplexität, da z.B. neben der verteilten Datenbank auch Funktionen zur Verwaltung von Zertifikaten bereitgestellt werden müssen.
Es besteht daher ein Bedarf für Technologien, welche eine ef fiziente Nutzung einer verteilten Datenbank mit authentifi zierten Benutzern ermöglicht. Eine der vorliegenden Offenba-
rung zu Grunde liegende Aufgabe besteht darin, diesem Bedarf gerecht zu werden.
Erfindungsgemäß wird diese Aufgabe durch eine Vorrichtung nach Anspruch 1, durch eine Vorrichtung nach Anspruch 4, durch ein Verfahren nach Anspruch 10, durch ein Verfahren nach Anspruch 12 und durch Computerprogramm nach Anspruch 14. Die abhängigen Ansprüche definieren weitere Ausführungsfor men .
Gemäß einem Ausführungsbeispiel wird eine erste Vorrichtung zur Bereitstellung einer verteilten Datenbank offenbart. Die Vorrichtung kann beispielsweise einen Knoten eines verteilten Datenbanksystems implementieren. Die erste Vorrichtung ist ausgestaltet zum:
- für einen Benutzer der verteilten Datenbank, der eine erste Identität aufweist, Speichern von Transaktionsdaten einer Transaktion in der verteilten Datenbank, wobei die Transakti on die erste Identität mit einer zweiten Identität verknüpft.
Auf diese Weise kann erreicht werden, dass auf effiziente und manipulationssichere Weise die erste Identität mit der zwei ten Identität verknüpft werden kann.
Die erste Identität umfasst einen öffentlichen kryptographi- schen Schlüssel, welcher zum Signieren einer Transaktion in der verteilten Datenbank nutzbar ist. Bei Veranlassung einer solchen Transaktion, können die Transaktionsdaten dieser Transaktion den öffentlichen kryptographischen Schlüssel, ei nen Hashwert des öffentlichen kryptographischen Schlüssels und/oder einen Identifikator des öffentlichen kryptographi schen Schlüssels umfassen.
Bei einem Ausführungsbeispiel der ersten Vorrichtung ist die Transaktion zur Verknüpfung der Identitäten exklusiv durch einen oder mehrere als vertrauenswürdig eingestuften Benutzer der verteilten Datenbank veranlassbar. Auf diese Weise kann
beispielsweise die Authentizität der zweiten Identität si chergestellt werden.
Gemäß einem Ausführungsbeispiel ist die erste Vorrichtung weiterhin ausgestaltet zum:
- Speichern von Transaktionsdaten wenigstens einer weiteren Transaktion in der verteilten Datenbank, wobei die weitere Transaktion die Verknüpfung der ersten Identität des Benut zers mit der zweiten Identität des Benutzers aufhebt. Auch die weitere Transaktion kann exklusiv durch einen oder mehre re als vertrauenswürdig eingestuften Benutzer der verteilten Datenbank veranlassbar sein, z.B. durch denselben Benutzer, welcher die Transaktion zur Verknüpfung der Identitäten ver anlasst hat. Auf diese Weise kann auf effiziente und manipu lationssichere Weise die zuvor erzeugte Verknüpfung der ers ten und zweiten Identität wieder aufgehoben werden.
Die Wiederaufhebung der Verknüpfung der zwei Identitäten kann aus verschiedenen Gründen erforderlich oder sinnvoll sein. Teilweise kann dies dadurch begründet sein, dass eine juris tische Beziehung beendet wurde. Dies kann etwa beim Ausschei den eines Mitarbeiters aus einer Firma der Fall sein, oder wenn ein Kraftfahrzeug verkauft wird. Im letzteren Fall soll te es beispielsweise nicht möglich sein, dass durch das
Kraftfahrzeug weiterhin Geschäfte veranlasst werden, die zu Lasten seines ehemaligen Eigentümers gehen. Die Wiederaufhe bung von Verknüpfungen der zwei Identitäten kann auch aus Si cherheitsgründen erforderlich sein, wenn beispielsweise
Schlüsselmaterial kompromittiert wurde.
Bei einem Ausführungsbeispiel der ersten Vorrichtung ist der Benutzer über die zweite Identität außerhalb der verteilten Datenbank identifizierbar. Eine anonyme oder pseudonyme Nut zung der ersten Identität kann somit vermieden werden.
Bei einem Ausführungsbeispiel der ersten Vorrichtung umfasst die zweite Identität eine oder mehrere Informationen, welche den Benutzer als natürliche Person, juristische Person, Orga-
nisation, Maschine oder physikalisches Objekt identifizieren. Die Informationen können beispielsweise einen Namen, z.B. Personennamen, Organisationsnamen, Gerätenamen, Produktnamen oder Herstellernamen beinhalten. Weiterhin können solche In formationen auch anderweitige Kennzeichnungsinformationen, z.B. eine Produktnummer, oder Adressdaten umfassen. Der Be nutzer kann somit über die zweite Identität zuverlässig iden tifiziert werden. Die Identifizierung als natürliche Person oder juristische Person kann beispielsweise auch eine Durch setzung von Rechtsansprüchen ermöglichen. Dies kann z.B. vor teilhaft sein, wenn die erste Identität in einem Geschäfts vorgang zwischen dem Benutzer und einem weiteren Benutzer verwendet wird, z.B. um eine entsprechende Transaktion in der verteilten Datenbank zu signieren.
Gemäß einem weiteren Ausführungsbeispiel wird eine zweite Vorrichtung zur Bereitstellung einer verteilten Datenbank of fenbart. Die Vorrichtung kann beispielsweise einen Knoten ei nes verteilten Datenbanksystems implementieren oder einen Zu gang zu einem oder mehreren Knoten eines verteilten Daten banksystems bereitstellen . Die zweite Vorrichtung ist ausge staltet zum:
- für einen Benutzer der verteilten Datenbank, welcher eine erste Identität aufweist, Prüfen einer zweiten Identität; und
- Veranlassen einer Transaktion in der verteilten Datenbank, welche die erste Identität mit der zweiten Identität ver knüpft .
Die erste Identität umfasst einen öffentlichen kryptographi- schen Schlüssel, welcher von dem Benutzer zum Signieren einer Transaktion in der verteilten Datenbank nutzbar ist.
Das Prüfen der zweiten Identität kann ein Bestätigen der Au thentizität der zweiten Identität durch eine vertrauenswürdi ge Instanz, z.B. eine Registration Authority (RA) umfassen. Die zweite Vorrichtung kann über die verteilte Datenbank mit der vertrauenswürdigen Instanz interagieren oder als Teil der vertrauenswürdigen Instanz implementiert sein.
Bei einem Ausführungsbeispiel der zweiten Vorrichtung ist der Benutzer über die zweite Identität außerhalb der verteilten Datenbank identifizierbar. Eine anonyme oder pseudonyme Nut zung der ersten Identität kann somit vermieden werden.
Bei einem Ausführungsbeispiel der zweiten Vorrichtung umfasst die zweite Identität eine oder mehrere Informationen, welcher den Benutzer als natürliche Person, juristische Person, Ma schine oder physikalisches Objekt identifizieren. Die Infor mationen können beispielsweise einen Namen, z.B. Personenna men, Organisationsnamen, Gerätenamen, Produktnamen oder Her stellernamen beinhalten. Weiterhin können solche Informatio nen auch anderweitige Kennzeichnungsinformationen, z.B. eine Produktnummer, oder Adressdaten umfassen.. Der Benutzer kann somit über die zweite Identität zuverlässig identifiziert werden. Die Identifizierung als natürliche Person oder juris tische Person kann beispielsweise auch eine Durchsetzung von Rechtsansprüchen ermöglichen. Dies kann z.B. vorteilhaft sein, wenn die erste Identität in einem Geschäftsvorgang zwi schen dem Benutzer und einem weiteren Benutzer verwendet wird, z.B. um eine entsprechende Transaktion in der verteil ten Datenbank zu signieren.
Bei einem Ausführungsbeispiel der zweiten Vorrichtung ist die Transaktion zur Verknüpfung der Identitäten exklusiv durch einen oder mehrere als vertrauenswürdig eingestuften Benutzer der verteilten Datenbank veranlassbar. Auf diese Weise kann beispielsweise die Authentizität der zweiten Identität si chergestellt werden.
Gemäß einem Ausführungsbeispiel ist die zweite Vorrichtung weiterhin ausgestaltet zum:
- Veranlassen einer weiteren Transaktion in der verteilten Datenbank, wobei die weitere Transaktion die Verknüpfung der ersten Identität mit der zweiten Identität aufhebt. Die wei tere Transaktion kann ebenfalls exklusiv durch einen oder mehrere als vertrauenswürdig eingestuften Benutzer der ver teilten Datenbank veranlassbar sein, z.B. durch denselben Be-
nutzer, welcher die Transaktion zur Verknüpfung der Identitä ten veranlasst hat. Auf diese Weise kann auf effiziente und manipulationssichere Weise die zuvor erzeugte Verknüpfung der ersten und zweiten Identität wieder aufgehoben werden.
Gemäß einem weiteren Ausführungsbeispiel wird ein erstes Ver fahren bereitgestellt. Das erste Verfahren umfasst:
- für einen Benutzer einer verteilten Datenbank, welcher eine erste Identität aufweist, Speichern von Transaktionsdaten ei ner Transaktion in der verteilten Datenbank, wobei die Trans aktion die erste Identität einer zweiten Identität verknüpft.
Die erste Identität des Benutzers umfasst einen öffentlichen kryptographischen Schlüssel, welcher zum Signieren einer Transaktion in der verteilten Datenbank nutzbar ist. Bei Ver anlassung einer solchen Transaktion, können die Transaktions daten dieser Transaktion den öffentlichen kryptographischen Schlüssel, einen Hashwert des öffentlichen kryptographischen Schlüssels und/oder einen Identifikator des öffentlichen kryptographischen Schlüssels umfassen.
Bei einem Ausführungsbeispiel des ersten Verfahrens ist die Transaktion zur Verknüpfung der Identitäten exklusiv durch einen oder mehrere als vertrauenswürdig eingestuften Benutzer der verteilten Datenbank veranlassbar. Auf diese Weise kann beispielsweise die Authentizität der zweiten Identität si chergestellt werden.
Bei einem Ausführungsbeispiel des ersten Verfahrens ist der Benutzer über zweite Identität außerhalb der verteilten Da tenbank identifizierbar.
Bei einem Ausführungsbeispiel des ersten Verfahrens umfasst die zweite Identität eine oder mehrere Informationen, welcher den Benutzer als natürliche Person, juristische Person, Ma schine oder physikalisches Objekt identifizieren. Die Infor mationen können beispielsweise einen Namen, z.B. Personenna men, Organisationsnamen, Gerätenamen, Produktnamen oder Her-
Steilernamen beinhalten. Weiterhin können solche Informatio nen auch anderweitige Kennzeichnungsinformationen, z.B. eine Produktnummer, oder Adressdaten umfassen.
Gemäß einem Ausführungsbeispiel umfasst das erste Verfahren weiterhin :
- Speichern von weiteren Transaktionsdaten einer weiteren Transaktion in der verteilten Datenbank, wobei die weitere Transaktion die Verknüpfung der ersten Identität mit der zweiten Identität aufhebt.
Die weitere Transaktion kann ebenfalls exklusiv durch einen oder mehrere als vertrauenswürdig eingestuften Benutzer der verteilten Datenbank veranlassbar sein, z.B. durch denselben Benutzer, welcher die Transaktion zur Verknüpfung der Identi täten veranlasst hat.
Gemäß einem weiteren Ausführungsbeispiel wird ein zweites Verfahren bereitgestellt. Das zweite Verfahren umfasst:
- für einen Benutzer einer verteilten Datenbank, welcher eine erste Identität aufweist, Prüfen einer zweiten Identität; und
- Veranlassen einer Transaktion in der verteilten Datenbank, welche die erste Identität mit der zweiten Identität ver knüpft .
Die erste Identität des Benutzers umfasst einen zum Signieren der ersten Transaktion genutzten öffentlichen kryptographi- schen Schlüssel. Die ersten Transaktionsdaten können den öf fentlichen kryptographischen Schlüssel, einen Hashwert des öffentlichen kryptographischen Schlüssels und/oder einen Identifikator des öffentlichen kryptographischen Schlüssels umfassen .
Das Prüfen der zweiten Identität kann ein Bestätigen der Au thentizität der zweiten Identität durch eine vertrauenswürdi ge Instanz, z.B. eine Registration Authority (RA) umfassen.
Bei einem Ausführungsbeispiel des zweiten Verfahrens ist der Benutzer über die zweite Identität außerhalb der verteilten Datenbank identifizierbar.
Bei einem Ausführungsbeispiel des zweiten Verfahrens umfasst die zweite Identität eine oder mehrere Informationen, welcher den Benutzer als natürliche Person, juristische Person, Orga nisation, Maschine oder physikalisches Objekt identifizieren. Die Informationen können beispielsweise einen Namen, z.B. Personennamen, Organisationsnamen, Gerätenamen, Produktnamen oder Herstellernamen beinhalten. Weiterhin können solche In formationen auch anderweitige Kennzeichnungsinformationen, z.B. eine Produktnummer, oder Adressdaten umfassen.
Bei einem Ausführungsbeispiel des zweiten Verfahrens ist die Transaktion zur Verknüpfung der Identitäten exklusiv durch einen oder mehrere als vertrauenswürdig eingestuften Benutzer der verteilten Datenbank veranlassbar.
Gemäß einem Ausführungsbeispiel umfasst das zweite Verfahren weiterhin :
- Veranlassen einer weiteren Transaktion in der verteilten Datenbank, wobei die weitere Transaktion die Verknüpfung der ersten Identität mit der zweiten Identität aufhebt.
Die weitere Transaktion kann ebenfalls exklusiv durch einen oder mehrere als vertrauenswürdig eingestuften Benutzer der verteilten Datenbank veranlassbar sein, z.B. durch denselben Benutzer, welcher die Transaktion zur Verknüpfung der Identi täten veranlasst hat.
Gemäß einem weiteren Ausführungsbeispiel wird ein Computer programm bzw. Computerprogrammprodukt bereitgestellt, z.B. in Form eines maschinenlesbaren Datenträgers wie eine CD, eine DVD, ein Magnetband, eine Festplatte oder ein USB-Stick, wel ches Programmcode umfasst der bei Ausführung durch einen oder mehrere Prozessoren einer programmierbaren Vorrichtung be wirkt, dass die Vorrichtung das erste Verfahren und/oder
zweite Verfahren gemäß einem der oben genannten Ausführungs beispiele ausführt. Bei dem Programmcode kann es sich um ei nen Quellcode (z.B. in einer Programmiersprache wie C oder C++) , der noch compiliert und gebunden oder interpretiert werden muss, oder um einen ausführbaren Programmcode handeln.
Bei den genannten Ausführungsbeispielen kann es sich bei dem Benutzer um eine Entität handeln, zu welcher Informationen in der verteilten Datenbank gespeichert werden. Beispiele für eine solche Entität sind: eine natürliche Person, eine juris tische Person, eine Maschine, z.B. ein IoT-Gerät (IoT: „In ternet of Things" bzw. Internet der Dinge), oder ein physika lisches Objekt, z.B. ein Produkt.
Bei den genannten Ausführungsbeispielen ermöglicht die Nut zung der verteilten Datenbank, welche beispielsweise als Blockchain implementiert sein kann, dass die Verknüpfung der ersten Identität mit der zweiten Identität auf effiziente Weise mit hoher Integrität gespeichert und für andere Benut zer der verteilten Datenbank zugänglich ist, ohne dass hierzu eine gesonderte PKI-Infrastruktur erforderlich ist.
Mit der verteilten Datenbank können die Transaktionsdaten in verschiedenen Knoten eines verteilten Datenbanksystems ge speichert werden, die räumlich voneinander getrennt sein kön nen. Die Knoten des verteilten Datenbanksystems können die Transaktionsdaten gegeneinander abgleichen, so dass gewähr leistet ist, dass die Transaktionsdaten in verschiedenen Kno ten der verteilten Datenbank redundant gespeichert sind. Eine Manipulation eines einzelnen Knotens oder einiger weniger Knoten der verteilten Datenbank kann somit über den Abgleich zwischen den Knoten zuverlässig erkannt werden. Eine etwaige über den Abgleich erkannte Abweichung der Transaktionsdaten zwischen zwei Knoten kann auch über den Abgleich korrigiert werden .
Im Folgenden werden Ausführungsbeispiele der vorliegenden Er findung unter Bezugnahme auf die beigefügten Figuren näher erläutert .
Fig. 1 veranschaulicht schematisch eine verteilte Datenbank gemäß einem Ausführungsbeispiel.
Fig. 2 zeigt schematisch ein verteiltes Datenbanksystem gemäß einem Ausführungsbeispiel.
Fig. 3 zeigt ein Flussdiagramm zur Veranschaulichung eines Verfahrens gemäß einem Ausführungsbeispiel.
Fig. 4 zeigt ein Flussdiagramm zur Veranschaulichung eines weiteren Verfahrens gemäß einem Ausführungsbeispiel.
Bei der nachfolgenden Beschreibung von Ausführungsbeispielen versteht es sich, dass die beigefügten Zeichnungen als sche matisch anzusehen sind, und dass die Zeichnungen und darge stellten Elemente nicht notwendigerweise maßstabsgerecht sind. Vielmehr sollen durch die Zeichnungen Funktionen und Zusammenwirken von Elementen und Komponenten veranschaulicht werden. Hierbei versteht es sich auch, dass jegliche Verbin dung oder Kopplung von dargestellten funktionalen Blöcken, Vorrichtungen, Komponenten oder anderweitigen physischen oder funktionalen Elementen auch durch eine indirekte Verbindung oder Kopplung, z.B. über ein oder mehrere Zwischenelemente, implementiert sein könnte. Eine Verbindung zwischen Komponen ten kann beispielweise über eine drahtgebundene und/oder drahtlose Datenverbindung implementiert sein. Funktionale Blöcke können durch Hardware, Firmware und/oder Software im plementiert sein.
Fig. 1 veranschaulicht schematisch eine verteilte Datenbank 100. Im Folgenden wird davon ausgegangen, dass die verteilte Datenbank 100 als Blockchain implementiert ist. Es versteht sich jedoch, dass andere Implementierungen der verteilten Da tenbank 100 ebenfalls möglich sind.
Die verteilte Datenbank 100 umfasst mehrere Datenblöcke 101- 103, welche in Form einer Kette oder Folge von Datenblöcken 101-103 verknüpft sind. Jeder Datenblock 101-103 weist eine Prüfsumme 111-113 auf, welche beispielsweise einen Hashwert darstellt. Die Prüfsumme 111-113 wird abhängig von dem je weils vorhergehenden Datenblock innerhalb der Folge von Da tenblöcken 101-103 bestimmt. Beispielsweise wird die Prüfsum me 112 des Datenblocks 102 abhängig von dem Datenblock 101 gebildet, was durch den entsprechenden Pfeil in der Fig. 1 dargestellt wird. Die Prüfsumme 112 bzw. 113 des Datenblocks 102 bzw. 103 kann beispielsweise ein Hashwert sein, welcher anhand der in dem jeweils vorhergehenden Datenblock 101 bzw. 102 gespeicherten Daten berechnet wird. Dadurch kann eine (unautorisierte) Modifikation des Datenblocks 101 bzw. 102 erfasst werden, indem der Datenblock 101 bzw. 102 mit der Prüfsumme 112 bzw. 113 verglichen wird.
In jedem Datenblock 101-103 können Transaktionen 120 gespei chert sein. Jede Transaktion 120 kann entsprechende Daten be inhalten oder auf entsprechende Daten verweisen, indem ein entsprechender Verweis oder eine entsprechende Zusatzinforma tion oder eine entsprechende Prüfsumme usw. abgespeichert wird. Die in der verteilten Datenbank 100 gespeicherten Daten zu einer bestimmten Transaktion 120 werden hierin auch als Transaktionsdaten bezeichnet.
Die in den Datenblöcken 101-103 gespeicherten Transaktionsda ten können beispielsweise Daten zu einem Vertrag zwischen zwei oder mehr Benutzern der verteilten Datenbank 100 bein halten .
Die in den Datenblöcken 101, 102, 103 gespeicherten Transak tionen 120 können insbesondere als Smart Contract realisier ten Programmcode beinhalten. Dieser Programmcode kann Infor mationen umfassen, ob eine Transaktion 120 erlaubt ist. Auf diese Weise können beispielsweise verschiedene Geschäftsvor gänge wie Verträge oder dergleichen, auf flexible und manipu-
lationssichere Weise über eine gemeinsame verteilte Daten bankstruktur organisiert werden. Zur Absicherung der Inhalte der jeweiligen Datenblöcke 101, 102, 103 kann beispielsweise ein Hash-Baum, ein Merkle-Baum oder ein Patricia-Baum genutzt werden .
Fig. 2 zeigt ein verteiltes Datenbanksystem 200, welches zur Implementierung der verteilten Datenbank 100 verwendet werden kann. Bei dem dargestellten Beispiel umfasst das verteilte Datenbanksystem mehrere Knoten 210, 230, 250, 260, 280 welche Transaktionen in der verteilten Datenbank 100 ausführen kön nen. Wie dargestellt, verfügt jeder der Knoten 210, 230, 250, 260, 280 über wenigstens einen Prozessor 211, 231, 251, 261, 281 sowie über einen Speicher 212, 232, 252, 262, 282. Mit tels des wenigstens einen Prozessors 211, 231, 251, 261, 281 kann Programmcode ausgeführt werden, der in dem Speicher 212, 232, 252, 262, 282 abgelegt ist. Hierbei kann es sich insbe sondere um Programmcode der Transaktionen der verteilten Da tenbank 100 handeln, z.B. Smart-Contract-Programmcode . Zumin dest einige der Knoten 210, 230, 250, 260, 280 speichern wie oben erläutert die Transaktionsdaten 120 der verteilten Da tenbank 100 und nehmen an einem Konsensusverfahren teil, um die gespeicherten Transaktionsdaten 120 miteinander abzuglei chen und so gegen Manipulation zu schützen.
Die Knoten 210, 230, 250, 260, 280 können jeweils einem Be nutzer der verteilten Datenbank 100 zugeordnet sein und dem entsprechend auch als Benutzerknoten oder Teilnehmerknoten bezeichnet werden. Dabei ist jedem Benutzer der verteilten Datenbank eine erste Identität zugeordnet. Diese erste Iden tität kann insbesondere genutzt werden, um durch den Benutzer veranlasste Transaktionen zu signieren. Die erste Identität kann somit einer Blockchain-Identität des Benutzers entspre chen. Die erste Identität umfasst insbesondere einen öffent lichen kryptographischen Schlüssel. Der öffentliche krypto- graphische Schlüssel kann als Teil der Transaktionsdaten 120 in der verteilten Datenbank gespeichert werden. Weiterhin ist es auch möglich, einen Verweis auf den öffentlichen krypto-
graphischen Schlüssel in den Transaktionsdaten 120 zu spei chern, z.B. in Form eines Hashwertes oder einer anderen Art von Identifikator .
Bei dem verteilten Datenbanksystem 200 ist der Knoten 250 ei nem als vertrauenswürdig eingestuften Benutzer zugeordnet.
Wie nachfolgend näher erläutert, können hierdurch über den Knoten 250 bestimmte Arten von Transaktionen veranlasst wer den, welche für andere Benutzer der verteilten Datenbank 100 nicht verfügbar sind. Diese dienen insbesondere dazu, die erste Identität eines Benutzers der verteilten Datenbank 100 mit einer zweiten Identität zu verknüpfen. Bei dem Beispiel von Fig. 2 wird angenommen, dass für einen dem Knoten 230 zu geordneten Benutzer die erste Identität mit einer zweiten Identität verknüpft werden soll. Hierzu veranlasst der Benut zer des Knotens 230 eine entsprechende Transaktion in der verteilten Datenbank 100. Bei dem Knoten 230 muss es sich nicht um einen Teilnehmer der verteilten Datenbank 100 han deln, d.h. es ist nicht erforderlich, dass der Knoten 230 selbst Transaktionsdaten der verteilten Datenbank 100 spei chert oder am Konsensusverfahren der verteilten Datenbank 100 teilnimmt .
Bei der zweiten Identität kann es sich insbesondere um In formationen handeln, welcher den Benutzer außerhalb der ver teilten Datenbank als natürliche Person, juristische Person, Organisation, Maschine oder physikalisches Objekt identifi ziert. Die zweite Identität ermöglicht dabei vorzugsweise ei ne eindeutige Identifizierung des Benutzers. Die zweite Iden tität ist somit nutzbar, um den jeweiligen Benutzer außerhalb der verteilten Datenbank 100 zu identifizieren. Mit anderen Worten kann die erste Identität des Benutzers anonym oder pseudonym genutzt werden, wohingegen die Verknüpfung der ers ten Identität mit der zweiten Identität den anonymen bzw. pseudonymen Charakter der ersten Identität aufhebt. Bei dem dargestellten Beispiel wird die Verknüpfung vorgenommen, in dem eine als Zertifikat bezeichnete Datenstruktur in der ver teilten Datenbank 100, d.h. als Teil der Transaktionsdaten
120, gespeichert wird. Das Zertifikat kann dabei insbesondere als Zustand eines Smart Contracts in der verteilten Datenbank 100 gespeichert werden.
Der Knoten 250, welcher die Verknüpfung veranlasst, kann so mit auch als „Certification Authority" (CA) bzw. CA-Knoten bezeichnet werden. Indem die Verknüpfung in der verteilten Datenbank 100 gespeichert wird und indem die entsprechende Transaktion nur durch den CA-Knoten 250 veranlasst werden kann, können Manipulationen der Verknüpfung zuverlässig ver mieden werden. Weiterhin kann auch vorgesehen sein, dass durch den CA-Knoten 250 Transaktionen veranlasst werden, um eine bereits bestehende Verknüpfung der ersten Identität und der zweiten Identität eines Benutzers wieder aufzuheben. Dies kann beinhalten, dass ein bereits in der verteilten Datenbank 100 gespeichertes Zertifikat als widerrufen gekennzeichnet wird oder gelöscht wird.
Bei dem dargestellten Beispiel interagiert der CA-Knoten 250 über die verteilte Datenbank 100 mit einem weiteren Knoten 260, welche den CA-Knoten 250 bei einer Prüfung der zweiten Identität des Benutzers unterstützt. Insbesondere kann der weitere Knoten 260 dem CA-Knoten die Authentizität bzw. Lega lität der zweiten Identität bestätigen. Dies kann auf ähnli che Weise erfolgen wie bei einer „Registration Authority"
(RA) eines herkömmlichen PKI-Systems. Der Knoten 260 kann da her auch als RA-Knoten bezeichnet werden. Bei dem dargestell ten Beispiel bestätigt der RA-Knoten 260 durch eine Transak tion in der verteilten Datenbank 100 die Authentizität bzw. Legalität der zweiten Identität. Wie bereits erwähnt, kann mittels des wenigstens einen Prozessors 261 des RA-Knotens Programmcode ausgeführt werden, der in dem Speicher 262 abge legt ist. Hierbei kann es sich insbesondere um Programmcode handeln, um typische RA-Funktionen zu implementieren. Bei dem RA-Knoten 260 muss es sich nicht um einen Teilnehmer der ver teilten Datenbank 100 handeln, d.h. es ist nicht erforder lich, dass der RA-Knoten 260 selbst Transaktionsdaten der
verteilten Datenbank 100 speichert oder am Konsensusverfahren der verteilten Datenbank 100 teilnimmt.
Wie dargestellt können bei dem verteilten Datenbanksystem 200 auch ein oder mehrere Zugangsknoten 280 vorgesehen sein, über welche Abfragen an die verteilte Datenbank 100 möglich sind. Beispielsweise kann der Zugangsknoten 280 eine Anfrage zu ei ner bestimmten Transaktion an die verteilte Datenbank 100 senden und dann eine Antwort erhalten, welche anzeigt ob die Transaktion erlaubt ist oder nicht und darüber hinaus die zweite Identität des Benutzers anzeigt, durch den die Trans aktion veranlasst wurde. Über den Knoten 280 kann beispiels weise auch eine Anfrage an die verteilte Datenbank 100 ge stellt werden, um die zweite Identität des Benutzers zu veri fizieren. Bei dem Zugangsknoten 280 muss es sich nicht um ei nen Teilnehmer der verteilten Datenbank 100 handeln, d.h. es ist nicht erforderlich, dass der Zugangsknoten 280 selbst Transaktionsdaten der verteilten Datenbank 100 speichert oder am Konsensusverfahren der verteilten Datenbank 100 teilnimmt.
Obwohl in Fig. 2 lediglich ein CA-Knoten 250 und ein RA- Knoten 260 dargestellt sind, versteht es sich, dass bei man chen Implementierungen auch mehrere CA-Knoten 250 und/oder mehrere RA-Knoten 260 vorgesehen sein könnten. Ebenso können mehrere Knoten 230 vorgesehen sein, über welche ein Benutzer eine Verknüpfung seiner ersten Identität mit einer zweiten Identität veranlassen kann. Weiterhin kann auch eine beliebi ge Anzahl von Zugangsknoten 280 vorgesehen sein, oder es könnte vollständig auf gesonderte Zugangsknoten, welche nicht Teilnehmer der verteilten Datenbank 100 sind, verzichtet wer den .
Bei einer beispielhaften Implementierung kann ein Smart- Contract-Programmcode zur Implementierung der oben erläuter ten Funktionalitäten folgende Funktionen aufweisen:
- eine Funktion „requestCertificate",
- eine Funktion „approveEntity",
- eine Funktion „certifyEntity",
- eine Funktion „revokeCertificate",
- eine Funktion „deleteCertificate" und
- eine Funktion „verifyEntity" .
Diese Funktionen können beispielsweise jeweils durch einen oder mehrere Smart-Contract-Prozesse implementiert sein.
Die grundlegende Datenstruktur kann ein Zertifikat wie in Ta belle 1 gezeigt definiert werden. struct Certificate {
address blockchainld;
string commonName;
uint256 startDate;
uint256 endDate;
State state;
}
Tabelle 1
Hierbei steht „blockchainld" für die Adresse in der Block- chain, welche der oben genannten ersten Identität entspricht, „commonName" für die zweite Identität, die mit der ersten Identität aus der Blockchain verknüpft werden soll, und „startDate" und „endDate" definieren Beginn bzw. Ende eines Gültigkeitszeitraums des Zertifikats. Ein Zustand des Zerti fikats wird durch „state" angegeben und kann die Werte „Requ- ested", „Approved", „Certified" und „Revoked" annehmen, wel che im Normalfall nacheinander zumindest bis „Certified" durchlaufen werden.
Als Datenstruktur zum Sammeln der Zertifikate kann bei der Smart-Contract-Sprache „Solidity" ein als "certificates" be- zeichnetes Mapping genutzt werden. Ein Mapping ist in Solidi ty eine Datenstruktur, bei der über beliebige Indizes auf an dere Daten zugegriffen werden kann, wobei jedem im Mapping vorhandenen Schlüsselwert genau ein Datum zugeordnet ist. Es versteht sich jedoch, dass vergleichbare Datenstrukturen auch
in anderen Sprachen zur Verfügung stehen und genutzt werden könnten. So wird in den Sprachen Python und Smalltalk eine dem Mapping von Solidity vergleichbare Datenstruktur „Dictio nary" genannt, in Perl „Hash" und in Java „Hashtable", was auf die zu ihrer Implementierung verwendete Technik der Hash- tabellen hinweist. In den Sprachen Javascript und Wolfram Language wird eine vergleichbare Datenstruktur mit „Associa- tive Array" bezeichnet. Im Mapping „certificates" sind die Schlüssel Blockchainadressen, die Werte Zertifikate. Weil über Mappings in Solidity nicht iteriert werden kann, können zusätzlich Listen von Adressen, für die Zertifikate beantragt bzw. auf „Approved" gesetzt wurden, genutzt werden.
Zunächst kann ein Benutzer in der Blockchain ein Zertifikat durch Aufruf der Funktion „requestCertificate" beantragen, wobei er als Parameter die zweite Identität mitgibt, mit der der Benutzer zertifiziert werden will. Der Smart Contract überprüft zunächst, ob es zur aufrufenden Blockchainadressse bereits ein Zertifikat gibt. Ist dies der Fall, kann kein neues beantragt werden.
Das neue Zertifikat wird mit dem Status "Requested" unter der Blockchainadresse des Antragstellers in das Mapping „certifi- cates" eingetragen, und diese Adresse wird auch an die Liste der beantragten Zertifikate angehängt. Die Gültigkeitsdauer des Zertifikats wird bei dem dargestellten Beispiel auf ein Jahr ab Erstellung festgelegt.
Die Funktion „approveEntity" darf nur von der RA verwendet werden. Bei praktischen Anwendungen kann die RA auch über die im dargestellten Beispiel realisierte Funktionalität hinaus gehende Aufgaben haben. Diese Aufgaben können unter Umständen auch manuell durchzuführende Vorgänge beinhalten, z. B. wenn zur Authentifizierung natürlichen Person ein Ausweisdokument der Person vorzulegen ist. Die RA arbeitet alle in der Liste der beantragten Zertifikate befindlichen Einträge ab.
Wenn die RA die Identität bestätigt und feststellt, dass ein Zertifikat erteilt werden kann, veranlasst die RA, dass mit der Funktion „approveEntity" der Status des Zertifikats im Mapping „certificates" auf „Approved" erhöht wird. Die Adres se des Antragstellers wird aus der Liste der beantragten Zer tifikate entfernt und an die Liste „approvedCertificates" an gehängt .
Die Funktion „certifyEntity" darf nur von der CA verwendet werden. Die CA arbeitet alle in der Liste „approvedCertifica tes" befindlichen Einträge ab. Die CA setzt den Status des entsprechenden Zertifikats im Mapping „certificates" auf „Certified" und entfernt die Adresse aus der Liste „appro vedCertificates" .
Wenn nun irgendein Benutzer der Blockchain überprüfen will, ob eine andere Identität tatsächlich zu einer bestimmten Blockchainadresse gehört, ruft er die Funktion „verifyEntity" auf, die als Parameter die Blockchainadresse und die als String codierte andere Identität erhält. Die Funktion prüft, ob unter der angegeben Adresse in „certificates" ein Eintrag mit dem Status „Certified" und dem angegebenen String exis tiert. Ist dies der Fall, und ist das Zertifikat noch nicht abgelaufen, wird als Antwort „true" zurückgegeben, in allen anderen Fällen wird als Antwort „false" ausgegeben.
Weiterhin sind bei dem dargestellten Beispiel Funktionen vor gesehen, um Zertifikate zu revozieren oder zu löschen. So kann die CA durch die Funktion „revokeCertificate" den Status eines Zertifikats im Mapping „certificates" auf „Revoked" setzen, um das Zertifikat zu widerrufen, oder durch die Funk tion „deleteCertificate" ein Zertifikats aus dem Mapping „certificates" löschen.
Fig. 3 zeigt ein Flussdiagramm zur Veranschaulichung eines Verfahrens, das zur Implementierung der dargestellten Konzep te in einem Knoten 210, 230, 250, 260, 280 des verteilten Da tenbanksystems 200 genutzt werden kann. Das Verfahren kann
beispielsweise implementiert werden, indem Programmcode, wel cher in einem Speicher des Knotens 210, 230, 250, 260, 280 abgelegt ist, von einem oder mehreren Prozessoren 211, 231, 251, 261, 281 des Knotens 210, 230, 250, 260, 280 ausgeführt wird .
Bei Block 310 kann der Knoten 210, 230, 250, 260, 280 optio nal erste Transaktionsdaten 120 einer ersten Transaktion in der verteilten Datenbank 100 speichern. Die erste Transaktion wird durch einen Benutzer der verteilten Datenbank 100 veran lasst. Hierbei kann es sich um einen dem Knoten 210, 230,
250, 260, 280 zugeordneten Benutzer oder einen anderen Benut zer der verteilten Datenbank handeln. Dem Benutzer ist eine erste Identität zugeordnet. Die Transaktion kann mit einer ersten Identität verknüpft sein. Bei der ersten Transaktion kann es sich um eine Anfrage des Benutzers für eine Verknüp fung der ersten Identität mit einer zweiten Identität han deln, z.B. durch Aufruf der oben genannten Funktion „request- Certificate" .
Die erste Identität umfasst einen zum Signieren der ersten Transaktion genutzten öffentlichen kryptographischen Schlüs sel des Benutzers. Insbesondere kann es sich bei der ersten Identität um einen zum Signieren der ersten Transaktion ge nutzten öffentlichen kryptographischen Schlüssel des Benut zers handeln. Die ersten Transaktionsdaten können den öffent lichen kryptographischen Schlüssel, einen Hashwert des öf fentlichen kryptographischen Schlüssels und/oder einen ander weitigen Identifikator des öffentlichen kryptographischen Schlüssels beinhalten.
Bei Block 320 speichert der Knoten 210, 230, 250, 260, 280 zweite Transaktionsdaten 120 einer zweiten Transaktion in der verteilten Datenbank 100. Die zweite Transaktion verknüpft die erste Identität mit einer zweiten Identität. Dies kann beispielsweise beinhalten, dass ein entsprechendes Zertifi kat, welches die erste Identität der zweiten Identität zuord net, in der verteilten Datenbank 100 gespeichert wird. Die
zweite Transaktion kann insbesondere durch einen als vertrau enswürdig eingestuften Benutzer der verteilten Datenbank 100 veranlasst sein, z.B. über den oben genannten CA-Knoten 250.
Über zweite Identität kann der Benutzer außerhalb der ver teilten Datenbank identifizierbar sein. Ein anonymer oder pseudonymer Charakter der ersten Identität kann somit durch die Verknüpfung aufgehoben werden. Die zweite Identität kann beispielsweise eine oder mehrere Informationen beinhalten, welche den Benutzer als natürliche Person, juristische Per son, Organisation, Maschine oder physikalisches Objekt iden tifizieren, z.B. in Form eines Namens oder einer Adresse.
Bei Block 330 kann der Knoten 210, 230, 250, 260, 280 optio nal weiterhin dritte Transaktionsdaten 120 einer dritten Transaktion in der verteilten Datenbank 100 speichern. Die dritte Transaktion bewirkt, dass die Verknüpfung der ersten Identität des Benutzers mit der zweiten Identität des Benut zers aufgehoben wird. Dies kann beinhalten, dass ein bereits in der verteilten Datenbank 100 gespeichertes Zertifikat, welches die erste Identität der zweiten Identität zuordnet, als widerrufen deklariert oder aus der verteilten Datenbank 100 gelöscht wird. Die dritte Transaktion kann insbesondere durch einen als vertrauenswürdig eingestuften Benutzer der verteilten Datenbank 100 veranlasst sein, z.B. über den oben genannten CA-Knoten 250.
Fig. 4 zeigt ein Flussdiagramm zur Veranschaulichung eines Verfahrens, das zur Implementierung der dargestellten Konzep te in dem CA-Knoten 250 und/oder RA-Knoten 260 des verteilten Datenbanksystems 200 genutzt werden kann. Das Verfahren kann beispielsweise implementiert werden, indem Programmcode, wel cher in einem Speicher des CA-Knotens 250 bzw. RA-Knotens 260 abgelegt ist, von einem oder mehreren Prozessoren 251 des CA- Knotens 250 bzw. einem oder mehreren Prozessoren 261 des RA- Knotens 260 ausgeführt wird.
Bei Block 410 wird für einen Benutzer der verteilten Daten bank 100, welcher eine erste Identität aufweist, eine zweite Identität. Dies kann beispielsweise beinhalten, dass der CA- Knoten 250 über die verteilte Datenbank 100 mit dem RA-Knoten 260 interagiert, um von dem RA-Knoten 260 eine Bestätigung der Authentizität oder Legalität der zweiten Identität zu er halten. Insbesondere kann der RA-Knoten 260 in der verteilten Datenbank 100 eine Transaktion veranlassen, welche die Au thentizität oder Legalität der zweiten Identität des Benut zers bestätigt. Der CA-Knoten kann daraufhin eine Transaktion veranlassen, welche die erste Identität mit der zweiten Iden tität verknüpft. Alternativ wäre es jedoch auch möglich, dass der CA-Knoten 250 ohne Einbeziehung der verteilten Datenbank 100 mit dem RA-Knoten 260 interagiert, z.B. indem der CA- Knoten 250 eine Anfrage an den RA-Knoten 260 sendet, worauf hin der RA-Knoten 260 die Authentizität bzw. Legalität der zweiten Identität mit einer Antwort an den CA-Knoten 250 be stätigt oder nicht bestätigt.
Bei der ersten Identität handelt es sich um einen zum Signie ren von Transaktionen in der verteilten Datenbank nutzbaren öffentlichen kryptographischen Schlüssel des Benutzers. Die Transaktionsdaten solcher Transaktionen können den öffentli chen kryptographischen Schlüssel, einen Hashwert des öffent lichen kryptographischen Schlüssels und/oder einen anderwei tigen Identifikator des öffentlichen kryptographischen
Schlüssels beinhalten.
Bei Block 420 veranlasst der CA-Konten 250, welcher einem als vertrauenswürdig eingestuften Benutzer der verteilten Daten bank 100 zugeordnet ist, eine Transaktion in der verteilten Datenbank 100. Die Transaktion verknüpft die erste Identität des Benutzers mit der zweiten Identität des Benutzers. Dies kann beispielsweise beinhalten, dass ein entsprechendes Zer tifikat, welches die erste Identität der zweiten Identität zuordnet, in der verteilten Datenbank 100 gespeichert wird.
Die Funktionen der Blöcke 410 und 420 können auch in einer Transaktion vereinheitlicht sein, welche z.B. durch den CA- Knoten oder den RA-Knoten 260 veranlasst werden kann.
Über zweite Identität kann der Benutzer außerhalb der ver teilten Datenbank identifizierbar sein. Ein anonymer oder pseudonymer Charakter der ersten Identität kann somit durch die Verknüpfung aufgehoben werden. Die zweite Identität kann beispielsweise eine oder mehrere Informationen beinhalten, welcher den Benutzer als natürliche Person, juristische Per son, Organisation, Maschine oder physikalisches Objekt iden tifizieren. Solche Informationen können beispielsweise einen Namen, z.B. Personennamen, Organisationsnamen, Gerätenamen, Produktnamen oder Herstellernamen beinhalten. Weiterhin kön nen solche Informationen auch anderweitige Kennzeichnungsin formationen, z.B. eine Produktnummer, oder Adressdaten umfas sen .
Bei Block 430 kann optional eine weitere Transaktion in der verteilten Datenbank 100 veranlasst werden, welche die Ver knüpfung der ersten Identität des Benutzers mit der zweiten Identität des Benutzers aufhebt. Dies kann beispielsweise be inhalten, dass der CA-Knoten 250 ein entsprechendes Zertifi kat, welches die erste Identität der zweiten Identität zuord net, als widerrufen deklariert oder aus der verteilten Daten bank 100 löscht.
Bei den dargestellten Konzepten kann somit eine Verknüpfung von zwei Identitäten eines Benutzers der verteilten Datenbank 100 über die verteilte Datenbank 100 selbst realisiert wer den, ohne dass beispielsweise eine dedizierte PKI- Infrastruktur benötigt wird. Es ist jedoch möglich, die RA eines bestehenden PKI-Systems zu nutzen wodurch die Implemen tierung oder Integration in bestehende Systeme vereinfacht werden kann. Im Ergebnis kann erreicht werden, dass für
Transaktionspartner in der verteilten Datenbank 100 zertifi zierte bzw. authentifizierte Identitäten verfügbar sind. Die Verknüpfung der ersten Identität mit der zweiten Identität kann mittels der verteilten Datenbank 100 auf einfache und
manipulationssichere Weise realisiert werden. Weiterhin kann eine gute Nachprüfbarkeit und Nachverfolgbarkeit von etwaigen Änderungen einer solchen Verknüpfung erreicht werden. Ein zur Implementierung genutzter Programmcode, z.B. Smart-Contract- Programmcode kann mit geringem Aufwand und geringer Komplexi tät erstellt werden, was auch eine vereinfachte Überprüfbar keit des Programmcodes ermöglicht. Durch eine Implementierung mittels Programmcode, der selbst in der verteilten Datenbank 100 abgelegt ist, z.B. als Smart-Contract-Programmcode, kann weiterhin eine leichte Aktualisierbarkeit des Programmcodes erreicht werden.
Es versteht sich, dass bei den vorangegangenen Beispielen zahlreiche Modifikationen möglich sind. So sind neben einer Implementierung der verteilten Datenbank 100 als Blockchain auch verschiedene andere Implementierungen möglich, z.B. als „distributed Ledger", welcher nicht auf einer linearen
Blockstruktur basiert. Weiterhin können verschiedene Arten von Vorrichtungen oder Systemen verwendet werden um die Kno ten 210, 250 des verteilten Datenbanksystems 200 zu implemen tieren .
Sofern es in der vorangegangenen Beschreibung nicht anders angegeben ist, beziehen sich die Begriffe "durchführen", "be rechnen", "rechnergestützt", "rechnen", "feststellen", "gene rieren", "konfigurieren", "rekonstruieren", „steuern", „zu weisen" und dergleichen vorzugsweise auf Handlungen und/oder Prozesse und/oder Verarbeitungsschritte, die Daten verändern und/oder erzeugen und/oder die Daten in andere Daten überfüh ren, wobei die Daten insbesondere als physikalische Größen dargestellt werden oder vorliegen können, beispielsweise als elektrische Impulse. Insbesondere sollte der Ausdruck "Compu ter" oder „Vorrichtung" möglichst breit ausgelegt werden, um insbesondere alle elektronischen Geräte mit Datenverarbei tungseigenschaften abzudecken. Computer können somit bei spielsweise Personal Computer, Server, speicherprogrammierba re Steuerungen (SPS) , Handheld-Computer-Systeme, Pocket-PC- Geräte, Mobilfunkgeräte und andere Kommunikationsgeräte, die
rechnergestützt Daten verarbeiten können, Prozessoren und an dere elektronische Geräte zur Datenverarbeitung sein.
Unter „rechnergestützt" kann im Zusammenhang mit der vorlie genden Offenbarung beispielsweise eine Implementierung des Verfahrens verstanden werden, bei dem insbesondere ein Pro zessor mindestens einen Verfahrensschritt des Verfahrens aus führt .
Unter einem Prozessor kann im Zusammenhang mit der vorliegen den Offenbarung beispielsweise eine Maschine oder eine elekt ronische Schaltung verstanden werden. Bei einem Prozessor kann es sich insbesondere um einen Hauptprozessor (engl.
Central Processing Unit, CPU) , einen Mikroprozessor oder ei nen Mikrokontroller, beispielsweise eine anwendungsspezifi sche integrierte Schaltung oder einen digitalen Signalprozes sor, möglicherweise in Kombination mit einer Speichereinheit zum Speichern von Programmbefehlen, etc. handeln. Bei einem Prozessor kann es sich beispielsweise auch um einen IC (inte grierter Schaltkreis, engl. Integrated Circuit), insbesondere einen FPGA (engl. Field Programmable Gate Array) oder einen ASIC (anwendungsspezifische integrierte Schaltung, engl. Ap- plication-Specific Integrated Circuit) , oder einen DSP (Digi taler Signalprozessor, engl. Digital Signal Processor) oder einen Grafikprozessor GPU (Graphic Processing Unit) handeln. Auch kann unter einem Prozessor ein virtualisierter Prozes sor, eine virtuelle Maschine oder eine Soft-CPU verstanden werden. Es kann sich beispielsweise auch um einen program mierbaren Prozessor handeln, der mit Konfigurationsschritten zur Ausführung eines hierin offenbarten Verfahrens ausgerüs tet wird oder mit Konfigurationsschritten derart konfiguriert ist, dass der programmierbare Prozessor die offenbarten Merk male von Verfahren, Komponenten, Module oder anderer Aspekte und/oder Teilaspekte der vorliegenden Offenbarung realisiert.
Unter einer „Speichereinheit" oder „Speichermodul" oder der gleichen kann im Zusammenhang mit der vorliegenden Offenba rung beispielsweise ein flüchtiger Speicher in Form von Ar-
beitsspeicher (RAM) oder ein dauerhafter Speicher wie eine Festplatte oder ein Datenträger verstanden werden.
Unter „bereitstellen" , insbesondere in Bezug auf Daten und/oder Informationen, kann im Zusammenhang mit der vorlie genden Offenbarung beispielsweise ein rechnergestütztes Be reitstellen verstanden werden. Das Bereitstellen erfolgt bei spielsweise über eine Schnittstelle (z. B. eine Datenbank schnittstelle, eine Netzwerkschnittstelle, eine Schnittstelle zu einer Speichereinheit) . Über diese Schnittstelle können beispielsweise beim Bereitstellen entsprechende Daten
und/oder Informationen übermittelt und/oder gesendet und/oder abgerufen und/oder empfangen werden.
Unter „bereitstellen" kann im Zusammenhang mit der vorliegen den Offenbarung beispielsweise auch ein Laden oder ein Spei chern, beispielsweise einer Transaktion mit entsprechenden Daten, verstanden werden. Dies kann beispielsweise auf oder von einem Speichermodul erfolgen. Unter „Bereitstellen" kann beispielsweise auch ein Übertragen (oder ein Senden oder ein Übermitteln) von entsprechenden Daten von einem Knoten zu ei nem anderen Knoten des verteilten Datenbanksystems verstanden werden .
Unter „Smart-Contract-Prozess" kann im Zusammenhang mit der vorliegenden Offenbarung insbesondere ein Ausführen eines Programmcodes (z. B. der Steuerbefehle) in einem Prozess durch die verteilte Datenbank bzw. deren Infrastruktur ver standen werden.
Unter einer „Prüfsumme", beispielsweise eine Datenblockprüf- summe, eine Datenprüfsumme, eine Knotenprüfsumme, eine Trans aktionsprüfsumme, eine Verkettungsprüfsumme oder dergleichen, kann im Zusammenhang mit der vorliegenden Offenbarung bei spielsweise eine kryptographische Prüfsumme oder kryptogra- phischer Hash bzw. Hashwert verstanden werden, die insbeson dere mittels einer kryptographischen Hashfunktion über einen Datensatz und/oder Daten und/oder eine oder mehrere der
Transaktionen und/oder einem Teilbereich eines Datenblocks (z. B. der Block-Header eines Blocks einer Blockchain oder Datenblock-Header eines Datenblocks der verteilten Datenbank oder nur einem Teil der Transaktionen eines Datenblocks) ge bildet oder berechnet werden. Bei einer Prüfsumme kann es sich insbesondere um eine Prüfsumme/n oder Hashwert/e eines Hash-Baumes (z. B. Merkle Baum, Patricia-Baum) handeln. Wei terhin kann darunter insbesondere auch eine digitale Signatur oder ein kryptographischer Nachrichtenauthentisierungscode verstanden werden. Mittels der Prüfsummen kann beispielsweise auf unterschiedlichen Ebenen der verteilten Datenbank ein kryptographischer Schutz/Manipulationsschutz für die Transak tionen und die darin gespeicherten Daten (sätze) realisiert werden. Ist beispielsweise eine hohe Sicherheit gefordert, werden beispielsweise die Prüfsummen auf Transaktionsebene erzeugt und überprüft. Ist eine weniger hohe Sicherheit ge fordert, werden beispielsweise die Prüfsummen auf Blockebene (z. B. über den ganzen Datenblock oder nur über einen Teil des Datenblocks und/oder einen Teil der Transkationen) er zeugt und überprüft.
Unter einer „Datenblockprüfsumme" kann im Zusammenhang mit der vorliegenden Offenbarung eine Prüfsumme verstanden wer den, die beispielsweise über einen Teil oder alle Transaktio nen eines Datenblocks berechnet wird. Ein Knoten kann dann beispielsweise die Integrität/Authentizität des entsprechen den Teils eines Datenblocks mittels der Datenblockprüfsumme prüfen/feststellen . Zusätzlich oder alternativ kann die Da tenblockprüfsumme insbesondere auch über Transaktionen eines vorhergehenden Datenblocks/Vorgänger-Datenblocks des Daten blocks gebildet worden sein. Die Datenblockprüfsumme kann da bei insbesondere auch mittels eines Hash-Baumes, beispiels weise einem Merkle Baum [1] oder einem Patricia-Baum, reali siert werden, wobei die Datenblockprüfsumme insbesondere die Wurzel-Prüfsumme des Merkle-Baumes bzw. eines Patricia-Baumes bzw. eines binären Hashbaumes ist. Insbesondere werden Trans aktionen mittels weiterer Prüfsummen aus dem Merkle-Baum bzw. Patricia-Baum abgesichert (z. B. unter Verwendung der Trans-
aktionsprüfsummen) , wobei insbesondere die weiteren Prüfsum men Blätter im Merkle-Baum bzw. Patricia-Baum sind. Die Da tenblockprüfsumme kann damit beispielsweise die Transaktionen absichern, indem die Wurzel-Prüfsumme aus den weiteren Prüf summen gebildet wird. Die Datenblockprüfsumme kann insbeson dere für Transaktionen eines bestimmten Datenblocks der Da tenblöcke berechnet werden. Insbesondere kann eine solche Da tenblockprüfsumme in einen nachfolgenden Datenblock des be stimmten Datenblocks eingehen, um diesen nachfolgenden Daten block beispielsweise mit seinen vorhergehenden Datenblöcken zu verketten und insbesondere damit eine Integrität der ver teilten Datenbank prüfbar zu machen. Hierdurch kann die Da tenblockprüfsumme beispielsweise die Funktion der Verket tungsprüfsumme übernehmen oder in die Verkettungsprüfsumme eingehen. Der Header eines Datenblocks (z. B. eines neuen Da tenblocks oder des Datenblocks für den die Datenblockprüfsum me gebildet wurde) kann beispielsweise die Datenblockprüfsum me umfassen.
Unter „Transaktionsprüfsumme" kann im Zusammenhang mit der vorliegenden Offenbarung eine Prüfsumme verstanden werden, die insbesondere über eine Transaktion eines Datenblocks ge bildet wird. Zusätzlich kann beispielsweise eine Berechnung einer Datenblockprüfsumme für einen entsprechenden Datenblock beschleunigt werden, da hierfür beispielsweise bereits be rechnete Transaktionsprüfsummen gleich als Blätter z. B. ei nes Merkle-Baumes verwendet werden können.
Unter einer „Verkettungsprüfsumme" kann im Zusammenhang mit der vorliegenden Offenbarung eine Prüfsumme verstanden wer den, die insbesondere einen jeweiligen Datenblock der ver teilten Datenbank den vorhergehenden Datenblock der verteil ten Datenbank angibt bzw. referenziert (in der Fachliteratur insbesondere häufig als „previous block hash" bezeichnet)
[1] . Hierfür wird insbesondere für den entsprechenden vorher gehenden Datenblock eine entsprechende Verkettungsprüfsumme gebildet. Als Verkettungsprüfsumme kann beispielsweise eine Transaktionsprüfsumme oder die Datenblockprüfsumme eines Da-
tenblocks (also ein vorhandener Datenblock der verteilten Da tenbank) verwendet werden, um einen neuen Datenblock mit ei nem (vorhandenen) Datenblock der verteilten Datenbank zu ver ketten. Es ist beispielsweise aber auch möglich, dass eine Prüfsumme über einen Header des vorhergehenden Datenblocks oder über den gesamten vorhergehenden Datenblock gebildet wird und als Verkettungsprüfsumme verwendet wird. Dies kann beispielsweise auch für mehrere oder alle vorhergehenden Da tenblöcke berechnet werden. Es ist beispielsweise auch reali sierbar, dass über den Header eines Datenblocks und der Da tenblockprüfsumme die Verkettungsprüfsumme gebildet wird. Ein jeweiliger Datenblock der verteilten Datenbank umfasst jedoch vorzugsweise jeweils eine Verkettungsprüfsumme, die für einen vorhergehenden Datenblock, insbesondere noch bevorzugter den direkt vorhergehenden Datenblock, des jeweiligen Datenblockes berechnet wurde bzw. sich auf diesen beziehen. Es ist bei spielsweise auch möglich, dass eine entsprechende Verket tungsprüfsumme auch nur über einen Teil des entsprechenden Datenblocks (z. B. vorhergehenden Datenblock) gebildet wird. Hierdurch kann beispielsweise ein Datenblock realisiert wer den, der einen integritätsgeschützten Teil und einen unge schützten Teil umfasst. Damit ließe sich beispielsweise ein Datenblock realisieren, dessen integritätsgeschützter Teil unveränderlich ist und dessen ungeschützter Teil auch noch später verändert werden kann. Unter integritätsgeschützt ist dabei insbesondere zu verstehen, dass eine Veränderung von integritätsgeschützten Daten mittels einer Prüfsumme fest stellbar ist.
Die Daten, die beispielsweise in einer Transkation eines Da tenblocks gespeichert werden, können insbesondere auf unter schiedliche Weise bereitgestellt werden. Anstelle der Daten, z. B. Nutzerdaten wie Messdaten oder Da
ten/Eigentumsverhältnisse zu Assets, kann beispielsweise eine Transaktion eines Datenblocks nur die Prüfsumme für diese Da ten umfassen. Die entsprechende Prüfsumme kann dabei auf un terschiedliche Weise realisiert werden. Dies kann z. B. eine entsprechende Datenblockprüfsumme eines Datenblocks (mit den
entsprechenden Daten) einer anderen Datenbank oder des ver teilten Datenbanksystems sein, eine Transaktionsprüfsumme ei nes Datenblocks mit den entsprechenden Daten (der verteilten Datenbank oder einer anderen Datenbank) oder eine Datenprüf summe, die über die Daten gebildet wurde.
Zusätzlich kann die entsprechende Transkation noch einen Ver weis oder eine Angabe zu einem Speicherort (z. B. eine Adres se eines Fileservers und Angaben, wo die entsprechenden Daten auf dem Fileserver zu finden sind; oder eine Adresse einer anderen verteilten Datenbank, welche die Daten umfasst) um fassen. Die entsprechenden Daten könnten dann beispielsweise auch in einer weiteren Transaktion eines weiteren Datenblock der verteilten Datenbank bereitgestellt werden (z. B. wenn die entsprechenden Daten und die zugehörigen Prüfsummen in unterschiedlichen Datenblöcken umfasst sind) . Es ist bei spielsweise aber auch denkbar, dass diese Daten über einen anderen Kommunikationskanal (z. B. über eine andere Datenbank und/oder einen kryptographisch gesicherten Kommunikationska nal) bereitgestellt werden.
Auch kann beispielsweise zusätzlich zu der Prüfsumme ein Zu- satzdatensatz (z. B. ein Verweis oder eine Angabe zu einem Speicherort) in der entsprechenden Transaktionen abgelegt sein, der insbesondere einen Speicherort angibt, wo die Daten abgerufen werden können. Das ist insbesondere dahingehend vorteilhaft, um eine Datengröße der verteilten Datenbank mög lichst gering zu halten.
Unter „Sicherheit" kann im Zusammenhang mit der vorliegenden Offenbarung beispielsweise ein Schutz von Daten verstanden werden, der insbesondere durch ein kryptographisches Verfah ren realisiert wird. Beispielsweise kann dies durch eine Nut zung der verteilten Datenbank für das Bereitstellen oder Übertragen oder Senden von entsprechenden Daten/Transaktionen realisiert werden. Dies wird vorzugsweise durch eine Kombina tion der verschiedenen ( kryptographischen) Prüfsummen er reicht, indem diese insbesondere synergetisch Zusammenwirken,
um beispielsweise die Sicherheit bzw. die kryptographische Sicherheit für die Daten der Transaktionen zu verbessern. Mit anderen Worten kann insbesondere unter „sicherheitsgeschützt" im Zusammenhang mit der Erfindung auch „kryptographisch ge schützt" und/oder „manipulationsgeschützt" verstanden werden, wobei „manipulationsgeschützt" auch als „integritätsge schützt" bezeichnet werden kann.
Unter „Verketten der/von Datenblöcken kann im Zusammenhang mit der vorliegenden Offenbarung beispielsweise verstanden werden, dass Datenblöcke jeweils eine Information (z. B. Ver kettungsprüfsumme) umfassen, die auf einen anderen Datenblock oder mehrere andere Datenblöcke der verteilten Datenbank ver weisen bzw. diese referenzieren [1] [4] [5] .
Unter „Einfügen in die verteilte Datenbank", „Hinterlegen von Daten in der verteilten Datenbank" „Speichern in der verteil ten Datenbank" oder dergleichen kann im Zusammenhang mit der vorliegenden Offenbarung beispielsweise verstanden werden, dass insbesondere eine Transaktion bzw. die Transaktionen o- der ein Datenblock mit seinen Transaktionen an einen oder mehrere Knoten eines verteilten Datenbanksystems übermittelt wird. Werden diese Transaktionen beispielsweise erfolgreich validiert (z. B. durch den/die Knoten), werden diese Transak tionen insbesondere als neuer Datenblock mit mindestens einem vorhandenen Datenblock der verteilten Datenbank verkettet
[1] [4] [5] . Hierzu werden die entsprechenden Transaktionen beispielsweise in einem neuen Datenblock gespeichert. Insbe sondere kann dieses Validieren und/oder Verketten durch einen vertrauenswürdigen Knoten (z. B. einen Mining Node, einen Blockchain-Orakel oder eine Blockhain-Plattform) erfolgen. Insbesondere kann dabei unter einer Blockchain-Plattform eine Blockchain als Dienst (bzw. „Blockchain als Service") ver standen werden, wie es beispielsweise durch Microsoft oder IBM vorgeschlagen wird. Insbesondere können ein vertrauens würdiger Knoten und/oder ein Knoten jeweils eine Knoten- Prüfsumme (z. B. eine digitale Signatur) in einem Datenblock hinterlegen (z. B. in dem von ihnen validierten und erzeugten
Datenblock, der dann verkettet wird) , um insbesondere eine Identifizierbarkeit des Erstellers des Datenblockes zu ermög lichen und/oder eine Identifizierbarkeit des Knotens zu er möglichen. Dabei gibt diese Knoten-Prüfsumme an, welcher Kno ten beispielsweise den entsprechenden Datenblock mit mindes tens einem anderen Datenblock der verteilten Datenbank ver kettet hat.
Unter „Transaktion" bzw. „Transaktionen" können im Zusammen hang mit der vorliegenden Offenbarung beispielsweise ein Smart-Contract [4] [5], eine Datenstruktur oder ein Transak tionsdatensatz verstanden werden, der insbesondere jeweils eine der Transaktionen oder mehrere Transkationen umfasst. Unter „Transaktion" bzw. „Transaktionen" können im Zusammen hang mit der Erfindung beispielsweise auch die Daten einer Transaktion eines Datenblocks einer Blockchain verstanden werden. Eine Transaktion kann insbesondere einen Programmcode umfassen, der beispielsweise einen Smart Contract realisiert. Beispielsweise können im Zusammenhang mit der Erfindung unter Transaktion auch eine Steuertransaktionen und/oder Bestäti gungstransaktion verstanden werden. Alternativ kann eine Transaktion beispielsweise eine Datenstruktur sein, die Daten speichert (z. B. Steuerbefehle und/oder Vertragsdaten
und/oder andere Daten wie Videodaten, Nutzerdaten, Messdaten etc . ) .
Unter „Speichern von Transaktionen in Datenblöcken", „Spei chern von Transaktionen" und dergleichen kann ein direktes Speichern oder indirektes Speichern verstanden werden. Unter einem direkten Speichern kann dabei beispielsweise verstanden werden, dass der entsprechende Datenblock oder die entspre chende Transaktion die jeweiligen Daten umfasst. Unter einem indirekten Speichern kann dabei beispielsweise verstanden werden, dass der entsprechende Datenblock oder die entspre chende Transaktion eine Prüfsumme und optional einen Zusatz datensatz (z. B. einen Verweis oder eine Angabe zu einem Speicherort) für entsprechende Daten umfasst und die entspre chenden Daten somit nicht direkt in dem Datenblock (oder der
Transaktion) gespeichert sind (also stattdessen nur eine Prüfsumme für diese Daten) . Insbesondere können beim Spei chern von Transaktionen in Datenblöcken diese Prüfsummen bei spielsweise validiert werden, so wie dies beispielsweise un ter „Einfügen in die verteilte Datenbank" erläutert ist.
Unter einem „Programmcode" (z. B. ein Smart-Contract) kann im Zusammenhang mit der vorliegenden Offenbarung beispielsweise ein Programmbefehl oder mehrere Programmbefehle verstanden werden, die insbesondere in einer oder mehreren Transaktionen gespeichert sind. Der Programmcode ist insbesondere ausführ bar und wird beispielsweise durch das verteilte Datenbanksys tem ausgeführt. Dies kann beispielsweise mittels einer Aus führungsumgebung (z. B. einer virtuellen Maschine) realisiert werden, wobei die zugrundeliegende Programmiersprache vor zugsweise Turing-vollständig ist. Der Programmcode wird vor zugsweise durch die Infrastruktur des verteilten Datenbank systems ausgeführt [4] [5] . Dabei wird beispielsweise eine virtuelle Maschine durch die Infrastruktur des verteilten Da tenbanksystems realisiert.
Unter einem „Smart Contract" kann im Zusammenhang mit der vorliegenden Offenbarung beispielsweise ein ausführbarer Pro grammcode verstanden werden [4] [5] (siehe insbesondere Defi nition „Programmcode") . Der Smart Contract ist vorzugsweise in einer Transaktion einer verteilten Datenbank (z. B. eine Blockchain) gespeichert, beispielsweise in einem Datenblock der verteilten Datenbank. Beispielsweise kann der Smart
Contract auf die gleiche Weise ausgeführt werden, wie dies bei der Definition von „Programmcode", insbesondere im Zusam menhang mit der Erfindung, erläutert ist.
Unter „Proof-of-Work-Nachweis" kann im Zusammenhang mit der vorliegenden Offenbarung beispielsweise ein Lösen einer re chenintensiven Aufgabe verstanden werden, die insbesondere abhängig vom Datenblock-Inhalt/Inhalt einer bestimmten Trans aktion zu lösen ist [1] [4] [5] . Eine solche rechenintensive
Aufgabe wird beispielsweise auch als kryptographisches Puzzle bezeichnet .
Unter einer „verteilten Datenbank" kann im Zusammenhang mit der vorliegenden Offenbarung beispielsweise eine dezentral verteilte Datenbank, eine Blockchain bzw. Blockkette, ein distributed Ledger, ein verteiltes Speichersystem, ein Dis- tributed Ledger Technology (DLT) basiertes System (DLTS) , ein revisionssicheres Datenbanksystem, eine Cloud, ein Cloud- Service, eine Blockchain in einer Cloud oder eine Peer-to- Peer Datenbank verstanden werden. Auch können beispielsweise unterschiedliche Implementierungen einer Blockchain oder ei nes DLTS verwendet werden, wie z. B. eine Blockchain oder ein DLTS, die mittels eines Directed Acylic Graph (DAG) , eines kryptographischen Puzzles, einem Hashgraph oder eine Kombina tion aus den genannten Implementierungsvarianten [6] [7] . Auch können beispielsweise unterschiedliche Konsensusverfahren (engl, „consensus algorithms") implementiert werden. Dies kann beispielsweise ein Konsensusverfahren mittels eines kryptographischen Puzzles, Gossip about Gossip, Virtual Vo- ting oder eine Kombination der genannten Verfahren sein (z.
B. Gossip about Gossip kombiniert mit Virtual Voting) [6] [7] . Wird beispielsweise eine Blockchain verwendet, so kann diese insbesondere mittels einer Bitcoin-basierten Realisierung o- der einer Ethereum-basierten Realisierung umgesetzt werden [1] [4] [5] .
Unter einem „verteilten Datenbanksystem" kann ein System zur Implementierung einer verteilten Datenbank bzw. deren Infra struktur verstanden werden. Bei einem solchen verteilten Da tenbanksystem kann beispielsweise auch ein verteiltes Daten banksystem verstanden werden, von dem zumindest ein Teil sei ner Knoten, Vorrichtungen und/oder Infrastruktur durch eine Cloud realisiert sein. Beispielsweise können die entsprechen den Komponenten als virtuelle Komponenten in der Cloud reali siert sein (z. B. als virtueller Knoten oder eine virtuelle Maschine) . Dies kann beispielsweise mittels VM-Ware, Amazon Web Services oder Microsoft Azure erfolgen. Aufgrund der ho-
hen Flexibilität der erläuterten Implementierungsvarianten, können insbesondere auch Teilaspekte der genannten Implemen tierungsvarianten miteinander kombiniert werden, indem z. B. ein Hashgraph als Blockchain verwendet wird, wobei die Block- chain selbst z. B. auch blocklos sein kann.
Wird beispielsweise ein Directed Acylic Graph (DAG) verwendet (z. B. IOTA oder Tangle) , sind insbesondere Transaktionen o- der Blöcke oder Knoten des Graphen miteinander über gerichte te Kanten miteinander verbunden. Azyklisch bedeutet dabei insbesondere, dass es keine Schleifen bei einem Durchlaufen des Graphen gibt. Durch die gerichteten Kanten und die Azyk- lizität kann sichergestellt werden, dass die zeitliche Rei henfolge vieler Transaktionen eindeutig feststeht.
Bei der verteilten Datenbank kann es sich beispielsweise um eine öffentliche verteilte Datenbank (z. B. eine öffentliche Blockchain) oder eine geschlossene (oder private) verteilte Datenbank (z. B. eine private Blockchain) handeln.
Handelt es sich beispielsweise um eine öffentliche verteilte Datenbank, bedeutet dies, dass neue Knoten und/oder Geräte ohne Berechtigungsnachweise oder ohne Authentifizierung oder ohne Anmeldeinformationen oder ohne Credentials dem verteil ten Datenbanksystem beitreten können bzw. von diesem akzep tiert werden. Insbesondere können in einem solchen Fall die Betreiber der Knoten und/oder Geräte zunächst anonym bleiben.
Handelt es sich bei der verteilten Datenbank beispielsweise um eine geschlossene verteilte Datenbank, können neue Knoten und/oder Vorrichtungen beispielsweise einen gültigen Berech tigungsnachweis und/oder gültige Authentifizierungsinformati- onen und/oder gültige Credentials und/oder gültige Anmeldein formationen benötigen, um dem verteilten Datenbanksystem bei treten können bzw. von diesem akzeptiert zu werden.
Bei dem verteilten Datenbanksystem kann es sich beispielswei se auch um ein verteiltes Kommunikationssystem zum Datenaus-
tausch handeln. Dies kann beispielsweise ein Netzwerk oder ein Peer-2-Peer Netzwerk sein.
Unter einem „Datenblock", der insbesondere je nach Kontext und Realisierung auch als „Glied" oder „Block" bezeichnet sein kann, kann im Zusammenhang mit der vorliegenden Offenba rung beispielsweise ein Datenblock in einer verteilten Daten bank verstanden werden, der insbesondere als Datenstruktur realisiert ist und vorzugsweise jeweils eine der Transaktio nen oder mehrere der Transaktionen umfasst. Bei einer Imple mentierung kann beispielsweise die verteilte Datenbank (oder das Datenbanksystem) ein DLTS oder eine Blockchain sein und ein Datenblock ein Block der Blockchain oder des DLTS. Ein Datenblock kann beispielsweise Angaben zur Größe (Datengröße in Byte) des Datenblocks, einen Datenblock-Header (engl.
Blockheader) , einen Transaktionszähler und eine oder mehrere Transaktionen umfassen [1]. Der Datenblock-Header kann bei spielsweise eine Version, eine Verkettungsprüfsumme, eine Da tenblockprüfsumme, einen Zeitstempel, einen Proof-of-Work Nachweis und eine Nonce (Einmalwert, Zufallswert oder Zähler, der für den Proof-of-Work Nachweis verwendet wird) umfassen [1] [4] [5] . Bei einem Datenblock kann es sich beispielsweise auch nur um einen bestimmten Speicherbereich oder Adressbe- reich der Gesamtdaten handeln, die in der verteilten Daten bank gespeichert sind. Damit lassen sich beispielsweise blocklose (engl, blockless) verteilte Datenbanken, wie z. B. die IoT Chain (ITC), IOTA, und Byteball, realisieren. Hierbei werden insbesondere die Funktionalitäten der Blöcke einer Blockchain und der Transaktionen miteinander derart kombi niert, dass z. B. die Transaktionen selbst die Sequenz oder Kette von Transaktionen (der verteilten Datenbank) absichern (also insbesondere sicherheitsgeschützt gespeichert werden) . Hierzu können beispielsweise mit einer Verkettungsprüfsumme die Transaktionen selbst miteinander verkettet werden, indem vorzugsweise eine separate Prüfsumme oder die Transaktions prüfsumme einer oder mehrerer Transaktionen als Verkettungs prüfsumme dient, die beim Speichern einer neuen Transaktion in der verteilten Datenbank in der entsprechenden neuen
Transaktion mit gespeichert wird. In einer solchen Ausfüh rungsform kann ein Datenblock beispielsweise auch eine oder mehrere Transaktionen umfassen, wobei im einfachsten Fall beispielsweise ein Datenblock einer Transaktion entspricht.
Unter „Nonce" kann im Zusammenhang mit der vorliegenden Of fenbarung beispielsweise eine kryptographische Nonce verstan den werden (Abkürzung für: „used only once"[2] oder „number used once"[3]). Insbesondere bezeichnet eine Nonce einzelne Zahlen- oder eine Buchstabenkombination, die vorzugsweise ein einziges Mal in dem jeweiligen Kontext (z. B. Transaktion, Datenübertragung) verwendet wird.
Unter „vorhergehende Datenblöcke eines (bestimmten) Datenblo ckes" kann im Zusammenhang mit der Erfindung beispielsweise der Datenblock der verteilten Datenbank verstanden werden, der insbesondere einem (bestimmten) Datenblock direkt vorher geht. Alternativ können unter „vorhergehende Datenblöcke ei nes (bestimmten) Datenblockes" insbesondere auch alle Daten blöcke der verteilten Datenbank verstanden werden, die dem bestimmten Datenblock vorhergehen. Solche vorhergehenden Da tenblöcke können auch als „Vorgängerdatenblock" bezeichnet werden. Hierdurch kann beispielsweise die Verkettungsprüfsum me oder die Transaktionsprüfsumme insbesondere nur über das dem bestimmten Datenblock direkt vorhergehenden Datenblock (bzw. deren Transaktionen) oder über alle dem ersten Daten block vorhergehenden Datenblöcke (bzw. deren Transaktionen) gebildet werden.
Unter einem „Knoten" können im Zusammenhang mit der vorlie genden Offenbarung beispielsweise Geräte (z. B. Feldgeräte, Mobiltelefone) , Rechner, Personal Computer, Smart-Phones , Clients oder Teilnehmergeräte verstanden werden, die Operati onen mit oder in der verteilten Datenbank durchführen
[1] [4] [5] . Solche Knoten können beispielsweise Transaktionen der verteilten Datenbank bzw. deren Datenblöcke ausführen o- der neue Datenblöcke mit neuen Transaktionen in die verteilte Datenbank einfügen bzw. verketten. Insbesondere kann dieses
Validieren und/oder Verketten durch einen vertrauenswürdigen Knoten (z. B. einem Mining Node) oder ausschließlich durch vertrauenswürdige Knoten erfolgen. Bei einem vertrauenswürdi gen Knoten handelt es sich beispielsweise um einen Knoten, der über zusätzliche Sicherheitsmaßnahmen verfügt (z. B.
Firewalls, Zugangsbeschränkungen zum Knoten oder ähnliches) , um eine Manipulation des Knotens zu verhindern. Alternativ oder zusätzlich kann beispielsweise ein vertrauenswürdiger Knoten beim Verketten eines neuen Datenblocks mit der ver teilten Datenbank, eine Knotenprüfsumme (z. B. eine digitale Signatur oder ein Zertifikat) in dem neuen Datenblock spei chern. Damit kann insbesondere ein Nachweis bereitgestellt werden, der angibt, dass der entsprechende Datenblock von ei nem bestimmten Knoten eingefügt wurde bzw. seine Herkunft an gibt. Ein Knoten umfasst typischerweise wenigstens einen Pro zessor, um z. B. seine Funktionen rechnergestützt bzw. compu terimplementiert auszuführen.
Unter einem „Blockchain-Orakel" können im Zusammenhang mit der vorliegenden Offenbarung beispielsweise Knoten, Geräte oder Rechner verstanden werden, die z. B. über ein Sicher heitsmodul verfügen, das beispielsweise mittels Software- Schutzmechanismen (z. B. kryptographische Verfahren), mecha nische Schutzeinrichtungen (z. B. ein abschließbares Gehäuse) oder elektrische Schutzeinrichtungen verfügt (z. B. Tamper- Schutz oder ein Schutzsystem, das die Daten des Sicherheits moduls bei einer unzulässigen Nutzung/Behandlung des Block chain-Orakel löscht umfasst) . Das Sicherheitsmodul kann dabei beispielsweise kryptographische Schlüssel umfassen, die für die Berechnung der Prüfsummen (z. B. Transaktionsprüfsummen oder Knotenprüfsummen) notwendig sind.
Unter einer „Vorrichtung" kann im Zusammenhang mit der vor liegenden Offenbarung beispielsweise ein Computer ( System) , ein Client, ein Smart-Phone, ein Server oder ein ähnliches Gerät verstanden werden. Eine solche Vorrichtung kann außer halb des verteilten Datenbanksystems angeordnet sein bzw. kein Teilnehmer der verteilten Datenbank (z. B. der Block-
chain) sein (also selbst keine Operationen in der verteilten Datenbank durchführen und diese beispielsweise nur abfragen, ohne jedoch Transaktionen durchzuführen, Datenblöcke einzufü gen oder Proof-of-Work-Nachweise zu berechnen) . Alternativ kann eine solche Vorrichtung auch einen Knoten des verteilten Datenbanksystems implementieren. Mit anderen Worten kann ins besondere unter einer Vorrichtung ein Knoten des verteilten Datenbanksystems verstanden werden oder auch eine Vorrichtung außerhalb des verteilten Datenbanksystems. Eine Vorrichtung außerhalb des verteilten Datenbanksystems kann beispielsweise auf die Daten (z. B. Transaktionen) der verteilten Datenbank zugreifen und/oder von Knoten (z. B. mittels Smart-Contracts und/oder Blockchain-Orakel ) angesteuert werden. Wird bei spielsweise eine Ansteuerung bzw. Steuerung einer Vorrichtung außerhalb des verteilten Datenbanksystems durch einen Knoten des verteilten Datenbanksystems realisiert, kann dies z. B. mittels eines Smart-Contracts erfolgen, der insbesondere in einer Transaktion der verteilten Datenbank gespeichert ist.
[1]
Andreas M. Antonopoulos "Mastering Bitcoin: Unlocking Digital Cryptocurrencies", O'Reilly Media, December 2014
[2]
Roger M. Needham, Michael D. Schroeder "Using encryption for authentication in large networks of Computers" ACM: Communi cations of the ACM. Band 21, Nr. 12 Dezember 1978,
[3]
Ross Anderson "Security Engineering. A Guide to Building De- pendable Distributed Systems" Wiley, 2001
[4]
Henning Diedrich „Ethereum: Blockchains, Digital Assets,
Smart Contracts, Decentralized Autonomous Organizations", CreateSpace Independent Publishing Platform, 2016
[5]
"The Ethereum Book Proj ect/Mastering Ethereum"
https://github.com/ethereumbook/ethereumbook, Stand 5.10.2017
[6]
Leemon Baird
"The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byz- antine Fault Tolerance",
Swirlds Tech Report SWIRLDS-TR-2016-01, 31.5.2016 [7]
Leemon Baird
"OverView of Swirlds Hashgraph",
31.5.2016 [8]
Blockchain Oracles
https : //blockchainhub . net/blockchain-oracles/
Stand 14.03.2018
Claims
Patentansprüche
1. Vorrichtung (210, 230, 250, 260, 280) zur Bereitstellung einer verteilten Datenbank (100), wobei die Vorrichtung (210, 230, 250, 260, 280) ausgestaltet ist zum:
- für einen Benutzer der verteilten Datenbank (100), welcher eine erste Identität aufweist, Speichern von Transaktionsda ten (120) einer Transaktion in der verteilten Datenbank
(100) ,
wobei die erste Identität einen öffentlichen kryptographi- schen Schlüssel umfasst, welcher zum Signieren einer Transak tion in der verteilten Datenbank (100) nutzbar ist, und wobei die Transaktion die erste Identität mit einer zweiten Identität verknüpft.
2. Vorrichtung (210, 230, 250, 260, 280) nach Anspruch 1, wobei die Vorrichtung (210, 250) weiterhin ausgestaltet ist zum :
- Speichern von Transaktionsdaten (120) wenigstens einer wei teren Transaktion in der verteilten Datenbank (100), wobei die weitre Transaktion die Verknüpfung der ersten Identität des Benutzers mit der zweiten Identität aufhebt.
3. Vorrichtung (210, 230, 250, 260, 280) nach Anspruch 2, wobei die weitere Transaktion exklusiv durch einen oder meh rere als vertrauenswürdig eingestufte Benutzer der verteilten Datenbank (100) veranlassbar ist.
4. Vorrichtung (250, 260) zur Bereitstellung einer verteilten Datenbank (100), wobei die Vorrichtung (250, 260) ausgestal tet ist zum:
- für einen Benutzer der verteilten Datenbank (100), welcher eine erste Identität aufweist, Prüfen einer zweiten Identi tät; und
- Veranlassen einer Transaktion in der verteilten Datenbank (100), welche die erste Identität mit der zweiten Identität des Benutzers verknüpft,
wobei die erste Identität einen öffentlichen kryptographi- schen Schlüssel umfasst, welcher zum Signieren einer Transak tion in der verteilten Datenbank (100) nutzbar ist.
5. Vorrichtung (250, 260) nach Anspruch 4,
wobei die Vorrichtung (250, 260) ausgestaltet ist zum:
- Veranlassen einer weiteren Transaktion in der verteilten Datenbank (100), wobei die weitere Transaktion die Verknüp fung der ersten Identität mit der zweiten Identität aufhebt.
6. Vorrichtung (250, 260) nach Anspruch 5,
wobei die weitere Transaktion exklusiv durch einen oder meh rere als vertrauenswürdig eingestufte Benutzer der verteilten Datenbank (100) veranlassbar ist.
7. Vorrichtung (210, 230, 250, 260, 280) nach einem der vor hergehenden Ansprüche,
wobei über zweite Identität der Benutzer außerhalb der ver teilten Datenbank (100) identifizierbar ist.
8. Vorrichtung (210, 230, 250, 260, 280) nach einem der vor hergehenden Ansprüche,
wobei die zweite Identität eine oder mehrere Informationen umfasst, welcher den Benutzer als natürliche Person, juristi sche Person, Organisation, Maschine oder physikalisches Ob jekt identifizieren.
9. Vorrichtung (210, 230, 250, 260, 280) nach einem der vor hergehenden Ansprüche,
wobei die Transaktion zur Verknüpfung der ersten Identität und der zweiten Identität exklusiv durch einen oder mehrere als vertrauenswürdig eingestuften Benutzer der verteilten Da tenbank veranlassbar ist.
10. Verfahren, umfassend:
- für einen Benutzer einer verteilten Datenbank (100), wel cher eine erste Identität aufweist, Speichern von Transakti-
onsdaten (120) einer Transaktion in der verteilten Datenbank (100) ,
wobei die erste Identität einen öffentlichen kryptographi- schen Schlüssel umfasst, welcher zum Signieren einer Transak tion in der verteilten Datenbank (100) nutzbar ist, und wobei die Transaktion die erste Identität mit einer zweiten Identität verknüpft.
11. Verfahren nach Anspruch 10, umfassend:
- Speichern von Transaktionsdaten (120) wenigstens einer wei teren Transaktion in der verteilten Datenbank (100), wobei die weitere Transaktion die Verknüpfung der ersten Identität mit der zweiten Identität aufhebt.
12. Verfahren, umfassend:
- für einen Benutzer einer verteilten Datenbank (100), wel cher eine erste Identität aufweist, Prüfen einer zweiten Identität; und
- Veranlassen einer Transaktion in der verteilten Datenbank (100), welche die erste Identität mit der zweiten Identität verknüpft,
wobei die erste Identität einen öffentlichen kryptographi- schen Schlüssel umfasst, welcher zum Signieren einer Transak tion in der verteilten Datenbank (100) nutzbar ist.
13. Verfahren nach Anspruch 12, umfassend:
- Veranlassen einer weiteren Transaktion in der verteilten Datenbank (100), wobei die weitere Transaktion die Verknüp fung der ersten Identität mit der zweiten Identität aufhebt.
14. Computerprogramm, welches Programmcode umfasst der bei Ausführung durch einen oder mehrere Prozessoren (211, 231, 251, 261, 281) einer programmierbaren Vorrichtung (210, 230, 250, 260, 280) bewirkt, dass die Vorrichtung (210, 230, 250, 260, 280) ein Verfahren nach einem der Ansprüche 10 bis 13 ausführt .
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP18199653.9A EP3637345A1 (de) | 2018-10-10 | 2018-10-10 | Verknüpfung von identitäten in einer verteilten datenbank |
PCT/EP2019/076721 WO2020074350A1 (de) | 2018-10-10 | 2019-10-02 | Verknüpfung von identitäten in einer verteilten datenbank |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3830781A1 true EP3830781A1 (de) | 2021-06-09 |
Family
ID=63915171
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP18199653.9A Withdrawn EP3637345A1 (de) | 2018-10-10 | 2018-10-10 | Verknüpfung von identitäten in einer verteilten datenbank |
EP19786503.3A Pending EP3830781A1 (de) | 2018-10-10 | 2019-10-02 | Verknüpfung von identitäten in einer verteilten datenbank |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP18199653.9A Withdrawn EP3637345A1 (de) | 2018-10-10 | 2018-10-10 | Verknüpfung von identitäten in einer verteilten datenbank |
Country Status (4)
Country | Link |
---|---|
US (1) | US20210391991A1 (de) |
EP (2) | EP3637345A1 (de) |
CN (1) | CN112789642A (de) |
WO (1) | WO2020074350A1 (de) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11696766B2 (en) | 2009-09-11 | 2023-07-11 | Tbi Innovations, Llc | Methods and devices to reduce damaging effects of concussive or blast forces on a subject |
US8900169B2 (en) | 2013-03-15 | 2014-12-02 | Tbi Innovations, Llc | Methods and devices to reduce the likelihood of injury from concussive or blast forces |
CN108601598A (zh) | 2015-11-16 | 2018-09-28 | Q30运动科学公司 | 创伤性脑损伤保护装置 |
JP2019513030A (ja) | 2016-03-02 | 2019-05-23 | キューサーティー スポーツ サイエンス エルエルシーQ30 Sports Science,Llc | 被験者に対する震盪性の力または爆風の力の損傷効果を削減するための方法及び装置 |
US11576037B2 (en) * | 2019-10-18 | 2023-02-07 | Huawei Technologies Co., Ltd. | Issuing offline PKI certificates in distributed V2X network |
GB2589636A (en) * | 2019-12-06 | 2021-06-09 | Nchain Holdings Ltd | Identity-based public-key generation protocol |
US11803849B1 (en) * | 2020-07-30 | 2023-10-31 | Mark Lawrence | Method and apparatus for decentralized micro businesses |
DE102020211793A1 (de) | 2020-09-21 | 2022-03-24 | Volkswagen Aktiengesellschaft | Verfahren zum Handhaben von elektronischen, nutzerspezifischen Informationen eines Nutzers eines Fahrzeugs, sowie Computerprogramm und elektronisches Verwaltungssystem |
Family Cites Families (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8738921B2 (en) * | 2006-05-16 | 2014-05-27 | Transactionsecure Llc | System and method for authenticating a person's identity using a trusted entity |
DE102007038763A1 (de) | 2007-08-16 | 2009-02-19 | Siemens Ag | Verfahren und Vorrichtung zur Sicherung eines Programms gegen eine Kontrollflussmanipulation und gegen einen fehlerhaften Programmablauf |
DE102007040343B4 (de) | 2007-08-27 | 2010-12-30 | Siemens Ag | Vorrichtung und Verfahren zum Erzeugen einer Zufallsbitfolge |
DE102008018678B4 (de) | 2008-04-14 | 2011-02-03 | Siemens Aktiengesellschaft | Vorrichtung und Verfahren zum Erzeugen einer Zufallsbitfolge |
DE102008061483A1 (de) | 2008-12-10 | 2010-06-24 | Siemens Aktiengesellschaft | Verfahren und Vorrichtung zum Verarbeiten von Daten |
CN101771537A (zh) * | 2008-12-26 | 2010-07-07 | ***通信集团公司 | 分布式认证***及其认证证书的处理方法、认证方法 |
DE102011007572A1 (de) | 2011-04-18 | 2012-10-18 | Siemens Aktiengesellschaft | Verfahren zur Überwachung eines Tamperschutzes sowie Überwachungssystem für ein Feldgerät mit Tamperschutz |
DE102011087804A1 (de) | 2011-12-06 | 2013-06-06 | Siemens Aktiengesellschaft | Vorrichtung und Verfahren zum Entschlüsseln von Daten |
DE102011088502B3 (de) | 2011-12-14 | 2013-05-08 | Siemens Aktiengesellschaft | Verfahren und Vorrichtung zur Absicherung von Blockchiffren gegen Template-Attacken |
DE102012217743B4 (de) | 2012-09-28 | 2018-10-31 | Siemens Ag | Überprüfung einer Integrität von Eigenschaftsdaten eines Gerätes durch ein Prüfgerät |
DE102012220990B3 (de) | 2012-11-16 | 2014-01-23 | Siemens Aktiengesellschaft | Verfahren und Anordnung zur sicheren Kommunikation zwischen Netzwerkeinrichtungen in einem Kommunikationsnetzwerk |
DE102013200017A1 (de) | 2013-01-02 | 2014-07-03 | Siemens Aktiengesellschaft | RFID-Tag und Verfahren zum Betreiben eines RFID-Tags |
DE102013208152A1 (de) | 2013-05-03 | 2014-11-20 | Siemens Aktiengesellschaft | Vorrichtung und Verfahren zum Erzeugen von Zufallsbits |
DE102013212525A1 (de) | 2013-06-27 | 2014-12-31 | Siemens Aktiengesellschaft | Datenspeichervorrichtung zum geschützten Datenaustausch zwischen verschiedenen Sicherheitszonen |
DE102013222218A1 (de) | 2013-10-31 | 2014-05-22 | Siemens Aktiengesellschaft | Konstruieren einer Schaltung geeignet zur Erzeugung von Zufallsbits und Schaltung zur Erzeugung von Zufallsbits |
DE102013227087A1 (de) | 2013-12-23 | 2015-06-25 | Siemens Aktiengesellschaft | Gesichertes Bereitstellen eines Schlüssels |
DE102014206992A1 (de) | 2014-04-11 | 2015-10-15 | Siemens Aktiengesellschaft | Zufallszahlengenerator und Verfahren zum Erzeugen von Zufallszahlen |
DE102014208210A1 (de) | 2014-04-30 | 2015-11-19 | Siemens Aktiengesellschaft | Ableiten eines gerätespezifischen Wertes |
US20150356523A1 (en) * | 2014-06-07 | 2015-12-10 | ChainID LLC | Decentralized identity verification systems and methods |
DE102014212488B4 (de) | 2014-06-27 | 2016-02-18 | Siemens Aktiengesellschaft | Gesichertes Bereitstellen eines Replika-Pseudo-Zufallsrauschcodes an eine Empfängereinheit |
DE102014212467B3 (de) | 2014-06-27 | 2015-10-15 | Siemens Aktiengesellschaft | Bereitstellen eines gesicherten Replika-Pseudo-Zufallsrauschsignals |
DE102015214267A1 (de) | 2015-07-28 | 2017-02-02 | Siemens Aktiengesellschaft | Verfahren und System zum Erzeugen eines sicheren Kommunikationskanals für Endgeräte |
EP3348019A1 (de) * | 2015-09-11 | 2018-07-18 | Aware, Inc. | Biometrische überprüfung eines blockchain-datenbanktransaktionskontributors |
CN108027608A (zh) | 2015-09-21 | 2018-05-11 | 西门子股份公司 | 针对处理对象的处理步骤的开启 |
BR112018007449B1 (pt) * | 2015-10-17 | 2024-02-20 | Banqu, Inc | Dispositivo de computação, método implementado por computador e dispositivo de memória legível por computador |
JP6516870B2 (ja) | 2016-02-09 | 2019-05-22 | シーメンス アクチエンゲゼルシヤフトSiemens Aktiengesellschaft | プログラム命令を安全に実行する方法及び該方法用プログラム |
KR101799343B1 (ko) * | 2016-05-16 | 2017-11-22 | 주식회사 코인플러그 | 인증 정보의 사용 방법, 파기 방법 및 이를 지원하는 블록체인기반 인증 정보 관리 서버 |
US20170346639A1 (en) * | 2016-05-24 | 2017-11-30 | Business Information Exchange System Corp. | Public Key Infrastructure based on the Public Certificates Ledger |
DE102016219848A1 (de) | 2016-10-12 | 2018-04-12 | Siemens Aktiengesellschaft | Verfahren und Vorrichtung zum Bereitstellen einer gesicherten Kommunikation innerhalb eines echtzeitfähigen Kommunikationsnetzwerkes |
DE102016219926A1 (de) | 2016-10-13 | 2018-04-19 | Siemens Aktiengesellschaft | Verfahren, Sender und Empfänger zum Authentisieren und zum Integritätsschutz von Nachrichteninhalten |
CN106850654B (zh) * | 2017-02-23 | 2020-08-21 | 布比(北京)网络技术有限公司 | 一种分布式信息的授权访问方法及*** |
US10848322B2 (en) * | 2017-03-24 | 2020-11-24 | Cable Television Laboratories, Inc | System and method for distributed PKI root |
US11032252B2 (en) * | 2018-01-03 | 2021-06-08 | Syccure, Inc. | Distributed authentication between network nodes |
CN108234515B (zh) * | 2018-01-25 | 2020-07-24 | 中国科学院合肥物质科学研究院 | 一种基于智能合约的自认证数字身份管理***及其方法 |
-
2018
- 2018-10-10 EP EP18199653.9A patent/EP3637345A1/de not_active Withdrawn
-
2019
- 2019-10-02 US US17/284,461 patent/US20210391991A1/en active Pending
- 2019-10-02 EP EP19786503.3A patent/EP3830781A1/de active Pending
- 2019-10-02 WO PCT/EP2019/076721 patent/WO2020074350A1/de unknown
- 2019-10-02 CN CN201980066713.9A patent/CN112789642A/zh active Pending
Also Published As
Publication number | Publication date |
---|---|
EP3637345A1 (de) | 2020-04-15 |
US20210391991A1 (en) | 2021-12-16 |
CN112789642A (zh) | 2021-05-11 |
WO2020074350A1 (de) | 2020-04-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3830781A1 (de) | Verknüpfung von identitäten in einer verteilten datenbank | |
EP3108610B1 (de) | Verfarhen und system zum erstellen und zur gültigkeitsprüfung von gerätezertifikaten | |
DE102008042262A1 (de) | Verfahren zur Speicherung von Daten, Computerprogrammprodukt, ID-Token und Computersystem | |
WO2003013167A1 (de) | Vorrichtung zur digitalen signatur eines elektronischen dokuments | |
WO2020011491A1 (de) | Verfahren, vorrichtungen und system zum datenaustausch zwischen einem verteilten datenbanksystem und geräten | |
WO2019063509A1 (de) | Verfahren und verteiltes datenbanksystem zum rechnergestützten ausführen eines programmcodes | |
WO2019229031A1 (de) | Verfahren und system zum steuern einer freigabe einer ressource | |
EP4315117A1 (de) | Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument | |
WO2019141392A1 (de) | Verfahren und system zum steuern und/oder überwachen von geräten | |
EP3629516B1 (de) | Dezentralisierte identitätsmanagement-lösung | |
EP4254234A1 (de) | Ausstellen eines digitalen credentials für eine entität | |
DE102018115348B4 (de) | Fälschungssicherung und Abgabekontrolle von Verbrauchsgütern | |
EP3797491A1 (de) | Steuern eines datennetzes hinsichtlich eines einsatzes einer verteilten datenbank | |
EP3617977A1 (de) | Einrichtung und verfahren zum ermitteln einer konsensversion eines transaktionsbuchs und einrichtung und verfahren zum überwachen eines verteilten datenbanksystems | |
EP3618348B1 (de) | Verfahren zum betreiben eines verteilten datenbanksystems, verteiltes datenbanksystem und industrieautomatisierungssystem | |
DE102021004548A1 (de) | Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems | |
EP3877935A1 (de) | Verfahren zum betreiben eines verteilten datenbanksystems, verteiltes datenbanksystem und industrieautomatisierungssystem | |
EP3617976A1 (de) | Verfahren zum betreiben eines verteilten datenbanksystems, verteiltes datenbanksystem und industrieautomatisierungssystem | |
WO2020043430A1 (de) | Einrichtung und verfahren zum bereitstellen einer orakel-transaktion in einem verteilten datenbanksystem | |
EP4092958B1 (de) | Ausstellen eines digitalen verifizierbaren credentials | |
EP3817315A1 (de) | Prüfvorrichtung, vorrichtung und verfahren zum validieren von transaktionen | |
WO2023131518A1 (de) | Verifikationsverfahren und verifikations-computersystem mit einer nft-erstellungsvorrichtung und einer verifikationsvorrichtung | |
EP3829103A1 (de) | Vorrichtung und verfahren zum bilden von datenblöcken | |
EP3786831A1 (de) | Verfahren und vorrichtung zum prüfen von einem datensatz | |
EP3828798A1 (de) | Vorrichtung und verfahren zum bilden von datenblöcken |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20210305 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) |