EP3830781A1

EP3830781A1 - Linking identities in a distributed database

Info

Publication number: EP3830781A1
Application number: EP19786503.3A
Authority: EP
Inventors: Hans Aschauer; Andreas Bogner; Markus Dichtl; Ingo Wenda
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2018-10-10
Filing date: 2019-10-02
Publication date: 2021-06-09
Also published as: CN112789642A; WO2020074350A1; EP3637345A1; US20210391991A1

Abstract

For a user of a distributed database (100) which has a first identity, transaction data (120) of a transaction is stored in the distributed database (100). The transaction links the first identity to a second identity.

Description

description

Linking identities in a distributed database

The present disclosure relates to methods, devices and computer programs for providing or operating a distributed database.

From the prior art are document US 8,531,247 B2, document US 8,892,616 B2, document US 8,300,811 B2, document US 9,147,088 B2, document US 9584311 B2, document EP 2976707 B1, document EP 2 605 445 B1, document EP 2 870 565 A1, document EP 2 891 102 A1, document WO 2017137256 A1, document EP 2870565 B1, EP

2891266 B1, the document EP 2961091 A1, the document EP

2961093 A1, document EP 3028140 B1, document EP

2930610 B1, the document EP 2940620 B1, the document EP

2899714 A1, document EP 2981926 A0, document EP

3125492 B1, document EP17195125, document EP17211075, document EP18178316, document EP18156084, document EP18151345, document EP18167702, the document

EP18153594, document EP18162050, document EP18178498, document EP18152117, document EP18150133, document EP18169145, document EP17210647, the document

EP18150146, document EP18167486, document EP18168670, document EP18162049, document EP17203819, document EP18157168, document EP18169421, the document

EP17210253, document EP17205224, document EP18169269, document EP18169254, document EP17210288, document EP18153025, document EP17200614, the document

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

2018068965 Al and document US 8 843 761 B2. A distributed database, sometimes also referred to as “distributed ledger”, typically uses cryptographic methods and consensus methods in order to protect information stored in the distributed database against manipulation. Such 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. In addition to applications for decentralized payment systems (e.g. Bitcoin), new application options are being developed in the financial industry, for example. In particular, 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".

To secure transactions in the distributed database, it is known to bind the identity of a user to a public cryptographic key. Using Sig natur with a private cryptographic key belonging to this public key, which is normally only accessible to the user, the user can prove that a transaction in the distributed database was actually initiated by him.

Typically, 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. However, in some use cases, it may be necessary to know the identity associated with a transaction. 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. Depending on the application scenario, it may be necessary to ensure that a public key is assigned to a specific natural or legal person. This can, for example, make it possible for claims to be enforced by judicial means against this natural or legal person.

To authenticate a cryptographic public key, e.g. a public part of an asymmetric key pair, it is known, a so-called

Use public key infrastructure (PKI) in which the identity linked to the cryptographic public key, e.g. a natural or legal person, confirmed by a trustworthy body. This confirmation of an identity can, for. B. gene by a certificate that is digitally signed by the trustworthy entity. This requires that the trustworthy entity ensures that the linked identity is authentic, e.g. based on an ID document. However, 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. In connection with a distributed database, 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.

There is therefore a need for technologies which enable efficient use of a distributed database with authenticated users. One of the present disclosures The underlying task is to meet this need.

According to the invention, 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.

According to one embodiment, a first device for providing a distributed database is disclosed. The device can, for example, implement a node of a distributed database system. The first device is designed for:

for a user of the distributed database who has a first identity, storing transaction data of a transaction in the distributed database, the transaction linking the first identity to a second identity.

In this way it can be achieved that 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. When such a transaction is initiated, 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.

In one embodiment of the first device, 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.

According to one embodiment, the first device is further configured to:

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

Motor vehicle continues to be arranged for transactions that are at the expense of its former owner. The restoration of links between the two identities may also be necessary for security reasons, for example if

Key material was compromised.

In one embodiment of the first device, 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.

