WO2023202836A1 - Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen - Google Patents

Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen Download PDF

Info

Publication number
WO2023202836A1
WO2023202836A1 PCT/EP2023/057540 EP2023057540W WO2023202836A1 WO 2023202836 A1 WO2023202836 A1 WO 2023202836A1 EP 2023057540 W EP2023057540 W EP 2023057540W WO 2023202836 A1 WO2023202836 A1 WO 2023202836A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication device
transaction
data communication
payment
user
Prior art date
Application number
PCT/EP2023/057540
Other languages
English (en)
French (fr)
Inventor
Christoph BÖSCH
Sven MARSING
Florian Peters
Original Assignee
Bundesdruckerei Gmbh
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 Bundesdruckerei Gmbh filed Critical Bundesdruckerei Gmbh
Publication of WO2023202836A1 publication Critical patent/WO2023202836A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • 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/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present invention relates to devices, a system and methods for electronic cashless payment.
  • cashless payment instruments are coming to the fore, especially based on electronic payment processing methods.
  • payment methods are transferred without any cash being transferred.
  • cash payments cash, i.e. banknotes or coins, is exchanged between the payer and the payee, whereas in a cashless payment there is no such exchange of cash.
  • Cash has the advantage that it is available to everyone and can be used quickly and anywhere.
  • a bank account is not required for cash-based payment processing.
  • cash is often valued by owners as a store of value.
  • cashless payment methods have the advantage that they enable efficient payment processing, even if the payer and the payee are in distant locations, as is the case, for example, with purchases over the Internet.
  • Cashless electronic payment procedures can also be carried out anonymously, but it may be necessary, for example due to legal regulations, to record the identities of the parties involved, i.e. the payer and the payee, above certain amounts so that they can be tracked.
  • cashless electronic payment methods based on a blockchain, such as Bitcoin such a tracking option is usually not available.
  • a trust service provider in particular a trust center, checks the identity of the payer, the identity of the payer in a database together with a transaction -ID stores and the transaction ID is digitally signed, so that the signed transaction ID is stored by the data communication device on a money ledger.
  • the linking of a transaction to the identity of the payer can be carried out by the trust center if the amount of the transaction exceeds a threshold value.
  • the data communication device can store the transaction without involving the trust center, i.e. the transaction can be carried out completely anonymously.
  • a data communication device for carrying out an electronic payment transaction.
  • the data communication device comprises at least one processor, which is designed to execute a payment application and an ID application, as well as a communication interface, which is designed to communicate with a trust center server arrangement and a money ledger.
  • the payment application is designed to send a transaction ID and a decentralized identity, DID, of a user of the data communication device to a payment agent of the trust center server arrangement.
  • the ID application is designed to send signed user credentials of the user of the data communication device to the ID agent of the trust center server arrangement in response to a request containing the DID from an ID agent of the trust center server arrangement.
  • the payment application is further designed to receive a signature of the transaction ID from the payment agent of the trust center server arrangement and to send the signature of the transaction ID to the Send money ledger to record the electronic payment transaction with the signature of the transaction ID on the money ledger.
  • the payment application is designed to carry out a further electronic payment transaction whose amount is less than a threshold value, to send a further transaction ID of the further electronic payment transaction to the money ledger without a signature of the further transaction ID, in order to record the electronic payment transaction with the additional transaction ID and without a signature of the additional transaction ID on the money ledger.
  • the payment application is further designed to generate the transaction ID and/or to receive the DID of the user of the data communication device from the ID application upon request.
  • the ID application is further designed, in response to the request of the ID agent of the trust center server arrangement, to send zero-knowledge proof data to the ID agent of the trust center server arrangement in order to obtain the signed user credentials of the user of the data communication device.
  • the payment application is further designed to send a further DID of a further user of a further data communication device together with the transaction ID and the DID of the user of the data communication device to the payment agent of the trust center server arrangement.
  • the further user of the further data communication device is the payment recipient.
  • the data communication device is a mobile and portable data communication device, in particular a smartphone.
  • a method for operating a data communication device for executing an electronic payment transaction comprises at least one processor which is designed to execute a payment application and an ID application, and a communication interface which is designed with one Trust center server arrangement and a money ledger to communicate.
  • the procedure includes the following steps:
  • a trust center server arrangement for executing an electronic payment transaction.
  • the trust center server arrangement includes at least a processor that is designed to execute a payment agent and an ID agent, a communication interface that is designed to communicate with a data communication device, and a memory for storing electronic data.
  • the payment agent is designed to receive a transaction ID and a decentralized identity, DID, of a user of the data communication device from a payment application of the data communication device.
  • the ID agent is trained to receive the signed user credentials of the user of the data communication device from an ID application of the data communication device in response to a request from the payment agent containing the DID for user credentials of the user of the data communication device.
  • the payment agent is further trained to receive the user credentials of the user of the data communication device and to store them in the memory together with the transaction ID.
  • the payment agent is further trained to sign the transaction ID and to send the signed transaction ID to the payment application of the data communication device in order to be able to record the electronic payment transaction with the signature of the transaction ID on a money ledger.
  • the communication interface is further designed to communicate with an ID ledger and the ID agent is further designed to receive zero-knowledge proof data from the ID application of the data communication device and use the zero-knowledge proof data. Data and the ID ledger to verify the signed user credentials of the user of the data communication device.
  • a method for operating a trust center server arrangement for executing an electronic payment transaction comprising at least one processor which is designed to execute a payment agent and an ID agent, a communication interface which is designed is to communicate with a data communication device, as well as a memory for storing electronic data.
  • the procedure includes the following steps:
  • a system for carrying out an electronic payment transaction comprising a plurality of data communication devices according to the first aspect and a trust center server arrangement according to the third aspect.
  • FIG. 1 shows a schematic diagram of a system for electronic payment according to an embodiment with a data communication device according to an embodiment and a trust center server arrangement according to an embodiment;
  • FIG. 2 is a signaling diagram illustrating the interaction of the components of the system of FIG. 1 according to one embodiment
  • FIG. 3 is a flowchart illustrating steps of a method for operating a data communication device according to an embodiment
  • FIG. 4 is a flowchart illustrating steps of a method for operating a trust center server arrangement according to an embodiment.
  • a “blockchain” is understood to mean an ordered data structure that includes a large number of data blocks linked together.
  • a blockchain is understood to mean an ordered data structure in which each of the blocks (except the first block) includes a test value, for example a hash value, of its predecessor block and thus the validity of all its predecessor blocks can be checked and, if necessary, confirmed on the basis of each block.
  • a test value for example a hash value
  • the concept of blockchain was described in a white paper on Bitcoin in 2008 under the pseudonym Satoshi Nakamoto ("Bitcoin: Peer-to-Peer Electronic Cash System” (https://bitcoin.org/bitcoin.pdf)).
  • the blockchain described therein consists of a series of data blocks in which one or more entries or transactions are summarized and provided with a checksum in the form of a hash value.
  • additional blocks of the blockchain are created in a computationally intensive process, also known as mining becomes. These additionally generated blocks are then added to the blockchain and distributed via a network to all participants or nodes in the network.
  • Embodiments can have the advantage that the blockchain offers a high degree of security against subsequent manipulation by storing the cryptographic checksum, i.e. hash values, of the previous block in the subsequent block. The chaining of the blocks can then be verified using these root hashes.
  • Each block of the blockchain contains the hash of the entire previous block header in its header. This means that the order of the blocks is clearly defined and a chain structure is created.
  • the blockchain is a blockchain in which only a selected group of participants has permission to add valid blocks.
  • a corresponding authorization can be proven, for example, by means of a signature using a private cryptographic key.
  • the private cryptographic key can belong to an asymmetric key pair, which also includes a public cryptographic key with which the signature can be verified.
  • the asymmetric key pair can also be assigned a certificate, for example, which proves the authorization to create a valid block of the blockchain. This certificate can also be assigned to a PKI, which proves the authenticity of the certificate.
  • a public key can be stored in the blockchain in an initialization entry for further participants who are to be added to the selected group. These public keys can be used to check whether signatures of blocks and thus the corresponding blocks themselves are valid.
  • Public keys of original participants in the selected group can, for example, be stored in a genesis block of the blockchain.
  • the present blockchain managed by the central bank is, for example, a public blockchain which is managed on the central bank's blockchain servers. For example, new blocks are entered exclusively through these blockchain servers managed by the central bank. In this case, for example, computationally intensive processes when adding additional blocks can be eliminated. For example, all that is required to add additional blocks is a signature with a signature key assigned to the central bank.
  • a trust center represents a trustworthy third party that can certify the respective identity of the communication partner in electronic communication processes. For example, in electronic communication in connection with electronic signatures, a trust center can issue certificates that can be used to certify the identity of the communication partners.
  • a “communications interface” or a “communications interface” here is understood to mean, for example, an interface via which data can be received and sent, whereby the communication interface can be configured with contact or contactless.
  • Network here is understood to mean any transmission medium with a connection for communication, in particular a local connection or a local network, in particular a local area network (LAN), a private network, in particular an intranet, and a digital private network (virtual private Network - VPN).
  • LAN local area network
  • VPN virtual private Network - VPN
  • a computer system can have a standard radio interface for connection to a WLAN.
  • it can be a public network, such as the Internet.
  • this connection can also be established via a mobile network.
  • a “processor” is understood to mean a logic circuit that is used to execute program instructions.
  • the logic circuit can be implemented on one or more discrete components, in particular on a chip.
  • a processor includes, for example, an arithmetic unit, a control unit, registers and data lines for communication with other components.
  • a “processor” is understood to mean a microprocessor or a microprocessor system consisting of several processor cores and/or several microprocessors.
  • the processor is configured to execute program instructions stored, for example, in a memory to carry out the operations and methods described herein.
  • a “memory” here is understood to mean, in particular, a non-volatile memory.
  • Non-volatile memory here is understood to mean, for example, an electronic memory for the permanent storage of data.
  • Nonvolatile memory can be configured as non-changeable memory, also known as read-only memory (ROM), or changeable memory, also known as non-volatile memory (NVM).
  • ROM read-only memory
  • NVM non-volatile memory
  • this can be an EEPROM, for example a flash EEPROM, referred to as flash for short.
  • flash flash for short.
  • a non-volatile memory is characterized by the fact that the data stored on it is retained even after the power supply is switched off.
  • a “protected memory area” is understood here to be an area of an electronic memory to which access, i.e. read access or write access, is only possible via a processor of a security element.
  • no external access is possible to the protected memory area, i.e. data can neither be brought in from outside nor output to the outside.
  • data can be read out from the protected memory area via the processor.
  • data can be brought into the protected memory area from outside via the processor.
  • access from or via the processor coupled to the memory is only possible if a necessary condition is met. This can be, for example, a cryptographic condition, in particular a successful authentication and/or a successful authorization check. Such a check can be based, for example, on an electronic signature with a signature key.
  • Asymmetric key pairs are used for a variety of cryptosystems and also play an important role in signing electronic data.
  • An asymmetric key pair consists of a public key, which is used to encrypt and/or decrypt data and may be passed on to third parties, and a private key, which is used to encrypt and/or decrypt data and is usually kept secret must become.
  • the public key allows anyone to encrypt data for the owner of the private key and to verify digital signatures created with the private key.
  • a private key allows its holder to decrypt data encrypted with the public key or create digital signatures. One with A signature created with a private key can be verified with the associated public key.
  • a signature is a cryptographic process in which an additional data value, which is referred to as a “signature”, is calculated for any data.
  • a signature can, for example, be a hash value of the original data encrypted with a private cryptographic key.
  • a security element here is understood to mean, for example, an electronic component which includes a processor and a memory and to which only certain predefined accesses are possible. For example, only certain data values, which are stored in certain areas of the memory, can be read out. For example, data values stored in a protected memory area cannot be read. For example, in order to write a data value into the memory of the security element, a digital signature is necessary, the verification key of which is stored in the security element. For example, only the processor has write permissions to write data to a protected memory area.
  • the security element further provides, for example, cryptographic core routines in the form of cryptographic program instructions with cryptographic algorithms for signature creation and/or verification, key generation, and/or random number generation and can further serve as a secure storage for cryptographic keys.
  • At least parts of the security element are signed. Before using the security element, it is checked whether the signature or signatures are valid. For example, if one of the signatures is not valid, use of the security element will be blocked.
  • the security element has physically restricted access options.
  • the security element can have additional measures against misuse, in particular against unauthorized access to data in the memory of the security element.
  • the means for protecting the security element against unauthorized manipulation include mechanical means, for example The purpose is to prevent the security element or its parts from being opened, or which, if an attempt is made to intervene in the security element, render it unusable, for example by causing data loss.
  • at least parts of the security element can be enclosed, cast and/or laminated in a material, the attempted removal of which leads to the inevitable destruction of the corresponding parts of the security element.
  • Figure 1 shows a system 100 for the traceable implementation of electronic cashless payments between a first data communication device 110 of a paying user 110a and a second data communication device 120 of a payment recipient.
  • the first and/or the second data communication device 110, 120 can each be a mobile and portable data communication device 110, 120, in particular a smartphone 110, 120.
  • the data communication devices 110, 120 are, for example, smartphones 110, 120.
  • the smartphone 110 of the paying user 110a and the smartphone 120 of the payment recipient each include one or more processors 111, 121, a communication interface 113, 123 for wireless and/or wired communication via a communication network and a memory 115, 125 for storing electronic data.
  • the smartphones 110, 120 can each include a security element, for example a virtual or physical SIM card, which is designed to store security-critical data and/or to carry out security-critical operations, in particular cryptographic operations.
  • the processor 111, 121 of the respective smartphone 110, 120 is designed to execute a payment application 111a, 121a and an ID application or ID card application 111b, 121b, whose function and interaction with one another and with the Other components of the system 100 will be described in detail below with further reference to Figure 2.
  • the system 100 includes a trust center
  • the trust center server arrangement 130 can have one or include several servers, with one or more processors 131, a communication interface 133 for wireless and / or wired communication via a communication network and a memory 135 for storing electronic data.
  • the at least one processor 131 of the trust center server arrangement 130 is designed to execute a payment agent 131a (or payment service 131a) and an ID agent 131b (or ID service 131b), the function of which and interaction with each other and with the other components of the system 100 will be described in detail below with further reference to Figure 2.
  • the money ledger 150 can, for example, be implemented on one or more blockchain servers.
  • the blockchain servers can be part of a money ledger network 150 and thus be blockchain nodes of the money ledger 150.
  • the blockchain servers and/or the money ledger 150, i.e. the blockchain network 150 can be managed by a central bank 160, for example. If the central bank 160 is a central bank 160 to which several countries belong, the money ledger 150 can, for example, include one or more blockchain servers per country.
  • Figure 2 illustrates the interaction of the components of the system 100 shown in Figure 1 according to one embodiment.
  • the user 110a who is obliged to pay would like to use his smartphone 110 to pay a certain amount to the payee via his smartphone 120.
  • the user 110a starts the payment application 111a (referred to as “payment app” in FIG. 2) on his smartphone 110.
  • the payment application 111a implemented by the processor 111 first checks the amount of the amount to be paid. If this amount is higher than a threshold value (for example a legally established threshold value), the smartphone 110 carries out the further steps shown in FIG. 2 (step 203 of FIG. 2). Otherwise, that is, if the one to be paid If the amount is not higher than the threshold value, the payment transaction can be carried out without the trust center 130 and recorded on the money ledger 150 in an essentially known manner.
  • a threshold value for example a legally established threshold value
  • the payment application 111a implemented by the processor 111 generates a request in step 205 of Figure 2 and sends it via the communication interface 113 to the trust center 130, in particular the payment agent 131a (identified as “TSE agent” 131a in FIG. 2) of the trust center 130 in order to receive a transaction ID digitally signed by the trust center 130.
  • the payment agent 131a in turn sends a request to the payment application 111a in step 207 of FIG. 2 for the transaction ID and a decentralized ID for the user 110a of the smartphone 110.
  • the transaction ID can be generated by the payment application 111a on the smartphone.
  • the payment application 111a first sends a request to the ID application 111b and receives the decentralized ID (DID; also known in English as a “decentralized identifier”) in response. of the paying user 110a of the smartphone 110.
  • DID decentralized ID
  • step 210 of Figure 2 the payment application 111a of the smartphone 110 sends the DID received from the ID application 111b and the transaction ID to the payment agent 131a of the trust center 130.
  • the payment agent 131a of the trust center 130 sends a request for "user credentials" (or user information) of the user 110a to the ID agent 131b of the trust center 130 in step 211 of Figure 2, the request being from the ID application 111b of the smartphone 110 contains the DID received.
  • the ID agent 131b essentially serves to automatically check identities in the SSI ledger (or ID ledger) 140, which is based on “Distributed Ledger Technology (DLT)”.
  • the ID agent 131b of the trust center 130 sends a request for the user credentials to the ID application 111b of the smartphone 110, that is, for the user information for determining the identity of the user 110a of the smartphone 110 using the SSI ledger 140
  • the request contains the DID originally received from the ID application 111b.
  • the ID application 111b of the smartphone 110 signs the user credentials or user information with a private key of the smartphone 110.
  • a private key can, for example, be stored in a secured memory area of a security element, for example a virtual or physical SIM card. Card of the smartphone 110 must be stored.
  • security-critical cryptographic operations of the ID application 111b and/or payment application 111a can be carried out in such a security element.
  • step 217 the ID application 111b of the smartphone 110 proves the authenticity of the user credentials or user information transmitted in step 215 using a zero-knowledge proof (ZKP).
  • ZKP zero-knowledge proof
  • the ID agent 131b of the trust center 130 After the ZKP has been confirmed by the ID agent 131b of the trust center 130 (due to which the ID agent 131a can trust the user credentials), the ID agent 131b of the trust center 130 sends the user credentials in step 223 of FIG the payment agent 131a.
  • the payment agent 131a then stores the signed transaction ID together with the user credentials in a database 135a implemented in the memory 135 (step 225 of FIG. 2). In one embodiment, the payment agent 131a can assign an identification number for this and link it to the transaction ID.
  • the payment agent 131a of the trust center 130 sends the signed one
  • Step 227 ultimately represents the response of the trust center 130 to the signed transaction ID requested in step 205.
  • the payment application 111a sends the transaction data, i.e. in particular the transaction ID and the amount, as well as the signature of the transaction ID, to the money ledger 150 in step 229 of FIG. 2, where this data is booked or stored in order to be available to the central bank server 160 for follow-up if necessary.
  • the payment process is now complete.
  • the identity of the payment recipient i.e. the user of the additional smartphone 120
  • the payment application 111a can also obtains the DID of the user of the additional smartphone 120.
  • the identity agent 131b of the trust center 130 would establish two separate connections, namely on the one hand to the smartphone 110 of the paying user 110a and on the other hand to the smartphone of the payment recipient.
  • FIG. 3 shows a flowchart which illustrates steps of a method 300 for operating the data communication device 110 according to one embodiment.
  • the method 300 includes the following steps:
  • Figure 4 shows a flowchart illustrating steps of a method 400 for operating the trust center server arrangement 130 according to one embodiment.
  • the method 400 includes the following steps: Receiving 401 a transaction ID and the decentralized identity, DID, of the user 110a of the data communication device 110 from a payment application 111a of the data communication device 110 by the payment agent 131a;

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Die Erfindung betrifft eine Datenkommunikationsvorrichtung (110) zum Ausführen einer elektronischen Bezahltransaktion. Die Datenkommunikationsvorrichtung (110) umfasst wenigstens einen Prozessor (111), der ausgebildet ist, eine Payment-Applikation (111a) und eine ID-Applikation (111b) auszuführen, und ein Kommunikationsinterface (113), das ausgebildet ist, mit einer Trustcenter-Serveranordnung (130) und einem Geld-Ledger (150) zu kommunizieren. Die Payment-Applikation (111a) ist ausgebildet, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) an einen Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) zu senden. Die ID-Applikation (111b) ist ausgebildet, in Reaktion auf eine die DID enthaltende Anfrage eines ID-Agenten (131b) der Trustcenter-Serveranordnung (130), signierte User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) an den ID-Agenten (131b) der Trustcenter- Serveranordnung (130) zu senden. Die Payment-Applikation (111a) ist ferner ausgebildet, eine Signatur der Transaktions-ID von dem Payment-Agenten (131a) der Trustcenter- Serveranordnung (130) zu empfangen und die Signatur der Transaktions-ID an den Geld- Ledger (150) zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger (150) zu verbuchen.

