DE102021000570A1 - METHOD OF PROVIDING AN EVIDENCE DATASET; PROCEDURE FOR EXAMINING AN EVIDENCE RECORD; A COIN REGISTER; A SUBSCRIBER UNIT AND A COMPUTER PROGRAM PRODUCT - Google Patents

Abstract

The invention relates to a method for providing a verification data set relating to an electronic coin data set by a subscriber unit of an electronic payment system, the electronic coin data set having a monetary amount and an obfuscation amount. The invention also relates to a method for checking proof of an electronic coin data set by a second subscriber unit or a coin register of an electronic payment system. The invention also relates to a coin register, a payment system, a subscriber unit and a computer program product.

Description

TECHNICAL FIELD OF THE INVENTION

The invention relates to a method for providing a verification data set relating to an electronic coin data set by a subscriber unit of an electronic payment system, the electronic coin data set having a monetary amount and an obfuscation amount. The invention also relates to a method for checking proof of an electronic coin data set by a second subscriber unit or a coin register of an electronic payment system. The invention also relates to a coin register, a payment system, a subscriber unit and a computer program product.

TECHNICAL BACKGROUND OF THE INVENTION

Protection of privacy is an important value for society, especially when very sensitive data, such as payment information, is involved. Security of payment transactions and the associated payment transaction data means protecting the confidentiality of the data exchanged; as well as protection of the integrity of the exchanged data; as well as protection of the availability of the exchanged data.

For electronic coin datasets, it must be possible to demonstrate basic control functions, in particular (1) the detection of multiple issuance procedures, also known as double spending, and (2) the detection of uncovered payments. In case (1) someone tries to spend the same coin data set several times and in case (2) someone tries to spend a coin data set although he/she has no credit (anymore).

In the WO 2016/200885 A1 describes a method for encrypting a monetary amount transacted in a blockchain ledger, whereby the verifiability of the transaction is retained. A concealment amount is added to an input value. Then an output value is generated and encrypted. Both the input value and the output value are within a range of values, with a sum of any two values within the range not exceeding a threshold. The sum of the encrypted input value and the encrypted output value can be equal to zero. Range checks, called range proofs, are associated with each of the input values and the output value. These range checks prove that the input value and the output value fall within the range of values. In this procedure, a blockchain technology is necessary, which, after receiving a coin record, must be called in order to validate the coin record.

Another example payment system is in the patent applications WO 2020/21337 A1 and WO 2020/212331 A1 described. There, electronic coin data records are masked and registered anonymously in a coin register in order to enable every participant in the payment system to check the validity of an electronic coin data record. With the registration of a masked electronic coin record, area verifications are also performed to prove that no new money has been generated and also to prove ownership.

In this exemplary payment system from WO 2020/21337 A1 and WO 2020/212331 A1 Zero-knowledge proofs are used as area proofs to verify that (1) the monetary amount of an electronic coin record is not negative, that (2) the electronic coin record was validly generated, and/or that (3) the monetary amount and the amount of obfuscation of the electronic coin record is known to the area evidencing preparer.

These well-known area proofs involve complex calculations and the transmission of large amounts of data and thus delays in the payment process. In particular, when using resource-restricted security elements such as smart cards or eUICC as subscriber units, the performance of the payment system is significantly impaired.

It is therefore the object of the present invention to create a method and a payment system in which a payment transaction between participants in a public payment system can be configured more easily, which is nevertheless secure and flexible. In particular, direct and anonymous payment should be created between the participants in the payment system. The exchanged electronic coin data sets should be confidential to other system participants, but each system participant allow mer to perform basic checks on the electronic coin record, namely the detection of multiple dispensing attempts; detecting attempts to pay with non-existent monetary amounts; and displaying ownership by the creator of the proof of ownership. The area verifications required for this should be simple and only require a small amount of data to be transmitted without having to disclose the (unmasked) electronic coin data set in whole or in part.

SUMMARY OF THE INVENTION

The tasks are solved with the features of the independent patent claims. Further advantageous configurations are described in the dependent patent claims.

The object is achieved with a method for providing a verification data set relating to an electronic coin data set by a subscriber unit of an electronic payment system, the electronic coin data set having a monetary amount and an obfuscation amount. The method comprises the following method steps: generating a first random number and a second random number; calculating, by the subscriber unit, a hash by applying a hash function using the first random number and the second random number; calculating, by the subscriber unit, a first verification parameter using the first random number and the monetary amount of the electronic coin record; calculating, by the subscriber unit, a second verification parameter using the second random number and the amount of obfuscation of the electronic coin record; and sending, by the subscriber unit, the verification data set relating to the electronic coin data set, the verification data set comprising the scatter value, the first verification parameter and the second verification parameter. This verification procedure is also called simplified zero-knowledge proof.

An Evidence Record is a record containing Evidence Record data elements. The verification data record makes it possible to indicate the possession of the electronic coin data record by another participant in the electronic payment system without revealing a data element of the electronic coin data record. This verification record increases confidence during a payment transaction with electronic coin records.

The verification data set is preferably provided upon direct request. To this end, the subscriber unit receives a request to provide a verification data record for an electronic coin data record. This request is preferably made after the electronic coin data record has been transmitted to the requesting entity, for example another subscriber unit or a coin register. This means that a proof data record is not generated with each transmission, which means that computing resources and data volumes can be reduced in the transmission per payment transaction.

Alternatively, with each transmission of an electronic coin data set or with each modification to an electronic coin data set, a verification data set is automatically generated and made available to the payment system (for example the coin register). The transmission of the electronic coin data record to another subscriber unit can then also include the sending of the verification data record to the coin register and/or also (in particular in advance) to this subscriber unit. This increases the security of the payment system, because each recipient of the proof data record can promptly check the validity of the electronic coin data record (or have it checked).

With this verification data record, the subscriber unit providing the verification data record proves in particular that it is in possession of the monetary amount of the electronic coin data record and the concealed amount of the electronic coin data record. To confirm the verification, a recipient of the verification data set can use a masked electronic coin data set that corresponds to the electronic coin data set. The masked electronic coin record may have been provided by a coin register or may be self-generated by a subscriber unit for checking the validity of the electronic coin record.

In a preferred embodiment, the subscriber unit also masks the electronic coin record by applying a homomorphic one-way function to the electronic coin record to obtain a masked generated electronic coin record and adding the masked electronic coin record to the verification record prior to the sending step. Masking is in the patent applications WO 2020/21337 A1 and WO 2020/212331 A1 sufficient described and referenced. By masking, a register data set is obtained, which consists in particular of the masked coin data set and now possibly also the verification data set. The register record is registered in the coin register. Part of this registration is checking the evidence record.

The random numbers are generated by one or more random number generators. The random numbers are preferably real random numbers (and not pseudo-random numbers) in order to sufficiently secure the payment method and to significantly reduce the probability of a prediction.

In one embodiment, the random numbers are generated by the subscriber unit itself, and then the subscriber unit has a random number generator.

Alternatively, the random numbers are generated by an external unit and made available securely to the subscriber unit. This external entity can be a coin register or another trusted entity of the electronic payment system.

The first random number is preferably different from the second random number.

The subscriber unit now calculates a hash using a hash function. A scatter function is a mapping rule that maps a large input quantity (here the two random numbers or a masking of them) to a smaller target quantity (the scatter value). A hash function is not injective. The input set can contain elements of different lengths, the elements of the target set can have a fixed length. A spread value function that is known or defined throughout the payment system is preferably used. The hash function can be a hash function, for example a sha-256 algorithm. Other spread value functions can be used, just for example SHA2, SHA3, RIPEMD.... A spread value function is preferably used, which can calculate a spread value with little computing effort. The spread value should have a small amount of data. In the present case, however, the amount of data is not reduced in particular by the scatter value function (the length of the input data is smaller than the length of the scatter value).

Before calculating the scatter value, a homomorphic one-way function can be applied to the first random number and the second random number to obtain a masked random number. Then, the masked random number is used in place of the first random number and the second random number to calculate the scatter value. The one-way homomorphic function used here is the same one-way homomorphic function used to mask the electronic coin record to create a register record.

The subscriber unit now calculates a first verification parameter using the first random number and the monetary amount of the electronic coin record. For example, the first detection parameter is formed by adding the first random number to a product of the previously calculated scatter value and the monetary amount. Other formation rules for calculating the first detection parameter are possible.

The subscriber unit now calculates a second verification parameter using the second random number and the amount of obfuscation of the electronic coin record. For example, the second detection parameter is formed by adding the second random number to a product of the previously calculated scatter value and the amount of concealment. Other formation rules for calculating the second detection parameter are possible.

The verification parameters are data elements of the verification data set. These verification parameters are used by the receiving entity to validate the electronic coin record.

The calculated scatter value is combined with the calculated first detection parameter and the calculated second detection parameter to form the detection data record. These at least three data elements then form the verification data record.

After merging, this record of evidence is then sent via suitable electronic communication channels.

The recipient of the credential record may be another subscriber unit. This other subscriber unit is provided with the verification data set with the transmission of the electronic coin data set or at its request. The electronic payment transaction is preferably only concluded when the other subscriber unit has indicated the authenticity of the electronic coin data record by checking the verification data record and the correctness of the verification.

The recipient of the verification data record can be a coin register. The verification data record is made available to this coin register automatically or after a request for registration of the electronic coin data record, for example a modification to the electronic coin data record. The modification to the electronic coin data record is preferably only considered valid when the coin register has indicated the authenticity of the electronic coin data record by checking the verification data record and the correctness of the verification.

Sending the evidencing record may be part of sending a registration request for a masked electronic coin record from the subscriber unit to the coin register. The registration request may be part of a switching modification (switch), a splitting modification (split) and/or a combining modification (merge). These various modifications are in the patent applications WO 2020/21337 A1 and WO 2020/212331 A1 adequately described and referenced.