In one embodiment of the first device, 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. The user can thus be reliably identified via the second identity. 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.

According to a further exemplary embodiment, a second device for providing a distributed database is disclosed. The device 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:

for a user of the distributed database who has a first identity, checking a second identity; and

- Initiate a transaction in the distributed database that links the first identity with the second identity.

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). The second device can interact with the trusted entity via the distributed database or can be implemented as part of the trusted entity. In one embodiment of the second device, 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.

In one exemplary embodiment of the second device, 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. Furthermore, such information can also include other labeling information, e.g. include a product number or address data. The user can thus be reliably identified via the second identity. 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.

In one embodiment of the second device, 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.

According to one embodiment, the second device is further configured to:

Initiating a further transaction in the distributed database, 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.

According to a further exemplary embodiment, a first method is provided. The first procedure includes:

- For a user of a distributed database who has a first identity, storing transaction data of a transaction in the distributed database, the transaction linking the first identity to a second identity.

The first identity of the user comprises a public cryptographic key, which can be used to sign a transaction in the distributed database. When such a transaction is initiated, 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.

In one embodiment of the first method, 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.

In one embodiment of the first method, the user can be identified via the second identity outside of the distributed database.

In one embodiment of the first method, 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. Furthermore, such information can also include other labeling information, for example a product number, or address data.

According to one embodiment, the first method further comprises:

Storing further transaction data of a further transaction in the distributed database, the further transaction breaking the link between the first identity and the second identity.

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.

According to a further exemplary embodiment, a second method is provided. The second procedure includes:

for a user of a distributed database who has a first identity, checking a second identity; and

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). In one embodiment of the second method, the user can be identified via the second identity outside the distributed database.

In one exemplary embodiment of the second method, 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. Furthermore, such information can also contain other labeling information, e.g. include a product number, or address information.

In one embodiment of the second method, the transaction for linking the identities can be initiated exclusively by one or more users of the distributed database classified as trustworthy.

According to one embodiment, the second method further comprises:

Initiating a further transaction in the distributed database, the further transaction breaking the link between the first identity and the second identity.

According to a further exemplary embodiment, 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.

In the exemplary embodiments mentioned, the user can be an entity about which information is stored in the distributed database. Examples of such an entity 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.

In the exemplary embodiments mentioned, 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.

With the distributed database, 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. In the following, exemplary embodiments of the present invention are explained in more detail with reference to the attached figures.

1 schematically illustrates a distributed database according to an embodiment.

2 schematically shows a distributed database system according to an exemplary embodiment.

3 shows a flowchart to illustrate a method according to an exemplary embodiment.

4 shows a flowchart to illustrate a further method according to an exemplary embodiment.

In the following description of exemplary embodiments, it is understood that the accompanying drawings are to be regarded as schematic and that the drawings and the elements illustrated are not necessarily to scale. Rather, the drawings are intended to illustrate the functions and interaction of elements and components. It is also understood here that any connection or coupling of the functional blocks, devices, components or other physical or functional elements shown is also possible through an indirect connection or coupling, e.g. could be implemented via one or more intermediate elements. A connection between components can be implemented, for example, via a wired and / or wireless data connection. Functional blocks can be implemented by hardware, firmware and / or software.

1 schematically illustrates a distributed database 100. In the following it is assumed that the distributed database 100 is implemented as a blockchain. However, it should be understood that other implementations of the distributed database 100 are also possible. 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. For example, 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. In this way, for example, 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. In the example shown, the distributed database system comprises a plurality of nodes 210, 230, 250, 260, 280 which transactions in the distributed database 100 can execute. As illustrated, 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. By means of the at least one processor 211 , 231, 251, 261, 281, program code can be executed which is stored in the memory 212, 232, 252, 262, 282. In particular, 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.

In the distributed database system 200, the node 250 is assigned to a user who is classified as trustworthy.