Description

Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen
Die vorliegende Erfindung betrifft Vorrichtungen, ein System und Verfahren zum elektronischen bargeldlosen Bezahlen.
Im Zuge der zunehmenden Digitalisierung rücken heutzutage mehr und mehr bargeldlose Zahlungsinstrumente in den Vordergrund, insbesondere basierend auf elektronischen Verfahren zur Zahlungsabwicklung. Im bargeldlosen Zahlungsverkehr erfolgt ein Transfer von Zahlungsmitteln, ohne dass dabei Bargeld transferiert wird. Bei Barzahlungen wird Bargeld, d.h. Banknoten oder Münzen, zwischen Zahlungspflichtigem und Zahlungsempfänger ausgetauscht, während es bei einer bargeldlosen Zahlung nicht zu einem solchen Austausch von Bargeld kommt.
Bargeld hat beispielsweise den Vorteil, dass es für jedermann verfügbar ist und schnell sowie überall eingesetzt werden kann. So ist beispielsweise für eine bargeldbasierte Zahlungsabwicklung kein Bankkonto erforderlich. Zudem wird Bargeld von den Besitzern oftmals als Wertaufbewahrungsmittel geschätzt. Bargeldlose Zahlungsverfahren haben demgegenüber beispielsweise den Vorteil, dass sie eine effiziente Zahlungsabwicklung ermöglichen, selbst wenn sich Zahlungspflichtiger und Zahlungsempfänger an entfernten Orten aufhalten, wie es beispielsweise bei Einkäufen über das Internet der Fall ist.
Bei Geldtransaktionen mit Bargeld bleibt die Anonymität der beteiligten Parteien im Wesentlichen gewahrt. Bargeldlose elektronische Zahlungsverfahren können ebenfalls anonym durchgeführt werden, es kann jedoch erforderlich sein, beispielsweise aufgrund von gesetzlichen Bestimmungen, die Identitäten der beteiligten Parteien, d.h. des Zahlungspflichtigen und des Zahlungsempfängers, ab bestimmten Beträgen zu erfassen, so dass diese nachverfolgt werden können. Bei bargeldlosen elektronischen Zahlungsverfahren, die auf einer Blockchain basieren, wie beispielweise Bitcoin, ist eine solche Möglichkeit der Nachverfolgung in der Regel nicht gegeben.
Es ist die Aufgabe der vorliegenden Erfindung, ein Konzept zum elektronischen bargeldlosen Bezahlen zu schaffen, welches bei Bedarf eine Nachverfolgung der Identitäten der beteiligten Parteien, d.h. des Zahlungspflichtigen und des Zahlungsempfängers, erlaubt. Diese Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst. Vorteilhafte Ausbildungsformen sind Gegenstand der abhängigen Patentansprüche, der Beschreibung sowie der Figuren.
Die hier beschriebenen erfindungsgemäßen Ausführungsformen beruhen auf der Idee, dass für die Durchführung einer bargeldlosen elektronischen Transaktion mittels einer Datenkommunikationsvorrichtung, beispielsweise eines Smartphones, ein Vertrauensdiensteanbieter, insbesondere ein Trustcenter, die Identität des Zahlungspflichtigen überprüft, die Identität des Zahlungspflichtigen in einer Datenbank zusammen mit einer Transaktions-ID speichert und die Transaktions-ID digital signiert, so dass die signierte Transaktions-ID von der Datenkommunikationsvorrichtung auf einem Geld-Ledger hinterlegt werden. Gemäß einer Ausführungsform kann die Verknüpfung einer Transaktion mir der Identität des Zahlungspflichtigen durch das Trustcenter durchgeführt werden, falls der Betrag der Transaktion einen Schwellenwert übersteigt. Für eine Transaktion, deren Betrag nicht höher als der Schwellenwert ist, kann die Datenkommunikationsvorrichtung die Transaktion ohne Einbeziehung des Trustcenters hinterlegen, d.h. die Transaktion vollkommen anonym durchgeführt werden. Durch die Verknüpfung einer Transaktion mit der Identität des Zahlungspflichtigen durch das Trustcenter kann die Anonymität einer Transaktion auf dem Geld-Ledger gewahrt werden, jedoch bei Bedarf nachverfolgt werden.
Gemäß einem ersten Aspekt wird eine Datenkommunikationsvorrichtung zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt. Dabei umfasst die Datenkommunikationsvorrichtung wenigstens einen Prozessor, der ausgebildet ist, eine Payment-Applikation und eine ID-Applikation auszuführen, sowie ein Kommunikationsinterface, das ausgebildet ist, mit einer Trustcenter-Serveranordnung und einem Geld-Ledger zu kommunizieren. Die Payment-Applikation ist ausgebildet, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers der Datenkommunikationsvorrichtung an einen Payment-Agenten der Trustcenter- Serveranordnung zu senden. Die ID-Applikation ist ausgebildet, in Reaktion auf eine die DID enthaltende Anfrage eines ID-Agenten der Trustcenter-Serveranordnung, signierte User-Credentials des Benutzers der Datenkommunikationsvorrichtung an den ID-Agenten der Trustcenter-Serveranordnung zu senden. Die Payment-Applikation ist ferner ausgebildet, eine Signatur der Transaktions-ID von dem Payment-Agenten der Trustcenter-Serveranordnung zu empfangen und die Signatur der Transaktions-ID an den Geld-Ledger zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger zu verbuchen.
In einer Ausführungsform ist die Payment-Applikation zum Ausführen einer weiteren elektronischen Bezahltransaktion, deren Betrag kleiner als ein Schwellenwert ist, ausgebildet, eine weitere Transaktions-ID der weiteren elektronischen Bezahltransaktion ohne eine Signatur der weiteren Transaktions-ID an den Geld-Ledger zu senden, um die elektronische Bezahltransaktion mit der weiteren Transaktions-ID und ohne eine Signatur der weiteren Transaktions-ID auf dem Geld-Ledger zu verbuchen.
In einer Ausführungsform ist die Payment-Applikation ferner ausgebildet, die Transaktions-ID zu generieren und/oder auf Anfrage die DID des Benutzers der Datenkommunikationsvorrichtung von der ID-Applikation zu erhalten.
In einer Ausführungsform ist die ID-Applikation ferner ausgebildet, in Reaktion auf die Anfrage des ID-Agenten der Trustcenter-Serveranordnung, Zero-Knowledge-Proof-Daten an den ID-Agenten der Trustcenter-Serveranordnung zu senden, um die signierten User- Credentials des Benutzers der Datenkommunikationsvorrichtung zu verifizieren.
In einer Ausführungsform ist die Payment-Applikation ferner ausgebildet, eine weitere DID eines weiteren Benutzers einer weiteren Datenkommunikationsvorrichtung zusammen mit der Transaktions-ID und der DID des Benutzers der Datenkommunikationsvorrichtung an den Payment-Agenten der Trustcenter-Serveranordnung zu senden. In einer Ausführungsform ist der weiteren Benutzer der weiteren Datenkommunikationsvorrichtung der Zahlungsempfänger.
In einer Ausführungsform handelt es sich bei der Datenkommunikationsvorrichtung um eine mobile und tragbare Datenkommunikationsvorrichtung, insbesondere ein Smartphone.
Gemäß einem zweiten Aspekt wird ein Verfahren zum Betreiben einer Datenkommunikationsvorrichtung zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt, wobei die Datenkommunikationsvorrichtung wenigstens einen Prozessor umfasst, der ausgebildet ist, eine Payment-Applikation und eine ID-Applikation auszuführen, sowie ein Kommunikationsinterface, das ausgebildet ist, mit einer Trustcenter-Serveranordnung und einem Geld-Ledger zu kommunizieren. Das Verfahren umfasst die folgenden Schritte:
Senden einer Transaktions-ID und einer dezentralen Identität, DID, eines Benutzers der Datenkommunikationsvorrichtung von der Payment-Applikation an einen Payment- Agenten der Trustcenter-Serveranordnung;
Senden von signierten User-Credentials des Benutzers der Datenkommunikationsvorrichtung von der ID-Applikation an einen ID-Agenten der Trustcenter-Serveranordnung, in Reaktion auf eine die DID enthaltende Anfrage des ID- Agenten der Trustcenter-Serveranordnung;
Empfangen einer Signatur der Transaktions-ID von dem Payment-Agenten der Trustcenter-Serveranordnung durch die Payment-Applikation; und
Senden der Signatur der Transaktions-ID von der Payment-Applikation an den Geld- Ledger, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger zu verbuchen.
Gemäß einem dritten Aspekt wird eine Trustcenter-Serveranordnung zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt. Die Trustcenter-Serveranordnung umfasst wenigstens einen Prozessor, der ausgebildet ist, einen Payment-Agenten und einen ID- Agenten auszuführen, ein Kommunikationsinterface, das ausgebildet ist, mit einer Datenkommunikationsvorrichtung zu kommunizieren, sowie einen Speicher zum Speichern von elektronischen Daten. Der Payment-Agent ist ausgebildet, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers der Datenkommunikationsvorrichtung von einer Payment-Applikation der Datenkommunikationsvorrichtung zu empfangen. Der ID-Agent ist ausgebildet, in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten nach User- Credentials des Benutzers der Datenkommunikationsvorrichtung, die signierten User- Credentials des Benutzers der Datenkommunikationsvorrichtung von einer ID-Applikation der Datenkommunikationsvorrichtung zu erhalten. Der Payment-Agent ist ferner ausgebildet, die User-Credentials des Benutzers der Datenkommunikationsvorrichtung zu erhalten und zusammen mit der Transaktions-ID in dem Speicher zu speichern. Der Payment-Agent ist ferner ausgebildet, die Transaktions-ID zu signieren und die signierte Transaktions-ID an die Payment-Applikation der Datenkommunikationsvorrichtung zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf einem Geld-Ledger verbuchen zu können. In einer Ausführungsform ist das Kommunikationsinterface ferner ausgebildet, mit einem ID-Ledger zu kommunizieren und der ID-Agent ist ferner ausgebildet, Zero-Knowledge- Proof-Daten von der ID-Applikation der Datenkommunikationsvorrichtung zu erhalten und mittels der Zero-Knowledge-Proof-Daten und dem ID-Ledger die signierten User- Credentials des Benutzers der Datenkommunikationsvorrichtung zu verifizieren.
Gemäß einem vierten Aspekt wird ein Verfahren zum Betreiben einer Trustcenter- Serveranordnung zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt, wobei die Trustcenter-Serveranordnung wenigstens einen Prozessor umfasst, der ausgebildet ist, einen Payment-Agenten und einen ID-Agenten auszuführen, ein Kommunikationsinterface, das ausgebildet ist, mit einer Datenkommunikationsvorrichtung zu kommunizieren, sowie einen Speicher zum Speichern von elektronischen Daten. Das Verfahren umfasst die folgenden Schritte:
Empfangen einer Transaktions-ID und einer dezentralen Identität, DID, eines Benutzers der Datenkommunikationsvorrichtung von einer Payment-Applikation der Datenkommunikationsvorrichtung durch den Payment-Agenten;
Erhalten von signierten User-Credentials des Benutzers der Datenkommunikationsvorrichtung von einer ID-Applikation der Datenkommunikationsvorrichtung durch den ID-Agenten, in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten nach den User-Credentials des Benutzers der Datenkommunikationsvorrichtung;
Erhalten der User-Credentials des Benutzers der Datenkommunikationsvorrichtung durch den Payment-Agenten;
Speichern der User-Credentials des Benutzers der Datenkommunikationsvorrichtung zusammen mit der Transaktions-ID durch den Payment-Agenten in dem Speicher; und Senden der signierten Transaktions-ID von dem Payment-Agenten an die Payment- Applikation der Datenkommunikationsvorrichtung, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf einem Geld-Ledger verbuchen zu können.
Gemäß einem fünften Aspekt wird ein System zum Ausführen einer elektronischen Bezahltransaktion bereitgestellt, wobei das System eine Vielzahl von Datenkommunikationsvorrichtungen gemäß dem ersten Aspekt und eine Trustcenter- Serveranordnung gemäß dem dritten Aspekt umfasst.
Die unterschiedlichen Aspekte der Erfindung können in Hardware und/oder Software realisiert werden. Weitere Ausführungsbeispiele werden Bezug nehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
Fig. 1 ein schematisches Diagramm eines Systems zum elektronischen Bezahlen gemäß einer Ausführungsform mit einer Datenkommunikationsvorrichtung gemäß einer Ausführungsform und einem Trustcenter-Server-Anordnung gemäß einer Ausführungsform;
Fig. 2 ein Signalisierungsdiagramm, welches die Interaktion der Komponenten des Systems von Figur 1 gemäß einer Ausführungsform illustriert;
Fig. 3 ein Flussdiagramm, welches Schritte eines Verfahrens zum Betreiben einer Datenkommunikationsvorrichtung gemäß einer Ausführungsform illustriert; und
Fig. 4 ein Flussdiagramm, welches Schritte eines Verfahrens zum Betreiben einer Trustcenter-Serveranordnung gemäß einer Ausführungsform illustriert.
Elemente der nachfolgenden im Detail beschriebenen Ausführungsformen, die einander entsprechen, werden mit denselben Bezugszeichen gekennzeichnet.
Unter einer "Blockchain" wird hier und im Folgenden eine geordnete Datenstruktur verstanden, welche eine Vielzahl von miteinander verketteten Datenblöcken umfasst. Insbesondere wird unter einer Blockchain eine geordnete Datenstruktur verstanden, bei welcher jeder der Blöcke (außer dem ersten Block) einen Prüfwert, beispielsweise einen Hashwert, seines Vorgängerblocks umfasst und somit anhand jedes Blocks die Gültigkeit aller seiner Vorgängerblocks geprüft und gegebenenfalls bestätigt werden kann. Das Konzept der Blockchain wurde beispielsweise im Jahre 2008 in einem White Paper unter dem Pseudonym Satoshi Nakamoto zu Bitcoin beschrieben ("Bitcoin: Peer-to-Peer Electronic Cash System" (https://bitcoin.org/bitcoin.pdf)). Die darin beschriebene Blockchain besteht aus einer Reihe von Datenblöcken, in denen jeweils ein oder mehrere Einträge bzw. Transaktionen zusammengefasst und mit einer Prüfsumme in Form eines Hashwerts versehen sind. Zusätzliche Blöcke der Blockchain werden beispielsweise in einem rechenintensiven Prozess erzeugt, der auch als sogenanntes Mining bezeichnet wird. Diese zusätzlich erzeugten Blöcke werden anschließend der Blockchain hinzugefügt und über ein Netzwerk an alle Teilnehmer, bzw. Knoten des Netzwerks, verbreitet.
Ausführungsformen können den Vorteil haben, dass die Blockchain durch die Speicherung kryptografischer Prüfsumme, d.h. Hashwerten, des vorangehenden Blocks im jeweils nachfolgenden Block ein hohes Maß an Sicherheit gegenüber nachträglichen Manipulationen bietet. Das Verketten der Blöcke kann dann unter Verwendung dieser Root-Hashwerte überprüft werden. Jeder Block der Blockchain enthält in seinem Header den Hash des gesamten vorherigen Blockheaders. Somit wird die Reihenfolge der Blöcke eindeutig festgelegt und es entsteht eine Kettenstruktur. Durch die so implementierte Verkettung der einzelnen Blöcke miteinander wird erreicht, dass ein nachträgliches Modifizieren vorangegangener Blöcke bzw. einzelner Einträge praktisch ausgeschlossen ist, da hierfür die Hashwerte aller nachfolgenden Blöcke in kurzer Zeit ebenfalls neu berechnet werden müssten.
Gemäß einer Ausführungsform handelt es sich bei der Blockchain um eine Blockchain, bei der nur eine ausgewählte Gruppe von Teilnehmern eine Berechtigung zum Hinzufügen gültiger Blöcke besitzt. Eine entsprechende Berechtigung kann beispielsweise mittels einer Signatur unter Verwendung eines privaten kryptografischen Schlüssels nachgewiesen werden. Der private kryptografische Schlüssel kann zu einem asymmetrischen Schlüsselpaar gehören, zu welchem auch ein öffentlicher kryptografischer Schlüssel gehört, mit dem die Signatur geprüft werden kann. Dem asymmetrischen Schlüsselpaar kann zudem beispielsweise ein Zertifikat zugeordnet sein, welches die Berechtigung zum Erzeugen eines gültigen Blocks der Blockchain belegt. Dieses Zertifikat kann ferner einer PKI zugeordnet sein, welche die Authentizität des Zertifikats belegt. Nach einer weiteren Ausführungsform kann beispielsweise für weitere Teilnehmer, welche der ausgewählten Gruppe hinzugefügt werden sollen, ein öffentlicher Schlüssel in der Blockchain in einem Initialisierungseintrag hinterlegt werden. Anhand dieser öffentlichen Schlüssel kann geprüft werden, ob Signaturen von Blöcken und damit die entsprechenden Blöcke selbst gültig sind. Öffentliche Schlüssel ursprünglicher Teilnehmer der ausgewählten Gruppe können beispielsweise in einem Genesisblock der Blockchain hinterlegt sein.
Bei der vorliegenden von einer der Zentralbank verwalteten Blockchain handelt es sich beispielsweise um eine öffentliche Blockchain, welche auf Blockchain-Servern der Zentralbank verwaltet wird. Beispielsweise erfolgt ein Einträgen neuer Blöcke ausschließlich durch diese von der Zentralbank verwalteten Blockchain-Server. In diesem Fall können beispielsweise rechenintensiven Prozesse bei Hinzufügen zusätzlicher Blöcke entfallen. Beispielsweise ist für ein Hinzufügen zusätzlicher Blöcke lediglich eine Signatur mit einem der Zentralbank zugeordneten Signaturschlüssel notwendig.
Ein Trustcenter stellt eine vertrauenswürdige dritte Instanz ("Trusted Third Party") dar, welche in elektronischen Kommunikationsprozessen die jeweilige Identität des Kommunikationspartners bescheinigen kann. Beispielsweise kann bei der elektronischen Kommunikation im Zusammenhang mit elektronischen Signaturen ein Trustcenter Zertifikate ausstellen, anhand derer die Identität der Kommunikationspartner bescheinigt werden können.
Unter einem "Kommunikationsinterface" bzw. einer "Kommunikationsschnittstelle" wird hier beispielsweise eine Schnittstelle verstanden, über die Daten empfangen und gesendet werden können, wobei das Kommunikationsinterface kontaktbehaftet oder kontaktlos konfiguriert sein kann.
Eine Kommunikation kann beispielsweise über ein Netzwerk erfolgen. Unter einem "Netzwerk" wird hier jedes Übertragungsmedium mit einer Anbindung zur Kommunikation verstanden, insbesondere eine lokale Verbindung oder ein lokales Netzwerk, insbesondere ein Local Area Network (LAN), ein privates Netzwerk, insbesondere ein Intranet, und ein digitales privates Netzwerk (Virtual Private Network - VPN).
Beispielsweise kann ein Computersystem eine Standardfunkschnittstelle zur Anbindung an ein WLAN aufweisen. Ferner kann es sich um ein öffentliches Netzwerk, wie beispielsweise das Internet handeln. Je nach Ausführungsform kann diese Verbindung auch über ein Mobilfunknetz hergestellt werden.
Unter einem "Prozessor" wird hier und im Folgenden eine Logikschaltung verstanden, die zur Ausführung von Programminstruktionen dient. Die Logikschaltung kann auf einem oder mehreren diskreten Bauelementen implementiert sein, insbesondere auf einem Chip. Ein Prozessor umfasst beispielsweise ein Rechenwerk, ein Steuerwerk, Register und Datenleitungen zur Kommunikation mit anderen Komponenten. Insbesondere wird unter einem "Prozessor" ein Mikroprozessor oder ein Mikroprozessorsystem aus mehreren Prozessorkernen und/oder mehreren Mikroprozessoren verstanden. Der Prozessor ist ausgebildet, Programminstruktionen auszuführen, die beispielsweise in einem Speicher gespeichert sind, um die hierein beschriebenen Operationen und Verfahren auszuführen. Unter einem "Speicher" wird hier insbesondere ein nichtflüchtiger Speicher verstanden. Unter einem "nichtflüchtigen Speicher" wird hier beispielsweise ein elektronischer Speicher zur dauerhaften Speicherung von Daten verstanden. Ein nichtflüchtiger Speicher kann als nichtänderbarer Speicher konfiguriert sein, der auch als Read-Only Memory (ROM) bezeichnet wird, oder als änderbarer Speicher, der auch als Non-Volatile Memory (NVM) bezeichnet wird. Insbesondere kann es sich hierbei um ein EEPROM, beispielsweise ein Flash-EEPROM, kurz als Flash bezeichnet, handeln. Ein nichtflüchtiger Speicher zeichnet sich dadurch aus, dass die darauf gespeicherten Daten auch nach Abschalten der Energieversorgung erhalten bleiben.
Unter einem "geschützten Speicherbereich" wird hier ein Bereich eines elektronischen Speichers verstanden, auf den ein Zugriff, das heißt ein Lesezugriff oder ein Schreibzugriff, nur über einen Prozessor eines Sicherheitselements möglich ist.
Beispielsweise ist auf den geschützten Speicherbereich kein externer Zugriff möglich, d.h. Daten können hierher weder von außen eingebracht werden, noch nach außen ausgegeben werden. Beispielsweise können Daten über den Prozessor nach außen aus den geschützten Speicherbereich ausgelesen werden. Beispielsweise können Daten über den Prozessor von außen in den geschützten Speicherbereich eingebracht werden. Nach Ausführungsformen ist der Zugriff von dem bzw. über den mit dem Speicher gekoppelten Prozessor nur dann möglich, wenn eine hierzu erforderliche Bedingung erfüllt ist. Hierbei kann es sich zum Beispiel um eine kryptografische Bedingung, insbesondere eine erfolgreiche Authentisierung und/oder eine erfolgreiche Berechtigungsprüfung, handeln. Eine solche Prüfung kann beispielsweise auf einer elektronischen Signatur mit einem Signaturschlüssel beruhen.
Asymmetrische Schlüsselpaare werden für eine Vielzahl von Kryptosystemen eingesetzt und spielen auch bei der Signatur elektronischer Daten eine wichtige Rolle. Ein asymmetrisches Schlüsselpaar besteht aus einem öffentlichen Schlüssel, welcher zur Ver- und/oder Entschlüsselung von Daten verwendet wird und an Dritte weitergegeben werden darf, sowie einem privaten Schlüssel, welcher zur Ver- und/oder Entschlüsselung von Daten verwendet wird und im Regelfall geheim gehalten werden muss. Der öffentliche Schlüssel ermöglicht es jedermann, Daten für den Inhaber des privaten Schlüssels zu verschlüsseln und digitale mit dem privaten Schlüssel erstellte Signaturen zu prüfen. Ein privater Schlüssel ermöglicht es seinem Inhaber, mit dem öffentlichen Schlüssel verschlüsselte Daten zu entschlüsseln oder digitale Signaturen zu erstellen. Eine mit einem privaten Schlüssel erstellte Signatur kann mit dem zugehörigen öffentlichen Schlüssel verifiziert werden.
Die Erstellung einer digitalen Signatur, im Folgenden auch lediglich als "Signatur" bezeichnet, ist ein kryptografisches Verfahren, bei dem zu beliebigen Daten ein weiterer Datenwert, welcher als "Signatur" bezeichnet wird, berechnet wird. Bei einer Signatur kann es sich zum Beispiel um eine mit einem privaten kryptografischen Schlüssel verschlüsselten Hashwert der Ausgangsdaten handeln.
Unter eine Sicherheitselement wird hier beispielsweise eine elektronische Komponente verstanden, welche einen Prozessor und einen Speicher umfasst, und auf welche nur bestimmte vordefinierte Zugriffe ermöglicht werden. Beispielsweise können nur bestimmte Datenwerte, welche etwa in bestimmten Bereichen des Speichers abgelegt sind, ausgelesen werden. Beispielsweise können in einem geschützten Speicherbereich abgelegt Datenwerte nicht ausgelesen werden. Beispielsweise ist zum Schreiben eines Datenwerts in den Speicher des Sicherheitselements eine digitale Signatur notwendig, deren Prüfschlüssel in dem Sicherheitselement hinterlegt ist. Beispielsweise besitzt nur der Prozessor Schreibrechte zum Schreiben von Daten in einen geschützten Speicherbereich.
Das Sicherheitselement stellt ferner beispielsweise kryptografische Kernroutinen in Form von kryptografischen Programminstruktionen mit kryptografischen Algorithmen für Signaturerstellung und/oder -prüfung, Schlüsselgenerierung, und/oder Zufallszahlengenerierung bereit und kann ferner als sicherer Speicher für kryptografische Schlüssel dienen.
Beispielsweise sind zumindest Teile des Sicherheitselements signiert. Vor einer Nutzung des Sicherheitselements wird geprüft, ob die Signatur bzw. die Signaturen, valide sind. Wenn eine der Signaturen nicht valide ist, wird die Nutzung des Sicherheitselements beispielsweise gesperrt.
Beispielsweise weist das Sicherheitselement physikalisch beschränkte Zugriffsmöglichkeiten auf. Zudem kann das Sicherheitselement zusätzliche Maßnahmen gegen Missbrauch aufweisen, insbesondere gegen unberechtigte Zugriffe auf Daten im Speicher des Sicherheitselement. Beispielsweise umfassen die Mittel zum Schutz des Sicherheitselements gegen unbefugte Manipulationen mechanische Mittel, die z.B. das Öffnen des Sicherheitselements oder seiner Teile verhindern sollen, oder die bei dem Versuch eines Eingriffs in das Sicherheitselement dieses unbrauchbar machen, beispielsweise indem ein Datenverlust eintritt. Beispielsweise können hierzu zumindest Teile des Sicherheitselements in ein Material eingeschlossen, eingegossen und/oder einlaminiert sein, dessen versuchte Entfernung zu einer unvermeidlichen Zerstörung der entsprechenden Teile des Sicherheitselements führt.
Figur 1 zeigt ein System 100 zum nachverfolgbaren Durchführen von elektronischen bargeldlosen Zahlungen zwischen einer ersten Datenkommunikationsvorrichtung 110 eines Zahlungspflichtigen Benutzers 110a und einer zweiten Datenkommunikationsvorrichtung 120 eines Zahlungsempfängers. Bei der ersten und/oder der zweiten Datenkommunikationsvorrichtung 110, 120 kann es sich jeweils um eine mobile und tragbare Datenkommunikationsvorrichtung 110, 120, insbesondere um ein Smartphone 110, 120 handeln. Bei den im Folgenden beschriebenen Ausführungsformen handelt es sich bei den Datenkommunikationsvorrichtungen 110, 120 exemplarisch um Smartphones 110, 120.
Bei der in Figur 1 dargestellten Ausführungsform umfassen das Smartphone 110 des Zahlungspflichtigen Benutzers 110a und das Smartphone 120 des Zahlungsempfängers jeweils einen oder mehrere Prozessoren 111, 121, ein Kommunikationsinterface 113, 123 zur drahtlosen und/oder drahtgebundenen Kommunikation über ein Kommunikationsnetzwerk sowie einen Speicher 115, 125 zum Speichern von elektronischen Daten. Die Smartphones 110, 120 können jeweils ein Sicherheitselement, z.B. eine virtuelle oder physikalische SIM-Karte umfassen, welches ausgebildet ist, sicherheitskritische Daten zu speichern und/oder sicherheitskritische Operationen, insbesondere kryptografische Operationen durchzuführen.
Wie in Figur 1 dargestellt, ist der Prozessor 111 , 121 des jeweiligen Smartphones 110, 120 ausgebildet, eine Payment-Applikation 111a, 121a und eine ID-Applikation bzw. Ausweis-Applikation 111b, 121b auszuführen, deren Funktion und Zusammenwirken untereinander und mit den anderen Komponenten des Systems 100 nachstehend unter weiterer Bezugnahme auf Figur 2 detailliert beschrieben wird.
Neben dem Smartphone 110 des Zahlungspflichtigen Benutzers 110a und dem
Smartphone 120 des Zahlungsempfängers umfasst das System 100 eine Trustcenter-
Serveranordnung 130, einen ID-Ledger 140 für selbstbestimmte Identitäten (Self- Sovereign Identity (SSI); daher in Figur 1 auch als "SSI-Ledger" 140 bezeichnet), einen Geld-Ledger 150, beispielweise eine Blockchain 150, und eine Zentralbank bzw. einen Zentralbankserver 160 zum Verwalten des Geld-Ledger 150. Die Trustcenter- Serveranordnung 130 kann einen oder mehrere Server umfassen, mit einem oder mehreren Prozessoren 131 , einem Kommunikationsinterface 133 zur drahtlosen und/oder drahtgebundenen Kommunikation über ein Kommunikationsnetzwerk sowie einem Speicher 135 zum Speichern von elektronischen Daten.
Wie in Figur 1 dargestellt, ist der wenigstens eine Prozessor 131 der Trustcenter- Serveranordnung 130 ausgebildet, einen Payment-Agenten 131a (bzw. Payment-Dienst 131a) und einen ID-Agenten 131b (bzw. ID-Dienst 131b) auszuführen, deren Funktion und Zusammenwirken untereinander und mit den anderen Komponenten des Systems 100 nachstehend unter weiterer Bezugnahme auf Figur 2 detailliert beschrieben wird.
Der Geld-Ledger 150 kann beispielsweise auf einem oder mehreren Blockchain-Servern implementiert sein. Mit anderen Worten: die Blockchain-Server können Teil eines Geld- Ledger-Netzwerks 150 sein und somit Blockchain-Knoten des Geld-Ledgers 150 sein. Die Blockchain-Server und/oder der Geld-Ledger 150, d.h. das Blockchain-Netzwerk 150 können beispielsweise von einer Zentralbank 160 verwaltet werden. Handelt es sich bei der Zentralbank 160 um eine Zentralbank 160, welcher mehrere Länder angehören, kann der Geld-Ledger 150 beispielsweise ein oder mehrere Blockchain-Server pro Land umfassen.
Figur 2 illustriert die Interaktion der Komponenten des in Figur 1 dargestellten Systems 100 gemäß einer Ausführungsform.
Der Zahlungspflichtige Benutzer 110a möchte mittels seines Smartphones 110 dem Zahlungsempfänger über dessen Smartphone 120 einen bestimmten Betrag bezahlen. Hierzu startet in Schritt 201 von Figur 2 der Benutzer 110a auf seinem Smartphone 110 die Payment-Applikation 111a (in Figur 2 als "Payment App" bezeichnet).
In der in Figur 2 dargestellten Ausführungsform überprüft die vom Prozessor 111 implementierte Payment-Applikation 111a zunächst die Höhe des zu bezahlenden Betrags. Falls dieser Betrag höher als ein Schwellenwert ist (beispielsweise ein gesetzlich festgelegter Schwellenwert), führt das Smartphone 110 die in Figur 2 dargestellten weiteren Schritte durch (Schritt 203 von Figur 2). Andernfalls, d.h. falls der zu bezahlende Betrag nicht höher als der Schwellenwert ist, kann die Bezahltransaktion ohne das Trustcenter 130 durchgeführt und in im Wesentlichen bekannter Art und Weise auf dem Geld-Ledger 150 verbucht werden. Erfindungsgemäß sind jedoch auch Ausführungsformen vorgesehen, bei denen diese Prüfung entfällt, und die nachstehend beschriebenen Schritte unabhängig von der Höhe des zu zahlenden Betrags durchgeführt werden.
Da bei dem in Figur 2 gezeigten Beispiel der zu bezahlenden Betrag größer als der Schwellenwert ist, generiert die von dem Prozessor 111 implementierte Payment- Applikation 111a beim Schritt 205 von Figur 2 eine Anfrage und sendet diese über die Kommunikationsschnittstelle 113 an das Trustcenter 130, insbesondere den Payment- Agenten 131a (in Figur 2 als "TSE-Agent" 131a gekennzeichnet) des Trustcenters 130, um eine vom Trustcenter 130 digital signierte Transaktions-ID zu erhalten. In Reaktion auf die Anfrage in Schritt 205 sendet der Payment-Agent 131a seinerseits beim Schritt 207 von Figur 2 eine Anfrage an die Payment-Applikation 111a nach der Transaktions-ID und einer Dezentralen-ID für den Benutzer 110a des Smartphones 110. In einer Ausführungsform kann die Transaktions-ID von der Payment-Applikation 111a das Smartphones generiert werden.
Bei den innerhalb des Smartphones 110 ablaufenden Schritten 209 von Figur 2 sendet die Payment-Applikation 111a zunächst eine Anfrage an die ID-Applikation 111b und erhält von dieser als Antwort die Dezentrale-ID (DID; im Englischen auch als "Decentralized Identifier" bekannt) des Zahlungspflichtigen Benutzers 110a des Smartphones 110.
Beim Schritt 210 von Figur 2 sendet die Payment-Applikation 111a des Smartphones 110 die von der ID-Applikation 111b erhaltene DID und die Transaktions-ID an den Payment- Agenten 131a des Trustcenters 130.
Der Payment-Agent 131a des Trustcenters 130 sendet beim Schritt 211 von Figur 2 eine Anfrage nach "User-Credentials" (bzw. Benutzerinformationen) des Benutzers 110a an den ID-Agenten 131b des Trustcenters 130, wobei die Anfrage die von der ID-Applikation 111b des Smartphones 110 erhaltene DID enthält. Der ID-Agent 131b dient im Wesentlichen zur automatischen Prüfung von Identitäten in dem SSI-Ledger (bzw. ID- Ledger) 140, der auf der "Distributed Ledger Technology (DLT)" basiert. Beim Schritt 213 von Figur 2 sendet der ID-Agent 131b des Trustcenters 130 eine Anfrage nach den User-Credentials an die ID-Applikation 111b des Smartphones 110, d.h. nach den Benutzerinformationen zur Identitätsfeststellung des Benutzers 110a des Smartphones 110 mittels des SSI-Ledgers 140. Dabei enthält die Anfrage die ursprünglich von der ID-Applikation 111b erhaltene DID.
Beim Schritt 215 von Figur 2 signiert die ID-Applikation 111b des Smartphones 110 die User-Credentials bzw. Benutzerinformationen mit einem privaten Schlüssel des Smartphones 110. Ein solcher privater Schlüssel kann beispielsweise in einem gesicherten Speicherbereich eines Sicherheitselements, beispielsweise einer virtuellen oder physikalischen SIM-Karte des Smartphones 110 hinterlegt sein. Wie bereits vorstehend beschrieben, können sicherheitskritische kryptografische Operationen der ID- Applikation 111b und/oder Payment-Applikation 111a in einem solchen Sicherheitselement durchgeführt werden.
Beim Schritt 217 beweist die ID-Applikation 111b des Smartphones 110 mittels eines Zero-Knowledge-Proofs (ZKP; Null-Wissen-Beweis) die Echtheit der beim Schritt 215 übermittelten User-Credentials bzw. Benutzerinformationen.
Beim Schritt 219 von Figur 2 beschafft sich der ID-Agent 131b des Trustcenters 130 Daten von dem ID-Ledger 140 zur Bestätigung bzw. Verifizierung des ZKP von Schritt 217, indem diese Daten von dem ID-Ledger 140 herunter geladen werden (Schritt 221 von Figur 2).
Nach der Bestätigung des ZKP durch den ID-Agent 131b des Trustcenters 130 (aufgrund derer der ID-Agent 131a den User-Credentials vertrauen kann), sendet beim Schritt 223 von Figur 2 der ID-Agent 131b des Trustcenters 130 die User-Credentials an den Payment-Agenten 131a. Daraufhin speichert der Payment-Agent 131a die signierte Transaktions-ID zusammen mit den User-Credentials in einer im Speicher 135 implementierten Datenbank 135a (Schritt 225 von Figur 2). In einer Ausführungsform kann der Payment-Agent 131a hierfür noch eine Identifikationsnummer vergeben und diese mit der Transaktions-ID verknüpfen.
Beim Schritt 227 sendet der Payment-Agent 131a des Trustcenters 130 die signierte
Transaktions-ID an die Payment-Applikation 111a des Smartphones 110. Somit stellt der Schritt 227 letztendlich die Antwort des Trustcenters 130 auf die in Schritt 205 angefragte signierte Transaktions-ID dar.
Zum Abschließen der Bezahltransaktion sendet die Payment-Applikation 111a beim Schritt 229 von Figur 2 die Transaktionsdaten, d.h. insbesondere die Transaktions-ID und den Betrag, sowie die Signatur der Transaktions-ID an den Geld-Ledger 150, wo diese Daten verbucht bzw. abgelegt werden, um bei Bedarf dem Zentralbankserver 160 für eine Nachverfolgung zur Verfügung zu stehen. Der Bezahlvorgang ist damit abgeschlossen. Optional kann zusätzlich auch die Identität des Zahlungsempfängers, d.h. des Benutzers des weiteren Smartphones 120 mit aufgenommen werden, indem sich die Payment- Applikation 111a auch die DID des Benutzers des weiteren Smartphones 120 verschafft. In dem Fall würde der Identity-Agent 131b des Trustcenters 130 zwei getrennte Verbindungen aufbauen, nämlich zum einen zum Smartphone 110 des Zahlungspflichtigen Benutzers 110a und zum anderen zum Smartphone des Zahlungsempfängers.
Figur 3 zeigt ein Flussdiagramm, welches Schritte eines Verfahrens 300 zum Betreiben der Datenkommunikationsvorrichtung 110 gemäß einer Ausführungsform illustriert. Das Verfahren 300 umfasst die folgenden Schritte:
Senden 301 einer Transaktions-ID und einer dezentralen Identität, DID, des Benutzers 110a der Datenkommunikationsvorrichtung 110 von der Payment-Applikation 111a an einen Payment-Agenten 131a der Trustcenter-Serveranordnung 130;
Senden 303 von signierten User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110 von der ID-Applikation 111b an einen ID-Agenten 131b der Trustcenter-Serveranordnung 130, in Reaktion auf eine die DID enthaltende Anfrage des ID-Agenten 131b der Trustcenter-Serveranordnung 130;
Empfangen 305 einer Signatur der Transaktions-ID von dem Payment-Agenten 131b der Trustcenter-Serveranordnung 130 durch die Payment-Applikation 111a; und Senden 307 der Signatur der T ransaktions-l D von der Payment-Applikation 111 a an den Geld-Ledger 150, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger 150 zu verbuchen.
Figure 4 zeigt ein Flussdiagramm, welches Schritte eines Verfahrens 400 zum Betreiben der Trustcenter-Serveranordnung 130 gemäß einer Ausführungsform illustriert.
Das Verfahren 400 umfasst die folgenden Schritte: Empfangen 401 einer Transaktions-ID und der dezentralen Identität, DID, des Benutzers 110a der Datenkommunikationsvorrichtung 110 von einer Payment-Applikation 111a der Datenkommunikationsvorrichtung 110 durch den Payment-Agenten 131a;
Erhalten 403 von signierten User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110 von einer ID-Applikation 111b der Datenkommunikationsvorrichtung 110 durch den ID-Agenten 131b, in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten 131a nach den User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110;
Erhalten 405 der User-Credentials des Benutzers 110a der
Datenkommunikationsvorrichtung 110 durch den Payment-Agenten 131a;
Speichern 407 der User-Credentials des Benutzers 110a der Datenkommunikationsvorrichtung 110 zusammen mit der Transaktions-ID durch den Payment-Agenten 131a in dem Speicher 135; und
Senden 409 der signierten Transaktions-ID von dem Payment-Agenten 131a an die Payment-Applikation 111a der Datenkommunikationsvorrichtung 110, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld- Ledger 150 verbuchen zu können.
BEZUGSZEICHENLISTE
100 Elektronisches Bezahlsystem
110 Datenkommunikationsvorrichtung des Zahlungspflichtigen
110a Zahlungspflichtiger Benutzer
111 Prozessor
111a Payment-Applikation
111b ID-Applikation
113 Kommunikations-Interface
115 Speicher
120 Datenkommunikationsvorrichtung des Zahlungsempfängers
121 Prozessor
121a Payment-Applikation
121b ID-Applikation
123 Kommunikations-Interface
125 Speicher
130 Trustcenter-Serveranordnung
131 Prozessor
131a Payment-Agent
131b ID-Agent
133 Kommunikations-Interface
135 Speicher
135a Datenbank
140 ID-Ledger
150 Geld-Ledger
160 Zentralbank

Claims

PATENTANSPRÜCHE
1. Datenkommunikationsvorrichtung (110) zum Ausführen einer elektronischen Bezahltransaktion, wobei die Datenkommunikationsvorrichtung (110) umfasst: wenigstens einen Prozessor (111), der ausgebildet ist, eine Payment-Applikation (111a) und eine ID-Applikation (111b) auszuführen; und ein Kommunikationsinterface (113), das ausgebildet ist, mit einer Trustcenter- Serveranordnung (130) und einem Geld-Ledger (150) zu kommunizieren; wobei die Payment-Applikation (111a) ausgebildet ist, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) an einen Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) zu senden; wobei die ID-Applikation (111b) ausgebildet ist, in Reaktion auf eine die DID enthaltende Anfrage eines ID-Agenten (131b) der Trustcenter-Serveranordnung (130), signierte User- Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) an den ID- Agenten (131b) der Trustcenter-Serveranordnung (130) zu senden; wobei die Payment-Applikation (111a) ferner ausgebildet ist, eine Signatur der Transaktions-ID von dem Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) zu empfangen und die Signatur der Transaktions-ID an den Geld-Ledger (150) zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger (150) zu verbuchen.
2. Datenkommunikationsvorrichtung (110) nach Anspruch 1 , wobei die Payment- Applikation zum Ausführen einer weiteren elektronischen Bezahltransaktion, deren Betrag kleiner als ein Schwellenwert ist, ausgebildet ist, eine weitere Transaktions-ID der weiteren elektronischen Bezahltransaktion ohne eine Signatur der weiteren Transaktions- ID an den Geld-Ledger (150) zu senden, um die elektronische Bezahltransaktion mit der weiteren Transaktions-ID und ohne eine Signatur der weiteren Transaktions-ID auf dem Geld-Ledger (150) zu verbuchen.
3. Datenkommunikationsvorrichtung (110) nach Anspruch 1 oder 2, wobei die Payment-Applikation (111a) ferner ausgebildet ist, die Transaktions-ID zu generieren und/oder auf Anfrage die DID des Benutzers 110a der Datenkommunikationsvorrichtung (110) von der ID-Applikation (111b) zu erhalten.
4. Datenkommunikationsvorrichtung (110) nach einem der vorhergehenden Ansprüche, wobei die ID-Applikation (111b) ferner ausgebildet ist, in Reaktion auf die Anfrage des ID-Agenten (131b) der Trustcenter-Serveranordnung (130), Zero-Knowledge- Proof-Daten an den ID-Agenten (131b) der Trustcenter-Serveranordnung (130) zu senden, um die signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) zu verifizieren.
5. Datenkommunikationsvorrichtung (110) nach einem der vorhergehenden Ansprüche, wobei die Payment-Applikation (111a) ferner ausgebildet ist, eine weitere DID eines weiteren Benutzers einer weiteren Datenkommunikationsvorrichtung (120) zusammen mit der Transaktions-ID und der DID des Benutzers (110a) der Datenkommunikationsvorrichtung (110) an den Payment-Agenten (131a) der Trustcenter- Serveranordnung (130) zu senden.
6. Datenkommunikationsvorrichtung (110) nach einem der vorhergehenden Ansprüche, wobei die Datenkommunikationsvorrichtung (110) eine mobile und tragbare Datenkommunikationsvorrichtung (110), insbesondere ein Smartphone (110) ist.
7. Verfahren (300) zum Betreiben einer Datenkommunikationsvorrichtung (110) zum Ausführen einer elektronischen Bezahltransaktion, wobei die Datenkommunikationsvorrichtung (110) wenigstens einen Prozessor (111) umfasst, der ausgebildet ist, eine Payment-Applikation (111a) und eine ID-Applikation (111b) auszuführen, sowie ein Kommunikationsinterface (113), das ausgebildet ist, mit einer Trustcenter-Serveranordnung (130) und einem Geld-Ledger (150) zu kommunizieren, wobei das Verfahren (300) umfasst:
Senden (301) einer Transaktions-ID und einer dezentralen Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) von der Payment-Applikation (111a) an einen Payment-Agenten (131a) der Trustcenter-Serveranordnung (130); Senden (303) von signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) von der ID-Applikation (111b) an einen ID- Agenten (131b) der Trustcenter-Serveranordnung (130), in Reaktion auf eine die DID enthaltende Anfrage des ID-Agenten (131b) der Trustcenter-Serveranordnung (130);
Empfangen (305) einer Signatur der Transaktions-ID von dem Payment-Agenten (131a) der Trustcenter-Serveranordnung (130) durch die Payment-Applikation (111a); und
Senden (307) der Signatur der T ransaktions-l D von der Payment-Applikation (111 a) an den Geld-Ledger (150), um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf dem Geld-Ledger (150) zu verbuchen.
8. Trustcenter-Serveranordnung (130) zum Ausführen einer elektronischen Bezahltransaktion, wobei die Trustcenter-Serveranordnung (130) umfasst: wenigstens einen Prozessor (131), der ausgebildet ist, einen Payment-Agenten (131a) und einen ID-Agenten (131b) auszuführen; ein Kommunikationsinterface (133), das ausgebildet ist, mit einer Datenkommunikationsvorrichtung (110) zu kommunizieren; und einen Speicher (135) zum Speichern von elektronischen Daten; wobei der Payment-Agent (131a) ausgebildet ist, eine Transaktions-ID und eine dezentrale Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) von einer Payment-Applikation (111a) der Datenkommunikationsvorrichtung (110) zu empfangen; wobei der ID-Agent (131b) ausgebildet ist, in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten (131a) nach User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110), die signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) von einer ID-Applikation (111b) der Datenkommunikationsvorrichtung (110) zu erhalten; wobei der Payment-Agent (131a) ferner ausgebildet ist, die User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) zu erhalten und zusammen mit der Transaktions-ID in dem Speicher (135) zu speichern; und wobei der Payment-Agent (131a) ferner ausgebildet ist, die Transaktions-ID zu signieren und die signierte Transaktions-ID an die Payment-Applikation (111a) der Datenkommunikationsvorrichtung (110) zu senden, um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf einem Geld-Ledger (150) verbuchen zu können.
9. Trustcenter-Serveranordnung (130) nach Anspruch 8, wobei das Kommunikationsinterface (133) ferner ausgebildet ist, mit einem ID-Ledger (140) zu kommunizieren und wobei der ID-Agent (131b) ferner ausgebildet ist, Zero-Knowledge- Proof-Daten von der ID-Applikation (111b) der Datenkommunikationsvorrichtung (110) zu erhalten und mittels der Zero-Knowledge-Proof-Daten und dem ID-Ledger (140) die signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) zu verifizieren.
10. Verfahren (400) zum Betreiben einer Trustcenter-Serveranordnung (130) zum Ausführen einer elektronischen Bezahltransaktion, wobei die Trustcenter- Serveranordnung (130) wenigstens einen Prozessor (131) umfasst, der ausgebildet ist, einen Payment-Agenten (131a) und einen ID-Agenten (131b) auszuführen, ein Kommunikationsinterface (133), das ausgebildet ist, mit einer Datenkommunikationsvorrichtung (110) zu kommunizieren, sowie einen Speicher (135) zum Speichern von elektronischen Daten, wobei das Verfahren (400) umfasst:
Empfangen (401) einer Transaktions-ID und einer dezentralen Identität, DID, eines Benutzers (110a) der Datenkommunikationsvorrichtung (110) von einer Payment- Applikation (111a) der Datenkommunikationsvorrichtung (110) durch den Payment- Agenten (131a);
Erhalten (403) von signierten User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) von einer ID-Applikation (111b) der Datenkommunikationsvorrichtung (110) durch den ID-Agenten (131b), in Reaktion auf eine die DID enthaltende Anfrage des Payment-Agenten (131a) nach den User- Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110); Erhalten (405) der User-Credentials des Benutzers (110a) der
Datenkommunikationsvorrichtung (110) durch den Payment-Agenten (131a);
Speichern (407) der User-Credentials des Benutzers (110a) der Datenkommunikationsvorrichtung (110) zusammen mit der Transaktions-ID durch den Payment-Agenten (131a) in dem Speicher (135); und
Senden (409) der signierten Transaktions-ID von dem Payment-Agenten (131a) an die Payment-Applikation (111a) der Datenkommunikationsvorrichtung (110), um die elektronische Bezahltransaktion mit der Signatur der Transaktions-ID auf einem Geld- Ledger (150) verbuchen zu können.
11 . System (100) zum Ausführen einer elektronischen Bezahltransaktion, wobei das System umfasst: eine Vielzahl von Datenkommunikationsvorrichtungen (110) nach einem der Ansprüche 1 bis 6; und eine Trustcenter-Serveranordnung (130) nach einem der Ansprüche 8 oder 9.
12. Computerprogramm mit einem Programmcode zum Ausführen des Verfahrens (300) nach Anspruch 7 und/oder des Verfahrens (400) nach Anspruch 10, wenn das Computerprogramm auf einem Computer ausgeführt wird.
PCT/EP2023/057540 2022-04-22 2023-03-23 Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen WO2023202836A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022109813.3 2022-04-22
DE102022109813.3A DE102022109813A1 (de) 2022-04-22 2022-04-22 Vorrichtungen, System und Verfahren zum elektronischen bargeldlosen Bezahlen

