EP4334872A1 - Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt - Google Patents

Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt

Info

Publication number
EP4334872A1
EP4334872A1 EP22725994.2A EP22725994A EP4334872A1 EP 4334872 A1 EP4334872 A1 EP 4334872A1 EP 22725994 A EP22725994 A EP 22725994A EP 4334872 A1 EP4334872 A1 EP 4334872A1
Authority
EP
European Patent Office
Prior art keywords
coin
register
subscriber unit
electronic coin
data set
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22725994.2A
Other languages
English (en)
French (fr)
Inventor
Matthias Fasching
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Advance52 GmbH
Original Assignee
Giesecke and Devrient Advance52 GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient Advance52 GmbH filed Critical Giesecke and Devrient Advance52 GmbH
Publication of EP4334872A1 publication Critical patent/EP4334872A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/383—Anonymous user system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the invention relates to a method for registering an electronic coin data set in a coin register of an electronic payment system. Registering the electronic coin record is preferably part of an atomic exchange process. In this case, an exchange request is sent in order to see an electronic coin data record of the payment system, in particular a CBDC-based payment system, against a data record from a system other than the payment system.
  • the invention also relates to a coin register, a subscriber unit and a computer program product.
  • 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.
  • An electronic asset system is described in US Pat. No. 5,872,844 A.
  • Electronic assets are issued in the system by an institution.
  • the electronic assets are transferred from a payer's wallet to a payee's wallet.
  • the payee's wallet routinely submits the transferred assets for possible scrutiny.
  • a fraud detection system takes samples from those submitted for review assets to uncover “bad” assets that have been used in a fraudulent manner. Upon such detection, the fraud detection system will identify the electronic wallet that used the bad asset and flag it as a "bad wallet”.
  • the fraud detection system compiles a list of such bad e-wallets and distributes the list to warn other wallets about the bad e-wallets. If a bad wallet subsequently attempts to spend assets (whether fraudulently or not), the intended recipient will check the list of bad wallets and refuse to do business with the bad wallet.
  • the issued assets must contain a signature chain, which means that the storage requirement of the asset per payment transaction increases, ie the electronic coin data record grows. Wallets that are not trusted will not be allowed on the system at all.
  • An exemplary payment system is in the patent applications WO 2020/212337 A1 and WO 2020/212331 A1. Reference is made here to the configurations described therein, in particular the modification (switching, connecting, splitting) of electronic coin data sets, the masking of electronic coin data sets, the registration of the masked electronic coin data sets, and the checking of their validity.
  • An exchange with non-access-based data records such as value-based data records, for example the electronic coin data records of a digital central bank currency (CBDC - Central Bank Digital Currency), is initially not possible, among other things because corresponding random value checks for verification and unlocking of the HTLCs are not in can be mapped to these value-based data sets.
  • CBDC digital central bank currency
  • direct and anonymous payment should be created between the participants in the payment system.
  • the exchanged electronic coin records should be confidential to other system participants, but allow each system participant to perform basic checks on the electronic coin record, namely (1) detecting multiple dispensing attempts; (2) recognizing attempts to pay with non-existent monetary amounts; and (3) recognizing return criteria for already dispensed coin records, for example that an electronic coin record should expire.
  • the object is achieved with a method for registering an electronic coin data set in a coin register of an electronic payment system.
  • the procedure comprises the following procedural steps:
  • the generated electronic coin record by applying a one-way function, e.g. homomorphic, to at least one data element of the electronic coin record to obtain a masked generated electronic coin record.
  • a one-way function e.g. homomorphic
  • the coin register receives a time-secured masked electronic coin that can be switched (only) within the time period. If there is no switchover within this time, the original state is restored, i.e. the switchover to the second subscriber unit fails. This original state can take place automatically after the time has elapsed - as will be described below - or it can be forced by the first subscriber unit by means of a switchover modification.
  • the basic principle of switching as a modification of an electronic coin data set has already been adequately described in patent applications WO 2020/212337 A1 and WO 2020/212331 A1 and reference is made thereto.
  • the obfuscation value may be an obfuscation amount, where the one-way function is applied at least to the monetary amount, preferably to the monetary amount and the obfuscation amount.
  • the result of applying the one-way function preferably forms the masked electronic coin record.
  • the one-way function is applied in particular to the two data elements mentioned (or all) of the electronic coin data set.
  • a masked spoof value may be generated from the spoof value in the masking step, wherein the masked electronic coin record includes the monetary amount and the masked spoof value as data elements.
  • Atomic barter transactions require two subscriber units to acknowledge receipt of records within a specified time frame. If either subscriber unit does not acknowledge the transaction within the time period, the entire transaction is voided and no records are exchanged. This prevents a scenario in which a subscriber unit receives a data record but then wants to renegotiate to send its own data record and may have both data records.
  • atomic refers to the fact that this exchange either takes place completely or does not take place at all. If one of the subscriber units gives up or does not (in a timely manner) do what is required of it according to the computer protocol, the exchange transaction fails and the records are automatically returned to their previous owners (subscriber units), an original state is restored, i.e. a state as the barter would never have started.
  • a period of time is a period of time between the sending of the registration request and the desired end of the possibility for the other subscriber unit to take possession of the record. Starting from the transmission time, the end of the period of time is in the future and is preferably a few days, for example 3 days.
  • the registration method described here may be part of an atomic exchange method. It provides the core, namely the registration process required for an "atomic swap" with the coin register of a payment system intended for the exchange of value-based coin data sets (such as CBDC coin data sets).
  • a time lock also referred to as a "time lock” or “time lock” or “time blockade”, is preferably a cryptographic primitive. This time-out defines a period of time during which the first subscriber unit cannot have the electronic coin record registered to it and/or a period of time within which the second subscriber unit can have the electronic coin record registered to it. Accordingly, this time lock is a function that ensures that electronic coin data sets can only change their owner within a predetermined period of time, ie can be switched over (coined).
  • time locks can be part of Hash Timelock Contracts, HTLC. They can also be used to block registration of the generated electronic coin record for the period defined with the time period. This time assurance represented a clear intention on the part of the first subscriber unit to transmit the generated electronic coin data set to a second subscriber unit.
  • the registration request may be a swap request (SWAP command) to exchange the generated electronic coin record from the first subscriber unit for a record from a system other than the payment system from the second subscriber unit.
  • Another system is, for example, another system for exchanging data records (value-based or access-based), it is preferably an access-based system in which, for example, cryptocurrencies or smart contracts are exchanged as part of blockchain transactions.
  • the data record of this system is preferably a blockchain-based data record, ie an access-based data record.
  • These data sets are characterized by the fact that they do not contain any monetary data (such as amounts, etc.), but only provide access data in order to be able to access this monetary data - for example a blockchain or a network data storage device.
  • the other system is also a system for the exchange of value-based records or a system for the exchange of access-based records. It is crucial that the data record is transmitted as a system in an architecture or platform that is different from the existing payment system.
  • Exchange means a mutual transfer of values, such as monetary amounts or items to be negotiated (for smart contracts).
  • the first subscriber unit can transmit the generated electronic coin record directly to the second subscriber unit when the first subscriber unit has received a registration confirmation from the coin register.
  • the coin register of the first subscriber unit indicates that a Verification of the registration request was successful, in particular that the electronic coin data record is time-secured in the coin register.
  • the coin register Before sending the registration confirmation to the first subscriber unit, the coin register may preferably verify that the masked generated electronic coin record is not yet registered in the coin register and that the coin register securely registers the masked generated coin record, with the time protection being automatically canceled when the period of time has expired .
  • the coin register can still check value range proofs to ensure that no new money has been generated.
  • the coin register can verify that the end of the period is in the future.
  • the coin register can verify that the coin data set received, on the basis of which the generated coin data set was generated, is valid and is registered in the coin register—ideally on the first subscriber unit.
  • a delayed switching request is preferably transmitted from the first subscriber unit to the coin register, on the basis of which the coin register automatically switches the masked generated coin data set to the first subscriber unit when the coin register determines that the time period has expired. This means that no further steps are required by the first subscriber unit in order to restore the original state if the exchange method fails.
  • the registration request is reinterpreted as a delayed toggle request in the coin register when the coin register determines that the time period has expired, whereupon the coin register automatically toggles (back) the masked generated coin record to the first subscriber unit.
  • the determination of the end of the time period in the coin register can be implemented using electronic counters or timers.
  • the delayed switching request reduces the system complexity, since the generation and registration of a further masked coin data record can be dispensed with.
  • the first subscriber unit Before sending the registration request, the first subscriber unit preferably receives a scatter value from a data record of the other system.
  • the scatter value from the data set of the other system is preferred.
  • the masked generated electronic coin data record is secured by the first subscriber unit (now also) with the scatter value, so that the coin register registers the masked generated coin data record with scatter value secured.
  • the hashlock prevents the record from being redeemed by the first subscriber unit unless the original image record is revealed.
  • the hash lock prevents the generated electronic coin data record from being switched over to the second subscriber unit if the second subscriber unit does not have the original image data record or if the latter does not disclose the original image data record.
  • Hash Timelock Contract HTLC
  • An HTLC is a piece of computer protocol and is based on two key functions: a "hashlock” and a "timelock”. Consequently, the use of HTLCs obviates the need for trust since they define a specific set of rules that prevent partial atomic swaps from being executed.
  • the first subscriber unit Before sending the registration request, the first subscriber unit preferably receives a period of time from the data record of the other system, the period of time from the data record specifying a period of time up to which the first subscriber unit can redeem the data record from the system other than the payment system.
  • the second subscriber unit has thus secured the data record of the other system in terms of time and when this period of time has elapsed, the second subscriber unit can redeem this data record for itself again.
  • the first subscriber unit preferably selects the time period for the registration request in such a way that it expires before the time period from the data record expires, with the time period for the registration request preferably being approximately half the time period between receipt of the time period from the data record and the expiry of the time period from the data record is. This presupposes that the period of time from the data set is also in the future, ie has not yet expired at the time of receipt by the first subscriber unit. This is useful if the validity of the electronic coin data set is to be checked first before the data set can be received at the first subscriber unit.
  • the second subscriber unit preferably receives the generated electronic coin data record directly from the first subscriber unit, the second subscriber unit checking whether the masked generated electronic coin data record is secured in the coin register with the spread value spread value. After receiving, the second subscriber unit preferably checks whether the monetary amount in the received generated electronic coin data record corresponds to the negotiated conditions.
  • the method preferably comprises the further steps: generating, by the second subscriber unit, an electronic coin data record comprising the monetary amount and an obfuscation amount, wherein the monetary amount of the generated electronic coin data record corresponds to the monetary amount of the electronic coin data record received from the first subscriber unit; masking, by the second subscriber unit, the generated electronic coin record by applying the homomorphic one-way function to the electronic coin record to obtain the masked generated electronic coin record; The second subscriber unit sends a switch request (here also "redeem" command) for the masked generated electronic coin data set to the coin register together with a primordial image data set, where the primordial image data set also forms the basis for the spread value in the data set other than the payment system, the sending being done within the time period of the time security.
  • a switch request here also "redeem" command
  • the archetype record is a secret of the second subscriber unit to which a hash function is applied to obtain the above hash value for saving the other system's record.
  • the secret must be communicated to the first subscriber unit in the course of the atomic exchange procedure. If the second subscriber unit finds the electronic coin record received from the first subscriber unit to be correct and now wants to switch it over to itself (which can be done by creating a new coin record, masking and registering), it must in turn publish the archetype record in order to do so the first subscriber unit can redeem the record on itself.
  • the coin register preferably registers the masked generated electronic coin data record of the second subscriber unit on the second subscriber unit if a scatter value via the original image data record matches the masked electronic coin data record of the coin register secured with the scatter value and if the duration of the time protection of the masked electronic coin data record generated is still valid has not expired.
  • the masked generated electronic coin data set becomes the first Participant unit invalid. The transmission of the electronic coin data record from the first subscriber unit to the second subscriber unit is thus successfully completed.
  • the first subscriber unit can now also redeem the data set for itself, it queries the original image data set (which is published and stored in the coin register so that it can be called up) from the coin register. With the archetype record, the first subscriber unit can redeem the record from the other system on itself.
  • the sending of the registration request can include a plurality of masked generated electronic coin data records from the first subscriber unit, with the same time security, preferably also the same spread value from a data record from a system other than the payment system, being used for each of the masked generated electronic coin data records.
  • the coin register registers each masked electronic coin record as a register record.
  • the following steps are preferably performed: receiving the electronic coin record from an issuer entity and/or another subscriber unit; and retrieving a register record from the coin register for the received electronic coin record.
  • the first subscriber unit thus ensures that the coin data record to be transmitted is present and valid.
  • the method according to the previous type is carried out only when a register data set for this electronic coin data set is available. Thus, it becomes a system requirement that the register data set must be present for an atomic exchange.
  • the length of time in the registration request is preferably only a few days, preferably 3 days, with the length of time in the data record preferably being 7 days. These are assumed to be sufficient periods of time to be able to perform the atomic replacement procedure.
  • the spread value can be calculated using a spread value function in the second subscriber unit, with a secret original image data record being generated in the second subscriber unit as the basis.
  • various functions can be used as the scatter value function.
  • a spread value function is preferably chosen which is already available in both systems (access-based/non-access-based).
  • Scattered value functions of the SHA2 type, in particular SHA256 can in principle also be used with other widespread scatter value functions such as SHA3, RIPEMD-160, MD5 or Haval.
  • the object is achieved by 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 set up to receive registration requests and to send register statuses regarding register data records of the payment system according to the type described above.
  • the coin register is preferably set up to receive a prototype data record from a subscriber unit; applying a hash function to the archetype data set to generate a hash value; comparing the generated hash value to a previously received hash value; and registering a register data set secured by means of the scatter value in the coin register.
  • the coin register preferably also has a checking unit for checking the validity of the electronic coin data sets corresponding to the register data sets.
  • a payment system for paying with electronic coin data sets comprises a coin register set up to register the generated electronic coin data sets according to the type described above and subscriber units set up to carry out payment transactions by transmitting the electronic coin data sets and for sending status and/or registration requests relating to the electronic coin data sets according to the above described and executing transactions by transferring data records in a system other than the payment system according to one of the preceding method claims.
  • the coin register of the payment system is preferably set up to register the electronic coin data record as part of an atomic exchange process, with a registration request being an exchange request to exchange the generated electronic coin data record from the first subscriber unit against a data record from a system other than the payment system from the second Exchange subscriber unit.
  • a subscriber unit is provided.
  • This subscriber unit is set up to transmit electronic coin data records directly to another subscriber unit in an electronic payment system and set up to carry out payment transactions by transmitting electronic coin data records and for sending status and/or registration requests regarding the electronic coin data records to a coin register.
  • the subscriber unit has a means for accessing a data memory, with at least one electronic coin data set being stored in the data memory; an interface for outputting the at least one electronic coin data set to the other subscriber unit for transmitting status and/or register requests relating to the electronic coin data sets to the coin register and a processing unit set up to carry out the method steps of the method described above.
  • a computer program product is executably installed on a subscriber unit and has means for performing the method steps of the method.
  • the electronic coin record is typically issued by a central bank.
  • the electronic coin record may be referred to as a central bank digital currency (CBDC) electronic coin record.
  • CBDC central bank digital currency
  • this monetary amount can change from a first terminal to another terminal.
  • a monetary amount (asset) is understood to mean a digital amount that can be credited to an account at a financial institution, for example, or exchanged for another means of payment.
  • An electronic coin record thus represents cash in electronic form.
  • An electronic coin data record for transferring monetary amounts differs significantly from the electronic data record for data exchange or data transfer, for example a register data record, since a classic data transaction is based on a Question-answer principle or on an intercommunication between the data transfer partners, for example the subscriber unit and a coin register (sometimes referred to here as a monitoring authority, monitoring register, transaction register, verifier).
  • a coin register sometimes referred to here as a monitoring authority, monitoring register, transaction register, verifier.
  • 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 is anonymous, unique, unambiguous and is part of a security concept.
  • 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.
  • a valid electronic coin data record should 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.
  • ASCII American Standard Code for Information Interchange
  • 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.
  • the electronic coin data record can be recorded as a QR code in a subscriber unit and output as a file or character string by the subscriber unit.
  • 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).
  • Teen 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.
  • the electronic coin data record can have further data elements, in particular which currency the monetary amount represents or by which issuing authority it was generated.
  • the electronic coin data record can include a signature of an issuer entity, in particular in order to increase security (although with reduced flexibility).
  • 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.
  • 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 therefore 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.
  • 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.
  • 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 checking requests to the coin register.
  • the subscriber unit has an interface for issuing electronic coin data records.
  • a communication protocol for wireless communication for wireless communication.
  • 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.
  • 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, E.g. SMS, MMS, instant messenger message, an APDU string.
  • the transmission takes place via the previously mentioned application of the subscriber unit and/or the security element.
  • the subscriber unit also has an interface for receiving electronic coin data sets.
  • 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.
  • the interface for receiving the at least one electronic coin data record is a protocol interface for wirelessly receiving the electronic coin data record from another security element or end device using a communication protocol for wireless communication.
  • a communication protocol for wireless communication In particular, this involves near-field communication, for example using the Bluetooth protocol or NFC protocol or IR protocol.
  • WLAN connections or mobile radio connections are conceivable.
  • 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.
  • 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.
  • 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 without manipulation and, if necessary, also be sent.
  • 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.
  • 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.
  • 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.
  • 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 sets.
  • 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.
  • 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.
  • the security element or subscriber unit is lost or if the security element or subscriber unit malfunctions, the electronic coin data records are not lost. Because possession of the (unmasked) electronic coin records equals possession corresponds to the monetary amount, money can be stored and managed more securely by using external data storage.
  • 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 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 the validity of such electronic coin data records 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.
  • less trustworthy units such as subscriber units, ie a terminal or a machine
  • 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.
  • 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.
  • 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.
  • cryptographic keys for example a session key negotiated for an electronic coin data record exchange or a symmetric or asymmetric key pair.
  • the coin data records are transmitted as APDU commands.
  • 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.
  • 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 for preparing the operational readiness of the security element(s) and/or a remote data storage service in which a wallet application with electronic Coin records 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.
  • the transmission can include an Internet data connection to an external data store, for example an online store.
  • the electronic coin data records are managed by the respective subscriber units, for example by security elements integrated there, and also transmitted by them.
  • the security element is introduced into the subscriber unit ready for operation.
  • 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.
  • 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.
  • a coin register of the payment system For example, the establishment of a communication link to the coin register is provided for registering the electronic coin data set. 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 sets. The coin register can also manage and check other (non-payment) transactions between subscriber units.
  • the coin register 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.
  • 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.
  • 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.
  • the coin register and a separate monitoring register are designed as a service server of the payment system.
  • 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.
  • the coin register provides a register data record.
  • the register data set has, for example, a masked electronic coin data set corresponding to an electronic coin data set as a data element.
  • the masked electronic coin record was provided by a subscriber unit or an issuing entity. Possession of a masked electronic coin data record does not permit disclosure of data elements of the (corresponding) electronic coin data record, whereby such a register data record with (only) masked coin data records is anonymous with regard to a subscriber identification and/or also anonymous with regard to a monetary amount of the electronic coin data 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.
  • 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.
  • a register data record with a masked coin data record is anonymous in terms of identity and pseudonymous in terms of amount.
  • 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.
  • a register data record is pseudonymous in identity and anonymous in terms of amount.
  • 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. That Masking is described in the applications WO 2020/212337 A1 and WO 2020/212331 A1 and reference is made thereto. 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 described in the applications WO 2020/212337 A1 and WO 2020/212331 A1 and reference is made to them in this regard.
  • the step of registering a register data set is described in the applications WO 2020/212337 A1 and WO 2020/212331 A1 and reference is made thereto.
  • a 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 total mark displayed in the coin register
  • Final processing decides whether an electronic coin record is valid or invalid
  • the registering step is preferably performed w 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 issuer instance is therefore also referred to as a privileged instance or privileged node, since only this can create new money in the form of electronic coin data records and can destroy money by deactivating electronic coin data 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.
  • 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 correspondingly obtain a masked new electronic coin record.
  • 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.
  • 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 instance is preferably accessed via an http protocol.
  • the process is not limited to one currency.
  • the payment system can be set up to manage different currencies from different publishers.
  • 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.
  • the electronic coin record becomes invalid and is deemed to have been returned.
  • a “Freeze” modification to an electronic coin data set can be provided in order to cause the electronic coin data set to be temporarily deactivated, or better yet, the monetary value of the electronic coin data set.
  • the electronic coin data record is set in a deactivated state without being destroyed, the electronic coin data record is quasi “frozen”. This "Freeze” modification or action differs from the "Deactivate” modification or action of an electronic coin record.
  • This "Freeze” modification cannot be carried out by a subscriber unit, i.e. not by the owner of the electronic coin data set.
  • This "Freeze” modification can only be initiated and carried out by a privileged authority, for example an issuing authority or a monitoring authority (not the coin register).
  • This privileged authority can be, for example, an authorized authority, for example a criminal prosecution authority, or a combination of several trustworthy authorities. In this way, a sum of money's worth can be confiscated from a suspect without the money being immediately destroyed.
  • a modification or action complementary to the “Freeze” modification or action is the “Unfreeze”.
  • the coin data sets deactivated by a "Freeze” action are reactivated (i.e. reactivated).
  • This "Unfreeze" modification can only be initiated and carried out by a privileged authority, for example an issuing authority or a monitoring authority (not the coin register).
  • This privileged authority can be, for example, an authorized authority, for example a criminal prosecution authority, or a combination of several trustworthy authorities. In this way, a monetary amount of a suspect can be released again, for example after the suspect has been proven innocent.
  • the actions "Freeze” and “Unfreeze” for a respective electronic coin data set are registered in a coin register by entries for a corresponding masked electronic coin data set. These actions are assumed here to be known per se.
  • a "Freeze” action for example, for a corresponding masked electronic coin data record no successor coins are specified (or the entered ones are deleted), which means that the electronic coin data record is invalid for all validity checks.
  • new successor coins are specified for a corresponding masked electronic coin data set, which means that the electronic coin data set is valid again during a validity check.
  • FIG. 1 shows an embodiment of a payment system according to the invention
  • FIG. 2 shows a further development of the exemplary embodiment of a payment system from FIG. 1;
  • FIG. 3 shows a further development of the exemplary embodiment of a payment system from FIG. 1;
  • FIG. 4 shows an exemplary embodiment of a method flow chart of a method in a publishing entity
  • FIG. 5 shows an exemplary embodiment of a data structure in the coin register
  • FIG. 7 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data record
  • FIG. 8 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data set
  • FIG. 9 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data set; 10 shows an exemplary embodiment of a method flow diagram of a method for registering a coin data set within an atomic exchange procedure; and
  • FIG. 11 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data set.
  • the payment system BZ includes at least two security elements, SE, SEI and SE2 for short.
  • SE, SEI and SE2 can be placed ready for operation in respective terminals M1 and M2 and logically or physically connected to the respective terminal M1 and M2.
  • M1 and M2 can also be subscriber units TE1, TE2.
  • the publishing entity 1 is, for example, a server entity of a central bank la.
  • a register data record RDS for example a masked electronic coin data record Z, is generated for the electronic coin data record C and registered 104 in a coin register 2 of the payment system BZ.
  • the register data record RDS for example the masked electronic coin data record Z, is in step 104, for example, by the issuing authority
  • 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
  • a request 210 from a central bank or a subscriber unit TE or a commercial bank for the generation of an electronic coin data set is received by the issuing entity 1 .
  • the issuing entity 1 has, for example, a coin generation unit 11 and a coin dispensing unit 12.
  • the two units 11, 12 are separate from one another and have an air gap 14.
  • the air gap 14 serves to ensure that the highly sensitive, security-relevant data and units of the payment system BZ in the issuing authority 1, in particular a private key PK and a random number generator, cannot be read via a network attack on the issuing authority 1 and used to manipulate the payment system BZ.
  • the coin generation Unit 11 can be completely isolated.
  • the coin generation unit 11 has no interface to a network such as TCP/IP, the Internet, the mobile network, etc.
  • the air gap process 14 is not explained further here.
  • the data transmission from and to the publishing entity preferably takes place using an http protocol.
  • the electronic coin data record also abbreviated as eMDS below, C can be requested in advance from the issuer entity 1 and optionally received by a terminal M (or an SE) or the issuer entity 1 or another payment system.
  • the request 210 may have been generated by a central bank la.
  • a subscriber unit TE requests the electronic coin data record C.
  • Steps 104 and 105 may correspond to steps 104 and 105 of FIG.
  • An action or modification (dividing, connecting, switching, transmitting, deactivating, exchanging, alarming) on the eMDS C can correspond to one of the actions in FIGS. 7 to 11. These modifications are also described by way of example in patent applications WO 2020/212337 A1 and WO 2020/212331 A1.
  • a genuine random number is generated as the concealment value n , which is preferably a concealment amount.
  • the obfuscation value n is known in the direct transaction layer 3 and for newly issued eMDS also in the issuer instance 1, it is secret for the other instances of the payment system BZ, ie also for the coin register 2.
  • the concealment value n is, for example, a 32-byte positive random number. The generation takes place, for example, by means of a real random number generator.
  • ECDSA Elliptic Curve Digital Signature Algorithm
  • the concealment value n is linked to a monetary amount Di.
  • the monetary amount Di is, for example, an integer value, preferably of the 32-bit unsigned integer value data type.
  • the monetary amount Di for example, only has a limited value range of powers of two. A value of zero (“0”) as a monetary amount Di could be invalid.
  • An i-th electronic coin data set according to the invention which was generated by the coin generation unit 1, could therefore read:
  • Ci ⁇ ; nj (1)
  • a valid electronic coin record C can be used for payment.
  • the owner of the two values Di and n 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 RDSi, for example a masked electronic coin data set Zi.
  • Zi preferably represents a point in an elliptic curve-based cryptographic method, for example an Elliptic Curve Digital Signature Algorithm , ECDSA for short, preferably of the secp256rl.
  • Zi may be encoded in an uncompressed form as specified in Standards for Efficient Cryptography, Elliptic Curve Cryptography; Section 2.3.3 is given as an example.
  • a masked electronic coin data set Zi is obtained as a register data set RDS by applying a homomorphic one-way function f(Ci) according to equation (2):
  • This function f(Ci) is public, i.e. every system participant can call up and use this function.
  • This function f(Ci) is defined according to equation (3):
  • 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.
  • G and H are generator points of an elliptic curve encryption, ECC, - ie private keys of the ECC are.
  • n H n H (4) the link n must be practically untraceable in order to prevent the monetary amount Di from being manipulated and a valid Zi being able to be calculated nonetheless. For example is:
  • Equation (3) is a "Pederson commitment for ECC” that ensures that the monetary amount u can be granted to a coin register 2, i.e. "committed", without revealing it to the coin register 2.
  • the obfuscation value n is referred to as the obfuscation amount because it at least masks the monetary amount of the eMDS.
  • a register data record RDS also abbreviated to some extent below as RDS, is then equated with a masked coin data record Z.
  • step 104 register, registration request
  • the registration request comprising the register record.
  • the RDS can be provided by the issuing authority 1 for the coin register 2 .
  • the RDS is preferably generated in the coin generator 11, but can also be generated in the coin dispensing unit 12.
  • Equations (3) and (3-1) make it possible through the entropy of the amount of concealment n to obtain a cryptographically strong Zi even with a small value range for monetary amounts Ui. Thus, a simple brute force attack by merely estimating monetary amounts Ui is practically impossible.
  • Equation (3) is a one-way function, which means that computing Zi from Ci is easy because an efficient algorithm exists, whereas computing Ci from Zi is very difficult because there is no polynomial-time solvable algorithm.
  • equation (3) is homomorphic for addition and subtraction, which means that:
  • the coin data set Ci can be divided according to equation (1) into:
  • 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 , Ck has.
  • the condition of equation (9) is checked to validate split coin data sets C j and C k and to invalidate coin data set Ci.
  • Such a splitting 110 of an electronic coin record Ci is shown in FIG.
  • Electronic coin data records C can also be combined (connected) 109 in the same way, see FIG. 7 and the explanations relating thereto.
  • a ring signature is preferably used for each bit
  • Cij aj H + bj G (9c)
  • Cij - aj - H (9d) it being possible in one embodiment to carry out a ring signature only for specific bits.
  • the embodiment of the payment system BZ shown in FIG. 1 shows in particular the generation of an electronic coin data record C for direct issue to a subscriber unit TE1 (step 102).
  • the issuance to the subscriber unit TE1 takes place indirectly via a bank entity 4 through steps 102' (providing the eMDS C to the bank 4) and in the subsequent step 102" (providing the eMDS C to the TE1).
  • the generation of the RDS by the publishing entity 1 is only optional here and can also be carried out by the subscriber units TE1, TE2.
  • FIG. 2 shows a further development of the payment system BZ shown in FIG. Reference is hereby made to the explanations of FIG. 1 in order to avoid repetition.
  • the deactivation of a coin data record C is described in FIG.
  • a participant unit TE1 decides to deactivate and return the coin data set C and sends a deactivation request in step 111.
  • This step 111 can be the mapping of a participant's request, namely to credit a monetary amount of a coin data set to an account of the participant, or can be based on an evaluation of a test value pi, in which it was determined that the coin data set meets the criteria for a return, e.g.
  • Step 111 is displayed directly to the coin dispensing unit 12 .
  • the display can also take place indirectly via the rank instance 4 (similar to obtaining the coin data record), which is illustrated in FIG. 2 by steps 111' and 111''.
  • the monetary amount is credited to an account of the participant or cash is issued at an output compartment of the unit 12 in the following step (not 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.
  • the RDS of the deactivated (credited) coin data record is deleted from coin register 2 (RDS crossed out).
  • the coin issuing unit 12 of the issuer entity 1 of FIG. 1 has a receiving unit 15 (not shown in FIG. not shown) arrive.
  • the receiving unit 15 transmits the request 210 to the coin generation unit 11 by means of an air gap process 14'.
  • the same mechanisms as in the previously mentioned air gap process 14 can be applied and the same interfaces can be used.
  • the coin generation unit 11 generates the coin data set C and also the register data set RDS.
  • the coin generation unit 11 signs the generated register data record RDS with a private key PK of the issuing authority 1.
  • the combination of electronic coin data record C, register data record RDS and signed register data record [RDS]Sig(PK) is Expression Ai, represented for example as a QR code.
  • This expression Ai is provided to the coin dispensing unit 12 via the air gap process 14 .
  • the expression Ai is read in by means of a reading unit 16, for example a QR code scanner, in order to obtain the electronic coin data record C.
  • the coin generation unit 11 generates metadata MC, which is added to the expression Ai or made available to the coin dispensing unit 12 as an independent transmission.
  • the unit 16 checks the uniqueness of the coin data record Ci, for example by comparing the metadata MCi with metadata of the coin data records C existing in the payment system BZ. For example, a serial number or a coin identifier is used for this check. If the uniqueness of the coin data record Ci is confirmed, it is stored in the coin store 17 of the issuer entity 1 and (time-uncorrelated) is output to a subscriber unit TE in step 102 . Providing the RDS to the Coin register 2 can already take place after checking for uniqueness or only when a coin data set Ci is requested by a TE or the rank instance 4 .
  • the provision of the RDS in step 102 to the coin register 2 enables the coin data set Ci to be registered in the payment system BZ.
  • the RDS and the signed [RDS]Sig(PK) are provided.
  • the signature of the signed [RDS]Sig(PK) can be checked in the coin register 2 and if the check is successful, the RDS is registered as valid in the coin register 2.
  • the coin register 2 only receives the signed register data record [RDS]Sig(PK).
  • the signature can be checked in the coin register 2 with the public key of the issuing authority 1 and if the check was successful be registered as valid in coin register 2 by the RDS.
  • the transmitted electronic coin data record Ci is received as Ci * in TE2.
  • the TE2 With the receipt of the electronic coin dataset Ci * , the TE2 is in possession of the digital money that the electronic coin dataset Ci * represents. With the direct transfer 105 it is available to the TE2 for further actions.
  • SEI Due to the higher degree of trustworthiness when using SEs, SEI, SE2 can trust one another and, in principle, no further steps are necessary for the transmission 105 . However, the SE2 does not know whether the electronic coin data record Ci * is actually valid. To further secure the transmission 105, further steps can be provided in the method, as will be explained below.
  • another RDS for example the masked transmitted electronic coin data record Zi *
  • the RDS ie, for example, the masked, transmitted electronic coin data record Zi *
  • the RDS 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, i.e. for example a match with a registered and valid masked electronic coin data set Zi, the validity of the received coin data set Ci * is displayed to the SE2 and it applies that the received electronic coin data set Ci * is equal to the registered electronic Coin record Ci is.
  • the validity check can be used to determine that the received electronic coin data set Ci * 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.
  • the electronic coin data record Ci authorizes payment, i.e. to carry out a transaction successfully, in particular if the coin data record Ci is valid, for example if the electronic coin data record Ci has an active status.
  • the status is preferably only set to an active status upon receipt of the deletion confirmation from the SEI.
  • the masked electronic coin records Zi are registered in the coin register 2, such as a public database. This registration 104 first makes it possible to check the validity of the electronic coin data set Ci, for example whether new monetary amounts were (illegally) created.
  • the masked electronic coin data sets Zi are stored in the coin register 2. All processing of the electronic coin data record Zi is registered there, whereas the actual transmission of the digital money takes place in a (secret, i.e. not known to the public) direct transaction layer 3 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 .
  • Examples of operations are listed in Table 1 below, whereby a corresponding processing step is also carried out with the specified command:
  • Table 1 Number of operations that can be carried out per processing of a C in the TE or the publisher instance Other operations not listed in Table 1 may be required, such as changing currency or cashing the monetary amount into an account. Instead of the implementation listed, other implementations are also conceivable which imply other operations.
  • Table 1 shows that for each coin data set, each of the processing (modification) “Create”, “Return”, “Split”, “Connect” and “Switch” different operations “Create Signature”; “Create random number”; “Create Mask”; “Range check” can be provided, with each of the processing operations being registered in the coin register 2 and appended there in unchangeable form to a list of previous processing operations for masked electronic coin data sets Zi.
  • the processing operations "Create” and “Return” of an electronic coin data record C are only executed in secure locations and/or only by selected entities, for example the issuer entity 1, as privileged entities, while the operations of all other processing operations are carried out on the subscriber units TE, i.e the terminals M or their security elements SE can be performed.
  • the subscriber units TE can be designed using an e-wallet for electronic coin data records Ci (with the test value p, pup ⁇ ), i.e. as an electronic purse with a memory area in which a large number of coin data records Ci can be stored, and thus, for example, in the form of an application be implemented on a smartphone or IT system of a retailer, a commercial bank or another market participant.
  • the components in the subscriber unit TE as shown in Table 3 are implemented in software. It is assumed that the coin register 2, a transaction register (not shown) and/or a monitoring register (not shown) is based on a server or on a DLT and is operated by a number of trusted market participants.
  • 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.
  • FIG. 4 shows a process flow chart of a process 200 for generating and issuing an electronic coin data record C in an issuing entity 1 .
  • a coin request is received in the issuing entity 1, for example the receiving unit 150.
  • the request 101 can be made by a central bank or by a subscriber unit TE or a commercial bank 4 of the payment system BZ.
  • this request is made using an air gap Process 14' to the coin generation unit 11 of the issuer entity 1.
  • step 101 a coin request is received in the issuing entity 1, for example the receiving unit 150.
  • the request 101 can be made by a central bank or by a subscriber unit TE or a commercial bank 4 of the payment system BZ.
  • this request is made using an air gap Process 14' to the coin generation unit 11 of the issuer entity 1.
  • an electronic coin data record is generated.
  • an RDS and a signed RDS can be generated in optional steps 203 and 204.
  • metadata is generated.
  • the electronic coin data record C is sent to the coin dispensing unit of the issuer instance 1 by means of the air gap process 14, optionally with the RDS and the signed RDS.
  • An expression A is preferably generated for this purpose.
  • the expression A is passed to the coin dispensing unit 12 in a dog-like manner.
  • a secured transport box (container) is used to transfer the printout (or printouts). The printout is brought to a reading section of the coin dispensing unit 12 to be read.
  • a banknote production infrastructure is preferably used.
  • the RDS and the signed RDS can be generated if this is not already the case in steps
  • step 209 the generated electronic coin data record C is output to a requesting (step 101) subscriber unit TE or a bank entity 4.
  • step 104 the coin data record C is registered in the coin register 2, for example by transmitting the RDS and/or the signed RDS.
  • Figure 5 shows a data structure for a coin register 2 of the previous figures. 5 shows data from the coin register 2 for illustration purposes; the masked electronic coin data sets Zi and, if applicable, their processing are registered here.
  • the coin register 2 can be accommodated in a server instance. Register 2 is preferably arranged locally at a distance from the subscriber units TE and is 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 sets Zi.
  • the individual operations or their test results that is to say the intermediate results of processing, are recorded in the coin register 2 .
  • 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.
  • Fig. 5 also shows the entry in the coin register 2 for the modification "Freeze”, also known as "blocking", on an electronic coin data set C, in which a temporary deactivation of the electronic coin data set C, better the monetary value Amount of the electronic coin data record C, is caused without removing the monetary amount from the payment system (to destroy).
  • an electronic coin data record is blocked (frozen), ie the monetary amount is still available, but cannot be used by any participant—in the context of a payment transaction—to see monetary amounts from stau.
  • This "freezing" modification cannot be carried out by a subscriber unit TE, ie not by the owner of the electronic coin data set C.
  • This "freezing" modification can only be initiated and carried out by a privileged authority, for example an issuer authority 1 or a monitoring authority (not the coin register 2).
  • This privileged authority can be, for example, an authorized authority, for example a criminal prosecution authority, or a combination of several trustworthy authorities. In this way, a sum of monetary value from a suspect can be confiscated without the money being destroyed in the BZ payment system.
  • the coin data sets C deactivated by a "freeze” action are reactivated (i.e. reactivated).
  • This "reactivation" modification can only be initiated and carried out by a privileged authority, for example an issuer authority 1 or a monitoring authority (not the coin register 2).
  • This privileged authority can be, for example, an authorized authority, for example a criminal prosecution authority, or a combination of several trustworthy authorities. In this way, a monetary amount of a suspect can be released again, for example after the suspect has been proven innocent.
  • a request 210 from a central bank 1a is used in the issuing entity 1 in order to generate an eMDS C.
  • the procedure is in accordance with the steps from the process flow diagram of the process 200 according to FIG. 6 .
  • the eMDS C is generated and provided as a printout A to the coin dispensing unit 12 in the air gap process 206 .
  • Unit 12 receives the eMDS C and optionally creates the RDS and the signed RDS in steps 207 and 208.
  • the RDS is registered with coin register 2.
  • the query 101 provides the eMDS C in step 209 (102) to the TE1.
  • the request 210 of a central bank 1a is used in the issuing entity 1 in order to generate an eMDS C.
  • the request is routed to the unit 11 in step 201, preferably as an air gap process.
  • the procedure is in accordance with the steps from the process flow diagram of the process 200 according to FIG. 6 .
  • steps 202, 203, 204 the eMDS C, the RDS and the signed RDS are generated and made available as a printout A to the coin dispensing unit 12 in the air gap process 206.
  • the unit 12 receives the eMDS C, the RDS and the signed RDS.
  • step 104 the RDS and the signed RDS are registered with the coin register 2.
  • the query 101 provides the eMDS C in step 209 (102) to the TE1.
  • the signed RDS is provided by the unit 12 to the coin register 2 and the RDS is generated in the TE1 and then sent to the coin register 2 (shown in dashed lines).
  • FIG. 7 once again shows, by way of example, the known steps possible for each subscriber unit of the value-based system. Some of the area verifications to be provided in the case of the use of equation (3) are not shown.
  • a newly issued, signed, masked electronic coin data set Zi is sent to the coin register 2 in step 1015 and the masked electronic coin data set Zi is registered there.
  • the subscriber unit TE1 receives the associated electronic coin data set Ci.
  • steps 103, 104 which are only optional, the subscriber unit TE1 checks whether a masked, electronic coin data record is registered for the coin data record Ci received.
  • step 103 the subscriber unit TE1 masks the received electronic coin data set Ci, in particular according to equation (3) or (3-1) and sends a status request to the coin register for the masked electronic coin data set Zi*.
  • the subscriber unit TE1 can switch the received electronic coin data set.
  • step 105 the coin data record Ci is transmitted in the direct transaction layer 3 to the second subscriber unit TE2.
  • steps 106 and 107 there is again a validity check with prior masking, in which case the coin register 2 confirms the validity of the coin data set Zi or Ci.
  • a received coin data set C k is switched over (of course, the received coin data set Ci could also be switched over) to a new one Coin record Ci, which invalidates coin record C k and prevents double-spend.
  • the monetary amount V k of the transmitted coin data record C k is used as the "new" monetary amount.
  • a concealment amount n is created.
  • the additional obfuscation amount r add is used to prove 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 records Zi and Z k are sent to the coin register 2 in a switchover request and the switchover from C k to Ci is thus instructed.
  • TE2 can generate an EVP according to Equations 9e through 9g to indicate that TE2 owns two coins Ci and Ck and both monetary amounts are equal. TE2 can then send Zi, Zk and the EVP to coin register 2 for verification and validation.
  • step 108 ' the corresponding check is carried out in the coin register 2.
  • the coin register 2 checks whether the masked coin data set Z k to be switched is a registered masked coin data set, in particular whether its status is valid, checks whether the changeover request is amount-neutral and registers - if both checks have been positive - the new masked coin data record Zi as a valid masked coin data record.
  • Z k is entered in column 22a and in column 23b the coin data record Zi to be rewritten according to the table in FIG.
  • a check is then carried out in the coin register 2 to determine whether Z k is (still) valid, i.e. whether the last processing of Z k is entered in one of the columns 23a/b (as proof that Z k is not further divided or deactivated or connected) and whether a check for the last processing failed.
  • Zi is entered in column 23b and the markings in columns 25, 26, 27 are initially set to "0". A check is now made as to whether Zi is valid. If it is good, the mark in column 25 is set to “1”, otherwise to “0”.
  • the optional step 109 two coin data records C k and Ci are connected to a new coin data record C m , as a result of which the coin data records C k , Ci become invalid and double dispensing is prevented.
  • the monetary amount n m is calculated from the two monetary amounts U k and ni formed.
  • the concealment amount r m is formed from the two concealment amounts r k and n.
  • 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.
  • a signature S k and a signature Si are generated and communicated to the monitoring register 6 and/or the coin register 2 .
  • TE2 may generate an EVP according to Equations 9e through 9g to indicate that TE2 owns the two coins Ci and Ck and no new monetary amounts have been generated. TE can then send Z m and Zi or Z m and Z k as well as the EVP to coin register 2 for checking and validation.
  • step 109' the corresponding check takes place in the coin register 2.
  • the markings in columns 25, 26, 27 are initially set to "0". A check is now made as to whether Z m is valid. If it is good, the mark in column 25 is set to “1”, otherwise to “0”. A check is now made that Zi plus Z k is equal to Z m and the marking in column 26 is set accordingly. Furthermore, it is checked whether the areas are conclusive, then the marking is set in column 27.
  • the coin register 2 can check the EVP using Equations 9h and 9i and then mark Z m as valid and mark Z k and Zi as invalid.
  • a coin data set Ci is asymmetrically divided into two partial coin data sets C k and Q, whereby the coin data set Ci is invalidated and the two asymmetrically divided partial coin data sets C k and Q are to be validated.
  • the monetary amount Ui is divided into monetary partial amounts Uk and Uj of different sizes .
  • the concealment amount n is divided into the two concealment amounts rk and h.
  • the masked coin part data sets Z k and Z j are obtained by means of equation (3) and sent to the coin register 2 with further information, for example the range checks (zero-knowledge proofs), and the splitting is requested as processing.
  • a signature Si is created and sent to the coin register 2 .
  • TE2 can generate an EVP according to Equations 9e through 9g to indicate that TE2 is in possession of the two coins Ci, Q and Ck and none new monetary amounts were generated.
  • TE can then send Zi and Zj or Zi and Zk as well as the EVP to coin register 2 for verification and validation.
  • step 110' the corresponding check takes place in the coin register 2.
  • the markings in columns 25, 26, 27 are initially set to "0". A check is now made as to whether Zj and Zk are valid, in which case the check according to equations (16) and (17) can be used. If it is good, the marking in column 25 is set to "1". A check is now carried out, the calculation according to equation (10) shows that Zi is equal to Zk plus Zj and the marking in column 26 is set accordingly. Furthermore, it is checked whether the areas are conclusive, then the marking is set in column 27. When checking the signature, it can be checked whether the second subscriber unit TE2 has exceeded a limit value for monetary amounts. The check is carried out with regard to a unit of time, for example a daily limit value could be monitored with it. Alternatively or additionally, the coin register 2 can check the EVP using equations 9h and 9i and then mark Zi and Zj as valid and mark Zk as invalid.
  • FIG. 9 An exemplary deactivation is shown in FIG. 9 .
  • a deactivation request 111 is sent to the coin dispensing unit 12 by the TE1.
  • the coin dispensing unit 12 creates a delete request 212 and sends it to the coin register 2 in order to delete the RDS for the eMDS C to be deactivated.
  • the monetary amount of the eMDS C is credited to the participant's account.
  • FIG. 10 shows an embodiment of a method flow diagram of a method 400 for registering 104 a coin data record within an atomic exchange procedure between the different systems. The steps of FIG. 10 are also shown in FIG. 11 and will be described together with FIG.
  • Method 400 depicts an atomic exchange method between TE1 and TE2, in which TE2 would like to exchange a data record from a system other than the payment system BZ with an eMDS C of TE2's BZ.
  • the BZ payment system is value-based System, in particular of the type described so far.
  • the other system Sys2 is another payment system and supports - preferably as an access-based system - smart contracts, for example it can be a system for exchanging a cryptocurrency such as BitCoin, Lightning, LiteCoin etc.
  • the other system is a bitcoin blockchain system.
  • TE2 wants to send Bitcoins to TE1 and receive a C from TE1 in return.
  • TE2 has a BitCoin wallet with one Bitcoin and would like to receive the eMDS C from TE1 in its CBDC data storage. Accordingly, TE1 and TE2 are both set up to carry out transactions in both systems Sys2, BZ.
  • TE1 has C and would like Bitcoin from TE1 in return. For the sake of simplicity, it is assumed that TE1 has (only) one C and TE2 (only) one bitcoin to be exchanged with each other.
  • one or both subscriber units has a plurality of eMDS C and/or data sets (such as BitCoin) and exchanges a plurality of eMDS C of the payment system and/or data sets of the other system as part of the atomic swap.
  • eMDS C and/or data sets such as BitCoin
  • a new electronic coin data set (the eMD of TE1) is registered 104 in the coin register 2. This can also be referred to as the registration phase and is primarily part of this application.
  • the setup is first carried out by TE2 and then the registration by TE1. Reversing the order of "setup” and “registration” is not completely impossible, so that TE1 can also initiate the atomic exchange. However, the order shown increases the security of the solution.
  • the exchange (including SWAP) is carried out in steps 410 to 418, the eMD changes ownership from TE1 to TE2 in step 410, after various checks, TE2 places the original image data record in step 414 to unlock the HTLC-secured data record Coin register 2 open. TE1 can then unlock the HTLC-secured data record and credit it (redeem).
  • Steps 401 to 418 are linked to defined periods of time TI and T2.
  • TE2 In step 401, TE2 generates a secret for this purpose, also referred to as a pre-image.
  • This secret is initially unknown to TE1 and is a database for a scatter value calculation via the original image by TE2.
  • the scatter value H is calculated using the scatter value function sha256 over the original image, for example.
  • TE2 defines a time period TI.
  • the scatter value H and the time span TI form the basis for a Hash Timelock contract, HTLC for short.
  • the TE2 In step 402, the TE2 generates a Bitcoin transaction - also referred to below as a data record.
  • the HTLC secures the data set in such a way that a recipient of the data set needs the original image of the scatter value H in order to be able to use the data set as intended.
  • the time period TI is provided so that TE2 can use the data set again as intended if within the time period TI there is no unlocking by means of an original image from another TE, i.e. the data set has not been redeemed using an original image.
  • step 403 the data set created (bitcoin, smart contracts, cryptocurrency) is introduced into a system Sys2, a system that is not the BZ payment system.
  • Sys2 is a blockchain architecture
  • the record is committed in one node, Sys2-Node.
  • the HTLC added to the data record means that TE1 must know the secret (original image) in order to unlock the data record in Sys2 and to be able to credit the data record to itself (“redeem”).
  • the hash value H and the time duration TI of the HTLC of the data record of Sys2 are queried or received by TE1 at Sys2.
  • a request-response scheme can be used that is additionally secured by authentication and, if necessary, encrypted transmission.
  • TE1 creates a first electronic coin data set C k and a second electronic coin data set Q from an existing coin data set Ci.
  • the alternative with two generated electronic coin data records C k and Q is to be pursued further in FIG. The following three conditions apply to Ci, C k and Q:
  • step 406 the optional EVP jk and EVPik are calculated according to equations (9e) to (9g) and a time duration T2 is defined.
  • the time period T2 is, for example, a few days, preferably 3 days.
  • Zi if not already present
  • Z k and Z j are calculated.
  • a new registration request is sent.
  • This request can also be referred to as a SWAP command in the BZ system.
  • the coin register 2 receives the following elements: Zi, Z j optionally with EVPi- j and duration T2, and Z k optionally with EVPi- k and the hash value H from the HTLC of Sys2.
  • Z j is secured with the time duration T2 (time lock) and Z k is secured with the hash value H (hash lock), so that a registration request with HTLC is transmitted to the coin register 2 as a result.
  • the masked coin data set Z j is secured with the scatter value H (hashlock) in step 407 and the registration request is interpreted as a time-delayed changeover command (by the time span T2).
  • Either TE2 releases the hash lock at Z j by disclosing the original image data set to coin register 2, or coin register 2 switches back from Z j back to Zi for TE1, delayed by time span T2, because time span T2 has expired .
  • a SWAP is executed or an original state is restored.
  • EVPi- j is verified from Zi and Zj (optional),
  • SWAP The actual exchange
  • TE1 transmits the coin data record Q to TE2 in step 410.
  • TE2 checks the correctness of the monetary amount of Q .
  • TE2 queries coin register 2 for the availability of Z k and checks whether the hash H of Z k matches the hash H from the data set. In addition, TE2 checks whether the end of the time period T2 is still in the future.
  • a Z m is calculated and optionally in step 413 the EVP km is calculated according to equations (9e) to (9g).
  • TE2 sends a registration request (also referred to as REDEEM) to coin register 2 with Z m , (possibly EVP km ) and the original image data set from step 401.
  • REDEEM a registration request
  • step 415 If all up to three verifications in step 415 have been successfully performed, then:
  • step 415 If one of the up to three verifications in step 415 is not successful, then an error message is sent to TE2 and the atomic swap is aborted. After the time period T2 has elapsed, Z j is switched over to TE1 (or to a SWITCH command from TE1). After the period TI has expired, the data record in Sys2 is written back to TE2.
  • the TE1 queries the original image data record from the coin register 2.
  • the query can be further secured by authentication or encryption.
  • step 417 the TE1 uses the original image data set to unlock the HTLC-secured data set of the third-party system Sys2 and have the bitcoin credited to it.
  • TE2 refuses to disclose the original image data record from step 401.
  • the atomic swap has therefore failed.
  • TE1 sends a switch command in step 420 to switch Z j to TE2, whereupon Z k is automatically invalidated.
  • Z k cannot be validated.
  • an automatic switch is made to Zi in the coin register 2 in order to restore the original state.
  • TE2 can have the bitcoin from Sys2 credited to it again in step 421.
  • Coin data record n m monetary amount of an electric to be connected/connected.
  • Coin record pi coin record aging counter value k random number for EVP n obfuscation amount random number r 0 parent obfuscation amount random number of parent coin record h, i j obfuscation amount of a split electronic coin record r m obfuscation amount of an electronic coin record to be connected

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren (400) zum Registrieren (104) eines elektronischen Münzdatensatzes (C) in einem Münzregister (2) eines elektronischen Bezahlsystems (BZ) mit den Verfahrensschritten: Erzeugen (405), durch eine erste Teilnehmereinheit (TE1) des Bezahlsystems (BZ), eines elektronischen Münzdatensatzes (Cj) aufweisend einen monetären Betrag (νj) und einen Verschleierungswert (rj), wobei der monetäre Betrag (vνj) des erzeugten elektronischen Münzdatensatzes (Cj) einem monetären Betrag (m) eines in der ersten Teilnehmereinheit (TE1) vorhandenen elektronischen Münzdatensatzes (Ci) entspricht; Maskieren (406), durch die erste Teilnehmereinheit (TE1), des erzeugten elektronischen Münzdatensatzes (Cj) durch Anwenden einer Einwegfunktion (f(C)) auf mindestens ein Datenelement des elektronischen Münzdatensatzes (Cj) zum Erhalten eines maskierten erzeugten elektronischen Münzdatensatzes (Zj); Senden einer Registrierungsaufforderung (407) für den maskierten erzeugten elektronischen Münzdatensatz (Zj) von der ersten Teilnehmereinheit (TE1) an das Münzregister (2) zusammen mit einer Zeitsicherung, wobei die Zeitsicherung eine Zeitdauer (T2) vorgibt, bis zu der eine zweite Teilnehmereinheit (TE2) des Bezahlsystems (BZ) den erzeugten elektronischen Münzdatensatz (Cj) im Münzregister (2) auf sich umzuschalten kann. Die Erfindung betrifft zudem ein Münzregister (2), ein Bezahlsystem (BZ), eine Teilnehmereinheit (TE) und ein Computerprogrammprodukt.

Description

VERFAHREN ZUM REGISTRIEREN EINES ELEKTRONISCHEN MÜNZDATENSATZES IN EINEM MÜNZREGISTER; EIN MÜNZREGISTER; EINE TEILNEHMEREINHEIT UND
EIN COMPUTERPROGRAMMPRODUKT
TECHNISCHES GEBIET DER ERFINDUNG
Die Erfindung betrifft ein Verfahren zum Registrieren eines elektronischen Münzdatensatzes in einem Münzregister eines elektronischen Bezahlsystems. Das Registrieren des elektronischen Münzdatensatzes ist bevorzugt ein Teil eines atomaren Austauschverfahrens. Dabei wird eine Austausch-Aufforderung gesendet, um einen elektronischen Münzdatensatz des Bezahlsystems, insbesondere eines CBDC-basierten Bezahlsystems gegen einen Datensatz aus einem anderen System als dem Bezahlsystem au szutau sehen. Die Erfindung betrifft zudem ein Münzregister, eine Teilnehmereinheit und ein Computerprogrammprodukt.
TECHNISCHER HINTERGRUND DER ERFINDUNG Schutz der Privatsphäre ist ein wichtiger Wert für die Gesellschaft, besonders wenn sehr sensible Daten, wie Zahlungsinformationen, betroffen sind. Sicherheit von Bezahltransaktionen und den dazugehörigen Bezahltransaktionsdaten bedeutet sowohl Schutz der Vertraulichkeit der ausgetauschten Daten; als auch Schutz der Integrität der ausgetauschten Daten; als auch Schutz der Verfügbarkeit der ausgetauschten Daten.
Für elektronische Münzdatensätze müssen dabei grundlegende Kontrollfunktionen, insbesondere (1) das Erkennen von Mehrfachausgabe- Verfahren, auch Double-Spending genannt, und (2) das Erkennen von ungedeckten Zahlungen nachgewiesen werden können. Im Fall (1) versucht jemand denselben Münzdatensatz mehrfach auszugeben und im Fall (2) versucht jemand einen Münzdatensatz auszugeben, obwohl er kein Guthaben (mehr) besitzt.
Zudem steigt durch die Vielzahl von Transaktionen eines elektronischen Münzdatensatzes und auch durch die fortschreitende Lebensdauer das Risiko, dass an dem elektronischen Münzdatensatz Manipulation(en) vorgenommen werden.
Es soll perspektivisch möglich sein, ganz auf Bargeld (Banknoten und analoge Münzen), zumindest aber auf analoge Münzen, zu verzichten.
In der US 5,872,844 A ist ein elektronisches Vermögens System beschrieben. Elektronische Vermögenswerte werden in dem System von einer Institution ausgegeben. Die elektronischen Vermögenswerte werden von einer Brieftasche des Zahlers auf eine Brieftasche des Zahlungsempfängers übertragen. Die Brieftasche des Zahlungsempfängers reicht die übertragenen Vermögenswerte routinemäßig für eine mögliche Prüfung ein. Ein Betrugserkennungssystem entnimmt Stichproben von den zur Prüfung eingereichten Vermögenswerten, um „schlechte“ Vermögenswerte aufzudecken, die in betrügerischer Weise verwendet wurden. Bei einer solchen Aufdeckung identifiziert das Betrugserkennungssystem die elektronische Brieftasche, die den schlechten Vermögenswert verwendet hat, und kennzeichnet sie als „schlechte Brieftasche“. Das Betrugserkennungssystem stellt eine Liste derartiger schlechter elektronischer Brieftaschen zusammen und verteilt die Liste, um andere Brieftaschen vor den schlechten elektronischen Brieftaschen zu warnen. Wenn eine schlechte Brieftasche anschließend versucht, Vermögenswerte auszugeben (ob in betrügerischer Absicht oder nicht), wird der beabsichtigte Empfänger die Liste der schlechten Brieftaschen überprüfen und sich weigern, Geschäfte mit der schlechten Brieftasche zu tätigen.
Dieses bekannte System ist nicht anonym, denn ein Teilnehmer generiert aus einer Identitätsnummer ein Pseudonym, das sowohl für die Bezahltransaktionen zum anderen Teilnehmer als auch bei der Generierung und Ausgabe der Vermögenswerte (=elektronische Münzdatensätze) von der Institution verwendet werden muss. Die ausgegebenen Vermögenswerte enthalten zudem zwingend eine Signaturkette, wodurch der Speicherbedarf des Vermögenswerts pro Bezahltransaktion größer wird, der elektronische Münzdatensatz also wächst. Brieftaschen, die nicht vertrauenswürdig sind, werden an dem System gar nicht zugelassen.
Ein beispielhaftes Bezahlsystem ist in den Patentanmeldungen WO 2020/212337 Al und WO 2020/212331 Al. Auf die darin beschrieben Ausgestaltungen, insbesondere das Modifizieren (Umschalten, Verbinden, Aufteilen) von elektronischen Münzdatensätzen, das Maskieren von elektronischen Münzdatensätzen, das Registrieren der maskierten elektronischen Münzdatensätze, das Prüfen derer Gültigkeit wird hierin Bezug genommen.
Mittlerweile gibt es eine Vielzahl von unterschiedlichen Plattformen und Architekturen, in den Transaktionen, beispielsweise Bezahltransaktionen (Kryptowährungssysteme) oder digitale Verträge (Smart Contracts), als Beispiele moderner Computerprotokolle durchgeführt werden können. Laut Informationen von der Website „coinmarketcap.com“ sind (Stand 5. Oktober 2020) 7300 Kryptowährungssysteme bekannt. Üblicherweise sind Benutzer gezwungen, Transaktionen innerhalb eines dieser in sich geschlossenen Systeme durchzuführen. Wenn Benutzer (Teilnehmereinheiten) Datensätze von unterschiedlichen Systemen austauschen wollen, muss eine dritte unabhängige Instanz, beispielsweise ein Trustcenter, zur Überwachung, Verifizierung und/oder Authentisierung der einzelnen Benutzer angerufen werden. Die Leistungen von derartigen dritten Instanzen sind nicht kostenfrei, sodass seit längerem der Wunsch besteht, Datensätze unterschiedlicher Systeme vereinfacht miteinander auszutauschen, ohne dabei eine systemunabhängige vertrauenswürdige Instanz zu verwenden. Ein Ansatz für systemübergreifende Transaktionen ohne dritte Instanz sind sogenannte atomare Austauschverfahren (englisch Atomic Swaps), bei denen eine Transaktion auf unterschiedlichen Systemen den wechselseitigen Austausch von Datensätzen nur vollständig oder gar nicht ermöglicht. Somit kann ein Fall, bei dem ein Benutzer seinen Datensatz bereits an einen anderen Benutzer übertragen hat, dieser andere Benutzer aber seinen Datensatz nicht zur Verfügung stellt, nicht auftreten.
Aus der Veröffentlichung „Atomic Cross-Chain Swaps“ von Maurice Herlihy der Brown University of Rhode Island aus dem Jahr 2018 ist es bekannt, atomare Austauschverfahren, englisch „atomic swaps“, durchzuführen, um Datensätze (zugangsbasierte Datensätze) verschiedener zugangsbasierter Systeme (hier Blockchain-Systeme) zwischen den Teilnehmereinheiten auszutauschen, ohne dass eine vermittelnde dritte Instanz, beispielsweise ein Trustcenter, verwendet wird. Zur Absicherung der auszutauschenden zugangsbasierten Datensätze werden Hash-Timelock Contracts, kurz HTLCs, eingesetzt, die eine Streu wertsicherung (Hashlock) basierend auf einem temporären Geheimnis (Urbild) und eine Zeitsicherung (Timelock) zur Absicherung des Datensatzes umfassen. Dieses Verfahren sieht nur den Austausch zugangsbasierter Datensätze unterschiedlicher zugangsbasierter Systeme vor. Ein Austausch auch mit nicht-zugangsbasierten Datensätzen, wie wertbasierten Datensätzen, beispielsweise den elektronischen Münzdatensätzen einer digitalen Zentralbankwährung (CBDC - Central Bank Digital Currency), ist zunächst nicht möglich, unter anderem da entsprechende Streu wert-Prüfungen zur Verifizierung und Entsicherung der HTLCs nicht in diesen wertbasierten Datensätzen abgebildet werden können.
Es ist daher die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein Bezahlsystem zu schaffen, in denen eine Bezahltransaktion zwischen Teilnehmern eines öffentlichen Bezahlsystems sicher, flexibel und einfach ausgestaltet ist. Dabei soll insbesondere eine direkte und anonyme Bezahlung zwischen den Teilnehmern des Bezahlsystems geschaffen werden. Die ausgetauschten elektronischen Münzdatensätze sollen vertraulich gegenüber anderen Systemteilnehmem sein, aber jedem Systemteilnehmer erlauben, grundlegende Prüfungen an dem elektronischen Münzdatensatz durchzuführen, nämlich (1) das Erkennen von Mehrfach - Ausgabe-Versuchen; (2) das Erkennen von Versuchen mit nicht vorhandenen monetären Beträgen zu zahlen und (3) das Erkennen von Rückgabekriterien für bereits ausgegebene Münzdatensätze, beispielsweise dass ein elektronischer Münzdatensatz verfallen soll.
Es ist eine Aufgabe der vorliegenden Erfindung, Datensätze unterschiedlicher Transaktions Systeme atomar auszutauschen, ohne eine dritte Instanz, wie ein Trustcenter, zu verwenden. Dabei soll es möglich sein, wertbasierte Datensätze eines ersten wertbasierten Systems auch mit zugangsbasierten Datensätzen eines vom ersten System verschiedenen zweiten Systems au szutau sehen. ZUSAMMENFASSUNG DER ERFINDUNG
Die gestellten Aufgaben werden mit den Merkmalen der unabhängigen Patentansprüche gelöst. Weitere vorteilhafte Ausgestaltungen sind in den abhängigen Patentansprüchen beschrieben.
Die Aufgabe wird mit einem Verfahren zum Registrieren eines elektronischen Münzdatensatzes in einem Münzregister eines elektronischen Bezahlsystems gelöst. Das Verfahren umfasst die folgenden Verfahrensschritten:
Erzeugen, durch eine erste Teilnehmereinheit des Bezahlsystems, eines elektronischen Münzdatensatzes aufweisend einen monetären Betrag und einen Verschleierungswert, wobei der monetäre Betrag des erzeugten elektronischen Münzdatensatzes einem monetären Betrag eines bereits in der ersten Teilnehmereinheit vorhandenen elektronischen Münzdatensatzes entspricht. Mit diesem Erzeugen wird ein neuer Münzdatensatz geschaffen, der den geforderten monetären Betrag umfasst. Das Erzeugen auf Basis eines bereits vorhandenen Münzdatensatzes stellt sicher, dass kein neues Geld generiert wird, sondern der bestehende Datensatz lediglich umgemünzt (also auf eine andere Teilnehmereinheit umgeschaltet) wird.
Maskieren, durch die erste Teilnehmereinheit, des erzeugten elektronischen Münzdatensatzes durch Anwenden einer, beispielsweise homomorphen, Einwegfunktion auf mindestens ein Datenelement des elektronischen Münzdatensatzes zum Erhalten eines maskierten erzeugten elektronischen Münzdatensatzes.
Senden einer Registrierungsaufforderung für den maskierten erzeugten elektronischen Münzdatensatz von der ersten Teilnehmereinheit an das Münzregister zusammen mit einer Zeitsicherung, wobei die Zeitsicherung (=timelock) eine Zeitdauer vorgibt, bis zu der eine zweite Teilnehmereinheit des Bezahlsystems den erzeugten elektronischen Münzdatensatz im Münzregister auf sich umzuschalten kann. Im Ergebnis dieses Schrittes erhält das Münzregister eine zeitgesicherte maskierte elektronische Münze, die (nur) binnen der Zeitdauer umschaltbar ist. Erfolgt keine Umschaltung binnen dieser Zeit, wird der Urzustand wiederhergestellt, d.h. die Umschaltung auf die zweite Teilnehmereinheit schlägt fehl. Dieser Urzustand kann automatisch mit Zeitdauerablauf erfolgen - wie nachfolgend noch beschrieben wird - oder er kann durch eine Umschalt-Modifikation durch die erste Teilnehmereinheit erzwungen werden. Das Grundprinzip eines Umschaltens als Modifikation eines elektronischen Münzdatensatzes ist bereits in den Patentanmeldungen WO 2020/212337 Al und WO 2020/212331 Al ausreichend beschrieben und es wird darauf Bezug genommen.
Damit wird in einem wertbasierten Bezahlsystem, bei dem insbesondere elektronische Münzdatensätze einer CBDC ausgetauscht werden, eine Möglichkeit geschaffen, zeitgesicherte Registrierungen im Münzregister vorzunehmen. Es ist einem Teilnehmer am Bezahlsystem nur binnen dieser definierten Zeitdauer technisch möglich, den elektronischen Münzdatensatz auf sich umzuschalten, umgangssprachlich auch als „ummünzen“ bezeichnet.
Das Maskieren mit einer homomorphen Einwegfunktion ist in den Patentanmeldungen WO 2020/212337 Al und WO 2020/212331 Al ausreichend beschrieben und es wird darauf Bezug genommen. Der Verschleierungswert kann ein Verschleierungsbetrag sein, wobei die Einwegfunktion zumindest auf den Geldbetrag, vorzugsweise auf den Geldbetrag und den Verschleierungsbetrag, angewendet wird. Das Ergebnis der Anwendung der Einwegfunktion bildet vorzugsweise den maskierten elektronischen Münzdatensatz. Die Einwegfunktion wird insbesondere auf die beiden genannten (bzw. alle) Datenelemente des elektronischen Münzdatensatzes angewandt. Alternativ kann in dem Schritt des Maskierens aus dem Verschleierungswert ein maskierter Verschleierungswert erzeugt werden, wobei der maskierte elektronische Münzdatensatz den Geldbetrag und den maskierten Verschleierungswert als Datenelemente umfasst.
Atomare Tauschgeschäfte erfordern, dass zwei Teilnehmereinheiten den Erhalt von Datensätzen innerhalb eines bestimmten Zeitrahmens bestätigen. Wenn eine der Teilnehmereinheiten die Transaktion nicht innerhalb der Zeitdauer bestätigt, wird die gesamte Transaktion für ungültig erklärt, und es werden keine Datensätze ausgetauscht. Damit verhindert man ein Szenario, in dem eine Teilnehmereinheit einen Datensatz erhält, dann aber zum Versenden des eigenen Datensatzes neu verhandeln möchte und ggf. beide Datensätze besitzt.
Der Begriff atomar bzw. "atomic" bezieht sich auf die Tatsache, dass dieses Tauschgeschäft entweder vollständig stattfindet oder gar nicht stattfinden. Wenn eine der Teilnehmereinheiten aufgibt oder nicht (zeitgerecht) tut, was von ihr gemäß dem Computerprotokoll verlangt wird, schlägt das Tauschgeschäft fehl und die Datensätze werden wieder automatisch an ihre bisherigen Eigentümer (Teilnehmereinheiten) zurückgegeben, es wird ein Urzustand wiederhergestellt, also ein Zustand als wäre das Tauschgeschäft nie begonnen worden.
Eine Zeitdauer ist dabei eine Zeitspanne zwischen dem Senden der Registrierungsanforderung und dem gewünschten Ende der Möglichkeit der anderen Teilnehmereinheit, den Datensatz in Besitz zu nehmen. Das Ende der Zeitspanne liegt ausgehend vom Sendezeitpunkt in der Zukunft und beträgt bevorzugt einige Tage, beispielsweise 3 Tage.
Das hier beschriebene Registrieren- Verfahren kann ein Teil eines atomaren Austauschverfahrens sein. Es stellt den Kern, nämlich das für einen „Atomic Swap“ notwendige Registrierungsvorgang beim Münzregister eines zum Austausch von wertbasierten Münzdatensätzen (wie CBDC-Münzdatensätzen) vorgesehenen Bezahlsystems zur Verfügung. Eine Zeitsicherung, auch als „Timelock“ oder „Zeitschloss“ oder „Zeitblockade“ bezeichnet, ist bevorzugt ein kryptographisches Primitiv. Diese Zeitsicherung definiert eine Zeitspanne, binnen der die erste Teilnehmereinheit den elektronischen Münzdatensatz nicht auf sich registrieren lassen kann und/oder eine Zeitspanne, binnen der die zweite Teilnehmereinheit den elektronischen Münzdatensatz auf sich registrieren lassen kann. Dieser Timelock ist demnach eine Funktion, die sicherstellt, dass elektronische Münzdatensatz nur innerhalb eines vorgegebenen Zeitraums ihren Besitzer wechseln können, also umgeschaltet (umgemünzt) werden kann. Erst nach Ablauf dieser Zeitspanne, kann die erste Teilnehmereinheit den elektronischen Münzdatensatz auf sich (zurück-)registrieren lassen, also „(zurück-)umschalten“. Diese Zeitsicherungen können Teil von Hash-Timelock-Contracts, HTLC, sein. Sie können auch verwendet werden, um das Registrieren des erzeugten elektronischen Münzdatensatzes für den mit der Zeitspanne definierten Zeitraum zu blockieren. Diese Zeitsicherung bildete einen eindeutigen Willen der ersten Teilnehmereinheit ab, den erzeugten elektronischen Münzdatensatz an eine zweite Teilnehmereinheit zu übertragen.
Die Registrierungsaufforderung kann eine Austausch-Aufforderung (SWAP-Befehl) sein, um den erzeugten elektronischen Münzdatensatz von der ersten Teilnehmereinheit gegen einen Datensatz aus einem anderen System als dem Bezahlsystem von der zweiten Teilnehmereinheit au szutau sehen. Ein anderes System ist beispielsweise ein anderes System zum Austausch von Datensätzen (wertbasiert oder zugangsbasiert), bevorzugt ist es ein zugangsbasiertes System, in dem beispielsweise Kryptowährungen oder Smart Contracts im Rahmen von Blockchain- Transaktionen ausgetauscht werden. Der Datensatz dieses Systems ist bevorzugt ein Blockchain-basierter Datensatz, also ein zugangsbasierter Datensatz. Diese Datensätze zeichnen sich dadurch aus, dass sie selbst keine monetären Daten (wie Beträge etc.) beinhalten, sondern nur Zugangsdaten bereitstellen, um auf diese monetären Daten - beispielsweise einer Blockchain oder eines Netzwerkdatenspeichers - zugreifen zu können. Es ist nicht ausgeschlossen, dass das andere System auch ein System zum Austausch wertbasierter Datensätze oder ein System zum Austausch zugangsbasierter Datensätze ist. Entscheidend ist, dass der Datensatz in einer vom vorliegenden Bezahlsystem verschiedenen Architektur oder Plattform als System übertragen wird.
Mit Austausch ist eine wechselseitige Übergabe von Werten, wie monetären Beträgen oder Verhandlungsgegenständen (für Smart Contracts), gemeint.
Die erste Teilnehmereinheit kann den erzeugten elektronischen Münzdatensatz direkt an die zweite Teilnehmereinheit übertragen, wenn die erste Teilnehmereinheit eine Registrierungsbestätigung von dem Münzregister erhalten hat. Mit der Registrierungsbestätigung zeigt das Münzregister der ersten Teilnehmereinheit an, dass eine Verifizierung der Registrierungsaufforderung erfolgreich war, insbesondere, dass der elektronische Münzdatensatz zeitgesichert im Münzregister registriert ist.
Vor dem Senden der Registrierungsbestätigung an die erste Teilnehmereinheit kann das Münzregister bevorzugt verifizieren, dass der maskierte erzeugte elektronische Münzdatensatz noch nicht im Münzregister registriert ist und dass das Münzregister den maskierten erzeugten Münzdatensatz abgesichert registriert, wobei die Zeitsicherung automatisch aufgehoben ist, wenn die Zeitdauer abgelaufen ist. Zudem kann das Münzregister noch Wertebereichsnachweise prüfen, um sicherzustellen, dass kein neues Geld generiert wurde. Zudem kann das Münzregister verifizieren, dass das Ende der Zeitdauer in der Zukunft liegt. Zudem kann das Münzregister verifizieren, dass der erhaltene Münzdatensatz, auf dessen Basis der erzeugte Münzdatensatz erzeugt wurde, gültig ist und im Münzregister - idealerweise auf die erste Teilnehmereinheit - registriert ist.
Bevorzugt wird mit der Registrierungsaufforderung gleich eine verzögerte Umschaltaufforderung von der ersten Teilnehmereinheit an das Münzregister übertragen aufgrund derer das Münzregister den maskierten erzeugten Münzdatensatz automatisch auf die erste Teilnehmereinheit umschaltet, wenn das Münzregister feststellt, dass die Zeitdauer abgelaufen ist. Damit sind keine weiteren Schritte durch die erste Teilnehmereinheit erforderlich, um bei misslungenem Austauschverfahren den Urzustand wiederherzu stellen.
Alternativ wird die Registrierungsaufforderung als eine verzögerte Umschaltaufforderung im Münzregister uminterpretiert, wenn das Münzregister feststellt, dass die Zeitdauer abgelaufen ist, woraufhin das Münzregister den maskierten erzeugten Münzdatensatz automatisch auf die erste Teilnehmereinheit (zurück-) umschaltet.
Das Feststellen von Zeitdauer-Enden im Münzregister kann über elektronische Zähler oder Timer realisiert werden.
In beiden soeben genannten Alternativen verringert die verzögerte Umschaltaufforderung den Systemaufwand, denn es kann auf die Erzeugung und Registrierung eines weiteren maskierten Münzdatensatzes verzichtet werden.
Bevorzugt empfängt die erste Teilnehmereinheit vor dem Senden der Registrier-Aufforderung einen Streuwert aus einem Datensatzes des anderen Systems. Bevorzugt ist der Streuwert aus dem Datensatz des anderen Systems. Der maskierte erzeugte elektronische Münzdatensatz wird durch die erste Teilnehmereinheit (nun auch) mit dem Streuwert streuwertgesichert, sodass das Münzregister den maskierten erzeugten Münzdatensatz streuwertgesichert registriert. Auf diese Weise wird mit der Registrierungsaufforderung nicht nur ein Timelock (=eine Zeitsicherung), sondern auch ein Hashlock (=eine Streuwertsicherung) vorgenommen. Die zweite Teilnehmereinheit, die den erzeugten elektronischen Münzdatensatz auf sich „ummünzen“ (= umschalten) möchte, muss diesen willen nun innerhalb der Zeitdauer dem Münzregister 2 anzeigen und die zweite Teilnehmereinheit muss den Urbild-Datensatzes (die Basis) des Streuwerts dem Münzregister offenlegen, bevor ein Umschalten des erzeugten elektronischen Münzdatensatzes von der ersten Teilnehmereinheit auf die zweite Teilnehmereinheit erfolgreich vom Münzregister registriert (durchgeführt) werden kann.
Eine Streuwertsicherung ist eine Sicherung (bzw. Blockade) des Münzdatensatzes, die nur aufgehoben werden kann, wenn der Urbild-Datensatz (=ein „pre-image“, ein (temporäres) Geheimnis) mit dem der Streuwert erzeugt wurde, offengelegt wird. Mit dem Offenlegen des Urbild-Datensatzes kann die Streuwertsicherung entsichert werden. Der Hashlock verhindert im anderen System, dass der Datensatz von der ersten Teilnehmereinheit eingelöst werden kann, es sei denn, es wird der Urbild-Datensatz preisgegeben. Der Hashlock verhindert im Bezahlsystem, dass der erzeugte elektronische Münzdatensatz auf die zweite Teilnehmereinheit umgeschaltet werden kann, wenn diese nicht im Besitz des Urbild-Datensatzes ist oder wenn diese den Urbild-Datensatz nicht offenlegt.
Diese Streuwertsicherung kann nun mit der Zeitsicherung kombiniert werden. Diese doppelte Sicherung kann mit Hash Timelock Contract, kurz HTLC genannt, technisch realisiert werden. Ein HTLC ist ein Computerprotokoll-Teil und basiert auf zwei Schlüsselfunktionen: einem „Hashlock“ und einem „Timelock“. Folglich macht die Verwendung von HTLCs die Notwendigkeit von Vertrauen überflüssig, da sie ein spezifisches Regelwerk definieren, das verhindert, dass „atomic swaps“ nur teilweise ausgeführt werden.
Bevorzugt empfängt die erste Teilnehmereinheit vor dem Senden der Registrierungsaufforderung eine Zeitdauer aus dem Datensatz des anderen Systems, wobei die Zeitdauer aus dem Datensatz eine Zeitdauer vorgibt, bis zu der die erste Teilnehmereinheit den Datensatz aus dem anderem System als dem Bezahlsystem für sich einlösen kann. Damit hat die zweite Teilnehmereinheit den Datensatz des anderen Systems zeitlich gesichert und mit Ablauf dieser Zeitdauer, kann die zweite Teilnehmereinheit diesen Datensatz wieder für sich einlösen.
Bevorzugt wählt die erste Teilnehmereinheit die Zeitdauer für die Registrierungsaufforderung derart, dass sie vor dem Ablauf der Zeitdauer aus dem Datensatz abläuft, wobei bevorzugt die Zeitdauer der Registrierungsaufforderung ungefähr die Hälfte der Zeitdauer zwischen Empfang der Zeitdauer aus dem Datensatz und dem Ablauf der Zeitdauer aus dem Datensatz ist. Dies setzt voraus, dass die Zeitdauer aus dem Datensatz ebenfalls in der Zukunft liegt, also noch nicht zum Zeitpunkt des Empfangs bei der ersten Teilnehmereinheit bereits abgelaufen ist. Dies ist sinnvoll, wenn zunächst die Gültigkeit für den elektronischen Münzdatensatz zu prüfen ist, bevor der Datensatz bei der ersten Teilnehmereinheit empfangen werden kann.
Die zweite Teilnehmereinheit empfängt bevorzugt den erzeugten elektronischen Münzdatensatz direkt von der ersten Teilnehmereinheit, wobei die zweite Teilnehmereinheit prüft, ob der maskierte erzeugte elektronische Münzdatensatz im Münzregister mit dem Streuwert streuwertgesichert ist. Nach dem Empfangen prüft die zweite Teilnehmereinheit bevorzugt, ob die Höhe des monetären Betrags im empfangenen erzeugten elektronischen Münzdatensatz den ausgehandelten Bedingungen entspricht.
Das Verfahren umfasst bevorzugt die weiteren Schritte: Erzeugen, durch die zweite Teilnehmereinheit, eines elektronischen Münzdatensatzes aufweisend den monetären Betrag und einen Verschleierungsbetrag, wobei der monetäre Betrag des erzeugten elektronischen Münzdatensatzes dem monetären Betrag des von der der ersten Teilnehmereinheit empfangenen elektronischen Münzdatensatzes entspricht; Maskieren, durch die zweite Teilnehmereinheit, des erzeugten elektronischen Münzdatensatzes durch Anwenden der homomorphen Einwegfunktion auf den elektronischen Münzdatensatz zum Erhalten des maskierten erzeugten elektronischen Münzdatensatzes; Senden einer Umschalten- Aufforderung (hier auch ,,Redeem“-Befehl) für den maskierten erzeugten elektronischen Münzdatensatz von der zweiten Teilnehmereinheit an das Münzregister zusammen mit einem Urbild-Datensatz, wobei der Urbild-Datensatz auch die Basis für den Streuwert in dem Datensatz aus dem anderem als dem Bezahlsystem ist, wobei das Senden innerhalb der Zeitdauer der Zeitsicherung erfolgt.
Der Urbild-Datensatz ist ein Geheimnis der zweiten Teilnehmereinheit, auf das eine Streu wertfunktion angewendet wird, um den o.g. Streuwert zum Sichern des Datensatzes des anderen Systems zu erhalten. Das Geheimnis muss im Lauf des atomaren Austauschverfahrens an die erste Teilnehmereinheit übermittelt werden. Wenn die zweite Teilnehmereinheit den erhaltenen elektronischen Münzdatensatz von der ersten Teilnehmereinheit für korrekt befindet und diesen nun auf sich umschalten möchte (was durch das Erzeugen eines neuen Münzdatensatzes, dem Maskieren und der Registeraufforderung erfolgen kann) muss es im Gegenzug den Urbild-Datensatz veröffentlichen, damit die erste Teilnehmereinheit den Datensatz auf sich einlösen kann.
Bevorzugt registriert das Münzregister den maskierten erzeugten elektronischen Münzdatensatz der zweiten Teilnehmereinheit auf die zweite Teilnehmereinheit, wenn ein Streu wert über den Urbild-Datensatz mit dem mit dem Streuwert streuwertgesicherten maskierten elektronischen Münzdatensatz des Münzregisters übereinstimmt und wenn die Zeitdauer der Zeitsicherung des maskierten erzeugten elektronischen Münzdatensatzes noch nicht abgelaufen ist. In diesem Zusammenhang wird der maskierte erzeugte elektronische Münzdatensatz der ersten Teilnehmereinheit ungültig. Die Übertragung des elektronischen Münzdatensatzes von der ersten Teilnehmereinheit an die zweite Teilnehmereinheit ist damit erfolgreich beendet.
Damit nun auch die erste Teilnehmereinheit den Datensatz auf sich einlösen kann, fragt sie den Urbild-Datensatz (der veröffentlicht im Münzregister abrufbar abgelegt ist) von dem Münzregister ab. Mit dem Urbild-Datensatz kann die erste Teilnehmereinheit den Datensatz von dem anderen System auf sich einlösen.
Das Senden der Registrierungsaufforderung kann eine Mehrzahl von maskierten erzeugten elektronischen Münzdatensatz von der ersten Teilnehmereinheit umfassen, wobei für jede der maskierten erzeugten elektronischen Münzdatensatz die gleiche Zeitsicherung, bevorzugt auch der gleiche Streuwert aus einem Datensatz aus einem anderen System als dem Bezahlsystem, verwendet wird.
Bevorzugt registriert das Münzregister jeden maskierten elektronischen Münzdatensatz als einen Registerdatensatz.
Vor dem Erzeugen-Schritt werden bevorzugt die folgenden Schritte durchgeführt: Empfangen des elektronischen Münzdatensatzes von einer Herausgeberinstanz und/oder einer anderen Teilnehmereinheit; und Abfragen eines Registerdatensatzes zu dem empfangenen elektronischen Münzdatensatz bei dem Münzregister. Damit stellt die erste Teilnehmereinheit sicher, dass der zu übertragende Münzdatensatz vorhanden und gültig ist.
Erst bei Vorhandensein eines Registerdatensatzes zu diesem elektronischen Münzdatensatz wird das Verfahren gemäß der vorhergehenden Art durchgeführt. Somit wird es eine Systemvoraussetzung, dass für einen atomaren Austausch der Registerdatensatz vorhanden sein muss.
Die Zeitdauer in der Registrierungsanfrage beträgt bevorzugt nur einige Tage, bevorzugt 3 Tage, wobei die Zeitdauer in dem Datensatz, bevorzugt 7 Tage, beträgt. Dies sind für ausreichend angenommene Zeitspannen, um die atomare Austauschprozedur durchführen zu können.
Der Streuwert kann mittels einer Streuwertfunktion in der zweiten Teilnehmereinheit errechnet werden, wobei als Basis ein geheimer Urbild-Datensatz in der zweiten Teilnehmereinheit generiert wurde.
Als Streuwertfunktion können vorliegend verschiedene Funktionen verwendet werden. Vorzugsweise wird eine Streuwertfunktion gewählt, die in beiden Systemen (zugangsbasiert/nicht- zugangsbasiert) bereits verfügbar ist. Neben den beispielhaft verwendeten Streu Wertfunktionen vom Typ SHA2, insbesondere SHA256, können grundsätzlich auch andere verbreitete Streuwertfunktionen, wie nur beispielsweise SHA3, RIPEMD-160, MD5 oder Haval verwendet werden.
In einem weiteren Aspekt wird die Aufgabe durch ein Münzregister zum Registrieren von Registerdatensätzen, insbesondere von maskierten elektronischen Münzdatensätzen, in einem elektronischen Bezahlsystem gelöst. Das Münzregister umfasst eine Datenschnittstelle, eingerichtet zum Empfangen von Registrieranforderungen und zum Senden von Registerstatus bezüglich Registerdatensätzen des Bezahlsystems gemäß der vorhergehend beschriebenen Art.
Bevorzugt ist das Münzregister eingerichtet zum Empfangen eines Urbild-Datensatzes von einer Teilnehmereinheit; Anwenden einer Streuwertfunktion auf den Urbild-Datensatz zum Erzeugen eines Streuwerts; Vergleichen des erzeugten Streuwerts mit einem zuvor empfangenen Streuwerts; und Registrieren eines mittels dem Streuwert gesicherten Registerdatensatz in dem Münzregister.
Das Münzregister weist bevorzugt weiter eine Prüfeinheit zum Prüfen der Gültigkeit von den Registerdatensätzen entsprechenden elektronischen Münzdatensätzen auf.
In einem weiteren Aspekt ist ein Bezahlsystem zum Bezahlen mit elektronischen Münzdatensätzen vorgesehen. Das Bezahlsystem umfasst ein Münzregister, eingerichtet zum Registrieren der erzeugten elektronischen Münzdatensätze gemäß der vorhergehend beschriebenen Art und Teilnehmereinheiten, die eingerichtet sind zum Ausführen von Bezahltransaktionen durch Übertragen der elektronischen Münzdatensätze und zum Senden von Status- und/oder Registrierungsanforderungen betreffend die elektronischen Münzdatensätze gemäß der vorhergehend beschriebenen und Ausführen von Transaktionen durch Übertragen von Datensätzen in einem anderen System als dem Bezahlsystem gemäß einem der vorhergehenden Verfahrensansprüche.
Das Münzregister des Bezahlsystems ist bevorzugt eingerichtet zum Registrieren des elektronischen Münzdatensatzes als ein Teil eines atomaren Austauschverfahrens, wobei eine Registrierungsaufforderung eine Austausch-Aufforderung ist, um den erzeugten elektronischen Münzdatensatz von der ersten Teilnehmereinheit gegen einen Datensatz aus einem anderen System als dem Bezahlsystem von der zweiten Teilnehmereinheit auszutauschen. In einem weiteren Aspekt ist eine Teilnehmereinheit vorgesehen.
Diese Teilnehmereinheit ist eingerichtet zum direkten Übertragen von elektronischen Münzdatensätzen an eine andere Teilnehmereinheit in einem elektronischen Bezahlsystem und eingerichtet zum Ausführen von Bezahltransaktionen durch Übertragen von elektronischen Münzdatensätzen und zum Senden von Status- und/oder Registrierungsanforderungen betreffend die elektronischen Münzdatensätzen an ein Münzregister. Die Teilnehmereinheit weist auf ein Mittel zum Zugreifen auf einen Datenspeicher, wobei im Datenspeicher zumindest ein elektronischer Münzdatensatz abgelegt ist; eine Schnittstelle zum Ausgeben des zumindest einen elektronischen Münzdatensatzes an die andere Teilnehmereinheit zum Übertragen von Status- und/oder Registeranforderungen betreffend die elektronischen Münzdatensätzen an das Münzregister und eine Recheneinheit, eingerichtet zum Ausführen der Verfahrensschritte des vorhergehend beschriebenen Verfahrens.
In einem Aspekt ist ein Computerprogramprodukt ausführbar installiert in einer Teilnehmereinheit und weist Mittel zum Ausführen der Verfahrens schritte des Verfahrens auf.
In dem vorangegangen beschriebenen Verfahren wurde von der ersten Teilnehmereinheit nur ein elektronischer Münzdatensatz erzeugt, dieser mit Zeitdauer und Hashwert im Rahmen eines HTLC im Münzregister gesichert. Wird - aus welchen Gründen auch immer - nicht umgeschalteten (=umgemünzt), so erfolgt ein automatisches Umschalten auf die erste Teilnehmereinheit. In einem alternativen Ansatz können zwei elektronische Münzdatensätze erzeugt werden, einer der entsichert wird, wenn die Zeitspanne der Registeraufforderung abgelaufen ist und ein weiterer elektronischer Münzdatensatz, der entsichert wird, wenn der Urbild-Datensatz von der zweiten Teilnehmereinheit veröffentlicht wird. Damit werden die Prozeduren im Münzregister weniger komplex und können mit einfachen Rechenoperationen durchgeführt werden. Dazu wird in der Figurenbeschreibung der Fig. 10 und Fig. 11 näher ausgeführt werden.
Ein elektronischer Münzdatensatz ist insbesondere ein elektronischer Datensatz, der einen geldwerten (=monetären) Betrag repräsentiert und umgangssprachlich auch als „digitale Münze” oder „elektronische Münze”, englisch „digital/electronic coin“ bezeichnet wird. Der elektronische Münzdatensatz wird in der Regel von einer Zentralbank herausgegeben. Der elektronische Münzdatensatz kann als elektronischer Münzdatensatz einer digitalen Zentralbankwährung (CBDC) bezeichnet werden. Dieser geldwerte Betrag kann bei dem Verfahren von einem ersten Endgerät zu einem anderen Endgerät wechseln. Als ein geldwerter Betrag (Vermögenwert) wird im Folgenden ein digitaler Betrag verstanden, der z.B. auf einem Konto eines Geldinstituts gutgeschrieben werden kann, oder gegen ein anderes Zahlungsmittel getauscht werden kann. Ein elektronischer Münzdatensatz repräsentiert also Bargeld in elektronischer Form.
Ein elektronischer Münzdatensatz zum Übertragen von geldwerten Beträgen unterscheidet sich wesentlich von dem elektronischen Datensatz zum Datenaustausch oder Datentransfer, beispielsweise einem Registerdatensatz, da eine klassische Datentransaktion auf Basis eines Frage- Antwort-Prinzips bzw. auf einer Interkommunikation zwischen den Datentransferpartnern, beispielsweise der Teilnehmereinheit und einem Münzregister (hier teils auch als Überwachungsinstanz, Überwachungsregister, Transaktionsregister, Verifier bezeichnet) stattfindet. Dabei können im Rahmen von Authentifizierungen, Identifizierungs- bzw. Kennungsdaten ausgetauscht werden, die Rückschlüsse auf eine Teilnehmerkennung und/oder eine Identifizierungsnummer einer natürlichen Person als Nutzer (Teilnehmer) des Bezahlsystems liefern können. Damit ist ein anonymes Bezahlen nicht möglich. Ein elektronischer Münzdatensatz ist dementgegen anonym, einmalig, eindeutig und steht im Kontext eines Sicherheitskonzepts. In einem elektronischen Münzdatensatz sind prinzipiell alle Datenelemente enthalten, die für eine empfangende Instanz benötigt werden, um den zu übertragenden geldwerten Betrag zu erhalten. Im Unterschied zum Kopieren von elektronischen Datensätzen, also der Vervielfältigung digitaler Daten, sollte ein gültiger elektronischer Münzdatensatz nur ein einziges Mal im Bezahlsystem existieren. Diese Systemvoraussetzung ist insbesondere beim Übertragen von elektronischen Münzdatensätzen zu beachten.
Ein elektronischer Münzdatensatz kann dabei in einer Vielzahl von unterschiedlichen Erscheinungsformen vorliegen und damit über verschiedene Kommunikationskanäle, Kommunikationsprotokolle, Kommunikations schichten nachfolgend als Schnittstellen zusammengefasst, ausgetauscht werden. Ein sehr flexibler Austausch von elektronischen Münzdatensätzen ist damit geschaffen.
Der elektronische Münzdatensatz ist beispielsweise in Form einer Datei darstellbar. Eine Datei besteht dabei aus inhaltlich zusammengehörigen Daten, die auf einem Datenträger, Datenspeicher oder Speichermedium gespeichert sind. Jede Datei ist zunächst eine eindimensionale Aneinanderreihung von Bits, die normalerweise in Byte-Blöcken zusammengefasst interpretiert werden. Ein Anwendungsprogramm (Applikation) oder ein Betriebssystem eines Sicherheitselements und/oder einer Teilnehmereinheit interpretiert diese Bit- oder Bytefolge beispielsweise als einen Text, ein Bild oder eine Tonaufzeichnung. Das dabei verwendete Dateiformat kann unterschiedlich sein, beispielsweise kann es eine reine Textdatei sein, die den elektronischen Münzdatensatz repräsentiert. Dabei werden insbesondere der monetäre Betrag und eine blinde Signatur als Datei abgebildet.
Der elektronische Münzdatensatz ist beispielsweise eine Folge von American Standard Code for Information Interchange, kurz ASCII, Zeichen. Dabei werden insbesondere der monetäre Betrag und eine blinde Signatur als diese Folge abgebildet.
Der elektronische Münzdatensatz kann in einer Teilnehmereinheit auch von einer Darstellungsform in eine andere Darstellungsform umgewandelt werden. So kann beispielsweise der elektronische Münzdatensatz als QR-Code in einer Teilnehmereinheit erfasst werden und als Datei oder Zeichenfolge von der Teilnehmereinheit ausgegeben werden.
Diese unterschiedlichen Darstellungsformen von ein und demselben elektronischen Münzdatensatz ermöglichen einen sehr flexiblen Austausch zwischen Teilnehmereinheiten bzw. Sicherheitselementen unterschiedlicher technischer Ausrüstung unter Verwendung unterschiedlicher Übertragungsmedien (Luft, Papier, drahtgebunden) und unter Berücksichtigung technischer Ausgestaltung von Teilnehmereinheit(en). Die Wahl der Darstellungsform der elektronischen Münzdatensätze erfolgt bevorzugt automatisch, beispielsweise aufgrund erkannter oder ausgehandelter Übertragungsmedien und Gerätekomponenten. Zusätzlich kann auch ein Benutzer einer Teilnehmereinheit die Darstellungsform zum Austausch (=Übertragen) eines elektronischen Münzdatensatzes wählen.
In einer vorteilhaften Ausgestaltung weist der elektronische Münzdatensatz als Datenelement einen monetären Betrag, also ein Datum, das einen Geldwert des elektronischen Münzdatensatzes darstellt, und als Datenelement einen Verschleierungsbetrag, beispielsweise eine Zufallszahl, auf. Der Verschleierungsbetrag ist dem Münzregister nicht bekannt. Der Verschleierungsbetrag ist - außer in der ersten Schicht (Direkttransaktionsschicht) - ein geheimes Datenelement. Ein elektronischer Münzdatensatz wird durch diese wenigstens zwei Datenelemente (monetärer Betrag, Verschleierungsbetrag) eindeutig repräsentiert. Jeder, der Zugriff auf diese Datenelemente eines elektronischen Münzdatensatzes hat, kann diesen elektronischen Münzdatensatz zum Bezahlen in einer Bezahltransaktion verwenden. Die Kenntnis dieser zwei Datenelemente (monetärer Betrag, Verschleierungsbetrag) ist also gleichbedeutend mit dem Besitz des digitalen Geldes. Dieser elektronische Münzdatensatz kann zwischen zwei Teilnehmereinheiten direkt übertragen werden. Zum Austausch von digitalem Geld (=Bezahltransaktion) ist nur die Übertragung des monetären Betrags und des Verschleierungsbetrags notwendig.
Darüber hinaus kann der elektronische Münzdatensatz weitere Datenelemente aufweisen, insbesondere welche Währung der monetäre Betrag repräsentiert oder von welcher Herausgeberinstanz er erzeugt wurde. Eine Signatur einer Herausgeberinstanz kann der elektronische Münzdatensatz alternativ oder zusätzlich umfassen, insbesondere um die Sicherheit zu erhöhen (bei jedoch verringerter Flexibilität).
Eine Teilnehmereinheit des Bezahlsystems kann beispielsweise ein mobiles Endgerät, wie z.B. ein Smartphone, ein Tablet-Computer, ein Computer, ein Server oder eine Maschine sein.
Alternativ oder zusätzlich kann die Teilnehmereinheit auch ein Gerät, wie Wearable, Smartcard, Maschine, Werkzeug, Automat oder auch Behälter bzw. Fahrzeug sein. Eine Teilnehmereinheit ist somit entweder stationär oder mobil. Die Teilnehmereinheit ist vorzugsweise ausgebildet, das Internet und/ oder andere öffentliche oder private Netze zu nutzen, um elektronische Münzdatensätze und/oder Registerdatensätze bzw. Anfragen diesbezüglich zu übertragen. Dazu verwendet die Teilnehmereinheit eine geeignete Verbindungstechnologie, beispielsweise Bluetooth, LoRa, NFC und/ oder WiFi und weist wenigstens eine entsprechende Schnittstelle auf. Die Teilnehmereinheit kann auch ausgebildet sein, mittels Zugangs zu einem Mobilfunknetz mit dem Internet und/ oder anderen Netzen verbunden zu werden.
Eine auf der Teilnehmereinheit betriebsbereit eingebrachte Applikation (installiert) kann eine Übertragung eines Münzdatensatzes zu einer anderen Teilnehmereinheit durch Nutzung von Eingabe- und/oder Ausgabemittel der jeweiligen Teilnehmereinheit initiieren und steuern. Beispielsweise kann mittels der Applikation Beträge von elektronischen Münzdatensätzen angezeigt werden und das Übertragungsverfahren überwacht werden. Diese oder eine weitere betriebsbereit eingebrachte Applikation kann eine Übertragung eines Registerdatensatzes zu einem Münzregister des Bezahlsystems durch Nutzung von Eingabe- und/oder Ausgabemittel der jeweiligen Teilnehmereinheit initiieren und steuern. Beispielsweise kann mittels der Applikation die Überprüfung von elektronischen Münzdatensätzen initiiert werden, beispielsweise durch Erzeugen von Registerdatensätzen und/oder dem Versenden von Prüf- Anfragen an das Münzregister.
In einer bevorzugten Ausgestaltung weist die Teilnehmereinheit eine Schnittstelle zum Ausgeben von elektronischen Münzdatensätzen auf.
Eine Schnittstelle zum Ausgeben (=Senden) des zumindest einen elektronischen Münzdatensatzes ist beispielsweise eine Protokollschnittstelle zum drahtlosen Senden des elektronischen Münzdatensatzes an das andere Sicherheitselement über eine Teilnehmereinheit mittels eines Kommunikationsprotokolls für Drahtloskommunikation. Dabei ist insbesondere eine Nahfeldkommunikation, beispielsweise mittels Bluetooth-Protokoll oder NFC-Protokoll oder IR- Protokoll vorgesehen, alternativ oder zusätzlich sind WLAN- Verbindungen oder Mobilfunkverbindungen denkbar. Der elektronische Münzdatensatz wird dann gemäß den Protokolleigenschaften angepasst oder in das Protokoll integriert und übertragen.
Eine Schnittstelle zum Ausgeben des zumindest einen elektronischen Münzdatensatzes ist beispielsweise eine Datenschnittstelle zum Bereitstellen des elektronischen Münzdatensatzes an die andere Teilnehmereinheit mittels einer Applikation. Im Unterschied zur Protokollschnittstelle wird hier der elektronische Münzdatensatz mittels einer Applikation übertragen. Diese Applikation überträgt sodann den elektronischen Münzdatensatz in einem entsprechenden Dateiformat. Es kann ein für elektronische Münzdatensätze sodann ein spezifisches Dateiformat verwendet werden, beispielsweise eine ASCII-Zeichenfolge oder eine Textnachricht, beispielsweise SMS, MMS, Instant-Messenger-Nachricht, eine APDU-Zeichenfolge. Alternativ oder zusätzlich erfolgt das Übertragen über die zuvor erwähnte Applikation der Teilnehmereinheit und/oder des Sicherheitselements.
In einer bevorzugten Ausgestaltung weist die Teilnehmereinheit weiter eine Schnittstelle zum Empfangen von elektronischen Münzdatensätzen auf.
In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Empfangen des zumindest einen elektronischen Münzdatensatzes ein elektronisches Erfassungsmodul des Sicherheitselements bzw. des Endgeräts, eingerichtet zum Erfassen eines, in visueller Form dargestellten elektronischen Münzdatensatzes. Das Erfassungsmodul ist dann beispielsweise eine Kamera oder ein Barcode bzw. QR-Code Scanner.
In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Empfangen des zumindest einen elektronischen Münzdatensatzes eine Protokollschnittstelle zum drahtlosen Empfangen des elektronischen Münzdatensatzes von einem anderen Sicherheitselement bzw. Endgerät mittels eines Kommunikationsprotokolls für Drahtloskommunikation· Dabei ist insbesondere eine Nahfeldkommunikation, beispielsweise mittels Bluetooth-Protokoll oder NFC-Protokoll oder IR- Protokoll, vorgesehen. Alternativ oder zusätzlich sind WLAN- Verbindungen oder Mobilfunkverbindungen denkbar.
In einer bevorzugten Ausgestaltung umfassend die Teilnehmereinheit zumindest ein Sicherheitselement-Lesegerät, eingerichtet zum Lesen eines Sicherheitselements; einen Zufallszahlengenerator; und/oder eine Kommunikationsschnittstelle zu einem Tresormodul und/ oder Bankinstitut mit zu autorisierendem Zugriff auf ein Bankkonto.
Eine Teilnehmereinheit des Bezahlsystems kann vorliegend ein Sicherheitselement aufweisen oder selbst ein Sicherheitselement sein, indem zumindest ein elektronischer Münzdatensatz sicher abgelegt ist. Die Übertragung von elektronischen Münzdatensätzen kann jeweils unter Zuhilfenahme von Endgeräten als Teilnehmereinheit erfolgen, die ggf. mit den Sicherheitselementen logisch und/oder physisch verbunden sind. Die auf der Teilnehmereinheit betriebsbereit eingebrachte Applikation(en) kann/können zumindest Teile des Übertragen- Verfahrens und/der Teile des Registrieren- Verfahrens und/oder Teile des Überprüfen- Verfahrens steuern oder zumindest initiieren.
In einer bevorzugten Ausgestaltung ist ein Sicherheitselement betriebsbereit in einer Teilnehmereinheit eingebracht. Damit ist sichergestellt, dass elektronische Münzdatensätze übertragen und/oder Registerdatensätze ohne Manipulationen erzeugt und verschlüsselt und ggf. auch gesendet werden. In einer Ausgestaltung wird der Registerdatensatz im Sicherheitselement erstellt und dann durch die Teilnehmereinheit an das Münzregister versendet.
Ein Sicherheitselement ist eine technische ressourcenbeschränkte Einrichtung. Ein Sicherheitselement ist beispielsweise ein spezielles Computerprogrammprodukt, insbesondere in Form einer abgesicherten Laufzeitumgebung innerhalb eines Betriebssystems eines Endgeräts, englisch Trusted Execution Environments, TEE, oder einer eSIM-Software, gespeichert auf einem Datenspeicher, beispielsweise einer Teilnehmereinheit, wie (mobiles) Endgerät, einer Maschine oder eines Bankautomat. Alternativ oder zusätzlich ist das Sicherheitselement beispielsweise als spezielle Hardware, insbesondere in Form eines gesicherten Hardware - Plattform-Moduls, englisch Trusted Platform Module, TPM oder als eine Chipkarte, UICC oder ein eingebettetes Sicherheitsmodul, eUICC, iUICC, eSIM, ausgebildet. Das Sicherheitselement stellt eine vertrauenswürdige Umgebung bereit und hat damit ein höheres Level-of-Trust als ein Endgerät, in dem das Sicherheitselement ggf. betriebsbereit integriert ist.
Ein elektronischer Münzdatensatz kann im Unterschied zu einem Registerdatensatz bevorzugt nicht von einer Teilnehmereinheit bzw. einem Sicherheitselement oder dem Münzregister erzeugt werden. Das Erzeugen eines elektronischen Münzdatensatzes (und auch dessen Vernichtung bzw. Löschen) erfolgt durch die Herausgeberinstanz des Bezahlsystems, bevorzugt ausschließlich durch die Herausgeberinstanz des Bezahlsystems.
In einer Teilnehmereinheit bzw. einem Sicherheitselement können ein oder mehre elektronische Münzdatensätze sicher abgelegt sein, beispielsweise kann eine Vielzahl von elektronischen Münzdatensätzen in einem exklusiv einer Teilnehmereinheit oder einem Sicherheitselement zugeordneten Datenspeicher gesichert abgelegt sein. Der Datenspeicher stellt dann beispielsweise eine elektronische Geldbörsen-Applikation dar. Dieser Datenspeicher kann beispielsweise intern, extern oder virtuell zum Sicherheitselement sein.
In einem einfachen Fall ist der Datenspeicher ein interner Datenspeicher der Teilnehmereinheit oder des Sicherheitselements. Hier werden die elektronischen Münzdatensätze abgelegt. Ein einfacher Zugriff auf elektronische Münzdatensätze ist somit gewährleistet.
Der Datenspeicher ist beispielsweise ein von der Teilnehmereinheit oder dem Sicherheitselement räumlich entfernter, also externer, Datenspeicher, auch Online-Speicher genannt. Somit weist das Sicherheitselement bzw. die Teilnehmereinheit nur ein Zugriffsmittel auf die extern und damit sicher abgelegten elektronischen Münzdatensätze auf. Insbesondere bei einem Verlust des Sicherheitselements bzw. der Teilnehmereinheit oder bei Fehlfunktionen des Sicherheitselements bzw. der Teilnehmereinheit sind die elektronischen Münzdatensätze nicht verloren. Da der Besitz der (nicht maskierten) elektronischen Münzdatensätze gleich dem Besitz des monetären Betrags entspricht, kann durch Verwendung externer Datenspeicher Geld sicherer aufbewahrt und verwaltet werden.
Beispielsweise ist der Datenspeicher ein gemeinsamer Datenspeicher auf den zumindest noch eine andere Teilnehmereinheit zugreifen kann, wobei jedes davon eine Applikation aufweist, wobei diese Applikation zum Kommunizieren mit dem Münzregister zum entsprechenden Registrieren von elektronischen Münzteildatensätzen eingerichtet ist.
Das Sicherheitselement könnte zudem elektronische Münzdatensätze auch von weniger vertrauenswürdigen Einheiten, wie Teilnehmereinheiten, also einem Endgerät oder einer Maschine, erhalten haben, beispielsweise über eine Import-/ExportFunktion des Sicherheitselements. Derartig erhaltene elektronische Münzdatensätze, die nicht direkt von einem anderen Sicherheitselement erhalten wurden, gelten als weniger vertrauenswürdig. Es könnte eine Voraussetzung des Bezahlsystems sein, derartige elektronische Münzdatensätze auf Gültigkeit mittels des Münzregisters prüfen zu müssen oder durch eine Aktion (Modifikation) durch das empfangende Sicherheitselement, den elektronischen Münzdatensatz auf das empfangende Sicherheitselement umzutragen, bevor dieser weitergegeben werden darf.
Die Kommunikation zwischen zwei Teilnehmereinheiten und/oder dem Münzregister, ggf. mittels der jeweiligen Sicherheitselemente, kann drahtlos oder drahtgebunden, oder z.B. auch auf optischem Weg, bevorzugt über QR-Code oder Barcode, erfolgen und kann als ein gesicherter Kanal, beispielsweise zwischen Applikationen der Teilnehmereinheiten ausgebildet sein. Der optische Weg kann beispielsweise die Schritte des Generierens einer optischen Codierung, insbesondere einer 2D-Codierung, vorzugsweise ein QR-Code, und des Einlesens der optischen Codierung umfassen. So können die elektronischen Münzdatensätze in beliebiger Formatierung übertragen werden. Dies impliziert, dass sie auf beliebigen Kanälen kommuniziert, also übertragen werden können. Sie müssen nicht in einem festgelegten Format oder in einem bestimmten Programm gespeichert werden.
Beispielsweise stellen zwei Teilnehmereinheiten eine lokale drahtlos Kommunikationsverbindung über deren Protokoll dann die Übertragung zwischen den beiden darin befindlichen Sicherheitselementen eingebracht ist.
Das Übertragen des elektronischen Münzdatensatzes ist beispielsweise durch kryptografische Schlüssel gesichert, beispielsweise einem für einen elektronischen Münzdatensatz-Austausch ausgehandelten Sitzungsschlüssel oder einem symmetrischen oder asymmetrischen Schlüsselpaar. Durch das Kommunizieren zwischen Teilnehmereinheiten, beispielsweise über ihre Sicherheitselemente, werden die ausgetauschten elektronischen Münzdatensätze vor Diebstahl oder Manipulation geschützt. Die Ebene der Sicherheitselemente ergänzt so die Sicherheit etablierter Blockchain-Technologie .
In einer bevorzugten Ausgestaltung erfolgt das Übertragen der Münzdatensätze als APDU Kommandos. Dazu ist der Münzdatensatz bevorzugt in einer (embedded oder integrated) UICC als Sicherheitselement abgelegt und wird dort verwaltet. Ein APDU ist ein kombinierter Kommando-/Datenblock eines Verbindungsprotokolls zwischen der UICC und einem Endgerät. Die Struktur der APDU ist durch den Standard ISO-7816-4 definiert. APDUs stellen ein Informationselement der Anwendungsebene (Schicht 7 des OSI-Schichtenmodels) dar.
Das Übertragen eines elektronischen Münzdatensatzes erfolgt bevorzugt zwischen zwei Sicherheitselementen, um eine vertrauenswürdige Umgebung zu schaffen. Dabei erfolgt die logische Übertragung des elektronischen Münzdatensatzes direkt, wohingegen eine physikalische Übertragung eines oder mehrere dazwischenliegende Instanzen aufweisen kann, beispielsweise eines oder mehrere Teilnehmereinheiten zur Herstellung der Betriebsbereitschaft des/der Sicherheitselemente und/oder ein entfernter Datenspeicherdienst, bei dem eine Geldbörsen- Applikation mit elektronischen Münzdatensätzen physikalisch gespeichert sind.
Sicherheitselemente können elektronische Münzdatensätze untereinander übertragen und dann direkt - ohne Registerprüfung(en) - weiterverwenden, insbesondere wenn das Bezahlsystem voraussetzt, dass elektronische Münzdatensätze von Sicherheitselementen per se als gültig anzu sehen sind.
Ein Übertragen des elektronischen Münzdatensatzes zwischen dem ersten und dem zweiten Sicherheitselement kann in ein Übertragungsprotokoll zwischen zwei Teilnehmereinheiten integriert sein und/oder in einem sicheren Kanal zwischen zwei Anwendungen der jeweiligen Teilnehmereinheit integriert sein. Zudem kann die Übertragung eine Internet-Datenverbindung zu einem externen Datenspeicher, beispielsweise einem Online-Speicher, beinhalten.
Um ein Übertragungsprotokoll zwischen Teilnehmereinheiten und/oder dem Münzregister sicher auszugestalten, werden die elektronischen Münzdatensätze durch jeweiliger Teilnehmereinheiten, beispielsweise durch dort integrierte Sicherheitselemente, verwaltet und auch durch diese übertragen. In einer bevorzugten Ausgestaltung ist das Sicherheitselement dazu betriebsbereit in die Teilnehmereinheit eingebracht. Dabei kann die Teilnehmereinheit eine Applikation beinhalten, durch die ein Benutzer (= Teilnehmer) einen Bezahlvorgang steuert und in diesem Bezahlvorgang auf elektronische Münzdatensätze des Sicherheitselements zurückgreift. Ein Übertragen des elektronischen Münzdatensatzes vom Sicherheitselement einer ersten Teilnehmereinheit erfolgt beispielsweise zum (zweiten) Sicherheitselement einer anderen Teilnehmereinheit. Dabei kann eine Teilnehmereinheit-zu-Teilnehmereinheit Übertragungs strecke aufgebaut werden, über die beispielsweise ein sicherer Kanal zwischen den beiden Sicherheitselementen aufgebaut wird, über den dann das Übertragen des elektronischen Münzdatensatzes erfolgt.
Der (zu übertragende oder zu modifizierende) elektronische Münzdatensatz ist in einem Münzregister des Bezahlsystems registriert. Damit ist beispielsweise zum Registrieren des elektronischen Münzdatensatzes der Aufbau einer Kommunikationsverbindung zu dem Münzregister vorgesehen. Diese Kommunikationsverbindung muss nunmehr nicht zwangsläufig während des Übertragungsvorgangs (Bezahlvorgang) vorhanden sein. Vorzugsweise ist das Münzregister zur Verwaltung und Prüfung von maskierten elektronischen Münzdatensätzen vorgesehen. Das Münzregister kann zusätzlich weitere (Nicht-Bezahl-) Transaktionen zwischen Teilnehmereinheiten verwalten und prüfen.
Das Münzregister - als Teil der zweiten Schicht - ist beispielsweise eine Datenbank, in der ein Registerdatensatz erzeugt und/oder abgelegt ist. Ein Registerdatensatz ist ein Datensatz, der es ermöglicht, die Gültigkeit, den Status, die Historie und/oder den Verbleib eines elektronischen Münzdatensatzes zu erfahren und/oder zu verifizieren. Ein Registerdatensatz ist bevorzugt einem elektronischen Münzdatensatz eindeutig zugeordnet. Der Registerdatensatz dient nur der Überprüfung und kann nicht verwendet werden, um anstelle des elektronischen Münzdatensatzes für Bezahltransaktionen verwendet zu werden.
Das Münzregister kann beispielsweise eine dezentrale öffentliche Datenbank sein. Diese Datenbank ermöglicht es auf einfache Weise, elektronische Münzdatensätze bezüglich ihrer Gültigkeit zu prüfen und „Double-Spending“, also Mehrfachausgaben, zu verhindern, ohne dass das Übertragen selbst registriert oder protokolliert wird. Die Datenbank, beispielsweise eine Distributed-Ledger-Technologie, DLT, beschreibt dabei eine Technik für vernetzte Computer, die zu einer Übereinkunft über die Reihenfolge von bestimmten Transaktionen kommen und darüber, dass diese Transaktionen Daten aktualisieren. Es entspricht einem dezentral geführten Verwaltungssystem oder einer dezentral geführten Datenbank.
Alternativ ist das Münzregister eine zentral geführte Datenbank, beispielsweise in Form eines öffentlich zugänglichen Datenspeichers oder als Mischform aus zentraler und dezentraler Datenbank. Beispielsweise sind das Münzregister und ein davon getrenntes Überwachungsregister als ein Dienste-Server des Bezahlsystems ausgebildet. Ist das Münzregister eine entfernte Instanz, so verfügt die Teilnehmereinheit und auch die Herausgeberinstanz bevorzugt über eine Schnittstelle zur Kommunikation mittels einem üblichen Intemet-Kommunikationsprotokoll, beispielsweise TCP, IP, UDP oder HTTP. Die Übertragung kann eine Kommunikation über das Mobilfunknetz beinhalten.
In einer bevorzugten Ausgestaltung stellt das Münzregister einen Registerdatensatz bereit. Der Registerdatensatz weist beispielsweise als Datenelement einen maskierten elektronischen Münzdatensatz korrespondierend zu einem elektronischen Münzdatensatz auf. Der maskierte elektronische Münzdatensatz wurde beispielsweise von einer Teilnehmereinheit oder einer Herausgeberinstanz bereitgestellt. Der Besitz eines maskierten elektronischen Münzdatensatzes erlaubt keine Offenlegung von Datenelementen des (korrespondierenden) elektronischen Münzdatensatzes, wodurch ein derartiger Registerdatensatz mit (nur) maskierten Münzdatensätzen anonym in Bezug auf eine Teilnehmerkennung und/oder auch anonym bezüglich eines geldwerten Betrags des elektronischen Münzdatensatzes ist. Das Maskieren wird später erläutert.
Ein Registerdatensatz weist dabei eines oder mehrere der folgenden Datenelemente auf: eine Signatur des elektronischen Münzdatensatzes; einen Bereichsnachweis eines elektronischen Münzdatensatzes; einen Prüfwert des elektronischen Münzdatensatzes; einen Prüfwert betreffend den elektronischen Münzdatensatz; einen Zählerwert betreffend den elektronischen Münzdatensatz; eine Teilnehmerkennung einer, den Registerdatensatz sendenden Teilnehmereinheit; einen maskierten elektronischen Münzdatensatz; und/oder einen geldwerten Betrag des elektronischen Münzdatensatz. Alle diese Datenelemente und deren Funktion werden an den geeigneten Stellen definiert.
In einer weiteren Ausgestaltung weist der Registerdatensatz beispielsweise als Datenelemente einen maskierten elektronischen Münzdatensatz und eine Betragskategorie betreffend einen geldwerten Betrag des elektronischen Münzdatensatzes korrespondierend zu dem maskierten elektronischen Münzdatensatz auf. Ein derartiger Registerdatensatz mit maskiertem Münzdatensatz ist identitätsanonym und betragspseudonym.
In einer weiteren Ausgestaltung weist der Registerdatensatz beispielsweise als Datenelemente eine Münzkennung eines elektronischen Münzdatensatzes, einen Prüfwert des elektronischen Münzdatensatzes und ein Pseudonym der Teilnehmerkennung auf. Ein derartiger Registerdatensatz ist identitätspseudonym und betragsanonym.
Beispielsweise sind maskierte elektronische Münzdatensätze als Datenelement im Registerdatensatz oder als der Registerdatensatz vorgesehen. Diese maskierten elektronischen Münzdatensätze sind mit ihrer entsprechenden Verarbeitung im Münzregister registriert. Das Maskieren ist in den Anmeldungen WO 2020/212337 Al und WO 2020/212331 Al beschrieben und es wird diesbezüglich darauf Bezug genommen. In einer bevorzugten Ausgestaltung lässt sich daraus ein Gültigkeits Status des (maskierten) elektronischen Münzdatensatzes ableiten. Bevorzugt wird die Gültigkeit der (maskierten) elektronischen Münzdatensätze in dem Münzregister vermerkt (registriert). Zudem werden Modifikationen, wie Umschalten, Aufteilen oder Kombinieren, zu den einzelnen elektronischen Münzdatensätzen im Münzregister registriert. Die Erstellung, Prüfung und Registrierung dieser Modifikationen ist in den Anmeldungen WO 2020/212337 Al und WO 2020/212331 Al beschrieben und es wird diesbezüglich darauf Bezug genommen.
Der Schritt des Registrierens eines Registerdatensatzes (bzw. eines maskierten elektronischen Münzdatensatzes ist in den Anmeldungen WO 2020/212337 Al und WO 2020/212331 Al beschrieben und es wird diesbezüglich darauf Bezug genommen. Eine Registrierung der Verarbeitung bzw. der Verarbeitungsschritte für eine jeweilige Modifikation in dem Münzregister kann in einer Ausgestaltung des Bezahlsystems auch das Registrieren von Prüfergebnissen und Zwischenprüfergebnissen betreffend die Gültigkeit eines elektronischen Münzdatensatzes im Münzregister betreffen, insbesondere das Bestimmen von Prüfwerten und Zählerwerten entsprechender elektronischer Münzdatensätze. Ist eine Verarbeitung endgültig, wird dies beispielsweise durch entsprechende Markierungen oder einer abgeleiteten Gesamtmarkierung im Münzregister angezeigt. Eine endgültige Verarbeitung entscheidet sodann, ob ein elektronischer Münzdatensatz gültig oder ungültig ist. Der Schritt des Registrierens wird vorzugsweise dann ausgeführt, wenn die Teilnehmereinheit und/oder das Sicherheitselement mit dem Münzregister verbunden ist.
Bevorzugt wird der zumindest eine initiale elektronische Münzdatensatz von der Herausgeberinstanz erstellt, wobei vorzugsweise die aufgeteilten elektronischen Münzdatensätze, insbesondere elektronischen Münzteildatensätze, auch durch eine Teilnehmereinheit generiert werden können. Das Erstellen und das Wählen eines monetären Betrags beinhalten bevorzugt auch das Wählen eines Verschleierungsbetrags mit hoher Entropie.
Die Herausgeberinstanz wird deshalb auch als privilegierte Instanz bzw. privilegierter Knoten, engl privileged node, bezeichnet, da nur diese neues Geld in Form von elektronischen Münzdatensätzen erstellen kann und Geld vernichten kann durch Deaktivieren von elektronischen Münzdatensätzen. Die Herausgeberinstanz kann deshalb geldwerte Beträge für das Bezahlsystem erzeugen und vernichten, dementsprechend den umlaufenden geldwerten Gesamtbetrag im Bezahlsystem steuern.
Die Herausgeberinstanz ist ein Rechensystem, welches bevorzugt entfernt von der ersten und/ oder zweiten Teilnehmereinheit ist. Nach dem Erstellen des neuen elektronischen Münzdatensatzes wird der neue elektronische Münzdatensatz in der Herausgeberinstanz durch Anwenden der homomorphen Einwegfunktion auf den neuen elektronischen Münzdatensatz maskiert, um entsprechend einen maskierten neuen elektronischen Münzdatensatz zu erhalten.
Des Weiteren werden zusätzliche Informationen, die zum Registrieren des Erstellens des maskierten neuen elektronischen Münzdatensatzes in dem entfernten Münzregister benötigt werden, in der Herausgeberinstanz berechnet. Bevorzugt sind diese weiteren Informationen ein Nachweis, dass der (maskierte) neue elektronische Münzdatensatz von der Herausgeberinstanz stammt, beispielsweise durch ein Signieren des maskierten neuen elektronischen Münzdatensatzes. In einer Ausgestaltung kann vorgesehen sein, dass die Herausgeberinstanz einen maskierten elektronischen Münzdatensatz beim Erzeugen des elektronischen Münzdatensatzes mit ihrer Signatur signiert. Die Signatur der Herausgeberinstanz wird dazu in dem Münzregister hinterlegt. Die Signatur der Herausgeberinstanz ist von der erzeugten Signatur einer Teilnehmereinheit bzw. eines Sicherheitselements verschieden.
Bevorzugt ist die Herausgeberinstanz eine Rechnerinstanz einer Zentralbank.
Bevorzugt sind das Münzregister und die Herausgeberinstanz in einer gemeinsamen Serverinstanz angeordnet oder liegen als Computerprogrammprodukt auf einem Server und/ oder einem Computer vor. Bevorzugt wird auf die Herausgeberinstanz über ein http -Protokoll zugegriffen.
Die Modifikationen (Umschaltens, Aufteilens, Verbinden) und die Aktionen (Erstellen und Deaktivieren (Zurückgebens)) werden jeweils durch einen entsprechenden Erstell-, Umschalt-, Aufteil-, Verbinden- bzw. Deaktivier-Befehl (Rückgabe-Befehle) ausgelöst.
Das Verfahren ist nicht auf eine Währung beschränkt. So kann das Bezahlsystem eingerichtet sein, verschiedene Währungen von unterschiedlichen Herausgeberinstanzen zu verwalten. Das Bezahlsystem ist beispielsweise eingerichtet einen elektronischen Münzdatensatz einer ersten Währung in ein elektronischen Münzdatensatz einer anderen Währung umzusetzen (=wechseln). Dieses Wechseln ist ebenfalls eine Modifikation des elektronischen Münzdatensatzes. Mit dem Wechsel wird der ursprüngliche Münzdatensatz ungültig und gilt als zurückgegeben. Ein flexibles Bezahlen mit unterschiedlichen Währungen ist damit möglich und die Benutzerfreundlichkeit ist erhöht.
Das Verfahren ermöglicht zudem das Umsetzen des elektronischen Münzdatensatzes in Buchgeld, also beispielsweise das Einlösen des monetären Betrags auf ein Konto des Teilnehmers am Bezahlsystem. Dieses Umsetzen ist ebenfalls eine Modifikation. Mit dem Einlösen wird der elektronische Münzdatensatz ungültig und gilt als zurückgegeben. Eine Modifikation „Freeze“ an einem elektronischen Münzdatensatz kann vorgesehen sein, um ein zeitweises Deaktivieren des elektronischen Münzdatensatzes, besser den geldwerten Betrag des elektronischen Münzdatensatzes, zu veranlassen. Der elektronische Münzdatensatz wird dabei in einen deaktivierten Zustand gesetzt, ohne vernichtet zu werden, der elektronische Münzdatensatz wird quasi „eingefroren“. Diese Modifikation bzw. Aktion „Freeze“ unterscheidet sich von der Modifikation bzw. Aktion „Deaktivieren“ eines elektronischen Münzdatensatz. Beim „Deaktivieren“ erfolgt ein vollständiges Entfernen des geldwerten Betrags eines elektronischen Münzdatensatz aus dem Bezahlsystem. Es wird Geld des Bezahlsystems vernichtet, der im Bezahlsystem umlaufende geldwerte Gesamtbetrag wird reduziert. Dieses „Deaktivieren“ erfolgt zum Eintauschen des geldwerten Betrags eines elektronischen Münzdatensatzes auf Wunsch des Teilnehmers (Gutschrift auf Konto, Elmformen zu Buchgeld, Auszahlen in Bargeld, etc.) oder aufgrund des Ablaufs einer Gültigkeit oder aufgrund des Überschreitens eines Prüfwerts. Im Gegensatz dazu wird bei der Modifikation „Freeze“ wird der elektronische Münzdatensatz lediglich zeitweise deaktiviert, d.h. der geldwerte Betrag ist weiterhin vorhanden, kann aber von keinem Teilnehmer - im Rahmen einer Bezahltransaktion - verwendet werden, um geldwerte Beträge auszutauschen. Diese Modifikation „Freeze“ kann nicht von einer Teilnehmereinheit, also nicht vom Besitzer des elektronischen Münzdatensatzes durchgeführt werden. Diese Modifikation „Freeze“ kann nur von einer privilegierten Instanz, beispielsweise einer Herausgeberinstanz oder einer Überwachungsinstanz (nicht dem Münzregister) initiiert und durchgeführt werden. Diese privilegierte Instanz kann beispielsweise eine autorisierte Behörde, beispielsweise eine Strafverfolgungsbehörde oder einer Kombination aus mehreren vertrauenswürdigen Instanzen sein. So kann ein geldwerter Betrag eines Verdächtigen beschlagnahmt werden, ohne dass das Geld sofort vernichtet wird.
Eine zur Modifikation bzw. Aktion „Freeze“ komplementäre Modifikation bzw. Aktion ist das „Unfreeze“. Hierbei werden die durch eine „Freeze“ Aktion deaktivierten Münzdatensätze wieder aktiviert (also reaktiviert). Diese Modifikation „Unfreeze“ kann nur von einer privilegierten Instanz, beispielsweise einer Herausgeberinstanz oder einer Überwachungsinstanz (nicht dem Münzregister) initiiert und durchgeführt werden. Diese privilegierte Instanz kann beispielsweise eine autorisierte Behörde, beispielsweise eine Strafverfolgungsbehörde oder einer Kombination aus mehreren vertrauenswürdigen Instanzen sein. So kann ein geldwerter Betrag eines Verdächtigen wieder freigegeben werden, beispielsweise nach erwiesener Unschuld des Verdächtigen.
Die Aktionen „Freeze“ und „Unfreeze“ für einen jeweiligen elektronischen Münzdatensatz werden in einem Münzregister durch Einträge zu einem entsprechenden maskierten elektronischen Münzdatensatz registriert. Diese Aktionen werden hier für sich genommen als bekannt vorausgesetzt. Bei einer „Freeze“ Aktion werden beispielsweise für einen entsprechenden maskierten elektronischen Münzdatensatz gar keine Nachfolger- Münzen angegeben (bzw. die eingetragenen werden gelöscht), wodurch der elektronische Münzdatensatz bei jeder Validität- Prüfungen ungültig ist. Bei einer „Unfreeze“ Aktion werden für einen entsprechenden maskierten elektronischen Münzdatensatz neue Nachfolger- Münzen angegeben, wodurch der elektronische Münzdatensatz bei einer Validität-Prüfungen wieder gültig ist.
KI IR ZF ZUSAMMENFASSUNG DER FIGUREN Nachfolgend wird anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.
Es zeigen:
Fig.1 ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung;
Fig. 2 eine Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der Fig. 1;
Fig. 3 eine Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der Fig. 1;
Fig.4 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines Verfahrens in einer Herausgeberinstanz;
Fig.5 ein Ausführungsbeispiel einer Datenstruktur im Münzregister;
Fig. 6 zwei Au sführungsbei spiele eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechende Verarbeitungs schritte eines Münzdatensatzes;
Fig. 7 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechende Verarbeitungsschritte eines Münzdatensatzes;
Fig. 8 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechende Verarbeitungsschritte eines Münzdatensatzes;
Fig. 9 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechende Verarbeitungsschritte eines Münzdatensatzes; Fig. 10 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines Verfahrens zum Registrieren eines Münzdatensatzes innerhalb einer atomaren Austauschprozedur; und
Fig. 11 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechende Verarbeitungsschritte eines Münzdatensatzes.
FIGURENBESCHREIBUNG
Die Fig. 1 zeigt ein Ausführungsbeispiel eines Bezahlsystems BZ gemäß der Erfindung. Die gestrichelt dargestellten Blöcke und Pfeile des Bezahlsystems BZ sind dabei optional. Das Bezahlsystem BZ umfasst zumindest zwei Sicherheitselemente, kurz SE, SEI und SE2. Die SEI und SE2 können dabei in jeweiligen Endgeräten Ml und M2 betriebsbereit eingebracht und logisch oder physisch mit dem jeweiligen Endgerät Ml und M2 verbunden sein. Ml und M2 können alternativ auch Teilnehmereinheiten TE1, TE2 sein.
Im Bezahlsystem der Fig. 1 ist zudem eine optionale Herausgeberinstanz 1, die einen elektronischen Münzdatensatz C, erzeugt. Die Herausgeberinstanz 1 ist beispielsweise eine Serverinstanz einer Zentralbank la. Zu dem elektronischen Münzdatensatz C wird ein Registerdatensatz RDS, beispielsweise ein maskierter elektronischer Münzdatensatz Z, erzeugt und in einem Münzregister 2 des Bezahlsystems BZ registriert 104. Der elektronische Münzdatensatz C wird im optionalen Schritt 102 von der Herausgeberinstanz 1 an das erste Endgerät Ml ausgegeben. Der Registerdatensatz RDS, beispielsweise der maskierte elektronische Münzdatensatz Z, wird im Schritt 104 beispielsweise von der Herausgeberinstanz
1 direkt oder über das erste Endgerät Ml an das Münzregister 2 ausgegeben. Der Registerdatensatz RDS, beispielsweise der maskierte elektronische Münzdatensatz Z, wird alternativ vom ersten Endgerät Ml (oder zweiten Endgerät M2) erzeugt und an das Münzregister
2 im Schritt 104 gesendet.
Um einen elektronischen Münzdatensatz C zu erzeugen wird folgendes Verfahren vorgeschlagen.
Eine Anfrage 210 von einer Zentralbank oder einer Teilnehmereinheit TE oder einer Geschäftsbank zur Erzeugung eines elektronischen Münzdatensatzes wird von der Herausgeberinstanz 1 erhalten. Die Herausgeberinstanz 1 hat beispielsweise eine Münzgenerierungs-Einheit 11 und eine Münzausgabe-Einheit 12. Beide Einheiten 11, 12 sind in einer Ausgestaltung voneinander getrennt und weisen ein Air-Gap 14 auf. Das Air-Gap 14 dient dazu, dass die in der Herausgeberinstanz 1 hochsensiblen sicherheitsrelevanten Daten und Einheiten des Bezahlsystems BZ, insbesondere ein privater Schlüssel PK und ein Zufallsgenerator nicht über einen Netzwerkangriff auf die Herausgeberinstanz 1 ausgelesen und für Manipulationen am Bezahlsystem BZ verwendet werden können. Die Münzgenerierungs- Einheit 11 kann dabei vollständig isoliert sein. Beispielsweise ist die Münzgenerierungs-Einheit 11 ohne Schnittstelle zu einem Netzwerk, wie TCP/IP, dem Internet, dem Mobilfunknetz, etc. Der Air-Gap Prozess 14 wird hier nicht weiter erläutert. Die Datenübertragung von und zur Herausgeberinstanz erfolgt bevorzugt mittels eines http-Protokolls.
Der elektronischer Münzdatensatz, im Folgenden auch abgekürzt als eMDS bezeichnet, C kann vorab bei der Herausgeberinstanz 1 angefragt und optional von einem Endgerät M (oder einem SE) oder der Herausgeberinstanz 1 oder einem anderen Bezahlsystem empfangen werden. Die Anfrage 210 kann von einer Zentralbank la generiert worden sein. Alternativ fragt eine Teilnehmereinheit TE den elektronischen Münzdatensatz C an. Die Schritte 104 und 105 können den Schritten 104 und 105 der Fig. 7 entsprechen. Eine Aktion bzw. Modifikation (Aufteilen, Verbinden, Umschalten, Übertragen, Deaktivieren, Umtauschen, Alarmieren) am eMDS C kann einer der Aktionen der Fig. 7 bis 11 entsprechen. Diese Modifikationen sind beispielhaft auch in den Patentanmeldungen WO 2020/212337 Al und WO 2020/212331 Al beschrieben.
Beispielsweise wird als Verschleierungswert n, der vorzugsweise ein Verschleierungsbetrag ist, eine echte Zufallszahl erzeugt. Der Verschleierungswert n ist zwar in der Direkttransaktionsschicht 3 und für neu herausgegebene eMDS auch in der Herausgeberinstanz 1 bekannt, aber für die übrigen Instanzen des Bezahlsystems BZ, also auch für das Münzregister 2 geheim. Der Verschleierungswert n ist beispielsweise eine 32 Byte große positive Zufallszahl. Die Erzeugung erfolgt beispielsweise mittels eines echten Zufallsgenerators. Ein Wertebereich für den Verschleierungswert n ist beispielsweise [0,n), wobei n die Ordnung eines auf elliptischen Kurven basierenden Kryptografie- Verfahrens, beispielsweise eines Elliptic Curve Digital Signature Algorithm, kurz ECDSA, bevorzugt des secp256rl ist, der auf der Kurve y2 = x3 + 7 eines Galois-Körpers basiert. Die Implementierungsmechanismen zur Generierung des Verschleierungs werts n werden sicherstellen, dass ein Verschleierungswert n nicht zweimal erstellt wird.
Der Verschleierungswert n wird mit einem monetären Betrag Di verknüpft. Der monetäre Betrag Di ist beispielsweise ein ganzzahliger Wert, bevorzugt vom Datentyp 32 bit unsigned integer value. Der monetäre Betrag Di hat nur beispielsweise einen beschränkten Wertebereich aus Zweierpotenzen. Der Wert null („0“) als monetärer Betrag Di könnte ungültig sein.
Ein erfindungsgemäßer i-ten elektronischen Münzdatensatz der von der Münzgenerierungs- Einheit 1 erzeugt wurde, könnte demnach lauten:
Ci = { ; nj (1) Ein elektronischer Münzdatensatz C mit dem monetären Betrag 100,00 Euro könnte demnach sein: c = (u; rj = (10000, 456123489469997561 } (la)
Ein gültiger elektronischer Münzdatensatz C kann zur Bezahlung eingesetzt werden. Der Besitzer der beiden Werte Di und n ist daher im Besitz des digitalen Geldes. Das digitale Geld ist definiert durch ein Paar bestehend aus einem gültigen elektronischen Münzdatensatz Ci und einem entsprechenden Registerdatensatz RDSi, beispielsweise einem maskierten elektronischen Münzdatensatz Zi. Zi repräsentiert bevorzugt einen Punkt in einem auf elliptischen Kurven basierenden Kryptografie- Verfahren, beispielsweise eines Elliptic Curve Digital Signature Algorithm, kurz ECDSA, bevorzugt des secp256rl. Zi kann in einer unkomprimierter Form kodiert sein, wie es in Standards for Efficient Cryptography, Elliptic Curve Cryptography; Abschnitt 2.3.3 beispielhaft angegeben ist. Beispielsweise wird ein maskierter elektronischer Münzdatensatz Zi als Registerdatensatz RDS, durch Anwenden einer homomorphen Einwegfunktion f (Ci) gemäß Gleichung (2) erhalten:
Zi =f (Ci) (2)
Diese Funktion f (Ci) ist öffentlich, d.h. jeder Systemteilnehmer kann diese Funktion aufrufen und verwenden. Diese Funktion f (Ci) ist gemäß Gleichung (3) definiert:
Z* = Vi H + n G (3) sodass ein zum elektronischen Münzdatensatz C gemäß Gleichung (la) passender maskierter elektronischer Münzdatensatz dann wäre:
Z« = 10000 H + 456123489469997561 G (3a) 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 H (4) die Verknüpfung n praktisch nicht auffindbar sein darf, um zu verhindern, dass der monetäre Betrag Di manipuliert wird und trotzdem ein gültiges Zi berechnet werden könnte. Beispielsweise ist:
G =
046bl7dlf2el2c4247f8bce6e563a440f277037d812deb33a0f4al3945d898c2964fe342e2fela7f9 b8ee7eb4a7cOf9el62bce33576b315ececbb6406837bf5 lf5 und
H =
04cf09b7c2c8e880d5053f73b2679b0842b38c9b0c6e9al80ab6c02f46fad8409a0d739cd5151026
8dd9aa0f4e306543e80d3085e48bl5a3ce2bl6406b8b0b5825
Diese Punkte G und H sind hier in unkomprimierter Form gemäß Abschnitt 4.3.6 von ANSI X9.62 angegeben. Dadurch werden sowohl x als auch y der Punkte der Kurve koordiniert als 64- Byte-Ganzzahlen in hexadezimaler Darstellung mit einem Formatpräfix angezeigt, in diesem Fall „04“ für unkomprimiert, was bedeutet, dass sowohl x als auch y angegeben sind. Mit diesen Werten von G und H, eingesetzt in Gleichung (3 a) ergibt sich
Zx =
6583233424795669663437883238211356250035283936299757616407822287674322554993 und
Zy =
78952089896437642461730835495473021650955753886857183759343381812153089956629 Sodass Z in unkomprimierter ANSI X9.62 als Hex-Koordinaten lautet:
Z =
040e8dfa631b4c2dfa9908252592ae693a5dcal9198ba0c801f503648f59299071ae8d4c9e88f0fd7
0777023f7014b98f873elf09dl85blca246b9c913ee369bl5
Die Gleichung (3) ist ein „Pederson-Commitment für ECC“, das sicherstellt, dass der monetäre Betrag u, einem Münzregister 2 zugestanden, also „commited“, werden kann, ohne diesen dem Münzregister 2 zu offenbaren. Der Verschleierungswert n wird als Verschleierungsbetrag bezeichnet, da er zumindest den monetären Betrag des eMDS maskiert.
Alternativ wird ein maskierter elektronischer Münzdatensatz Zi als Registerdatensatz RDS, durch Anwenden einer Einwegfunktion f (Ci) gemäß Gleichung (3-1) erhalten: Zi = { Vi ; n Gj (3-1)
Der maskierte elektronischer Münzdatensatz Zi besteht dann aus dem Betrag v und dem maskierten Verschleierungswert Ri, mit Ri = n · G.
Nachfolgend wird ein Registerdatensatz RDS, im Folgenden teils auch verkürzt RDS, mit einem maskierten Münzdatensatz Z gleichgesetzt.
Dem Münzregister 2 wird nur der RDS, beispielsweise der maskierte Münzdatensatz Zi zugesendet (offenbart), also insbesondere nicht der Verschleierungswert (und ggf. nicht der monetäre Betrag). In Fig. 1 ist dies als Schritt 104 (Registrieren, Registrierungsanforderung) dargestellt, wobei die Registrierungsanforderung den Registerdatensatz umfasst.
Der RDS kann dabei von der Herausgeberinstanz 1 für das Münzregister 2 bereitgestellt werden. Das RDS wird bevorzugt in der Münzgenerierung 11, kann aber auch in der Münzausgabe- Einheit 12 generiert werden.
Auch wenn im vorliegenden Beispiel eine Verschlüsselung basierend auf elliptischen Kurven beschrieben ist bzw. wird, so wäre auch ein anderes kryptographisches Verfahren denkbar, welches auf einem diskreten logarithmischen Verfahren beruht.
Die Gleichungen (3) und (3-1) ermöglichen durch die Entropie des Verschleierungsbetrags n, dass auch bei kleinem Wertebereich für monetäre Beträge Ui ein kryptografisch starkes Zi erhalten wird. Somit ist ein einfacher Brute-Force-Angriff durch bloßes Schätzen von monetären Beträgen Ui praktisch nicht möglich.
Die Gleichung (3) ist eine Einwegfunktion, das heißt, dass die Berechnung von Zi aus Ci einfach ist, da ein effizienter Algorithmus existiert, wohingegen die Berechnung von Ci ausgehend von Zi sehr schwer ist, da kein in polynomialer Zeit lösbarer Algorithmus existiert.
Zudem ist die Gleichung (3) homomorph für Addition und Subtraktion, das heißt es gilt:
Zi + Zj = (Vi H + n G)+ (Oj H + h G) = ( + Vj)· H + (n + h)· G (5)
Somit können Additions-Operationen und Subtraktions-Operationen sowohl in der Direkttransaktionsschicht 3 also auch parallel in dem Münzregister 2 ausgeführt werden, ohne dass das Münzregister 2 Kenntnis von den elektronischen Münzdatensätzen Ci hat. Die homomorphe Eigenschaft der Gleichung (3) ermöglicht eine Überwachung von gültigen und ungültigen elektronischen Münzdatensätzen Ci auf alleiniger Basis der maskierten Münzdatensätze Zi zu führen und sicherzustellen, dass kein neuer monetärer Betrag Uj geschaffen wurde.
Durch diese homomorphe Eigenschaft kann der Münzdatensatz Ci gemäß Gleichung (1) aufgeteilt werden in:
Ci = Cj + Ck = {vj; rj} + {vk; n} (6) wobei gilt:
Vi = Vj + Vk (7) n = h + (8)
Für die entsprechenden maskierten Münzdatensätze gilt:
Zi = Zj + Zk (9)
Mit Gleichung (9) kann beispielsweise auf einfache Weise ein symmetrisches oder asymmetrisches Aufteilen als Modifikation bzw. ein „symmetrischer oder asymmetrischer Aufteilen“-Verarbeitungsschritt 110 eines Münzdatensatzes C gemäß Fig. 8 geprüft werden, ohne dass das Münzregister 2 Kenntnis von Ci, Cj, Ck hat. Insbesondere wird die Bedingung der Gleichung (9) geprüft, um aufgeteilte Münzdatensätze Cj und Ck für gültig zu erklären und den Münzdatensatz Ci für ungültig zu erklären. Ein derartiges Aufteilen 110 eines elektronischen Münzdatensatzes Ci ist in Fig. 8 gezeigt.
Auf die gleiche Weise können elektronische Münzdatensätze C auch zusammengefügt (verbunden) 109 werden, siehe dazu Fig. 7 und die Erläuterungen dazu.
Zusätzlich gilt es zu prüfen, ob (nicht erlaubte) negative monetäre Beträge registriert werden. Ein Besitzer eines elektronischen Münzdatensatzes Ci muss dabei dem Münzregister 2 und/oder dem Münzregister 2 nachweisen können, dass alle monetären Beträge Di in einer Verarbeitungs- Operation innerhalb eines Wertebereichs von [0, ... , n] liegen, ohne dem Münzregister 2 dabei die monetären Beträge Di mitzuteilen. Diese Bereichsnachweise werden auch „Range-Proofs“ genannt. Als Bereichsnachweise werden bevorzugt Ringsignaturen (engl ring signature) verwendet. Für das vorliegende Ausführungsbeispiel werden sowohl der monetäre Betrag D als auch der Verschleierungsbetrag r eines elektronischen Münzdatensatzes C in Bitdarstellung aufgelöst. Es gilt:
Di=Zäj-2J für 0 < j < n und aj E {0; 1 } (9a) sowie ri=£bj-2J für 0 < j < n und bj E {0; 1 } (9b)
Für jedes Bit wird vorzugsweise eine Ringsignatur mit
Cij= aj H + bj G (9c) und
Cij - aj - H (9d) durchgeführt, wobei in einer Ausgestaltung vorgesehen sein kann, nur für bestimmte Bits eine Ring Signatur durchzuführen.
Zusätzlich oder alternativ sollte bewiesen werden, dass kein zusätzliches Geld generiert wurde und es muss der rechtmäßige Besitz nachgewiesen werden können. Diese beiden Beweise (kein zusätzliches Geld + rechtmäßiger Besitz) können in einem „Equal Value Proof‘, kurz EVP, gemeinsam durchgeführt werden:
Ausgangspunkt dieses EVP sind zwei maskierte Münzdatensätze Zi, Z2, deren dazugehörige elektronischen Münzdatensätze Ci, C2 denselben monetären Betrag, also u = m = m aufweisen. Es muss nun bewiesen werden, dass der Beweiserbringer die elektronischen Münzdatensätze Ci, C2 kennt und dass beiden maskierten Münzdatensätze Zi, Z2 der gleiche Betrag u = ui = 112 zugestanden wurde („commited“).
Dazu werden drei Zufallszahlen ko, ki und k2 jeweils im Wertebereich [0, n) generiert und folgende Parameter berechnet: e = h (kO * H + kl * G II kO * H + k2 * G) mod N sO = (kO + e * v) mod N sl = (kl + e * rl) mod N s2 = (k2 + e * r2) mod N
Wobei n und N die Ordnung des ECC ist, h eine Streu wertfunktion zum Erzeugen eines Streuwerts, beispielsweise eines SHA-256 Hashwerts, über die Punkte (p 1 , ... pn} mit: h(pl II ... II pn) = sha256(pl || ... || pn) (9f)
Der EVP kann veröffentlicht werden, beispielsweise als: evp = {e, s0, sl, s2} (9g)
Die EVP dieser zwei maskierten Münzdatensätze Zi, Z2 kann nun (im Münzregister 2 oder einer TE) verifiziert werden: e' = h(s0 * H + sl * G - e * ZI II sO * H + s2 * G - e * Z2) (9h) denn es gilt:
Das Münzregister 2 kann nun validieren, dass e = e‘ ist, woraufhin u = u i = m gelten muss. Die EVP hat eine insgesamte Länge von 196 Byte, wobei e = 32 Byte, sO = 36 Byte, sl = 64 Byte und s2 = 64 Byte aufweist.
Wird ein maskierter elektronischer Münzdatensatz Zi gemäß Gleichung 3-1 erzeugt, vereinfacht sich die Prüfung der monetären Beträge.
Die in Fig. 1 gezeigte Ausgestaltung des Bezahlsystems BZ zeigt insbesondere das Erzeugen eines elektronischen Münzdatensatzes C zur direkten Herausgabe an eine Teilnehmereinheit TE1 (Schritt 102). Alternativ erfolgt die Herausgabe an die Teilnehmereinheit TE1 indirekt über eine Bankinstanz 4 durch die Schritte 102‘ (Bereitstellen des eMDS C an die Bank 4) und in dem Folgeschritt 102“ (Bereitstellen des eMDS C an die TE1).
Das Erzeugen des RDS durch die Herausgeberinstanz 1 ist hier nur optional und kann auch von den Teilnehmereinheiten TE1, TE2 durchgeführt werden.
Die Fig. 2 zeigt eine Weiterbildung des in Fig. 1 gezeigten Bezahlsystems BZ. Auf die Ausführungen der Fig. 1 wird hiermit Bezug genommen, um Wiederholungen zu vermeiden. Dabei wird in Fig. 2 das Deaktivieren eines Münzdatensatzes C beschrieben. Eine Teilnehmereinheit TE1 entscheidet sich zur Deaktivierung und Rückgabe des Münzdatensatzes C und sendet eine Deaktivieren-Aufforderung im Schritt 111. Dieser Schritt 111 kann die Abbildung eines Teilnehmerwunsches sein, nämlich einen monetären Betrag eines Münzdatensatzes auf ein Konto des Teilnehmers gutzuschreiben, oder kann aufgrund einer Auswertung eines Prüfwerts pi erfolgen, bei der festgestellt wurde, dass der Münzdatensatz die Kriterien für eine Rückgabe erfüllt, beispielsweise dem Ablauf einer Gültigkeitsdauer, dem Erreichen eines Rückgabezeitpunkts, dem Erreichen eines „Alters“ (Anzahl von Übertragungen und Modifikationen) oder dem Erreichen eines Schwellwerts bei Nichtverwendung des Münzdatensatzes C. Schritt 111 wird der Münzausgabe-Einheit 12 direkt angezeigt. Das Anzeigen kann auch indirekt über die Rankinstanz 4 erfolgen (ähnlich dem Erhalten des Münzdatensatzes), was in Fig. 2 durch die Schritte 111‘ und 111“ dargestellt ist. In der Folge des Schritts 111 wird das Gutschreiben des monetären Betrags auf ein Konto des Teilnehmers oder durch Ausgeben von Bargeld an einem Ausgabefach der Einheit 12 im Folgeschritt veranlasst (nicht dargestellt). Im dargestellten Folgeschritt 212 wird ein Deaktivieren- Kommando an das Münzregister 2 gesendet, um den Registerdatensatz RDS aus dem Münzregister 2 zu löschen oder ihn dort auf ungültig zu schalten. In der Folge ist der RDS des deaktivierten (gutgeschriebenen) Münzdatensatzes aus dem Münzregister 2 gelöscht (durchgestrichenes RDS).
Fig. 3 ist eine Weiterbildung des Bezahlsystems BZ der Fig. 1. Die Münzausgabe-Einheit 12 der Herausgeberinstanz 1 der Fig. 1 weist eine Empfangseinheit 15 (nicht dargestellt in Fig. 1) auf, an der Münzgenerieranfragen einer Teilnehmereinheit TE oder einer Zentralbank (nicht dargestellt) ankommen. Die Empfangseinheit 15 überträgt die Anfrage 210 an die Münzgenerierungs-Einheit 11 mittels eines Air-Gap Prozesses 14‘. Dabei können die gleichen Mechanismen wie beim zuvor erwähnten Air-Gap Prozess 14 angewendet und die gleichen Schnittstellen verwendet werden. Die Münzgenerierungs-Einheit 11 erzeugt den Münzdatensatz C und auch den Registerdatensatz RDS.
Um den Registerdatensatz RDS als vertrauenswürdig zu kennzeichnen, signiert die Münzgenerierungs-Einheit 11 den erzeugten Registerdatensatz RDS mit einem privaten Schlüssel PK der Herausgeberinstanz 1. Die Kombination aus elektronischem Münzdatensatz C, Registerdatensatz RDS und signiertem Registerdatensatz [RDS]Sig(PK) wird durch einen Ausdruck Ai, beispielsweise als QR-Code, repräsentiert. Dieser Ausdruck Ai wird über den Air- Gap-Prozess 14 an die Münzausgabeeinheit 12 bereitgestellt. Dort wird mittels einer Leseeinheit 16, beispielsweise einem QR-Code-Scanner, der Ausdruck Ai eingelesen, um den elektronischen Münzdatensatz C zu erhalten. Zudem erzeugt die Münzgenerierungs-Einheit 11 Metadaten MC, die dem Ausdruck Ai angefügt oder als eigenständige Übertragung an die Münzausgabe-Einheit 12 bereitgestellt wird.
Die Einheit 16 prüft die Einmaligkeit des Münzdatensatzes Ci, indem beispielsweise die Metadaten MCi mit Metadaten der im Bezahlsystem BZ existierenden Münzdatensätze C abgeglichen wird. Beispielsweise wird eine Seriennummer oder eine Münzkennung für diese Prüfung herangezogen. Ist die Einmaligkeit des Münzdatensatzes Ci bestätigt, so wird dieser in dem Münzspeicher 17 der Herausgeberinstanz 1 abgelegt und (zeitlich unkorreliert) an eine Teilnehmereinheit TE im Schritt 102 ausgegeben. Das Bereitstellen des RDS an das Münzregister 2 kann bereits nach Prüfung auf Einmaligkeit erfolgen oder erst bei Anfragen eines Münzdatensatzes Ci durch eine TE oder die Rankinstanz 4 erfolgen.
Das Bereitstellen des RDS im Schritt 102 an das Münzregister 2 ermöglicht das Registrieren des Münzdatensatzes Ci im Bezahlsystem BZ. Dazu wird in einer Ausgestaltung der RDS und der signierte [RDS]Sig(PK) bereitgestellt. Mit dem öffentlichen Schlüssel der Herausgeberinstanz 1 kann im Münzregister 2 die Signatur des signierten [RDS]Sig(PK) geprüft werden und bei erfolgreicher Prüfung wird der RDS als gültig im Münzregister 2 registriert. In einer anderen Ausgestaltung erhält das Münzregister 2 nur den signierten Registerdatensatz [RDS]Sig(PK). Sobald eine Teilnehmereinheit TE den Registerdatensatz RDS direkt an das Münzregister 2 bereitstellt (also erst nach der Ausgabe des Münzdatensatzes C an die TE1 im Schritt 102), kann in dem Münzregister 2 mit dem öffentlichen Schlüssel der Herausgeberinstanz 1 die Signatur geprüft werden und bei erfolgreicher Prüfung der RDS als gültig im Münzregister 2 registriert werden.
Gemäß Fig. 1 und 3 wird im TE2 der übertragene elektronische Münzdatensatz Ci als Ci* erhalten. Mit dem Erhalt des elektronischen Münzdatensatzes Ci* ist die TE2 im Besitz des digitalen Geldes, den der elektronische Münzdatensatz Ci* repräsentiert. Mit der direkten Übertragung 105 steht es der TE2 für weitere Aktionen zur Verfügung.
Aufgrund der höheren Vertrauenswürdigkeit bei der Verwendung von SEs können sich SEI, SE2 gegenseitig vertrauen und es sind prinzipiell keine weiteren Schritte für das Übertragen 105 notwendig. Allerdings ist dem SE2 nicht bekannt, ob der elektronische Münzdatensatz Ci* tatsächlich gültig ist. Zur weiteren Absicherung des Übertragens 105 können weitere Schritte im Verfahren vorgesehen sein, wie nachfolgend erläutert wird.
Zum Prüfen der Validität des erhaltenen elektronischen Münzdatensatzes Ci* kann im SE2 mit der - öffentlichen - Einwegfunktion aus Gleichung (3) ein weiterer RDS, beispielsweise der maskierte übertragene elektronische Münzdatensatz Zi*, errechnet werden. Der RDS, also beispielsweise der maskierte übertragene elektronische Münzdatensatz Zi* wird dann an das Münzregister 2 im Schritt 104 übertragen und dort gesucht. Bei Übereinstimmung beider RDS bezüglich des gleichen Münzdatensatzes C, also beispielsweise einer Übereinstimmung mit einem registrierten und gültigen maskierten elektronischen Münzdatensatz Zi, wird dem SE2 die Validität des erhaltenen Münzdatensatzes Ci* angezeigt und es gilt, dass der erhaltene elektronische Münzdatensatz Ci* gleich dem registrierten elektronischen Münzdatensatz Ci ist. Mit der Prüfung auf Validität kann in einer Ausgestaltung festgestellt werden, dass der erhaltene elektronische Münzdatensatz Ci* noch gültig ist, d.h., dass er nicht bereits durch einen anderen Verarbeitungsschritt oder bei einer anderen Transaktion/Aktion bereits verwendet wurde und/ oder einer weiteren Veränderung unterworfen war. Bevorzugt findet danach ein Umschalten (=Switch) des erhaltenen elektronischen Münzdatensatzes statt.
Die alleinige Kenntnis eines RDS, also beispielsweise eines maskierten elektronischen Münzdatensatzes Zi, berechtigt nicht dazu, das digitale Geld des korrespondierenden elektronischen Münzdatensatzes Ci auszugeben.
Die alleinige Kenntnis des elektronischen Münzdatensatzes Ci berechtigt zum Bezahlen, d.h. eine Transaktion erfolgreich durchzuführen, insbesondere wenn der Münzdatensatz Ci gültig ist, beispielsweise wenn der elektronische Münzdatensatz Ci einen aktiven Status aufweist. Der Status wird bevorzugt erst bei Erhalt der Löschbestätigung des SEI in einen Aktiv-Status gesetzt. Es herrscht eine eineindeutige Beziehung zwischen den elektronischen Münzdatensätzen Ci und den entsprechenden maskierten elektronischen Münzdatensätzen Zi. Die maskierten elektronischen Münzdatensätze Zi werden in dem Münzregister 2, beispielsweise einer öffentlichen Datenbank, registriert. Durch dieses Registrieren 104 wird zunächst die Gültigkeit des elektronischen Münzdatensatzes Ci prüfbar, beispielsweise ob neue monetäre Beträge (illegaler Weise) erschaffen wurden.
Die maskierten elektronischen Münzdatensätze Zi werden in dem Münzregister 2 gespeichert. Alle Verarbeitungen an dem elektronischen Münzdatensatz Zi werden dort registriert, wohingegen die tatsächliche Übertragung des digitalen Geldes in einer (geheimen, d.h. einer der Öffentlichkeit nicht bekannten) Direkttransaktionsschicht 3 des Bezahlsystems BZ erfolgt. Zudem können in diesem Bezahlsystem BZ Überwachungen am Münzdatensatz C und der Teilnehmereinheit TE in einem Münzregister 2 erfasst werden.
Um ein mehrfaches Ausgeben zu verhindern oder um ein flexibleres Übertragen 105 zu gewährleisten, können die elektronischen Münzdatensätze C modifiziert werden. In der nachfolgenden Tabelle 1 sind beispielhafte Operationen aufgelistet, wobei mit dem angegebenen Befehl auch ein entsprechender Verarbeitungs schritt ausgeführt wird:
Tabelle 1 Anzahl von pro Verarbeitung eines C im TE bzw. der Herausgeberinstanz durchführbaren Operationen Weitere Operationen, die in Tabelle 1 nicht aufgeführt sind, können benötigt werden, beispielsweise das Wechseln der Währung oder das Einlösen des monetären Betrags auf einem Konto. Anstelle der angeführten Implementierung sind auch andere Umsetzungen denkbar, die andere Operationen implizieren.
Die Tabelle 1 zeigt, dass für jeden Münzdatensatz, jede der Verarbeitungen (Modifikationen) „Erstellen“, „Zurückgeben“, „Aufteilen“, „Verbinden“ und „Umschalten“ verschiedene Operationen „Signatur erstellen“; „Zufallszahl erstellen“; „Maskierung erstellen“; „Bereichsprüfung“ vorgesehen sein können, wobei jede der Verarbeitungs-Operation in dem Münzregister 2 registriert und dort in unveränderlicher Form an eine Liste vorheriger Verarbeitungs-Operationen für maskierte elektronische Münzdatensätze Zi angehängt wird. Die Operationen der Verarbeitungen „Erstellen“ und „Zurückgeben“ eines elektronischen Münzdatensatzes C werden nur an sicheren Orten und/oder nur von ausgewählten Instanzen, beispielsweise der Herausgeberinstanz 1, als privilegierten Instanzen ausgeführt, während die Operationen aller übrigen Verarbeitungen auf den Teilnehmereinheiten TE, also den Endgeräten M bzw. deren Sicherheitselementen SE ausgeführt werden können.
Die Teilnehmereinheiten TE können mittels e-Wallet für elektronische Münzdatensätze Ci (mit den Prüfwert p, pu p^) d.h. als elektronische Geldbörse mit einem Speicherbereich, in dem eine Vielzahl von Münzdatensätzen Ci hinterlegt sein können, ausgebildet sein und so beispielsweise in Form einer Applikation auf einem Smartphone oder IT-System eines Händlers, einer Geschäftsbank oder eines anderen Marktteilnehmers implementiert sein. Somit sind die Komponenten in der Teilnehmereinheit TE, so wie sie in Tabelle 3 gezeigt sind, als Software implementiert. Es wird davon ausgegangen, dass das Münzregister 2, ein nicht dargestelltes Transaktionsregister und/oder ein nicht dargestelltes Überwachungsregister auf einem Server oder auf einer DLT basiert und von einer Reihe vertrauenswürdiger Marktteilnehmer betrieben wird.
Im Münzregister 2 kann ein RDS betreffend den elektronischen Münzdatensatz C durch einen zu registrierenden RDS betreffend den elektronischen Münzdatensatz C oder eines modifizierten elektronischen Münzdatensatzes C ersetzt werden. Damit werden im Münzregister 2 (nur) aktuelle - im Bezahlsystem BZ existierende - Münzdatensätze C als RDS gepflegt.
In der Fig. 4 ist ein Verfahrensablaufdiagramm eines Verfahrens 200 für das Erzeugen und Herausgeben eines elektronischen Münzdatensatzes C in einer Herausgeberinstanz 1 gezeigt. Dabei wird im optionalen Schritt 101 eine Münzanfrage in der Herausgeberinstanz 1, beispielsweise der Empfangseinheit 150, empfangen. Die Anfrage 101 kann von einer Zentralbank oder auch von einer Teilnehmereinheit TE oder einer Geschäftsbank 4 des Bezahlsystems BZ erfolgt sein. Im optionalen Schritt 201 wird diese Anfrage mittels Air-Gap Prozess 14‘ an die Münzgenerierung s -Einheit 11 der Herausgeberinstanz 1 gesendet. Im Schritt
202 wird (beispielsweise im Münzgenerator 140) ein elektronischer Münzdatensatz generiert. Zudem können ein RDS und ein signierter RDS in den optionalen Schritten 203 und 204 erzeugt werden. Im optionalen Schritt 205 werden Metadaten erzeugt. Im Schritt 206 wird der elektronische Münzdatensatz C mittels Air-Gap-Prozess 14, ggf. mit dem RDS und dem signierten RDS an die Münzausgabe-Einheit der Herausgeberinstanz 1 gesendet. Dazu wird bevorzugt ein Ausdruck A erzeugt. Der Ausdruck A wird beispielsweise hündisch an die Münzausgabeeinheit 12 übergeben. Alternativ wird eine gesicherte Transportbox (Behälter) verwendet, um den Ausdruck (oder die Ausdrucke) zu übertragen. Der Ausdruck wird einen Lesebereich der Münzausgabe-Einheit 12 gebracht, um eingelesen zu werden. Bevorzugt wird eine Infrastruktur der Banknotenherstellung verwendet. In den optionalen Schritten 207 und 208 können der RDS und der signierte RDS erzeugt werden, sollte dies noch nicht in den Schritten
203 und 204 erfolgt sein. Nicht dargestellt ist eine Zwischenspeicherung des Münzdatensatzes C im Münzspeicher 170 der Herausgeberinstanz 1. Im Schritt 209 wird der erzeugte elektronische Münzdatensatz C an eine anfordemde (Schritt 101) Teilnehmereinheit TE oder eine Bankinstanz 4 ausgegeben. Im optionalen Schritt 104 wird der Münzdatensatz C in dem Münzregister 2 registriert, beispielsweise durch Übermittlung des RDS und/oder des signierten RDS.
Fig. 5 zeigt eine Datenstruktur für ein Münzregister 2 der vorhergehenden Figuren. In der Fig. 5 sind Daten des Münzregisters 2 zur Veranschaulichung dargestellt, hier sind die maskierten elektronischen Münzdatensätze Zi und ggf. ihre Verarbeitungen registriert. Das Münzregister 2 kann in einer Serverinstanz untergebracht sein. Register 2 ist bevorzugt lokal entfernt von den Teilnehmereinheiten TE angeordnet und beispielsweise in einer Server- Architektur untergebracht.
Jede Verarbeitungs-Operation für eine Verarbeitung (Erstellen, Deaktivieren, Aufteilen, Verbinden und Umschalten) wird dabei in dem Münzregister 2 registriert und dort beispielsweise in unveränderlicher Form an eine Liste vorheriger Verarbeitungs-Operationen für maskierte elektronische Münzdatensätze Zi angehängt. Die einzelnen Operationen bzw. deren Prüfergebnis, also quasi die Zwischenergebnisse einer Verarbeitung, werden in dem Münzregister 2 festgehalten. Zwar wird im Folgenden von einer sich fortsetzenden Liste ausgegangen, jedoch kann auch diese Datenstruktur, gegebenenfalls nach vorbestimmten Regeln, bereinigt oder komprimiert werden bzw. in einer bereinigten oder komprimierten Form separat bereitgestellt werden. Die Modifikationen „Erzeugen“, „Deaktivieren“, „Umschalten“, „Verbinden“ und „Aufteilen“ sind bereits in den Patentanmeldungen WO 2020/212337 Al und WO 2020/212331 Al beschrieben und es wird diesbezüglich und auch auf das Durchführen entsprechender Prüfungen darauf verwiesen. In Fig. 5 ist zudem der Eintrag im Münzregister 2 für die Modifikation „Einfrieren“ („Freeze“), auch als „Blockieren“ bezeichnet, an einem elektronischen Münzdatensatz C gezeigt, bei der ein zeitweises Deaktivieren des elektronischen Münzdatensatzes C, besser des geldwerten Betrags des elektronischen Münzdatensatzes C, veranlasst wird, ohne den geldwerten Betrag aus dem Bezahlsystem zu entfernen (zu vernichten). Hier wird ein elektronischer Münzdatensatz blockiert (eingefroren), d.h. der geldwerte Betrag ist weiterhin vorhanden, kann aber von keinem Teilnehmer - im Rahmen einer Bezahltransaktion - verwendet werden, um geldwerte Beträge au szutau sehen. Diese Modifikation „Einfrieren“ kann nicht von einer Teilnehmereinheit TE, also nicht vom Besitzer des elektronischen Münzdatensatzes C durchgeführt werden. Diese Modifikation „Einfrieren“ kann nur von einer privilegierten Instanz, beispielsweise einer Herausgeberinstanz 1 oder einer Überwachungsinstanz (nicht dem Münzregister 2) initiiert und durchgeführt werden. Diese privilegierte Instanz kann beispielsweise eine autorisierte Behörde, beispielsweise eine Strafverfolgungsbehörde oder einer Kombination aus mehreren vertrauenswürdigen Instanzen sein. So kann ein geldwerter Betrag eines Verdächtigen beschlagnahmt werden, ohne dass das Geld im Bezahlsystem BZ vernichtet wird. Bei einer „Freeze“ Aktion werden beispielsweise für einen entsprechenden maskierten elektronischen Münzdatensatz gar keine Nachfolger-Münzen in den Spalten 23 a und 23b zu den Vorgänger- Münzen 22a, 22b angegeben (bzw. dadurch, dass bisher eingetragene Münze gelöscht), wodurch der dazugehörige elektronische Münzdatensatz C bei jeder Validität- Prüfungen ungültig ist.
Zudem ist ein Eintrag im Münzregister 2 für die Modifikation bzw. Aktion „Reaktivieren“ (=Unfreeze) an einem elektronischen Münzdatensatz C gezeigt. Hierbei werden die durch eine „Freeze“ Aktion deaktivierten Münzdatensätze C wieder aktiviert (also reaktiviert). Diese Modifikation „Reaktivieren“ kann nur von einer privilegierten Instanz, beispielsweise einer Herausgeberinstanz 1 oder einer Überwachungsinstanz (nicht dem Münzregister 2) initiiert und durchgeführt werden. Diese privilegierte Instanz kann beispielsweise eine autorisierte Behörde, beispielsweise eine Strafverfolgungsbehörde oder einer Kombination aus mehreren vertrauenswürdigen Instanzen sein. So kann ein geldwerter Betrag eines Verdächtigen wieder freigegeben werden, beispielsweise nach erwiesener Unschuld des Verdächtigen. Bei einer „Reaktivieren“ Aktion werden für einen entsprechenden maskierten elektronischen Münzdatensatz neue Nachfolger-Münzen in Spalte 23 a angegeben, wodurch der elektronische Münzdatensatz bei einer Validität- Prüfungen wieder gültig ist. Das Münzregister 2 prüft bei der O-Flag Prüfung, ob eine „Einfrieren“ Aktion zuvor erfolgreich durchgeführt wurde.
In einer ersten Ausgestaltung der Fig. 6 (oberhalb der gestrichelten Trennlinie) wird eine Anfrage 210 einer Zentralbank la in der Herausgeberinstanz 1 verwendet, um einem eMDS C zu erzeugen. Dabei wird gemäß den Schritten aus dem Verfahrensablaufdiagramm des Verfahrens 200 gemäß Fig. 6 vorgegangen. Im Schritt 202 wird der eMDS C erzeugt und als Ausdruck A an die Münzausgabeeinheit 12 im Air-Gap-Prozess 206 bereitgestellt. Die Einheit 12 erhält den eMDS C und erstellt optional den RDS und den signierten RDS in den Schritten 207 und 208. Schließlich wird der RDS im Schritt 104 beim Münzregister 2 registriert. Durch die Anfrage 101 wird der eMDS C im Schritt 209 (102) an die TE1 bereitgestellt.
In einer zweiten Ausgestaltung der Fig. 6 (unterhalb der gestrichelten Trennlinie) wird die Anfrage 210 einer Zentralbank la in der Herausgeberinstanz 1 verwendet, um einem eMDS C zu erzeugen. Dazu wird die Anfrage im Schritt 201 an die Einheit 11 geleitet, bevorzugt als Air- Gap-Prozess. Dabei wird gemäß den Schritten aus dem Verfahrensablaufdiagramm des Verfahrens 200 gemäß Fig. 6 vorgegangen. In den Schritten 202, 203, 204 werden der eMDS C, der RDS und der signierte RDS erzeugt und als Ausdruck A an die Münzausgabeeinheit 12 im Air-Gap-Prozess 206 bereitgestellt. Die Einheit 12 erhält den eMDS C, den RDS und den signierten RDS. Zudem werden Metadaten MC im Schritt 205 erzeugt und im Schritt 206a der Einheit 12 bereitgestellt. Schließlich wird der RDS und der signierte RDS im Schritt 104 beim Münzregister 2 registriert. Durch die Anfrage 101 wird der eMDS C im Schritt 209 (102) an die TE1 bereitgestellt. Alternativ wird nur der signierte RDS von der Einheit 12 an das Münzregister 2 bereitgestellt und der RDS in der TE1 erzeugt und anschließend an das Münzregister 2 gesendet (gestrichelt dargestellt).
Fig. 7 zeigt noch einmal beispielhaft die jeder Teilnehmereinheit des wertbasierten Systems möglichen bekannten Schritte. Die insbesondere im Fall der Verwendung von Gleichung (3) bereitzustellenden Bereichsnachweise sind teils nicht dargestellt. Gemäß Fig. 7 wird ein neu herausgegebener, signierter maskierter elektronischer Münzdatensatz Zi im Schritt 1015 an das Münzregister 2 gesendet und der maskierte elektronischer Münzdatensatz Zi dort registriert. Den zugehörigen elektronischen Münzdatensatz Ci erhält in Schritt 102 die Teilnehmereinheit TE1. Mit den nur optionalen Schritt 103, 104 prüft die Teilnehmereinheit TE1, ob für den erhaltenen Münzdatensatz Ci ein maskierter elektronsicher Münzdatensatz registriert ist. In Schritt 103 maskiert die Teilnehmereinheit TE1 den erhaltenen elektronischen Münzdatensatzes Ci, insbesondere gemäß der Gleichung (3) oder (3-1) und sendet für den maskierten elektronischen Münzdatensatz Zi* eine Statusanfrage an das Münzregister. In Schritt 104 prüft das Register, ob der maskierte elektronische Münzdatensatz Zi* in dem Münzregister 2 als gültiger maskierter Münzdatensatz registriert ist (Zi*=Zi?) und bestätigt dies der Teilnehmereinheit TE1. Optional kann die Teilnehmereinheit TE1 den erhaltenen elektronischen Münzdatensatz umschalten. Im Schritt 105 erfolgt das Übertragen des Münzdatensatzes Ci in der Direkttransaktionsschicht 3 an die zweite Teilnehmereinheit TE2. In den optionalen Schritten 106 und 107 erfolgt wiederum eine Validitäts-Prüfung mit vorheriger Maskierung, bei der im Gutfall das Münzregister 2 die Gültigkeit des Münzdatensatzes Zi bzw. Ci bestätigt.
Im optionalen Schritt 108 erfolgt das Umschalten eines erhaltenen Münzdatensatzes Ck (es könnte natürlich auch der erhaltene Münzdatensatz Ci umgeschaltet werden) auf einen neuen Münzdatensatz Ci, wodurch der Münzdatensatz Ck ungültig wird und ein Doppeltausgeben verhindert wird. Dazu wird der monetäre Betrag Vk des übertragenen Münzdatensatzes Ck als „neuer“ monetärer Betrag verwendet. Zudem wird ein Verschleierungsbetrag n erstellt. Der zusätzliche Verschleierungsbetrag radd wird verwendet, um zu beweisen, dass kein neues Geld (in Form eines höheren monetären Betrags) von der zweiten Teilnehmereinheit TE2 generiert wurde. Dann werden die maskierten Münzdatensätze Zi und Zk in einer Umschaltanforderung an das Münzregister 2 gesendet und somit das Umschalten von Ck auf Ci beauftragt. Beispielsweise kann TE2 einen EVP entsprechend der Gleichungen 9e bis 9g generieren, um anzuzeigen, dass TE2 im Besitz der beiden Münzen Ci und Ck ist und beide monetären Beträge gleich sind. Zur Prüfung und Validierung kann TE2 sodann Zi, Zk und den EVP an das Münzregister 2 senden.
Im Schritt 108‘ erfolgt die entsprechende Prüfung in dem Münzregister 2. Das Münzregister 2 prüft, ob der umzuschaltende maskierte Münzdatensatz Zk ein registrierter maskierter Münzdatensatz ist, insbesondere ob dessen Status gültig ist, prüft ob die Umschaltaufforderung betragsneutral ist und registriert - falls beide Prüfungen positiv verlaufen sind - den neuen maskierten Münzdatensatz Zi als gültigen maskierten Münzdatensatz.
Im Einzelnen könnte dabei nur beispielhaft orientiert an der Tabelle in Fig. 7 das Folgende ablaufen. Zk wird in die Spalte 22a und in Spalte 23b der umzu schreibende Münzdatensatz Zi gemäß der Tabelle in Fig. 7 eingetragen. Es erfolgt sodann eine Prüfung in dem Münzregister 2, ob Zk (noch) gültig ist, also ob die letzte Verarbeitung von Zk in einer der Spalten 23a/b eingetragen ist (als Beweis dafür, dass Zk nicht weiter aufgeteilt oder deaktiviert oder verbunden wurde) und ob eine Prüfung für die letzte Verarbeitung fehlgeschlagen ist. Zudem wird Zi in die Spalte 23b eingetragen und die Markierungen in den Spalten 25, 26, 27 werden zunächst auf „0“ gesetzt. Nun erfolgt eine Prüfung, ob Zi gültig ist. Im Gutfall wird die Markierung in Spalte 25 auf „1“ gesetzt, ansonsten auf „0“. Nun erfolgt eine Prüfung, dass Zk und Zi betragsneutral sind und entsprechend wird die Markierung in Spalte 26 gesetzt. Weiterhin wird geprüft, ob die Bereiche schlüssig sind, sodann wird die Markierung in Spalte 27 gesetzt. Wenn alle Prüfungen erfolgreich waren, und dies entsprechend unveränderlich in dem Münzregister 2 festgehalten wurde, gilt der Münzdatensatz als umgeschaltet. D.h. der Münzdatensatz Ck ist nicht mehr gültig und ab sofort ist der Münzdatensatz Ci gültig. Ein Doppeltausgeben ist nicht mehr möglich, wenn eine dritte Teilnehmereinheit TE die Validität des (doppelt ausgegebenen) Münzdatensatz an dem Münzregister 2 und/oder dem Überwachungsregister 6 erfragt. Alternativ oder zusätzlich kann das Münzregister 2 dazu den EVP mittels Gleichungen 9h und 9i prüfen und dann Zk als gültig markieren und Zi als ungültig markieren.
Im optionalen Schritt 109 erfolgt ein Verbinden von zwei Münzdatensätzen Ck und Ci auf einen neuen Münzdatensatz Cm, wodurch die Münzdatensätze Ck, Ci ungültig werden und ein Doppeltausgeben verhindert wird. Dazu wird der monetäre Betrag nm aus den beiden monetären Beträgen Uk und ni gebildet. Dazu wird der Verschleierungsbetrag rm aus den beiden Verschleierungsbeträgen rk und n gebildet. Zudem wird mittels Gleichung (3) der maskierte zu verbindende Münzdatensatz Zm erhalten und dieser (mit anderen Informationen zusammen) an das Münzregister 2 gesendet und das Verbinden als Verarbeitung erbeten. Zudem wird eine Signatur Sk und eine Signatur Si erzeugt und dem Überwachungsregister 6 und/oder dem Münzregister 2 mitgeteilt. Beispielsweise kann TE2 einen EVP entsprechend der Gleichungen 9e bis 9g generieren, um anzuzeigen, dass TE2 im Besitz der beiden Münzen Ci und Ck ist und keine neuen monetären Beträge generiert wurden. Zur Prüfung und Validierung kann TE sodann Zmund Zi oder Zmund Zk sowie den EVP an das Münzregister 2 senden.
Im Schritt 109‘ erfolgt die entsprechende Prüfung in dem Münzregister 2. Das Münzregister 2 prüft die Gültigkeit der zu verbindenden Münzdatensätze Zk, Zi, prüft (direkt oder indirekt) ob das Verbinden betragsneutral ist (vk + Vi = vm). Falls die Prüfungen erfolgreich sind, wird Zm als gültiger maskierter Münzdatensatz registriert und der Status von Zk sowie Zi wird ungültig. Dabei kann im Einzelnen Zm in die Spalte 23b gemäß Tabelle in Fig. 7 eingetragen werden. Es erfolgt sodann eine Prüfung in dem Münzregister 2, ob Zk und Zi (noch) gültig sind, also ob die letzte Verarbeitung von Zk oder Zi in einer der Spalten 23a/b eingetragen ist (als Beweis dafür, dass Zk und Zi nicht weiter aufgeteilt oder deaktiviert oder verbunden wurden) und ob eine Prüfung für die letzte Verarbeitung fehlgeschlagen ist. Zudem werden die Markierungen in den Spalten 25, 26, 27 zunächst auf „0“ gesetzt. Nun erfolgt eine Prüfung, ob Zm gültig ist. Im Gutfall wird die Markierung in Spalte 25 auf „1“ gesetzt, ansonsten auf „0“. Nun erfolgt eine Prüfung, dass Zi plus Zk gleich Zm ist und entsprechend wird die Markierung in Spalte 26 gesetzt. Weiterhin wird geprüft, ob die Bereiche schlüssig sind, sodann wird die Markierung in Spalte 27 gesetzt. Alternativ oder zusätzlich kann das Münzregister 2 dazu den EVP mittels Gleichungen 9h und 9i prüfen und dann Zm als gültig markieren sowie Zk und Zi als ungültig markieren.
Im optionalen Schritt 110 erfolgt ein asymmetrisches Aufteilen eines Münzdatensatz Ci in zwei Münzteildatensätzen Ck und Q, wodurch der Münzdatensatz Ci ungültig gemacht wird und die beiden asymmetrisch geteilten Münzteildatensätze Ck und Q gültig gemacht werden sollen. Bei einem asymmetrischen Aufteilen wird der monetären Betrag Ui in verschieden große monetäre Teilbeträge Uk und Uj aufgeteilt. Dazu wird der Verschleierungsbetrag n in die beiden Verschleierungsbeträge rk und h aufgeteilt. Zudem werden mittels Gleichung (3) die maskierten Münzteildatensätze Zk und Zj erhalten und diese mit weiteren Informationen, beispielsweise den Bereichsprüfungen (Zero-knowledge-proofs), an das Münzregister 2 gesendet und das Aufteilen als Verarbeitung erbeten. Zudem wird eine Signatur Si erstellt und an das Münzregister 2 gesendet. Beispielsweise kann TE2 einen EVP entsprechend der Gleichungen 9e bis 9g generieren, um anzuzeigen, dass TE2 im Besitz der beiden Münzen Ci, Q und Ck ist und keine neuen monetären Beträge generiert wurden. Zur Prüfung und Validierung kann TE sodann Ziund Zj oder Zi und Zk sowie den EVP an das Münzregister 2 senden.
Im Schritt 110‘ erfolgt die entsprechende Prüfung in dem Münzregister 2. Das Münzregister 2 prüft die Gültigkeit des aufzuteilenden Münzdatensatzes Zi und prüft (direkt oder indirekt) ob das Aufteilen betragsneutral ist (vk + Vj = Vi). Falls die Prüfungen erfolgreich sind, werden Zk und Zj als gültige maskierte Münzdatensätze registriert und der Status von Zi wird ungültig. Dabei kann im Einzelnen Zj und Zk in die Spalten 23a/b gemäß Tabelle in Fig. 7 eingetragen werden. Es erfolgt sodann eine Prüfung in dem Münzregister 2, ob Zi (noch) gültig ist, also ob die letzte Verarbeitung von Zi in einer der Spalten 23a/b eingetragen ist (als Beweis dafür, dass Zi nicht weiter aufgeteilt oder deaktiviert oder verbunden wurde) und ob eine Prüfung für die letzte Verarbeitung fehlgeschlagen ist. Zudem werden die Markierungen in den Spalten 25, 26, 27 zunächst auf „0“ gesetzt. Nun erfolgt eine Prüfung, ob Zj und Zk gültig sind, wobei dabei die Prüfung gemäß Gleichungen (16) und (17) verwendet werden können. Im Gutfall wird die Markierung in Spalte 25 auf „1“ gesetzt. Nun erfolgt eine Prüfung, die Berechnung gemäß Gleichung (10) ergibt, dass Zi gleich Zk plus Zj ist und entsprechend wird die Markierung in Spalte 26 gesetzt. Weiterhin wird geprüft, ob die Bereiche schlüssig sind, sodann wird die Markierung in Spalte 27 gesetzt. Beim Prüfen der Signatur kann geprüft werden, ob die zweite Teilnehmereinheit TE2 einen Grenzwert für monetäre Beträge überschritten hat. Die Prüfung erfolgt im Hinblick auf eine Zeiteinheit, beispielsweise könnte ein Tagesgrenzwert damit überwacht werden. Alternativ oder zusätzlich kann das Münzregister 2 dazu den EVP mittels Gleichungen 9h und 9i prüfen und dann Zi und Zj als gültig markieren sowie Zk als ungültig markieren.
In Fig. 9 ist ein beispielhaftes Deaktivieren gezeigt. Dabei wird vom TE1 eine Deaktivieren - Aufforderung 111 an die Münzausgabe-Einheit 12 gesendet. Die Münzausgabeeinheit 12 erstellt eine Lösch- Aufforderung 212 und sendet diese an das Münzregister 2, um den RDS zur zu deaktivierenden eMDS C zu löschen. Der monetäre Betrag des eMDS C wird auf einem Konto des Teilnehmers gutgeschrieben.
In Fig. 10 ist ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines Verfahrens 400 zum Registrieren 104 eines Münzdatensatzes innerhalb einer atomaren Austauschprozedur zwischen den unterschiedlichen Systemen gezeigt. Die Schritte der Fig. 10 sind auch in der Fig. 11 gezeigt und werden mit der Fig. 11 zusammen beschrieben.
In Fig. 11 ist ein Verfahrensablaufdiagramm für ein erfindungsgemäßes Verfahren 400 dargestellt. Das Verfahren 400 bildet ein atomares Austauschverfahren zwischen TE1 und TE2 ab, bei dem TE2 einen Datensatz aus einem anderen System als dem Bezahlsystem BZ mit einem eMDS C des BZ des TE2 austauschen möchte. Das Bezahlsystem BZ ist ein wertbasiertes System, insbesondere der bisher beschriebenen Art. Das andere System Sys2 ist ein anderes Bezahlsystem und unterstützt - vorzugsweise als zugangsbasiertes System - Smart Contracts, beispielsweise kann es ein System zum Austausch einer Kryptowährung, wie BitCoin, Lightning, LiteCoin etc., sein. Der Einfachheit halber wird für Fig. 11 angenommen, dass das andere System ein Bitcoin-Blockchain System ist.
Folgende Annahmen werden getroffen: TE2 hat Bitcoins und TE1 hat eMDS (=C). TE2 möchte Bitcoins an TE1 senden und im Gegenzug einen C von TE1 erhalten. TE2 hat dazu ein BitCoin - Wallet mit einem Bitcoin und möchte den eMDS C von TE1 in seinen CBDC-Datenspeicher empfangen. TE1 und TE2 sind demnach beide dazu eingerichtet, in beiden Systemen Sys2, BZ, Transaktionen durchzuführen. TE1 hat C und möchte gern dafür Bitcoin von TE1 haben. Der Einfachheit halber wird angenommen, dass TE1 (nur) eine C hat und TE2 (nur) einen Bitcoin, die gegenseitig getauscht werden sollen.
Es ist erfindungsgemäß nicht ausgeschlossen, dass einer oder beide Teilnehmereinheiten eine Mehrzahl von eMDS C und/oder Datensätzen (wie BitCoin) aufweist und im Rahmen des atomic swaps eine Mehrzahl von eMDS C des Bezahlsystems und/oder Datensätzen des anderen Systems austauscht.
Es wird folgendes atomares Austauschverfahren zwischen den unterschiedlichen Systemen durchgeführt:
Das atomare Austauschverfahren zeigt mit den Schritten 401-403 das Erzeugen und Einbringen eines HTLC-gesicherten Datensatzes (der Bitcoin von TE2) im anderen System Sys2 (=Fremdsystem, nicht das Bezahlsystem BZ). Dies kann auch als Einrichten-Phase bezeichnet werden.
In den Schritten 404 bis 409 erfolgt das Registrieren 104 eines neuen elektronischen Münzdatensatzes (der eMD von TE1) in dem Münzregister 2. Dies kann auch als Registrieren - Phase bezeichnet werden und ist vorrangig Teil dieser Anmeldung.
Hier erfolgt zuerst das Einrichten durch die TE2 und anschließend das Registrieren durch TE1. Das Vertauschen der Reihenfolge von „Einrichten“ und „Registrieren“ ist nicht völlig ausgeschlossen, sodass auch TE1 den atomaren Austausch initiieren kann. Die gezeigte Reihenfolge erhöht jedoch die Sicherheit der Lösung.
In den Schritten 410 bis 418 wird der Austausch (inklusive SWAP) durchgeführt, die eMD wechselt den Besitzer von TE1 zu TE2 in Schritt 410, nach diversen Prüfungen legt TE2 in Schritt 414 den Urbild-Datensatz zum Entsichern des HTLC-gesicherten Datensatzes im Münzregister 2 offen. Sodann kann TE1 den HTLC-gesicherten Datensatz entsichern und auf sich gutschreiben (Redeem).
Die Schritte 401 bis 418 sind an definierte Zeitspannen TI und T2 gekoppelt.
Nun folgt eine detaillierte Beschreibung der Fig. 11:
Im Schritt 401 erzeugt TE2 dazu ein Geheimnis, auch als Urbild oder pre-image bezeichnet. Dieses Geheimnis ist zunächst dem TE1 unbekannt und ist eine Datenbasis für eine Streu Wertberechnung über das Urbild durch TE2. Der Streuwert H ist beispielsweise mittels Streu wertfunktion sha256 über das Urbild berechnet. Zudem definiert TE2 eine Zeitspanne TI. Der Streuwert H und die Zeitspanne TI bilden die Grundlage für einen Hash Timelock contract, kurz HTLC.
Im Schritt 402 erzeugt die TE2 eine Bitcoin Transaktion - nachfolgend auch Datensatz genannt. Diesem BitCoin-Datensatz wird der HTLC hinzugefügt, wodurch der Bitcoin mit dem HTLC verschlossen (=gesichert) ist. Der HTLC sichert den Datensatz derart ab, dass ein Empfänger des Datensatzes das Urbild des Streuwerts H benötigt, um den Datensatz bestimmungsgemäß verwenden zu können. Zudem ist die Zeitdauer TI dazu vorgesehen, dass TE2 den Datensatz wieder bestimmungsgemäß verwenden kann, wenn binnen der Zeitdauer TI keine Entsicherung mittels Urbildes von einer anderen TE erfolgt, der Datensatz also nicht mittels Urbildes eingelöst worden ist.
Im Schritt 403 wird der erstellte Datensatz (Bitcoin, Smart contracts, cryptocurrency) in einem System Sys2, einem System, dass nicht das Bezahlsystem BZ ist, eingebracht. Beispielsweise ist Sys2 eine Blockchain-Architektur, der Datensatz wird in einem Knoten, Sys2-Node, bestätigt („commited“). Das dem Datensatz zugefügte HTLC bedingt, dass TE1 das Geheimnis (Urbild) kennen muss, um den Datensatz im Sys2 zu entsichern und den Datensatz auf sich gutschreiben („redeem“) zu können.
In der Schrittabfolge 404 wird der Hashwert H und die Zeitdauer TI des HTLC des Datensatzes des Sys2 durch die TE1 beim Sys2 abgefragt bzw. erhalten. Dabei kann ein Anfrage-Antwort Schema verwendet werden, dass durch eine Authentisierung und ggf. eine verschlüsselte Übertragung zusätzlich abgesichert ist.
Im Schritt 405 erzeugt TE1 einen ersten elektronischen Münzdatensatz Ck und einen zweiten elektronischen Münzdatensatz Q aus einem vorhandenen Münzdatensatz Ci. Alternativ wird nur ein elektronischer Münzdatensatz Q aus einem vorhandenen Münzdatensatz Ci erzeugt. Weiterverfolgt soll in Fig. 11 die Alternative mit zwei erzeugten elektronischen Münzdatensätzen Ck und Q werden. Für Ci, Ck und Q gelten die folgenden drei Bedingungen:
Ui = Uk = Uj Ui > 0 n ungleich h ungleich rk.
Im Schritt 406 werden nach Gleichungen (9e) bis (9g) die optionalen EVPj-k und EVPi-k errechnet und eine Zeitdauer T2 definiert. Die Zeitdauer T2 ist beispielsweise einige Tage, bevorzugt 3 Tage. Die Zeitdauer T2 muss enden, bevor die Zeitdauer TI endet, beispielsweise beträgt TI = 2 x T2. Im Schritt 406 werden Zi (falls noch nicht vorhanden), Zk und Zj berechnet.
Im Schritt 407 wird eine neuartige Registrierungsaufforderung gesendet. Diese Aufforderung kann im System BZ auch als SWAP-Befehl bezeichnet werden. Das Münzregister 2 empfängt folgende Elemente: Zi, Zj optional mit EVPi-j und Zeitdauer T2 sowie Zk optional mit EVPi-k und dem Hashwert H vom HTLC des Sys2. Dabei ist Zj mit der Zeitdauer T2 gesichert (timelock) und Zk ist mit dem Hashwert H gesichert (hashlock), sodass im Ergebnis eine Registrierungsaufforderung mit HTLC an das Münzregister 2 übertragen wird.
In der nicht dargestellten Alternative mit nur einem erzeugten elektronischen Münzdatensatz Ck, wird im Schritt 407 der maskierte Münzdatensatz Zj mit dem Streuwert H gesichert (Hashlock) und die Registrieraufforderung wird als (um die Zeitspanne T2) zeitverzögertes Umschalte - Kommando interpretiert. Entweder löst TE2 den Hashlock am Zj auf, indem er den Urbild- Datensatz dem Münzregister 2 offenlegt, oder die um die Zeitspanne T2 zeitverzögerte Umschaltung von Zj zurück auf Zi für die TE1 erfolgt durch das Münzregister 2, weil die Zeitspanne T2 abgelaufen ist. Je nachdem was zuerst eintritt, wird entweder ein SWAP ausgeführt oder ein Urzustand wiederhergestellt.
Im Schritt 408 überprüft das Münzregister 2 die Registrierungsaufforderung (=SWAP). Dazu werden durch das Münzregister 2 bis zu fünf Verifizierungen durchgeführt:
1: EVPi-j wird aus Zi und Zj verifiziert (optional),
2: EVPi-k wird aus Zi und Zk verifiziert (optional),
3: Es wird verifiziert, dass Zi existiert und gültig ist,
4: Es wird verifiziert, dass Zk und Zj den gleichen Betrag wie Zi enthalten, und optional dass sie (noch) nicht existieren; und
5: Es wird verifiziert, dass die Zeitspanne T2 in der Zukunft liegt.
Sind alle bis zu fünf Verifizierungen erfolgreich durchgeführt worden, dann wird: 1 : Zi als ungültig markiert,
2: Zj und Zk gesichert in das Münzregister 2 eingetragen (Timelock & Hashlock),
3: Eine Bestätigung „OK“ im Schritt 409 an die TE1 gesendet.
Ist eine der bis zu fünf Verifizierungen nicht erfolgreich, dann wird eine Fehlermeldung an TE1 gesendet. Der atomic swap wird dann vorzugsweise abgebrochen. Nach Ablauf der Zeitspanne T2 wird Zj auf TE1 umgeschaltet (oder auf SWITCH-Kommando vom TE1). Nach Ablauf der Zeitspanne TI wird der Datensatz in Sys2 wieder an TE2 zurückgeschrieben.
Mit dem Schritt 409 sind alle Vorbereitungen für einen atomic SWAP abgeschlossen, TI, T2 sind definiert, H ist in TE1 bekannt, der Datensatz des Fremdsystems Sys2 ist mit HTLC gesichert im Sys2 und Zi und Zk sind gesichert in das Münzregister 2 eingetragen (Timelock & Hashlock). Nochmal der Hinweis: In einer alternativen (nicht dargestellten) Ausführung, wird nur Zj in das Münzregister 2 eingetragen und über einen mit Zeitspanne T2 zeitverzögertes Umschalten kann der Urzustand wieder hergestellt werden. Dieser Umschaltbefehl kann von TE1 generiert werden mit Schritt 407 oder der Schritt 407 wird als zeitverzögertes Umschalten vom Münzregister 2 interpretiert.
Ab dem Schritt 410 erfolgt das eigentliche Austauschen (SWAP).
Zunächst überträgt TE1 an TE2 im Schritt 410 den Münzdatensatz Q. Im Schritt 411 prüft TE2 die Korrektheit des monetären Betrags von Q.
Im Schritt 412 fragt TE2 am Münzregister 2 die Verfügbarkeit von Zk ab und prüft, ob der Hash H des Zk dem Hash H vom Datensatz entspricht. Zudem prüft TE2, ob das Ende der Zeitspanne T2 noch in der Zukunft liegt.
Sind alle Prüfungen in den Schritten 411 und 412 erfolgreich, erzeugt TE2 im Schritt 413 einen elektronischen Münzdatensatz Cm mit Uk = r>m und n ungleich rm. Zudem wird ein Zm errechnet und optional im Schritt 413 nach Gleichungen (9e) bis (9g) der EVPk-m errechnet.
Im Schritt 414 sendet TE2 eine Registrierungsaufforderung (auch als REDEEM bezeichnet) an das Münzregister 2 mit Zm, (ggf. EVPk-m) und dem Urbild-Datensatz aus Schritt 401.
Im Schritt 415 überprüft das Münzregister 2 die Registrierungsaufforderung (=REDEEM). Dazu werden durch das Münzregister 2 bis zu drei Verifizierungen durchgeführt:
1: EVPk-m wird aus Zk und Zm verifiziert (optional), 2: Es wird verifiziert, dass Zk existiert und mit dem Hashwert H gesichert ist (hashlock),
3: Es wird verifiziert, dass bei Anwendung der Streu wertfunktion (gleich der Streu wertfunktion aus Schritt 401) aus dem Urbild-Datensatz von TE2 der Hashwert H wird, der das Zk sichert.
Sind alle bis zu drei Verifizierungen im Schritt 415 erfolgreich durchgeführt worden, dann wird:
1 : Zj und Zk als ungültig markiert,
2: Zm in das Münzregister 2 eingetragen (ungesichert),
3: Der Urbild-Datensatz im Münzregister 2 veröffentlicht,
3: Ein „OK“ im Schritt 415a an die TE2 gesendet.
Ist eine der bis zu drei Verifizierungen im Schritt 415 nicht erfolgreich, dann wird eine Fehlermeldung an TE2 gesendet, der atomic swap wird abgebrochen. Nach Ablauf der Zeitspanne T2 wird Zj auf TE1 umgeschaltet (oder auf SWITCH-Kommando vom TE1). Nach Ablauf der Zeitspanne TI wird der Datensatz in Sys2 wieder an TE2 zurückgeschrieben.
Im Schritt 416 fragt die TE1 den Urbild-Datensatz von dem Münzregister 2 ab. Die Abfrage kann durch Authentisierung oder Verschlüsselungen weiter abgesichert sein.
Im Schritt 417 verwendet die TE1 den Urbild-Datensatz, um den HTLC-gesicherten Datensatz des Fremdsystems Sys2 zu entsichern und den Bitcoin auf sich gutschreiben zu lassen.
Ist eine der Prüfungen in den Schritten 411 und 412 nicht erfolgreich, so verweigert die TE2 das Offenlegen des Urbild-Datensatzes aus dem Schritt 401. Damit ist der atomic swap gescheitert. Nach der Zeitspanne T2 sendet TE1 im Schritt 420 ein Umschalt- Kommando, um Zj auf TE2 umzuschalten, woraufhin Zk automatisch invalidiert wird. Selbst wenn TE2 den Urbild- Datensatz veröffentlicht, kann dann Zk nicht validiert werden. Alternativ (nicht dargestellt) wird nach Ablauf von T2 ein automatischer Switch im Münzregister 2 auf Zi durchgeführt, um den Urzustand wieder herzustellen. Nach Ablauf der Zeitspanne TI kann TE2 im Schritt 421 den Bitcoin aus Sys2 wieder auf sich gutschreiben lassen.
Im Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/oder beanspruchten Elemente beliebig miteinander kombiniert werden. BEZUGSZEICHENLISTE
BZ Bezahlsystem
1 Herausgeberinstanz,
11 Münzgenerierung (Münzgenerator)
12 Münzausgabe
13 Prüfeinheit 14, 14’ Air Gaps
15 Empfangseinheit
16 Münzeinlese-Einheit
17 Datenspeicher la Zentralbank, CB,
2 Münzregister
21 Befehls-Eintrag
22a, b Eintrag eines zu verarbeitenden elektronischen Münzdatensatzes (Vorgänger) 23a, b Eintrag eines verarbeiteten elektronischen Münzdatensatzes (Nachfolger)
24 Signatur-Eintrag
25 Markierung der Gültigkeitsprüfung
26 Markierung der Betrags-Berechnungsprüfung
27 Markierung der Bereichsnachweisprüfung
28 Markierung der Signatur-Prüfung
29 Abschluss-Markierung
3 Direkttransaktions Schicht
4 Bankinstanz
Ai Ausdruck repräsentierend einen elektronischen Münzdatensatz
MCi Metadaten über den elektronischen Münzdatensatz M-ID Münzkennung des elektronischen Münzdatensatzes Ci elektronischer Münzdatensatz,
Co elektronischer Stamm-Münzdatensatz
Cj, Ck aufgeteilter elektronischer Münzteildatensatz,
Cj k k-ter aufgeteilter elektronischer Münzteildatensatz bei symmetrischer Aufteilung
Ci umzu schaltender elektronischer Münzdatensatz
Cm zu verbindendender elektronischer Münzdatensatz
Ci* übertragener elektronischer Münzdatensatz
Cj *, Ck * übertragener aufgeteilter elektronischer Münzteildatensatz,
Mx x-tes Gerät SEx x-tes Sicherheitselement TEx x-te Teilnehmereinheit RDSi Registerdatensatz RDSo Stamm-Registerdatensatz
[RDSi]Sig(PKi) Signatur der Herausgeberinstanz (Münzgenerierung)
PKi Privater Schlüsselteil der Herausgeberinstanz f(C) Einwegfunktion Ui, Monetärer Betrag u0 Monetärer Stamm-Betrag des elektronischen Stamm-Münzdatensatzes
Dj, Uj Aufgeteilter monetärer Betrag ui, Monetärer Betrag eines umzuschaltenden/umgeschalteten elektr. Münzdatensatzes nm, Monetärer Betrag eines zu verbindenden/verbundenen elektr. Münzdatensatz pi, Zählerwert für Alterung des Münzdatensatzes k Zufallszahl für EVP n Verschleierungsbetrag, Zufallszahl r0 Stamm-Verschleierungsbetrag, Zufallszahl des Stamm-Münzdatensatzes, h, ij Verschleierungsbetrag eines aufgeteilten elektronischen Münzdatensatzes rm Verschleierungsbetrag eines zu verbindenden elektronischen Münzdatensatzes
Zi maskierter elektronischer Münzdatensatz
Zi* maskierter übertragener elektronischer Münzdatensatz
Zj, Zk maskierter aufgeteilter elektronischer Münzteildatensatz
Zj *, Zk *maskierter übertragener aufgeteilter elektronischer Münzdatensatz
Zi maskierter umzu schaltender elektronischer Münzdatensatz
Zm maskierter zu verbindender elektronischer Münzdatensatz
101-111 Verfahrensschritte des Bezahlsystems gemäß einem Ausführungsbeispiel
201-212 Verfahrensschritte der Herausgeberinstanz gemäß einem Ausführungsbeispiel
301-311 Verfahrensschritte im Bezahlsystem gemäß einem Ausführungsbeispiel
401-421 Verfahrensschritte im Bezahlsystem gemäß einem Ausführungsbeispiel

Claims

PATENTANSPRÜCHE
1. Ein Verfahren (400) zum Registrieren (104) eines elektronischen Münzdatensatzes (C) in einem Münzregister (2) eines elektronischen Bezahlsystems (BZ) mit den Verfahrensschritten:
Erzeugen (405), durch eine erste Teilnehmereinheit (TE1) des Bezahlsystems (BZ), eines elektronischen Münzdatensatzes (Q) aufweisend einen monetären Betrag (nj) und einen Verschleierungswert (h), wobei der monetäre Betrag (nj) des erzeugten elektronischen Münzdatensatzes (Q) einem monetären Betrag (Di) eines in der ersten Teilnehmereinheit (TE1) vorhandenen elektronischen Münzdatensatzes (Ci) entspricht;
Maskieren (406), durch die erste Teilnehmereinheit (TE1), des erzeugten elektronischen Münzdatensatzes (Q) durch Anwenden einer Einwegfunktion (f(C)) auf mindestens ein Datenelement des elektronischen Münzdatensatzes (Q) zum Erhalten eines maskierten erzeugten elektronischen Münzdatensatzes (Zj);
Senden einer Registrierungsaufforderung (407) für den maskierten erzeugten elektronischen Münzdatensatz (Zj) von der ersten Teilnehmereinheit (TE1) an das Münzregister (2) zusammen mit einer Zeitsicherung, wobei die Zeitsicherung eine Zeitdauer (T2) vorgibt, bis zu der eine zweite Teilnehmereinheit (TE2) des Bezahlsystems (BZ) den erzeugten elektronischen Münzdatensatz (Q) im Münzregister (2) auf sich umschalten kann.
2. Das Verfahren (400) nach Anspruch 1, wobei das Registrieren (104) des elektronischen Münzdatensatzes (Q) ein Teil eines atomaren Austauschverfahrens ist.
3. Das Verfahren (400) nach Anspruch 1 oder 2, wobei die Registrierungsaufforderung (407) eine Austausch- Aufforderung ist, um den erzeugten elektronischen Münzdatensatz (Q) von der ersten Teilnehmereinheit (TE1) gegen einen Datensatz aus einem anderen System (Sys2) als dem Bezahlsystem (BZ) von der zweiten Teilnehmereinheit (TE2) au szutau sehen.
4. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei die erste Teilnehmereinheit (TE1) den erzeugten elektronischen Münzdatensatz (Q) direkt an die zweite Teilnehmereinheit (TE2) überträgt, wenn die erste Teilnehmereinheit (TE1) eine Registrierungsbestätigung (409) von dem Münzregister (2) erhalten hat.
5. Das Verfahren (400) nach Anspruch 4, wobei vor dem Senden der Registrierungsbestätigung (409) an die erste Teilnehmereinheit (TE1) das Münzregister (2) verifiziert, dass der maskierte erzeugte elektronische Münzdatensatz (Zj) noch nicht im Münzregister (2) registriert ist und dass das Münzregister (2) den maskierten erzeugten Münzdatensatz (Zj) zeitgesichert registriert, wobei die Zeitsicherung automatisch aufgehoben ist, wenn die Zeitdauer (T2) abgelaufen ist.
6. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei mit der Registrierungsaufforderung (407) eine verzögerte Umschaltaufforderung (108) von der ersten Teilnehmereinheit (TE1) an das Münzregister (2) übertragen wird oder wobei die Registrierungsaufforderung (407) auch eine verzögerte Umschaltaufforderung (108) ist, aufgrund dessen das Münzregister (2) den maskierten erzeugten Münzdatensatz (Zj) automatisch auf die erste Teilnehmereinheit (TE1) umschaltet (108), wenn die Zeitdauer (T2) abgelaufen ist.
7. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei vor dem Senden - Schritt (407) die erste Teilnehmereinheit (TE1) einen Streuwert (H) aus einem Datensatz aus einem anderen System (Sys2) als dem Bezahlsystem (BZ) empfängt und die erste Teilnehmereinheit (TE1) den maskierten erzeugten elektronischen Münzdatensatz (Zj) mit dem Streuwert (H) streuwertsichert, sodass das Münzregister (2) den maskierten erzeugten Münzdatensatz (Zj) streuwertgesichert registriert.
8. Das Verfahren (400) nach Anspruch 7, wobei vor dem Senden-Schritt (407) die erste Teilnehmereinheit (TE1) zudem eine Zeitdauer (TI) aus dem Datensatz des anderen Systems (Sys2) empfängt, wobei die Zeitdauer (TI) aus dem Datensatz des anderen Systems (Sys2) eine Zeitspanne vorgibt, bis zu der die erste Teilnehmereinheit (TE1) den Datensatz aus dem anderem System (Sysl) für sich einlösen kann.
9. Das Verfahren (400) nach Anspruch 8, wobei die erste Teilnehmereinheit (TE1) die Zeitdauer (T2) für die Registrierungsaufforderung (407) derart wählt, dass sie vor dem Ablauf der Zeitdauer (TI) aus dem Datensatz des anderen Systems (Sys2) abläuft, wobei bevorzugt die Zeitdauer (T2) der Registrierungsaufforderung (407) ungefähr die Hälfte der Zeitdauer (TI) zwischen Empfang der Zeitdauer (TI) aus dem Datensatz des anderen Systems (Sys2) und dem Ablauf der Zeitdauer (TI) aus dem Datensatz des anderen Systems (Sys2)ist.
10. Das Verfahren (400) nach einem der Ansprüche 1 bis 9, wobei die zweite Teilnehmereinheit (TE2) den erzeugten elektronischen Münzdatensatz (Q) direkt von der ersten Teilnehmereinheit (TE1) empfängt und wobei die zweite Teilnehmereinheit (TE2) prüft, ob der maskierte erzeugte elektronische Münzdatensatz (Zj) im Münzregister (2) mit dem Streuwert (H) streuwertgesichert ist.
11. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, mit den weiteren Verfahrensschritten:
Erzeugen (413), durch die zweite Teilnehmereinheit (TE2), eines elektronischen Münzdatensatzes (Cm) aufweisend einen monetären Betrag (nm) und einen Verschleierungswert (rm), wobei der monetäre Betrag (nm) des erzeugten elektronischen Münzdatensatzes (Cm) dem monetären Betrag (i)j) des von der der ersten Teilnehmereinheit (TE1) empfangenen elektronischen Münzdatensatzes (Q) entspricht;
Maskieren, durch die zweite Teilnehmereinheit (TE2), des erzeugten elektronischen Münzdatensatzes (Cm) durch Anwenden der Einwegfunktion (f(C)) auf mindestens ein Datenelement des elektronischen Münzdatensatzes (Cm) zum Erhalten des maskierten erzeugten elektronischen Münzdatensatzes (Zm);
Senden einer Registrierungsaufforderung (415) für den maskierten erzeugten elektronischen Münzdatensatz (Zm) von der zweiten Teilnehmereinheit (TE2) an das Münzregister (2) zusammen mit einem Urbild-Datensatz, wobei der Urbild-Datensatz auch die Basis für den Streuwert (H) in dem Datensatz aus dem anderem als dem Bezahlsystem (Sys2) ist, wobei das Senden innerhalb der Zeitdauer (T2) der Zeitsicherung erfolgt.
12. Das Verfahren (400) nach Anspruch 11, wobei das Münzregister (2) den maskierten erzeugten elektronischen Münzdatensatz (Zm) auf die zweite Teilnehmereinheit (TE2) registriert (104), wenn ein Streuwert über den Urbild-Datensatz mit dem mit dem Streuwert (H) streuwertgesicherten maskierten elektronischen Münzdatensatz (Zj) des Münzregisters (2) übereinstimmt und wenn die Zeitdauer (T2) der Zeitsicherung des maskierten erzeugten elektronischen Münzdatensatzes (Zj) noch nicht abgelaufen ist.
13. Das Verfahren (400) nach einem der vorhergehenden Ansprüche 11 oder 12, wobei die erste Teilnehmereinheit (TE1) den Urbild-Datensatz von dem Münzregister (2) abfragt, um den Datensatz aus dem anderen System (Sys2) als dem Bezahlsystem (BZ) zu empfangen.
14. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei das Senden der Registrierungsaufforderung (407) eine Mehrzahl von maskierten erzeugten elektronischen Münzdatensätzen von der ersten Teilnehmereinheit (TE1) umfasst, wobei für jede der maskierten erzeugten elektronischen Münzdatensätze (Z) die gleiche Zeitsicherung, bevorzugt auch die gleiche Streuwertsicherung durch einen Streuwert (H) aus einem Datensatz aus einem anderen System (Sysl) als dem Bezahlsystem (BZ), verwendet wird.
15. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei das Münzregister (2) jeden maskierten elektronischen Münzdatensatz (Z) als registrierten Registerdatensatz (RDS) registriert.
16. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei vor dem Erzeugen- Schritt (405) die folgenden Schritte durchgeführt werden:
Empfangen (102, 105) des elektronischen Münzdatensatzes (Ci) von einer
Herausgeberinstanz (1) und/oder einer anderen Teilnehmereinheit (TE); und Abfragen eines Registerdatensatzes (RDSi) zu dem empfangenen elektronischen
Münzdatensatz (Ci) bei dem Münzregister (2).
17. Das Verfahren (400) nach Anspruch 16, wobei erst bei Vorhandensein eines
Registerdatensatzes (RDSi) zu diesem elektronischen Münzdatensatz (Ci), das Verfahren gemäß der Ansprüche 1 bis 16 durchgeführt wird.
18. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei die
Verfahrensschritte, die in einer Teilnehmereinheit (TE) durchgeführt werden, in einer gesicherten Laufzeitumgebung, beispielsweise einem Sicherheitselement (SE) der jeweiligen Teilnehmereinheit (TE), durchgeführt werden.
19. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei die Zeitdauer (T2) in der Registrierungsaufforderung (407) nur einige Tage, bevorzugt 3 Tage ist, wobei die Zeitdauer (TI) in dem Datensatz des anderen Systems (Sys2), bevorzugt 7 Tage ist.
20. Das Verfahren (400) nach einem der vorhergehenden Ansprüche, wobei der Streuwert (H) mittels einer Streuwertfunktion in der zweiten Teilnehmereinheit (TE2) errechnet wurde, wobei als Basis ein geheimer Urbild-Datensatz in der zweiten Teilnehmereinheit (TE2) generiert (401) wurde.
21. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei in dem Schritt des Maskierens eine homomorphe Einwegfunktion angewandt wird; und/oder
- der Verschleierung s wert ein Verschleierungsbetrag ist, wobei die Einwegfunktion zumindest auf den Geldbetrag (v), vorzugsweise auf den Geldbetrag (v) und den Verschleierungsbetrag (r) angewandt wird,
- in dem Schritt des Maskierens aus dem Verschleierungswert (r) ein maskierter Verschleierungswert (R) erzeugt wird, wobei der maskierte elektronische Münzdatensatz (Z) den Geldbetrag (v) und den maskierten Verschleierungswert (R) als Datenelemente umfasst.
22. Münzregister (2) zum Registrieren von Registerdatensätzen (RDS), insbesondere maskierten elektronischen Münzdatensätzen (Z), in einem elektronischen Bezahlsystem (BZ), mit: einer Datenschnittstelle, eingerichtet zum Empfangen von Status- und/oder Registrieranforderungen und zum Senden von Registerstatus bezüglich Registerdatensätzen (RDS) des Bezahlsystems (BZ) gemäß einem der vorhergehenden Ansprüche.
23. Das Münzregister (2) nach Anspruch 22, wobei das Münzregister (2) eingerichtet ist zum:
Empfangen eines Urbild-Datensatzes von einer Teilnehmereinheit (TE); Anwenden einer Streu wertfunktion auf den Urbild-Datensatz zum Erzeugen eines Streu werts;
Vergleichen des erzeugten Streuwerts mit einem zuvor empfangenen Streuwerts (H); und Registrieren (104) eines mittels dem Streuwert streuwertgesicherten Registerdatensatz (RDS) in dem Münzregister (2).
24. Das Münzregister (2) nach Anspruch 22 oder 23, weiter aufweisend eine Prüfeinheit zum Prüfen der Gültigkeit von den Registerdatensätzen (RDSi) entsprechenden elektronischen Münzdatensätzen (Ci).
25. Ein Bezahlsystem (BZ) zum Bezahlen mit elektronischen Münzdatensätzen (C) mit: einem Münzregister (2), eingerichtet zum Registrieren (104) der elektronischen
Münzdatensätze (C) gemäß einem der vorhergehenden Verfahrensansprüche; Teilnehmereinheiten (TE1, TE2), eingerichtet zum:
Ausführen von Bezahltransaktionen durch Übertragen (105) der elektronischen Münzdatensätze (C) und zum Senden von Status- und/oder Registrierungsaufforderungen (407) betreffend die elektronischen Münzdatensätze (C) gemäß einem der vorhergehenden Verfahrensansprüche; und
Ausführen von Transaktionen durch Übertragen von Datensätzen in einem anderen System (Sys2) als dem Bezahlsystem (BZ) gemäß einem der vorhergehenden V erfahrensansprüche .
26. Das Bezahlsystem (BZ) nach Anspruch 25, wobei das Münzregister (2) eingerichtet ist zu Registrieren (104) des elektronischen Münzdatensatzes (C) als ein Teil eines atomaren Austauschverfahrens, wobei eine Registrierungsaufforderung (407) eine Austausch- Aufforderung ist, um den erzeugten elektronischen Münzdatensatz (C) von der ersten Teilnehmereinheit (TE) gegen einen Datensatz aus einem anderen System (Sysl) als dem Bezahlsystem (BZ) von der zweiten Teilnehmereinheit (TE2) auszutauschen.
27. Eine Teilnehmereinheit (TE1), eingerichtet zum direkten Übertragen von elektronischen Münzdatensätzen (Ci) an eine andere Teilnehmereinheit (TE2, TE3) in einem elektronischen Bezahlsystem (BZ) und eingerichtet zum Ausführen von Bezahltransaktionen durch Übertragen (105) von elektronischen Münzdatensätzen (Ci) und zum Senden von Status- und/oder Registrierungsaufforderungen (407) betreffend die elektronischen Münzdatensätze (C) an ein Münzregister (2) aufweisend:
- ein Mittel zum Zugreifen auf einen Datenspeicher (10, 10‘), wobei im Datenspeicher (10, 10‘) zumindest ein elektronischer Münzdatensatz (C) abgelegt ist;
- eine Schnittstelle zum Ausgeben des zumindest einen elektronischen Münzdatensatzes (C) an die andere Teilnehmereinheit (TEx) zum Übertragen von Status- und/oder Registrierungsaufforderungen (407) betreffend die elektronischen Münzdatensätzen (C) an das Münzregister (2); und
- eine Recheneinheit (33), eingerichtet zum Ausführen der Verfahrensschritte des Verfahrens (400) gemäß einem der Ansprüche 1 bis 21.
28. Ein Computerprogramprodukt ausführbar installiert in einer Teilnehmereinheit (TE) und aufweisend Mittel zum Ausführen der Verfahrensschritte des Verfahrens (400) gemäß einer der Ansprüche 1 bis 21.
EP22725994.2A 2021-05-03 2022-05-02 Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt Pending EP4334872A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021002329.3A DE102021002329A1 (de) 2021-05-03 2021-05-03 Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
PCT/EP2022/025198 WO2022233454A1 (de) 2021-05-03 2022-05-03 Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt

Publications (1)

Publication Number Publication Date
EP4334872A1 true EP4334872A1 (de) 2024-03-13

Family

ID=81850682

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22725994.2A Pending EP4334872A1 (de) 2021-05-03 2022-05-02 Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt

Country Status (3)

Country Link
EP (1) EP4334872A1 (de)
DE (1) DE102021002329A1 (de)
WO (1) WO2022233454A1 (de)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872844A (en) 1996-11-18 1999-02-16 Microsoft Corporation System and method for detecting fraudulent expenditure of transferable electronic assets
DE102019002732A1 (de) 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
DE102019002731A1 (de) * 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
WO2021046494A1 (en) * 2019-09-06 2021-03-11 Bosonic, Inc. System and method of providing a blockchain-based recordation process

Also Published As

Publication number Publication date
DE102021002329A1 (de) 2022-11-03
WO2022233454A1 (de) 2022-11-10
WO2022233454A8 (de) 2024-05-23

Similar Documents

Publication Publication Date Title
WO2020212331A1 (de) Gerät zum direkten übertragen von elektronischen münzdatensätzen an ein anderes gerät sowie bezahlsystem
DE102019002732A1 (de) Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
WO2022008322A1 (de) Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
DE102009038645A1 (de) Verfahren und tragbarer Datenträger zum Übertragen eines geldwerten Betrages in Form eines elektronischen Datensatzes zwischen einer ersten nichtzentralen Instanz und einer zweiten nichtzentralen Instanz
EP4111399B1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
EP4399632A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
WO2023011761A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
EP4179488A1 (de) Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem
WO2022233454A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
EP4111347B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102021000570A1 (de) Verfahren zum bereitstellen eines nachweisdatensatzes; verfahren zum prüfen eines nachweisdatensatzes; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
EP4179486A1 (de) Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
WO2023011756A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
EP4179489A1 (de) Verfahren, endgerät sowie münzregister zum übertragen von elektronischen münzdatensätzen
WO2024012624A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber
WO2023202836A1 (de) Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen
DE102009035412A1 (de) Verfahren und System zum Übertragen von geldwerten Beträgen in Form elektronischer Datensätze

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231204

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR