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.

Applications Claiming Priority (2)

Publications (1)

Family

ID=80999433

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (3)

• 2021
  • 2021-03-25 DE DE102021107512.2A patent/DE102021107512A1/de active Pending
• 2022
  • 2022-03-08 CN CN202280031405.4A patent/CN117280346A/zh active Pending
  • 2022-03-08 EP EP22713881.5A patent/EP4315117A1/de active Pending
  • 2022-03-08 WO PCT/EP2022/055884 patent/WO2022200035A1/de active Application Filing

Also Published As

Similar Documents

Legal Events