As explained in more detail below, certain types of transactions can thereby be initiated via the node 250 which are not available to other users of the distributed database 100. In particular, these serve to link the first identity of a user of the distributed database 100 to a second identity. In the example of FIG. 2, it is assumed that for a user assigned to node 230, the first identity is to be linked to a second identity. For this purpose, 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. In other words, 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. In the example shown, 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. By storing the link in the distributed database 100 and by the corresponding transaction only by the CA node Manipulations of the linkage can be reliably avoided, and it can also be provided that transactions are initiated by the CA node 250 in order to remove an already existing linkage between the first identity and the second identity of a user include that a certificate already stored in the distributed database 100 is marked as revoked or deleted.

In the example shown, 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. In particular, 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"

(RA) of a conventional PKI system. The node 260 can therefore also be referred to as an RA node. In the example shown, the RA node 260 confirms the authenticity or legality of the second identity through a transaction in the distributed database 100. As already mentioned, 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.

As shown, 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. For example, 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 . For example, 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.

Although only one 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.

In an exemplary implementation, a smart contract program code for implementing the functionalities explained above can have the following functions:

- a function "requestCertificate",

- a function "approveEntity",

- a function "certifyEntity", - a function "revokeCertificate",

- a function "deleteCertificate" and

- a "verifyEntity" function.

These functions can, for example, each be implemented by one or more smart contract processes.

The basic data structure can be defined in a certificate as shown in Table 1. struct Certificate {

address blockchainld;

string commonName;

uint256 startDate;

uint256 endDate;

State state;

}

Table 1

Here, "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, and "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".

In the smart contract language "Solidity", a mapping called "certificates" can be used as the data structure for collecting the certificates. In solidity, 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. However, it goes without saying that comparable data structures are also are available and could be used in other languages. In the 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. In the languages Javascript and Wolfram Language is a comparable data structure called "associative array". In the "certificates" mapping, 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.

First, 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. In the example shown, the certificate is valid for one year fixed from creation.

The "approveEntity" function may only be used by the RA. In practical applications, 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.

If 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 ".

Furthermore, functions are provided in the example shown in order to revoke or delete certificates. 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.

At block 310, 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,

250, 260, 280 assigned users or another user of the distributed database. 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. In particular, 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.

At block 320, 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 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.

At block 330, 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. At block 410, 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. In particular, 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. Alternatively, however, 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

Key included.

At block 420, 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. Furthermore, such information can also include other labeling information, e.g. include a product number or address data.

At block 430, 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.

In the concepts shown, 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. However, it is possible to use the RA of an existing PKI system, which can simplify the implementation or integration into existing systems. As a result, it can be achieved for

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.

It is understood that numerous modifications are possible in the preceding examples. In addition to an implementation of the 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.

Unless otherwise stated in the preceding description, the terms “carry out”, “calculate”, “computer-assisted”, “calculate”, “determine”, “generate”, “configure”, “reconstruct”, “ control "," to assign "and the like preferably to actions and / or processes and / or processing steps that change and / or generate data and / or convert the data into other data, the data in particular being represented or available as physical quantities can, for example as electrical pulses. In particular, 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.

Central Processing Unit, CPU), a microprocessor or a microcontroller, for example an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc. 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. For example, 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.

Under a “storage unit” or “storage module” or the like, in connection with the present disclosure, for example, a volatile storage device in the form of memory beitsspeicher (RAM) or permanent storage such as a hard drive or a data carrier can be understood.

“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. For example, 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

and / or information is transmitted and / or sent and / or called up and / or received.

In the context of the present disclosure, “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.

In the context of the present disclosure, “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 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. Using the checksums, for example, 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).

In the context of the present disclosure, 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 In addition or as an alternative, 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. using the trans action checksums), in particular the other checksums are leaves in the Merkle tree or Patricia tree. 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. In particular, 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. As a result, 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.

In the context of the present disclosure, “transaction checksum” can be understood to mean a checksum which is formed in particular via a transaction of a data block. In addition, for example, 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.

In the context of the present disclosure, 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)

[1] . For this purpose, 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 (that is, an existing data block of the distributed database) can be used to link a new data block with an (existing) data block of the distributed database. However, 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. However, 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. For example, 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). In this way, for example, 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. In this context, 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. Instead of the data, e.g. B. user data such as measurement data or Da