Publications (1)

Publication Number Publication Date
WO2023202836A1 true WO2023202836A1 (de) 2023-10-26

Family

ID=85795312

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/057540 WO2023202836A1 (de) 2022-04-22 2023-03-23 Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen

Country Status (2)

Country Link
DE (1) DE102022109813A1 (de)
WO (1) WO2023202836A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170250972A1 (en) * 2016-02-29 2017-08-31 Troy Jacob Ronda Systems and methods for distributed identity verification
US20180270065A1 (en) * 2017-03-15 2018-09-20 NuID, Inc. Methods and systems for universal storage and access to user-owned credentials for trans-institutional digital authentication
US20200210594A1 (en) * 2018-12-27 2020-07-02 Eli Talmor Method and System for secure Applications using Blockchain.
EP3965040A1 (de) * 2020-09-03 2022-03-09 Sicpa Holding Sa Verfahren und system zum konformen austausch von auf digitaler, auf token basierender währung

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10333705B2 (en) 2016-04-30 2019-06-25 Civic Technologies, Inc. Methods and apparatus for providing attestation of information using a centralized or distributed ledger
US11645654B2 (en) 2021-01-14 2023-05-09 American Express Travel Related Services Company, Inc. Biometric-based identity verification using zero-knowledge proofs

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170250972A1 (en) * 2016-02-29 2017-08-31 Troy Jacob Ronda Systems and methods for distributed identity verification
US20180270065A1 (en) * 2017-03-15 2018-09-20 NuID, Inc. Methods and systems for universal storage and access to user-owned credentials for trans-institutional digital authentication
US20200210594A1 (en) * 2018-12-27 2020-07-02 Eli Talmor Method and System for secure Applications using Blockchain.
EP3965040A1 (de) * 2020-09-03 2022-03-09 Sicpa Holding Sa Verfahren und system zum konformen austausch von auf digitaler, auf token basierender währung

