EP3830781A1 - Association d'identités dans une base de données répartie - Google Patents

Association d'identités dans une base de données répartie

Info

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
Application number
EP19786503.3A
Other languages
German (de)
English (en)
Inventor
Hans Aschauer
Andreas Bogner
Markus Dichtl
Ingo Wenda
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP3830781A1 publication Critical patent/EP3830781A1/fr
Pending legal-status Critical Current

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)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

Des données de transaction (120) relatives à une transaction sont mémorisées dans une base de données répartie (100) pour un utilisateur de la base de données répartie (100) possédant une première identité. La transaction associe la première identité à une deuxième identité.
EP19786503.3A 2018-10-10 2019-10-02 Association d'identités dans une base de données répartie Pending EP3830781A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP18199653.9A EP3637345A1 (fr) 2018-10-10 2018-10-10 Mise en relation d'identités dans une base de données distribuée
PCT/EP2019/076721 WO2020074350A1 (fr) 2018-10-10 2019-10-02 Association d'identités dans une base de données répartie

Publications (1)

Publication Number Publication Date
EP3830781A1 true EP3830781A1 (fr) 2021-06-09

Family

ID=63915171

Family Applications (2)

Application Number Title Priority Date Filing Date
EP18199653.9A Withdrawn EP3637345A1 (fr) 2018-10-10 2018-10-10 Mise en relation d'identités dans une base de données distribuée
EP19786503.3A Pending EP3830781A1 (fr) 2018-10-10 2019-10-02 Association d'identités dans une base de données répartie

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP18199653.9A Withdrawn EP3637345A1 (fr) 2018-10-10 2018-10-10 Mise en relation d'identités dans une base de données distribuée

Country Status (4)

Country Link
US (1) US20210391991A1 (fr)
EP (2) EP3637345A1 (fr)
CN (1) CN112789642A (fr)
WO (1) WO2020074350A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
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
MX2018006086A (es) 2015-11-16 2018-08-24 Q30 Sports Science Llc Dispositivos de proteccion de lesiones cerebrales traumaticas.
BR112018067355B1 (pt) 2016-03-02 2023-04-11 Q30 Sports Science, Llc Sistema para reduzir os efeitos danificantes de forças concussivas ou de choque sobre um sujeito
US11576037B2 (en) * 2019-10-18 2023-02-07 Huawei Technologies Co., Ltd. Issuing offline PKI certificates in distributed V2X network
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)

* Cited by examiner, † Cited by third party
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
DE102014212467B3 (de) 2014-06-27 2015-10-15 Siemens Aktiengesellschaft Bereitstellen eines gesicherten Replika-Pseudo-Zufallsrauschsignals
DE102014212488B4 (de) 2014-06-27 2016-02-18 Siemens Aktiengesellschaft Gesichertes Bereitstellen eines Replika-Pseudo-Zufallsrauschcodes an eine Empfängereinheit
DE102015214267A1 (de) 2015-07-28 2017-02-02 Siemens Aktiengesellschaft Verfahren und System zum Erzeugen eines sicheren Kommunikationskanals für Endgeräte
WO2017044554A1 (fr) * 2015-09-11 2017-03-16 Aware, Inc. Vérification biométrique d'un contributeur de transactions par une base de données de type chaîne de blocs
CN113589775A (zh) 2015-09-21 2021-11-02 西门子股份公司 针对处理对象的处理步骤的开启
WO2017066002A1 (fr) * 2015-10-17 2017-04-20 Banqu, Inc. Plateforme d'identité et de transaction basée sur une chaîne de blocs
HUE043151T2 (hu) 2016-02-09 2019-08-28 Siemens Ag Eljárás és végrehajtási környezet program-utasítások biztonságos végrehajtására
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 中国科学院合肥物质科学研究院 一种基于智能合约的自认证数字身份管理系统及其方法

Also Published As

Publication number Publication date
EP3637345A1 (fr) 2020-04-15
CN112789642A (zh) 2021-05-11
US20210391991A1 (en) 2021-12-16
WO2020074350A1 (fr) 2020-04-16

Similar Documents

Publication Publication Date Title
WO2020074350A1 (fr) Association d'identités dans une base de données répartie
EP3108610B1 (fr) Procédé et système d'établissement et vérification de validité de certificats d'appareil
WO2003013167A1 (fr) Dispositif de signature numerique d'un document electronique
WO2019063509A1 (fr) Procédé et système de base de données distribuée pour l'exécution informatique d'un code de programme
WO2020011491A1 (fr) Procédés, dispositifs et système permettant l'échange de données entre un système de base de données réparties et des appareils
WO2019229031A1 (fr) Procédé et système de commande d'une libération d'une ressource
EP3910875A1 (fr) Concept d'échange des informations clés cryptographiques
EP4254234A1 (fr) Délivrance d'un credial numérique pour une entité
DE102018115348B4 (de) Fälschungssicherung und Abgabekontrolle von Verbrauchsgütern
EP3797491A1 (fr) Commande d'un réseau de données en vue de l'utilisation d'une base de données distribuée
WO2019141392A1 (fr) Procédé et système de commande et/ou de surveillance d'appareils
EP3617977A1 (fr) Dispositif et procédé pour determiner un consensus sur la version de journal des transactions et dispositif et procédé pour la surveillance d'un système distribué de base de données
EP3618348B1 (fr) Procédé de fonctionnement d'un système de banques de données distribuée, système de banques de données distribuée et système d'automatisation industrielle
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
WO2020126236A1 (fr) Procédé pour faire fonctionner un système de base de données distribué, système de base de données distribué et système d'automatisation industrielle
EP3617976A1 (fr) Procédé de fonctionnement d'un système de base de données distribuée, système de base de données distribuée et système d'automatisation industrielle
WO2020043430A1 (fr) Dispositif et procédé de fourniture d'une transaction oracle dans un système de base de données réparties
EP3817315A1 (fr) Dispositif de vérification, dispositif et procédé de validation de transactions
WO2023131518A1 (fr) Procédé de vérification et système informatique de vérification comprenant un dispositif de génération de nft et un dispositif de vérification
EP3829103A1 (fr) Dispositif et procédé de formation de blocs de données
EP3828798A1 (fr) Dispositif et procédé de formation de blocs de données
WO2020193044A1 (fr) Procédé et système de commande pour la commande d'une exécution de transactions
EP3787251A1 (fr) Procédé, dispositif de communication et application réseau destinés à la transmission protégée d'un ensemble de données
DE102022002518A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber
DE102021005040A1 (de) Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit

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)