In a preferred embodiment, the method used herein is provided by the subscriber unit for providing evidence of a first electronic coin record and a second electronic coin record, each electronic coin record having a monetary amount and an obfuscation amount. The method is based on the method of the previous statements and further comprises: generating a third random number; calculating, by the first subscriber unit, the hash by applying the hash function using the first random number, the second random number and the third random number; calculating, by the first subscriber unit, the second verification parameter using the second random number and the amount of obfuscation of the first electronic coin record; calculating, by the first subscriber unit, a third verification parameter using the third random number and the amount of obfuscation of the second electronic coin record; and sending, by the first subscriber unit, the verification data set relating to the first electronic coin data set and the second electronic coin data set, the verification data set comprising the scatter value, the first verification parameter, the second verification parameter and the third verification parameter. This proof procedure is also called proof of equivalence, English "Equal Value Proof, EVP for short".

This proof of equivalence is also used in the electronic payment process to prove ownership of the electronic coin data record. In addition, the proof of equivalence serves to ensure that the person who created the proof (here the subscriber unit) can prove that the two electronic coin data records relating to the proof data record each have the same monetary value Amount is included, i.e. no new money was generated.

The statements made above regarding the generation of random numbers also apply to the generation of the third random number for this proof of equivalence.

The explanations above for calculating the scatter value also apply to the calculation of the scatter value for this proof of equivalency.

The statements above regarding the calculation of the verification parameters also apply to the calculation of the three verification parameters for this verification of equivalence. The calculation of the second verification parameter is specified in such a way that the obfuscation amount of the first electronic coin data record is used for this purpose.

The above statements on sending the verification data set also apply to sending the verification data set for this proof of equivalence.

For the proof of equivalence, a (the) homomorphic one-way function is preferably applied to the first random number and the second random number to obtain a first masked random number. In addition, the homomorphic one-way function is applied to the first random number and the third random number to obtain a second masked random number. The first masked random number is matched with the second mas linked random number, only preferably concatenated (= concatenation). Concatenation is a combination of two sets (here first masked random number and second masked random number) to form a new set (concatenated masked random number). The linked set consists of all combinations of the elements of both sets using a normally non-commutative operation. As a rule, the concatenation of the elements is used as an operation.

The proof is provided in particular as part of a switching modification (switch) of the first electronic coin data set to the second electronic coin data set in order to indicate to the coin register that no new monetary value was generated with the second coin data set to be switched. With the changeover modification, the first electronic coin data set is switched over to the second electronic coin data set, with the monetary amounts of both electronic coin data sets being identical. Switching is necessary in order to invalidate the first electronic coin data record received in the payment system and thus avoid double spending. As long as no toggle modification has occurred, the sender of the first electronic coin record could still reissue it to another subscriber unit. The toggle modification is in the patent applications WO 2020/21337 A1 and WO 2020/212331 A1 adequately described and referenced.

In one embodiment, the monetary amount of the second electronic coin dataset is part of the monetary amount of the first electronic coin dataset. This is achieved, for example, in a splitting modification by the subscriber unit, preferably without registration and checking in the coin register. The split modification is in the patent applications WO 2020/21337 A1 and WO 2020/212331 A1 adequately described and referenced.

For the calculation of the scatter value by the subscriber unit, a division factor of the monetary amounts is then also used when applying the scatter value function using the first random number, the second random number and the third random number. This division factor, as an additional parameter of the verification data record, enables a quick check to be made that no new sum of money was generated with the division.

For this purpose, the remaining monetary amount from the subtraction of the monetary amount of the first electronic coin dataset and the monetary amount of the second electronic coin dataset is preferably greater than zero.

A further aspect of the invention proposes a method for checking proof of an electronic coin data set by a second subscriber unit or a coin register of a payment system. This checking method comprises the following method steps: receiving, from a first subscriber unit, a verification data record of the payment system, the verification data record including a scatter value, a first verification parameter and a second verification parameter; calculating, by the second subscriber unit, a hash value by applying a hash function using the first detection parameter and the second detection parameter; comparing the received scatter value from the detection data set with the calculated scatter value; indicating the correctness of the evidence to the first subscriber unit if the comparing step determines that the received hash value from the evidence record matches the calculated hash value.

This calculated scatter value for checking the scatter value of the detection data set is calculated using the same scatter value function that was used to calculate the scatter value of the detection data set.

The notification is sent to the first subscriber unit as a signed response to the received credential record. The signature of the coin register increases the authenticity of the display and increases confidence in the payment transaction.

If the proof is correct, the electronic coin data record can be registered in the coin register of the electronic payment system. An existing register data set can be expanded to include the received verification data set. It is then also possible to check the electronic coin data record again at a later point in time.

In one embodiment of the method, the electronic coin data record is received by an issuer entity and/or another subscriber unit and a register data record relating to the received electronic coin data record is queried from the coin register.

The method described above is preferably only carried out when a register data record for this electronic coin data record is present in the coin register.

The method steps mentioned, which are carried out in a subscriber unit, are preferably carried out in a secure runtime environment, for example a security element of the respective subscriber unit.

A further aspect of the invention provides a coin register for registering register data records, in particular masked electronic coin data records, in an electronic payment system. The coin register includes a data interface that is set up to receive verification data records and to display the correctness of the verification according to the type described above.

The coin register may be configured to apply the spread value function to generate the spread value; compare the generated scatter value with the received scatter value of the evidence data set; and register a register record in the coin register. The subscriber unit thus ensures that the coin data set to be transmitted is available and valid.

The coin register preferably includes a checking unit for checking the verification data set according to the method of the type described above. The checking unit can also be set up to check the validity of the electronic coin data sets corresponding to the register data sets.

Preferably, the coin register registers each masked electronic coin record as a record record along with the evidencing record or at least using the evidencing record.

In a further aspect of the invention, a payment system for paying with electronic coin data records is provided. The payment system comprises a coin register set up to check a verification data set and to register the electronic coin data sets; and subscriber units which are set up to carry out payment transactions by transmitting the electronic coin data records and to provide verification data records relating to the electronic coin data records according to the method of the type described above.

In a further aspect of the invention, a subscriber unit is set up for directly transmitting electronic coin data records to another subscriber unit in an electronic payment system and set up for executing payment transactions by transmitting electronic coin data records and for providing verification data records relating to the electronic coin data records to another subscriber unit or a Coin register of the payment system according to the method of the type described above with a means for accessing a data memory, wherein at least one electronic coin data set is stored in the data memory; an interface for issuing the at least one electronic coin record to the other subscriber unit and for sending and receiving verification records related to the electronic coin records; and a computing unit that is set up to carry out the method steps according to the method of the type described above.

The subscriber unit can transmit the electronic coin record directly to a second subscriber unit. The subscriber unit or the second subscriber unit sends a registration request and receives a registration confirmation from the coin register as an indication of the correctness of the credential record. With the registration confirmation, the coin register indicates to the respective subscriber unit that a verification of the registration request was successful, in particular that the electronic coin data record is genuine and the subscriber unit possesses this electronic coin data record.

In a further aspect of the invention, a computer program product is executably installed in a subscriber unit or a coin register of a payment system and has means for carrying out the method steps according to the method of the type described above.

An electronic coin data record is in particular an electronic data record that represents a monetary (=monetary) amount and is colloquially referred to as a “digital coin” or “electronic coin”. Preferably lies an electronic coin data prefix of a central bank currency or "central bank digital currency, CBDC". In the method, this monetary amount can change from a first terminal to another terminal. A monetary amount (asset) is understood below to mean a digital amount that can be credited to an account at a financial institution, for example, or can be exchanged for another means of payment. An electronic coin record thus represents cash in electronic form.

An electronic coin data record for transferring amounts of money differs significantly from the electronic data record for data exchange or data transfer, for example a register data record, since a classic data transaction based on a question-answer principle or on an intercommunication between the data transfer partners, for example the subscriber unit and a Coin register (also referred to as the supervisory authority, monitoring register, transaction register, verifier) takes place. Within the framework of authentication, identification or identification data can be exchanged, which can provide conclusions about a subscriber ID and/or an identification number of a natural person as a user (participant) of the payment system. This means that anonymous payment is not possible. An electronic coin data set, on the other hand, is anonymous, unique, unambiguous and is part of a security concept. In principle, an electronic coin data record contains all data elements that are required for a receiving entity in order to receive the amount of money to be transmitted. In contrast to copying electronic data records, i.e. duplicating digital data, a valid electronic coin data record may only exist once in the payment system. This system requirement must be observed in particular when transferring electronic coin data records.

An electronic coin data set can be present in a large number of different forms and can thus be exchanged via different communication channels, communication protocols, communication layers, summarized below as interfaces. This creates a very flexible exchange of electronic coin data sets.

The electronic coin data set can be presented in the form of a file, for example. A file consists of data that is related in terms of content and is stored on a data carrier, data storage device or storage medium. Each file is initially a one-dimensional sequence of bits, which are usually interpreted in groups of bytes. An application program or an operating system of a security element and/or a subscriber unit interprets this bit or byte sequence as text, an image or a sound recording, for example. The file format used can be different, for example it can be a pure text file that represents the electronic coin data record. In particular, the monetary amount and a blind signature are displayed as a file.

The electronic coin data record is, for example, a sequence of American Standard Code for Information Interchange, or ASCII for short, characters. In particular, the monetary amount and a blind signature are shown as this sequence.

The electronic coin record can also be converted from one representation form to another representation form in a subscriber unit. For example, the electronic coin data record can be recorded as a QR code in a subscriber unit and output by the subscriber unit as a file or character string.

In particularly preferred refinements, electronic coin data records are only exchanged directly between secure runtime environments of the subscriber units, ie in particular between security elements (such as chip cards, security modules, SIM modules, TPMs, NFC modules or eUICCs).

These different forms of representation of one and the same electronic coin data record enable a very flexible exchange between subscriber units or security elements of different technical equipment using different transmission media (air, paper, wire) and taking into account the technical design of subscriber unit(s). The selection of the form of representation of the electronic coin data records is preferably made automatically, for example on the basis of recognized or negotiated transmission media and device components. In addition, a user of a subscriber unit can also select the form of representation for exchanging (=transmitting) an electronic coin data set.