Also Published As

Publication number Publication date
DE102022109813A1 (de) 2023-10-26

Similar Documents

Publication Publication Date Title
DE102018106682B4 (de) Bereitstellen einer out-of-band-verifizierung für blockchain-transaktionen
EP3596653B1 (de) Ausstellen virtueller dokumente in einer blockchain
EP3446273B1 (de) Elektronisches verfahren zur kryptographisch gesicherten überweisung eines betrags einer kryptowährung
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
EP3993318B1 (de) Blockchain-basiertes digitales dokumentensystem
DE102019002732A1 (de) Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
EP3814970A1 (de) Manipulationssicheres ausstellen und speichern von elektronischen urkunden
DE202015009601U1 (de) System zur persönlichen Identifizierung und Verifizierung
DE202015009562U1 (de) System zur persönlichen Identifizierung und Verifizierung
EP3206151B1 (de) Verfahren und system zur authentifizierung eines mobilen telekommunikationsendgeräts an einem dienst-computersystem und mobiles telekommunikationsendgerät
WO2022008322A1 (de) Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
EP4315117A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
WO2023202836A1 (de) Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
DE102020104904A1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
EP4111347B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102021129047A1 (de) Selektiv anonymisierende Überweisung einer Kryptowährung
EP3180729B1 (de) Digitale identitäten mit fremdattributen
DE102021002329A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102020004122A1 (de) Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102010026697A1 (de) Gesicherter automatisierter Austausch von Informationen zur Vertrauenswürdigkeit von Geschäfts- oder Kommunikationspartnern

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: 23714516

Country of ref document: EP

Kind code of ref document: A1