ten / ownership of assets, for example, 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.

In addition, 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). For example, it is also conceivable that this data is made available via another communication channel (eg via another database and / or a cryptographically secured communication channel).

In addition to the checksum, for example, 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.

In the context of the present disclosure, “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 usammenwirken synergistically _Z, for example to improve security or cryptographic security for transaction data. In other words, "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".

In the context of the present disclosure, “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].

In the context of the present disclosure, “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

[1] [4] [5]. For this purpose, the corresponding transactions are stored in a new data block, for example. In particular, this validation and / or concatenation can be carried out by a trustworthy node (e.g. a mining node, a blockchain oracle or a block grove platform). In particular, 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. In particular, a trustworthy node and / or a node can each be a node. Store checksum (e.g. a digital signature) in a data block (e.g. in the one you validated and generated Data block, which is then chained), in particular to make it possible to identify the creator of the data block and / or to enable the node to be identified. 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.

In the context of the present disclosure, “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. In the context of the invention, “transaction” or “transactions” can also be understood to mean, for example, the data of a transaction of a data block of a blockchain. In particular, a transaction can include a program code that, for example, implements a smart contract. For example, in connection with the invention, a transaction can also be understood to mean a tax transaction and / or a confirmation transaction. Alternatively, a transaction can be, for example, a data structure that stores data (e.g. control commands and / or contract data

and / or other data such as video data, user data, measurement data etc. ).

“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). In particular, when storing transactions in data blocks, these checksums can be validated, for example, as is explained, for example, under “inserting into the distributed database”.

In the context of the present disclosure, 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] Here, for example, a virtual machine is implemented through the infrastructure of the distributed database system.

In the context of the present disclosure, 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. For example, the Smart

Contract are executed in the same way as is explained in the definition of "program code", in particular in connection with the invention.

In connection with the present disclosure, “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.

In the context of the present disclosure, 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]. 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 (e.g.

B. Gossip about Gossip combined with virtual voting) [6] [7]. If, for example, a blockchain is used, this can be implemented in particular by means of a Bitcoin-based implementation or an Ethereum-based implementation [1] [4] [5].

A “distributed database system” can be understood to mean a system for implementing a distributed database or its infrastructure. With such a distributed database system, for example, 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. For example, 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. Because of the high hen flexibility of the implementation variants explained, in particular also partial aspects of the implementation variants mentioned can be combined with one another, for example by For example, a hash graph is used as a blockchain. B. can also be blockless.

If, for example, a Directed Acylic Graph (DAG) is used (e.g. IOTA or Tangle), in particular 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).

If it is, for example, a publicly distributed database, this means that new nodes and / or devices without credentials or without authentication or without credentials or without credentials can join or be accepted by the distributed database system. In such a case, in particular, the operators of the nodes and / or devices can initially remain anonymous.

If the distributed database is, for example, a closed, distributed database, 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.

A "data block", which can also be referred to as a "link" or "block", depending on the context and implementation, can be understood in connection with the present disclosure, for example, to be a data block in a distributed database, which in particular is implemented as a data structure and preferably each comprises one of the transactions or more of the transactions. In an implementation, for example, 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]. For example, 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. In particular, the functionalities of the blocks of a blockchain and the transactions are combined with each other in such a way that, for. B. the transactions themselves secure the sequence or chain of transactions (the distributed database) (in particular, they are stored in a security-protected manner). For this purpose, for example, the transactions themselves can be linked to one another with a chaining checksum, in that a separate checksum or the transaction checksum of one or more transactions serves as a chaining checksum, which is saved in the corresponding new one when a new transaction is stored in the distributed database Transaction is saved with. In such an embodiment, a data block can also comprise one or more transactions, for example, in the simplest case a data block corresponding to a transaction.

In the context of the present disclosure, “nonce” can be understood to mean, for example, a cryptographic nonce (abbreviation for: “used only once” [2] or “number used once” [3]). In particular, a nonce denotes individual numbers or a letter combination that is preferably used once in the respective context (e.g. transaction, data transfer).