In an advantageous embodiment, the electronic coin data record has a monetary amount as a data element, ie a date that represents a monetary value of the electronic coin data record, and an obfuscation amount, for example a random number, as a data element. The amount of concealment is not known to the coin register. The obfuscation amount is - except in the first layer (direct transaction layer) - a secret data element. An electronic coin data set is uniquely represented by these at least two data elements (monetary amount, concealment amount). Anyone who has access to these data elements of an electronic coin record can use this electronic coin record to pay in a payment transaction. Knowledge of these two data elements (monetary amount, concealment amount) is therefore equivalent to possession of the digital money. This electronic coin record can be directly transmitted between two subscriber units. To exchange digital money (= payment transaction), only the transfer of the monetary amount and the concealment amount is necessary.

In addition, the electronic coin data record can have further data elements, for example which currency the monetary amount represents, by which issuing authority it was generated and/or a signature of an issuing authority.

A subscriber unit of the payment system can be, for example, a mobile terminal such as a smartphone, a tablet computer, a computer, a server or a machine.

Alternatively or additionally, the subscriber unit can also be a device such as a wearable, smart card, machine, tool, vending machine or even a container or vehicle. A subscriber unit is thus either stationary or mobile. The subscriber unit is preferably designed to use the Internet and/or other public or private networks in order to transmit electronic coin data records and/or register data records or queries relating thereto. For this purpose, the subscriber unit uses a suitable connection technology, for example Bluetooth, LoRa, NFC and/or WiFi, and has at least one corresponding interface. The subscriber unit can also be designed to be connected to the Internet and/or other networks by means of access to a mobile radio network.

An application brought ready for operation (installed) on the subscriber unit can initiate and control a transmission of a coin data set to another subscriber unit by using input and/or output means of the respective subscriber unit. For example, amounts of electronic coin data records can be displayed and the transmission process can be monitored using the application. This or another ready-to-operate application can initiate and control the transmission of a register data record to a coin register of the payment system by using input and/or output means of the respective subscriber unit. For example, the checking of electronic coin data sets can be initiated by means of the application, for example by generating register data sets and/or sending check requests to the coin register.

In a preferred embodiment, the subscriber unit has an interface for issuing electronic coin data sets.

An interface for issuing (=sending) the at least one electronic coin data set is, for example, a protocol interface for wirelessly sending the electronic coin data set to the other security element via a subscriber unit using a communication protocol for wireless communication. In particular, near-field communication is provided, for example by means of a Bluetooth protocol or NFC protocol or IR protocol; WLAN connections or mobile radio connections are conceivable as an alternative or in addition. The electronic coin data set is then adapted according to the protocol properties or integrated into the protocol and transmitted.

An interface for outputting the at least one electronic coin data record is, for example, a data interface for providing the electronic coin data record to the other subscriber unit using an application. In contrast to the protocol interface, the electronic coin data set is transmitted here using an application. This application then transfers the electronic coin data record in an appropriate file format. A specific file format for electronic coin data records can then be used, for example an ASCII character string or a text message, for example SMS, MMS, instant messenger message, particularly preferably an APDU character string. Alternatively or additionally, the transmission takes place via the previously mentioned application of the subscriber unit and/or the security element.

In a preferred embodiment, the subscriber unit also has an interface for receiving electronic coin data records.

In a preferred embodiment, the interface for receiving the at least one electronic coin data record is an electronic detection module of the security element or terminal device, set up to detect an electronic coin data record presented in visual form. The detection module is then, for example, a camera or a barcode or QR code scanner.

In a preferred embodiment, the interface for receiving the at least one electronic coin dataset is a protocol interface for wirelessly receiving the electronic coin dataset from another security element or end device using a communication protocol for wireless communication. In this case, in particular, near-field communication is provided, for example by means of a Bluetooth protocol or NFC protocol or IR protocol. Alternatively or additionally, WLAN connections or mobile radio connections are conceivable.

In a preferred embodiment, the subscriber unit comprises at least one security element reader, set up to read a security element; a random number generator; and/or a communication interface to a vault module and/or bank institution with access to a bank account to be authorized.

In the present case, a subscriber unit of the payment system can have a security element or itself be a security element in that at least one electronic coin data record is securely stored. Electronic coin data records can be transmitted with the aid of terminal devices as subscriber units, which may be logically and/or physically connected to the security elements. The application(s) installed ready for operation on the subscriber unit can control or at least initiate at least parts of the transmission method and/or parts of the registration method and/or parts of the checking method.

In a preferred embodiment, a security element is installed ready for operation in a subscriber unit. This ensures that electronic coin data sets are transmitted and/or register data sets are generated and encrypted and possibly also sent without manipulation. In one embodiment, the register data set is created in the security element and then sent to the coin register by the subscriber unit.

A security element is a technical resource-limited facility. A security element is, for example, a special computer program product, in particular in the form of a secure runtime environment within an operating system of a terminal, English Trusted Execution Environments, TEE, or eSIM software, stored on a data memory, for example a subscriber unit, such as (mobile) terminal, a machine or an ATM. Alternatively or additionally, the security element is designed, for example, as special hardware, in particular in the form of a secure hardware platform module, English Trusted Platform Module, TPM or as a chip card, UICC or an embedded security module, eUICC, iUICC, eSIM. The security element provides a trustworthy environment and thus has a higher level of trust than a terminal device in which the security element is possibly integrated ready for operation.

In contrast to a register data record, an electronic coin data record can preferably not be generated by a subscriber unit or a security element or the coin register. The generation of an electronic coin data record (and also its destruction or deletion) is carried out by the issuer of the payment system, preferably exclusively by the issuer of the payment system.

One or more electronic coin data records can be stored securely in a subscriber unit or a security element, for example a large number of electronic coin data records can be stored securely in a data memory exclusively assigned to a subscriber unit or a security element. The data memory then represents an electronic purse application, for example. This data memory can, for example, be internal, external or virtual to the security element.

In a simple case, the data store is an internal data store of the subscriber unit or the security element. The electronic coin data sets are stored here. This ensures easy access to electronic coin data records.

The data memory is, for example, a data memory that is physically remote from the subscriber unit or the security element, ie external, also called online memory. Thus, the security element or the subscriber unit has only one means of access to the electronic coin data records that are stored externally and thus securely. In particular, if the security element or subscriber unit is lost or if the security element or subscriber unit malfunctions, the electronic coin data sets are not lost. Since owning the (unmasked) electronic coin records is equivalent to owning the monetary amount, using external data storage allows money to be stored and managed more securely.

For example, the data memory is a shared data memory that at least one other subscriber unit can access, each of which has an application, with this application being set up to communicate with the coin register for the corresponding registration of electronic coin part data records.

The security element could also have received electronic coin data records from less trustworthy units, such as subscriber units, ie a terminal or a machine, for example via an import/export function of the security element. Electronic coin records obtained in this way that are not obtained directly from another security element are considered less trustworthy. It could be a requirement of the payment system to have to check such electronic coin data records for validity using the coin register or, through an action (modification) by the receiving security element, to transfer the electronic coin data record to the receiving security element before it can be passed on.

The communication between two subscriber units and/or the coin register, if necessary by means of the respective security elements, can be wireless or wired, or e.g. also optical, preferably via QR code or barcode, and can be used as a secure channel, e.g. between applications of the Subscriber units be trained. The optical path can include, for example, the steps of generating an optical code, in particular a 2D code, preferably a QR code, and reading in the optical code. In this way, the electronic coin data sets can be transmitted in any format. This implies that it communicates, i.e. can be transmitted, on any channel. They do not have to be saved in a fixed format or in a specific program.

For example, two subscriber units set up a local wireless communication connection via the protocol of which the transmission between the two security elements located therein is then introduced.

The transmission of the electronic coin data record is secured, for example, by cryptographic keys, for example a session key negotiated for an electronic coin data record exchange or a symmetric or asymmetric key pair.

By communicating between subscriber units, for example via their security elements, the exchanged electronic coin records are protected from theft or tampering. The level of security elements thus complements the security of established blockchain technology.

In a preferred embodiment, the coin data records are transmitted as APDU commands. For this purpose, the coin data record is preferably stored in an (embedded or integrated) UICC as a security element and is managed there. An APDU is a combined command/data block of a connection protocol between the UICC and a terminal. The structure of the APDU is defined by the ISO-7816-4 standard. APDUs represent an information element of the application layer (layer 7 of the OSI layer model).

Transmission of an electronic coin record is preferably between two security elements to create a trusted environment. In this case, the logical transmission of the electronic coin data record is direct, whereas a physical transmission may involve one or more intermediary entities, for example one or more subscriber units to the Preparation of the operational readiness of the security element(s) and/or a remote data storage service in which a purse application with electronic coin data sets are physically stored.

Security elements can transfer electronic coin data sets among one another and then continue to use them directly - without register check(s), especially if the payment system requires that electronic coin data sets of security elements are to be regarded as valid per se.

Transmission of the electronic coin data set between the first and the second security element can be integrated in a transmission protocol between two subscriber units and/or integrated in a secure channel between two applications of the respective subscriber unit. In addition, the transmission can include an Internet data connection to an external data store, for example an online store.

In order to securely configure a transmission protocol between subscriber units and/or the coin register, the electronic coin data records are managed by the respective subscriber units, for example by security elements integrated there, and also transmitted by them. In a preferred embodiment, the security element is introduced into the subscriber unit ready for operation. In this case, the subscriber unit can contain an application through which a user (=subscriber) controls a payment process and in this payment process accesses electronic coin data records of the security element.

The electronic coin data record is transmitted from the security element of a first subscriber unit to the (second) security element of another subscriber unit, for example. In this case, a subscriber unit-to-subscriber unit transmission link can be set up, via which, for example, a secure channel is set up between the two security elements, via which the electronic coin data record is then transmitted.

