WO2022200035A1 - Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument - Google Patents

Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument Download PDF

Info

Publication number
WO2022200035A1
WO2022200035A1 PCT/EP2022/055884 EP2022055884W WO2022200035A1 WO 2022200035 A1 WO2022200035 A1 WO 2022200035A1 EP 2022055884 W EP2022055884 W EP 2022055884W WO 2022200035 A1 WO2022200035 A1 WO 2022200035A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
proof
smart contract
certificate
document
Prior art date
Application number
PCT/EP2022/055884
Other languages
English (en)
French (fr)
Inventor
Mike Bergmann
Original Assignee
Muehlbauer GmbH & Co. KG
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 Muehlbauer GmbH & Co. KG filed Critical Muehlbauer GmbH & Co. KG
Priority to EP22713881.5A priority Critical patent/EP4315117A1/de
Priority to CN202280031405.4A priority patent/CN117280346A/zh
Publication of WO2022200035A1 publication Critical patent/WO2022200035A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • 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/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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • age-restricted goods e.g. luxury goods
  • the seller can obtain much more information about the buyer (first and last name, day, month, year of birth, place of residence ; nationality, etc.) than is required for concrete proof (buyer is of legal age).
  • Proof of creditworthiness for example from a buyer for the conclusion of a purchase agreement for an apartment, or proof of income from a tenant for the conclusion of a rental agreement, currently requires a letter from a bank or an employer. In addition to the currently required scope of creditworthiness, various other information can be obtained from such a letter.
  • a mobile ID solution eg MB TECURE ID (https://www.muehlbauer.de/solutions/id-card- solution), processes digital representations of officially issued and certified documents, such as proof of identity, driver's licenses, etc. These documents often include a photo of the Owner, name, address, nationality, gender, date of birth, driver's license classes, date of issue and validity, and more.
  • a mobile ID is generated from the details of the respective document, which is stored and kept on a traveller's mobile device. This mobile ID replaces a large number of inhomogeneous travel documents; it allows for a convenient, contact-free procedure that conforms to data protection regulations and reliably identifies the traveler.
  • a user presents proof of his identity, which is to be checked by the system.
  • Authentication represents the actual verification of the identity claimed by the user.
  • Authentication is carried out by a trustworthy authority. This trustworthy authority verifies or falsifies the user's identity based on the characteristics contained in the proof.
  • After successfully completed (verified) authentication the user is granted the rights he has requested during authorization.
  • a traveler can actively authenticate themselves at the train station with their passport and ticket. The passenger is - passively - authenticated by the station/train staff on the basis of the documents presented by him. The passenger is thus authorized to travel with his ticket.
  • the authority/employer issuing the document can be contacted for such scenarios and asked to issue a dedicated certificate with a dedicated signature for this document.
  • Self-signed certificates are another option. However, these certificates only offer a low level of security, since the authenticity of the content of the certificate has not been proven.
  • Public Key Infrastructure PKI describes a system that is able to generate, distribute and check digital certificates. These certificates serve as a digital identity for people.
  • An asymmetric cryptosystem can sign and encrypt messages to be sent electronically. A signed message in this form actually comes from the specified sender.
  • the public key (public key) of the sender which can be sent by e-mail, for example, is required.
  • the key to be sent can itself be signed with a trustworthy key.
  • a hierarchy of trustworthy institutions is to be set up, whereby the authenticity of the keys of the highest institution in this hierarchy is to be accepted.
  • Digital Certificates are digitally signed electronic data to prove the authenticity of objects.
  • a certification authority - Certificate Authority, CA - is an entity that provides the certificate and takes on the signature of certificate applications.
  • a PKI offers a hierarchical validity model. If a certification authority is trusted, all certificates signed by it are also trusted. Since a CA can have subordinate CAs, all subordinate CAs are also trusted.
  • Personal data should be disclosed while maintaining or only slightly weakening the completeness and correctness (intactness) of the data, the authenticity of the person or IT component or application involved, protection against unauthorized disclosure of the data, and/or the anonymity of the issuer can be issued to a third party.
  • the release of metadata in connection with the data release to the third party should also be avoided.
  • a method is specified as an embodiment of a solution, which is implemented at least partially as logic (in hardware and/or software) in a user's portable device.
  • the part of the logic implemented in the portable device is set up to communicate with other parts of the logic implemented in remote portable or stationary devices/in cloud computing via a network/data connection.
  • the portable device is a mobile device (smartphone) that is set up to run what is known as an app, ie application software for the portable device with a mobile operating system designed for this.
  • an app ie application software for the portable device with a mobile operating system designed for this.
  • the part of the process to be triggered/executed by the user is to authenticate and verify the user, his data or parts thereof in a user-friendly, privacy-preserving, trustworthy and situation-appropriate manner and to present them to a third party.
  • the procedural steps required for this are carried out decentrally.
  • cloud computing for decentralized execution via a network offers simple and rapid access to a shared pool of computer resources (networks, servers, storage systems, applications and services) that can be configured as required, whenever and wherever required.
  • a stationary computer resource can also be provided for the user, which provides the user with the functionality required for this solution.
  • the following resources shall be used for the logic steps to be performed inside and/or outside the portable device app.
  • a so-called distributed ledger distributed digital analogue of an accounting journal
  • data records are distributed in a peer-to-peer network (P2P network).
  • P2P network peer-to-peer network
  • nodes in the network jointly decide on the updating of the data by means of an agreement (consensus).
  • the data can be, for example, account balances of a cryptocurrency, proof of origin for goods, the content of the above-mentioned officially issued documents or, more abstractly, the status of so-called smart contracts.
  • a calculation rule is stored in the distributed ledger as a program or script (see below).
  • this program or script is used to authenticate and/or verify an input value.
  • the distributed ledger therefore does not contain a static value or date. Rather, it is stored in a smart contract (see below), such as, for example, based on an officially certified date of birth of a user, a query regarding his majority (with yes or no) is to be answered without later entering the date of birth of the user disclose the user himself.
  • This clearly defined, binary answer to a - possibly also complex - question is determined by a calculation rule in the smart contract checked by miner in the network (see below).
  • This response is transmitted as a certified/encrypted message comprising the response (is of legal age, has a class B driver's license, etc.) in relation to a document and/or an identity hint (name).
  • This response is for submission to a third party and provides easy and reliable handling in digital traffic.
  • a distributed ledger With a distributed ledger, there is no central communication control and no central storage of data records.
  • the network nodes each manage a local copy of the complete database and can add new data sets themselves.
  • a suitable consensus mechanism ensures that the distributed data sets are up-to-date and consistent in all nodes and that the distributed iedger as a distributed data structure is thus always kept in a consistent state.
  • smart contracts are stored as distributed programs/scripts tested by the miner, which can no longer be changed and are kept consistent.
  • the data structure, the data sets and consensus building, cryptographic methods are used for the required security (particularly integrity and authenticity).
  • Rules for the validation, storage and use of the data are encoded in various forms in the data sets themselves and are automatically executed and enforced by the network during processing.
  • biockchain technology data sets are validated as so-called transactions in a blockchain network and combined into blocks.
  • Cryptographic chaining connects new data blocks (transactions) to their predecessors in the chain in a tamper-proof manner. This concatenation also establishes a chronological order of the transactions. As a special case of a distributed iedger, this creates a chain of data blocks that is becoming longer, a so-called blockchain.
  • each block of the biockchain contains a cryptographic hash of the previous block in the chain, a timestamp, and one or more records.
  • a blockchain is maintained on the blockchain network, where all nodes collectively follow a protocol for validating new blocks.
  • a biockchain is inherently resistant to modification of the records, since once they have been included in the biockchain, they cannot be retrospectively modified without modifying all subsequent blocks. This would require consensus among the majority of nodes in the network.
  • a transaction also refers to information that is managed or to be processed in the distributed ledger/biockchain.
  • the term wallet describes on the one hand a digital wallet, for example in the mobile device for access data and secrets of a user, and on the other hand a general user interface to the blockchain network through which the user manages his access data and secrets and participates in the system can.
  • a network node or actor in the network that is allowed to add new blocks to a biockchain is also known as a miner.
  • One or more smart contracts can be stored in a distributed iedger. Smart contracts are not contracts in the legal sense, but rather computer-aided, executable instructions. A smart contract therefore contains one or more executable programs. A smart contract should enable actions or transactions between unknown or suspicious people in a tamper-proof manner. Such a smart contract has its own address for interaction with the smart contract.
  • the program code of the smart contract is sent to the biockchain in a transaction and executed by the network nodes as part of the validation.
  • the smart contract is invoked by a transaction.
  • a record is also entered into a smart contract by a transaction.
  • its calls can be registered and monitored.
  • the smart contract can also be called up completely anonymously in order to avoid disclosure of the data.
  • a call counter to display the reputation of the smart contract can also be implemented be. Since a blockchain is immutable, subsequent changes to the program code are impossible.
  • An independent entity the issuing office of a document (identity card, passport), the user or the checking third party can create a smart contract, have it checked by the miner network, certified and then used.
  • a smart contract can be programmed as a script in a stack-based scripting language, for example, or as a sequence of instructions in a compilable programming language, for example Solidity, Go, Java, Node.js or the like.
  • the compiler creates a bytecode. This bytecode or script is sent to the network as a stand-alone transaction without specifying a recipient address.
  • a miner assigns a newly generated address to the smart contract and publishes the program code in the blockchain.
  • a transaction to the address of the smart contract results in its execution by the miner when the transaction is included in a block and then by every other node when it is verified.
  • a client of a smart contract commissions only some of the network nodes / miners to execute the smart contract. These network nodes first simulate the execution of the smart contract locally independently of one another and report the result back to the client without anchoring it in the blockchain. If there is a sufficient number of matching responses, a transaction is set up and sent to another group of network nodes. This group decides the order in which incoming transactions are included in the blockchain without any validation or content evaluation. This validation is final by all network nodes when they update their local copy of the blockchain.
  • Regulations contained in the smart contract can also be executed outside of the blockchain on an API (application programming interface, interface for programming applications that is made available by a software system to other programs for connection to the system); only the commands that affect specific blockchain operations, such as a transfer of values, are forwarded to the blockchain as a transaction and entered there.
  • the program code can be changed later because it is not on the blockchain itself. The principle of immutability has been abandoned in favor of possible error correction.
  • a single b/ockchain has at least two blocks. Each block contains the hash value of the previous block. This creates a chain dependency that protects against illegitimate modification of a transaction in a block by requiring a recalculation of each block created after the modified block.
  • Transactions exchanged between the nodes of the network are stored in the blocks of the biockchain.
  • Each transaction can contain user data and a digital signature, e.g. B. contain the encrypted hash value of the user data.
  • New blocks are created by a consensus process among the nodes of the network and, once created, new blocks are appended to the biockchain.
  • a typical consensus procedure is the so-called proof-of-work procedure, which corresponds to searching for a hash value with a specific requirement, i.e. searching for a specific hash value that results after applying a hash function to the entire content of a block.
  • the difficulty of calculating this hash value is determined by the number of zero bits that must be present at the beginning of the hash value. This number of zero bits is also referred to as the degree of difficulty. A higher/lower number of zeros at the beginning of the hash value can increase/reduce the computational effort.
  • a so-called "nonce" i. H.
  • a random value that is part of a block can be used.
  • the nonce is randomly modified in proof-of-work to find the desired target hash for the entire block. So different hash values can be achieved by modifying the nonce and/or adding new incoming transactions. Finding the solution using the proof-of-work method usually involves a great deal of computing effort.
  • the proof-of-work procedure is not the only consensus procedure used; rather, others, e.g. B. proof-of-stake, proof-of-capacity, proof-of-burn and proof-of-activity are used.
  • miners are nodes that calculate blocks, i.e. also participate in the implementation of the proof-of-work.
  • miners can collect all current transactions that are not yet contained in the biockchain and the hash values obtained from the transactions with the hash value of the previous block, the timestamp and the nonce combine.
  • a hash function is applied to these combined records, yielding a hash of the new block.
  • Miners repeatedly perform this calculation (changing the nonce and/ or add new incoming transactions) until a solution for the proof-of-work is found.
  • the first miner to find a solution sends the calculated block to the other nodes in the network. When the other nodes validate the block, the transaction is added to the blockchain.
  • the new transaction is sent from the originating node into the network and received by all nodes.
  • the transaction is validated by all nodes and each node sends the result of the validation, i.e. it indicates whether the transaction is considered valid/validated or not.
  • the miners start the calculation of the block e.g., (4) the first miner to find a solution (e.g . B. for the proof-of-work) sends the calculated block into the network.
  • the other nodes validate the solution and send the validation result to the network, i.
  • each transaction can be digitally signed by the originating node of the transaction by applying a hash function to the transaction record and encrypting the resulting hashed value with the private key of the originating node.
  • the receiving nodes can then validate the transaction by decrypting the digital signature with the originating node's public key, computing the hash value of the record, and comparing the received hash value with the computed hash value.
  • the solution presented here combines certificate storage with a distributed iedger, in particular a blockchain.
  • At least one smart contract is stored in the distributed iedger / blockchain. Certificates with distributed trust are issued with the program or script contained in this smart contract or the sequence of instructions. In particular, the smart contract specifies how and under what conditions the data record contained in the certificate to be issued is to be calculated.
  • the solution presented here relates to a method for generating, providing and exchanging a trustworthy electronic data record or certificate based on an electronic document relating to a user, with the steps: providing the document comprising information relating to the user in an electronic format;
  • the blockchain including a smart contract configured and programmed to (i) check whether the document evidences the user's satisfaction of a constraint; (ii) to check the fulfillment / non-fulfilment of the constraint via the smart contract, (iii) to calculate a proof via the smart contract, and generate a certificate of the proof via the smart contract using a cryptographic function; and (iv) sending the certificate of the proof through the smart contract to the user.
  • a smart contract configured and programmed to (i) check whether the document evidences the user's satisfaction of a constraint; (ii) to check the fulfillment / non-fulfilment of the constraint via the smart contract, (iii) to calculate a proof via the smart contract, and generate a certificate of the proof via the smart contract using a cryptographic function; and (iv) sending the certificate of the proof through the smart contract to the user.
  • the solution presented here involves that the blockchain held in the network/computer and/or network resources is part of a distributed ledger.
  • a hash value calculated by the smart contract is stored in another blockchain in order to generate another characteristic of authenticity independently of the cryptographically generated proof.
  • the solution presented here uses the smart contract in the blockchain to calculate the certificate.
  • a hash is used as proof that (i) the calculation of the proof has taken place using the smart contract, and (ii) that nothing was changed.
  • the solution presented here includes, before contacting the blockchain held in the network, the user initiating an interaction with another person; and/or notification of the restriction of the interaction by the other person to the user, whereby the fulfillment / non-fulfilment of the restriction by the user must be proven on the basis of the document.
  • the solution presented here comprises, after the smart contract has sent the hash value of the proof to the user, (i) the user sending the received hash value of the proof to the other person; (ii) the further person checking the hash value of the proof; and/or (iii) causing, depending on the result of the check, execution or refusal of the interaction initiated by the user by the additional person.
  • the solution presented here includes the smart contract being set up and programmed to create a derived, trustworthy certificate for the calculated proof and the generated hash value of the proof.
  • the distributed ledger is transparent to each party regarding the smart contract and allows for validation of both itself and the calculation instructions.
  • the security and privacy of the data when accessing the user's documents are retained to the extent required or defined by the user, without the underlying document or a data element contained therein having to be disclosed.
  • age queries user is older than x years
  • the date of birth as a whole should not be disclosed.
  • a secure yes/no statement is generated from the user's certified date of birth.
  • the bank provides a statement confirming/denying the specific query value (user has a creditworthiness > €150,000) instead of the account statement.
  • the smart contracts can be expanded to include additional characteristics of the user (is socially insured, is a citizen of country XX, has a class YY driver’s license, has a residence permit in country XX on the ZZ date, etc.).
  • the level of trustworthiness - level of assurance - results from the trust that the distributed calculation or the network of miners offers.
  • the hashing of the smart contract and its storage in the distributed ledger guarantees a level of assurance that results from the share of miners in relation to all nodes in the network. This guarantees that the calculated value belongs exactly to the calculation instruction of the smart contract and that the validation of the smart contract and the calculation result is reliable.
  • a new credential is provided, with a certification from the blockchain network.
  • the certificate can be stored in the user's wallet and used later when this type of certification is required.
  • the certificate Once the certificate has been generated, it can later be shown multiple times.
  • the certificate itself can also be provided with a time stamp so that a third party can evaluate the certificate accordingly.
  • a count of calls to the smart contract can be stored in the blockchain, which can be used to document the reputation.
  • the certificate always contains the address of the smart contract for later verification by the verifier.
  • the provision of the document includes such a document in which at least information relating to the user is certified, signed and/or authenticated in the electronic format.
  • the contacting of the blockchain includes the transmission of information by the user by means of electronic data communication (i) to identify the user; (ii) to the document; (iii) the smart contract to be used to validate the restriction; and/or (iv) to the restriction; via a network to the blockchain.
  • the user sends the smart contract at least part of the document to check whether the restriction has been fulfilled; and/or the smart contract access data for at least part of the document; over the network to the blockchain.
  • a variant of the solution presented here comprises a program code or a script with instructions for (i) checking at least one certificate, one signature and/or one authentication of the document for checking whether the restriction of the smart contract has been fulfilled; (ii) calculating the proof based on the result of the check of the at least one certificate, the at least one signature and/or the at least one authentication of the document; and/or (iii) signing the proof using a preferably distributed cryptographic function by generating a signature of the proof.
  • a signature has the advantage that it can be used to prove who calculated the hash.
  • the smart contract SC is stored in the blockchain BC.
  • the signature can be created centrally or distributed, both are possible.
  • the sending of the proof certificate by the blockchain to the user includes transmitting the proof certificate by means of electronic data communication over the network to (i) the proof certificate in a mobile device or a stationary computer resource to save the wallet held by the user so that this certificate of the proof is accessible to the user for further processing; and/or (ii) to send the certificate of the proof with or without prior storage in the wallet of the mobile device or the stationary computer resource of the user via the network to the other person without any action by the user.
  • the provision of the document includes such a document in which (i) at least the user-related information using PHg a preferably biometric ID document are certified, signed and/or authenticated in the electronic format by an official authority or a trusted partner; and/or (ii) at least information relating to the user is stored in an electronic proof of identity and/or an elD server with a functional elD interface for external access.
  • the (i) smart contractm of the bbckchain is programmed and set up to access the information relating to the user in the electronic proof of identity and/or the elD server to check the restriction, and/or (ii) the information relating to the user is kept ready by the user as a mobile ID in his wallet for transmission via the network to the smart contractm of the blockchain.
  • a smart contract validated by miners in nodes of the network is used as a smart contract, which is programmed and set up to contain information relating to the user in the document with the restriction on its fulfillment transmitted to the smart contract to compare.
  • the smart contract can be programmed and set up to indicate the presence/non-existence of the fulfillment of the constraint after the proof has been calculated by the smart contract and the certificate of the proof has been generated by the smart contract using the cryptographic function to send users.
  • the smart contract can be programmed and set up to transmit further information from the document that can be specified with regard to the scope by means of information sent to the smart contract.
  • the smart contract is programmed and set up to (i) certify, sign and/or authenticate further information from the document for the information relating to the user and to the extent specified in terms of scope, and /or to generate new certified, signed, and/or authenticated data elements that can be fully verified by third parties through independent access to the smart contract in the bbckchain and that can be checked with regard to the authenticity of the data elements.
  • the smart contract is programmed and set up to send the existence / non-existence of fulfillment / non-fulfillment of the restriction by the user to the user in a form that has the same level of trustworthiness - level of assurance - like the document used to check the restriction using the smart contract; and/or where the smart contract programmed and set up so that the user (i) calculates the proof using the smart contract, (ii) generates the certificate of the proof using a, preferably distributed, cryptographic function using the smart contract, and/or (iii) the Sending of the certificate of the proof initiated by the smart contract to the user himself.
  • public-key cryptography/digital signatures and/or cryptographic hash functions are used as the cryptographic function.
  • a key pair with a private key and a public key that is mathematically linked to one another by a calculation rule is generated in public-key cryptography.
  • smart contract and the creation of a hasb ⁇ Ner- of the proof by the smart contract with ith i Ife of the key pair.
  • the pair of keys is used to create a digital signature, with the user signing the transaction with his private key, which only he has, and sending the resulting signed message to the smart contract.
  • the smart contract is set up and programmed to generate a hash value from the transaction, which is then encrypted with the private key. A third party can then use the public key to decrypt the hash value and check whether it matches the transaction.
  • the smart contract is set up and programmed to sign the proof with the digital signature before the hash value is sent.
  • the smart contract is set up and programmed to check the transaction with the user's public key and to verify the authenticity of the transaction, provided the two keys correspond.
  • the integrity of the content of the transaction must be checked by the user and/or the third person.
  • the hash function is deterministic. The original proof cannot be determined based on the generated hash value, especially not with justifiable effort. It is not possible, especially not with justifiable effort, to find a second, different proof that results in the same hash value of the proof. It is not possible, especially not with reasonable effort, to find two different proofs that result in the same hash value of the proof.
  • the hash function implements an algorithm based, for example, on SHA-2 or SHA-3.
  • the blockchain containing the smart contract and implemented in a distributed ledger is implemented as a permission-based public blockchain, as a permission-based private blockchain or as a permission-free public blockchain.
  • a portable device is also disclosed here, which is set up to execute logic in hardware and/or software, in which the method according to one of the above variants is implemented.
  • the logic is set up to carry out one or more of the method steps according to one of the above variants either with resources of the portable device, or to communicate via a network with remote resources for carrying out one or more of the method steps.
  • user-triggered or executed logic steps can be used to authenticate, verify and present the user, his data or parts thereof to a third party, and other logic steps can be decentralized as cbud computing and /or be implemented in nodes of the network, in particular also in nodes acting as miners.
  • a wallet is also disclosed here, implemented as a database in a portable device that is set up to execute logic in hardware and/or software, in which the method is implemented according to one of the above variants, and the logic for this is set up to carry out one or more of the method steps according to one of the above variants either with resources of the portable device or to communicate via a network with remote resources for carrying out one or more of the method steps.
  • a memory for storing the digital certificate of the proof can be provided in the portable device, which was transmitted by the blockchain to the wallet of the user by means of electronic data communication over the network.
  • the portable device can be programmed and set up to store and/or forward the digital certificate of the proof in the wallet by means of commands to be entered via a user interface, and/or store the digital certificate of the proof beforehand in the wallet from the user's portable device to the other person over the network without any action by the user.
  • the information relating to the user can be kept ready for the user as a mobile ID in his wallet for transmission via the network to the smart contract in the blockchain.
  • the solution presented here serves to generate, provide and forward a trustworthy electronic data record or certificate based on an electronic document D relating to a user N. Individual entities and their interaction with one another are illustrated as individual steps in FIG.
  • a validated smart contract which is stored in a distributed n ledger, is used to derive attributes of the authorization holder / user in a data protection-friendly manner without revealing additional information.
  • the validated smart contract verifies the official signatures of the data elements / information INFO of the document D and calculates and generates new certified data elements (exceeding/falling below an age limit, nationality, nationality, ...), which a third party through an electronic request - ge where distributed ledgers can be verified.
  • the smart contract and the results of its calculations are protected by strong cryptography. The same level of security can thus be achieved for the derived data as for the source data. Any third party granted access to the distributed ledger can verify the authenticity of these credentials.
  • the user can generate N credentials based on officially certified credentials.
  • the privacy of the user N is preserved as far as possible.
  • the derived proofs of authorization have the same or a similar level of assurance (LOA) as the source proof of authorization used for generation, although they were not generated by an authority or the like. Rather, the user N himself generates the derived proof of authorization by the smart contract
  • the present solution enables the user N to have a self-signed certificate issued which maintains the level of security of the original data or is not significantly weaker than this.
  • the creation and accumulation of metadata is avoided. It is also not possible to trace who requested which data and when, etc.
  • a digital wallet presented here with officially signed certificates also serves this purpose.
  • the solution calculates and derives signed certificates as a result of the calculations of a smart contract, which are stored in a distributed ledger and are (also publicly) available.
  • the distributed ledger is a permission-based public blockchain.
  • Other variants with which the solution presented here can also be implemented are a permission-based private blockchain or a permissionless public blockchain.
  • the distributed ledger makes the smart contract SC transparent for each trusting party and allows the smart contract SC and the calculation instructions it contains to be validated itself. With the help of validation schemes, the origin of the underlying certificates can be verified. The loa is thus retained without the underlying data element from, for example, an e-passport of user N being disclosed.
  • a calculation with the smart contract SC uses a certified data element, in this example the date of birth of user N. 1 illustrates this process.
  • the smart contract SC can be extended by relying parties to further properties such as "isMarried()", “isOver24()", “isEuropean()", “isHealth Insurance()” etc. by using the blockchain functionality.
  • the loa results from the trust that the distributed computation (and the (strong) encryption) offers. Hashing the smart contract and storing it in the distributed n ledger guarantees the LOA as long as more than half of the miners are independent. The smart contract guarantees that the calculated value corresponds exactly to the calculation statement of the smart contract and that the validation of the smart contract and the proof are reliable.
  • the result of the calculation becomes a new proof with a certification from the blockchain network.
  • the user N can store the certificate in the wallet and use it later when requested. Once generated, the proof can be shown multiple times.
  • the proof itself contains a time-stamped certification. In this way, the entity to which the proof is presented can evaluate the proof of entitlement accordingly.
  • the starting point is that the user N is identified by a trusting instance Certificate Authority, for example an official authority (government) (i) with an ID document, (ii) an ID card/deed (passport, identity card), or (iii) with biometric data.
  • a trusting instance Certificate Authority for example an official authority (government) (i) with an ID document, (ii) an ID card/deed (passport, identity card), or (iii) with biometric data.
  • the user N has a digitally signed th certificate from the Certificate Authority instance in an elD document or in an authorized database.
  • the user N has a digitally signed certificate in a digital wallet as a mobile ID in his smart phone or as a software wallet in a computer. The digitally signed certificate is accessible to the user for further processing.
  • the user N connects electronically with a biockchain BC and delivers his date of birth and his passport ID including official signatures to the biockchain BC. (Fig. 1, step 3)
  • the biockchain BC includes a smart contract SC.
  • This smart contract SC checks the signatures and calculates the proof.
  • the proof is signed by the biockchain BC using a distributed cryptographic function. (Fig. 1, steps 4 - 8)
  • the signed proof is sent back to user N.
  • User N puts the proof in his wallet for further use.
  • the wallet can be configured so that the proof is automatically forwarded to the entity that requested the proof, here the object Obj. (Fig. 1, step 9)
  • the proof is forwarded either automatically or manually by the user N to the entity that requested the proof.
  • the authority can now check the signature of the proof and decide on the access decision. (Fig. 1, steps 10 - 16)
  • step 1 the user N electronically accesses an object Obj, which is protected by a restriction RE.
  • the object Obj can be a rental agreement for an apartment.
  • the RE restriction is that the renter must be 24 years of age or older.
  • step 2 the object Obj informs the user N electronically that he has to provide proof that the tenant of the apartment must be 24 years old or older.
  • step 3 user N contacts a distributed ledger DL.
  • This distributed ledger DL includes a blockchain BC.
  • This biockchain BC contains a smart contract "Over23 proof”. In this way, the user N can (have) produce proof that he meets the restriction RE of being 24 years old or older without having to disclose his date of birth (day, month, year) to the landlord.
  • step 4 the smart contract SC requests the public key of the signer of the document D (the certification authority CA) in order to check the authenticity.
  • the smart contract SC generally receives the public key from an exchange platform PKD public key directory of the certification authority CA participants store their public keys there so that public key messages to them can be encrypted with these public keys. Decryption is only possible for the recipient with his private key private key. So-called digital signatures can also be generated with this mechanism, in which case a signature is generated with its private key and checked with the associated public key.
  • a digital signature is based on an asymmetric encryption, in which a sender uses his private key to calculate a value for a digital message, which is called the digital signature. With this value and the public key, third parties can check the undeniable authorship and integrity of the message. In order to be able to assign a signature created with a signature key to a person, the public key must be unequivocally assigned to this person. The signature is calculated from the digital message to be signed and the private key using a unique calculation rule. Different digital messages must lead to a different signature with a probability bordering on certainty, and the signature must result in a different value for each key.
  • the private key is usually not applied directly to the message, but to its hash value, which is calculated from the message using a hash function (such as SHA-2, SHA-3 or the like). becomes. If the public key was assigned to a person by means of a digital certificate, since there is only one private key corresponding to the public key, the identity of the signature creator can be determined and checked via the public directory of the certification service provider.
  • PKI Public Key Infrastructure
  • the authenticity of the sender is essential here - i.e. proof that the issuer of a public key is actually who he claims to be.
  • the public key infrastructure PKI makes it possible to ensure the trustworthiness of a public key by obtaining it from a trustworthy key directory. Issuers of documents can publish their public keys, which are required for verification, in the public key directory exchange platform. The smart contract SC can then obtain the public key from the platform.
  • step 5 the public key is transmitted to the smart contract SC.
  • step 6 the smart contract SC checks the signature of the certification authority CA under the document D. If the signature is valid, the next steps are carried out. If not, execution stops here.
  • step 7 the age check is based on the calculation rule in the smart contract SC and the date of birth in the document D, the accuracy and trustworthiness of which is documented by encryption with the public key and the authenticity of the document from the certification authority CA.
  • the information INFO arrives from the document D from the certification authority CA to the smart contract SC in the manner shown below.
  • the necessary data is made available directly to the smart contract SC.
  • the responsible public key directory PKD is previously entered in the smart contract SC.
  • the document D already has the necessary certificates. This eliminates the need for additional services.
  • the smart contract SC can be preceded by a dictionary function that gives the user information about which smart contract SC might be the most suitable for his query.
  • the smart contract SC thus calculates fulfillment on the basis of a document D provided by the certification authority CA, for example an e-passport document, more precisely information INFO in the document D relating to the user N in an electronic format the restriction RE by user N.
  • the result of this calculation is a true/false statement.
  • the date of birth (year - month - day) of user N is subtracted from the current date (year - month - day) and the result is 23 years compared. If the result is greater than 23, the smart contract SC will return a "True”; if the result is less than 23, the smart contract SC will return a "False".
  • a smart contract SC with any other functionality / test capability could also be executed.
  • step 8 the result is signed.
  • the basis of trust for this approach is the distributed ledger DL.
  • Each participant can view and validate the smart contract SC.
  • a dedicated distributed hash to detect manipulation protects each smart contract SC.
  • the result of the calculation is bundled with an ID of the user.
  • the ID of the user N and the proof proof are linked to the ID of the smart contract SC, more precisely the address of the smart contract SC, in order to document the origin of the result of the calculation.
  • the distributed ledger DL determines a hash value for this triple ⁇ ID, SC-result, SC-hash> in order to document the authenticity of the triple.
  • the triple cannot be changed without destroying the hash of the distributed ledger DL.
  • the distributed ledger DL consensus is a "proof-of-work" in one variant and a "proof-of-stake” in another variant.
  • step 9 the triple ⁇ ID, SC-result, SC-hash> is sent back electronically to the user N as the result of the calculation by the smart contract SC. User N can now store the result in his wallet.
  • step 10 the result of the calculation is sent electronically by the user N to the object Obj. This can be triggered manually by the user, or automatically by forwarding based on stored preferred settings as soon as the result of the calculation has reached the user N electronically and is stored in his wallet.
  • step 11 the validity of the proof of object Obj is checked in a request for verification. Alternatively, the proof of the object Obj can be forwarded to a dedicated verification instance VI for verification.
  • step 12 the dedicated verification instance VI checks the validity of the hashes and the signature using a request to the distributed ledger DL.
  • step 13 a validation takes place by subjecting the authenticity of the triple ⁇ ID, SC-result, SC-hash> and the triple signature to a check.
  • the distributed ledger DL compares the transmitted triple and its hash value with the triple originally generated by the smart contract SC, and then the values generated by the distributed ledger DL.
  • the verification result comes from the distributed ledger DL.
  • the distributed ledger DL is designed as an independent instance that delivers the result.
  • a property of the distributed iedger DL is that it is available online or offline because it is distributed to different nodes in the network. Verification can be done online or offline with a local, secured and certified copy of the distributed iedger DL.
  • the distributed iedger DL must be online from time to time in order to be updated with the latest changes in the distributed iedger DL.
  • the distributed iedger DL is preferably permission-based.
  • step 15 the verification instance VI makes a decision based on the verification result.
  • the verification instance VI generates a decision on the originally requested request.
  • the verification authority VI confirms or does not confirm the request, does the user have an "age-over-23"?
  • step 16 the requested access from step 1 may or may not be granted depending on the decision from step 15.
  • the prerequisite is that the ID of user N is not changed.
  • Another application is the proof of the general higher education entrance qualification, in which the holder of a high school diploma can prove his/her qualifications as a user without disclosing details of the exam, such as the date, location, grade or other content of the high school diploma. It is only proven that the user has the general university entrance qualification for which he has received a valid certificate from the smart contract SC.
  • Another use case is participation in a social assistance program.
  • User N applies for a government benefit and proves that he is entitled to it. To do this, the user N has his domestic address checked against his place of residence in his identity card as an election/Fasch statement.
  • Another application is a vehicle registration where the user N would like to register a car. To do this, he must give his address and tax information to the vehicle registration office. The address is given in full at the vehicle registration office. A proof of outstanding taxes of user N is required by the vehicle registration office.
  • User N provides his tax identification number. The user N himself electronically contacts a correspondingly programmed smart contract SC.
  • the smart contract SC connects to the tax authorities with reference to the tax identification number of user N and receives the statement that there are no outstanding tax payments by user N.
  • the smart contract SC certifies the result that user N has no tax debts. The user N uses this proof without disclosing his tax identification number when registering the vehicle.
  • Another use case is a certificate of deposit, where the user N is requested to have a certain amount of money available in preparation for a transaction (rent/buy a house, buy a car, etc.).
  • the user N uses an appropriately programmed smart contract SC together with details of his bank details (account details, credit line of the current account, cash balance) to prove the required amount as available without disclosing the account number, the financial institution and other details.
  • Another use case is a driver's license certificate, for which the user N must prove that he is authorized to drive and is at least 24 years old.
  • the procedure presented here provides proof without disclosing the other details of user N's driving license.
  • authorization to drive certain vehicles defined in the driving license classes (B, B17, B96, B196, BE, A1 , A2, A, AM, C1, C1E, C, CE, D1, D1E, D, DE, L, T) or groups thereof without disclosing the other details of user N's driving licence.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Die hier vorgestellte Lösung betrifft ein Verfahren zum Ezeugen, Bereitstellen und Austauschen eines vertrauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer betreffenden elektronischen Dokument, mit den Schritten; Bereitstellen des Dokuments, das eine den Nutzer betreffende Information in einem elektronischen Format umfasst; Kontaktieren einer in einem Netzwerk gehaltenen blockchain durch den Nutzer, wobei die blockchain einen smart contract enthält, der eingerichtet und dazu programmiert ist (i) zur Prüfung, ob das Dokument die Erfüllung einer Einschränkung durch den Nutzer belegt; (ii) zur Prüfung der Erfüllung/Nicht-Erfüllung der Einschränkung mittels des smart contract; (iii) zum Berechnen eines proof mittels des smart contract, und Erzeugen eines Zertifikates des proof mittels des smart contract unter Verwendung einer kryptografischen Funktion; und (iv) zum Versenden des Zertifikates und des proof durch den smart contract an den Nutzer.

Description

Verfahren und Vorrichtung zum Erzeugen, Bereitstellen und Weitergeben eines vertrauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer betreffenden elektronischen Dokument
Beschreibung
Gegenstand
Hier Ist ein Erzeugen, Bereitstellen und Weltergeben eines vertrauenswürdigen elektroni- schen Datensatzes oder Zertifikates basierend auf einem einen Nutzer betreffenden elektro- nischen Dokument offenbart. Dies ist als Vorrichtung und als Verfahren zu realisieren. Merk- male und Eigenschaften der Vorrichtung und des Verfahrens sind In den Ansprüchen defi- niert; aber auch die Beschreibung und die Figuren offenbaren Charakteristika der Vorrich- tung und des Verfahrens sowie deren unterschiedliche Aspekte und Zusammenhänge. Hintergrund und Stand der Technik
Herkömmliche offiziell ausgestellte Dokumente (Pass, Personalausweis, Führerschein, Ge- burts-, Heiratsurkunde, Schul- Universitätsabschluss, oder dergl.) enthalten eine Sammlung vordefinierter zertifizierter Datensätze (Name, Adresse, Geburtsdatum, Blutgruppe, Impfsta- tus, Familienstand, Fingerabdruck, Irisblld, etc.). Das Verlegen eines solchen Dokuments durch dessen Inhaber gegenüber einem Dritten (Behörde, Geschäftspartner, etc.) etwa zum Nachweis des Alters oder der Staatsangehörigkeit ist üblich und erfüllt seinen Zweck. Aller- dings gibt der Inhaber durch die Vorlage des Dokuments als Ganzes dem Dritten meist mehr Informationen (Nebeninformationen) über sich preis als In der momentanen Situation erfor- derlich.
Wird etwa beim Kauf einer altersbeschränkten Ware (zum Beispiel Genussmittel) ein solches Dokument seitens des Käufers zum Nachweis seiner Volljährigkeit verwendet, kann der Ver- käufer über den Käufer viel mehr Informationen (Vor- und Nachname, Tag, Monat; Jahr der Geburt, Wohnort; Staatsangehörigkeit, etc.) erlangen, als für den konkreten Nachweis (Käu- fer Ist volljährig) erforderlich. Ein Bonitätsnachweis, etwa eines Käufers für einen Abschluss eines Kaufvertrags einer Wohnung, oder ein Einkommensnachwels eines Mieters für einen Abschluss eines Mietvertrags, erfordern derzeit ein Schreiben einer Bank bzw. eines Arbeit- gebers. Aus einem solchen Schreiben lassen sich neben dem aktuell geforderten Umfang der Bonität diverse weitere Informationen entnehmen.
Eine mobile ID-Lösung, z.B. MB TECURE ID (https://www.muehlbauer.de/solutions/id-card- solution), verarbeitet digitale Darstellungen amtlich ausgestellter und beglaubigter Dokumen- te, wie Identitätsnachweise, Führerscheine, etc. Diese Dokumente umfassen oft ein Foto des Inhabers, Name, Adresse, Nationalität, Geschlecht, Geburtsdatum, Führerscheinklassen, Aus- stellung- und Gültigkeitsdatum, und Weiteres. Aus den Angaben des jeweiligen Dokuments wird eine mobile ID erzeugt, die auf einem Mobilgerät eines Reisenden eingespeichert und gehalten wird. Diese mobile ID ersetzt eine Vielzahl inhomogener Reisedokumente; sie er- laubt eine bequeme, berührungslose und datenschutzkonforme Vorgehensweise bei sicherer Identifikation des Reisenden.
Zur Identitätsprüfung einer Person und/oder einem Einräumen von Rechten an eine Person werden folgende Schritte unterschieden: Bei einer Authentisierung legt ein Nutzer einen Nachweis seiner vom System zu überprüfenden Identität vor. Eine Authentifizierung stellt die eigentliche Prüfung der vom Nutzer behaupteten Identität dar. Die Authentifizierung nimmt eine vertrauenswürdige Instanz vor. Diese vertrauenswürdige Instanz verifiziert oder falsifi- ziert die Identität des Nutzers anhand der im Nachweis enthaltenen Merkmale. Nach erfolg- reich abgeschlossener (verifizierter) Authentifizierung werden bei der Autorisierung dem Nut- zer die von ihm nachgefragten Rechte eingeräumt. Ein Reisender kann sich am Bahnhof mit Reisepass und Fahrkarte - aktiv - authentisieren. Durch das Bahnhofs-/Zugpersonal wird der Reisende - passiv - anhand der von ihm vorgelegten Dokumente authentifiziert. So ist der Reisende durch seine Fahrkarte zur Reise autorisiert.
In bekannten elektronischen Lösungen kann für derartige Szenarien die das Dokument aus- stellende Behörde / der Arbeitgeber kontaktiert und gebeten werden, zu diesem Dokument ein dediziertes Zertifikat mit einer dedizierten Signatur auszustellen. Dies erfordert eine zen- trale Infrastruktur und ist nicht datenschutzfreundlich, da die Verbindungsdaten (Metadaten) in der konkreten Situation nicht erforderliche Information (zum Beispiel Geo-Standort, Datum und Uhrzeit, Art des Zertifikats) preisgeben. Selbstsignierte Zertifikate sind eine weitere Mög- lichkeit. Diese Zertifikate bieten jedoch nur eine geringe Sicherheit, da die Authentizität des Inhalts des Zertifikats nicht nachgewiesen ist.
Public Key Infrastruktur PKI bezeichnet ein System, das digitale Zertifikate zu erzeugen, zu verteilen und zu prüfen in der Lage ist. Diese Zertifikate dienen als digitale Identität für Per- sonen. Eines asymmetrisches Kryptosystem kann elektronisch zu versendende Nachrichten signieren und verschlüsseln. Eine signierte Nachricht stammt in dieser Form tatsächlich vom angegebenen Absender. Um dies zu verifizieren, ist der öffentliche, zum Beispiel per E-Mail versendbare öffentliche Schlüssel (Public-Key) des Absenders erforderlich. Um zu gewährlei- sten, dass es sich tatsächlich um den Schlüssel des Absenders handelt, kann der zu verschi- ckende Schlüssel selbst wieder mit einem vertrauenswürdigen Schlüssel signiert sein. So ist eine Hierarchie aus vertrauenswürdigen Institutionen aufzubauen, wobei die Echtheit der Schlüssel der obersten Institution dieser Hierarchie zu akzeptieren ist. Digitale Zertifikate sind digital signierte elektronische Daten zum Nachweis der Echtheit von Objekten. Eine Zer- tifizierungsstelle - Certificate Authority, CA - ist eine das Zertifikat bereitstellende und die Si- gnatur von Zertifikatsanträgen übernehmende Entität. Eine PKI bietet ein hierarchisches Gül- tigkeitsmodell an. Wird einer Zertifizierungsstelle vertraut, wird allen von ihr signierten Zerti- fikaten auch vertraut. Da eine CA untergeordnete CAs haben kann, wird auch allen unterge- ordneten CAs vertraut.
Zugrundeliegendes Problem
Persönliche Daten sollen bei Wahrung oder nur geringfügiger Schwächung der Vollständig- keit und Korrektheit (Unversehrtheit) der Daten, der Authentizität der beteiligten Person oder IT-Komponente oder -Anwendung, des Schutzes vor unbefugter Preisgabe der Daten, und/ oder der Anonymität des Herausgebenden an einen Dritten ausgegeben werden können. Da- bei ist auch die Herausgabe von Meta-Daten im Zusammenhang mit der Datenausgabe an den Dritten zu vermeiden.
Lösung
Als Ausprägung einer Lösung wird ein Verfahren angegeben, das zumindest teilweise als Lo- gik (in Hard- und/oder Software) in einem portablen Gerät eines Nutzers implementiert ist. Der in dem portablen Gerät implementierte Teil der Logik ist dazu eingerichtet, mit weiteren, in entfernten portablen oder stationären Geräten / in cloud computing implementierten Tei- len der Logik über eine Netzwerk-/Daten-Verbindung zu kommunizieren.
Das portable Gerät ist in einer Variante ein Mobilgerät (Smartphone), das dazu eingerichtet ist, eine sog. App auszuführen, also eine Anwendungssoftware für das portable Gerät mit ei- nem dafür ausgerichteten mobilen Betriebssystem. In dieser App ist der vom Nutzer auszu- lösende / auszuführende Teil des Verfahrens, um in nutzerfreundlicher, Privatsphäre wahren- der, vertrauenswürdiger und situationsangemessener Weise den Nutzer, seine Daten oder deren Teile zu authentifizieren, zu verifizieren und einem Dritten zu präsentieren. Die dafür erforderlichen Verfahrensschritte werden dezentral ausgeführt. In einer Variante bietet cloud computing für die dezentrale Ausführung über ein Netz bei Bedarf, jederzeit und überall ei- nen einfachen und schnellen Zugriff auf einen geteilten Pool in erforderlicher Weise konfigu- rierbarer Rechnerressourcen (Netze, Server, Speichersysteme, Anwendungen und Dienste).
Anstelle des portablen Geräts kann für den Nutzer auch eine stationäre Rechnerresouce vor- gesehen sein, die dem Nutzer die für diese Lösung erforderliche Funktionalität bereitstellt.
Für die innerhalb und/oder außerhalb der App des portablen Geräts auszuführenden Schritte der Logik sind die folgende Ressourcen einzusetzen. In einem sogenannten distributed ledger (verteiltes digitales Analogon zu einem Buchfüh- rungsjournal) werden Datensätze in einem Peer-to-Peer-Netzwerk (P2P-Netzwerk) verteilt. Dabei entscheiden Knoten des Netzwerks durch eine Übereinkunft (Konsens) gemeinsam über die Aktualisierung der Daten. Bei den Daten kann es sich beispielsweise um Konto- stände einer Kryptowährung, Herkunftsnachweise für Waren, die Inhalte oben genannter offiziell ausgestellter Dokumente oder abstrakter um Vertragszustände von sogenannten smart contracts handeln.
In der hier vorgestellten Lösung wird in dem distributed ledger eine Rechenvorschrift, als Programm oder Skript (siehe unten) gespeichert. Dieses Programm oder Skript dient in einer Variante dazu, einen Eingangswert zu authentifizieren, und/oder zu verifizieren. Der distribu- ted ledger enthält also keinen statischen Wert oder Datum. Vielmehr wird in einem smart contract (siehe unten) hinterlegt, wie zum Beispiel basierend auf einem offiziell zertifizierten Geburts-Datum eines Nutzers eine Abfrage in Bezug auf dessen Volljährigkeit, (mit Ja oder Nein) zu beantworten ist, ohne später das Geburts-Datum des Nutzers selbst preiszugeben.
Diese klar definierte, binäre Antwort auf eine - ggf. auch komplexe - Frage, wird ermittelt durch eine von miner im Netzwerk überprüfte (siehe unten) Rechenvorschrift in dem smart contract. Diese Antwort wird übermittelt als eine zertifizierte / verschlüsselte Nachricht, um- fassend die Antwort (ist volljährig, hat einen Führerschein der Klasse B, etc.) in Bezug auf ein Dokument und/oder einen Identitätshinweis (Name). Diese Antwort dient zur Vorlage bei einem Dritten und bietet eine einfache und zuverlässige Handhabung im digitalen Verkehr.
Bei einem distributed ledger gibt es keine zentrale Kommunikationssteuerung und keine zen- trale Speicherung von Datensätzen. Die Knoten des Netzwerks verwalten jeweils eine lokale Kopie des vollständigen Datenbestands und können selbst neue Datensätze hinzufügen. Ein geeigneter Konsensmechanismus sorgt dafür, dass die verteilten Datensätze in allen Knoten aktuell sind und übereinstimmen und das distributed iedger als verteilte Datenstruktur damit stets in einem konsistenten Zustand gehalten wird. In dem distributed iedger sind smart con- tracts als verteilt durch die miner geprüfte Programme / Skripte abgelegt, die nicht mehr ge- ändert werden können und konsistent gehalten werden.
Zur Absicherung des Zugangs zu dem Netzwerk, der Datenstruktur, der Datensätze und der Konsensbildung werden für die erforderliche Sicherheit (insbesondere Integrität und Authen- tizität) kryptografische Verfahren eingesetzt. Regeln für die Validierung, Speicherung und Nutzung der Daten sind in diversen Ausprägungen in den Datensätzen selbst codiert und werden bei der Verarbeitung automatisiert vom Netzwerk ausgeführt und durchgesetzt. In der sogenannten biockchain-Technologie werden Datensätze als sogenannte transactions in einem blockchain-Netzwerk validiert und zu Blöcken zusammengefasst. Durch kryptografi- sche Verkettung werden neue Datenblöcke (transactions) manipulationssicher mit ihrem Vor- gänger in der Kette verbunden. Diese Verkettung legt auch eine chronologische Reihenfolge der transactions fest. So entsteht als Spezialfall eines distributed iedger eine länger werden- de Kette von Datenblöcken, eine sogenannte blockchain. Typischerweise enthält jeder Block der biockchain einen kryptografischen hash des vorherigen Blocks in der Kette, einen Zeit- stempel und einen oder mehrere Datensätze. Zur Verwendung als distributed ledger wird ei- ne biockchain in dem blockchain-Netzwerk verwaltet, in dem alle Knoten gemeinsam ein Pro- tokoll zur Validierung neuer Blöcke befolgen. Eine biockchain ist inhärent resistent gegen Mo- difikation der Datensätze, da diese nach ihrer Aufnahme in die biockchain nicht rückwirkend geändert werden können, ohne dass alle nachfolgenden Blöcke geändert werden. Dies wür- de einen Konsens zwischen der Mehrheit der Knoten im Netzwerk erfordern.
Eine transaction bezeichnet dabei auch eine in dem distributed ledger / der biockchain ver- waltete oder zu verarbeitende Information. Der Begriff wallet beschreibt zum einen eine digi- tale Brieftasche zum Beispiel in dem Mobilgerät für Zugangsdaten und Geheimnisse eines Nutzers, und zum anderen eine generelle Benutzerschnittstelle zum blockchain-Netzwerk, über die der Nutzer seine Zugangsdaten und Geheimnisse verwalten und am System teil ha- ben kann. Ein Netzwerkknoten oder Akteur im Netzwerk, der einer biockchain neue Blöcke hinzufügen darf, wird auch als miner bezeichnet.
In einem distributed iedger können ein oder mehrere smart contracts gespeichert sein. Als smart contract sind nicht Verträge im rechtlichem Sinne, sondern rechnergestützte, ausführ- bare Anweisungen verstanden. Ein smart contract enthält also ein oder mehrere ausführbare Programme. Ein smart contract soll Handlungen oder Geschäfte zwischen einander unbe- kannten oder misstrauenden Personen manipulationssicher ermöglichen. Ein solcher smart contract exhält eine eigene Adresse zur Interaktion mit dem smart contract.
Der Programmcode des smart contract wird in einer transaction an die biockchain gesendet und von den Netzwerkknoten im Rahmen der Validierung ausgeführt. Der smart contract wird durch eine transaction aufgerufen. Ein Datensatz wird in einen smart contract ebenfalls durch eine transaction eingegeben. In hier vorgestellten Varianten des smart contract kann dessen Aufrufen registriert und überwacht werden. Aber auch völlig anonymes Aufrufen des smart contract kann vorgesehen sein, um ein Offenlegen der Daten zu vermeiden. Ein Auf- ruf-Zähler zur Darstellung der Reputation des smart contract kann zusätzlich implementiert sein. Da eine blockchain unveränderlich ist, sind nachträgliche Änderungen am Programm- code unmöglich.
Eine unabhängige Instanz, die ausgebende Stelle eines Dokuments (Personalausweis, Reise- pass), der Nutzer oder der prüfende Dritte kann einen smart contract erstellen, von dem Netzwerk der miner prüfen, zertifizieren und anschließend nutzen lassen.
Ein smart contract kann als Skript in einer z.B. stackbasierten Skriptsprache, oder als Anwei- sungsabfolge in einer compilierbaren Programmiersprache, zum Beispiel Solidity, Go, Java, Node.js oder dergl. programmiert sein. Der Compiler erzeugt einen Bytecode. Dieser Byte- code oder das Skript wird als eigenständige transaction ohne Angabe einer Empfängeradres- se an das Netzwerk gesendet. Ein miner ordnet dem smart contract eine neu erzeugte Ad- resse zu und veröffentlicht den Programmcode in der blockchain. Eine transaction an die Ad- resse des smart contract hat dessen Ausführung durch den miner bei Aufnahme der trans- action in einen Block und anschließend von jedem anderen Knoten bei dessen Verifikation zur Folge.
Alterativ beauftragt ein Auftraggeber eines smart contract nur einige der Netzwerkknoten / miner mit der Ausführung des smart contract Diese Netzwerkknoten simulieren unabhängig voneinander zunächst lokal die Ausführung des smart contract und meldet das Ergebnis an den Auftraggeber zurück, ohne es in der blockchain zu verankern. Bei ausreichender Anzahl übereinstimmender Rückmeldungen wird eine transaction aufgesetzt und an eine andere Gruppe von Netzwerkknoten geschickt. Diese Gruppe entscheidet ohne eine Validierung oder inhaltliche Bewertung über die Reihenfolge, in der eingegangene transactions in die block- chain aufgenommen werden. Diese Validierung erfolgt final durch alle Netzwerkknoten, wenn sie ihre lokale Kopie der blockchain aktualisieren.
In dem smart contract enthaltene Regelungen können auch außerhalb der blockchain auf ei- ner API (application programming interface, Schnittstelle zur Programmierung von Anwen- dungen, die von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird), ausgeführt werden; lediglich die Befehle, die spezifische block- chain-Operationen betreffen, etwa ein Transfer von Werten, werden als transaction an die blockchain weitergeleitet und dort eingetragen. So ist der Programmcode nachträglich verän- derbar, da dieser nicht selbst auf der blockchain liegt. Dabei ist das Prinzip der Unveränder- lichkeit zugunsten einer möglichen Fehlerkorrektur aufgegeben.
Noch detaillierter ergibt sich basierend auf der vorstehend erläuterten Infrastruktur folgen- des Zusammenwirken der einzelnen Funktionen: Eine einzelne b/ockchain hat wenigstens zwei Blöcke. Jeder Block enthält den hash-Wert des vorhergehenden Blocks. So wird eine Kettenabhängigkeit hergestellt, die vor unrechtmäßiger Änderung einer transaction in einem Block schützt, indem sie eine Neuberechnung jedes Blocks erfordert, der nach dem geänderten Block erzeugt wird. Transactions, die zwischen den Knoten des Netzwerks ausgetauscht werden, werden in den Blöcken der biockchain ge- speichert. Dabei kann jede transaction Benutzerdaten und eine digitale Signatur, z. B. den verschlüsselten Hash-Wert der Benutzerdaten enthalten. Eine transaction kann als Msg = D + h(D) definiert werden, wobei Msg die Nachricht bezeichnet, D für den in der transaction enthaltenen Datensatz steht, und h() eine hash-Funktion bezeichnet.
Neue Blöcke werden durch ein Konsensverfahren unter den Knoten des Netzwerks erzeugt und, sobald sie erzeugt sind, werden neue Blöcke an die biockchain angehängt. Ein typisches Konsensverfahren ist das sogenannte proof-of-work-Verfahren, das der Suche nach einem hash-Wert mit einer bestimmten Anforderung entspricht, d.h. der Suche nach einem be- stimmten hash-Wert, der sich nach Anwendung einer hash -Funktion auf den gesamten In- halt eines Blocks ergibt. Die Schwierigkeit, diesen hash -Wert zu berechnen, wird durch die Anzahl der Nullbits bestimmt, die am Anfang des hash -Wertes vorhanden sein müssen. Die- se Anzahl der Nullbits wird auch als Schwierigkeitsgrad bezeichnet. Durch eine höhere/niedri- gere Anzahl von Nullen am Anfang des hash -Wertes kann der Rechenaufwand erhöht/ver- ringert werden. Zur Berechnung des hash -Wertes kann eine sogenannte "nonce", d. h. ein Zufallswert verwendet werden, der Teil eines Blocks ist. Die nonce wird im proof-of-work- Verfahren zufällig modifiziert, um den gewünschten Ziel-hash -Wert für den gesamten Block zu finden. Unterschiedliche hash -Werte können also durch Modifikation der nonce und/ oder Hinzufügen neuer eingehender transactions erreicht werden. Das Finden der Lösung im proof-of-work-Verfahren ist in der Regel mit einem hohen Rechenaufwand verbunden. Das proof-of-work-Verfahren ist nicht das einzige verwendete Konsensverfahren; vielmehr wer- den auch andere, z. B. proof-of-stake, proof-of-capacity, proof-of-burn und proof-of-activity verwendet.
In dem blockchain-Netzwerk sind miner solche Knoten, die Blöcke berechnen, also auch an der Durchführung des proof-of-work teilnehmen . Um einen neuen Block zu berechnen, kön- nen miner alle aktuellen transactions sammeln, die noch nicht in der biockchain enthalten sind, und die aus den transactions gewonnenen Hash-Werte mit dem Hash-Wert des vorheri- gen Blocks, dem Zeitstempel und der nonce kombinieren. Als Nächstes wird auf diese kombi- nierten Datensätze eine hash-Funktion angewendet, die einen hash-Wert des neuen Blocks ergibt. Miner führen diese Berechnung wiederholt durch (indem sie die nonce ändern und/ oder neue eingehende transactions hinzufügen), bis eine Lösung für den Proof-of-Work ge- funden ist. Der erste miner, der eine Lösung findet, sendet den berechneten Block an die an- deren Knoten im Netzwerk. Wenn die anderen Knoten den Block validieren, wird die trans- action zur blockchain hinzugefügt.
Um eine neue transaction der blockchain hinzuzufügen, werden typischerweise die folgenden Schritte im blockchain-Netzwerk ausgeführt: (1) Die neue transaction wird vom Ursprungs- knoten in das Netzwerk gesendet und von allen Knoten empfangen. (2) Die transaction wird von allen Knoten validiert und jeder Knoten sendet das Ergebnis der Validierung, d.h., er gibt an, ob die transaction als gültig / validiert angesehen wird oder nicht. (3) Wenn die trans- action akzeptiert wird, d.h., die Mehrheit der Knoten bestimmt die transaction als gültig / va- lidiert, beginnen die miner die Berechnung des Blocks z.B., (4) der erste miner, der eine Lö- sung (z. B. für den proof-of-work) findet, sendet den berechneten Block in das Netzwerk. (5) Die anderen Knoten validieren die Lösung und senden das Validierungsergebnis in das Netz- werk, d. h., sie geben an, ob die Lösung akzeptiert oder abgelehnt wird. (6) Wenn die Lö- sung akzeptiert wird, d. h., die Mehrheit der Knoten akzeptiert die Lösung, wird der Block der blockchain hinzugefügt und die Knoten aktualisieren ihr distributed iedger entsprechend. Die Validierung der transaction in Schritt (2) oben kann unter Verwendung bekannter digita- ler Signaturen durchgeführt werden. Z.B. kann jede transaction vom Ursprungsknoten der transaction digital signiert werden, indem eine hash - Funktion auf den Datensatz der Trans- aktion angewendet und der erhaltene hash-Wert mit dem private key des Ursprungsknotens verschlüsselt wird. Die empfangenden Knoten können dann die transaction validieren, indem sie die digitale Signatur mit dem öffentlichen Schlüssel des Ursprungsknotens entschlüsseln, den hash-Wert des Datensatzes berechnen und den empfangenen hash -Wert mit dem berechneten hash-Wert vergleichen.
Aus technischer Sicht werden bei der hier vorgestellten Lösung Zertifikate-Speicher mit ei- nem distributed iedger, insbesondere einer blockchain kombiniert. In dem distributed iedger / der blockchain ist zumindest ein smart contract hinterlegt. Mit dem in diesem smart con- tract enthaltenen Programm oder Skript oder der Anweisungsabfolge werden Zertifikate mit verteiltem Vertrauen ausgegeben. Der smart contract legt insbesondere fest, wie und unter welchen Bedingungen der Datensatz zu berechnen ist, der sich in dem auszugebenden Zertifikat befindet.
Die hier vorgestellte Lösung betrifft ein Verfahren zum Erzeugen, Bereitstellen und Austau- schen eines vertrauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer betreffenden elektronischen Dokument, mit den Schritten: Bereitstellen des Dokuments, das eine den Nutzer betreffende Information in einem elektro- nischen Format umfasst;
Kontaktieren einer in einem Netzwerk gehaltenen blockchain durch den Nutzer, wobei die blockchain einen smart contract enthält, der eingerichtet und dazu programmiert ist (i) zur Prüfung, ob das Dokument die Erfüllung einer Einschränkung durch den Nutzer belegt; (ii) zur Prüfung der Erfüllung / Nicht-Erfüllung der Einschränkung mittels des smart contract, (iii) zum Berechnen eines proof mittels des smart contract, und Erzeugen eines Zertifikates des proof mittels des smart contract unter Verwendung einer kryptografischen Funktion; und (iv) zum Versenden des Zertifikates des proof durch den smart contract an den Nutzer.
Die hier vorgestellte Lösung umfasst, dass die in dem Netzwerk / den Rechner- und/oder Netzwerkressourcen gehaltene blockchain Teil eines distributed ledger ist.
Zusätzlich wird in einer Variante der hier vorgestellten Lösung ein durch den smart contract berechneter hash-Wert in einer weiteren blockchain abgelegt, um unabhängig vom krypto- graphisch erzeugten proof ein weiteres Merkmal der Authentizität zu erzeugen.
Die hier vorgestellte Lösung nutzt den smart contract in der blockchain zur Berechnung des Zertifikates.
Anstelle des zu versendenden Zertifikates des proof durch den smart contract an den Nutzer wird in einer Variante der hier vorgestellten Lösung ein hash verwendet als Beleg verwendet, dass (i) die Berechnung des proof mittels des smart contract stattgefunden hat, und (ii) dass nichts verändert wurde.
Die hier vorgestellte Lösung umfasst in einer Variante vor dem Kontaktieren der in dem Netzwerk gehaltenen blockchain, ein Einleiten einer Interaktion mit einer weiteren Person durch den Nutzer; und/oder ein Mitteilen der Einschränkung der Interaktion durch die wie- tere Person an den Nutzer, wobei die Erfüllung / Nicht-Erfüllung der Einschränkung durch den Nutzer anhand des Dokuments zu belegen ist.
Die hier vorgestellte Lösung umfasst in einer weiteren Variante, nach dem Versenden des hash-Wertes des proof durch den smart contract an den Nutzer, (i) ein Versenden des er- haltenen hash-Wertes des proof durch den Nutzer an die weitere Person; (ii) ein Prüfen des hash-Wertes des proof durch die weitere Person; und/oder (iii) ein Bewirken, abhängig vom Ergebnis des Prüfens, einer Ausführung oder Verweigerung der durch den Nutzer eingeleite- ten Interaktion durch die weitere Person. Die hier vorgestellte Lösung umfasst in einer weiteren Variante, dass der smart contract eingerichtet und dazu programmiert ist, ein abgeleitetes, vertrauenswürdiges Zertifikat zu dem berechneten proof und dem erzeugten hash-Wertes des proof zu erstellen.
Der distributed ledger ist in Bezug auf den smart contract für jede Partei transparent und ermöglicht die Validierung sowohl seiner selbst als auch der Berechnungsanweisungen. Da- bei bleiben Sicherheit und privacy der Daten bei Zugriff auf Dokumente des Nutzers im vom Nutzer geforderten oder definierten Umfang erhalten, ohne dass das zugrunde liegende Do- kument oder ein darin enthaltenes Datenelement offenzulegen ist. So ist zum Beispiel bei Al- tersabfragen (Nutzer ist älter als x Jahre) nicht das Geburtsdatum als ganzes (Tag/ Monat/ Jahr) preiszugeben. Vielmehr wird mit der hier vorgestellten Lösung aus dem zertifizierten Geburtsdatum des Nutzers eine sichere Ja/Nein-Aussage erzeugt. Ähnlich liefert bei einer Bo- nitätsabfrage für einen Wohnungskauf die Bank statt des Kontoauszugs eine den konkreten Abfragewert bestätigende/verneinende Aussage (Nutzer hat eine Bonität > €150000). Die smart contracts können unter Verwendung der blockchain-Funktionalität auf weitere Eigen- schaften des Nutzer (ist sozialversichert, ist Staatsbürger des Landes XX, hat Fahrerlaubnis der Klasse YY, hat zum Datum ZZ einen Aufenthaltstitel im Land XX, etc.) erweitert werden.
Das Maß an Vertrauenwürdigkeit - level ofassurance - ergibt sich aus dem Vertrauen, das die verteilte Berechnung bzw. das Netzwerk aus minern bietet. Das hashing des smart con- tract und dessen Speicherung im distributed ledger garantiert einen level ofassurance, der sich aus dem Anteil der miner bezogen auf alle Knoten im Netzwerk ergibt. So wird garan- tiert, dass der berechnete Wert genau zu der Berechnungsanweisung des smart contract ge- hört und die Validierung des smart contracts und des Berechnungsergebnisses zuverlässig ist.
Als Ergebnis der Berechnung wird ein neuer Berechtigungsnachweis bereitgestellt, mit einer Zertifizierung aus dem blockchain-Netzwerk. Das Zertifikat kann in der wallet des Nutzers ge- speichert und später verwendet werden, wenn diese Art der Zertifizierung erforderlich ist.
Das einmal generierte Zertifikat kann später mehrfach gezeigt werden. Das Zertifikat selbst kann auch mit einem Zeitstempel versehen sein, so dass eine dritte Partei das Zertifikat ent- sprechend bewerten kann. In der blockchain kann eine Zählung der Aufrufe des smart con- tract hinterlegt werden, die zur Dokumentation der Reputation dienen kann. Das Zertifikat enthält immer die Adresse des smart contract zur späteren Verifikation durch den Überprü- fenden. Bei einer Variante der hier vorgestellten Lösung umfasst das Bereitstellen des Dokuments ein solches Dokument, bei dem zumindest den Nutzer betreffende Information in dem elektroni- schen Format zertifiziert, signiert, und/oder authentifiziert sind.
Bei einer Variante der hier vorgestellten Lösung umfasst das Kontaktieren der blockchain ein Übermitteln von Angaben durch den Nutzer mittels einer elektronischen Datenkommunika- tion (i) zur Identifizierung des Nutzers; (ii) zu dem Dokument; (iii) zu dem zur Prüfung der Einschränkung zu verwendenden smart contract; und/oder (iv) zu der Einschränkung; über ein Netzwerk an die blockchain umfasst.
Bei einer Variante der hier vorgestellten Lösung sendet der Nutzer zum Prüfen der Erfüllung der Einschränkung mittels des smart contract, (i) dem smart contract zumindest teilweise das Dokument; und/oder dem smart contract Zugangsdaten zu zumindest einem Teil des Dokuments; über das Netzwerk an die blockchain.
Eine Variante der hier vorgestellten Lösung umfasst zum Prüfen der Erfüllung der Einschrän- kung der smart contract einen Programmcode oder ein Skript mit Anweisungen zum (i) Prü- fen wenigstens eines Zertifikats, einer Signatur und/oder einer Authentifizierung des Doku- ments; (ii) Berechnen des proof basierend auf dem Ergebnis der Prüfung des wenigstens ei- nen Zertifikats, der wenigstens einen Signatur und/oder der wenigstens einer Authentifizie- rung des Dokuments; und/oder (iii) Signieren des proof mittels einer vorzugsweise verteilten kryptografischen Funktion durch Erzeugen einer Signatur des proof. Eine Signatur hat den Vorzug, dass mit ihr zu beweisen ist, wer den hash berechnet hat. Der smart contract SC ist in der in der blockchain BC abgelegt. Die Signatur kann dabei zentral oder verteilt erstellt werden, das ist beides möglich.
Bei einer Variante der hier vorgestellten Lösung umfasst das Versenden des Zertifikates des proof durch die blockchain an den Nutzer ein Übermitteln des Zertifikates des proof mittels elektronischer Datenkommunikation über das Netzwerk, um (i) das Zertifikat des proof in einer in einem Mobilgerät oder einer stationären Rechnerresouce des Nutzers gehaltenen wallet abzuspeichern, so dass dieses Zertifikat des proof für den Nutzer zur weiteren Bear- beitung zugänglich ist; und/oder (ii) das Zertifikat des proof mit oder ohne vorheriges Ab- speichern in der wallet von dem Mobilgerät oder der stationären Rechnerresouce des Nutzers ohne eine Aktion des Nutzers über das Netzwerk an die weitere Person zu versenden.
Bei einer Variante der hier vorgestellten Lösung umfasst das Bereitstellen des Dokuments ein solches Dokument, bei dem (i) zumindest den Nutzer betreffende Information unter Verwen- düng eines vorzugsweise biometrischen ID-Dokuments von einer offiziellen Behörde oder ei- nes trusted partner in dem elektronischen Format zertifiziert, signiert, und/oder authentifi- ziert sind; und/oder (ii) zumindest den Nutzer betreffende Information in einem elektroni- schen Identitätsnachweis und/oder einem elD-Server mit funktionaler elD-Schnittstelle für externe Zugriffe gespeichert sind.
Bei einer Variante der hier vorgestellten Lösung ist der (i) smart contractm der bbckchain dazu programmiert und eingerichtet, auf die den Nutzer betreffende Information in dem elektronischen Identitätsnachweis und/oder dem elD-Server zur Prüfung der Einschränkung zuzugreifen, und/oder (ii) die den Nutzer betreffende Information als mobile ID in seiner wallet durch den Nutzer bereitgehalten zur Versendung über das Netzwerk an den smart contractm der blockchain.
Bei einer Variante der hier vorgestellten Lösung wird als smart contract ein durch miner in Knoten des Netzwerks validierter smart contract eingesetzt, der programmiert und dazu ein- gerichtet ist, in dem Dokument den Nutzer betreffende Information mit der an den smart contract übermittelten Einschränkung auf deren Erfüllung hin zu vergleichen. Dabei kann der smart contract programmiert und dazu eingerichtet sein, ein Vorliegen / Nicht-Vorliegen der Erfüllung der Einschränkung nach dem Berechnen des proof durch den smart contract, und dem Erzeugen des Zertifikates des proof durch den smart contract mithilfe der kryptogra- fischen Funktion an den Nutzer zu versenden. Zusaätzlich oder stattdessen kann der smart contract programmiert und dazu eingerichtet sein, mittels an den smart contract gesendeter Angaben hinsichtlich des Umfangs festlegbare weitere Informationen aus dem Dokument übertragen.
Bei einer Variante der hier vorgestellten Lösung ist der smart contract programmiert und dazu eingerichtet, (i) für die den Nutzer betreffende Information, und soweit hinsichtlich des Umfangs festgelegt, weitere Informationen aus dem Dokument, zu zertifizieren, signieren, und/oder authentifizieren, und/oder neue zertifizierte, signierte, und/oder authentifizierte Datenelemente zu erzeugen, die durch Dritte durch unabhängigen Zugriff auf den smart contract in der bbckchain vollständig verifizierbar und hinsichtlich der Authentizität der Da- tenelemente überprüfbar sind.
Bei einer Variante der hier vorgestellten Lösung ist der smart contract programmiert und dazu eingerichtet, das Vorliegen / Nicht-Vorliegen der Erfüllung / Nicht-Erfüllung der Ein- schränkung durch den Nutzer in einer Form an den Nutzer zu senden, die das gleiche Maß an Vertrauenwürdigkeit - level of assurance - aufweisen wie das zum Prüfen der Einschrän- kung mittels des smart contract verwendete Dokument; und/oder wobei der smart contract programmiert und dazu eingerichtet ist, dass der Nutzer (i) das Berechnen des proof durch den smart contract, (ii) das Erzeugen des Zertifikates des proof durch den smart contract mithilfe einer, vorzugsweise verteilten, kryptografischen Funktion, und/oder (iii) das Versen- den des Zertifikates des proof durch den smart contract an den Nutzer selbst initiiert.
Bei einer Variante der hier vorgestellten Lösung werden als kryptografische Funktion eine public-key -Kryptographie / digitale Signaturen und/oder kryptographische hash-Funktionen eingesetzt. In einer Variante wird in der public-key -Kryptographie ein durch eine Rechenvor- schrift mathematisch miteinander verbundenes Schlüsselpaar mit einem private key und ei- nem public key erzeugt. In einer Variante smart contract, und das Erzeugen eines hasb-\Ner- tes des proof durch den smart contract m ith i Ife des Schlüsselpaars. In einer Variante wird das Schlüsselpaar zur Erstellung einer digitalen Signatur verwendet, indem der Nutzer die transaction mit seinem private key signiert, über den nur er verfügt, und die so entstandene signierte Nachricht an den smart contract sendet. In einer anderen Variante ist der smart contract eingerichtet und dazu programmiert, von der transaction ein hash-Wert erzeugt, der dann mit dem private key verschlüsselt wird. Mit dem public key kann anschließend ein Drit- ter den hash-Wert entschlüsseln und prüfen, ob er zur transaction paßt. In einer weiteren Variante ist der smart contract eingerichtet und dazu programmiert, vor dem Versenden des hash-Wertes des proof diesen mit der digitalen Signatur zu signieren. In einer Variante ist der smart contract eingerichtet und programmiert, die transaction mit dem public key des Nutzers zu prüfen und die Authentizität der transaction, sofern die beiden Schlüssel korre- spondieren, zu verifizieren. In einer Variante ist nach dem Signieren der transaction durch den smart contract die transaction auf inhaltliche Integrität durch den Nutzer und/oder die dritte Person zu prüfen.
In einer Variante ist der smart contract eingerichtet und dazu programmiert, das Erzeugen des hash-Wertes und/oder des Zertifikats des proof mit einer kryptographischen hash-Funk- tion auszuführen, wobei aus dem proof, der eine Zeichenfolge beliebiger Länge ist, eine Re- chenvorschrift der hash-Funktion eine Zeichenfolge mit fixer Länge ( = hash-Wert ) erzeugt. Dabei ist die hash-Funktion deterministisch. Ausgehend von dem erzeugten hash-Wert ist der ursprüngliche proof nicht, insbesondere nicht mit vertretbarem Aufwand, zu bestimmen. Es ist nicht, insbesondere nicht mit vertretbarem Aufwand, möglich, einen zweiten, anderen proof zu finden, der denselben hash-Wert des proof ergibt. Es ist nicht, insbesondere nicht mit vertretbarem Aufwand, möglich, zwei unterschiedliche proofs zu finden, die denselben hash-Wert des proof ergeben. In einer Variante implementiert die hash-Funktion einen z.B. auf SHA-2, oder SHA-3 basierenden Algorithmus. In einer Variante ist die den smart contract enthaltende, in einem distributed ledger imple- mentierte blockchain als erlaubnisbasierte öffentliche blockchain, als eine erlaubnisbasierte private blockchain oder als eine erlaubnisfreie öffentliche blockchain implementierte.
Hier ist auch ein portables Gerät offenbart, das dazu eingerichtet ist, eine Logik in Hard- und /oder Software auszuführen, in der das Verfahren nach einer der vorstehenden Varianten im- plementiert ist. Die Logik ist dazu eingerichtet, einen oder mehrere der Verfahrensschritte nach einer der vorstehenden Varianten entweder mit Ressourcen des portablen Geräts aus- zuführen, oder über ein Netzwerk mit entfernten Ressourcen zur Ausführung eines oder mehrerer der Verfahrensschritte zu kommunizieren. Insbesondere in dem portablen Gerät können vom Nutzer auszulösende oder auszuführende Verfahrensschritte der Logik dazu die- nen, den Nutzer, seine Daten oder deren Teile zu authentifizieren, zu verifizieren und einem Dritten zu präsentieren, und weitere Verfahrensschritte der Logik dezentral als cbud Compu- ting und/oder in Knoten des Netzwerks, insbesondere auch in als miner wirkenden Knoten implementiert sein.
Hier ist auch ein wallet offenbart, implementiert als Datenbank in einem portablen Gerät, das dazu eingerichtet ist, eine Logik in Hard- und/oder Software auszuführen, in der das Verfah- ren nach einer der vorstehenden Varianten implementiert ist, und wobei die Logik dazu ein- gerichtet ist, einen oder mehrere der Verfahrensschritte nach einer der vorstehenden Varian- ten entweder mit Ressourcen des portablen Geräts auszuführen, oder über ein Netzwerk mit entfernten Ressourcen zur Ausführung eines oder mehrerer der Verfahrensschritte zu kom- munizieren. Insbesondere kann in dem portablen Gerät ein Speicher zur Speicherung des di- gitalen Zertifikates des proof vorgesehen sein, der durch die blockchain an die wallet des Nutzers mittels elektronischen Datenkommunikation über das Netzwerk übermittelt wurde.
Das portable Gerät kann programmiert und dazu eingerichtet sein, in der wallet die Speiche- rung und/oder die Weiterversendung des digitalen Zertifikates des proof mittels über eine Nutzeroberfläche einzugebender Befehle zu bewirken, und/oder das digitale Zertifikat des proof mit vorherigem Abspeichern in der wallet von dem portablen Gerät des Nutzers ohne eine Aktion des Nutzers über das Netzwerk an die weitere Person zu versenden. Die den Nutzer betreffende Information kann als mobile ID in seiner wallet für den Nutzer bereitge- halten werden zur Versendung über das Netzwerk an den smart contract in der blockchain.
Kurzbeschreibuno der Figuren
Weitere Merkmale, Eigenschaften, Vorteile, Zweckmäßigkeiten der Vorrichtungen und der Verfahrensweisen sind der nachfolgenden Beschreibung in Verbindung mit der Zeichnung zu entnehmen. Auch mögliche Abwandlungen werden für einen Fachmann anhand der nachste- henden Beschreibung deutlich, die auf die beigefügten Zeichnungen Bezug nimmt. Dabei veranschaulichen die Fig. Ausführungsformen hier erörterter Lösungen. Hierbei zeigt Fig. 1 einen Ablauf der Schritte einer Variante des hier offenbarten Verfahrens.
Detaillierte Beschreibung von Varianten
Die hier vorgestellte Lösung dient zum Erzeugen, Bereitstellen und Weitergeben eines ver- trauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer N betreffenden elektronischen Dokument D. Dazu sind einzelne Entitäten und deren Interaktion miteinander als einzelne Schritte in der Fig. 1 veranschaulicht.
Ein validierter smart contract, der in einem distributed n ledger abgelegt ist, dient dazu, in datenschutzfreundlicher Weise Attribute des Berechtigungsinhabers / Nutzers abzuleiten, ohne Nebeninformationen preiszugeben. Der validierte smart contract verifiziert die offiziel- len Signaturen der Datenelemente / Informationen INFO des Dokuments D und berechnet und generiert neue zertifizierte Datenelemente (Über-/ Unterschreitung einer Altersgrenze, Nationalität, Staatsangehörigkeit, ...), die von einem Dritten durch eine elektronische Anfra- ge bei dem distributed ledger verifiziert werden können. Der smart contract und die Ergeb- nisse seiner Berechnungen sind durch starke Kryptographie geschützt. Damit ist für die ab- geleiteten Daten das gleiche Maß an Sicherheit wie bei den Quelldaten erreichbar. Jeder Dritte, dem Zugriff auf den distributed ledger gewährt wird, kann die Authentizität dieser Berechtigungsnachweise überprüfen.
So kann der Nutzer N Berechtigungsnachweise auf der Grundlage offiziell zertifizierter Be- rechtigungsnachweise generieren. Dabei bleibt die Privatsphäre des Nutzers N so weit wie möglich gewahrt. Die abgeleiteten Berechtigungsnachweise haben bei der hier vorgestellten Lösung das gleiche oder ein ähnliches level ofassurance (loa) wie der zur Generierung ver- wendete Quellberechtigungsnachweis, obwohl sie nicht von einer Behörde oder dergl. er- zeugt wurden. Vielmehr bewirkt der Nutzer N selbst die Generierung der abgeleiteten Be- rechtigungsnachweise durch den smart contract
Die vorliegende Lösung versetzt den Nutzer N in die Lage, sich ein selbstsigniertes Zertifikat ausstellen zu lassen, das den Grad der Sicherheit der ursprünglichen Daten beibehält oder demgegenüber nicht wesentlich schwächer ist. Dabei wird die Erzeugung und Anhäufung von Metadaten vermieden. So ist auch nicht nachvollziehbar, wer wann welche Daten ange- fordert hat, etc. Hierzu dient auch eine hier vorgestellte digitale wallet mit offiziell signierten Zertifikaten. Die Lösung berechnet und leitet signierte Zertifikate als Ergebnis der Berechnungen eines smart contract ab, die in einem distributed ledger gespeichert und (auch öffentlich) verfügbar sind. Der distributed ledger ist in hier vorgestellten Varianten eine erlaubnisbasierte öffent- liche blockchain. Andere Varianten, mit denen die hier vorgestellte Lösung ebenfalls zu reali- sieren ist, sind eine erlaubnisbasierte private blockchain oder eine erlaubnislose öffentliche blockchain.
Der distributed ledger macht den smart contract SC für jede vertrauende Partei transparent und erlaubt die Validierung des smart contract SC und der in ihm enthaltenen Berechnungs- anweisungen selbst. Mit Hilfe von Validierungsschemata kann die Herkunft der zugrunde lie- genden Zertifikate nachgewiesen werden. Damit bleibt der loa erhalten, ohne dass das zu- grundeliegende Datenelement aus zum Beispiel einem E-Pass des Nutzers N offengelegt wird. Zur Beantwortung einer gestellten Anfrage (z.B.: ist der Nutzer volljährig? "istVolljäh- rig()") wird einer Berechnung mit dem smart contract SC ein zertifiziertes Datenelement, in diesem Beispiel das Geburtsdatum des Nutzers N verwendet. Die Fig. 1 veranschaulicht die- sen Ablauf. Der smart contract SC kann von vertrauenden Parteien unter Verwendung der Blockchain-Funktionalität auf weitere Eigenschaften wie "istVerheiratet()", "istÜber24()", "istEuropäer()", "istKrankenversichert()" usw. erweitert werden.
Aus dem Vertrauen, das die distributed Berechnung (und die (starke) Verschlüsselung) bie- ten, ergibt sich die loa. Das hashing des smart contract und dessen Speicherung im distribu- ted n ledger garantiert, den loa, solange mehr als die Hälfte der miner unabhängig ist. Der smart contract garantiert, dass der berechnete Wert genau zu der Berechnungsanweisung des smart contract gehört, und dass die Validierung des smart contract und des proof zu- verlässig sind.
Das Ergebnis der Berechnung wird zu einem neuem proof mit einer Zertifizierung aus dem blockchain-Netzwerk. Das Zertifikat kann der Nutzer N in der wallet speichern und später bei Anforderung verwenden. Der einmal generierte proof kann mehrfach gezeigt werden. Der proof selbst enthält eine mit einem Zeitstempel versehene Zertifizierung. So kann die In- stanz, der der proof vorgelegt wird, den Berechtigungsnachweis entsprechend bewerten.
Ausgangspunkt ist, dass der Nutzer N von einer Vertrauen genießenden Instanz Certificate Authority zum Beispiel einer offiziellen Behörde (Regierung) identifiziert (i) mit einem ID- Dokument, (ii) einem Ausweis/einer Urkunde (Reisepass, Personalausweis), oder (iii) mit biometrischen Daten. Alternativ oder kumulativ verfügt der Nutzer N über ein digital signier- tes Zertifikat der Instanz Certificate Authority in einem elD-Dokument oder in einer autori- sierten Datenbank. Alternativ oder kumulativ verfügt der Nutzer N über ein digital signiertes Zertifikat in einer digitalen wallet als mobile ID in seinem smart phone oder als Software- wallet in einem Rechner. Das digital signierte Zertifikat ist für den Benutzer zur Weiterverar- beitung zugänglich.
Als Beispiel sei vorgesehen, dass der Nutzer N ein Objekt Obj mieten möchte. Dazu stellt der Nutzer N eine Anfrage an den Inhaber des Objekts Obj auf elektronischem Weg, z.B. mit seinem smart phone oder drahtlos oder drahtgebunden. (Fig. 1, Schritt 1)
Als Antwort erhält der Nutzer N auf elektronischem Weg, dass er zum Mieten des Objekt Obj belegen muss, die Beschränkung RE zu erfüllen, 24 oder älter zu sein. (Fig. 1, Schritt 2)
Um diesen Beleg zu erbringen, verbindet sich der Nutzer N auf elektronischem Weg mit ei- ner biockchain BC und liefert der biockchain BC sein Geburtsdatum und seine Pass-ID inklu- sive offizieller Unterschriften ein. (Fig. 1, Schritt 3)
Die biockchain BC umfasst einen smart contract SC. Dieser smart contract SC prüft die Si- gnaturen und berechnet den proof. Der proof wird von der biockchain BC mithilfe einer ver- teilten kryptografischen Funktion signiert. (Fig. 1, Schritte 4 - 8)
Der signierte proof wird an den Nutzer N zurückgeschickt. Der Nutzer N legt den proof zur weiteren Verwendung in seine wallet. Die wallet kann so konfiguriert sein, dass der proof automatisch an die Instanz weitergeleitet wird, die den Nachweis angefordert hat, hier das Objekt Obj. (Fig. 1, Schritt 9)
Der proof wird entweder automatisch oder manuell von dem Nutzer N an die Instanz wei- tergeleitet, die den Nachweis angefordert hat. Die Instanz kann nun die Signatur des proof prüfen und über die Zugangsentscheidung befinden. (Fig. 1, Schritte 10 - 16)
Der Ablauf im Einzelnen ist wie folgt:
Im Schritt 1 erfolgt durch den Nutzer N auf elektronischem Weg ein Zugriff auf ein Objekt Obj, das durche eine Einschränkung RE geschützt ist. Das Objekt Obj kann ein Mietvertrag für eine Wohnung sein. Die Einschränkung RE besteht darin, dass der Mieter 24 Jahre alt oder älter sein muss.
Im Schritt 2 teilt das Objekt Obj dem Nutzer N auf elektronischem Weg dass er einen Nach- weis zu erbringen hat, dass der Mieter 24 der Wohnung Jahre alt oder älter sein muss. Im Schritt 3 kontaktiert der Nutzer N einen distributed ledger DL. Dieser distributed ledger DL umfasst eine blockchain BC. Diese biockchain BC enthält einen smart contract "Over23 proof". So kann der Nutzer N einen Beleg dafür erzeugen (lassen), dass er die Einschrän- kung RE erfüllt, 24 Jahre alt oder älter zu sein, ohne dabei sein Geburtdatum (Tag, Monat, Jahr) gegenüber dem Vermieter offenlegen zu müssen.
Im Schritt 4 fordert der smart contract SC den öffentlichen Schlüssel public key des Unter- zeichners des Dokuments D (der Zertifizierungsstelle CA) an, um die Authentizität zu prüfen. Der smart contract SC erhält den öffentlichen Schlüssel public key in der Regel aus einer Austauschplattform PKD public key directory der der Zertifizierungsstelle CA Teilnehmer le- gen ihre öffentlichen Schlüssel public keys dort ab, damit mit diesen öffentlichen Schlüsseln public key Nachrichten an sie verschlüsselt werden können. Das Entschlüsseln ist nur beim Empfänger mit dessen privatem Schlüssel private key möglich. Mit diesem Mechanismus las- sen sich auch so genannte digitale Signaturen erzeugen, wobei hier eine Signatur mit sei- nem private key erzeugt und mit dem zugehörigen öffentlichen Schlüssel überprüft wird.
Diese Signaturen belegen, ob eine Nachricht vom angegebenen Absender stammt oder ob sie von einer unbefugten Person verändert wurde: ob also beispielsweise Daten von der je- weiligen Behörde auf einen elektronischen Pass geschrieben wurden oder ob sie manipuliert sind.
Eine digitale Signatur basiert auf einer asymmetrischen Verschlüsselung, bei der ein Sender mit Hilfe seines private key zw einer digitalen Nachricht einen Wert errechnet, der digitale Signatur genannt wird. Mit diesem Wert und dem public key können Dritte die nicht abstreit- bare Urheberschaft und Integrität der Nachricht prüfen. Um eine mit einem Signaturschlüs- sel erstellte Signatur einer Person zuordnen zu können, muss der public key dieser Person zweifelsfrei zugeordnet sein. Aus der zu signierenden digitalen Nachricht und dem private key wird durch eine eindeutige Rechenvorschrift die Signatur berechnet. Unterschiedliche digitale Nachrichten müssen dabei mit an Sicherheit grenzender Wahrscheinlichkeit zu einer anderen Signatur führen, und die Signatur muss für jeden Schlüssel einen anderen Wert ergeben. Bei einer digitalen Signatur wird der private key in der Regel nicht direkt auf die Nachricht angewendet, sondern auf deren Hash-Wert, der mittels einer Hashfunktion (wie z. B. SHA-2, SHA-3 oder dergl.) aus der Nachricht berechnet wird. Soweit der public key mit- tels eines digitalen Zertifikats einer Person zugeordnet wurde, kann, da es nur einen zum public key korrespondierenden private key gibt, über das öffentliche Verzeichnis des Zertifi- zierungsdiensteanbieters die Identität des Signaturerstellers ermittelt und überprüft werden. Die Gesamtheit der technischen Infrastruktur, mit der die Zertifikate und Informationen zu ihrer Gültigkeit erzeugt und öffentlich bereitgestellt werden, wird als PKI (Public Key Infra- structure) bezeichnet.
Dabei ist die Authentizität des Absenders wesentlich - also der Nachweis, dass ein Heraus- geber eines öffentlichen Schlüssels auch tatsächlich der ist, der er vorgibt zu sein. Die Pub- lic-Key-Infrastruktur PKI ermöglicht, die Vertrauenswürdigkeit eines öffentlichen Schlüssels sicherzustellen, indem dieser aus einem vertrauenswürdigen Schlüsselverzeichnis bezogen wird. In der Austauschplattform public key directory können Aussteller von Dokumenten ihre öffentlichen Schlüssel publizieren, die zur Verifikation notwendig sind. Von der Plattform kann der smart contract SC dann den öffentlichen Schlüssel public key beziehen.
Im Schritt 5 wird der öffentliche Schlüssel public key dem smart contract SC übermittelt.
Im Schritt 6 prüft der smart contract SC die Unterschrift der Zertifizierungsstelle CA unter dem Dokument D. Falls die Signatur gültig ist, werden die nächsten Schritte ausgeführt. Wenn nicht, bricht die Ausführung hier ab.
Im Schritt 7 erfolgt die Altersprüfung basierend auf der Berechnungsvorschrift in dem smart contract SC und der Angabe des Geburtsdatums in dem Dokument D, dessen Richtigkeit und Vertrauenswürdigkeit durch die Verschlüsselung mit dem öffentlichen Schlüssel public key und die Authentizität des Dokuments aus der Zertifizierungsstelle CA belegt ist. Die Informa- tion INFO gelangt aus dem Dokument D von der Zertifizierungsstelle CA zu dem smart con- tract SC in der nachstehend dargestellten Weise. Hierbei werden die erforderlichen Daten dem smart contract SC direkt zur Verfügung gestellt. Das zuständige public key directory PKD ist vorher in dem smart contract SC eingetragen. In einer weiteren Variante hat das Dokument D bereits die notwendigen Zertifikate. Dies erübrigt weitere Dienste. Dem smart contract SC vorangeschaltet kann eine Dictionary-Funktionalität sitzen, die dem Nutzer Aus- kunft gibt, welcher smart contract SC für seine Anfrage am geeignetsten sein könnte.
Pseudo Code zum Erzeugen eines neuen Zertifikates
// Das Datum wird signiert, das Zertifikat dazu wird mitgegeben
// Im Zertifikat sind der Herausgeber und die Gültigkeitsdauer des Zertifikats angegeben.
// Das Datum im Zertifikat entspricht den Angaben in der machine readable zone, MRZ, eines Passes // oder ID Karte, deren hash in dem document security object, SOD des Passes oder ID-Karte signiert // abgelegt ist. let DG1 = ["IDD< < 1234567897< < <<<<<<<<<<<<<",
"9701218F2026031D<<<<<<<<<< <<<()",
"MARTINA< <<SPECIMEN<< <<<<<<<<<<"]; let SOD = [ hashDGl = "596BAE8E7BA9F4D6FC9A468251B3B08A", // MD5 hash als Bsp.
... // weitere hashes weiterer Datengruppen sodSignatur = "SidcJvN0zGHGaTtmcmuUVIS6BGlLf2o9hbFT9ND08T8=", sodCertificat = "The Certificate to prove the signature, optional... "]; let personalData = [DG1, SOD];
// Diese Adresse wird von der BC vergeben und ist unveränderlich const SC_ADDRESS = "ID_OF_THE_SMARTCONTRACT";
// die staatliche CA, falls kein Zertifikat vorhanden ist const govCA = RESPONSIBLE_COUNTRY_CA; var certificate = undefined;
// Hilfskonstante zum Altersvergleich const ticks24years = dockTicksfor24Years();
// Struktur zur Aufnahme des zertifizierten Ergebnisses (analog zu SOD) dass SignedResult = {result, scAddr, signature, certificate};
// Hilfsfunktion zum Prüfen des Zertifikates function boolean checkSignatureOfData(signedData){ if (hasCertificate(signedData) ){ certificate = getCertificateFromData(signedData);
}else( certificate = getCertificateFromPKD(govCA);
) return isValid(signedData, certificate);
} function SignedResult generateSignedResult( result, addr ) {
// es wird im SC ein externer, vertrauenswürdiger Dienst gerufen der das Ergebnis des SC signiert var signature = callTrustedSignatureService(result, addr ); return new SignedResult( result, addr, signature, certificate );
} function SignedResult over23( personalData ) {
// Prüfen der Validität der Signatur if (checkSignatureOfData( personalData ) )
{ var DateOfBirth = extractDoB(personalData); boolean res = ( (now() - DateOfBirth) > ticks24Years );
// optional kann der Zeitstempel mit in das Ergebnis einfließen result = [res, timestamp ]; return generateSignedResult( result, SC_ADDRESS );
}
}
Pseudo-Code zum Validieren des Zertifikates
// Funktion zur Prüfung der Signatur function boolean isSCCertificateVaIid ( scCredential ){ result = scCredential. result; address = scCredential.scAddr;
Signatare = scCredential.signature; cert = scCredential.certificate; return (callTrustedSignatureService(result, address ) == signature);
}
Damit errechnet der smart contract SC auf Basis eines von der Zertifizierungsstelle CA be- reitgestellten Dokuments D, zum Beispiel einem E-Pass-Dokument, genauer gesagt einer in dem Dokument D den Nutzer N betreffenden Information INFO in einem elektronischen For- mat, die Erfüllung der Einschränkung RE durch den Nutzer N. Das Ergebnis dieser Berech- nung ist eine Wahr/Falsch-Angabe. Im vorliegenden Beispiel wird von dem aktuellen Tages- datum (Jahr - Monat - Tag) das Geburtsdatum (Jahr - Monat - Tag) des Nutzers N, wie es aus seinem E-Pass-Dokument D entnehmbar ist, subtrahiert und das Ergebnis mit 23 Jahren verglichen. Wenn das Ergebnis größer ist als 23, wird der smart contract SC ein „Wahr" aus- geben; wenn das Ergebnis kleiner ist als 23, wird der smart contract SC ein „Falsch" ausge- ben. Anstelle dieses Beispiels könnte auch ein smart contract SC mit beliebiger anderer Funktionalität / Prüffähigkeit ausgeführt werden.
Im Schritt 8 erfolgt die Signierung des Ergebnisses. Die Vertrauensbasis dieses Ansatzes ist der distributed ledger DL. Jeder Teilnehmer kann den smart contract SC einsehen und vali- dieren. Ein dedizierter distributed hash zur Erkennung von Manipulationen schützt jeden smart contract SC. Das Ergebnis der Berechnung wird mit einer ID des Nutzers gebündelt. Hierdurch werden die ID des Nutzers N und der Beweis proof mit der ID des smart contract SC, genauer gesagt der Adresse des smart contract SC verknüpft, um die Herkunft des Er- gebnisses der Berechnung zu dokumentieren. Für dieses Tripel <ID, SC-result, SC-hash> er- mittelt dann der distributed ledger DL einen hash-Wert, um die Authentizität des Tripels zu dokumentieren. Das Tripel kann nicht verändert werden, ohne den hash des distributed ledger DL zu zerstören. Der distributed ledger DL -Konsens ist in einer Variante ein "proof- of-work" und in einer anderen Variante ein "proof-of-stake".
Im Schritt 9 wird das Triple <ID, SC-result, SC-hash> als Ergebnis der Berechnung durch den smart contract SC an den Nutzer N auf elektronsichem Weg zurückgesendet. Der Nutzer N kann nun das Ergebnis in seiner wallet speichern.
Im Schritt 10 wird das Ergebnis der Berechnung durch den Nutzer N an das Objekt Obj auf elektronischem Weg gesandt. Dies kann durch den Nutzer manuell ausgelöst erfolgen, oder automatisch, indem das Weiterleiten aufgrund gespeicherter bevorzugter Einstellungen er- folgt, sobald das Ergebnis der Berechnung den Nutzer N auf elektronischem Weg erreicht hat und in seiner wallet gespeichert ist. Im Schritt 11 wird in einer Anfrage zur Verifizierung die Gültigkeit des proof vom Objekt Obj überprüft. Alternativ dazu kann der proof vom Objekt Obj an eine dedizierte Verifizie- rungsinstanz VI zur Verifizierung weitergeleitet werden.
Im Schritt 12 prüft die dedizierte Verifizierungsinstanz VI die Gültigkeit der hashes und der Signatur mittels einer Anfrage an den distributed ledger DL.
Im Schritt 13 erfolgt eine Validierung, indem die Echtheit des Triple <ID, SC-result, SC- hash> und der Triple-Signatur einer Überprüfung unterzogen werden. Dazu vergleicht der distributed ledger DL das übermittelte Tripel und dessen hash-Wert mit den ursprünglich mittels des smart contract SC erzeugten Tripels, und anschließend mittels des distributed ledger DL erzeugten Werten.
Im Schritt 14 kommt das Verifizierungsergebnis aus dem distributed ledger DL. Der distribu- ted ledger DL ist als unabhängige Instanz ausgestaltet, die das Ergebnis liefert. Eine Eigen- schaft des distributed iedger DL ist, dass er online oder offline verfügbar ist, da er auf ver- schiedene Knoten im Netzwerk verteilt ist. So kann die Verifizierung online oder offline mit einer lokalen, gesicherten und zertifizierten Kopie des distributed iedger DL erfolgen. Der di- stributed iedger DL muss jedoch von Zeit zu Zeit online sein, um auf neueste Änderungen des distributed iedger DL aktualisiert zu werden. Der distributed iedger DL ist in der hier ein- gesetzten Variante bevorzugt erlaubnisbasiert.
Im Schritt 15 erfolgt die Entscheidung der Verifizierungsinstanz VI basierend auf dem Veri- fizierungsergebnis. Hierzu generiert die Verifizierungsinstanz VI eine Entscheidung zu den ursprünglich angeforderten Anfrage. Im vorliegenden Beispiel bestätigt oder nicht bestätigt die Verifizierungsinstanz VI die Anfrage, hat der Nutzer ein "Alter-über-23"?
Im Schritt 16 kann der angeforderte Zugriff aus Schritt 1 in Abhängigkeit von der Entschei- dung aus Schritt 15 gewährt werden oder nicht. Beim nächsten Zugriff auf eine Ressource mit derselben Anfrage können die Schritte ab Schritt 9 durchgeführt werden. Voraussetzung ist, dass die ID des Nutzers N nicht geändert wird.
Die einzelnen Schritte sind auch wie folgt in Java-Programmnotation zu beschreiben:
1. Zugriff.beschränktes.Objekt(ID, ObjID)
2. ObjID. nachweis(Alter >23)
3. BerechneAltersnachweisAlter >23(ID, signiertes Dokument)
4. HolePublicKey () 5. SendePublicKey ()
6. Beweisesignatur (PublicKey)
7. BerechneAltersnachweis(Grenze = 23, Geburtsdatum)
8. ErzeugeCryptoSigniertenProof (blockchain Netzwerk)
9. SendeSigniertenAgeproof (signed(wahr/falsch)
10. Weiterleiten (ID, CryptoSignedProof23)
11. Nachfrageverifizierung (ID2, CryptoSignedProof23)
12. Verifizierung (CryptoSignedProof23): wahr/falsch
13. BelegeGültigkeitQ: wahr/falsch
14. VerifizierungsErgebnisQ : wahr/falsch
15. Entscheidung (ID2, ObjID): wahr/falsch
16. ZugangGewährt(ID2, ObjID): wahr/falsch
Ein weiterer Anwendungsfall ist der Nachweis der allgemeinen Hochschulreife, bei der als Nutzer der Inhaber eines Abiturzeugnisses die Qualifikation nachweisen kann, ohne Details der Prüfung, wie Datum, Ort, Note oder sonstige Inhalte des Abiturzeugnisses preiszugeben. Es wird lediglich nachgewiesen, dass der Nutzer über die allgemeine Hochschulreife verfügt, zu der er ein gültiges Zertifikat von dem smart contract SC erhalten hat.
Ein weiterer Anwendungsfall ist die Teilnahme an einem Sozialhilfeprogramm. Der Nutzer N beantragt eine staatliche Leistung und weist nach, dass er dazu berechtigt ist. Dazu lässt der Nutzer N seine inländische Adresse gegen seinen Wohnort in seinem Personalausweis als Wahl-/Fasch -Aussage abprüfen.
Ein weiterer Anwendungsfall ist eine KFZ-Zulassung, bei der der Nutzer N ein Auto anmel- den möchte. Dazu muss er bei der KFZ-Zulassungsstelle seine Anschrift und Steuerinforma- tionen angeben. Die Anschrift wird bei der KFZ-Zulassungsstelle vollständig angegeben. Ein Nachweis über ausstehende Steuern des Nutzers N wird von KFZ-Zulassungsstelle verlangt. Der Nutzer N gibt seine Steueridentifikationsnummer an. Der Nutzer N selbst kontaktiert auf elektronischem Wege einen entsprechend programmierten smart contract SC. Der smart contract SC verbindet sich unter Bezug auf die Steueridentifikationsnummer des Nutzers N mit den Steuerbehörden und erhält die Aussage, dass keine offenen Steuerzahlungen des Nutzers N bestehen. Daraufhin bescheinigt der smart contract SC das Ergebnis, wonach der Nutzer N keine Steuerschulden hat. Der Nutzer N nutzt diesen Nachweis, ohne seine Steuer- identifikationsnummer bei der KFZ-Zulassung preiszugeben.
Ein weiterer Anwendungsfall ist ein Einlagenzertifikat, bei dem der Nutzer N aufgefordert wird, die Verfügbarkeit eines bestimmten Geldbetrags zur Vorbereitung einer Transaktion (Miete/Kauf eines Hauses, Kauf eines Autos usw.) zu beweisen. Der Nutzer N verwendet einen entsprechend programmierten smart contract SC zusammen mit Details seiner Bank- verbindung (Kontoverbindung, Kreditlinie des Girokontos, Bakguthaben) um den erforderli- chen Betrag als verfügbar zu beweisen, ohne die Kontonummer, das Finanzinstitut und an- dere Details preiszugeben.
Ein weiterer Anwendungsfall ist ein Führerscheinnachweis, zu dem der Nutzer N nachweisen muss, dass er zum Fahren berechtigt ist und mindestens 24 Jahre alt ist. Die hier vorgestell- te Verfahrensweise liefert einen Nachweis ohne Offenlegung der sonstigen Details der Fah- rerlaubnis des Nutzers N. Analog kann auch die Berechtigung zum Fahren bestimmter Fahr- zeuge, festgelegt in den Führerscheinklassen ( B, B17, B96, B196, BE, A1, A2, A, AM, C1, C1E, C, CE, D1, D1E, D, DE, L, T) oder Gruppen davon ohne Offenlegung der sonstigen De- tails der Fahrerlaubnis des Nutzers N nachgewiesen werden.
Die vorangehend beschriebenen Varianten der Vorrichtung, deren Aufbau- und Betriebsas- pekte, sowie die Varianten der Verfahrensweise dienen lediglich dem besseren Verständnis der Struktur, der Funktionsweise und der Eigenschaften; sie schränken die Offenbarung nicht etwa auf die Ausführungsbeispiele ein. Die Fig. sind teilweise schematisch. Dabei sind wesentliche Eigenschaften und Effekte zum Teil deutlich vergrößert dargestellt, um die Funktionen, Wirkprinzipien, technischen Ausgestaltungen und Merkmale zu verdeutlichen.
Dabei kann jede Funktionsweise, jedes Prinzip, jede technische Ausgestaltung und jedes Merkmal, welches/welche in den Fig. oder im Text offenbart ist/sind, mit allen Ansprüchen, jedem Merkmal im Text und in den anderen Fig., anderen Funktionsweisen, Prinzipien, tech- nischen Ausgestaltungen und Merkmalen, die in dieser Offenbarung enthalten sind oder sich daraus ergeben, frei und beliebig kombiniert werden, so dass alle denkbaren Kombinationen der beschriebenen Vorgehensweise zuzuordnen sind. Dabei sind auch Kombinationen zwi- schen allen einzelnen Ausführungen im Text, das heißt in jedem Abschnitt der Beschreibung, in den Ansprüchen und auch Kombinationen zwischen verschiedenen Varianten im Text, in den Ansprüchen und in den Fig. umfasst. Auch die Ansprüche limitieren nicht die Offenba- rung und damit die Kombinationsmöglichkeiten aller aufgezeigten Merkmale untereinander. Alle offenbarten Merkmale sind explizit auch einzeln und in Kombination mit allen anderen Merkmalen hier offenbart.

Claims

Patentansprüche
1. Verfahren zum Erzeugen, Bereitstellen und Austauschen eines vertrauenswürdigen elek- tronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer (N) betreffenden elektronischen Dokument (D), mit den Schritten:
• Kontaktieren einer in einem Netzwerk (NW) gehaltenen blockchain (BC) durch den Nutzer (N) auf elektronischem Weg, wobei die blockchain (BC) einen smart con- tract (SC) enthält, der zur Prüfung eingerichtet und dazu programmiert ist, ob ein von einer Zertifizierungsstelle (CA) bereitgestelltes Dokument (D), das eine den Nutzer (N) betreffende Information (INFO) in einem elektronischen Format umfasst, die Er- füllung einer Einschränkung (RE) durch den Nutzer (N) belegt;
• Prüfen der Erfüllung der Einschränkung (RE) mittels des smart contracts (SC);
• Berechnen, in Abhängigkeit vom Ergebnis des Prüfens der Erfüllung der Ein- schränkung (RE), eines proof (P) mittels des smart contract (SC), und Erzeugen ei- nes Zertifikates des proof (P) mittels des smart contract (SC) unter Verwendung ei- ner kryptografischen Funktion; und
• Versenden des Zertifikates des proof (P) und des proof (P) durch den smart contract (SC) an den Nutzer (N).
2. Verfahren nach Anspruch 1, weiter umfassend, vor dem Kontaktieren der in dem Netzwerk (NW) gehaltenen blockchain (BC), ein
• Einleiten einer Interaktion mit einem Objekt (Obj) durch den Nutzer (N); und/oder ein
• Mitteilen der Einschränkung (RE) der Interaktion durch das Objekt (Obj) an den Nutzer (N), wobei die Nicht-/Erfüllung der Einschränkung (RE) durch den Nutzer (N) anhand des Dokuments (D) zu belegen ist.
3. Verfahren nach Anspruch 1 oder 2, weiter umfassend, nach dem Versenden des Zertifika- tes des proof (P) und/oder -des proof (P) durch den smart contract (SC) an den Nutzer (N), ein
• Versenden des erhaltenen Zertifikates des proof (P) und/oder proof (P) durch eine durch den den Nutzer (N) einzuleitende Aktion an die weitere Person (3P);
• Prüfen des hash-Wertes des proof (P) durch das Objekt (Obj); und
• Bewirken, abhängig vom Ergebnis des Prüfens, einer Ausführung oder Verwei- gerung der durch den Nutzer (N) eingeleiteten Interaktion durch das Objekt (Obj).
4. Verfahren nach Anspruch 1, 2 oder 3, wobei das Bereitstellen des Dokuments ein solches Dokument (D) umfasst, bei dem zumindest den Nutzer (N) betreffende Information (INFO) in dem elektronischen Format zertifiziert, signiert, und/oder authentifiziert sind.
5. Verfahren nach einem der Ansprüche 1 bis 4, wobei das Kontaktieren der blockchain (BC) ein Übermitteln von Angaben durch den Nutzer mittels einer elektronischen Datenkommuni- kation
• zur Identifizierung des Nutzers (N);
• zu dem Dokument (D);
• zu dem zur Prüfung der Einschränkung zu verwendenden smart contract (SC); und/oder
• zu der Einschränkung; über ein Netzwerk (NW) an die blockchain (BC) umfasst.
6. Verfahren nach einem der Ansprüche 1 bis 5, wobei der Nutzer (N) zum Prüfen der Erfüllung der Einschränkung (RE) mittels des smart contract (SC),
• dem smart contract (SC) zumindest teilweise das Dokument (D); und/oder
• dem smart contract (SC) Zugangsdaten zu zumindest einem Teil des Doku- ments (D); über das Netzwerk (NW) an die blockchain (BC) sendet.
7. Verfahren nach einem der Ansprüche 1 bis 6, wobei zum Prüfen der Erfüllung / Nicht-Er- füllung der Einschränkung (RE) der smart contract (SC) programmiert und dazu eingerichtet ist, einen Programmcode oder ein Skript mit Anweisungen zum
• Prüfen wenigstens eines Zertifikats, einer Signatur und/oder einer Authentifi- zierung des Dokuments (D);
• Berechnen des proof (P) basierend auf dem Ergebnis der Prüfung des wenig- stens einen Zertifikats, der wenigstens einen Signatur und/oder der wenigstens einer Authentifizierung des Dokuments (D); und/oder
• Signieren des proof { P) mittels einer kryptografischen Funktion durch Erzeugen eines digitalen Zertifikates des proof ( P); auszuführen.
8. Verfahren nach einem der Ansprüche 1 bis 7, wobei das Versenden des Zertifikates des proof (P) durch die blockchain (BC) an den Nutzer (N) ein Übermitteln des Zertifikates des proof (P) mittels einer elektronischen Datenkommunikation über das Netzwerk (NW) um- fasst, um • das Zertifikat des proof ( P) in einer in einem Portablen Gerät (PG) oder einer stationären Rechnerresouce des Nutzers (N) gehaltenen wallet (W) abzuspeichern, so dass dieser für den Nutzer (N) zur weiteren Bearbeitung zugänglich ist; und/oder
• das Zertifikat des proof( P) mit oder ohne vorheriges Abspeichern in der wallet (W) von dem portablen Gerät (PG) oder der stationären Rechnerresouce des Nutzers (N) ohne eine Aktion des Nutzers (N) über das Netzwerk (NW) an die weitere Person (3P) zu versenden.
9. Verfahren nach einem der Ansprüche 1 bis 8, wobei das Bereitstellen des Dokuments ein solches Dokument (D) umfasst, bei dem
• zumindest den Nutzer (N) betreffende Information (INFO) unter Verwendung eines vorzugsweise biometrischen ID-Dokuments von einer offiziellen Behörde oder eines trusted partner (TP) in dem elektronischen Format zertifiziert, signiert, und/ oder authentifiziert sind, und/oder
• zumindest den Nutzer (N) betreffende Information (INFO) in einem elektroni- schen Identitätsnachweis und/oder einem elD-Server mit funktionaler elD- Schnittstelle für externe Zugriffe gespeichert sind.
10. Verfahren nach einem der Ansprüche 1 bis 9, bei dem
• der smart contract (SC) in der blockchain (BC) dazu programmiert und einge- richtet ist, auf die den Nutzer (N) betreffende Information (INFO) in dem elektro- nischen Identitätsnachweis und/oder dem elD-Server zur Prüfung der Einschrän- kung zuzugreifen, und/oder
• die den Nutzer (N) betreffende Information (INFO) als mobile ID in seiner wallet (N) durch den Nutzer (N) bereitgehalten wird zur Versendung über das Netzwerk (NW) an den smart contract (SC) in der blockchain (BC).
11. Verfahren nach einem der Ansprüche 1 bis 10, wobei
• als smart contract (SC) ein durch miner (M) in Knoten des Netzwerks (NW) validierter smart contract (SC) eingesetzt wird, der programmiert und dazu eingerichtet ist, in dem Dokument den Nutzer (N) betreffende Information (INFO) mit der an den smart contract (SC) übermittelten Einschränkung (RE) auf deren Erfüllung / Nicht-Erfüllung hin zu vergleichen; und/oder wobei
• der smart contract (SC) programmiert und dazu eingerichtet ist, ein Vorliegen / Nicht-Vorliegen der Erfüllung / Nicht-Erfüllung der Einschränkung (RE) nach dem Berechnen des proof (P) durch den smart contract (SC), und dem Erzeugen des Zer- tifikates des proof (P) durch den smart contract (SC) mithilfe der kryptografischen Funktion an den Nutzer (N) zu versenden; und/oder wobei • der smart contract (SC) programmiert und dazu eingerichtet ist, mittels an den smart contract (SC) gesendeter Angaben hinsichtlich des Umfangs festlegbare weitere Informationen aus dem Dokument überträgt.
12. Verfahren nach einem der Ansprüche 1 bis 11, wobei der smart contract (SC) pro- grammiert und dazu eingerichtet ist,
• für die den Nutzer betreffende Information (INFO), und soweit hinsichtlich des Umfangs festgelegt, weitere Informationen aus dem Dokument, zu zertifizieren, zu signieren, und/oder zu authentifizieren, und/oder
• neue zertifizierte, signierte, und/oder authentifizierte Datenelemente zu erzeu- gen, die durch Dritte durch unabhängigen Zugriff auf den smart contract (SC) in der blockchain (BC) vollständig verifizierbar und hinsichtlich der Authentizität der Daten- elemente überprüfbar sind.
13. Verfahren nach einem der Ansprüche 1 bis 12, wobei der smart contract programmiert und dazu eingerichtet ist,
• das Vorliegen / Nicht-Vorliegen der Erfüllung / Nicht-Erfüllung der Einschrän- kung (RE) durch den Nutzer (N) in einer Form an den Nutzer (N) zu senden, die das gleiche Maß an Vertrauenswürdigkeit - level of assurance (loa) - aufweist wie das zum Prüfen der Erfüllung der Einschränkung (RE) mittels des smart contract (SC) verwendete Dokument; und/oder
• der Nutzer (N) das Berechnen des proof (P) durch den smart contract (SC), das Erzeugen des Zertifikates des proof (P) durch den smart contract (SC) mithilfe einer kryptografischen Funktion, und/oder das Versenden des Zertifikates des proof (P) durch den smart contract (SC) an den Nutzer (N) selbst initiiert.
14. Verfahren nach einem der Ansprüche 1 bis 13, wobei
• als kryptografische Funktion eine public-key-Kryptographie / digitale Signatu- ren und/ oder kryptographische hash-Funktionen eingesetzt werden; und/oder wobei
• zur public-key-Kryptographie ein durch eine Rechenvorschrift mathematisch miteinander verbundenes Schlüsselpaar mit einem private key und einem public key erzeugt wird; und/oder wobei
• das Berechnen eines proof (P) durch den smart contract (SC), und Erzeugen eines Zertifikates des proof (P) durch den smart contract (SC) mithilfe des Schlüssel- paars erfolgt; und/oder wobei
• das Schlüsselpaar zur Erstellung einer digitalen Signatur verwendet wird, in- dem der Nutzer (N) die transaction mit seinem private key versieht, und die so ent- standene signierte Nachricht an den smart contract (SC) sendet; und/oder wobei • der smart contract (SC) eingerichtet und dazu programmiert ist, vor dem Ver- senden des Zertifikates des proof (P) diesen mit der digitalen Signatur zu signieren;
• der smart contract (SC) eingerichtet und dazu programmiert ist, die transac- tion mit dem public key des Nutzers (N) zu prüfen und somit die Authentizität der transaction, sofern die beiden Schlüssel korrespondieren, zu verifizieren; und/oder wobei
• nach dem Signieren der transaction durch den smart contract (SC) die trans- action auf inhaltliche Integrität durch den Nutzer (N) und/oder die dritte Person zu prüfen ist.
15. Verfahren nach einem der Ansprüche 1 bis 14, wobei der smart contract (SC) eingerich- tet und dazu programmiert ist, das Erzeugen des Zertifikates des proof (P) mit einer krypto- graphischen Signatur-Funktion auszuführen, wobei aus dem proof (P), der eine Zeichenfolge beliebiger Länge ist, eine Zeichenfolge fixer Länge erzeugt wird, wobei die Signatur- oder hash-Funktion deterministisch ist, ausgehend von dem erzeugten Signatur- oder hash-Wert der ursprüngliche proof nicht, insbesondere nicht mit vertretbarem Aufwand, zu bestimmen ist, und es nicht, insbesondere nicht mit vertretbarem Aufwand, möglich ist, einen zweiten, anderen proof zu finden, der die gleiche Signatur des proof ergibt, und es nicht, insbeson- dere nicht mit vertretbarem Aufwand, möglich ist, zwei unterschiedliche proofs zu finden, die dieselbe Signatur des proof ergeben.
16. Verfahren nach einem der Ansprüche 1 bis 15, wobei die den smart contract (SC) enthal- tende biockchain (BC) als erlaubnisbasierte öffentliche biockchain, als eine erlaubnisbasierte private biockchain oder als eine erlaubnisfreie öffentliche biockchain in einem distributed iedger (DI) implementiert ist.
17. Portables Gerät, das dazu eingerichtet ist, eine Logik in Hard- und/oder Software auszu- führen, in der das Verfahren nach einem der vorstehenden Ansprüche 1 - 16 implementiert ist, und wobei die Logik dazu eingerichtet ist, einen oder mehrere der Verfahrensschritte nach einem der vorstehenden Ansprüche 1 - 16 entweder mit Ressourcen des portablen Ge- räts auszuführen, oder über ein Netzwerk mit entfernten Ressourcen zur Ausführung eines oder mehrerer der Verfahrensschritte zu kommunizieren, wobei insbesondere in dem portab- len Gerät vom Nutzer auszulösende oder auszuführende Verfahrensschritte der Logik dazu dienen, den Nutzer, seine Daten oder deren Teile zu authentifizieren, zu verifizieren und ei- nem Dritten zu präsentieren, und weitere Verfahrensschritte der Logik dezentral als doud computing und/oder in Knoten des Netzwerks, insbesondere auch in als miner wirkenden Knoten implementiert sind.
18. Wallet, implementiert als Datenbank in einem portablen Gerät, das dazu eingerichtet ist, eine Logik in Hard- und/oder Software auszuführen, in der das Verfahren nach einem der vorstehenden Ansprüche 1 - 17 implementiert ist, und wobei die Logik dazu eingerichtet ist, einen oder mehrere der Verfahrensschritte nach einem der vorstehenden Ansprüche 1 - 17 entweder mit Ressourcen des portablen Geräts auszuführen, oder über ein Netzwerk mit ent- fernten Ressourcen zur Ausführung eines oder mehrerer der Verfahrensschritte zu kommuni- zieren, wobei insbesondere in dem portablen Gerät ein Speicher vorgesehen ist, zur Speiche- rung des Zertifikates des proof (P), der durch die bbckchain (BC) an den Nutzer (N) mittels elektronischen Datenkommunikation über das Netzwerk (NW) übermittelt wurde, wobei das portable Gerät programmiert und dazu eingerichtet ist, in der wallet die Speicherung und/ oder Weiterversendung des Zertifikates des proof (P) mittels über eine Nutzeroberfläche einzugebender Befehle zu bewirken, und/oder das Zertifikat des proof ( P) mit vorherigem Abspeichern in der wallet (W) von dem portablen Gerät (PG) des Nutzers (N) ohne eine Ak- tion des Nutzers (N) über das Netzwerk (NW) an die weitere Person (3P) zu versenden; und/ oder die den Nutzer (N) betreffende Information (INFO) als mobile ID in seiner wallet (W) für den Nutzer (N) bereitzuhalten zur Versendung über das Netzwerk (NW) an den smart contract (SC) in der blockchain (BC).
19. Bbckchain (BC) zum Erzeugen, Bereitstellen und Austauschen eines vertrauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer (N) betreffen- den elektronischen Dokument (D), die in einem Netzwerk (NW) gehalten ist und einen smart contract (SC) enthält, der zur Prüfung eingerichtet und dazu programmiert ist, ob ein von ei- ner Zertifizierungsstelle (CA) bereitgestelltes Dokument (D), das eine den Nutzer (N) betref- fende Information (INFO) in einem elektronischen Format umfasst, die Erfüllung einer Ein- schränkung (RE) durch den Nutzer (N) belegt, wobei der smart contract (SC) dazu eingerich- tet und programmiert ist, (i) das Prüfen der Erfüllung der Einschränkung (RE) auszuführen, (ii) zu Berechnen, in Abhängigkeit vom Ergebnis des Prüfens der Erfüllung der Einschränkung (RE), eines proof (P), (iii) zu Erzeugen eines Zertifikates des proof (P) unter Verwendung einer kryptografischen Funktion; und (iv) Versenden des Zertifikates des proof (P) und des proof (P) an den Nutzer (N).
20. In einem computerlesbaren Speichermedium auf einer oder mehreren Rechnerressour- cen in einem Netzwerk (NW) abgelegtes Computerprogramm oder Skript in einer Realisie- rung als bbckchain (BC), das durch mindestens einen miner geprüft ist, und das eingerichtet und programmiert ist, zum Erzeugen, Bereitstellen und Austauschen eines vertrauenswürdi- gen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer (N) be- treffenden elektronischen Dokument (D), und einen smart contract (SC) enthält, der zur Prü- fung eingerichtet und dazu programmiert ist, ob ein von einer Zertifizierungsstelle (CA) be- reitgestelltes Dokument (D), das eine den Nutzer (N) betreffende Information (INFO) in ei- nem elektronischen Format umfasst, die Erfüllung einer Einschränkung (RE) durch den Nut- zer (N) belegt, wobei der smart contract (SC) dazu eingerichtet und programmiert ist, (i) das Prüfen der Erfüllung der Einschränkung (RE) auszuführen, (ii) zu Berechnen, in Abhängigkeit vom Ergebnis des Prüfens der Erfüllung der Einschränkung (RE), eines proof (P), (iii) zu Er- zeugen eines Zertifikates des proof (P) unter Verwendung einer kryptografischen Funktion; und (iv) Versenden des Zertifikates des proof (P) und des proof (P) an den Nutzer (N).
PCT/EP2022/055884 2021-03-25 2022-03-08 Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument WO2022200035A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22713881.5A EP4315117A1 (de) 2021-03-25 2022-03-08 Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
CN202280031405.4A CN117280346A (zh) 2021-03-25 2022-03-08 用于生成、提供和转发基于与用户相关的电子文件的可信电子数据集或证书的方法和装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021107512.2A DE102021107512A1 (de) 2021-03-25 2021-03-25 Verfahren und Vorrichtung zum Erzeugen, Bereitstellen und Weitergeben eines vertrauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer betreffenden elektronischen Dokument
DE102021107512.2 2021-03-25

Publications (1)

Publication Number Publication Date
WO2022200035A1 true WO2022200035A1 (de) 2022-09-29

Family

ID=80999433

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/055884 WO2022200035A1 (de) 2021-03-25 2022-03-08 Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument

Country Status (4)

Country Link
EP (1) EP4315117A1 (de)
CN (1) CN117280346A (de)
DE (1) DE102021107512A1 (de)
WO (1) WO2022200035A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117408846A (zh) * 2023-12-14 2024-01-16 陕西华海信息技术有限公司 一种基于云计算的学校教务数据处理系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020023460A1 (en) * 2018-07-23 2020-01-30 Cambridge Blockchain, Inc. Systems and methods for secure custodial service

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3023325A1 (en) 2017-11-07 2019-05-07 Adepto Enterprises Inc System and method for dynamic financial management
US11080240B2 (en) 2019-09-12 2021-08-03 Vijay Madisetti Method and system for real-time collaboration and annotation-based action creation and management

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020023460A1 (en) * 2018-07-23 2020-01-30 Cambridge Blockchain, Inc. Systems and methods for secure custodial service

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HALPIN HARRY: "Nym Credentials: Privacy-Preserving Decentralized Identity with Blockchains", 2020 CRYPTO VALLEY CONFERENCE ON BLOCKCHAIN TECHNOLOGY (CVCBT), IEEE, 11 June 2020 (2020-06-11), pages 56 - 67, XP033799491, DOI: 10.1109/CVCBT50464.2020.00010 *
LOÏC LESAVRE: "A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems NIST CSWP 01142020", 14 January 2020 (2020-01-14), pages 1 - 62, XP061049168, Retrieved from the Internet <URL:https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01142020.pdf> [retrieved on 20200114], DOI: 10.6028/NIST.CSWP.01142020 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117408846A (zh) * 2023-12-14 2024-01-16 陕西华海信息技术有限公司 一种基于云计算的学校教务数据处理系统
CN117408846B (zh) * 2023-12-14 2024-03-01 陕西华海信息技术有限公司 一种基于云计算的学校教务数据处理系统

Also Published As

Publication number Publication date
CN117280346A (zh) 2023-12-22
DE102021107512A1 (de) 2022-09-29
EP4315117A1 (de) 2024-02-07

Similar Documents

Publication Publication Date Title
DE102017204536B3 (de) Ausstellen virtueller Dokumente in einer Blockchain
Çabuk et al. A survey on feasibility and suitability of blockchain techniques for the e-voting systems
EP2585963B1 (de) Verfahren zur erzeugung eines zertifikats
EP3993318B1 (de) Blockchain-basiertes digitales dokumentensystem
EP3182318B1 (de) Signaturgenerierung durch ein sicherheitstoken
WO2020212337A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten sowie bezahlsystem
EP3114600B1 (de) Sicherheitssystem mit zugriffskontrolle
DE102020104906A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
DE102021122557A1 (de) Konformitätsmechanismen in blockchain-netzwerken
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
DE102018115350A1 (de) Manipulationssicheres Ausstellen und Speichern von elektronischen Urkunden
DE112022000906T5 (de) Trennen von blockchain-daten
WO2022200035A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
EP4254234A1 (de) Ausstellen eines digitalen credentials für eine entität
DE102020004121A1 (de) Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
EP3913886A1 (de) Ausstellen digitaler dokumente mit einer blockchain
DE102020104904A1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
US20240187259A1 (en) Method and apparatus for generating, providing and distributing a trusted electronic record or certificate based on an electronic document relating to a user
DE102021112754A1 (de) Ausstellen eines digitalen verifizierbaren Credentials
EP4177808A1 (de) Selektiv anonymisierende überweisung einer kryptowährung
DE102020004122A1 (de) Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
WO2023202836A1 (de) Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen
DE102021000570A1 (de) Verfahren zum bereitstellen eines nachweisdatensatzes; verfahren zum prüfen eines nachweisdatensatzes; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz

Legal Events

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

Ref document number: 22713881

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 18552173

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2022713881

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 202280031405.4

Country of ref document: CN

ENP Entry into the national phase

Ref document number: 2022713881

Country of ref document: EP

Effective date: 20231025