In the context of the invention, “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. Alternatively, “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”. In this way, for example, 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

[1] [4] [5]. 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. In particular, 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.

Firewalls, access restrictions to the node or the like) to prevent manipulation of the node. Alternatively or additionally, for example, when a new data block is concatenated with the distributed database, 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.

In the context of the present disclosure, 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).

In the context of the present disclosure, a “device” can be understood to mean, for example, a computer (system), a client, a smart phone, a server or a similar device. Such 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). Alternatively, such a device can also implement a node of the distributed database system. In other words, 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.

[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: Communications of the ACM. Volume 21, No. 12 December 1978,

[3]

Ross Anderson "Security Engineering. A Guide to Building Dependable 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, as of October 5, 2017

[6]

Leemon Baird

"The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance",

Swirlds Tech Report SWIRLDS-TR-2016-01, May 31, 2016 [7]

Leemon Baird

"Over _V iew of Swirlds Hashgraph"

5/31/2016 [8]

Blockchain Oracle

https: // blockchainhub. net / blockchain-oracles /

As of March 14, 2018

Claims

1. Device (210, 230, 250, 260, 280) for providing a distributed database (100), the device (210, 230, 250, 260, 280) being designed for:

- For a user of the distributed database (100) who has a first identity, storing transaction data (120) of a transaction in the distributed database

(100),

the first identity comprising a public cryptographic key which can be used to sign a transaction in the distributed database (100), and the transaction linking the first identity to a second identity.

2. The device (210, 230, 250, 260, 280) according to claim 1, wherein the device (210, 250) is further configured to:

- Saving transaction data (120) of at least one further transaction in the distributed database (100), the further transaction breaking the link between the first identity of the user and the second identity.

3. Device (210, 230, 250, 260, 280) according to claim 2, wherein the further transaction can be initiated exclusively by one or more trusted users of the distributed database (100).

4. Device (250, 260) for providing a distributed database (100), the device (250, 260) being designed for:

- for a user of the distributed database (100) who has a first identity, checking a second identity; and

- initiating a transaction in the distributed database (100) which links the first identity with the second identity of the user, the first identity comprising a public cryptographic key which can be used to sign a transaction in the distributed database (100).

5. The device (250, 260) according to claim 4,

the device (250, 260) being designed for:

- initiating a further transaction in the distributed database (100), the further transaction breaking the link between the first identity and the second identity.

6. The device (250, 260) according to claim 5,

wherein the further transaction can be initiated exclusively by one or more users of the distributed database (100) who are classified as trustworthy.

7. The device (210, 230, 250, 260, 280) according to one of the preceding claims,

the user being identifiable outside the distributed database (100) via the second identity.

8. The device (210, 230, 250, 260, 280) according to one of the preceding claims,

wherein the second identity comprises one or more information which identify the user as a natural person, legal entity, organization, machine or physical object.

9. Device (210, 230, 250, 260, 280) according to one of the preceding claims,

wherein the transaction for linking the first identity and the second identity can be initiated exclusively by one or more users of the distributed database classified as trustworthy.

10. A method comprising:

- For a user of a distributed database (100) who has a first identity, storing transactions ons data (120) of a transaction in the distributed database (100),

11. The method of claim 10, comprising:

- Saving transaction data (120) at least one further transaction in the distributed database (100), the further transaction breaking the link between the first identity and the second identity.

12. A method comprising:

- for a user of a distributed database (100) who has a first identity, checking a second identity; and

- initiating a transaction in the distributed database (100) which links the first identity with the second identity,

the first identity comprising a public cryptographic key which can be used to sign a transaction in the distributed database (100).

13. The method of claim 12, comprising:

14. Computer program, which comprises program code which, when executed by one or more processors (211, 231, 251, 261, 281) of a programmable device (210, 230, 250, 260, 280), causes the device (210, 230, 250, 260, 280) executes a method according to one of claims 10 to 13.