The electronic coin data record (to be transferred or modified) is registered in a coin register of the payment system. Thus, for example, the establishment of a communication link to the coin register is provided for registering the electronic coin data record. This communication connection does not necessarily have to be present during the transmission process (payment process). The coin register is preferably provided for the administration and checking of masked electronic coin data records. The coin register can also manage and check other (non-payment) transactions between subscriber units.

The coin register—as part of the second layer—is, for example, a database in which a register data record is generated and/or stored. A register record is a record that allows the validity, status, history and/or whereabouts of an electronic coin record to be known and/or verified. A register data record is preferably uniquely assigned to an electronic coin data record. The register record is for verification only and cannot be used to replace the electronic coin record for payment transactions.

For example, the coin register can be a decentralized public database. This database makes it easy to check electronic coin data records for their validity and to prevent "double spending", i.e. multiple issues, without the transmission itself being registered or logged. The database, for example a distributed ledger technology, DLT, describes a technique for networked computers that come to an agreement about the sequence of certain transactions and that these transactions update data. It corresponds to a decentralized management system or a decentralized database.

Alternatively, the coin register is a centrally managed database, for example in the form of a publicly accessible data store or as a hybrid of a central and decentralized database. For example, the coin register and the monitoring register are designed as a service server of the payment system.

If the coin register is a remote entity, the subscriber unit and also the issuer entity preferably have an interface for communication using a standard Internet communication protocol, for example TCP, IP, UDP or HTTP. The transmission may include communication over the cellular network.

In a preferred embodiment, the coin register provides a register data set. The register data set has, for example, a masked electronic coin data set corresponding to an electronic coin data set as a data element. For example, the masked electronic coin record was provided by a subscriber unit or an issuing entity. Possession of a Masked Electronic Coin Record does not permit disclosure of data elements of the (corresponding) Electronic Coin Record, whereby such Register Record with (only) masked coin records is anonymous in respect of a subscriber identifier and also anonymous in respect of a monetary amount of the Electronic Coin Record. The masking will be explained later.

A register data set has one or more of the following data elements: a signature of the electronic coin data set; an area evidencing of an electronic coin record; a check value of the electronic coin record; a check value related to the electronic coin record; a counter value relating to the electronic coin record; a subscriber identifier of a subscriber unit sending the register data record; a masked electronic coin record; and/or a monetary amount of the electronic coin record. All of these data elements and their function are defined in the appropriate places.

In a further embodiment, the register data record has, for example, as data elements, a masked electronic coin data record and an amount category relating to a monetary amount of the electronic coin data record corresponding to the masked electronic coin data record. Such a register data record with a masked coin data record is anonymous in terms of identity and pseudonymous in terms of amount.

In a further embodiment, the register data record has, for example, as data elements, a coin identifier of an electronic coin data record, a check value of the electronic coin data record and a pseudonym of the subscriber identifier. Such a register data record is pseudonymous in identity and anonymous in terms of amount.

The register data record includes, for example, a verification data record of the type described above.

For example, masked electronic coin records are provided as a data element in the register record or as the register record. These masked electronic coin data sets are registered with their corresponding processing in the coin register. The masking is in the registrations WO 2020/21337 A1 and WO 2020/212331 A1 described and reference is made in this regard. In a preferred embodiment, a validity status of the (masked) electronic coin data record can be derived from this. The validity of the (masked) electronic coin data records is preferably noted (registered) in the coin register. In addition, modifications such as switching, dividing or combining are registered for the individual electronic coin data sets in the coin register. The creation, testing and registration of these modifications is in the applications WO 2020/21337 A1 and WO 2020/212331 A1 described and reference is made in this regard.

The step of registering a register record (or masked electronic coin record) is described in Applications WO 2020/21337 A1 and WO 2020/212331 A1 described and reference is made in this regard. In one embodiment of the payment system, registration of the processing or the processing steps for a respective modification in the coin register can also relate to the registration of test results and intermediate test results relating to the validity of an electronic coin data record in the coin register, in particular the determination of test values and counter values of corresponding electronic coin data records. If processing is final, this is indicated, for example, by corresponding markings or a derived total marking in the coin register. Final processing then decides whether an electronic coin record is valid or invalid. The step of registering is preferably performed when the subscriber unit and/or the security element is connected to the coin register.

The at least one initial electronic coin data record is preferably created by the issuing entity, it being possible for the divided electronic coin data records, in particular electronic partial coin data records, to also be generated by a subscriber unit. Creating and choosing a monetary amount preferably also includes choosing a high entropy obfuscation amount.

The publisher instance is therefore also called a privileged instance or privileged node. privileged node, because only this can create new money in the form of electronic coin records and destroy money, namely by deactivating electronic coin records. The issuing authority can therefore create and destroy monetary amounts for the payment system, and correspondingly control the total monetary amount circulating in the payment system.

The publishing entity is a computing system, which is preferably remote from the first and/or second subscriber unit. After creating the new electronic coin record, the new electronic coin record is masked in the issuer instance by applying the homomorphic one-way function to the new electronic coin record to obtain a masked new electronic coin record accordingly.

Furthermore, additional information needed to register the creation of the masked new electronic coin record in the remote coin register is computed in the issuer entity. This additional information is preferably proof that the (masked) new electronic coin data record originates from the issuing authority, for example by signing the masked new electronic coin data record. In one embodiment, it can be provided that the issuing entity signs a masked electronic coin data record with its signature when the electronic coin data record is generated. The signature of the issuing authority is stored in the coin register. The signature of the issuing authority is different from the signature generated by a subscriber unit or a security element.

The issuing entity is preferably a computer entity of a central bank.

The coin register and the issuer entity are preferably arranged in a common server entity or are present as a computer program product on a server and/or a computer. The publishing entity is preferably accessed via an http protocol.

The modifications (switching, splitting, connecting) and the actions (creating and deactivating (returning)) are each triggered by a corresponding create, switch, split, connect or deactivate command (return commands).

The process is not limited to one currency. For example, the payment system can be set up to manage different currencies from different publishers. The payment system is set up, for example, to convert (=change) an electronic coin data record in a first currency into an electronic coin data record in a different currency. This switching is also a modification of the electronic coin record. With the change, the original coin record becomes invalid and is deemed returned. Flexible payment with different currencies is therefore possible and user-friendliness is increased.

The method also enables the electronic coin data record to be converted into book money, ie for example the monetary amount can be redeemed in an account of the participant in the payment system. This repositioning is also a modification. Upon redemption, the electronic coin record becomes invalid and is deemed to have been returned.

character list

The invention and further embodiments and advantages of the invention are explained in more detail below with reference to figures, with the figures merely describing exemplary embodiments of the invention. Identical components in the figures are provided with the same reference symbols. The figures are not to be regarded as true to scale; individual elements of the figures may be exaggerated in size or exaggeratedly simplified.

• 1 ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung;
• 2 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens zum Bereitstellen eines Nachweisdatensatzes;
• 7 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens zum Prüfen eines Nachweisdatensatzes;
• 4 ein Ausführungsbeispiel einer Datenstruktur in einem Münzregister;
• 5 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechende Verarbeitungsschritte eines Münzdatensatzes;
• 6 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechende Verarbeitungsschritte eines Münzdatensatzes; und
• 7 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechende Verarbeitungsschritte eines Münzdatensatzes.

Show it:

• 1 an embodiment of a payment system according to the invention;
• 2 an exemplary embodiment of a method flow chart of a method according to the invention for providing a verification data record;
• 7 an embodiment of a method flow chart of a method according to the invention for checking a verification data record;
• 4 an embodiment of a data structure in a coin register;
• 5 an embodiment of a process flow chart of a method according to the invention and corresponding processing steps of a coin data set;
• 6 an embodiment of a process flow chart of a method according to the invention and corresponding processing steps of a coin data set; and
• 7 an embodiment of a process flow chart of a method according to the invention and corresponding processing steps of a coin data set.

FIGURE DESCRIPTION

the 1 shows an embodiment of a payment system BZ according to the invention. The blocks and arrows of the payment system BZ shown in dashed lines are optional. The payment system BZ includes at least two security elements SE1 and SE2. The SE1 and SE2 can be installed ready for operation in the respective terminals M1 and M2 and logically or physically connected to the respective terminal M1 and M2. M1 and M2 can be subscriber units TE1, TE2.

In the payment system 1 is an optional issuer entity 1 that creates an electronic coin record C, also called CBDC. The publishing entity 1 is, for example, a server entity of a central bank. A register data set RDS, for example a masked electronic coin data set Z, is generated for the electronic coin data set C and registered in a coin register 2 of the payment system BZ in a step 104 . In the optional step 102, the electronic coin data set C is issued by the issuer entity 1 to the first terminal M1. The register data record RDS, for example the masked electronic coin data record Z, is output to the coin register 2 in step 104, for example by the issuing entity 1 directly or via the first terminal M1. The register data set RDS, for example the masked electronic coin data set Z, is alternatively generated by the first terminal M1 (or second terminal M2) and sent to the coin register 2 in step 104.

Steps 104 and 105 can follow steps 104 and 105 of 5 correspond to. An action or modification (split, connect, switch, transfer, deactivate) on the eMD C can be one of the actions of the 5 until 7 correspond to. These modifications are also exemplified in the patent applications WO 2020/21337 A1 and WO 2020/212331 A1 described and will not be discussed in detail here.

For example, an electronic coin data record is formed from a concealment amount r _i and an amount in money's worth. The concealment amount r _i is only known in a direct transaction layer of the payment system BZ and in the issuing entity 1 . The concealment amount r _i is secret for the other instances of the payment system BZ, ie also for the coin register 2 . The concealment amount r _i is, for example, a positive random number. The generation takes place, for example, by means of a real random number generator. A range of values for the amount of obfuscation r _i is, for example, [0,n), where n is the order of a cryptography method based on elliptic curves, for example an Elliptic Curve Digital Signature Algorithm, ECDSA for short, preferably of secp256r1, which is based on curve y ² = x ³ + 7 of a Galois field. The implementation mechanisms for generating the obfuscation amount r _i must ensure that an identical obfuscation amount r _i is not generated for another electronic coin record.

The concealment amount r _i is linked to a monetary amount υ _i . The monetary amount υ _i is an integer value, for example. It is preferably of the 32-bit unsigned integer value data type. The monetary amount υ _i has, for example, a limited value range of powers of two. The value zero ("0") as monetary amount υ _i could be invalid. An i-th electronic coin data set according to the invention could read: $$C_i=\left\{v_i;{\mathrm{right}}_i\right\}$$

A valid electronic coin record C can be used for payment. The owner of the two values υ _i and r _i therefore owns the digital money. The digital money is defined by a pair consisting of a valid electronic coin data set Ci and a corresponding register data set RDS _{i ,} for example a masked electronic coin data set Z _i . Z _i represents a point in a cryptography method based on elliptic curves, for example an Elliptic Curve Digital Signature Algorithm, ECDSA for short, preferably secp256r1. Z _i may be encoded in an uncompressed form as specified in Standards for Efficient Cryptography, Elliptic Curve Cryptography; Section 2.3.3 at is specified playfully. For example, a masked electronic coin data set Z _i as RDS, is obtained by applying a homomorphic one-way function f(C _i ) according to equation (2): $$Z_i=ƒ\left(C_i\right)$$

wobei H und G Generatorpunkte einer Gruppe G, in der das diskrete Logarithmusproblem schwer ist, mit den Generatoren G und H, für die der diskrete Logarithmus der jeweils anderen Basis unbekannt ist. Beispielsweise sind G und H Generatorpunkte einer elliptischen Kurvenverschlüsselung, ECC, - also private Schlüssel der ECC, sind. Diese Generatorpunkte G und H müssen in der Art gewählt werden, dass der Zusammenhang von G und H nicht öffentlich bekannt ist, sodass bei: $$G=n\cdot H$$

die Verknüpfung n praktisch nicht auffindbar sein darf, um zu verhindern, dass der monetäre Betrag υ_i manipuliert wird und trotzdem ein gültiges Z_i berechnet werden könnte.This function f(C _i ) is public, ie every system participant can call up and use this function. This function f(C _i ) is defined according to equation (3): $$Z_i=v_i\cdot H+{\mathrm{right}}_i\cdot G$$

where H and G are generator points of a group G in which the discrete logarithm problem is hard, with generators G and H for which the discrete logarithm of the other base is unknown. For example, G and H are generator points of an elliptic curve encryption, ECC, - ie private keys of the ECC are. These generator points G and H must be chosen in such a way that the connection between G and H is not publicly known, so that: $$G=n\cdot H$$

the link n must be practically impossible to find in order to prevent the monetary amount υ _i from being manipulated and a valid Z _i still being able to be calculated.

Equation (3) is a “Pederson commitment for ECC”, which ensures that the monetary amount υ _i can be granted to a coin register 2, i.e. “committed”, without disclosing it to the coin register 2.

Only the RDS, for example the masked coin data set Z _{i ,} is sent (revealed) to the coin register 2, which is 1 as step 104 (registration, registration request), but not the electronic coin record C.

Even if encryption based on elliptic curves is or is described in the present example, another cryptographic method which is based on a discrete logarithmic method would also be conceivable.

Due to the entropy of the amount of concealment r _i , equation (3) makes it possible for a cryptographically strong Z _i to be obtained even with a small value range for monetary amounts υ _i . Thus, a simple brute force attack by merely estimating monetary amounts υ _i is practically impossible.

Equation (3) is a one-way function, which means that calculating Z _i from C _i is easy because an efficient algorithm exists, whereas calculating C _i from Z _i is very difficult because there is no solvable one in polynomial time algorithm exists.

In addition, equation (3) is homomorphic for addition and subtraction, which means that: $$Z_i+Z_j=\left(v_i\cdot H+{\mathrm{right}}_i\cdot G\right)+\left(v_j\cdot H+{\mathrm{right}}_j\cdot G\right)=\left(v_i+v_j\right)\cdot H+\left({\mathrm{right}}_i+{\mathrm{right}}_j\right)\cdot G$$

Thus addition operations and subtraction operations can be carried out both in the direct transaction layer 3 and also in parallel in the coin register 2 without the coin register 2 having knowledge of the electronic coin data sets C _i . The homomorphic property of equation (3) enables monitoring of valid and invalid electronic coin records Ci based solely on the masked coin records Zi _and ensuring that no new monetary amount υ _j has _been created.

wobei gilt: $$v_i=v_j+v_k$$

$$r_i=r_j+r_k$$

Due to this homomorphic property, the coin data set C _i can be divided according to equation (1) into: $$C_i=C_j+C_k=\left\{v_j;{\mathrm{right}}_j\right\}+\left\{v_k;{\mathrm{right}}_k\right\}$$

where: $$v_i=v_j+v_k$$

$${\mathrm{right}}_i={\mathrm{right}}_j+{\mathrm{right}}_k$$

For the corresponding masked coin data sets: $$Z_i=Z_j+Z_k$$

With Equation (9), for example, a symmetrical or asymmetrical splitting as a modification or a “symmetrical or asymmetrical splitting” processing step 110 of a coin data set C according to FIG 6 be checked without the coin register 2 having knowledge of C _i , C _j , C _k . In particular, the condition of equation (9) is tested to validate split coin data sets C _j and C _k and invalidate coin data set C _i . Such a splitting 110 of an electronic coin record C _i is shown in FIG 6 shown.

Electronic coin data records C can also be merged (connected) 109 in the same way, see in this regard 7 and the explanations for it.

According to the invention, it must now be checked whether (not permitted) negative monetary amounts are registered. An owner (TE1) of an electronic coin data set C _i must be able to prove to the coin register 2 and/or another subscriber unit TE2 that all monetary amounts υ _i in a processing operation are within a value range of [0, . . . , n]. , without disclosing the coin data record C _i , ie the monetary amount υ _i or the concealment amount r _i , to the coin register 2 . These range proofs are also called "range proofs". Two proofs are presented below, the provision of which is based on the procedure of the 2 and testing according to the procedure of 3 be explained.

A first proof is the simplified zero-knowledge proof, hereinafter referred to as the simplified zero-knowledge proof, or "simplified ZKPR" for short. For this purpose, a verification data record NDS _{i_ZKPR} relating to an electronic coin data record C _i is provided by TE1.

First, with step 201, a first random number k ₀ and a second random number k ₁ are generated. This can be done in TE1 with a random number generator. Only alternatively does the coin register 2 or the issuer entity 1 provide the random numbers k ₀ , k ₁ (possibly secured). In step 202, the random numbers k ₀ , k ₁ are masked with equation (3). $$K_i=k_0\cdot H+{\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1\cdot G$$

In step 204, a scatter value e is then calculated using the random numbers k ₀ , k ₁ . The scatter value function h () used for this is the same and known throughout the payment system. In the present example: $$e=H\left(K_i\right)=H\left(k_0\cdot H+{\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1\cdot G\right)$$

und ein zweiter Nachweisparameter s₁ auf Basis der zweiten Zufallszahl k₁, des Streuwerts e und dem Verschleierungsbetrag r_i des elektronischen Münzdatensatzes C_i berechnet: $$s_1=\left(k_1+e\cdot r_i\right)$$

In step 205, a first verification parameter s ₀ based on the first random number k ₀ , the scatter value e and the monetary amount ν _i of the electronic coin data set C _i $$s_0=\left(k_0+e\cdot v_i\right)$$

and a second verification parameter s ₁ calculated on the basis of the second random number k ₁ , the spread value e and the concealment amount r _i of the electronic coin data set C _i : $$s_1=\left({\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1+e\cdot {\mathrm{right}}_i\right)$$

The scatter value e, the first verification parameter s ₀ and the second verification parameter s ₁ are sent as a verification data record NDS _{i_ZKPR} from the TE1 in step 206, which can be evaluated as a publication of the NDS _{i_ZKPR} : $$ND{S}_{i\_ZKPR}=\left\{e,s_0,s_1\right\}$$

A masked coin data set Z _i has already been created using equation (3) or created as part of the verification creation according to optional step 205 . This Z _i can be sent together with the NDS _{i_ZKPR} as RDS _i from TE1. The NDS _{i_ZKPR} does not disclose any data elements of the electronic coin data set C _i and can therefore be sent to the coin register 2, for example as part of a registration request in step 104. The NDS _{i_ZKPR} can also be part of the data when transmitting an electronic coin data set C _i to TE2 as part of a payment transaction are sent.

This NDS _{i_ZKPR} a masked coin data set Z _i can now be checked in the coin register 2 or a TE2, which through the process steps 3 is shown. For this purpose, the NDS _{i_ZKPR} is received in step 301 in the coin register 2 or the TE2. In step 302, a scatter value e' is calculated on the basis of the received NDS _{i_ZKPR} : $$e\text{'}=H\left(s_0\cdot H+s_1\cdot G-e\cdot Z_i\right)$$

In this case, the scatter value e is compared with the scatter value e' in step 303 . If both scatter values e, e' are identical, then the following applies: $$\begin{array}{c}e\text{'}=H\left(s_0\cdot H+s_1\cdot G-e\cdot Z_i\right)\\ =H\left(k_0\cdot H+e\cdot v_i\cdot H+{\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1\cdot G+e\cdot {\mathrm{right}}_1\cdot G-e\cdot v_i\cdot H-e\cdot {\mathrm{right}}_i\cdot G\right)\\ =H\left(k_0\cdot H+{\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1\cdot G\right)\\ =e\end{array}$$

Equation (9e) or (9h) would not be solvable if e could not be eliminated from the archetype of the scatter value function. However, this can only be achieved if the creator of the NDS _{i_ZKPR} has correctly carried out the above-mentioned calculations according to equations (9a) to (9d), which requires knowledge of the monetary amount v _i and the obfuscation amount r _i of the electronic coin data record C _i . If e and e' match, the verification data record is considered correct. This correctness means that the electronic coin data record Ci is owned by _TE1 . This correctness is indicated in step 305. The RDS _i can then be registered in the coin register 2 in step 104 .

A second proof that can be carried out as an alternative to the first proof (simplified ZKPR) is now presented.

The second proof is proof of equivalence, which is carried out in particular to check two coin data records C ₁ and C ₂ which should have the same monetary amount v ₁ =v ₂ =v. This check is used in particular for a switch modification (step 108) in which a C ₁ is to be switched (converted) to a C ₂ or for a split modification (step 110).

The aim of the second proof, in addition to proof of lawful possession (as in the first proof), is now also to prove that no additional money was generated. These two proofs (no additional money + lawful possession) can be carried out together in the second proof, the Equal Value Proof, EVP for short.

The starting point of this EVP are two masked coin data records Z ₁ , Z ₂ , whose associated electronic coin data records C ₁ , C ₂ have the same monetary amount, ie v=v ₁ =v ₂ .

It must now be proven that TE1 knows the electronic coin data records C ₁ , C ₂ and that the two masked coin data records Z ₁ , Z ₂ were granted the same amount v=v ₁ =v ₂ (“committed”).

First, in step 201, a first random number k ₀ , a second random number k ₁ and a third random number k ₂ are generated. This can be done in TE1 with a random number generator. Alternatively, the coin register 2 or the issuer entity 1 provides the random numbers k ₀ , k ₁ , k ₂ (possibly secured). In step 202, the random numbers k ₀ , k ₁ , k ₂ are masked with equation (3). Here two masked random numbers K ₁ and K ₂ are generated: $$\begin{array}{c}{\mathrm{<figure-callout\; id="1"\; label="K"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">K</figure-callout>}}_1=k_0\cdot H+{\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1\cdot \mathrm{<figure-callout\; id="2"\; label="G\; K"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0033.png"\; state="\{\{state\}\}">G</figure-callout>}& \\ K_{}{}_2=k_0\cdot H+{\mathrm{<figure-callout\; id="2"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0033.png"\; state="\{\{state\}\}">k</figure-callout>}}_2\cdot G\end{array}$$

In step 203, both masked random numbers are linked, in particular concatenated: $${\mathrm{<figure-callout\; id="1"\; label="K"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">K</figure-callout>}}_1\Vert {\mathrm{<figure-callout\; id="2"\; label="K"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0033.png"\; state="\{\{state\}\}">K</figure-callout>}}_2$$

In step 204, a scatter value e is then calculated using the random numbers k ₀ , k ₁ , k ₂ (here by concatenating the masked random numbers K ₁ and K ₂ ). The scatter value function h () used for this is the same and known throughout the payment system. In the present example: $$e=H\left({\mathrm{<figure-callout\; id="1"\; label="K"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">K</figure-callout>}}_1\Vert K_2\right)=H\left(k_0\cdot H+{\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1\cdot G\Vert k_0\cdot H+{\mathrm{<figure-callout\; id="2"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0033.png"\; state="\{\{state\}\}">k</figure-callout>}}_2\cdot G\right)$$

und ein zweiter Nachweisparameter s₁ auf Basis der zweiten Zufallszahl k₁, des Streuwerts e und dem Verschleierungsbetrag r_i des ersten elektronischen Münzdatensatzes C₁ berechnet: $$s_1=\left(k_1+e\cdot r_1\right)$$

und ein dritter Nachweisparameter s₂ auf Basis der dritten Zufallszahl k₂, des Streuwerts e und dem Verschleierungsbetrag r_i des zweiten elektronischen Münzdatensatzes C₂ berechnet: $$s_2=\left(k_2+e\cdot r_2\right)$$

In step 205, a first verification parameter s ₀ based on the first random number k ₀ , the scatter value e and the (same) monetary amount v of one of the electronic coin data sets C ₁ or C ₂ : $$s_0=\left(k_0+e\cdot v\right)$$

and a second verification parameter s ₁ is calculated based on the second random number k ₁ , the spread value e and the concealment amount r _i of the first electronic coin data set C ₁ : $$s_1=\left({\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1+e\cdot {\mathrm{right}}_1\right)$$

and a third verification parameter s ₂ based on the third random number k ₂ , the spread value e and the concealment amount r _i of the second electronic coin data set C ₂ is calculated: $$s_2=\left({\mathrm{<figure-callout\; id="2"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0033.png"\; state="\{\{state\}\}">k</figure-callout>}}_2+e\cdot {\mathrm{right}}_2\right)$$

The scatter value e, the first verification parameter so, the second verification parameter s ₁ and the third verification parameter s ₂ are sent as a verification data record NDS _{i_EVP} from the TE1 in step 206, which can be evaluated as a publication of the NDS _{i_EVP} : $$ND{S}_{i\_EVP}=\left\{e,s_0,{\mathrm{<figure-callout\; id="1"\; label="s"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">s</figure-callout>}}_1,s_2\right\}$$

The masked coin data records Z ₁ and Z ₂ have already been created using equation (3) or created as part of the proof creation according to step 205 . These Z ₁ and Z ₂ can be sent together with the NDS _{i_EVP} as RDS _i from TE1. The NDS _{i_EVP} does not reveal any data elements of the first electronic coin data set C ₁ or the second electronic coin data set C ₂ and can therefore be sent to the coin register 2, for example as part of a changeover request in step 108.

This NDS _{i_EVP} from the two masked coin data sets Z ₁ and Z ₂ can now be checked in the coin register 2 or a TE2, which is the process steps of 3 is shown. For this purpose, the NDS _{i_EVP} is received in step 301 in the coin register 2 or the TE2. In step 302, a scatter value e' is calculated on the basis of the received NDS _{i_EVP} : $$e\text{'}=H\left(s_0\cdot H+s_1\cdot G-\mathrm{<figure-callout\; id="1"\; label="e\; \cdot \; Z"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">e</figure-callout>}\cdot Z_{}{}_1\Vert s_0\cdot H+s_2\cdot G-e\cdot Z_2\right)$$

In this case, the scatter value e is compared with the scatter value e' in step 303 . If both scatter values e, e' are identical, then the following applies: $$\begin{array}{c}e\text{'}=H\left(s_0\cdot H+s_1\cdot G-e\cdot Z_i\Vert s_0\cdot H+s_2\cdot G-e\cdot Z_2\right)\\ \begin{array}{l}=H(k_0\cdot H+e\cdot v\cdot H+{\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1\cdot G+e\cdot {\mathrm{right}}_1\cdot G-e\cdot v\cdot H-e\cdot {\mathrm{right}}_l\cdot G\Vert \\ k_0\cdot H+e\cdot v\cdot H+{\mathrm{<figure-callout\; id="2"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0033.png"\; state="\{\{state\}\}">k</figure-callout>}}_2\cdot G+e\cdot {\mathrm{right}}_2\cdot G-e\cdot v\cdot H-e\cdot {\mathrm{right}}_2\cdot G)\end{array}\\ =H\left(k_0\cdot H+{\mathrm{<figure-callout\; id="1"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">k</figure-callout>}}_1\cdot G\Vert k_0\cdot H+{\mathrm{<figure-callout\; id="2"\; label="k"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0033.png"\; state="\{\{state\}\}">k</figure-callout>}}_2\cdot G\right)\\ =e\end{array}$$

Equation (9p) or (9q) would not be solvable if the e could not be eliminated from the archetype of the scattering value function. However, this can only be achieved if the creator of the NDS _{i_EVP} has carried out the above calculations according to equations (9i) to (9n) correctly, which is the knowledge of the monetary amount ν ₁ and ν ₂ and the obfuscation amount r ₁ and r ₂ of the first and the second electronic coin data set C ₁ and C ₂ as well as the equality of the monetary amounts v ₁ = v ₂ = v. If e and e' match, the verification data record is considered correct. This correctness means that the electronic coin data sets C1 and _C2 are owned by _TE1 . This correctness is indicated in step 305. The RDS _i can then be registered in the coin register 2 in step 104 .

A further development of the in 1 The payment system BZ shown can provide for the deactivation of a coin data record C. A subscriber unit TE1 decides to deactivate and return the coin data record C and sends a deactivation request in step 111 (see 7 ). This step 111 can be the mapping of a participant's request, namely to credit a monetary amount of a coin data set to the participant's account, or it can be based on an evaluation of a test value, in which it was determined that the coin data set meets the criteria for a return, for example the expiry a period of validity, reaching a return time, reaching an “age” (number of transmissions and modifications) or reaching a threshold value if the coin data set C is not used. As a result of step 111, the monetary amount is credited to an account of the participant . in 7 In the subsequent step 112 shown, a deactivation command is sent to the coin register 2 in order to delete the register data set RDS from the coin register 2 or to switch it there to invalid. As a result, the RDS of the deactivated (credited) coin data record is deleted from coin register 2 (RDS crossed out).

According to 1 the transmitted electronic coin data record C _i is received in TE2. Upon receipt of electronic coin record C _i , TE2 is in possession of the digital money represented by electronic coin record C ₁ . With the direct transmission 105, it is available to TE2 for further actions.

To check the validity of the electronic coin data set C _i received, another RDS can be calculated in SE2 using the—public—one-way function from equation (3). The RDS, ie for example the masked transmitted electronic coin data set Z _i , is then transmitted to the coin register 2 in step 104 and searched for there. If both RDSs match with regard to the same coin data set C, for example a match with a registered and valid masked electronic coin data set Z _i , the SE2 is shown the validity of the received coin data set C _i and it applies that the received electronic coin data set C _i is equal to the registered one electronic coin record C _i . This validity check is secured with the second proof (EVP). In one embodiment, the validity check can be used to determine that the electronic coin data set C _i received is still valid, ie that it has not already been used by another processing step or in another transaction/action and/or has undergone further modification was.

Switching (=switch) of the received electronic coin data set now preferably takes place, which is described in the patent applications WO 2020/21337 A1 and WO 2020/212331 A1 is adequately described.

Mere knowledge of an RDS, ie for example a masked electronic coin data set Z _i , does not entitle the digital money of the corresponding electronic coin data set C _i to be issued.

Merely knowing the electronic coin data record C _i authorizes payment, ie to carry out a transaction successfully, in particular if the coin data record C _i is valid, for example if the electronic coin data record C _i has an active status. The status is preferably only set to an active status upon receipt of the deletion confirmation from SE1. There is a one-to-one relationship between the electronic coin records C _i and the corresponding masked electronic coin records Z _i . The masked electronic coin data records Z _i are registered in the coin register 2, for example a public database. This registration 104 makes it possible to check the validity of the electronic coin data set C _i , for example whether new monetary amounts have been (illegally) created.

The masked electronic coin data records Z _i are stored in the coin register 2 . All processing of the electronic coin data record Z _i is registered there, whereas the actual transmission of the digital money takes place in a (secret, ie not known to the public) direct transaction layer of the payment system BZ. In addition, monitoring of the coin data record C and the subscriber unit TE can be recorded in a coin register 2 in this payment system BZ.

The electronic coin data sets C can be modified to prevent multiple spending or to ensure more flexible transmission 105 .

The subscriber units TE can be designed using an e-wallet for electronic coin data sets C _i ie as an electronic wallet with a storage area in which a large number of coin data sets C _i are stored and thus, for example, in the form of an application on a smartphone or a retailer’s IT system , a commercial bank or another market participant. Thus, the components in the subscriber unit TE are implemented as software. The coin register 2 is expected to be server or DLT based and operated by a number of trusted market participants.

In the coin register 2, an RDS relating to the electronic coin data record C can be replaced by an RDS relating to the electronic coin data record C or a modified electronic coin data record C to be registered. This means that (only) current coin data records C that exist in the payment system BZ are maintained as RDS in the coin register 2.

4 shows a data structure for a coin register 2 of the previous figures. In the 4 data of the coin register 2 are shown for illustration, here the masked electronic coin data sets Z _i and possibly their processing are registered. The coin register 2 can be accommodated in a server entity. Coin register 2 is preferably located locally remote from the subscriber units TE and housed in a server architecture, for example.

Each processing operation for processing (creating, deactivating, dividing, connecting and switching over) is registered in the coin register 2 and appended there, for example in unchangeable form, to a list of previous processing operations for masked electronic coin data records Z _i . The individual operations or their test results, that is to say the intermediate results of processing, are recorded in the coin register 2 . The flags shown are optional data elements. Although the list below is assumed to be continuous, this data structure can also be cleaned up or compressed, if necessary according to predetermined rules, or be provided separately in a cleaned up or compressed form. The modifications "Create", "Deactivate", "Toggle", "Connect" and "Split" are already in the patent applications WO 2020/21337 A1 and WO 2020/212331 A1 described and reference is made in this regard and also to the carrying out of corresponding tests. It should be noted in particular that only the (valid) masked electronic coin data sets need to be stored in the coin register; the other data elements, such as the flags shown, the signatures or the commands are optional data elements.

According to 5 a signed masked electronic coin record is sent to coin register 2 in step 1015. In step 103, the received electronic coin dataset C _i is masked according to equation (3) and, if necessary, signed. Then in step 104 the masked electronic coin data set Z _i is registered in the coin register 2 . Optionally, the subscriber unit TE1 can switch the received electronic coin data set. In step 105, the coin data record C _i is transmitted in the direct transaction layer to the second subscriber unit TE2. In steps 201-206, an NDS according to 2 created in TE2. In steps 301-305, the validity of the NDS is checked in the coin register 2 according to FIG 3 . If the NDS is correct, this is indicated to the TE2 and the RDS is entered, whereupon the validity of the coin data set Z _i or C _i is confirmed.

In the optional switching step 108, a received coin data set C _k is then switched over to a new coin data set C _i , as a result of which the coin data set C _k becomes invalid and double dispensing is prevented. For this purpose, the monetary amount υ _k of the transmitted coin data set C _k is used as the “new” monetary amount υ _l . In addition, a concealment amount r ₁ is established. The additional obfuscation amount radd is used to prove with the NDS _EVP that no new money (in the form of a higher monetary amount) was generated by the second subscriber unit TE2. Then the masked coin data set Z ₁ to be switched over is sent to the coin register 2 and the switching over from C _k to C ₁ is instructed. An NDS _EVP is also used in accordance with this 2 created and sent. For example, TE2 can generate an NDS _EVP according to Equations 9i through 9n to indicate that TE2 owns two coins C ₁ and C _k and both monetary amounts are equal. The TE can then send Z ₁ , Z _k and the NDS _EVP to the coin register 2 for testing and validation.

In steps 301 to 305, the corresponding check is carried out in the coin register 2 according to equations 9m to 9q. If all tests were successful and this was recorded in the coin register 2 in an unchangeable manner, the coin data record is considered switched. Ie the coin data set C _k is no longer valid and the coin data set C ₁ is valid immediately. A double issuance is no longer possible if a third subscriber unit TE requests the validity of the coin data record (issued twice) from the coin register 2 .

In the optional step 109, two coin data sets C _k and C _i are combined into a new coin data set C _m , as a result of which the coin data sets C _k , C _i become invalid and double dispensing is prevented. For this purpose, the monetary amount υ _m is formed from the two monetary amounts υ _k and υ _i . For this purpose, the concealment amount r _m is formed from the two concealment amounts rk and r _i . In addition, the masked coin data set Z _m to be connected is obtained by means of equation (3) and this (together with other information) is sent to the coin register 2 and connection is requested as processing. For example, TE2 may generate an NDS _EVP according to Equations 9i through 9n to indicate that _TE2 owns two coins Ci and _Ck and no new monetary amounts have been generated.

In steps 301 to 305, the corresponding check is carried out in the coin register 2. The coin register 2 checks the NDS using equations 9i and 9n and can then mark Z _m as valid and mark Z _k and Z ₁ as invalid.

In optional step 110, a coin data set C _i is split into two partial coin data sets C _k and C _j , whereby the coin data set C _i is invalidated and the two divided partial coin data sets C _k and C _j are to be validated. When splitting, the monetary amount υ _i is split into monetary partial amounts υ _k and υ _j . For this purpose, the concealment amount r _i is divided into the two concealment amounts r _k and r _j . In addition, the masked coin part data records Z _k and Z _j are obtained by means of equation (3) and these are sent to the coin register 2 with the NDS and the splitting is requested as processing. In steps 301 to 305, the corresponding check is carried out in coin register 2.

In an embodiment of 6 (below the dashed line in 6 ) it is suggested to perform symmetric splits or fractional splits in an “offline” payment situation. "Offline" means that neither TE2 (payer) nor TE1 (payee) can call coin register 2 to check the correctness of the payment. Therefore, all NDSs must be stored in the TEs involved. They must then not be data or computationally intensive in order to meet the performance criteria of TEs, particularly resource-constrained SEs. With each payment, the data must be transmitted from TE2 to TE1 via the defined communication protocol.

One implementation of offline payment is the imitation of denominations known for cash. By choosing an optimized denomination scheme (e.g. denominations based on powers of 2 instead of powers of 10), the probability of not being able to pay a certain amount can be reduced. However, under all circumstances, a digital payment system should be able to pay any amount as long as sufficient funds are available. This problem can be solved with offline splitting of the 6 be solved that no NDS _{_ZKPR} and thus requires significantly less data and calculations.

From a C with a corresponding Z, a part of n/m of its monetary amount v can be divided with the . When n=1 and m=2, symmetric splits are allowed. Asymmetric splitting is possible but less preferred.

wobei n und m teilerfremde Primzahlen sind und n < m gilt. Der Verschleierungsbetrag r₁ wird zufällig gewählt. Mit Gleichung (3) wird Z₁ berechnet. Nun wird ein NDS_EVP berechnet, wobei in Übereinstimmung mit Gleichungen 9i bis 9n für einen EVP (Z₀, Z₁) in Analogie nun gilt: $$EVP\left(n\cdot Z_0,m\cdot Z_1\right)$$

A monetary partial amount ν _l can be obtained from v ₀ , r ₀ , Z ₀ as part of a division in TE2 with: $${\mathrm{<figure-callout\; id="1"\; label="v"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">v</figure-callout>}}_1=n\text{/}m\cdot v_0$$

where n and m are relatively prime numbers and n < m. The concealment amount r ₁ is chosen at random. Using Equation (3), Z ₁ is calculated. An NDS _EVP is now calculated, where, in accordance with Equations 9i to 9n, for an EVP (Z ₀ , Z ₁ ) by analogy now applies: $$EVP\left(n\cdot Z_0,m\cdot Z_1\right)$$

und der Verschleierungsrestbetrag r₁' berechnet werden mit: $$r_1\text{'}=r_0-r_1$$

Now the monetary remainder ν ₁ ' can be calculated with: $$v_1\text{'}=v_0-{\mathrm{<figure-callout\; id="1"\; label="v"\; filenames="DE102021000570A1\_0030.png,DE102021000570A1\_0031.png"\; state="\{\{state\}\}">v</figure-callout>}}_1=\left(1-n\text{/}m\right)\cdot v_0$$

and the concealment remainder r ₁ ' can be calculated with: $${\mathrm{right}}_1\text{'}={\mathrm{right}}_0-{\mathrm{right}}_1$$

Due to the condition that n < m, both monetary amounts ν ₁ and ν ₁ ' are either both inside or both outside the allowed range. In some cases, additional measures can be taken to ensure that once out-of-bounds electronic coin records cannot "enter" it again through multiple consecutive splits.

Within the scope of the invention, all of the elements described and/or drawn and/or claimed can be combined with one another as desired.

Reference List

BZ

payment system

1

editorial authority,

2

coin register

21

command entry

22a, b

Entry of an electronic coin data set to be processed (predecessor)

23a, b

Entry of a processed electronic coin data set (successor)

24

signature entry

25

Validation check mark

26

Marking of the calculation check

27

Marking of area verification check

28

Marking of signature verification

29

completion marker

ci

electronic coin record, CBDC,

cj, ck

split electronic coin part data set,

class

switchable electronic coin data set

Cm

electronic coin record to be connected

e, e'

spread value

f(C)

Homomorphic one-way function

k0,1,2

Random number for EVP or ZKPR

Ki

masked random number

NDSi

Evidence record regarding C _i

RDSi

Register record regarding C _i

right

obfuscation amount, random number

rj, rj

Amount of obfuscation of a split electronic coin record

rm

Amount of obfuscation of an electronic coin record to be connected

s0,1,2

Evidence parameters for EVP or ZKPR

Sex

umpteenth security element

tex

umpteenth subscriber unit

room

masked electronic coin record

Zj, Zk

masked split electronic coin part record

Zl

masked toggling electronic coin record

room

masked electronic coin record to be connected

vi,

monetary amount

vj, vj

Split monetary amount

fl,

Monetary amount of an electr. coin record

vm,

Monetary amount of a to be connected / connected electr. coin record

101-112

Method steps of the payment system according to an embodiment

201-206

Procedural steps for deploying an NDS

301-305

Method steps in the payment system according to an embodiment

QUOTES INCLUDED IN DESCRIPTION

This list of the documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• WO 2016/200885 A1 [0004]
• WO 2020/21337 A1 [0005, 0006, 0015, 0029, 0037, 0038, 0105, 0106, 0120, 0163, 0171]
• WO 2020/212331 A1 [0005, 0006, 0015, 0029, 0037, 0038, 0105, 0106, 0120, 0163, 0171]

Claims (24)

A method (200) for providing a verification data record (NDS) relating to an electronic coin data record (C) by a subscriber unit (TE1) of an electronic payment system (BZ), the electronic coin data record (C) having a monetary amount (υ) and an obfuscation amount (r ) having, with the method steps: - generating (201) a first random number (k ₀ ) and a second random number (k ₁ ); - calculating (204), by the subscriber unit (TE1), a hash (e) by applying a hash function using the first random number (k ₀ ) and the second random number (k ₁ ); - calculating (205), by the subscriber unit (TE1), a first verification parameter (s ₀ ) using the first random number (k ₀ ) and the monetary amount (v) of the electronic coin record (C) and a second verification parameter (s ₁ ) using the second random number (k ₁ ) and the obfuscation amount (r) of the electronic coin record (C); - Sending (206), by the subscriber unit (TE1), the verification data set (NDS) relating to the electronic coin data set (C), the verification data set (NDS) containing the scatter value (e), the first verification parameter (s ₁ ) and the second verification parameter ( S2) includes. The method (200) after claim 1 , The verification data record (NDS) being sent from the subscriber unit (TE1) to a second subscriber unit (TE2) in the payment system (BZ). The method (200) after claim 1 , The verification data record (NDS) being sent to a coin register (2) of the payment system (BZ). The method (200) according to any one of the preceding claims, wherein before calculating (204) the scatter value (e), a homomorphic one-way function (f(C)) on the first random number (k ₀ ) and the second random number (k ₁ ) for generating (202) a masked random number (K _i ) is applied and the masked random number (K _i ) is used to calculate (204) the spread value (e). The method (200) after claim 4 , wherein the calculation (205) of each detection parameter (s ₀ , s ₁ ) is also performed using the masked random number (K _i ). The method (200) of any preceding claim for providing evidence of a first electronic coin record (C ₁ ) and a second electronic coin record (C ₂ ) by the subscriber unit (TE1), each electronic coin record (C) having a monetary amount ( v) and having a concealment amount (r), the method (200) further comprising: - generating a third random number (k ₂ ); - calculating (204), by the first subscriber unit (TE1), the hash (e) by applying the hash function (h) using the first random number (k ₀ ), the second random number (k ₁ ) and the third random number (k ₂ ); - calculating (205), by the first subscriber unit (TE1), the second verification parameter (s ₁ ) using the second random number (k ₁ ) and the concealment amount (r ₁ ) of the first electronic coin record (C ₁ ); - calculating (205), by the first subscriber unit (TE1), a third verification parameter (s ₂ ) using the third random number (k ₂ ) and the concealment amount (r ₂ ) of the second electronic coin record (C ₂ ); and - the first subscriber unit (TE1) sending (206) the verification data set (NDS) relating to the first electronic coin data set (C _i ) and the second electronic coin data set (C ₂ ), the verification data set (NDS) containing the scatter value (e) , the first detection parameter (s ₀ ), the second detection parameter (s ₁ ) and the third detection parameter (s ₂ ). The method (200) after claim 6 , wherein before calculating (204) the scatter value (e): - a homomorphic one-way function (f(C)) on the first random number (k ₀ ) and the second random number (k ₁ ) to generate (202) a first masked random number ( K ₁ ) is applied; - the homomorphic one-way function (f(C)) is applied to the first random number (k ₀ ) and the third random number (k ₂ ) to generate a second masked random number (K ₂ ); and - the first masked random number (K ₁ ) is combined (203) with the second masked random number (K ₂ ). The method (200) after claim 6 or 7 , wherein the provision of the verification data record takes place as part of a changeover modification (108) of the first electronic coin data record (C ₁ ) to the second electronic coin data record (C ₂ ). The method (200) of any preceding Claims 6 until 8th , wherein the monetary amount (v ₂ ) of the second electronic coin record (C ₂ ) is part of the monetary amount (v ₁ ) of the first electronic coin record (C _i ). The method (200) after claim 9 , wherein for calculating (204), by the subscriber unit (TE1), the hash (e) by applying the hash function using the first random number (k ₀ ), the second random number (k ₁ ) and the third random number (k ₂ ). a division factor (n/m) of the monetary amounts is used. The method (200) according to one of Claims 8 until 10 , wherein a monetary remainder from the subtraction of the monetary amount (υ ₁ ) of the first electronic coin data record (C _i ) and the monetary amount (υ ₂ ) of the second electronic coin data record (C _i ) is greater than zero. A method (300) for checking proof of an electronic coin data set (C) by a second subscriber unit (TE2) or a coin register (2) of an electronic payment system (BZ), with the method steps: - Receiving (301) from a first subscriber unit (TE1) of the electronic payment system (BZ), a verification data set (NDS), the verification data set (NDS) comprising a scatter value (e), a first verification parameter (s ₀ ) and a second verification parameter (s ₁ ); - calculating (302), by the second subscriber unit (TE2), a hash value (e') by applying a hash function using the first detection parameter (s ₀ ) and the second detection parameter (s ₁ ); - comparing (303) the received scatter value (e) from the detection data set (NDS) with the calculated scatter value (e'); - Indicating (305) the correctness of the verification to the first subscriber unit (TE1) if the comparing step (303) results in the received scatter value (e) from the verification data set (NDS) matching the calculated scatter value (e'). The method (300) after claim 12 , wherein the indicating (305) is sent to the first subscriber unit (TE1) as a signed response to the received evidence record (NDS). The method (300) according to any one of the preceding claims, wherein the spread value function is known throughout the payment system. The method (300) according to one of the preceding claims, wherein the electronic coin data record (C) is registered in the coin register (2) of the electronic payment system (BZ) if the verification is correct. The method (200, 300) according to any one of the preceding claims, wherein the following steps are performed: - receiving (102, 105) the electronic coin data record (C _i ) from an issuer entity (1) and/or another subscriber unit (TE); and - queries a register data record (RDS _i ) relating to the received electronic coin data record (C _i ) in the coin register (2). The method (200, 300) after Claim 16 , With only the presence of a register data set (RDS _i ) to this electronic coin data set (C _i ), the method (200, 300) according to one of Claims 1 until 15 is carried out. The method (200, 300) according to one of the preceding claims, wherein the method steps that are carried out in a subscriber unit (TE) are carried out in a secure runtime environment, for example a security element (SE) of the respective subscriber unit (TE). A coin register (2) for registering register data records (RDS), in particular masked electronic coin data records (Z), in an electronic payment system (BZ), with: - A data interface set up to receive evidence data sets and to display the correctness of the evidence according to any one of the preceding claims. The coin register (2) after claim 19 wherein the coin register (2) is arranged to: - apply the spread value function to generate (302) the spread value (e'); - Comparing (303) the generated scatter value (e') with the received scatter value (e) of the detection data set (NDS); and - registering (104) a register data set (RDS) in the coin register (2). The coin register (2) after claim 19 or 20 , further comprising a checking unit for checking the verification data set (NDS) according to the method according to any one of the preceding claims. A payment system (BZ) for paying with electronic coin data sets (C) with: - a coin register (2) set up for checking a verification data record and registering (104) the electronic coin data records (C) according to one of the preceding method claims; - Subscriber units (TE1, TE2) set up to carry out payment transactions by transmitting (105) the electronic coin data records (C) and for providing verification data records relating to the electronic coin data records (C) according to one of the preceding method claims. A subscriber unit (TE1), set up for the direct transmission of electronic coin data sets (C _i ) to another subscriber unit (TE2, TE3) in an electronic payment system (BZ) and set up for executing payment transactions by transmitting (105) electronic coin data sets (C _i ) and for providing verification data sets (NDS) relating to the electronic coin data sets (C) to another subscriber unit (TE2) or a coin register (2) of the electronic payment system (BZ) according to one of the preceding methods claims 1 until 18 with: - a means for accessing a data memory, at least one electronic coin data set (C) being stored in the data memory; - An interface for outputting the at least one electronic coin data record (C) to the other subscriber unit (TE) and for sending and receiving verification data records (NDS) relating to the electronic coin data records (C); and - a computing unit set up to execute the method steps of the method according to one of Claims 1 until 18 . A computer program product executable installed in a subscriber unit (TE) or a coin register of an electronic payment system (BZ) and having means for executing the method steps of the method according to one of Claims 1 until 18 .

Images