EP4179487A1 - Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen - Google Patents

Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen

Info

Publication number
EP4179487A1
EP4179487A1 EP21739315.6A EP21739315A EP4179487A1 EP 4179487 A1 EP4179487 A1 EP 4179487A1 EP 21739315 A EP21739315 A EP 21739315A EP 4179487 A1 EP4179487 A1 EP 4179487A1
Authority
EP
European Patent Office
Prior art keywords
register
transaction
coin
electronic coin
record
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
EP21739315.6A
Other languages
English (en)
French (fr)
Inventor
Daniel Albert
Raoul-Thomas HERBORG
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 EP4179487A1 publication Critical patent/EP4179487A1/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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • 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
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the invention relates to a method in a first subscriber unit, a method in a transaction register, a subscriber unit, a transaction register and a payment system for managing transaction data records when transmitting electronic coin data records.
  • 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.
  • FIG. 1a a payment system is shown in FIG. 1a and FIG.
  • a terminal M1 divides a coin data set C a in order to obtain a partial coin data set C b .
  • the terminal Ml passes on the coin data set C b in an unauthorized manner to the terminal M2 and M3 at the same time.
  • terminal M2 passes on coin data set C b and receives coin data set C B , which is then forwarded directly to terminal M4.
  • the terminal M4 forwards the coin data record C c directly to the terminal M6.
  • the terminal M6 forwards the coin data record C c directly to the terminal M8.
  • the unsuspecting participant with terminal M3 forwards the partial coin data set C b directly to terminal M5.
  • the terminal M3 is the Münz Scheme C b to the terminal M5 directly on.
  • the terminal M5 gives Münz Scheme C b to the terminal M7 spur. Both coin data sets C b and C c thus frequently change hands without a coin register 2 of the payment system finding out about this.
  • the exchanged coin records should be confidential to other system participants, but allow each system participant to perform basic checks on the 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, such as that a coin record should expire.
  • the object is achieved in particular by a method in a first subscriber unit, preferably a first security element, having an electronic coin data set in a coin register of a payment system is registered.
  • the method has the following method steps: generating a transaction data record relating to a transmission of the electronic coin data record to a second subscriber unit, preferably a second security element, or relating to a modification of the electronic coin data record to be registered in the coin register; Encrypting the generated transaction data record with a cryptographic key, the cryptographic key being composed of at least two cryptographic part keys, preferably at least three cryptographic part keys, each from different remote entities; and initiating a communication connection setup to a trade repository to send the encrypted transaction record to the trade repository.
  • the method according to the invention grants access to confidential information to a defined (specific) group of people, in particular enforcement authorities in criminal prosecution, in order to prevent or prosecute crimes.
  • a defined (specific) group of people in particular enforcement authorities in criminal prosecution, in order to prevent or prosecute crimes.
  • several (at least two) partial keys from different remote entities are required. This ensures the confidentiality and data integrity of the payment system.
  • this monetary amount can change from a first terminal to another terminal.
  • a monetary amount 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 example the transaction data record, for data exchange or data transfer, since, for example, a classic data transaction is based on a question-and-answer principle or on intercommunication between the data transfer partners, for example the subscriber unit and the trade repository.
  • An electronic coin data record is unique, unambiguous and stands in the context of a security concept which, for example, uses masks, signatures or may include encryption.
  • an electronic coin data record contains all the data that is required for a receiving entity with regard to verification, authentication and forwarding to other entities. Intercommunication between the terminals when exchanging data is therefore generally not necessary with this type of data set.
  • a valid electronic coin data record may only exist once in the payment system. This system requirement must be observed in particular when transferring electronic coin data sets.
  • 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 incorporated into the subscriber unit ready for operation.
  • the subscriber unit can be, for example, a mobile terminal such as a smartphone, a tablet computer, a computer, a server or a machine.
  • the electronic coin data record is transmitted from the (first) 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 path 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.
  • An application entered (installed) ready for operation on the subscriber unit can initiate and control the transmission of the coin data record 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.
  • a transaction data record is generated by the first subscriber unit, ie the subscriber unit sending the (at least one) coin data record.
  • the transaction data record includes the information that is required in order to be able to clearly identify the transmission of the coin data record between two subscriber units of the payment system in the totality of the transmissions (payment transactions).
  • the transaction data record includes in particular the subscriber units participating in the transmission and information regarding the coin data record to be transmitted. With a (decrypted) transaction data record, the transmission of the electronic coin data record can be clearly reconstructed.
  • the transaction data record has a monetary value of the electronic coin data record.
  • the transaction data record has a transaction number.
  • This transaction number is, for example, a random number generated before the generation step. A random number generator of the subscriber unit or of the security element is preferably used for this purpose.
  • the transaction number is an identification number of the transaction that is unique for transmission from the first subscriber unit.
  • the transaction number can identify the transaction in the payment system.
  • the transaction data record also has a masked electronic coin data record corresponding to the electronic coin data record to be transmitted, preferably instead of the monetary amount of the electronic coin data record or instead of the electronic coin data record.
  • the masking will be explained later.
  • the non-inclusion of the electronic coin data record enables the retention of two system requirements, namely that the electronic coin data record only exists once in the system and (and is not a copy in the transaction data record), and secondly, the possession of the electronic coin data record entitles to payment, i.e. a still non-encrypted transaction data set (possibly after transmission to the second subscriber unit) or a decrypted transaction data set would potentially contain coin data sets that could be used for payment transactions, thereby increasing the risk of fraud.
  • the transaction data record has a transaction time.
  • a time stamp is generated and added to the transaction data record.
  • the time stamp is preferably unique throughout the payment system.
  • the transaction record may contain additional data such as location of transaction (GPS). However, it preferably consists of the data mentioned.
  • GPS location of transaction
  • the first subscriber unit adds a transaction time to the encrypted transaction data record (in plain text), for example as metadata.
  • This transaction time can be in the trade repository as an input parameter for calculating a deletion time of the encrypted transaction data record. So for example, as part of data retention, the encrypted transaction data record could be automatically deleted from the trade repository after a set storage time, for example X months or Y years, has expired. This is advantageous in the event that the transaction data record is not sent to the transaction register until much later after the transmission of the coin data record, in order not to extend the storage (possibly in an illegal manner).
  • An identifier or the identifiers of the transaction data record could also be added in plain text as further metadata.
  • the transaction data record has an acknowledgment of receipt from the second subscriber unit.
  • the acknowledgment of receipt serves as proof or acknowledgment of proper receipt of the electronic coin data set in the second subscriber unit, and possession of the acknowledgment of receipt in the first subscriber unit proves proper transmission of the electronic coin data set.
  • this transaction record contradicts the requirement of anonymity for the payment system. For this reason, the transaction record is encrypted in a subsequent step.
  • the transaction record is preferably encrypted immediately after it is created, more preferably the creation and the encryption occur as an atomic operation. Encryption is done with a cryptographic key. This means that the transaction data set cannot be viewed by an uninvolved third party and its content is hidden from this uninvolved third party. This ensures that an attack on the subscriber identity module to spy out unencrypted transaction data is unsuccessful.
  • This cryptographic key is composed of at least two partial keys. Each subkey comes from a (single) remote entity. The remote instances are independent of each other. A remote entity has knowledge and possession of only a (own) part of the key. In particular, a remote entity is unaware of and does not possess a partial key of another remote entity.
  • the assembly of the cryptographic key also includes deriving a public key part of a PKI key infrastructure to be used for encryption, which may have been generated using an assembled private key part.
  • remote entity is meant here that this entity is not a local entity of a subscriber unit.
  • the remote entity is preferably not the coin register of the payment system, not the transaction register of the payment system and not the monitoring register of the payment system, so that anonymity and neutrality are maintained in the payment system, an independence that the register instances of the payment system cannot decrypt the encrypted transaction data record or cannot contribute a partial key for decryption.
  • this encrypted transaction record can be decrypted by authorized parties as the remote entities.
  • authorized parties could be, for example, a law enforcement agency, a notary public, the Department of Justice, a central bank, a payment processing authority, a court of law, or others.
  • the cryptographic partial keys are each from a law enforcement agency; a notary authority; a Department of Justice entity; a central issuing authority of the payment system; or a commercial bank instance of the payment system.
  • the cryptographic key for encrypting the transaction data record is a public key part of an asymmetric
  • the cryptographic key for encrypting the transaction data record is a public key part of an asymmetric
  • PKI Key infrastructure
  • All remote entities only have a partial key of the decryption key, i.e. all remote entities or a subset of the remote entities are always required to jointly decrypt the encrypted transaction data record. This improves security against misuse, as multiple instances are required to perform data access, which represents significant overhead in an attack scenario.
  • the partial keys are combined into a common (private) decryption key. This combining is done in the trade repository, for example. Alternatively the combining occurs in the first subscriber unit. This combining is done, for example, by addition or by bit-by-bit XOR operation, which no remote entity can obtain for itself merely by knowing the partial key(s). This shared (private) decryption key is then used to decrypt the encrypted transaction record.
  • the corresponding public key portion of this shared private decryption key is used in the first subscriber unit to encrypt the generated transaction record.
  • This public key part can be sent from the trade repository to the subscriber unit and received there.
  • the public key is preferably stored in the subscriber unit, in particular stored in advance, more preferably stored in a change-protected manner.
  • the cryptographic key for encryption is a symmetric key, with the corresponding private key part for decrypting the transaction data record being composed of at least two cryptographic partial keys by an addition operation or a bitwise XOR operation.
  • threshold cryptography is applied to allow that not all remote entities are required to contribute their partial key, but that a subset of the entities is sufficient to compose the decryption key.
  • the rule here is that at least the number of the subset must contribute its respective partial key. If the subset is smaller than a predefined minimum number of remote instances, decryption is not possible.
  • all remote entities have a complete set of decryption keys for decrypting the encrypted transaction record.
  • Each remote entity then has a security element, for example a smart card, a TSM, an eUICC, in whose data memory all partial keys are stored.
  • a security element for example a smart card, a TSM, an eUICC, in whose data memory all partial keys are stored.
  • Each of these remote instances is then technically capable of decrypting the encrypted transaction dataset on its own, for example as soon as access to it has been authenticated by a trustworthy body, for example a court authority after a decision has been issued. This access will only be granted by the trusted entity (the trade repository) if that authority(ies) can provide a legally binding document reflecting a court decision in this regard.
  • all remote entities generate their own PKI key pair consisting of a private key part and a public key part.
  • the public key parts of the respective key pairs are provided and/or received by the first subscriber unit.
  • the first subscriber unit encrypts the generated transaction record with a first public key portion of a first remote entity to obtain a first partially-encrypted transaction record.
  • This first encrypted transaction record is encrypted by the first subscriber unit with a public key portion of a second remote entity to obtain a second encrypted transaction record.
  • this second encrypted transaction record is encrypted by the first subscriber unit with a public key portion of a third remote entity to obtain a third encrypted transaction record.
  • the number and/or the order in which the public key parts of the respective remote entity are used is specified throughout the payment system, for example, in order to simplify subsequent decryption in the transaction register using the corresponding private key parts of the remote entities.
  • at least the order, and in one embodiment also the number, of the use of the public keys of the respective instance is varied and decryption in the trade repository is carried out using "trial &error", i.e. a heuristic method in which a decryption order and key selection is sought/tried for as long as until the desired decryption takes place in order to better secure the process.
  • the encryption methods described here are transparent in order to ensure user acceptance.
  • a communication link to a transaction register of the payment system is initiated in order to send the encrypted transaction data record to the transaction register.
  • This will attempt to send the transaction record to the trade repository.
  • a standard communication protocol such as TCP/IP or mobile radio communication, can be used in this case.
  • a proactive command is sent to the subscriber unit.
  • Initiating represents an attempt to establish a connection or an initiation of establishing a connection, the termination of which is also a scenario of the method according to the invention. Initiating may also include the subscriber unit not attempting to establish a connection knowing that a connection to the trade repository is not possible, for example upon detecting an offline status of the first subscriber unit, such as "no reception” or "airplane mode” or "no credit”. . Then the knowledge of the impossible connection to the trade repository, equated to initiating, for example, by previously querying or checking existing communication options.
  • Initiating also includes reading out a memory content of a first
  • Initiating also includes reading out a memory content of a first
  • the transaction register of the payment system is used to archive the encrypted transaction data record.
  • This encrypted transaction data record can be decrypted there, in particular after an official request, using composite (combined) partial keys from the remote authorities and can then be viewed by the requesting authority (court authority, etc.).
  • An inspection for control verification purposes in each transmission of an electronic coin data record in the payment system and/or each modification to be registered or each registered modification of an electronic coin data record in the payment system is thus possible, but technically feasible only under very strict conditions.
  • the governmental request such as a court order, includes a subscriber unit identifier and requests all transactions of that identifier within a specified time period or point in time.
  • the metadata of the transaction data record then simplifies the answering of this request at the trade repository.
  • the trade repository can be a non-public database of the payment system, for example.
  • the encrypted transaction records are stored in this database for possible later verification.
  • the transaction register is designed, for example, as a centrally managed database in the form of a data store or service server of the payment system.
  • the first security element is installed ready for operation in the first subscriber unit. This ensures that the transaction data records are generated and encrypted and, if necessary, also sent without manipulation. In one embodiment, the transaction data record is created in the security element and then encrypted 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 or an embedded security module, eUICC, eSIM.
  • TPM English Trusted Platform Module
  • eUICC embedded security module
  • eSIM embedded security module
  • 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 themselves and then continue to use them directly - without checking the register - especially if the payment system requires that electronic coin data sets of security elements are to be regarded as valid per se.
  • 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 first security element could also have received electronic coin data records from less trustworthy units, such as subscriber units, ie end device or machine, for example via an import/export function of the security element. Electronic coin records obtained in this way that are not obtained directly from another security element are considered less trustworthy. It could be a requirement of the payment system to have to check such electronic coin data sets for validity using the coin register or by an action (modification) by the receiving one 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 end device or machine
  • 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 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 record. This communication link 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 a database in which masked electronic coin records are registered with corresponding processing of the masked electronic coin record.
  • the masking will be explained later.
  • a validity status of the (masked) electronic coin data set can be derived from this.
  • the validity of the (masked) electronic coin data records is preferably noted in and by the coin register. Modifications, such as switching, dividing or combining, to the individual electronic coin data records are registered in the coin register. Modifications requested or carried out or to be carried out preferably also cause the above-described generation of a transaction data record, which is stored in encrypted form in the transaction register. In this way, the trade register is also used to archive modifications to a coin data set.
  • This information in the payment system which is possibly redundant to the information from the coin register or the monitoring register, increases the stability and security of the payment system.
  • the registration of the processing or the processing steps for a respective modification can also relate to the registration of test results and intermediate test results relating to the validity of an electronic coin data record, in particular the determination of test values and counter values of corresponding coin data records. If processing is final, this is indicated, for example, by corresponding markings or a derived total marking in the coin register. One final processing then decides whether an electronic coin record is valid or invalid.
  • test results and intermediate test results relating to a respective modification or a transmission process between subscriber units or their security elements and relating to the validity (in particular for display) of an electronic coin data record are registered, in particular the determination of test values and counter values of corresponding electronic coin data records not in the coin register of the payment system, but in a monitoring register of the payment system.
  • the monitoring register is set up to store anonymized and/or pseudonymized transaction data records in order to enable the transactions to be monitored during ongoing operation of the payment system.
  • the monitoring register is a separate instance of the same payment system from the coin register.
  • Both the coin register and the monitoring register can be decentralized public databases, for example.
  • 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 the monitoring register are designed as a service server of the payment system.
  • the first subscriber unit sends the encrypted transaction data record to the transaction register. In this case, after initiating, communication between the subscriber unit and trade repository could be successfully established and the encrypted transaction data record sent successfully. As a result, the first subscriber unit can locally delete the transaction record to save storage space.
  • the encrypted transaction data record is sent to the transaction register in a cryptographically secure manner for transport.
  • a cryptographically secure manner for transport In this case, for example, mutual authentication between subscriber unit and trade register is used.
  • a key exchange is either negotiated in advance as a session key or issued in advance. This additional transport security prevents an attacker from learning that a transaction record is now being transmitted. This increases security when transferring the transaction data records.
  • the encrypted transaction data record is stored in the first subscriber unit if the establishment of a communication connection (after initiation) to the transaction register or the sending of the encrypted transaction data record fails.
  • the storage can be an intermediate storage as long as the encrypted transaction record has not yet been successfully sent to the trade repository.
  • the saved encrypted transaction data record is used for a necessary repetition (RETRY) of sending in the event of connection errors or authentication problems and then does not have to be recreated and encrypted.
  • the encrypted transaction data record is sent from the first security element to the transaction register as soon as the communication connection with the transaction register has been successfully established.
  • Successful connection establishment means, for example, that communication of data is made possible via an established communication channel, ie the communication channel between the trade register and the subscriber unit has been established. This keeps the trade repository up to date with regard to completed/planned transfers and recent transactions are promptly archived in the trade repository.
  • Sending is also prioritized in the event that no connection to the transaction register was available at the time the coin data record was transmitted, and the subscriber unit or its security element is required to promptly send the encrypted transaction data record to the transaction register if a (recognized) available communication connection is available.
  • the electronic coin data set is transmitted from the first subscriber unit to the second subscriber unit.
  • the transmission takes place, for example, immediately before the generating step, so that the transaction data record relates to a coin data record to be transmitted.
  • the transfer occurs immediately after the generate step but before the encrypt step, so the transfer could be part of the atomic operation described above and only the entire chain of generate-transfer-encrypt can be performed. This avoids differences between the generated transaction data record and the actually transmitted coin data record.
  • the transmission takes place, for example, immediately after the encryption step and before the initiating step, so that the transaction data record relates to a coin data record to be transmitted.
  • the transmission takes place, for example, immediately after the initiating step, so that the transaction data record relates to a coin data record that has already been transmitted
  • a transmission protocol can ensure that a transmission process (payment process), even though it is executed asynchronously, can be trusted by checking for the presence of a received message and using security elements.
  • a two-stage transmission is preferably to be ensured so that amounts of money are not destroyed nor are they duplicated in the active state.
  • the generated transaction data record is stored in the first subscriber unit, preferably in a non-volatile manner.
  • the storage can be an intermediate storage as long as the electronic coin data set has not yet been successfully transmitted to the second subscriber unit. The storage takes place locally.
  • the transaction record can be used to repeat the transmission process between the subscriber units. In this case, no changes need to be made to the coin data record or the transaction data record itself.
  • the stored transaction data record is used for a necessary repetition (RETRY) of the transmission in the event of connection errors or authentication problems during transmission.
  • the stored transaction data set is used for reversal (ROLLBACK) if the transmission of the coin data set failed.
  • ROLLBACK reversal
  • the electronic coin data record in the event of a transmission error, is sent again using the stored transaction data record. It is assumed that the transmission of the electronic coin data set has failed, but the transmission process is to be completed. The transmission of the electronic coin record is promptly repeated.
  • the electronic coin data record to be resent corresponds to the electronic coin data record during the transmission of which a transmission error occurred. No changes are therefore required to the coin data record for resending.
  • a further transaction data record is generated for logging purposes
  • a transmission error case is assumed, for example, if an acknowledgment of receipt was not received in the first security element within a predefined period of time.
  • a timer is started, for example; the timer is preferably started during the transmission step of the electronic coin data set.
  • the case of a transmission error can be indicated by an error message from the first or the second security element.
  • the error case is thus explicitly displayed.
  • the transmission error case can also be assumed by a detected connection fault (connectivity failure).
  • the error case is thus indicated implicitly.
  • the transmission error case can also occur due to failed authentication (authentication failure).
  • the transmission error can also occur when a terminal device (device shutdown) in which one of the security elements is installed ready for operation is switched off, or when the transmission range is exceeded (exceeded distance) due to a movement of a participant.
  • the transmission error can also occur due to an internal error in the first or second security element, in an application of the terminal device, or in the respective terminal device, for example due to a storage error or a lack of storage space.
  • the first security element queries the second security element at predefined periodic time intervals and actively requests an acknowledgment of receipt, alternatively also when a time value of a timer has been exceeded.
  • a successful transfer is indicated in the first subscriber unit.
  • a user display can be updated or the monetary amount can be deleted from a list of available monetary amounts.
  • a participant (user) in the payment system is visualized by this display that the transmission process was successful.
  • an available monetary amount is updated, in particular reduced in accordance with the transmitted monetary amount.
  • the electronic coin data record is evaluated as an input parameter of an application of the first subscriber unit in the display step.
  • the transaction data of this electronic coin data record thus actively controls the transmission process, regardless of an application that is executable in the first subscriber unit. Changes to the electronic coin data set are visualized for a user by the application on the first subscriber unit, and the user accordingly receives prompt feedback on the validity/status of the electronic coin data set to be/are transmitted.
  • the transmission step is only carried out when a checking step shows that a check value for a number of transmissions to the second subscriber unit or to one or more other subscriber units failed to establish a communication connection to the transaction register or failed to send the encrypted transaction data record to the trade repository is below or equal to a predefined threshold.
  • the number of transmissions of coin data sets from the first subscriber unit is thus limited to a maximum value if the respective transaction data sets have not been or could not be sent to the transaction register in the meantime. This forces the first subscriber unit to always check whether a threshold value, for example 100, more preferably 50, more preferably 10 transmissions, ideally 5 transmissions, has been reached.
  • a check value must be passed for a number of transmissions to the second subscriber unit or to one or more further subscriber units if the transmission failed
  • the number of transmissions of coin data sets from the first subscriber unit is thus limited to a maximum value if the respective transaction data sets have not been or could not be sent to the transaction register in the meantime. This forces the first subscriber unit to send the encrypted transaction records. A transfer of coin data sets is prevented until the transaction data sets have been sent successfully.
  • the threshold value is, for example, 100, more preferably 50, more preferably 10 transmissions, ideally 5 transmissions.
  • a test value is incremented in the first subscriber unit if the electronic coin data record was successfully transmitted and the communication connection to the transaction register failed or the encrypted transaction data record was not sent to the transaction register.
  • the test value to be checked is always up-to-date in relation to transmitted coin data sets whose corresponding transaction data set has not yet been sent from the subscriber unit to the transaction register.
  • the method has the further steps: masking the electronic coin data set by applying a homomorphic one-way function to the electronic coin data set to obtain a masked electronic coin data set and registering the masked electronic coin data set in a coin register of the payment system, the registration preferably for switching , splitting or joining masked electronic coin records.
  • masking will be explained later.
  • the task is also solved by a previously described subscriber unit.
  • the subscriber unit has a computing unit that is set up to execute the method described here.
  • the subscriber unit also has means for accessing a data memory, with at least one electronic coin data record being stored in the data memory.
  • the subscriber unit also has an interface that is set up to set up a communication link to a trade register in order to send an encrypted transaction data record to the trade register.
  • the object is also achieved by a method in a transaction register for storing encrypted transaction data records of a payment system with the method steps: receiving an encrypted transaction data record from a first subscriber unit, the received encrypted transaction data record being replaced by the previously procedure described was generated and encrypted; and storing the encrypted transaction data set in a memory area of the transaction register.
  • the object is also achieved by a method for storing encrypted transaction data records of a payment system with the method steps: generating, from a first subscriber unit, a transaction data record with regard to a transmission of the electronic coin data record to a second subscriber unit, preferably a second security element, or with regard to a coin register registering modification of the electronic coin record; Encryption, from the first subscriber unit, of the transaction data record generated with a cryptographic key, the cryptographic key being composed of at least two partial cryptographic keys, preferably at least three partial cryptographic keys, each from different remote entities, sending the encrypted transaction data record to a transaction register; Receiving an encrypted transaction data set, the received encrypted transaction data set being generated and encrypted in particular by the method described above; and storing the encrypted transaction data set in a memory area of the transaction register.
  • the filing in the trade repository is limited to a predefined period of time.
  • This period begins, for example, at the time the encrypted transaction data record is received in the trade repository or is started by a transaction time that is attached to the encrypted transaction data record as metadata.
  • This period is, for example, a legal requirement, ie a minimum or maximum period of time for storing the transaction data records, for example as part of data retention, for example X months or Y years.
  • the method includes the further step of decrypting the encrypted transaction data record with a cryptographic key, the key for decrypting the encrypted transaction data record being composed of at least two cryptographic partial keys of respective different remote entities in the transaction register.
  • the assembling takes place by means of an addition operation or a bitwise XOR operation.
  • the cryptographic key for decrypting the encrypted transaction data record is from a predefined number of cryptographic subkeys of different remote entities, where the predefined number is less than the total number of the different entities.
  • the decryption only takes place upon external request. This request may be the result of an investigation to verify that a transaction actually took place.
  • the transaction register has a hardware security module, HSM for short, with the hardware security module being a secure key memory in which different generations of the partial keys of the respective remote instances are stored.
  • HSM hardware security module
  • the hardware security module being a secure key memory in which different generations of the partial keys of the respective remote instances are stored.
  • the key generations are preferably tracked by an HSM of the transaction register.
  • the transaction register has a hardware security module against which the various instances authenticate themselves before decrypting the stored encrypted transaction data record.
  • the HSM can therefore fulfill various functions, it is primarily a secure key store and a secure processing unit.
  • the HSM module can contain, for example, different key generations of the partial keys, with the remote entities authenticating themselves to the HSM in order to enable decryption with all generations.
  • the encrypted transaction data record is re-encrypted.
  • the encrypted transaction data is always re-encrypted (i.e. decrypted and re-encrypted) when it is received, thus avoiding transaction data records being stored in different encrypted formats in the transaction register. This simplifies the administration of the encrypted transaction data records in the trade repository.
  • the encrypted transaction record is re-encrypted. This prevents transaction data records from being stored in different encrypted formats in the transaction register when the key of an instance is changed.
  • the encrypted Transaction record after receiving the encrypted transaction data record from the first subscriber unit, the encrypted Transaction record decrypted and an identifier of a (first and / or second) subscriber unit replaced by a pseudonym in the transaction record to obtain a decrypted pseudonymised transaction record.
  • the storage of the received encrypted transaction data sets is unaffected by this.
  • an identifier of a subscriber unit (for example subscriber ID of a terminal device) is uniquely assigned to a natural person in the payment system.
  • This person assignment is carried out, for example, by an issuing entity of the payment system or a bank entity of the payment system and possibly also managed there.
  • This personal assignment can also be managed by a service entity, for example an entity that provides a purse application for the terminal device or that provides online access to a cloud purse.
  • This assignment of person to identifier is only carried out by the respective instance after the person has been successfully identified, for example by presenting an official identification document such as an identity card or passport.
  • the encrypted transaction data record is decrypted and a monetary amount of an electronic coin data record is replaced by one or more amount categories in the transaction data record in order to obtain a decrypted amount-categorized transaction data record.
  • An amount category is, for example, an amount range (from-to) in which the monetary amount of the coin data record lies.
  • an amount category is a rounded amount value of the monetary amount, either rounded up or down.
  • the storage of the received encrypted transaction data sets is unaffected by this.
  • the decrypted, pseudonymised or decrypted amount-categorized transaction data record is sent to a monitoring register of the payment system and stored there.
  • anonymized or pseudonymised transaction data records can be stored in the monitoring register, thereby enabling transactions to be monitored during ongoing operations
  • pseudonymised transaction data records With the creation of pseudonymised transaction data records, an anonymity level for the respective transaction data record is changed.
  • the pseudonymised transaction data record is always more anonymous than the (non-pseudonymised) transaction data record.
  • the pseudonymised transaction data record can also be stored unencrypted in the register instances (coin register, monitoring register, transaction register) - as required by the payment system - and used for further validity checks in the payment system. This could result in cases of fraud or manipulation in the payment system can be better detected by the payment system itself, an official request (judicial decision) may then not be necessary.
  • An anonymity level of a record reflects a degree of anonymity of the (coin or transaction) record, i.e. a possibility of assigning a constant identity, such as subscriber identifier, ID number, natural person, etc., to a record.
  • the aim of the payment system is to transfer monetary amounts anonymously (level 1), i.e. it should not be possible for a participant in the payment system - based on analogue cash - to deduce the constant identity of the participant based on a received coin data set.
  • the generated transaction data records are not anonymous (level 3), they are therefore clearly assigned to a constant identity, for example a subscriber ID, which can lead to a person attribution to a natural person.
  • a mixed form is a pseudonym (level 2). This is the temporary or permanent association of a derived identity with a record.
  • the derivation is generated, for example, in a trusted entity such as an audit register.
  • a subscriber identifier in the encrypted transaction data record preferably has level 3 anonymity, so that decrypting the transaction data record shows the constant subscriber identifier.
  • a monetary amount in the encrypted transaction data record preferably has level 3 anonymity, so that decrypting the transaction data record shows the exact amount.
  • the anonymity level of a subscriber identifier in the transaction data record is different from an anonymity level of an amount category, so that mixed forms (different gradations) can be present in a pseudonymised transaction data record.
  • the task is also solved by a transaction register for a payment system.
  • the trade repository has a processing unit that is set up to execute the method of the method described above in a trade repository.
  • the transaction register also has means for accessing a data memory, with at least one encrypted transaction data record being stored in the data memory.
  • the trade repository also has an interface that is set up for communication with a subscriber unit to receive an encrypted transaction record from the subscriber unit.
  • the system preferably has means for carrying out the generating step and the encrypting step of the method described above.
  • the encrypted transaction record can be sent to a trade repository.
  • the transaction register also has: a hardware security module, set up for the secure storage of partial keys of different generations; and decrypting encrypted transaction records.
  • the HSM of the trade repository is set up to decrypt encrypted transaction data records; replacing a subscriber unit identifier with a pseudonym in the transaction record to obtain a decrypted pseudonymised transaction record.
  • the HSM of the trade repository is set up to decrypt encrypted transaction data records and to replace a monetary amount of an electronic coin data record with an amount category in the transaction data record in order to obtain a decrypted amount-categorized transaction data record.
  • the interface is set up to send the decrypted pseudonymised transaction data record or the decrypted amount-categorized transaction data record to a monitoring register of the payment system.
  • the object is also achieved by a payment system having at least one subscriber unit as described above, the subscriber unit being set up to carry out the method described above in a first subscriber unit; and a transaction repository as described above, wherein the transaction repository is set up in a transaction repository for performing the method described above.
  • the payment system also has an issuing entity that is designed to create an electronic coin data record for the payment system; and/or a coin register configured to register a masked electronic coin data record, the registering being preferential for switching, splitting or connecting masked electronic coin data records; and/or a monitoring register arranged to receive a pseudonymised masked electronic coin record from the subscriber unit or to receive a decrypted one pseudonymised or decrypted amount-categorized transaction data record from the trade repository.
  • an issuing entity that is designed to create an electronic coin data record for the payment system
  • a coin register configured to register a masked electronic coin data record, the registering being preferential for switching, splitting or connecting masked electronic coin data records
  • a monitoring register arranged to receive a pseudonymised masked electronic coin record from the subscriber unit or to receive a decrypted one pseudonymised or decrypted amount-categorized transaction data record from the trade repository.
  • the payment system is preferably also set up to manage electronic coin data sets from other issuing entities and/or monetary amounts as book money.
  • the electronic coin data set has a monetary amount, ie a date that represents a monetary value of the electronic coin data set, and an obfuscation amount, for example a random number.
  • the electronic coin data record can have further metadata, for example which currency the monetary amount represents.
  • An electronic coin data record is uniquely represented by these at least two pieces of data (monetary amount, concealment amount).
  • Teen who has access to this data of an electronic coin record can use this electronic coin record for payment. Knowing these two pieces of data (monetary amount, concealment amount) is therefore equivalent to owning the digital money.
  • This electronic coin record can be directly transmitted between two subscriber units.
  • a status (active, inactive) of the electronic coin data record is also added to the coin data record, so that this then consists of three pieces of data (monetary amount, concealment amount, status).
  • the status of a coin data record is not appended to the coin data record and is only managed in the security element itself and/or the coin register.
  • a corresponding masked electronic coin data record is assigned to each electronic coin data record in the respective method.
  • Knowledge of a masked electronic coin record does not authorize spending the digital money represented by the electronic coin record. This represents a key difference between the masked Electronic Coin Records and the (non-masked) Electronic Coin Records.
  • a Masked Electronic Coin Record is unique and also unique to an Electronic Coin Record, so there is a 1-to-1 relationship between a Masked Electronic Coin Record and a (non-masked) electronic coin record.
  • the electronic coin data set is preferably masked by a processing unit of the subscriber unit.
  • the subscriber unit has at least one electronic coin record.
  • the masking can be performed by a processing unit of a subscriber unit receiving the electronic coin data set.
  • This masked electronic coin record is obtained by applying a one-way homomorphic function, specifically a cryptographic homomorphic function.
  • This Function is a one-way function, i.e. a mathematical function that is “easily” calculable in terms of complexity theory, but is “difficult” to practically impossible to reverse.
  • a one-way function is also referred to as a function for which no reversal that can be carried out in practice within a reasonable time and with reasonable effort is known to date.
  • the calculation of a masked electronic coin data set from an electronic coin data set is comparable to the generation of a public key in an encryption method using a residual class group.
  • a one-way function is used that operates on a group where the discrete logarithm problem is difficult to solve, such as B.
  • a cryptographic method analogous to an elliptic curve encryption, ECC for short from a private key of a corresponding cryptographic method.
  • the reverse function ie the generation of an electronic coin data record from a masked electronic coin data record, is very time-consuming—equivalent to generating the private key from a public key in an encryption method using a residual class group.
  • the respective operations on the corresponding mathematical group are to be understood in the mathematical sense, for example the group of points on an elliptic curve.
  • the one-way function is homomorphic, i.e. a cryptographic method that has homomorphic properties. Mathematical operations can thus be carried out with the masked electronic coin data record, which can also be carried out in parallel on the (non-masked) electronic coin data record and can therefore be reproduced. With the help of the homomorphic one-way function, calculations with masked electronic coin data records in the coin register and/or the monitoring register can be reproduced without the corresponding (non-masked) electronic coin data records being known there. Therefore, certain calculations with electronic coin data sets, for example for processing the (non-masked) electronic coin data set (e.g.
  • the monitoring of the legality of the respective electronic coin dataset can be verified in the monitoring register.
  • the homomorphic property thus makes it possible to keep a record of valid and invalid electronic coin records based on their masked electronic coin records in a coin register and a monitoring register without knowledge of the electronic coin records even if these electronic coin records are processed (split, merged, switched) or transmitted directly, i.e. an action is carried out with these electronic coin data sets. It is always ensured that no additional monetary amount was created or that an identity of the subscriber units or their security elements is recorded in the coin register or the monitoring register. Masking allows for a high level of security without giving any insight into the monetary amount or subscriber unit.
  • a status of the electronic coin data record can be set to inactive status in order to invalidate the electronic coin data record, then it is sent (as the first step of the transmission) to the second subscriber unit and, if there is an acknowledgment of receipt from the second subscriber unit, it is deleted of the electronic coin record in the first subscriber unit (as the second step of the transmission).
  • a confirmation of erasure from the first subscriber unit may be sent to the coin register or the second subscriber unit to indicate a successful erasure (performed in the first subscriber unit) of the electronic coin record.
  • the switching can preferably take place automatically upon receipt of the confirmation of deletion of an electronic coin data record in the second subscriber unit. In addition, it can also be done on request, for example by a command from the first subscriber unit and/or the second subscriber unit.
  • an electronic coin data record can also be divided into at least two electronic partial coin data records (“split”).
  • two electronic coin datasets can be combined into one electronic coin dataset (“merge”). Switching, splitting and connecting are various modifications to an electronic coin record, i.e. actions with the electronic coin record. These modifications require the masked coin data set to be registered in the coin register of the payment system. The concrete implementation of the individual modifications will be explained later.
  • Switching also takes place when an electronic coin dataset is changed, for example split up or connected to other electronic coin datasets, in particular in order to be able to settle a monetary amount to be paid appropriately.
  • the method comprises the further steps of: masking the electronic coin data set by applying a homomorphic one-way function to the electronic coin data set to obtain a masked electronic coin data set; associating the masked electronic coin record with a pseudonym to obtain a pseudonymized masked electronic coin record; and sending the pseudonymized masked electronic coin record to a monitoring register of the payment system. Modifications to the electronic coin data record are thus tracked in the coin register and documented in the monitoring register under a pseudonym, without anonymity in the payment system being removed. The monitoring register can thus identify the outgoing transactions at the subscriber unit even if it knows the affiliation of the pseudonym and the subscriber unit.
  • the pseudonymized masked electronic coin data record is preferably included in the transaction data record in the generation step by the first subscriber unit, more preferably instead of the masked electronic coin data record, and thus sent in encrypted form to the transaction register. A later decryption reveals the pseudonym under which the transaction took place.
  • This procedure represents an alternative to the above-described provision of the pseudonymised transaction data of the trade repository and could be used in parallel or in addition to this procedure in the monitoring register.
  • the selection of The respective pseudonymisation procedure can be set flexibly in the payment system and adapted to the actual requirements of the payment system, for example to the processing power of the trade repository or the monitoring register or a transmission capacity in the payment system.
  • the limit value must be subscriber unit-specific and/or time-dependent. Due to the non-transparent multiple (direct) transmission of a coin data record between a large number of different subscriber units, this requirement for deanonymization, also known as re-identification, is not aimed at individual transmissions (transactions) between two subscriber units, but usually relates to the total of all transactions within a certain unit of time (duration) received and/or sent by a subscriber unit.
  • a mechanism is therefore provided for determining the sum of all monetary amounts sent or received by a subscriber unit within a given unit of time. For this purpose, a method is described which enables the anonymity of a transmitting subscriber unit to be revoked if a limit value per unit of time is exceeded.
  • pseudonymization is carried out in a preferred embodiment of the method.
  • a linking step is carried out before the masking step in order to link a pseudonym of the first subscriber unit with the electronic coin data record.
  • the pseudonym is preferably subscriber unit specific.
  • a pseudonym is any type of disguised identity that makes it possible to draw conclusions about the subscriber unit and the transactions carried out with it without merely knowing the electronic coin data record.
  • the subscriber unit must perform a modification (split, switch, connect) for each received coin record in order to associate the pseudonym with the coin record.
  • the registration in the coin register associated with each modification is sufficient in order to be able to unambiguously assign all coin data record transactions that were carried out with the subscriber unit to this subscriber unit on the basis of the linked pseudonym.
  • a monitoring register can identify the incoming transactions at the subscriber unit if it knows the affiliation of the pseudonym and the subscriber unit.
  • modifications to the electronic coin record are linked to a pseudonym stored on the subscriber unit. This pseudonym can either be permanent or only valid for a certain period of time.
  • an anonymous masked electronic coin record lies in the identifiability of the subscriber unit by the surveillance register when using the pseudonym.
  • An anonymous masked electronic coin record does not contain any information about its origin, so it cannot be linked to a subscriber unit.
  • a pseudonymized masked electronic coin record has an association with a pseudonym of the subscriber unit, so that the subscriber unit that sent the pseudonymized masked electronic coin record to the monitoring register can be identified via the linked pseudonym.
  • the mechanism described is sufficient to determine whether the sum of the monetary amounts of all transactions in a subscriber unit is below a limit value, preferably within a specific time unit. If it is recognized that the limit value is exceeded by a desired modification, the monitoring register could promptly prevent such a modification by blocking or rejecting the registration of the corresponding electronic coin data set in the coin register. Alternatively or additionally, the subscriber unit could be informed that the modification (and thus the transaction) would only be carried out if the subscriber unit de-anonymizes itself, e.g. discloses personal access data, before the modification is registered and the electronic coin record is validated, thereby completing the transaction would be accepted.
  • the number of area confirmations or area verifications that the monitoring register requests from the first subscriber unit is reduced by sending the pseudonymized masked electronic coin data record instead of an anonymous masked electronic coin data record.
  • the monitoring register, the coin register and/or the first subscriber unit can process the masked electronic coin records in an anonymous or in a pseudonymous mode.
  • the monitoring register requests necessary and other (catch up) area proofs or area confirmations.
  • the monitoring register does not request at least one of the other area verifications or area confirmations, but checks for the pseudonym whether a (catch-up) criterion is met.
  • An electronic coin record can already be treated as valid if the necessary checks have been carried out. Only when the (catch-up) criterion has been met will Area credentials or cumulative area credentials (or acknowledgment) requested from subscriber unit. For example, a period of time or a number of masked electronic coin data sets can be used as (catch-up) criteria for the pseudonym.
  • the first subscriber unit receives a request for a sum area confirmation or a sum area proof from the monitoring register and sends the requested sum area confirmation or the requested sum area proof to the monitoring register.
  • the first subscriber unit generates an unsolicited summary area confirmation or an unsolicited summary area proof, and sends the unsolicited summary area confirmation or the requested summary area proof to the monitoring register.
  • a sum range confirmation or a sum range proof is information from the subscriber unit about a sum of monetary amounts of a plurality of electronic coin data sets, preferably electronic coin data sets transmitted directly between subscriber units. This total information is compared in the monitoring register with an area information. If the specified range is exceeded, the electronic coin data records are de-anonymized in order to be able to secure and control the transfer of large monetary amounts.
  • the first subscriber unit preferably forms a sum of monetary amounts from a number of electronic coin data records, confirming with the sum range confirmation that the sum formed is within a range.
  • the sum range confirmation is understood in the monitoring register as an indication of the subscriber unit and the subscriber unit is classified as trustworthy.
  • the first subscriber unit creates a sum range verification for a number of electronic coin data sets that can be checked by the monitoring register. The total range is then checked by the monitoring register and there is a confirmation that the total is in range (or not). The proof of total area is preferably also part of the transaction data record for the trade repository.
  • the multiple electronic coin data records only include selected electronic coin data records.
  • the Sum area confirmation or the sum area proof is not carried out for all electronic coin data sets of the subscriber units, but only for a specific selection.
  • the selection relates only to electronic coin data sets sent from pseudonymised, masked electronic coin data sets.
  • only electronic coin data records are affected by sent anonymous masked electronic coin data records or sent pseudonymized masked electronic coin data records.
  • only electronic coin data records are affected by anonymous masked electronic coin data records sent, pseudonymised masked electronic coin data records sent and/or masked electronic coin data records not sent to the monitoring register.
  • the several electronic coin data records are selected as a selection criterion after a preselected period of time. A day, a week or even a much shorter period can be selected as the period.
  • This selection is preferably masked and then sent to the trade repository in encrypted form as part of the transaction record.
  • a list in the first subscriber unit or in the monitoring register is to be used as a selection criterion, based on which list the electronic coin data records are selected.
  • This list is preferably masked and then sent to the trade repository in encrypted form as part of the transaction record.
  • the monitoring register requests area confirmations or area verifications from subscriber units as part of a sum check.
  • the anonymous masked electronic coin record monitoring register employs a first sum checking mode.
  • the monitoring register applies a second sum checking mode.
  • the monitoring register checks a proof of area for each modified electronic coin data set received.
  • the monitoring register regularly or quasi-randomly requests area confirmations or area verifications from subscriber units. This takes place, for example, in the first sum check mode.
  • the monitoring register only requests an area confirmation or an area verification from the subscriber unit once a number of coin data sets have been received for a pseudonym. This takes place, for example, in the second sum check mode. This number is preferably dependent on subscriber unit type and/or coin denomination range. This means that the area proofs or area confirmations can be flexibly tailored to a specific user situation and thus increase the security of the payment system.
  • the masking of the electronic coin data record and linking the masked electronic coin data record in the second subscriber unit with a pseudonym of the second subscriber unit in the second subscriber unit and sending the pseudonymized masked electronic coin data record to the surveillance register is not carried out.
  • These identified outbound transactions are preferably sent to the trade repository in encrypted form as part of the transaction record.
  • the linking step of pseudonymizing is preferably performed by signing the respective masked electronic coin data record in the second subscriber unit with a private signature key of the second subscriber unit to obtain a signed masked electronic coin data record as a pseudonymized masked electronic coin data record or as a pseudonymized masked electronic coin data record transmitted.
  • Signing is done with a private signature key of the subscriber unit.
  • This signature key is preferably subscriber-unit-specific, i.e. knowing the verification key, it can be traced who last modified (switched, divided, connected) the coin data record.
  • the signed masked electronic coin record is registered in the audit register.
  • the signed, masked electronic coin data record is preferably included in the transaction data record in the generation step by the first subscriber unit, more preferably instead of the masked electronic coin data record, and is thus sent to the transaction register in encrypted form. Subsequent decryption then reveals the signature under which the transaction took place.
  • an asymmetric cryptosystem in which the subscriber unit using a secret signature key, here as a private Signature key or "private key”, calculates a value for a data set. This value enables anyone to check the authorship and integrity of the data set using a public verification key, the "public key”.
  • the step of registering preferably involves checking the signature in the monitoring register, with the monitoring register having the public verification key of the signature for this purpose.
  • the signature can now be checked by the monitoring register, in that a public verification key for the signature is known there.
  • the public verification key for checking the signature is preferably known only to the surveillance register, which means that the method remains anonymous to the subscriber units among themselves.
  • the coin register preferably registers any modification, i.e. switching, splitting and/or connecting together with the signature of the subscriber unit.
  • the coin register and/or the monitoring register can monitor and determine the sum of monetary amounts for all transactions of a subscriber unit.
  • the signature is, for example, part of the transaction data record and is sent to the trade repository either in encrypted form or in plain text and stored (archived) there.
  • the signature is preferably valid within a specific time unit, the specific time unit preferably being one day.
  • Each subscriber unit therefore has an asymmetric key pair in order to sign each modification with the private signature key.
  • the public key is known to the surveillance registry (and also to the coin registry).
  • the audit trail can link each transaction to the subscriber unit as the sender or recipient of the coin record.
  • the electronic coin data sets are issued by a central issuing authority, each electronic coin data set additionally having a test value.
  • the check value is incremented when the electronic coin data set is transmitted directly between two subscriber units, or the check value is invariant in the case of an action (modification) carried out by subscriber units with the electronic coin data set.
  • the method includes the following step: determining by the subscriber unit based on the check value of an electronic coin data record whether this electronic coin data record is displayed by the subscriber unit at the payment system or determining by the subscriber unit based on the check value of the electronic coin data record whether the electronic coin data record to the central issuing authority is returned.
  • the recognition of return criteria it is also determined on the basis of the above-mentioned test value for transaction data records that have not been sent or based on a further test value whether the electronic coin data record is displayed by the first subscriber unit in the payment system, in particular a coin register, and/or whether the electronic coin data record is returned to the central issuing authority.
  • Each test value of the electronic coin data record is used in the method to enable or improve a control function in the payment system.
  • Each verification value is preferably a data element of the electronic coin record readable by the subscriber unit or a data element in the subscriber unit and its value can be determined by the subscriber unit.
  • the check value for the return criteria is coupled to an electronic coin record.
  • the incrementing is either incremented by a sending subscriber unit immediately before the coin data record is sent to a receiving terminal. Or the incrementing occurs in a receiving subscriber unit immediately after receipt of the coin record.
  • the number of direct transmissions between subscriber units is recorded for each coin record.
  • the test value is invariant in the event of an action (invariant to action) carried out by subscriber units with the electronic coin data record.
  • Action-invariant means that the test value remains unchanged during an action with the coin data set.
  • the action-invariant test value is not specific to the electronic coin data set but is group-specific and therefore applies to a number of different coin data sets in order to maintain anonymity and prevent coin data set tracking. Any modification to the coin data record carried out by a terminal device, ie in particular switching, dividing, combining, as will be described later, is considered an action with a coin data record.
  • an action means each transmission of the coin data record, for example to a (different) subscriber unit or also to an instance in the payment system.
  • an action means redeeming the coin data set to credit a monetary amount of the coin data set or changing the currency system.
  • the display corresponds to the sending of a switching command to a coin register of the payment system in order to cause the coin data set to be switched there to the subscriber unit sending the coin data set.
  • the display causes the coin data record to be marked in a monitoring register of the payment system.
  • the check value and/or the coin data record can, but does not have to, be transmitted to the payment system for the purpose of display.
  • the return of the electronic coin record by the subscriber unit entails either redeeming a monetary amount associated with the electronic coin record or issuing a new electronic coin record of an identical monetary amount.
  • the return of the electronic coin data set by the subscriber unit can trigger a resetting or deletion of all entries in the monitoring register in the payment system relating to the electronic coin data set. In this way, digital traces of the electronic coin data record are deleted and the anonymity of the procedure is secured.
  • the subscriber unit uses the check value of the electronic coin record to determine whether to return the electronic coin record to the central issuing authority.
  • a criterion for the return of an electronic coin data record can thus be defined with the test value.
  • the electronic coin data set is sent to the central issuing authority as a result of the notification from the payment system (the monitoring register). returned. By displaying this in the payment system, it is thus determined in the payment system whether the coin data set is to be returned. In this embodiment, the determination as to whether a return must take place is carried out in the payment system instead of in the subscriber unit. The result of the determination is communicated to the subscriber unit and the subscriber unit is requested by the payment system to return the electronic coin data set.
  • the payment system requests the modification of the electronic coin data record as a result of the display. Modifying, for example splitting, combining or switching, requires the electronic coin data set to be registered in the payment system. In many configurations of the digital currency system, a return to the issuing authority is not necessary and sometimes also not sensible. This is especially true when the coin record was modified rapidly promptly after it was issued. In this embodiment, the coin record is not returned, but is considered returned.
  • a counter value in the payment system (the monitoring register) relating to this electronic coin data record is determined as a result of the display by the payment system using the check value of the electronic coin data record.
  • the check value of the coin data record is preferably transmitted from the subscriber unit to the payment system (the monitoring register).
  • the counter value is not part of the coin data set.
  • the counter value is preferably managed in the payment system.
  • the counter value is preferably incremented with each action (modification, transmission, redemption) relating to the electronic coin data set.
  • the counter value is preferably increased with different weighting for different actions. This makes it possible to better control the return according to different actions.
  • the check value is thus provided in the coin data record as a data element which is incremented in particular with each direct transmission between subscriber units.
  • the counter value in the payment system includes the check value, for example by adding the previous counter value to the check value.
  • each electronic coin data record has a first check value and a second check value.
  • the first check value is then correspondingly incremented when the electronic coin data record is transmitted directly between two subscriber units, the first check value of the electronic coin data record being used to determine whether the electronic coin data record is displayed by the subscriber unit in the payment system.
  • Based on at least the second check value of the electronic coin data set it is determined whether the electronic coin data set is returned to the central issuing authority.
  • a display check value is provided separately from a return check value in the coin record.
  • the second check value is preferably invariant in an action performed by subscriber units with the electronic coin data set, the second check value preferably being at least one value from the following list: return date of the electronic coin data set; issue date of the electronic coin record; electronic coin record registration date; and electronic coin record identification value.
  • the action-invariant test value is not specific to the electronic coin data set but is group-specific and therefore applies to a number of different coin data sets in order to maintain anonymity and prevent coin data set tracking.
  • the second action-invariant check value is not individual for the electronic coin data record, but applies to a number of different coin data records (group ID) in order to maintain anonymity and prevent coin data record tracking.
  • the second check value is variable and includes the first check value to determine whether the electronic coin record is returned.
  • a sum could be formed and this sum could be compared with a predefined threshold value.
  • the number of direct transmissions could be a return criterion, so that no infrastructure for evaluating the coin data sets with regard to the return of the coin data sets would have to be provided in the payment system, ie simpler and more secure management would be possible while creating the control functions.
  • the exceeding of a threshold value of the check value of the electronic coin data record is determined by a first terminal device and an action with this electronic coin data record, in particular the direct transmission of this electronic coin data record from the first terminal device to a second terminal device, is only carried out if in first terminal it has been determined that no other electronic coin data set is present in the first terminal. This ensures that a payment transaction between two terminals can still be carried out and completed with the coin data set despite a large number of direct transmissions of this coin data set between terminals due to a lack of alternative coin data sets in the terminal.
  • the exceeding of a blocking threshold value of the test value of the electronic coin data set is determined by a first subscriber unit and an action with this electronic coin data set, in particular the direct transmission of this electronic coin data set from the first subscriber unit to a second subscriber unit, is blocked, regardless of this whether or not there is another electronic coin record in the first subscriber unit.
  • a threshold value is thus defined which, when it is reached, completely prevents (blocks) direct forwarding (transmission) between subscriber units. For example, this one could Coin data are stored in a secure storage area, also only a return process but no action process of the subscriber unit has access.
  • the imminent blocking can be detected in advance by the subscriber unit and a user of the subscriber unit can be informed in order to prevent the blocking of the coin data set by immediately returning the coin data set. Additionally or alternatively, the subscriber unit may return the electronic coin record upon detecting that the blocking threshold has been exceeded.
  • the threshold value of the check value is preferably lower than the blocking threshold value of the check value.
  • the blocking threshold can be a multiple of the threshold in order not to block the coin record too early.
  • the threshold value is ten, for example, or five, for example, or 3, for example.
  • the blocking threshold value is correspondingly 30, or, for example, 15, or, for example, 10.
  • the issuer entity queries test values of coin data sets at predefined periodic intervals or in a specifically controlled manner and automatically requests an electronic coin data set back if a test value of the electronic coin data set is exceeded.
  • the monitoring register of the payment system determines a counter value in the monitoring register relating to the electronic coin data set using the test value of the electronic coin data set. If the counter value exceeds a threshold value, the electronic coin data record is returned (directly or indirectly) to the central issuing authority. In this case, preferably only masked coin data records are managed in the monitoring register.
  • the issuer instance or the payment system requests the corresponding coin data set from the subscriber unit or provides corresponding information from the payment system to the subscriber unit for (direct) return.
  • the counter value is preferably increased with each action on the electronic coin data set, the counter value preferably being increased with different weighting for different actions.
  • the check value of the electronic coin data set is reset by the payment system. This simplifies the procedure since the subscriber unit does not have to be adjusted to the sum of all permitted actions, but only to the sum of consecutively permitted direct transmissions.
  • the payment system determines the highest test value of the electronic coin part data records and this highest test value is adopted as the test value of the combined electronic coin data record.
  • the monitoring register determines a new test value from the sum of all test values of the electronic coin part data records divided by the product of the number of coin part data records with a constant correction value, this new test value being the test value of the combined electronic coin dataset is adopted, the correction value being greater than or equal to 1 and the correction value preferably depending on a maximum deviation of the individual test values of the electronic coin part datasets or on a maximum test value of one of the electronic coin part datasets, with the correction value being more preferably less than or equal to 2.
  • the correction value is constant throughout the system.
  • the electronic coin data record is returned from the monitoring register to the issuing entity when the terminal device initiates the redemption of a monetary amount of the electronic coin data record to an account in the payment system and/or when the subscriber unit exchanges the monetary amount of the electronic coin data record for a requests another currency system of the payment system.
  • An electronic coin record can be split in a subscriber unit and this split is then registered in the coin register.
  • This has the advantage that an owner of the at least one electronic coin data record is not forced to always transfer the entire monetary amount at once, but rather to form and transfer corresponding partial monetary amounts.
  • the monetary value can be divided symmetrically or asymmetrically without restrictions as long as all electronic coin data subsets have a positive monetary amount that is smaller than the monetary amount of the electronic coin data set from which it is split and the sum of the electronic coin subdata sets is equal to the electronic coin subdata set to be split.
  • fixed denominations can be used.
  • the division into partial amounts is arbitrary.
  • the splitting triggers the execution of the method described above for generating and encrypting a transaction record
  • the masked split electronic coin split record may be part of a transaction record for the trade repository.
  • the method preferably has the following further steps: switching over the transmitted electronic coin part data record; and/or merging the transmitted electronic coin record with a second electronic coin record to form a (new) linked electronic coin record.
  • the partial electronic coin data set received from the first subscriber unit results in a new electronic coin data set, preferably with the same monetary amount, the so-called electronic coin data set to be switched over.
  • the new electronic coin data set is generated by the second subscriber unit, preferably by using the monetary amount of the received electronic coin data set as the monetary amount of the electronic coin data set to be switched.
  • a new concealment amount for example a random number, is thereby generated.
  • the new obfuscation amount is added to the obfuscation amount of the received electronic coin record so that the sum of both obfuscation amounts (new and received) serves as the obfuscation amount of the electronic coin record to be switched.
  • the electronic coin part data set received and the electronic coin part data set to be switched over are preferably masked in the subscriber unit by applying the homomorphic one-way function to the electronic coin part data set received and the electronic coin part data set to be switched over, respectively, in order to obtain a masked electronic coin part data set received and a masked electronic coin part data set to be switched over .
  • the switching triggers for example, the execution of the method described above for generating and encrypting a transaction record and the masked electronic coin part record to be switched can be part of a transaction record for the trade register.
  • the switching is thus secured by adding a new spoof amount to the spoof amount of the received electronic coin record, thereby obtaining a spoof amount that only the second subscriber unit knows.
  • Newly created obfuscation amounts must have high entropy since they are used as the blinding factor for the corresponding masked electronic coin part records.
  • a random number generator on the security element is preferably used for this purpose. This safeguard can be tracked in the coin register.
  • additional information that is required to register the switching of the masked electronic coin data set in the coin register is preferably calculated in the subscriber unit.
  • the additional information includes a range verification of the masked electronic coin record to be switched and a range verification of the masked received electronic coin record.
  • the proof of area is proof that the monetary amount of the electronic coin data set is not negative, the electronic coin data set is valid and/or the monetary amount and the concealed amount of the electronic coin data set are known to the creator of the proof of area.
  • the area credential serves to provide such credential(s) without revealing the monetary amount and/or the concealment amount of the masked electronic coin record.
  • Ring signatures are preferably used as area verification.
  • the changeover of the masked electronic coin data set is then registered in the remote coin register.
  • registration triggers the execution of the method described above for generating and encrypting a transaction record, and the masked electronic coin part record to be switched may be part of a transaction record for the transaction register.
  • the registering step is preferably performed when the second subscriber unit is connected to the coin register. While the electronic coin records are used for direct payment between two subscriber units, the masked coin records can be registered with a pseudonym in the coin register.
  • the registration triggers for example, the execution of the method described above for generating and encrypting a transaction record and the pseudonymized masked electronic coin part record to be switched can be part of a transaction record for the transaction record.
  • a further electronic coin data record (connected electronic coin data record) is determined from a first and a second electronic coin part data record for connecting electronic coin part data records.
  • the concealment amount for the electronic coin data set to be connected is calculated by forming the sum of the respective concealment amounts of the first and the second electronic coin data set.
  • the monetary amount for the associated electronic coin data record is preferably calculated by forming the sum of the respective monetary amounts of the first and the second electronic coin data record.
  • the first electronic coin part data record, the second electronic coin part data record, and the electronic coin data record to be connected in the (first and/or second) subscriber unit are created by applying the homomorphic one-way function to the first electronic coin part data record, the second electronic coin part data record, and the to connecting electronic coin data set masked to correspondingly a masked first electronic coin part data set, a masked second electronic coin part data set, and a masked electronic coin data set to be connected receive.
  • additional information needed to register the linking of the masked electronic coin records in the remote coin register is computed in the subscriber unit.
  • the additional information includes area evidence of the masked first electronic coin part record and area evidence of the masked second electronic coin part record.
  • the proof of area is proof that the monetary amount of the electronic coin data record is not negative, the electronic coin data record was validly created and/or the monetary amount and the concealed amount of the electronic coin data record are known to the creator of the area proof.
  • area verification serves to provide such verification(s) without revealing the monetary value and/or the amount of obfuscation of the masked electronic coin record.
  • range proofs are also called "zero knowledge range proofs”. Ring signatures are preferably used as area verification.
  • the connection of the two masked electronic coin part data sets is then registered in the remote coin register. For example, registration triggers the execution of the method described above for generating and encrypting a transaction record, and the masked linked electronic coin part record may be part of a transaction record for the transaction repository.
  • two electronic coin data records or two electronic coin part data records can be combined.
  • the monetary amounts as well as the concealment amounts are added up.
  • the validity of the two original coin data records can also be carried out when connecting.
  • the registering step comprises receiving the masked electronic coin part data set to be switched over in the coin register, checking the masked electronic coin part data set to be switched over for validity; and registering the masked electronic coin part record to be switched in the coin register if the verifying step is successful, whereby the electronic coin part record to be switched is deemed to be verified.
  • a first layer electronic coin data records are transmitted directly between individual subscriber units or their security elements.
  • a second layer testing layer
  • masked electronic coin data sets are registered and checked in a coin register and a monitoring register.
  • no payment transactions are recorded, only masked electronic coin data records, their status, possibly test values, signatures and modifications for the purpose of verifying the validity of (non-masked) electronic coin data records. This ensures the anonymity of the participants in the payment system.
  • the second layer provides information about valid and invalid electronic coin data sets, for example to avoid multiple issuance of the same electronic coin data set or to verify the authenticity of the electronic coin data set as validly issued electronic money or to record the sum of monetary amounts per security element in order to compare this sum with a limit value and prohibit or permit modification accordingly.
  • the second layer may use a counter value of an electronic coin record to determine whether the electronic coin record has expired and is to be returned, or modified appropriately so that it is deemed to be returned.
  • a third layer archiving layer
  • encrypted transaction data records are stored in a transaction repository and decrypted on official request as shown above in order to be checked.
  • the payment system also includes, for example, an issuer entity that generates electronic coin data sets (creation) and requests them again (deletion).
  • an issuer entity that generates electronic coin data sets (creation) and requests them again (deletion).
  • a masked electronic coin data record can also be issued by the issuer entity to the coin register and/or the monitoring register of the payment system for registering the electronic coin data record.
  • a subscriber unit can have a security element or itself be a security element in which the electronic coin data record is securely stored.
  • An application that controls or at least initiates parts of the transmission process can be installed ready for operation on the subscriber unit.
  • Electronic coin data records can be transmitted with the aid of terminal devices as subscriber units, which are logically and/or physically connected to the security elements.
  • the communication between two subscriber units can be wireless or wired, or e.g. also optically, preferably via QR code or barcode, and can be designed as a secure channel, for example between applications of the subscriber units.
  • 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 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) 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).
  • 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.
  • a mobile telecommunications terminal for example a smartphone
  • the subscriber unit can also be a device such as a wearable, smart card, machine, tool, vending machine or even a container or vehicle.
  • a subscriber unit is thus either stationary or mobile.
  • the subscriber unit is preferably designed to use the Internet and/or other public or private networks.
  • 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.
  • 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 first and/or second security element processes the received electronic coin data records in the presence or receipt of a plurality of electronic coin data records according to their monetary value. Provision can thus be made for electronic coin data records with a higher monetary value to be processed before electronic coin data records with a lower monetary value.
  • the subscriber unit can be designed, after receiving an electronic coin data record, to connect this to the electronic coin data record already present in the subscriber unit depending on attached information, for example a currency or denomination, and to carry out a corresponding step of connecting. Furthermore, the subscriber unit can also be designed to automatically carry out a switchover after receipt of the electronic coin data set.
  • further information is transmitted during the transmission from the first subscriber unit or first security element to the second subscriber unit or second security element, for example a currency.
  • this information can be included in the electronic coin data set.
  • the procedures are not limited to one currency.
  • the payment system can be set up to manage different currencies from different publishers.
  • the methods also allow the electronic coin data record to be converted into book money, ie, for example, the monetary amount can be redeemed in an account held by the participant in the payment system. This repositioning is also a modification. Upon redemption, the electronic coin record becomes invalid and is deemed to have been returned.
  • the at least one initial electronic coin data record is preferably created exclusively by the issuer entity, with the divided electronic coin data records, in particular electronic partial coin data records, also being able to be generated by a subscriber unit. Creating and choosing a monetary amount preferably also includes choosing a high entropy obfuscation amount.
  • the publishing entity is a computing system, which is preferably remote from the first and/or second subscriber unit. After creating the new electronic coin record, the new electronic coin record is masked in the issuer instance by applying the homomorphic one-way function to the new electronic coin record to obtain a masked new electronic coin record accordingly. Furthermore, additional information needed to register the creation of the masked new electronic coin record in the remote coin register is calculated in the issuer entity.
  • this further information is proof that the (masked) new electronic coin data set originates from the issuing authority, for example by signing the masked new electronic coin data set.
  • 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 issuer entity can preferably deactivate an electronic coin data record that is in its possession (i.e. of which it knows the monetary amount and the obfuscation amount) by masking the masked electronic coin data record to be deactivated with the homomorphic one-way function and a deactivate command for the coin register prepared.
  • a part of the deactivation command is preferably also the proof that the deactivation step was initiated by the issuing authority, for example in the form of the signed masked electronic coin data set to be deactivated.
  • range checks for the masked electronic coin record to be deactivated could be included in the deactivate command. Disabling may be the result of a return.
  • the deactivation of the masked electronic coin data set is then registered in the remote coin register.
  • the deactivation step is triggered with the deactivation command.
  • the create and deactivate steps preferably take place in secure locations, especially not in the subscriber units.
  • the steps of creation and deactivation are carried out or initiated only by the publishing entity. These steps preferably take place in a secure location, for example in a hardware and software architecture that was developed for processing sensitive data material in insecure networks.
  • the deactivation of the corresponding masked electronic coin data set has the effect that the corresponding masked electronic coin data set is no longer available for further processing, in particular transactions. However, in one embodiment it can be provided that the deactivated, masked electronic coin data record remains in the archives of the issuing authority.
  • the fact that the deactivated masked electronic coin data set is no longer valid or returned can be identified, for example, using a flag or another coding, or the deactivated masked electronic coin data set can be destroyed and/or deleted.
  • the deactivated electronic coin record is also physically removed from the subscriber unit or security element.
  • Various processing operations (modifications) for the electronic coin data sets and the corresponding masked electronic coin data sets are made possible by the method according to the invention.
  • Each of the processing operations (in particular creating, deactivating, dividing, connecting and switching over) is registered in the coin register and appended there in unchangeable form to the list of previous processing operations for the respective masked electronic coin data set.
  • Each of the processing operations initiates the process of creating and encrypting a transaction record, for example.
  • the registration is independent of the payment process between the subscriber units, both in terms of time and place (spatial).
  • the processing operations "Create” and “Deactivate” ( return), which affect the existence of the monetary amount itself, i.e. the creation and destruction up to the destruction of money, require additional approval, for example in the form of a signature, by the issuing authority in order to be registered (i.e. logged) in the coin register.
  • Processing in the direct transaction layer only affects the ownership and/or the assignment of the coin data records to subscriber units of the respective electronic coin data records.
  • a registration of the respective processing in the coin register or the monitoring register is implemented, for example, by corresponding list entries in a database that includes a series of markings that must be carried out by the coin register.
  • a possible structure for a list entry includes, for example, column (s) for a predecessor coin data set, column (s) for a successor coin data set, a signature column for the issuer instance, a signature column for the sending and / or receiving security element, a Signature column for coin division operations and at least one marking column.
  • a change is final when and the required markings have been validated by the coin register or the monitoring register, ie after the corresponding check, for example, they have changed from status "0" to status "1". If a check fails or takes too long, it is instead changed from status to status "0", for example.
  • Other status values are conceivable and/or the status values mentioned here are interchangeable.
  • the statuses regarding the modifications are independent of the status during the transfer process (inactive/active).
  • the validity of the respective (masked) electronic coin data sets from the status values of the markings are summarized in one column for each masked electronic coin data set involved in registering the processing.
  • At least two, preferably three or even all of the aforesaid flags can also be replaced by a single flag which is then set if all tests have been successfully completed.
  • the two columns for predecessor data sets and successor data sets can each be combined into one in which all coin data sets are listed together. As a result, more than two electronic coin data sets could then also be managed per field entry, and thus, for example, a split into more than two coin data sets could be implemented.
  • a masked electronic coin data set is invalid if one of the following checks applies, i.e. if:
  • the masked electronic coin record is not the successor of a valid masked electronic record unless signed by the issuing authority;
  • the monetary amount of the masked electronic coin data record means that a limit value for a maximum permissible monetary amount, in particular per unit of time, is exceeded and the required deanonymization is rejected by the corresponding subscriber unit;
  • the payment system is preferably designed to carry out the above-mentioned method and/or at least one of the embodiment variants.
  • a further aspect relates to a currency system comprising an issuer entity, a coin register layer, a first security element and a second security element, the issuer entity being designed to create an electronic coin data record.
  • the masked electronic coin data set is designed to be demonstrably created by the issuing authority.
  • the verification layer is designed to perform a registration step as set forth in the above method.
  • the security elements, ie at least the first and second security element are preferably suitable for carrying out one of the above-mentioned methods (i) for transmission and (ii) for generating + encrypting + initiating.
  • the issuing entity is authorized to initially create an electronic coin data record and finally withdraw it.
  • Processing for example the step of connecting, splitting and/or switching, can and preferably is performed by a subscriber unit.
  • the deactivation processing step can preferably only be carried out by the publishing entity.
  • the coin register, the monitoring 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 transaction register is preferably arranged in a server instance that is different from the common server instance or is present there as a computer program product.
  • An electronic coin data record can be present in a large number of different forms and can therefore be exchanged via different communication channels, also referred to 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 the security element and/or the terminal 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 set.
  • the monetary amount and the blind signature are mapped as a file.
  • the electronic coin data record is, for example, a sequence of American Standard Code for Information Interchange, or ASCII for short, characters. In particular, the monetary amount and the 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 received as a QR code in a subscriber unit and can be output from the subscriber unit as a file or character string.
  • the data store is an internal data store of the subscriber unit.
  • the electronic coin data sets are stored here. This ensures easy access to electronic coin data sets.
  • the data memory is in particular an external data memory, 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 sets are not lost. Since owning the (unmasked) electronic coin records is equivalent to owning the monetary amount, using external data storage allows money to be stored and managed more securely.
  • the subscriber unit preferably has 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.
  • near-field communication is provided, for example by means of a Bluetooth protocol or NFC protocol or IR protocol; WL AN connections or mobile phone 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.
  • the interface for issuing the at least one electronic coin data record is 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 file format specific to electronic coin records can be used.
  • the coin data record is transmitted as an ASCII character string or as a text message, for example SMS, MMS, instant messenger (such as Threema or WhatsApp).
  • the coin record is transmitted as an APDU character string.
  • a purse application can also be provided.
  • the exchanging subscriber units preferably ensure that an exchange using the application is possible, ie that both subscriber units have the application and are ready to exchange.
  • the subscriber unit also has an interface for receiving electronic coin data records.
  • 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 dataset is a protocol interface for wirelessly receiving the electronic coin dataset from another security element or end device using a communication protocol for wireless communication.
  • a communication protocol for wireless communication In particular, near-field communication is provided, for example by means of a Bluetooth protocol or NFC protocol or IR protocol. Alternatively or additionally, WLAN connections or mobile radio connections are conceivable.
  • the interface for receiving the at least one electronic coin data record is a data interface for receiving the electronic coin data record from the other subscriber unit using an application. This application then receives the coin data set in a corresponding file format. A file format specific to coin records can be used.
  • the coin data record is transmitted as an ASCII character string or as a text message, such as SMS, MMS, Threema or WhatsApp.
  • the coin record is transmitted as an APDU character string.
  • the transfer can take place using a wallet application.
  • 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.
  • 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 sets.
  • a solution is therefore proposed here that issues digital money in the form of electronic coin data sets, which is based on the use of conventional (analog) banknotes and/or coins.
  • the digital money is represented here by electronic coin data sets.
  • (analogue) banknotes these electronic coin records will also be usable for all forms of payments, including peer-to-peer payments and/or POS payments. Knowing all the components (in particular the monetary amount and the obfuscation amount) of a valid electronic coin dataset is tantamount to owning (owning) the digital money. It is therefore advisable to treat these valid electronic coin data records confidentially, i.e. to store them in a security element/safe module (of an end device) and process them there, for example.
  • masked electronic coin data sets are kept in the coin register as a unique, corresponding public representation of the electronic coin data set. Knowing or possessing a masked electronic coin record does not constitute possession of money. Rather, it is like verifying the authenticity of the analog currency.
  • the coin register also contains, for example, markings about executed and planned processing of the masked electronic coin data set. From the markers to the A status of the respective masked electronic coin data record is derived from processing, which indicates whether the corresponding (non-masked) electronic coin data record is valid, ie ready for payment. Therefore, a receiver of an electronic coin data record will first generate a masked electronic coin data record and have the validity of the masked electronic coin data record authenticated by the coin register.
  • a great advantage of this solution according to the invention is that the digital money is distributed to terminals, dealers, banks and other users of the system, but no digital money or other metadata is stored in the coin register or the monitoring register - ie shared entities.
  • the proposed solution can be integrated into existing payment systems and infrastructures.
  • a payment process can take place with banknotes and/or coins, but the change or change is available as an electronic coin data set.
  • ATMs with an appropriate configuration, in particular with a suitable communication interface, and/or mobile terminals can be provided for the transaction.
  • an exchange of the electronic coin data record for banknotes or coins is conceivable.
  • steps of creating, switching, splitting, connecting and deactivating (returning) listed here are each triggered by a corresponding create, switching, splitting, connecting or deactivating command (return commands).
  • Fig.la,b an embodiment of a payment system according to the prior art
  • FIG. 2 shows an embodiment of a payment system according to the invention
  • FIG. 3 shows an exemplary embodiment of a method flow chart of a method according to the invention in a subscriber unit; 4 shows an exemplary embodiment of a method flow chart of a method according to the invention in a transaction register;
  • FIG. 5 shows an exemplary embodiment of an encryption and decryption of a transaction data record
  • FIG. 6 shows a further development of the exemplary embodiment of a payment system from FIG. 2;
  • Fig. 7 shows an alternative development of the embodiment of a payment system
  • FIG. 8 shows an embodiment of a coin register and monitoring register
  • FIG. 9 illustrates one embodiment of a system in accordance with the invention for splitting and switching and direct transmission of electronic coin records
  • FIG. 10 shows an embodiment of a payment system according to the invention for connecting electronic coin data sets
  • FIG. 11 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a
  • FIG. 12 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a
  • FIG. 13 shows an exemplary embodiment of a security element according to the invention
  • FIG. 1a and 1b show an exemplary embodiment of a payment system according to the prior art. These Fig.la and Fig.lb have already been described in the introduction to the description. It is repeatedly pointed out that a terminal M8 would like to register the coin data record C c as the coin data record C e in the coin register 2 and the coin register 2 determines that the coin data record C b is already invalid. As a result, the coin register 2 accepts neither the supposedly valid coin data set C c nor the coin data set C e to be switched over .
  • the problem can occur when, for example, an attacker with terminal Ml is a further Münz Scheme C b (pirated) at two terminals M2 and M3 directly. As soon as one of the two participants with the terminal M2 registers the coin data record in the coin register 2 (so-called coin conversion), the coin data record C b becomes invalid. Instead, an unsuspecting subscriber with terminal M3 forwards the coin data set C b directly to terminal M5 without having it registered. Only terminal M7 breaks through the direct transmission chain and shows the coin data set C b in coin register 2. At the same time, the subscriber with terminal M2 divides the coin data set C b into coin data sets C c and C x and forwards C c directly to terminal M4.
  • Terminal M4 forwards the coin data set C c directly to terminal M6.
  • Terminal M6 forwards the coin data record C c directly to terminal M8.
  • An attack double issuing of an electronic coin data record
  • M1 is therefore only discovered late in the prior art and a large number of direct transmissions were carried out in an unauthorized manner.
  • the risk that manipulation(s) have been carried out on the electronic coin data set increases.
  • the coin data set should expire, i.e. on the one hand the number of direct transmissions of coin data sets should be limited and on the other hand it should be possible to trace who caused the attack if an attack is detected (Here terminal Ml) has carried out.
  • a method/system is described below in which transaction data from subscriber units (terminals or security elements) are archived in a remote transaction register and can be checked in the event of an official decision.
  • the payment system comprises at least two, preferably a large number of subscriber units TEs, which are also referred to or illustrated below as security elements SEx or terminal devices Mx, and a transaction register.
  • the payment system can use it
  • at least one issuing authority 1 one or more commercial banks, one (or more) central coin register 2, which registers the coin data sets and checks and logs the modifications to the coin data set.
  • the payment system BZ includes at least two security elements SEI and SE2.
  • the 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.
  • a transaction register 4 of the payment system BZ is shown.
  • an issuer entity for example a central bank, which generates the electronic coin data record C in addition to the person assignment 7.
  • a masked electronic coin data set Z is generated for the electronic coin data set C and registered 104 in a coin register 2 of the payment system.
  • the masked electronic coin data record Z is output to the coin register 2, for example, by the issuing entity 1 directly or via the first terminal M1.
  • the masked electronic coin data set Z is alternatively generated by the first terminal M1 (or second terminal M2) and sent to the coin register 2 in step 104.
  • a transaction data set TDS is generated in the first terminal M1.
  • the transaction data record TDS has a subscriber ID of the sending terminal device Ml, a subscriber ID of the receiving terminal device M2, optionally a transaction number, optionally a monetary amount of the coin data record, optionally a masked coin data record Z corresponding to the electronic coin data record C (masking is explained later ) and optionally a transaction time.
  • Each subscriber ID of a terminal device is assigned to a natural person throughout the pay system. This assignment of persons 7 is carried out and also managed here, for example, by an editorial authority. This assignment 7 is only carried out after the person has been successfully identified by presenting an identity card or passport. This assignment 7 can be changed at the request of the person, for example when changing the subscriber unit or adding another subscriber unit.
  • This cryptographic key is, for example, a public key part of a corresponding composite private key part.
  • This private key part is composed of three partial keys 8a, 8b, 8c, the partial keys 8a, 8b, 8c being added or XORed, for example.
  • This combination of the partial keys 8a, 8b, 8c takes place either in the first terminal M1 or in the transaction register 4.
  • This combination of the partial keys 8a, 8b, 8c is, for example, secret throughout the system. Knowing or possessing only one partial key 8a, 8b, 8c does not allow the transaction data record TDS to be decrypted.
  • FIG. 5 shows an embodiment for encrypting and decrypting a transaction data record TDS.
  • the encrypted transaction data record TDS is sent from the first terminal M1 to the transaction register 4 and stored there.
  • the time of sending is preferably closely linked to the transmission 105 of the electronic coin data record, so that the transaction register 4 is always up to date on the transactions carried out in the payment system BZ.
  • an official decision for example a court decision, could be ordered to decrypt the encrypted transaction data set TDS in order to uncover and analyze the transaction recorded therewith (the transmission 105).
  • all stored transactions would then be queried, for example, at the transaction register 4 for a terminal M (using the identifier) over a specific point in time or a specific period of time.
  • other attributes of the transaction data such as the monetary value of the coin data sets, the respective transaction partners, etc., could be queried.
  • the transaction data can be decrypted by a plurality of remote entities as authorized parties generating (or providing) a decryption key by combining their partial keys.
  • the remote entities are, for example, law enforcement agencies, notaries, the Ministry of Justice, a central bank or others.
  • All remote entities (authorized parties) only have partial keys 8a, 8b, 8c of the decryption key. All members or a minimum number n of m remote entities are required to jointly decrypt the transaction data record TDS. From a technical point of view, the individual sub-keys 8a, 8b, 8c of the various remote entities are assembled into a common private key part by addition or by bit-by-bit XOR linking. This private key part (which corresponds to the corresponding public key part of the encryption) is then used to decrypt the transaction data record TDS. This concept guarantees that no remote entity alone can decrypt the TDS transaction record and thus bypass other entities.
  • threshold cryptography could be applied to use a subset n of these subkeys 8a, 8b, 8c. This subset n then defines the minimum number of partial keys 8a, 8b, 8c to be combined.
  • the payment system shown in FIG. 2 has a three-layer structure.
  • the issuing authority for example a central bank, is responsible for money creation and destruction, as will be explained later.
  • Commercial banks can store coin data sets C, for example in vault modules that are designed as highly secure modules, for example as HSMs. Distributes money to users and sends or receives money to/from the central bank.
  • the coin register 2 and the transaction register 4 are provided in a second layer.
  • This layer serves to check the coin data sets C, in particular the validity and authenticity of the coin data sets C in circulation, and checks whether coin data sets C have been issued twice.
  • the trade register 4 is provided. It is also conceivable to decouple this transaction register 4 from the payment system BZ in order to follow the principle of "separation of concerns". For the sake of simplicity, the trade register 4 is subsequently assigned to the second layer of the payment system BZ.
  • the Trade Repository 4 as a trusted authority, is responsible for protecting people's privacy in regular situations and disclosing encrypted transaction records TDS when required by court decisions.
  • the Trade Repository 4 is an extension for use cases in law enforcement, with the aim of uncovering suspicious transaction data.
  • the trade repository 4 stores encrypted data records about transactions that are (must) be reported by the participants involved and forwards them to the authorities according to due process.
  • the transaction data records TDS are stored in encrypted form in the transaction register 4 . This ensures that due process must be followed and no one can access this sensitive transaction data at will.
  • a re-encryption unit can be deployed in the trade repository, which re-encrypts the TDS so that a law enforcement agency only has access to officially approved data. Metadata such as transaction time and participant ID are used to provide the requested data.
  • the transcoding unit can access and decrypt all data.
  • the third layer is a direct transaction layer 3 in which all participants, ie consumers, dealers, etc., participate equally via their subscriber units TE in order to exchange electronic coin data records C.
  • Each subscriber unit TE can have a wallet application have to manage coin records C.
  • subscriber units TE can directly (directly) interact with other subscriber units TE.
  • the actual data transfer for a coin record may involve other intervening entities.
  • This offline design of the payment system BZ makes it necessary for the coin data records C to be kept in certified areas, for example a purse application, ideally within security elements SE, for example smart cards or an eSim environment, in order to obtain trustworthiness in the payment system BZ.
  • the transmission 105 takes place, for example, wirelessly via WLAN, NFC or Bluetooth, ie preferably locally.
  • the transmission 105 can be additionally protected by cryptographic encryption methods, for example by negotiating a session key or by using a PKI infrastructure.
  • the transmission 105 can also take place using an online data memory, from which the electronic coin data set C is transmitted to the TE2 (M2, SE2).
  • a secure channel is set up between the SEI and the SE2, within the framework of which both SEs authenticate one another.
  • the transmission path between SEI and SE2 is not necessarily direct, but can be an Internet or near-field communication path with entities connected in between (end devices, routers, switches, applications).
  • SEs as a secure environment instead of terminals ME as TEs, a higher level of trust is generated, ie trustworthiness in the payment system BZ is increased.
  • a timer is optionally started at the same time as the eMD C is sent or immediately before or after it. Before that, the eMD C can be invalidated and then no longer used by the SEI for actions (as described below). The eMD C is thus blocked in the payment system BZ due to a transmission process 105 that has already been initiated (and has not yet ended). This prevents double spending. Invalidating allows for easy handling during the transfer process 105.
  • the SE2 If the eMD C is properly received in the SE2, the SE2 generates an acknowledgment of receipt and sends it back to the SEI.
  • the acknowledgment of receipt from the SE2 can be sent as a deletion request, because the eMD C can (may) only be validated and used in the SE2 after the eMD C has been deleted in the SEI.
  • deleting the eMD C are displayed by the SEI. In this case, for example, an amount display of the SEI (or a terminal ME1 in which the SEI is logically located) is updated. For example, the monetary amount of the eMD C is subtracted from an amount of the SEI available for payment transactions.
  • a deletion confirmation can be sent from the SEI to the SE2.
  • the SE2 can convert the status of the eMD C in the SE2 into an active status, the eMD C is thus validated and can be used for further payment transactions or actions (split, combine, switch) in the SE2 from this point in time .
  • the eMD C of the SE2 in coin register 2 is switched to the SE2 (see below), whereby the eMD C is registered to the SE2 (step 104).
  • a transmission error in the transmission 105 can be determined in the SEI, for example by exceeding a predefined period of time, indicated by a timer or by receiving an error message from SE2 or the terminal M1 or the other terminal M2 (not shown). For example, a counter value can be incremented with each new attempt to transmit the eMD C (RETRY) and if a maximum permissible number of retries is exceeded, for example 10 or 5 or 3 times, it is decided in step 308 automatically and independently of the error that no new Sending attempt (RETRY) is carried out, but the transmission 105 is to be ended as unsuccessful and a ROLLBACK has to be carried out.
  • RETRY a maximum permissible number of retries
  • the status of the eMD is reported to the coin register 2 by the SEI.
  • a connection is then established with coin register 2 to query the status of the eMD C. If the coin register 2 continues to report an inactive status to the eMD C (registered on the SEI), no transaction error (manipulation attempt) is assumed. However, if the coin register 2 reports an active status to the eMD C or a registration to another SE, a transaction error (attempted manipulation) is assumed and the payment system is alarmed.
  • the transaction data record TDS of the SEI is used as evidence.
  • the electronic coin data record C can be requested in advance from an issuing entity 1 and optionally received by a terminal M (or an SE) or the issuing entity 1 or another payment system. Steps 104 and 105 may correspond to steps 104 and 105 of FIG. An action (split, connect, switch, transfer, redeem, change) on the eMD C can correspond to one of the actions of FIGS. 9 to 12.
  • a genuine random number is generated as the concealment amount n.
  • the concealment amount n is linked to a monetary amount Ui.
  • a valid electronic coin record can be used for payment.
  • the owner of the two values Ui and r 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 masked electronic coin data set Zi.
  • a masked electronic coin data set Zi is obtained 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 the 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.
  • Equation (3) is a "Pederson commitment for ECC" that ensures that the monetary amount Ui can be granted to a coin register 2, i.e. "committed”, without revealing it to the coin register 2.
  • the public and remote coin register 2 is therefore only sent (revealed) the masked coin data set Zi, which is shown in FIG. 2 as step 104 (registration).
  • equation (3) enables a cryptographically strong Zi to be obtained even with a small value range for monetary amounts Ui. Therewith 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:
  • Equation (3) allows monitoring of valid and invalid electronic Münz Schemesn Ci to lead on the sole basis of the masked Münz Scheme Zi and to ensure that no new monetary amount U j has been created.
  • the coin data set Ci can be divided according to equation (1) into:
  • Equation (9) can be used to check, for example, a "symmetric or asymmetric splitting" processing or a "symmetric or asymmetric splitting” processing step of a coin data set according to FIG. 9 or 12 in a simple manner, without the coin register 2 being aware of Ci , Ck has.
  • the condition of equation (9) is checked to validate split coin data sets and C k and invalidate coin data set Ci.
  • Such a partitioning of an electronic coin record Ci is shown in FIG. 9 or 12.
  • FIG. Electronic coin data records C can also be combined (connected) in the same way, see FIG. 10 or 11 and the explanations relating thereto.
  • Cij - aj H (9d) it being possible in one embodiment to carry out a ring signature only for certain bits.
  • FIG. 3 shows an exemplary embodiment of a method sequence diagram of a method 300 according to the invention in a subscriber unit TE, also referred to below as terminals M or security elements SE.
  • the blocks of the method 300 shown in dashed lines are optional. Each of these steps may involve user interaction or at least user informing, for example via a GUI of the TE.
  • a transaction data record TDS is generated.
  • the transaction data record TDS includes the subscriber identifiers from the first subscriber unit TE1 (sending TE) and from the second subscriber unit TE2.
  • information about the electronic coin data set C to be transmitted (or transmitted) is included, for example the monetary value v.
  • the masked electronic coin data record Z can be introduced into the TDS.
  • a transaction time can be contained in the TDS, which characterizes the time of the transmission 105 of the electronic coin data record C between the two subscriber units TE.
  • the time of generation 301 can be closely coupled in time to the time of transmission 105 .
  • a specification of the payment system BZ can require that the electronic coin data record C must first be transmitted (step 105) before the encrypted transaction data record TDS is to be sent.
  • the generated transaction data record TDS is encrypted.
  • the first subscriber unit TE1 has a public key part K, which is made up of partial keys from different remote entities.
  • the key composition is shown in FIG.
  • the subscriber unit TE1 receives a corresponding cryptographic key K in step 302, for example when the transaction register 4 requests the key.
  • the key K can be a key of a PKI structure or a symmetric key.
  • step 303 the transaction data record TDS is then encrypted with the cryptographic key K in the first subscriber unit TE1, for example by an encryption module or a processing unit of the first subscriber unit TE1.
  • FIG. 3 Not shown in FIG. 3 is an optional linking step of (plain text) metadata to the encrypted transaction data record TDS, for example an identifier of the first subscriber unit TE1, an identifier of the second subscriber unit TE2 and/or a transaction time.
  • This metadata allows the encrypted TDS stored locally and/or in the trade repository 4 to be indexed or catalogued.
  • step 304 a communication link to the transaction register 4 is then initiated. An attempt is thus made to set up a communication channel between the first subscriber unit TE1 and the transaction register 4 . Initiating also includes the respective subscriber unit TE recognizing/knowing that an offline transaction is currently planned/performed and no connection to the remote transaction register 4 can or should be established.
  • step 305 the subscriber unit TE1 is queried as to whether a connection could be set up in step 304.
  • test step 305 the encrypted transaction data record TDS is sent to the transaction register 4 in step 306 . If necessary, further transaction data records TDS from earlier transmissions of electronic coin data records C are also sent, should these communications link may have been established for the first time since those transmissions. In this context, a check value is then also reset (not shown in FIG. 3), which represents a number of transmissions of electronic coin data sets C that took place without sending a transaction data set TDS. In a test step 305a, a query may be made as to whether a transmission error occurred when the encrypted transaction data record TDS was sent 305 .
  • the encrypted and/or the unencrypted transaction data record TDS is then optionally stored locally in the first subscriber unit TE2 for archiving purposes or for storing a history or for queries based on official requests.
  • the electronic coin data record C is then transmitted to the second subscriber unit TE2 in step 105 if a specification in the payment system BZ is that the encrypted transaction data record TDS is to be sent first before the electronic coin data record C can be transmitted in step 105.
  • the masked electronic coin data record Z after the transmission 105, the masked electronic coin data record Z must be registered 104 in the coin register 2 it is described in Figures 7, 15 and 16.
  • test step 305 (offline transaction, flight mode, no transmission of the transaction data TDS (from the subscriber) desired) and also in the yes case of test step 305a (transmission error, connection termination), a connection error is determined in step 307.
  • a test value p is compared with a threshold value X in the first subscriber unit TE1.
  • the check value in step 308 represents a number of (offline) transmissions 105 of electronic coin data sets C that took place without sending a transaction data set TDS. These (offline) transmissions 105 originating from the first subscriber unit TE1 can have been transmitted to any other subscriber unit TEx. If test step 308 is yes, i.e.
  • test value p is greater than the threshold value X, for example 100 or 50 or 10 transmissions, the transaction data record TDS is stored (encrypted and/or unencrypted) and step 304 must be repeated. If the test step 308 is not, the transmission 105 takes place if a specification in the payment system BZ is that the encrypted transaction data record TDS is to be sent first before the electronic coin data record C may be transmitted in step 105 . In step 310, the test value p is then incremented, i.e. increased in stages, preferably increased by 1.
  • Steps 308 to 310 ensure that the offline behavior of the subscriber units TE remains monitored and does not go beyond a predefined, specific (system-specified) threshold value X of the number of transmissions.
  • Transaction data records TDS of an offline transaction that cannot be sent immediately, i.e. a transmission 105 without registering 104 or reporting to one of the register instances 2, 4, 6 of the Payment system BZ are temporarily stored in step 309 and sent at a later time.
  • the number of offline transactions that a subscriber unit TE is allowed to carry out is limited by the system and checked using the test value p in step 308. If the threshold value X is reached, the transaction data records TDS must first be sent before another offline transaction 105 is possible (see step 309 to step 304).
  • This test value p can be recorded and managed independently of other tests in the subscriber unit TE.
  • This check value p can be combined with other check or counter values pu, pu of the coin data set C for checking in the coin register 2 or the monitoring register 6, see payment system BZ in FIG. 6.
  • a general first specification in the payment system BZ can be that coin data records C are only transmitted between TEs before a transaction data record TDS is created for this. A TDS would then always relate to a coin data set C that has already been transmitted; step 105 would have to be carried out before the associated steps 301, 303.
  • a general first specification in the payment system BZ can be that coin data records C are only transferred between TEs (step 105) after a transaction data record TDS has been created for this (step 301). A TDS would then always relate to a coin data set C still to be transmitted, step 105 would have to be carried out after the associated step 301.
  • a second general specification in the BZ payment system could relate to the local storage of the TDS in the TE. It may be required that TDS are also stored locally (ie history or archiving). The storage step 309 should then not only be provided for transmission repetitions (in the event of an error in a first transmission attempt). It can be a default detail that the TDS are also to be stored encrypted in the TE.
  • This local storage of the TDS which is redundant to the storage of the TDS in trade repository 4, can also be read out as part of an official request (a court order), i.e. the participant can be forced to provide this local storage or the transfer of the local storage in take place in a (background) process of the subscriber unit TE without subscriber interaction.
  • a third general specification in the payment system BZ can be to store pseudonymised TDS * in a monitoring register 6 of the payment system BZ. These pseudonymised TDS * are taken into account when validating the coin data sets in order to be able to detect fraud scenarios within the payment system.
  • a fourth general requirement in the payment system BZ can be not to send encrypted TDS to the trade register 4 when an offline transaction is planned/performed.
  • This requirement can be tightly coupled to the test value p, so that a subscriber unit TE issues a warning to the subscriber even before selecting a transmission mode (online or offline) that a test value p has exceeded a threshold value for the maximum number of offline transmissions 105 and no further offline transmission is possible without prior sending of the (old) TDS to the trade repository 4 (with reset of the check value counter).
  • FIG. 4 shows an exemplary embodiment of a method flow chart of a method 400 according to the invention in a transaction register 8 .
  • the blocks of the method 400 shown in dashed lines are optional.
  • step 401 an encrypted transaction data record TDS is received by a subscriber unit TE in the transaction register 4 .
  • This transaction data record TDS was generated according to the method shown in FIG.
  • step 402 it is checked whether different generations of partial keys are present in the payment system BZ, for example the transaction register 4, preferably an HSM module within the transaction register 4 as a key memory. If step 402 is yes, the transaction data record TDS is decrypted with the private key part k of the cryptographic key as the decryption key in step 403 and encrypted again with a cryptographic key, for example with an HSM key of the trade repository 4. In this way it can Storage of differently encrypted transaction records TDS, which are encrypted with different key versions of the remote entities, in the transaction register 4 can be prevented. The administrative effort in the trade register 4 is thus reduced.
  • the transaction data record TDS is stored in a memory area and archived there. If necessary, the transaction data record TDS has metadata in plain text, which is entered or tracked in a database of the transaction register 4 . If, for example, a transaction time is available as metadata of the TDS, a deletion time can be generated as part of data retention. The TDS would then be automatically deleted from the trade repository 4 after a set period of time (the time of deletion) has elapsed.
  • the TDS are stored in encrypted form in the transaction register 4 (e.g. a database as a trustworthy entity), and several partial keys are required for their decryption are. This ensures that due process must be followed and no one can access sensitive TDS transaction data at will.
  • the transaction register 4 e.g. a database as a trustworthy entity
  • step 405 partial keys of the cryptographic key k are received and combined in step 406 in the transaction register 4, for example to form the private key part of the private key part when using a PKI key structure.
  • the combination is secret, for example, in order not to allow owners of the partial keys 8a, 8b, 8c to combine the decryption key.
  • the combined key can also be composed of only a subset of partial keys, which is possible by using threshold cryptography.
  • a decryption request is made to the trade register 4 in step 407.
  • the metadata of the transaction data records can be matched with parameters of the decryption question, for example to query all transaction data records with a specific participant ID for a specific point in time or period.
  • each remote entity is requested to authenticate itself at the transaction register 4.
  • only a subset of remote entities required to decrypt the desired transaction data record(s) TDS is queried.
  • the decryption then takes place with the combined key from the jointly present partial keys of the remote entities.
  • a subscriber unit identifier in the decrypted transaction data record TDS is replaced by a pseudonym of the subscriber unit TE.
  • the pseudonym preferably corresponds to the pseudonym of FIGS. 7, 15 and 16. This changes an anonymity level for the TDS so that the TDS can be used in unencrypted form for checking coin data records.
  • a monetary amount in the decrypted transaction data record TDS is replaced by one or more amount categories.
  • the monetary amount of the coin data set C is rounded up or down, for example:
  • the monetary amount is sorted into one or more amount categories that represent amount ranges, for example:
  • Steps 410 and/or 411 can be performed by an HSM in the trade repository 4 .
  • the pseudonymised transaction data TDS * and/or the amount-categorized transaction data are sent (back) in step 412 to the monitoring register 6 or the subscriber unit TE. changed for the respective transaction record.
  • the encrypted transaction data records TDS are stored in the transaction register (step 404, possibly after step 412).
  • the pseudonymised transaction data set TDS * always has a higher level of anonymity than the (non-pseudonymised) transaction data set TDS.
  • the pseudonymised transaction data record TDS * can also be stored unencrypted in the coin register 2, monitoring register 6 and/or the transaction register 4 - as specified by the payment system BZ - and used for further validity checks in the payment system BZ. This would allow cases of fraud or manipulation in the BZ payment system to be better detected by the BZ payment system itself, and an official request (judicial decision) may then not be necessary.
  • FIG. 5 shows an exemplary embodiment of an encryption and decryption of a transaction data record TDS.
  • the remote instances 8a, 8b, 8c each have partial keys whose bitwise addition results in a private key part k of a cryptographic key (key pair).
  • the private key part k is stored, for example, in a key memory of the transaction register 4, for example a hardware security module of the transaction register 4.
  • the public key part K is derived from the private key part k and made available to the subscriber unit TE.
  • the encryption step 303 in FIG. 3 of the generated transaction data record TDS or the re-encryption step 403 in FIG. 4 of the decrypted transaction data record TDS is then carried out with the public key part K.
  • This asymmetric crypto-system must ensure that the public key part K is actually the key part derived from the combined private key part k and that this is not a forgery by a fraudster.
  • Digital certificates that confirm the authenticity of the public key part K are used for this purpose.
  • the digital Certificate can itself be protected by a digital signature.
  • the transaction data record TDS encrypted with the public key part K is stored in the transaction register 4 .
  • the subset or all remote entities must authenticate themselves to the transaction register 4 . If authentication is successful, the transaction data record TDS is decrypted using the private key part k.
  • the generated transaction data record consists, for example, of a transaction number, a recipient address (here from TE2), a sender address (here from TE1) and a monetary amount of the eMD C.
  • the generated transaction data record can also be used in TE1 to log the transmission 105 in order to be used in the transmission - carry out a reversal (ROLLBACK) or repetition (RETRY) of the transmission 105 in the event of an error.
  • ROLLBACK reversal
  • RETRY repetition
  • FIG. 6 shows a further development of the exemplary embodiment of a system in FIG. 2. Reference is made to the statements in FIG. 2 to avoid repetition.
  • At least one check value pu can also be kept in the electronic coin data set C as a further data element.
  • This test value pu is incremented as subscriber units TE1, TE2 with each direct transmission 105 of this electronic coin data record C between subscriber units TE1, TE2, ie terminals M1, M2 or security elements SEI, SE2.
  • a counter value pu can also be managed or determined, which includes the check value pu, for example as the sum of the previous (registered) counter value pu and the check value pu, in order to determine whether the coin data record C is to be returned.
  • Each action with the coin data set C increases this counter value pu.
  • Different action types weight the counter value pu differently, so that, for example, a direct forwarding of the coin data set C has a higher weight than a modification (dividing, combining, switching). In this way, the service life and the actions carried out in a coin data record C are evaluated and criteria for its return are defined according to the actions carried out.
  • the test value pn and also the counter value pu map the life cycle of the coin data set C, on the basis of which a decision is then made about a return.
  • a check value p can be provided in the payment system BZ in a subscriber unit TE (ie the terminals M1, M2 or security elements SEI, SE2 shown in FIG. 6) which indicates the number of coin data sets C already transmitted without ( immediate) associated transmission of an encrypted transaction record TDS to the Trade repository 4 represents.
  • This test value p is compared with a threshold value X in step 307 when a connection error is detected. In the process, it is determined whether a further (offline) transmission 105 may be carried out (payment system specification) or not.
  • FIG. 6 shows transaction register 4, which has already been described with reference to FIGS.
  • the transaction register 4 can be in communication with the monitoring register 6 in order to register pseudonymised transaction data sets TDS* in the monitoring register 6 .
  • a subscriber unit identifier in the decrypted transaction data record TDS is replaced by a pseudonym P for the subscriber unit TE.
  • a monetary amount in the decrypted transaction data record TDS is replaced by an amount category.
  • Steps 410 and/or 411 can be performed by an HSM in the trade repository 4 .
  • the pseudonymised transaction data TDS * and/or the amount-categorized transaction data TDS * are sent to the monitoring register 6 according to step 412, while the encrypted transaction data records TDS are stored in the transaction register 4.
  • a masked electronic coin data set Zi for example in the SEI, is calculated from the electronic coin data set Ci using equation (3), and this masked coin data set Zi is registered in a monitoring register 6 together with at least the second check value pu.
  • the transmitted electronic coin data set Ci is received as Ci * .
  • the SE2 Upon receipt of the electronic coin data set Ci * , the SE2 is in possession of the digital money that the electronic coin data set Ci * represents. With the direct transmission 105 it is available to the SE2 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.
  • the masked transmitted electronic coin data record Zi* can be calculated in SE2 with the—public—one-way function from equation (3).
  • the masked transmitted electronic coin data set Zi * is then transmitted to the coin register 2 in step 104 and searched for there.
  • 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 data set Ci.
  • 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 set C and the subscriber unit TE can be recorded in a monitoring register 6 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
  • 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” an electronic coin data set C are only carried out in secure locations and/or only by selected entities, for example the issuing entity 1, while the operations of all other processing operations are carried out on the subscriber units TE, i.e. the terminals M or whose security elements SE can be executed.
  • the number of operations for each processing is marked in Table 1 with "0", "1" or "2".
  • the number “0” indicates that a subscriber unit TE or the issuer entity 1 does not have to carry out this operation for this processing of the electronic coin data record C.
  • the number “1” indicates that the subscriber unit TE or the issuer entity 1 must be able to perform this operation once for this processing of the electronic coin data record C.
  • the number “2” indicates that the subscriber unit TE or the issuer entity 1 must be able to carry out this operation twice for this processing of the electronic coin data record.
  • one embodiment can also provide for an area check to be carried out by the issuing authority 1 when creating and/or deleting.
  • Table 2 below lists the operations required for the coin register 2 and/or the monitoring register 6 for the individual processes:
  • Table 3 shows the components to be preferably installed for the system participants in the payment system of FIG. 1:
  • Table 3 shows an overview of the components to be used preferably in each system participant, i.e. the issuing entity 1, a subscriber unit TE and the register entities, namely the coin register 2, the monitoring register 6, the transaction register 4.
  • the subscriber units TE can be designed using an e-wallet for electronic coin data sets Ci (with the test value p, pn pn), i.e. as an electronic wallet with a memory area in which a large number of coin data sets Ci can be stored, and thus, for example, in the form of an application a smartphone or a retailer’s IT system, a be implemented by a commercial bank or another market participant.
  • the components in the subscriber unit TE as shown in Table 3 are implemented in software.
  • the coin register 2, trade register 4 and/or monitoring register 6 are assumed to be server or DLT based and operated by a number of trusted market participants.
  • FIG. 7 shows an alternative development to FIG. 6 of the exemplary embodiment of a system from FIG. 2. Reference is made to the explanations of FIG. 2 and FIG. 6 to avoid repetition. The configurations of FIG. 7 can also be combined with the configurations of FIG. 6 .
  • Fig. 7 shows an embodiment of a payment system BZ with terminals Ml and M2 (as examples of subscriber units TE), an issuer entity 1, a coin register 2, a monitoring register 6 and a transaction register 4.
  • the terminals Ml and M2 can also be devices or security elements SEI , be SE2.
  • the coin register 2 contains a register 210 in which valid masked electronic coin data sets Zi are stored.
  • the electronic coin data record Ci represents a monetary amount Ui.
  • the electronic coin data set Ci is output to a first terminal Ml.
  • Electronic coin data sets Ci preferably for which a masked electronic coin data set Zi is registered, can be used for payment.
  • the masked electronic coin data record Zi can also be referred to as an amount-masked electronic coin data record, since the monetary amount Ui is unknown to the coin register 2 (and also remains unknown later on).
  • a recipient, for example a second terminal M2 here, of the electronic coin data set Ci can check its validity using the coin register 2 .
  • the coin register 2 can confirm the validity of the electronic coin data set Ci using the masked electronic coin data set Zi.
  • the masked electronic coin data set Zi is an anonymous electronic coin data set, particularly since it does not know the owner of the associated electronic coin data set Ci.
  • the anonymity level of a masked coin data record Zi in the register 201 of the coin register 2 is accordingly level 1 (completely anonymous).
  • the coin register 2 processes the masked electronic coin data record Zi* sent anonymously in an anonymous mode 2a in which, for example, the second terminal M2 is only confirmed that the masked electronic coin data record Zi* sent is valid.
  • the coin register 2 stores in the register 210 anonymous (amount) masked coin data sets Zi from electronic coin data sets Ci of the issuer entity 1 or from modified electronic coin data sets of the terminals M.
  • FIG. 7 also shows that the second terminal M2 can also send masked electronic coin data sets Si* to the monitoring register 6 in a pseudonymized mode M2p.
  • the second terminal M2 links, for example, the masked electronic coin data set Zi * with a pseudonym P M 2 and sends the pseudonymized masked electronic coin data set Si * to the monitoring register 6.
  • the second terminal M2 could a pseudonymized masked electronic coin data set Si * by appending the pseudonym P M 2 to generate the masked electronic coin data set Zi*.
  • the second terminal M2 creates a signature via the masked electronic coin data record Zi* and adds the signature to the coin data record Zi*.
  • the public key of the signature key pair can serve as the pseudonym P M 2 .
  • the pseudonym P M 2 is derived from a subscriber identifier, such as a terminal number, IMEI, IMSI or a similarly derived identifier.
  • the pseudonym P may be a derivation of the subscriber unit identifier mentioned above.
  • the pseudonym P can also be listed in the person assignment 7 of the publishing entity 1 (or alternatively of a service provider, for example a purse application provider or an online storage provider) next to the subscriber unit identifier.
  • the pseudonym P can only be assigned to a natural person in a trustworthy authority.
  • the monitoring register 6 processes the pseudonymously transmitted masked electronic coin data record Si* in a pseudonymous mode 2p, in which the second terminal M2 is also confirmed that the transmitted masked electronic coin data record Zi* is valid.
  • the assignment of the masked electronic coin data record Zi to the pseudonym P M 2 is additionally stored in a data structure 220 of the monitoring register 6 .
  • the data structure 220 can be used as a register for masked electronic coin data sets Zi that are still to be checked, ie can also fulfill the function of a coin register 2 .
  • the monitoring register 6 postpones or skips in particular a verification step carried out in the anonymous mode 2a (more frequently or always).
  • the checking step it is checked—preferably still without knowing the monetary amount Ui—whether the monetary amount Ui of the masked electronic coin data record Zi is within a range.
  • the aspects described below build at least partially on details of this embodiment of FIG. 2, 6 or 7.
  • the more complex pseudonymous mode 2p or M2p is primarily described there, since the simpler anonymous mode 2a or M2a runs without a pseudonym (or signature).
  • configurations are described in FIGS. 15 and 16 which can only optionally be combined with the details of the other configurations.
  • Figure 8 shows a data structure for a coin register 2 and/or a monitoring register 6 of the previous figures.
  • data from the coin register 2 and/or the monitoring register 6 are shown together in a common data structure as a table for illustration purposes.
  • the registers 2, 6, the masked electronic coin data sets Zi and possibly their processing are registered.
  • the coin register 2 and the monitoring register 6 can be accommodated in a common server instance and are only logically separated from one another in order to be able to reduce the computing effort for the individual checks through strict assignments.
  • the registers 2, 6 are also physically separated from one another. Both registers 2, 6 are preferably arranged locally at a distance from the subscriber units TE and are housed, for example, in a server architecture.
  • 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.
  • the "Create” and “Deactivate” processing which per se affects the existence of the monetary amount Ui, i.e. the creation and destruction of money, requires additional approval by the issuing authority 1 in order to be in the coin register 2 and/or the Monitoring register 6 registered (ie logged) to be.
  • the respective processing is registered, for example, by corresponding list entries in the database according to FIG.
  • Each list entry has further markings 25 to 28, which document the intermediate results of the respective processing, which must be carried out by the coin register 2 and/or the monitoring register 6.
  • the markings 25 to 28 are preferably used as an aid and are discarded after the commands from the coin register 2 and/or the monitoring register 6 have been completed.
  • the checks corresponding to the markings 27b and 27c are not necessary for pseudonymised coin data records because they are carried out later in a different form.
  • the checking steps of the markings 25, 26, 27a and 28, on the other hand, are necessary.
  • necessary or validity-relevant test steps and subsequent or validity-independent test steps are referred to in part, since they are directly or indirectly made up for.
  • a coin record can be treated as valid if the necessary checks have been made.
  • the data highlighted in bold in columns 24, 28 and 29 in Fig. 8 are only relevant for coin data records received in pseudonymised form and therefore primarily relate to entries in the monitoring register 6.
  • An optional marker 29 can indicate the completion of processing, for example.
  • the markings 29 are, for example, in the state and are set to the state “1” after all tests have been successfully completed (for markings 25-28) and are set to the state “0” if at least one test has failed.
  • a (completion) marking 29 with the value "2" could indicate, for example, that only the necessary tests were completed and tests that could be made up for were omitted. If checks for one or more entries are made later by the end device with the pseudonym, the marking can be set to the value "1".
  • the markers 27b and 27c of the examinations to be made up for could of course also be used and/or a separate pseudonym marker could be used.
  • a possible structure for a list entry of a coin data record includes, for example, two columns 22a, 22b for a predecessor coin data record (Ol, 02), two columns 23a, 23b for a successor coin data record (Sl, S2), a signature column 24 for signatures from Issuer entity(s) 1 and signatures of terminals M, and six marking columns 25, 26, 27a, 27b and 27c and 28.
  • Each of the entries in columns 25 to 28 has three alternative states or "0".
  • Column 25 indicates whether a validity check in column 22a/b with regard to an electronic predecessor coin data set was successful.
  • the state "1" means that a Validity check determined that the column 22a/b electronic coin record is valid and the status "0" indicates that a validity check determined that the column 22a/b electronic coin record is invalid and the status indicates that a validity examination is not yet completed.
  • a common O-flag both valid is preferred for multiple predecessor coin data sets rather than two separate O-flags.
  • Column 26 indicates whether a first check calculation for the masked electronic coin records was successful. The first check calculation checks in particular whether the command is amount-neutral, ie primarily that the sum of the monetary amounts involved is zero.
  • the "1" state means that a calculation was successful and the "0" state indicates that the calculation was unsuccessful and the state indicates that a calculation is not yet complete.
  • the first area proof of column 27a is always necessary for the coin record(s) to be considered valid.
  • a typical example of a necessary check is checking that the monetary amount is not negative (or that none of the monetary amounts is negative).
  • the second and third proof of area does not affect the validity of the coin data set and can be made up for pseudonymized masked coin data sets, for example in a later transaction of the pseudonym.
  • the area verification in column 27b is used to check whether the monetary amount of the masked coin data record (or each coin data record) is below a maximum amount. The maximum amount can be predetermined system-wide or for specific end device types.
  • a sum of monetary amounts that the subscriber unit TE (sent or received) in a certain period of time - such as 24 hours - is compared with a total limit value or, for example, a number of transactions per time unit for the subscriber unit TE is checked, such as maximum 5 per minute or 100 per day.
  • the limit values can be specified system-wide by the payment system BZ or can be defined for specific subscriber unit types (that is to say subscriber unit-specific). For example, a Type X coffee maker is designed to only dispense four portions of hot beverages per minute and accordingly only allows four coin transactions per minute.
  • Column 28 indicates whether a signature of the electronic coin dataset matches the signature in column 24, with status "1" meaning that a validity check revealed that the signature could be identified as that of the issuing authority and the state "0" indicates that a validity check revealed that the signature could not be identified as that of the publisher authority and the state indicates that a validity check has not yet been completed.
  • a change in the status of one of the markings requires the approval of the coin register 2 and/or the monitoring register 6 and must then be stored invariably in the data structure of FIG.
  • Processing is final in anonymous mode (or for an anonymous masked coin data set) if and only if the required markings 25 to 28 have been validated by the coin register 6, i.e. after the corresponding check from state "0" to state "1” or the status "1" was changed.
  • Processing in the pseudonymous mode (or for a pseudonymised masked coin data set) is completed when the checks for the markings 25 to 27a and 28 have been carried out by the monitoring register 6.
  • a data structure without final markings 29 is assumed and the validity of anonymous coin data sets is considered first.
  • the coin register 2 looks for the last change affecting the masked electronic coin record Z. It applies that the masked electronic coin data record Z is valid if the masked electronic coin data record Z is listed for its last processing in one of the successor columns 23a, 23b if and only if this last processing has the corresponding final marking 25 to 28. It also applies that the masked electronic coin data record Z is valid if the masked electronic coin data record Z is listed for its last processing in one of the predecessor columns 22a, 22b if and only if this last processing failed, i.e. at least one of the corresponding required states of markings 25 to 28 is set to "0".
  • the masked electronic coin record Z is not found in the coin register 2, it is invalid. It also applies that the anonymous masked electronic coin data record Z is not valid for all other cases. For example, if the last processing of the masked electronic coin data record Z is listed in one of the successor columns 23a, 23b, but this last processing never became final, or if the last processing of the masked electronic coin data record Z is in one of the predecessor columns 22a, 22b and this last processing is final.
  • the checks made by coin register 2 and/or monitor register 6 to determine if processing is final are represented by columns 25 through 28: The status in column 25 indicates whether the masked electronic coin record(s). are valid according to predecessor columns 22a, 22b.
  • the status in column 26 indicates whether the calculation of the masked electronic coin record according to equation (10) is correct.
  • the status in column 27a indicates whether the area verifications for the masked electronic coin records Z could be verified successfully.
  • the status in column 28 indicates whether the signature in column 24 of the masked electronic coin data set Z is a valid signature of the issuing authority 1.
  • the status "0" in a column 25 to 28 indicates that the check was unsuccessful.
  • the status "1" in a column 25 to 28 indicates that the check was successful.
  • the status in a column 25 to 28 indicates that no check has taken place.
  • the statuses can also have a different value, as long as it is possible to clearly distinguish between the success/failure of a test and whether a specific test was carried out.
  • One processing is, for example, “creating” an electronic coin data record Ci.
  • the creation in the direct transaction layer 3 by the issuer entity 1 involves choosing a monetary amount Ui and creating an obfuscation amount n, as already described with equation (1). As shown in FIG. 8, no entries/markings are required in columns 22a, 22b, 23b and 25 to 27 during the “generate” processing.
  • the masked electronic coin data set Zi is registered in the successor column 23a. This registration preferably takes place before the transmission 105 to a subscriber unit TE, in particular or already during generation by the issuing entity 1, with equation (3) having to be executed in both cases.
  • the masked electronic coin data record Zi is signed by the issuing authority 1 when it is created, this signature is entered in column 24 to ensure that the electronic coin data record Ci was actually created by an issuing authority 1, with other methods also being possible. If the signature of a received Zi matches the signature in column 24, the marking in column 28 is set (from "0" to "1"). The markings according to columns 25 to 27 do not require a status change and can be ignored. The proof of area is not required since the coin register 2 and/or the monitoring register 6 can be confident that the issuing authority 1 will not issue any negative monetary amounts. In an alternative embodiment, however, it can also be sent by the issuer instance 1 in the create command and can be checked by the coin register 2 and/or the monitoring register 6 .
  • deactivation ie the destruction of money
  • the deactivation has the effect that the masked electronic coin data record Zi becomes invalid after the issuer entity 1 has successfully executed the deactivation command. It is therefore no longer possible to process the (masked) electronic coin data record to be deactivated in the coin register 2 and/or in the monitoring register 6 .
  • the corresponding (non-masked) electronic coin records Ci should also be disabled in the direct transaction layer 3.
  • the masked electronic coin data record Zi is to be checked when deactivating whether the signature matches the signature according to column 24 in order to ensure that the electronic coin data record Ci was actually created by an issuing authority 1, although other means can be used for this check. If the signed Zi, which is also sent in the deactivation command, can be confirmed as signed by the issuer authority 1, the marker 28 is set (from "0" to "1"). The flags according to columns 26 to 27 do not require a status change and can be ignored. The markings according to columns 25 and 28 are set after a corresponding check.
  • a processing is, for example, the "split".
  • the division i.e. the division of an electronic coin data set Zi into a number n, for example 2, of electronic partial coin data sets Z j and Z k takes place first in the direct transaction layer 3, as is shown in Figures 9, 11 and 12, with the monetary amounts U j and the concealment amount h are generated.
  • V k and r k are given by equations (7) and (8).
  • the markings 24 to 27 are set in the coin register 2 and/or the monitoring register 6, the predecessor column 22a is written with the electronic coin data set Zi, successor column 23a is written with Z j and successor column 23b is written with Z k .
  • the status changes required according to columns 24 to 27 take place after the corresponding check by the coin register 2 and/or the monitoring register 6 and document the respective check result.
  • the flag according to column 28 is ignored in anonymous mode.
  • a first proof of area RI according to column 27a must be provided to show that no monetary amount is negative.
  • a second proof of area R2 in column 27b is not necessary, since the monetary partial amounts of the successor are always smaller than the initial monetary amount of the predecessor.
  • a summary area statement R3 in column 27c is also usually not required (no new monetary amounts).
  • Column 24 is used for entering a generated signature dividing the coin data record subscriber unit TE.
  • connection ie the combining of two electronic coin data sets Zi and Z j to form an electronic coin data set Z m , first takes place in the direct transaction layer 3, as is also shown in FIGS where the monetary amount u m and the concealment amount r m are calculated.
  • the markings 25 to 28 are set in the coin register 2 and/or the monitoring register 6, the predecessor column 22a is written with the electronic coin data record Zi, the predecessor column 22b is written with Z j and the successor column 23b is written with Z m .
  • the flags in columns 25 through 28 require status changes and coin register 2 and/or monitor register 6 performs the appropriate checks.
  • a first proof of area RI according to column 27a must be provided to show that no new money was generated.
  • a second proof of area R2 in column 27b makes sense since the new monetary amount of the successor could be greater than a maximum value.
  • a cumulative area statement R3 in column 27c is also generally useful since the terminal device could use newly received predecessors. The marking according to column 28 can be ignored.
  • Column 24 is used for entering a generated signature connecting the coin data record subscriber unit TE.
  • Switching is necessary when an electronic coin data set has been transferred to another subscriber unit TE and a renewed issue by the transmitting subscriber unit TE is to be ruled out.
  • switching over also called “switch”
  • the electronic coin data record C k received from the first subscriber unit TE1 is exchanged for a new electronic coin data record Ci with the same monetary amount.
  • the new electronic coin data record Ci is generated by the second subscriber unit TE2. This switching is necessary in order to invalidate (make invalid) the electronic coin data record C k received from the first subscriber unit TE2, thereby avoiding the same electronic coin data record C k being issued again.
  • the first subscriber unit TE1 Since the first subscriber unit TE1 is aware of the electronic coin data set C k , as long as the electronic coin data set C k is not switched, the first subscriber unit TE1 can forward this electronic coin data set C k to a third subscriber unit TE.
  • the switching is effected for example by adding a new fogging amount r to add fogging amount r k of the obtained electronic Münz Scheme C k, n is obtained whereby a fogging amount, known only to the second subscriber unit TE2. This can also be done in the coin register 2 or the monitoring register 6.
  • the modifications "split" and "connect" to an electronic coin data record can also be delegated from a subscriber unit TE1 to another subscriber unit TE, for example if a communication link to the coin register 2 and/or to the monitoring register 6 is not available.
  • FIG. 9 shows an exemplary embodiment of a payment system BZ according to the invention for the “split”, “connect” and “switch” actions of electronic coin data records C.
  • the first subscriber unit has received the TE1 Münz Scheme Ci and now wants a pay transaction do not perform k with the total monetary amount Ui, but only a partial amount V. To do this, the coin data set Ci is divided. To do this, the monetary amount is first divided:
  • Each of the received amounts U j , U k must be greater than 0 because negative monetary amounts are not permitted.
  • the monetary amount Ui is divided symmetrically into a number n of equal monetary partial amounts Uj.
  • V j / n (12a)
  • the number n is an integer greater than or equal to two.
  • the last partial amount of concealment h_ h is equal to the difference between the amount of concealment n and the sum of the remaining partial amounts of concealment:
  • h_i amounts to r, n -i be arbitrarily selected and the procedure of the equation (13a) is by means of appropriate calculation of the "last" h_ individual fogging amount satisfies h.
  • a signature is calculated in the respective subscriber unit TE.
  • n is the number of symmetrically divided coin part data sets.
  • the signature of the k-th partial coin data set k can be checked according to (13c) with the following verification key Sig:
  • Equation 13f The simplification based on Equation 13f makes it possible to completely dispense with zero-knowledge proofs, which means that the use of a symmetrical distribution saves an enormous amount of computing power and data volume.
  • a partial coin data set, here C k is then transmitted from the first subscriber unit TE1 to the second subscriber unit TE2.
  • a switching operation makes sense in order to exchange the electronic coin data record C k received from the first subscriber unit TE1 for a new electronic coin data record Ci with the same monetary amount.
  • the new electronic coin data record Ci is generated by the second subscriber unit TE2.
  • the monetary amount of the coin data record Ci is adopted and not changed, see equation (11).
  • the coin data set Ci to be switched is masked by the equation (3) to obtain the masked coin data set Z ⁇ .
  • FIG. 10 shows an embodiment of a payment system according to the invention for connecting (also called combining) electronic coin data records.
  • the two coin data sets Ci and are received in the second subscriber unit TE2.
  • a new coin data record Z m is now obtained by adding both the monetary amounts and the concealed amount of the two coin data records Ci and Ci.
  • the obtained coin data C m to be connected is masked and the masked coin data Z m is registered in the coin register 2 .
  • the signature of the second subscriber unit TE2 is entered, since this has received the coin data sets Ci and .
  • the highest of the two individual check values of the respective electronic partial coin data records Ci and Ci is determined. This highest check value is adopted as the check value Ci and the combined electronic coin record.
  • a new check value is determined from the sum of all check values of the electronic coin part data sets Ci and divided by the product of the number (here two) of the coin part data sets Ci and with a constant correction value.
  • the correction value is constant throughout the system.
  • the correction value is greater than or equal to 1.
  • the correction value is preferably dependent on a maximum deviation of the individual test values of the electronic coin part data sets Ci and/or on a maximum test value of one of the electronic coin part data sets Ci and .
  • the correction value is more preferably less than or equal to 2. This new check value is adopted as the check value of the combined electronic coin data set C m .
  • FIGS. 11 and 12 each show an exemplary embodiment of a method flowchart of a method 100.
  • FIGS. 11 and 12 are explained together below.
  • a coin data record is requested and provided by the issuer entity 1 to the first subscriber unit TE1 after the electronic coin data record has been created.
  • a signed masked electronic coin record is sent at step 103 to the coin register 2 and/or the monitoring register 6.
  • the received electronic coin data set Ci is masked according to equation (3) and signed in step 103p according to equation (3a).
  • step 104 the masked electronic coin data record Zi is registered in the coin register 2 or the monitoring register 6 .
  • the subscriber unit TE1 the received electronic Switch coin data set, then a signature Si would be entered in the coin register 2 or the monitoring register 6.
  • the coin data record Ci is transmitted in the direct transaction layer 3 to the second subscriber unit TE2.
  • a validity check is carried out with prior masking, in which case the coin register 2 and/or the monitoring register 6 confirms the validity of the coin data set Zi or Ci.
  • a received coin data set C k is then switched over (of course, the received coin data set Ci could also be switched over) to a new coin data set Ci, whereby the coin data set C k becomes invalid and double issuance is prevented.
  • the monetary amount v /, - of the transmitted coin data set C k is used as the "new" monetary amount.
  • the 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.
  • a signature S k is created by the first subscriber unit TE1 or the second subscriber unit TE2 and stored in the coin register 2 and/or the monitoring register 6 .
  • a signature Si could also be created and stored in the coin register 2 and/or monitoring register 6 if transmitting subscriber units TE were registered instead of receiving subscriber units TE.
  • step 108' the corresponding check is carried out in coin register 2 and/or monitoring register 6.
  • Z k is entered in column 22a according to the table in FIG Coin register 2 and/or the monitoring register 6 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 was made) 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, in which case the check according to equations (16) and (17) can be used. If it is good, the mark in column 25 is set to “1”, otherwise to “0”.
  • the second subscriber unit TE2 When checking the signature, it can be checked in pseudonymous mode 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. If the limit value is exceeded, the coin register 2 and/or the monitoring register 6 initially refuses to switch over the coin data set Ci and requests the second subscriber unit TE2 to deanonymize itself. Depending on the system, deanonymized switching may be permitted.
  • 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 u m is formed from the two monetary amounts and U k Ui.
  • the concealment amount r m is formed from the two concealment amounts r k and r i .
  • 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 monitoring register 6 and/or 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 .
  • step 109' the corresponding check is made in the coin register 2 and/or the monitoring register 6.
  • Z m is entered in the column 23b according to the table in FIG. 2, which is also equivalent to a paraphrase.
  • a check then takes place in the coin register 2 and/or the monitoring register 6 as to whether Z k and Zi are (still) valid, i.e. whether the last processing of Z k or Zi is entered in one of the columns 23a/b (as proof of this that Z k and Zi were not split further or deactivated or connected) and whether a check for the last processing failed.
  • the markings in columns 25, 26, 27 are initially set to "0".
  • 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. If the limit is exceeded, coin register 2 and/or monitoring register 6 refuses first connects the coin data set C m and requests the second subscriber unit TE2 to de-anonymize itself. A deanonymized connection may then be permitted.
  • a coin data set Ci is asymmetrically divided into two partial coin data sets C k and Q, whereby coin data set Ci is invalidated and the two asymmetrically divided partial coin data sets C k and are to be validated.
  • the monetary amount Ui is divided into different sized part monetary amounts U k and U j.
  • the concealment amount r is divided into the two concealment amounts rk and r.
  • the masked coin part data sets Z k and Z j are obtained using equation (3) and sent to the coin register 2 and/or the monitoring register 6 with further information, for example the area checks (zero-knowledge proofs), and the splitting is requested as processing .
  • a signature Si is created and sent to the coin register 2 and/or to the monitoring register 6 .
  • step 110' the corresponding check is carried out in the coin register 2 and/or the monitoring register 6.
  • Z j and Z k are entered in the columns 23a/b according to the table in FIG.
  • a check is then carried out in the monitoring register 6 and/or the coin register 2 to determine whether Zi is (still) valid, i.e. whether the last processing of Zi is entered in one of the columns 23a/b (as proof that Zi is not further divided or disabled or connected) and whether a check for the last processing failed.
  • the markings in columns 25, 26, 27 are initially set to "0".
  • a check is now made as to whether Z j and Z k are valid, in which case the check according to equations (16) and (17) can be used.
  • the marking in column 25 is set to "1".
  • 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. If the limit value is exceeded, the coin register 2 and/or the monitoring register 6 initially refuses to split up the coin data record Ci and requests the second subscriber unit TE2 to deanonymize itself. Deanonymized splitting may then be permitted.
  • FIG. 13 shows an exemplary embodiment of a first subscriber unit TE1 according to the invention.
  • the first subscriber unit TE1 can be a device M1 in which a security element SEI is incorporated.
  • the term device M1 is used below.
  • Electronic coin data records Ci can be stored in a data memory 10, 10' in the device M1.
  • the electronic coin data records Ci can be on the data memory 10 of the device M1 or can be available in an external data memory 10'.
  • the electronic coin data records Ci could be stored in an online memory, for example a data memory 10' of a provider for digital purses.
  • private data storage for example a network attached storage, NAS could also be used in a private network.
  • the electronic coin record Ci is presented as a hard copy.
  • the electronic coin data record can be represented by a QR code, an image of a QR code, or a file or a character string (ASCII).
  • the device Ml has at least one interface 12 available as a communication channel for issuing the coin data set Ci.
  • This interface 12 is, for example, an optical interface, for example for showing the coin data set Ci on a display unit (display), or a printer for printing out the electronic coin data set Ci as a paper printout.
  • This interface 12 can also be a digital communication interface, for example for near-field communication such as NFC, Bluetooth, or an Internet-enabled interface such as TCP, IP, UDP, HTTP or access to a chip card as a security element.
  • This interface 12 is a data interface, for example, so that the coin data record Ci is transmitted between devices via an application, for example an instant messenger service, or as a file or as a character string.
  • the interface 12 or another interface (not shown) of the device M1 is set up to interact with the coin register 4.
  • the device M1 is preferably online-capable.
  • the device Ml also have an interface for receiving electronic coin data sets.
  • This interface is set up to receive visually presented coin data sets, for example using a detection module such as a camera or scanner, or digitally presented coin data sets, received via NFC, Bluetooth, TCP, IP, UDP, HTTP or coin data sets presented using an application.
  • the device M1 also includes a computing unit 13 which can carry out the method described above for masking coin data sets and the processing of coin data sets.
  • the device Ml is online capable and can preferably recognize by means of a location detection module 15 when it is connected to a WLAN.
  • the location detection module 15 recognizes when the device Ml is in predefined GPS coordinates including a defined radius and performs the special functions according to the so-defined location zone through. This location zone can either be introduced manually into the device M1 or via other units/modules into the device M1.
  • the special functions that the device Ml performs when recognizing the location zone are, in particular, the transmission of electronic coin data sets from / to the external data memory 10 from / to a vault module 14 and, if necessary, the transmission of masked coin data sets Z to the coin register 4 and / or the monitoring register 6, for example as part of the above processing of a coin data record.
  • the device M1 is accordingly set up to carry out the method according to FIG.
  • the device Ml is set up to create and encrypt a transaction data record TDS.
  • the device M1 is set up to initiate communication with a transaction register.
  • the device M1 is set up to send the encrypted transaction data set TDS to the transaction register.
  • Device M1 is set up to link metadata (in plain text) to the transaction data record TDS.
  • the device M1 is set up to store the transaction data record TDS locally (temporarily).
  • all coin data records Ci are automatically linked to form a coin data record in device M1 upon receipt (see link processing or link step). That is, as soon as a new electronic coin data set is received, a connect or toggle command is sent to the coin register 4.
  • the device M1 can also prepare electronic coin data records in algorithmically defined denominations and store them in the data memory 10, 10', so that a payment process is also possible without a data connection to the coin register 4 and/or monitoring register 6.
  • a payment system is shown in FIG. 14 for better understanding.
  • the overall system according to the invention includes an issuing authority (central bank) la.
  • further issuer instances lb, lc can be provided which, for example, issue electronic coin data records in a different currency.
  • at least one payment system BZ is shown, in which at least one coin register 2, a monitoring register 6 and a transaction register 4 of the payment system BZ are provided in order to register the coin data sets Ci or Zi and to check and log the modifications to the coin data set Ci.
  • the publishing entity la can also be provided as part of the payment system BZ.
  • bank instance(s) can be arranged between the issuing instances la-c and the payment system BZ.
  • Registers 2, 4, 6 are housed together, for example, in one server entity and are logically separated from one another there. Alternatively, the registers 2, 4, 6 are also spatially/physically separated from one another.
  • the trade register 4 can also be arranged as a unit external to the payment system BZ.
  • a judicial/judicial authority 9 is shown, which requests a judicial request for decrypting encrypted transaction data records TDS from the payment system BZ (or directly from the transaction register) if fraud is suspected.
  • Remote instances 8a-c with corresponding subkeys are also shown to in the event of a request to make their partial keys available to the trade repository 4 in order to obtain a cryptographic key as a decryption key.
  • FIG. 14 provides a large number of participants, which are shown as terminal devices Mx (with respective SEx).
  • the terminals Ml to M6 can directly exchange coin data records Ci in the direct transaction layer 3.
  • terminal M5 transmits a coin record to terminal M4.
  • terminal M4 transmits the coin record to terminal M3.
  • the terminal M6 transmits a coin data set to the terminal Ml.
  • the test value pn of the coin data set to be sent or received and, if applicable, the counter value p is used in each transmitting terminal device Mx or each receiving terminal device Mx to check whether the coin data set is displayed in the payment system and/or whether the coin data set is displayed in the Publishing authority la is to be returned.
  • the payment system BZ uses the test value pn or a counter value p derived from the test value pn to check for each coin data set C whether the coin data set C is to be returned or not.
  • a test value is provided in each terminal Mx in order to monitor a number of transaction data sets TDS that have not yet been sent, despite the coin data sets being transmitted.
  • FIG. 15 shows a flowchart of a method with which, for example, compliance with a limit value for monetary amounts per unit of time is made possible.
  • the upper part of the figure shows the payment system BZ consisting of three terminals M1, M2, M3. Three data structures 910, 920, 930 of the respective registers 2, 4, 6 are shown in the lower part of the figure.
  • the valid masked coin data records Zi are stored in the data structure 910 of the coin register 2 .
  • the data structure 920 of the monitoring register 6 includes the assignment of pseudonymously transmitted, masked coin data sets to the pseudonym and can be viewed as the monitoring register 6 of coin data sets that are still to be checked pseudonymously. Based on the data in the data structure 920, the monitoring register 6 can decide whether an area verification is requested for a pseudonym.
  • Encrypted transaction data records TDS are stored in the data structure 930 of the transaction register.
  • the first terminal Ml split a coin 901.
  • the coin register 2 therefore knows that the coin Ci is a result of this split and stores the masked coin record Zi in the data structure 910.
  • the first terminal Ml could report the split to the monitoring register 6 anonymously or send pseudonymously. In the illustration, it is assumed that the terminals M1 and M3 send their masked coin data records to the monitoring register 6 anonymously.
  • the first terminal M1 sends the coin Ci directly to the second terminal M2 in a direct transmission step 902. Neither the coin register 2 nor the monitoring register 6 receive any information about this.
  • the first terminal Ml generates a transaction data record TDS902 regarding the transmission step 902, encrypts this transaction data record TDS902 and sends it to the transaction register 4.
  • the encrypted transaction data record TDS902 contains an identifier of the first terminal Ml, an identifier of the second terminal M2 and the monetary amount ui of the coin ci
  • the second terminal M2 converts the coin Ci into the coin C2 (switches over) 903.
  • the new masked coin data record Z2 is stored in the data structure 910 of the coin register 2 and the old masked coin data record Zi is deleted (or marked as invalid).
  • the second terminal M2 transmits its masked (or at least the illustrated) Münz Scheme pseudonym to the monitoring register 6.
  • the monitoring register 6 receives the monitoring register 6, the information that the second terminal M2 has received the coin C with the pseudonym P M 2 (and now coin C2 possesses) and stores the masked coin data set Z2 (and/or the masked coin data set Zi) for P M 2 in the data structure 920 of the monitoring register 6 accordingly the terminal M2.
  • the second terminal M2 sends the coin C2 in a further direct transmission step 905 to the third terminal M3. Neither the coin register 2 nor the monitoring register 6 receive any information about this.
  • the second terminal M2 generates a transaction data record TDS905 with regard to the transmission step 905, encrypts this transaction data record TDS905 and sends it to the transaction register 4.
  • the encrypted transaction data record TDS905 contains an identifier for the second terminal M2, an identifier for the third terminal M3 and the monetary amount 02 of the coin C2.
  • the third terminal M3 connects the received coin C2 to the connected coin C3 and sends this information to the coin register 2 with anonymous masked coin data sets.
  • the coin register 2 carries out all checking steps, i.e. in particular all area verifications for the masked coin data sets Z2 involved. .. and Z3 or a cumulative area proof for the third terminal M3. Only then does the coin register 2 delete the masked coin data record Z2 (and the other coin data records of the process) from the data structure 910 and save the new masked coin data record Z3 as a valid masked coin data record. 6.
  • the third terminal M3 in step 906 sends the coin C 3 directly to the second terminal M2. Neither the coin register 2 nor the monitoring register 6 receive any information about this.
  • the third terminal M3 generates a transaction data record TDS 906 with regard to the transmission step 906, encrypts this transaction data record TDS 906 and sends it to the transaction register 4.
  • the encrypted transaction data record TDS 906 contains an identifier for the third terminal M3, an identifier for the second terminal M2 and the monetary amount 0 3 of the coin C 3.
  • the second terminal M2 converts in a further step 903, the coin C 3 in the coin C4 to (switch), and sends a masked Münz Scheme Z4 together with his alias to the monitoring register 6.
  • the monitoring register 6 receives the information necessary tests throws . With the help of the data structure 920, the monitoring register 6 determines whether one or more checks are to be made up for the pseudonym of the terminal M2. If the criterion for a catch-up, such as time elapsed or number of transactions for a pseudonym, is not yet met, only notes the further masked coin data record Z4 for the pseudonym in the data structure 920 of the monitoring register 6.
  • the coin register 2 stores the masked coin data record Z4 in the data structure 910 and deletes the masked coin data set Z3 there. On the other hand, if a criterion for a catch-up test step is met, it first carries out the catch-up test step (or its equivalent).
  • the monitoring register 6 has the information that the second terminal device M2 had the coin C 2 (see step 3). Since the sum of the monetary amounts of C 2 and coin coin C4 might exceed its Münzschwellwert, calls the monitoring register 6 from the second terminal M2 a sum detection area (or a total area confirmation) on. The proof of the sum range shows that the sum of the monetary amounts of the coins C 2 and C 4 has not yet exceeded the—for example daily—limit of the transactions for the second terminal M2.
  • the monitoring register 6 can also monitor a limit for a time-independent number of transactions (area verification after 3/5/10/... transactions).
  • the monitoring register 6 can make up for a range check for the individual coin data sets that are linked in the data structure 920 of the monitoring register 6 with the pseudonym P M 2 (Is the monetary amount of each coin data set Z2 and Z4 less than X? ). If checks were successfully made up for, the corresponding data records in the data structure 920 of the monitoring register 6 can also be deleted.
  • the transaction register 4 has the transaction data records TDS 902 , TDS 905 and TDS 906 in encrypted form.
  • the transaction data records are decrypted and pseudonymised.
  • the identifiers of the terminals M1 to M3 are replaced by the pseudonyms P and the respective amount is converted into amount categories.
  • the pseudonymized unencrypted transaction data records are sent to the monitoring register 6. Since the sum of the monetary amounts of coin C2 and coin C4 could exceed a coin threshold value, the monitoring register 6 requests a sum range proof (or sum range confirmation) from the second terminal M2.
  • the amount categories in the pseudonymised transaction data records TDS* are meaningful in such a way that the monitoring register 6 can itself carry out the proof of the sum range using the pseudonymised transaction data records TDS *.
  • the monitoring register 6 can now also carry out a range check for the individual coin data sets using the pseudonymised transaction data sets TDS * .
  • FIG. 16 shows a further exemplary embodiment of a sequence in a payment system BZ with masked coin data records.
  • a first terminal M1 sends anonymous masked coin data records to the coin register 2 in steps 151.
  • a second terminal M2 sends pseudonymised masked coin data records to the monitoring register 6 in steps 161.
  • the coin register 2 responds to each of the anonymous transmission steps 151 of the first terminal Ml (in its anonymous mode) with a (recoverable) check for the masked coin data set or the first terminal Ml. Any additional tests that may be necessary are not shown in FIG.
  • the coin register 2 requests, for each masked coin record, a range verification that the monetary amount of the masked coin record from step 151 is below a maximum value (or equivalent range confirmation).
  • the coin register 2 requests proof (or confirmation) of the total area from the first terminal M1.
  • the first terminal M1 must create the (or the) requested evidence(s) in step 153 and send them in step 154 so that the (at least one) masked coin data record of step 151 in the coin register 2 is treated as valid.
  • the monitoring register 6 reacts to the first transmission steps 161 of the second terminal M2 (in its pseudonymous mode) by skipping a (repeatable) check for the masked coin data record or the second terminal M2.
  • the masked coin data set sent pseudonymously is registered as valid. Necessary checks, not shown here, are carried out, for example, which, however, do not require further communication with the second terminal M2.
  • the monitoring register 6 stores an association between the pseudonym and the pseudonymously transmitted masked coin data record(s). In the example shown, this reacts Monitoring register 6 analogous to a second (or further) transmission steps 161 of the second terminal M2. In doing so, it checks whether a catch-up criterion has been met for the pseudonym.
  • the monitoring register 6 establishes that a check should be carried out for the pseudonym. It sends a request 162 to the second terminal M2, for example to create area verifications for a number of coin data records or a total area verification.
  • the second terminal M2 creates a number of area verifications, a total area verification or a total area confirmation and sends this to the monitoring register 6 in step 164.
  • multiple coin data records of the second terminal M2 are selected and a sum is formed from their monetary amounts.
  • These coin data records relate either only to pseudonymised coin data records or to anonymous and pseudonymised coin data records (here, the masked coin data records that have already been sent are taken into account and the sum is formed from the monetary amounts of the corresponding unmasked coin data records).
  • the selection can be made on the basis of criteria that are either known due to the system or were transmitted from the monitoring register 6 in step 162 .
  • the criteria are, for example, a period of time, in particular a predefined period of time, in which a total of all monetary amounts should/may not exceed a certain range, for example a monetary amount x euros per time unit y.
  • the criterion can also be a list in the first terminal M1 or in the monitoring register 6.
  • step 164 the requested sum area confirmation (or the requested sum area proof) is transmitted from the second terminal M2 to the monitoring register 6 .
  • the area generally relates to a total of all transactions within a specific time unit that are received and/or sent by a terminal. A mechanism is therefore created with which it is determined how high the total of all monetary amounts that were sent or received by a terminal within a specific time unit is.

Abstract

Die Erfindung betrifft ein Verfahren in einer ersten Teilnehmereinheit, bevorzugt einem ersten Sicherheitselement, aufweisend einen elektronischen Münzdatensatz, der in einem Münzregister eines Bezahlsystems registriert ist, mit den Verfahrensschritten: Erzeugen eines Transaktionsdatensatzes bezüglich eines Übertragens des elektronischen Münzdatensatzes an eine zweite Teilnehmereinheit, bevorzugt ein zweites Sicherheitselement oder bezüglich einer am Münzregister zu registrierenden Modifikation des elektronischen Münzdatensatzes; Verschlüsseln des erzeugten Transaktionsdatensatzes mit einem kryptografischen Schlüssel, wobei der kryptografische Schlüssel aus zumindest zwei kryptografischen Teilschlüsseln, bevorzugt mindestens drei kryptografischen Teilschlüsseln, jeweils verschiedener entfernter Instanzen zusammengesetzt ist; und Initiieren einer Kommunikationsverbindung zu einem Transaktionsregister des Bezahlsystems, um den verschlüsselten Transaktionsdatensatz an das Transaktionsregister zu senden. Weiter betrifft die Erfindung eine Teilnehmereinheit, ein Verfahren in einem Transaktionsregister, ein Transaktionsregister und ein Bezahlsystem.

Description

VERFAHREN TEILNEHMEREINHEIT· TRANSAKTIONSREGISTER UND BEZAHLSYSTEM ZUM VERWALTEN VON TRANSAKTIONSDATENSÄTZEN
TECHNISCHES GEBIET DER ERFINDUNG
Die Erfindung betrifft ein Verfahren in einer ersten Teilnehmereinheit, ein Verfahren in einem Transaktionsregister, eine Teilnehmereinheit, ein Transaktionsregister und ein Bezahlsystem zum Verwalten von Transaktionsdatensätzen beim Übertragen von elektronischen Münzdatensätzen.
TECHNISCHER HINTERGRUND DER ERFINDUNG Schutz der Privatsphäre ist ein wichtiger Wert für die Gesellschaft, besonders wenn es um sehr sensible Daten wie Zahlungsinformationen. 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 Fall (2) versucht jemand einen Münzdatensatz auszugeben, obwohl er kein Guthaben (mehr) besitzt.
Um den Fall (1) zu verdeutlichen, ist in Fig. la und Fig. lb ein Bezahlsystemen dargestellt, bei dem es möglich ist, einen geldwerten Betrag in Form von elektronischen Münzdatensätzen C direkt zwischen Endgeräten M im Bezahlsystem auszutauschen. Bei einem direkten Übertragen zwischen den Endgeräten M wird keine zentrale Instanz des Bezahlsystems, beispielsweise ein Münzregister 2, benötigt. In Fig. la teilt ein Endgerät Ml einen Münzdatensatz Ca auf, um einen Münzteildatensatz Cb zu erhalten. Das Endgerät Ml gibt den Münzdatensatz Cb in unerlaubter Weise an Endgerät M2 und M3 gleichzeitig weiter.
Im Bezahlsystem der Fig. la teilt das Endgerät M2 den Münzdatensatz Cb weiter und erhält den Münzdatensatz C , der sodann direkt an das Endgerät M4 weitergegeben wird. Das Endgerät M4 gibt den Münzdatensatz Cc an das Endgerät M6 direkt weiter. Das Endgerät M6 gibt den Münzdatensatz Cc an das Endgerät M8 direkt weiter. Der arglose Teilnehmer mit Endgerät M3 gibt den Münzteildatensatz Cb direkt an das Endgerät M5 weiter. Das Endgerät M3 gibt den Münzdatensatz Cb an das Endgerät M5 direkt weiter. Das Endgerät M5 gibt den Münzdatensatz Cb an das Endgerät M7 direkt weiter. Somit wechseln beide Münzdatensätze Cb und Cc häufig den Besitzer, ohne dass ein Münzregister 2 des Bezahlsystems dies erfährt.
Wenn - wie in Fig. lb dargestellt - das Endgerät M7 den Münzdatensatz Cb in einem Münzregister 2 des Bezahlsystems auf sich registrieren lässt (= umschalten oder switch), wird der Münzdatensatz Cb ungültig (dargestellt durch das Durchstreichen des Münzdatensatzes) und ein Münzdatensatz Cd gültig. Wenn nun auch das Endgerät M8 den Münzdatensatz Cc als den Münzdatensatz Ce beim Münzregister 2 registrieren lassen möchte, stellt das Münzregister 2 fest, dass der Münzdatensatz Cb bereits ungültig ist. Der Angriff von Ml wird erst jetzt entdeckt. In der Folge akzeptiert das Münzregister 2 weder den Münzdatensatz Cc noch den Münzdatensatz Ce.
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.
Unter bestimmten Umständen kann es wünschenswert sein, die Privatsphäre nach einem ordnungsgemäßen Verfahren einzuschränken, beispielsweise wenn kriminelle Aktivitäten vermutet werden. Bislang schützt das Bezahlsystem die Privatsphäre der Teilnehmer.
Es ist daher die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zu schaffen, in denen eine Bezahltransaktion zwischen Teilnehmern eines Bezahlsystems sicher aber dennoch einfach ausgestaltet ist. Dabei soll insbesondere eine direkte und anonyme Bezahlung zwischen Teilnehmereinheiten, wie Geräten, Token, Smartphones, Sicherheitselementen aber auch Maschinen, Kassenterminals oder Automaten geschaffen werden. Mehrere Münzdatensätze sollen beim Teilnehmer (=Benutzer) beliebig miteinander kombiniert und/oder aufgeteilt werden können, um ein flexibles Austauschen (Übertragen) zu ermöglichen. Die ausgetauschten Münzdatensätze sollen vertraulich gegenüber anderen Systemteilnehmem sein, aber jedem Systemteilnehmer erlauben, grundlegende Prüfungen an dem 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 eine Münzdatensatz verfallen soll.
Insbesondere soll es auf behördliche Anfrage hin möglich sein, Transaktionen zu deanonymisieren, um beispielsweise eine Strafverfolgung zu ermöglichen.
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 insbesondere durch ein Verfahren in einer ersten Teilnehmereinheit, bevorzugt einem ersten Sicherheitselement, aufweisend einen elektronischen Münzdatensatz, der in einem Münzregister eines Bezahlsystems registriert ist, gelöst. Das Verfahren weist die folgenden Verfahrensschritte auf: Erzeugen eines Transaktionsdatensatzes bezüglich eines Übertragens des elektronischen Münzdatensatzes an eine zweite Teilnehmereinheit, bevorzugt ein zweites Sicherheitselement oder bezüglich einer am Münzregister zu registrierenden Modifikation des elektronischen Münzdatensatzes; Verschlüsseln des erzeugten Transaktionsdatensatzes mit einem kryptografi sehen Schlüssel, wobei der kryptografische Schlüssel aus zumindest zwei kryptografi sehen Teil schlüsseln, bevorzugt mindestens drei kryptografi sehen Teilschlüsseln, jeweils verschiedener entfernter Instanzen zusammengesetzt ist; und Initiieren eines Kommunikationsverbindungsaufbau zu einem Transaktionsregister, um den verschlüsselten Transaktionsdatensatz an das Transaktionsregister zu senden.
Unter bestimmten Umständen kann es wünschenswert sein, die Privatsphäre nach einem ordnungsgemäßen Verfahren einzuschränken, beispielsweise wenn kriminelle Aktivitäten vermutet werden. Durch das erfindungsgemäße Verfahren wird einem definierten (bestimmten) Personenkreis, insbesondere Vollzugsbehörden bei der Strafverfolgung, Zugang zu vertraulichen Informationen gewährt, um Verbrechen zu verhindern oder zu verfolgen. Um den Zugang zu erlangen, also um verschlüsselte Transaktionsdatensätze entschlüsseln zu können, sind mehrere (mindestens zwei) Teilschlüssel verschiedener entfernter Instanzen notwendig. Damit ist die Vertraulichkeit und auch die Datenintegrität des Bezahlsystems weiter gewahrt.
In der nachfolgenden Beschreibung wird der Kommunikationsvorgang mit Transaktionsdatensätzen (=Senden) begrifflich vom Kommunikationsvorgang mit Münzdatensätzen getrennt (Übertragen).
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. Dieser geldwerte Betrag kann bei dem Verfahren von einem ersten Endgerät zu einem anderen Endgerät wechseln. Als ein geldwerter Betrag 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, beispielsweise dem Transaktionsdatensatz, zum Datenaustausch oder Datentransfer, da beispielsweise eine klassische Datentransaktion auf Basis eines Frage-Antwort-Prinzips bzw. auf einer Interkommunikation zwischen den Datentransferpartnern, beispielsweise der Teilnehmereinheit und dem Transaktionsregister, stattfindet. Ein elektronischer Münzdatensatz ist dementgegen einmalig, eindeutig und steht im Kontext eines Sicherheitskonzepts, welches beispielsweise Maskierungen, Signaturen oder Verschlüsselungen umfassen kann. In einem elektronischen Münzdatensatz sind prinzipiell alle Daten enthalten, die für eine empfangende Instanz bezüglich Verifikation, Authentisierung und Weitergeben an andere Instanzen benötigt werden. Eine Interkommunikation zwischen den Endgeräten beim Austausch ist daher bei dieser Art Datensätze grundsätzlich nicht erforderlich.
Im Unterschied zum Kopieren von elektronischen Datensätzen, also der Vervielfältigung digitaler Daten, darf 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.
Um ein Übertragungsprotokoll 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 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.
Die Teilnehmereinheit kann beispielsweise ein mobiles Endgerät, wie z.B. ein Smartphone, ein Tablet-Computer, ein Computer, ein Server oder eine Maschine sein. Ein Übertragen des elektronischen Münzdatensatzes vom (ersten) Sicherheitselement einer ersten Teilnehmereinheit erfolgt beispielsweise zum (zweiten) Sicherheitselement einer anderen Teilnehmereinheit. Dabei kann eine Teilnehm ereinheit-zu-Teilnehmereinheit Üb ertragungs 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. Eine auf der Teilnehmereinheit betriebsbereit eingeberachte Applikation (installiert) kann die Übertragung des Münzdatensatzes durch Nutzung von Eingabe- und/oder Ausgabemittel der jeweiligen Teilnehmereinheit initiieren und steuern. Beispielsweise können Beträge von elektronischen Münzdatensätzen angezeigt werden und das Übertragungsverfahren überwacht werden.
Erfindungsgemäß ist vorgesehen, dass von der ersten Teilnehmereinheit, also der den (zumindest einen) Münzdatensatz sendenden Teilnehmereinheit, ein Transaktionsdatensatz erzeugt wird. Der Transaktionsdatensatz umfasst diejenigen Informationen, die benötigt werden, um die Übertragung des Münzdatensatzes zwischen zwei Teilnehmereinheiten des Bezahlsystems eindeutig in der Gesamtheit der Übertragungen (Bezahltranskationen) identifizieren zu können. Der Transaktionsdatensatz umfasst dabei insbesondere die an der Übertragung teilnehmenden Teilnehmereinheiten und eine Information bezüglich des zu übertragenden Münzdatensatzes. Mit einem (entschlüsselten) Transaktionsdatensatz kann das Übertragen des elektronischen Münzdatensatz eindeutig rekonstruiert werden. In einer bevorzugten Ausgestaltung weist der Transaktionsdatensatz zumindest eine Kennung oder Adresse der ersten Teilnehmereinheit (=Sender) auf, also ein Datum, mit dem dieses Sicherheitselement eindeutig im Bezahlsystem identifiziert werden kann. Zudem weist der Transaktionsdatensatz zumindest, eine Kennung oder Adresse einer zweiten Teilnehmereinheit, (=Empfänger) auf, also ein Datum, mit dem dieses Sicherheitselement eindeutig im Bezahlsystem identifiziert werden kann. Zudem weist der Transaktionsdatensatz einen geldwerten Betrag des elektronischen Münzdatensatzes auf.
In einer weiter bevorzugten Ausgestaltung weist der Transaktionsdatensatz eine Transaktionsnummer auf. Diese Transaktionsnummer ist beispielsweise eine vor dem Erzeugen- Schritt erzeugte Zufallszahl. Bevorzugt wird dazu ein Zufallszahlengenerator der Teilnehmereinheit oder des Sicherheitselements verwendet. Alternativ oder zusätzlich ist die Transaktionsnummer eine Identifizierungsnummer der Transaktion, die für die Übertragung von der ersten Teilnehmereinheit eindeutig und einmalig ist. Zusätzlich kann die Transaktionsnummer eine Identifizierung der Transaktion im Bezahlsystem sein.
In einer weiter bevorzugten Ausgestaltung weist der Transaktionsdatensatz weiter einen maskierten elektronischen Münzdatensatz korrespondierend zu dem zu übertragenden elektronischen Münzdatensatz, bevorzugt anstelle des geldwerten Betrags des elektronischen Münzdatensatzes oder anstelle des elektronischen Münzdatensatzes auf. Das Maskieren wird später erläutert. Das Nicht-Einbringen des elektronischen Münzdatensatzes ermöglicht die Einbehaltung zweier Systemvoraussetzungen, nämlich dass der elektronische Münzdatensatz nur einmal im System vorhanden ist und (und eben nicht in Kopie im Transaktionsdatensatz ist), und zweitens der Besitz des elektronischen Münzdatensatzes zur Zahlung berechtigt, also ein noch nicht verschlüsselter Transaktionsdatensatz (ggf. nach dem Übertragen an die zweite Teilnehmereinheit) oder ein entschlüsselter Transaktionsdatensatz potenziell für Bezahlvorgänge verwendbare Münzdatensätze enthalten würde und damit das Risiko an Betrug stiege.
In einer weiter bevorzugten Ausgestaltung weist der Transaktionsdatensatz einen Transaktionszeitpunkt auf. Dazu wird ein Zeitstempel generiert und dem Transaktionsdatensatz angefügt. Der Zeitstempel ist bevorzugt bezahlsystemweit eindeutig.
Der Transaktionsdatensatz kann weitere Daten enthalten, wie Transaktionsort (GPS), enthalten. Bevorzugt besteht er jedoch aus den genannten Daten.
In einer bevorzugten Ausgestaltung fügt die erste Teilnehmereinheit einen Transaktionszeitpunkt an den verschlüsselten Transaktionsdatensatz (im Klartext) an, beispielsweise als Metadatum. So kann dieser Transaktionszeitpunkt im Transaktionsregister als ein Eingangsparameter zur Berechnung eines Löschungszeitpunkts des verschlüsselten Transaktionsdatensatzes sein. So könnte, beispielsweise im Rahmen einer Vorratsdatenspeicherung, der verschlüsselte Transaktionsdatensatz automatischen nach Ablauf einer eingestellten Speicherzeit, beispielsweise X Monate oder Y Jahre, aus dem Transaktionsregister wieder gelöscht werden. Dies ist vorteilhaft für den Fall, dass der Transaktionsdatensatz zeitlich erst viel später nach der Übertragung des Münzdatensatzes an das Transaktionsregister gesendet wird, um die Speicherung nicht (ggf. in illegaler Weise) zu verlängern.
Als ein weiteres Metadatum könnte auch eine Kennung oder die Kennungen des Transaktionsdatensatzes in Klartext angefügt werden.
In einer weiter bevorzugten Ausgestaltung weist der Transaktionsdatensatz eine Empfangsbestätigung der zweiten Teilnehmereinheit auf. Die Empfangsbescheinigung dient als Nachweis bzw. Quittierung eines ordnungsgemäßen Empfangs des elektronischen Münzdatensatzes in der zweiten Teilnehmereinheit und der Besitz der Empfangsbestätigung in der ersten Teilnehmereinheit beweist eine ordnungsgemäße Übertragung des elektronischen Münzdatensatzes.
Dieser Transaktionsdatensatz widerspricht zunächst einmal dem Gebot der Anonymität für das Bezahlsystem. Aus diesem Grund wird der Transaktionsdatensatz in einem Folgeschritt verschlüsselt. Das Verschlüsseln des Transaktionsdatensatzes erfolgt bevorzugt unmittelbar nach dessen Erzeugung, mehr bevorzugt erfolgt das Erzeugen und das Verschlüsseln als eine atomare Operation. Das Verschlüsseln erfolgt mit einem kryptografi sehen Schlüssel. Damit ist der Transaktionsdatensatz für einen unbeteiligten Dritten nicht einsehbar und dessen Inhalt für diesen unbeteiligten Dritten verborgen. So ist sichergestellt, dass ein Angriff auf das Teilnehmeridentitätsmodul zum Ausspähen unverschlüsselter Transaktionsdaten erfolglos bleibt.
Dieser kryptografi sehe Schlüssel ist aus zumindest zwei Teilschlüsseln zusammengesetzt. Jeder Teilschlüssel stammt von einer (einzigen) entfernten Instanz. Die entfernten Instanzen sind voneinander unabhängig. Eine entfernte Instanz hat Kenntnis und Besitz von nur einem (eigenen) Teil Schlüssel. Eine entfernte Instanz hat insbesondere keine Kenntnis und ist nicht im Besitz eines Teilschlüssels einer anderen entfernten Instanz. Das Zusammensetzen des kryptografischen Schlüssels beinhaltet auch das Ableiten eines zum Verschlüsseln zu verwendenden öffentlichen Schlüsselteil einer PKI-Schlüsselinfrastruktur, der ggf. unter Verwendung eines zusammengesetzten privaten Schlüsselteils generiert wurde.
Mit entfernter Instanz ist hier gemeint, dass diese Instanz keine lokale Instanz einer Teilnehmereinheit ist. Die entfernte Instanz ist bevorzugt nicht das Münzregister des Bezahlsystems, nicht das Transaktionsregister des Bezahlsystems und nicht das Überwachungsregister des Bezahl Systems, sodass zur Wahrung der Anonymität und Neutralität im Bezahlsystem, eine Unabhängigkeit die Registerinstanzen des Bezahlsystems den verschlüsselten Transaktionsdatensatz nicht entschlüsseln können bzw. keinen Teilschlüssel zur Entschlüsselung beisteuern können.
Damit kann der Transaktionsdatensatz an einem vertrauenswürdigen Ort, dem Transaktionsregister, in verschlüsselter Form gespeichert werden. Als Ergebnis eines Gerichtsurteils kann dieser verschlüsselte Transaktionsdatensatz von autorisierten Parteien als den entfernten Instanzen entschlüsselt werden. Diese autorisierten Parteien könnten z.B. eine Strafverfolgungsbehörde, ein Notar, das Justizministerium, eine Zentralbank, eine Herausgeberinstanz des Bezahlverfahrens, eine Gerichtsinstanz oder andere sein.
In einer bevorzugten Ausgestaltung sind die kryptografischen Teilschlüssel jeweils von einer Vollzugsbehördeninstanz; einer Notarinstanz; einer Justizministeriuminstanz; einer zentrale Herausgeberinstanz des Bezahlsystems; oder einer Geschäftsbankinstanz des Bezahl Systems.
In einer bevorzugten Ausgestaltung ist der kryptografische Schlüssel zum Verschlüsseln des Transaktionsdatensatzes ein öffentlicher Schlüsselteil einer asymmetrischen
Schlüsselinfrastruktur (Public-Key-Infrastructure, kurz PKI), wobei der korrespondierende private Schlüsselteil zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes durch eine Additions-Operation oder eine bitweise XOR-Operation aus allen kryptografischen Teil schlüsseln der verschiedenen entfernten Instanzen zusammengesetzt ist.
In einer bevorzugten Ausgestaltung ist der kryptografische Schlüssel zum Verschlüsseln des Transaktionsdatensatzes ein öffentlicher Schlüsselteil einer asymmetrischen
Schlüsselinfrastruktur (PKI), wobei der korrespondierende private Schlüsselteil zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes aus einer vordefinierten Anzahl von kryptografischen Teilschlüsseln verschiedener entfernter Instanzen zusammengesetzt ist, wobei die vordefinierte Anzahl geringer ist als die Gesamtanzahl der verschiedenen - einen Teilschlüssel aufweisenden - entfernten Instanzen.
Alle entfernten Instanzen besitzen nur jeweils einen Teilschlüssel des Entschlüsselungsschlüssel, d.h. alle entfernten Instanzen beziehungsweise eine Untermenge der entfernten Instanzen sind stets erforderlich, um gemeinsam den verschlüsselten Transaktionsdatensatz zu entschlüsseln. Dies verbessert Sicherheit vor Missbrauch, da mehre Instanzen für die Durchführung eines Datenzugriffs benötigt werden, was in einem Angriffsszenario einen bedeutenden Mehraufwand darstellt.
Die Teilschlüssel werden zu einem gemeinsamen (privaten) Entschlüsselungsschlüssel kombiniert. Dieses Kombinieren erfolgt beispielsweise in dem Transaktionsregister. Alternativ erfolgt das Kombinieren in der ersten Teilnehmereinheit. Dieses Kombinieren erfolgt beispielsweise durch Addition oder durch bitweise XOR-Verknüpfung, die keine entfernte Instanz in bloßer Kenntnis der/des Teilschlüssels für sich allein erhalten kann. Dieser gemeinsame (private) Entschlüsselungsschlüssel wird dann zur Entschlüsselung des verschlüsselten Transaktionsdatensatzes verwendet.
Der entsprechende öffentliche Schlüsselteil dieses gemeinsamen privaten Entschlüsselungsschlüssels wird in der ersten Teilnehmereinheit zum Verschlüsseln des erzeugten Transaktionsdatensatzes verwendet. Dieser öffentliche Schlüsselteil kann von dem Transaktionsregister an die Teilnehmereinheit versendet und dort empfangen werden. Bevorzugt ist der öffentliche Schlüssel jedoch in der Teilnehmereinheit gespeichert, insbesondere vorab gespeichert, weiter vorzugsweise änderungsgeschützt gespeichert.
In einer alternativen Ausgestaltung ist der kryptografische Schlüssel zum Verschlüsseln ein symmetrischer Schlüssel, wobei der korrespondierende private Schlüsselteil zum Entschlüsseln des Transaktionsdatensatzes durch eine Additions-Operation oder eine bitweise XOR-Operation aus zumindest zwei kryptografi sehen Teilschlüsseln zusammengesetzt ist.
Dieses Schlüssel-Konzept garantiert, dass keine entfernte Instanz alle anderen umgehen könnte, um Daten allein zu entschlüsseln. In einer Ausgestaltung wird eine Schwellenwert-Kryptographie angewendet, um es zu ermöglichen, dass nicht zwingend alle entfernten Instanzen ihren Teilschlüssel beisteuern müssen, sondern dass eine Untermenge der Instanzen ausreicht, um den Entschlüsselungsschlüssel zusammenzusetzen. Dabei gilt, dass zumindest die Anzahl der Untermenge ihren jeweiligen Teilschlüssel beisteuern muss. Ist die Untermenge kleiner als eine vordefinierte Mindestanzahl an entfernten Instanzen, so ist eine Entschlüsselung nicht möglich.
In einer weniger bevorzugten alternativen Ausgestaltung verfügen alle entfernten Instanzen (alle autorisierten Parteien) über einen vollständigen Satz von Entschlüsselungsteil schlüsseln zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes. Jede entfernte Instanz besitzt dann ein Sicherheitselement, beispielsweise eine Smartcard, ein TSM, eine eUICC, in dessen Datenspeicher alle Teilschlüssel abgespeichert sind. Jede dieser entfernten Instanzen ist sodann technisch in der Lage, den verschlüsselten Transaktionsdatensatz allein zu entschlüsseln, beispielsweise sobald ein Zugriff darauf von einer vertrauenswürdigen Stelle, beispielsweise einer Gerichtsbehörde nach ergangenem Beschluss, authentisiert wurde. Dieser Zugriff wird nur dann von der vertrauenswürdigen Stelle (dem Transaktionsregister) gewährt, wenn diese Behörde(n) ein rechtsverbindliches Dokument vorlegen kann, das eine diesbezügliche Gerichtsentscheidung abbildet. Diese Ausgestaltung hat den Vorteil, dass in dringenden Fällen eine Analyse ggf. relevanter Transaktionsdatensätze mit weniger beteiligten entfernten Instanzen schneller durchgeführt werden könnte. In einer alternativen Ausgestaltung generieren alle entfernten Instanzen ein eigenes PKI- Schlüsselpaar bestehend aus einem privaten Schlüsselteil und einem öffentlichen Schlüsselteil. Die öffentlichen Schlüsselteile der jeweiligen Schlüsselpaare werden bereitgestellt und/oder von der ersten Teilnehmereinheit empfangen. Die erste Teilnehmereinheit verschlüsselt den erzeugten Transaktionsdatensatz mit einem ersten öffentlichen Schlüsselteil einer ersten entfernten Instanz, um einen ersten unvoll ständig-verschlüsselten Transaktionsdatensatz zu erhalten. Dieser erste verschlüsselte Transaktionsdatensatz wird von der ersten Teilnehmereinheit mit einem öffentlichen Schlüsselteil einer zweiten entfernten Instanz verschlüsselt, um einen zweiten verschlüsselten Transaktionsdatensatz zu erhalten. Bevorzugt wird dieser zweite verschlüsselte Transaktionsdatensatz von der ersten Teilnehmereinheit mit einem öffentlichen Schlüsselteil einer dritten entfernten Instanz verschlüsselt, um einen dritten verschlüsselten Transaktionsdatensatz zu erhalten. Die Anzahl und/oder die Reihenfolge der Anwendung der öffentlichen Schlüsselteile der jeweiligen entfernten Instanz ist beispielsweise bezahlsystemweit festgeschrieben, um ein späteres Entschlüsseln im Transaktionsregister mit den entsprechenden privaten Schlüsselteilen der entfernten Instanzen zu vereinfachen. Alternativ wird zumindest die Reihenfolge, in einer Ausgestaltung auch die Anzahl, der Anwendung der öffentlichen Schlüssel der jeweiligen Instanz variiert und das Entschlüsseln im Transaktionsregister über „Trial & Error“, also einer heuristischen Methode bei der solange eine Entschlüsselungsreihenfolge und Schlüsselauswahl gesucht/probiert wird, bis die gewünschte Entschlüsselung erfolgt, um das Verfahren besser abzusichem.
Die hier beschriebenen Verschlüsselungs-Verfahren sind transparent, um eine Benutzerakzeptanz zu gewährleisten.
Im Folgeschritt des Verfahrens wird eine Kommunikationsverbindung zu einem Transaktionsregister des Bezahlsystems initiiert, um den verschlüsselten Transaktionsdatensatz an das Transaktionsregister zu senden. Damit wird der Versuch unternommen, den Transaktionsdatensatz an das Transaktionsregister zu senden. Dabei kann eine übliches Kommunikationsprotokoll, wie TCP/IP oder eine Mobilfunkkommunikation, verwendet werden. Im Fall eines Sicherheitselements wird beispielsweise ein proaktives Kommando an die Teilnehmereinheit gesendet.
Das Initiieren stellt einen Versuch eines Verbindungsaufbaus bzw. ein Einleiten eines Verbindungsaufbaus dar, dessen Abbruch auch Szenario des erfindungsgemäßen Verfahrens ist. Das Initiieren kann auch beinhalten, dass die Teilnehmereinheit im Wissen, dass keine Verbindung mit dem Transaktionsregister möglich ist, beispielsweise beim Erkennen eines Offline-Status der ersten Teilnehmereinheit, wie „kein Empfang“ oder „Flugmodus“ oder „kein Guthaben“, keinen Verbindungsaufbauversuch vornimmt. Sodann wird das Wissen über die unmögliche Verbindung zum Transaktionsregister, beispielsweise durch vorhergehendes Abfragen oder Prüfen bestehender Kommunikationsmöglichkeiten dem Initiieren gleichgesetzt.
Das Initiieren beinhaltet auch das Auslesen eines Speichereinhalts eines ersten
Sicherheitselements durch die erste Teilnehmereinheit und das Senden des ausgelesenen Inhalts durch die erste Teilnehmereinheit.
Das Initiieren beinhaltet auch das Auslesen eines Speichereinhalts eines ersten
Sicherheitselements durch das Transaktionsregister und Empfangen des ausgelesenen Inhalts im T ransaktionsregi ster.
Das Transaktionsregister des Bezahlsystems dient der Archivierung des verschlüsselten Transaktionsdatensatzes. Dieser verschlüsselte Transaktionsdatensatz kann dort insbesondere nach behördlicher Anfrage mittels zusammengesetzten (kombinierten) Teilschlüsseln der entfernten Instanzen entschlüsselt werden und in der Folge von der anfragenden Instanz (Gerichtsbehörde, etc.) eingesehen werden. Eine Einsicht zu Kontroll-Überprüfzwecken in jedes Übertragen eines elektronischen Münzdatensatzes im Bezahlsystem und/oder jede zu registrierende Modifikation oder jede registrierte Modifikation eines elektronischen Münzdatensatzes im Bezahlsystem ist somit ermöglicht, aber nur unter sehr strengen Auflagen technisch umsetzbar.
Die behördliche Anfrage, beispielsweise ein Gerichtsbeschluss, enthält eine Teilnehm ereinheiten- Kennung und fragt alle Transaktionen dieser Kennung innerhalb eines bestimmten Zeitraums oder zu einem bestimmten Zeitpunkt ab. Die Metadaten des Transaktionsdatensatzes vereinfachen dann die Beantwortung dieser Anfrage beim Transaktionsregister.
Das Transaktionsregister kann beispielsweise eine nicht-öffentliche Datenbank des Bezahlsystems sein. In dieser Datenbank werden die verschlüsselten Transaktionsdatensätze - für eine mögliche spätere Überprüfung - abgelegt. Das Transaktionsregister ist beispielsweise als eine zentral geführte Datenbank in Form eines Datenspeichers oder Dienste-Server des Bezahlsystems ausgebildet.
In einer bevorzugten Ausgestaltung ist das erste Sicherheitselement betriebsbereit in der ersten Teilnehmereinheit eingebracht. Damit ist sichergestellt, dass die Transaktionsdatensätze ohne Manipulationen erzeugt und verschlüsselt und ggf. auch gesendet werden. In einer Ausgestaltung wird der Transaktionsdatensatz im Sicherheitselement erstellt und dann durch die Teilnehmereinheit verschlüsselt. 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 oder ein eingebettetes Sicherheitsmodul, eUICC, 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.
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 - weiterverwenden, insbesondere wenn das Bezahlsystem voraussetzt, dass elektronische Münzdatensätze von Sicherheitselementen per se als gültig anzusehen sind.
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.
Das erste Sicherheitselemente könnte zudem elektronische Münzdatensätze auch von weniger vertrauenswürdigen Einheiten, wie Teilnehmereinheiten, also Endgerät oder Maschine, erhalten haben, beispielsweise über eine Import/Export Funktion 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.
Eine Ü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 Intemet-Datenverbindung zu einem externen Datenspeicher, beispielsweise einem Online-Speicher, beinhalten.
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 (Bezahl Vorgang) 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 ist eine Datenbank, in der maskierte elektronische Münzdatensätze mit entsprechender Verarbeitung des maskierten elektronischen Münzdatensatzes registriert sind. Das Maskieren wird später erläutert werden. In einer bevorzugten Ausgestaltung lässt sich daraus ein Gültigkeitsstatus des (maskierten) elektronischen Münzdatensatzes ableiten. Bevorzugt wird die Gültigkeit der (maskierten) elektronischen Münzdatensätze in dem und durch das Münzregister vermerkt. Modifikationen, wie Umschalten, Aufteilen oder Kombinieren, zu den einzelnen elektronischen Münzdatensätzen werden im Münzregister registriert. Bevorzugt verursachen angefragte bzw. durchgeführte bzw. durchzuführende Modifikationen ebenfalls das oben beschriebene Erzeugen eines Transaktionsdatensatzes, der in verschlüsselter Form im Transaktionsregister abgelegt wird. Auf diese Weise dient das Transaktionsregister auch zur Archivierung von Modifikationen eines Münzdatensatzes. Diese zu den Informationen des Münzregisters oder des Überwachungsregisters möglicherweise redundanten Informationen im Bezahlsystem erhöhen die Stabilität und die Sicherheit des Bezahlsystems.
Die Registrierung der Verarbeitung bzw. der Verarb ei tungs schritte für eine jeweilige Modifikation kann in einer Ausgestaltung des Bezahlsystems auch das Registrieren von Prüfergebnissen und Zwischenprüfergebnissen betreffend die Gültigkeit eines elektronischen Münzdatensatzes betreffen, insbesondere das Bestimmen von Prüfwerten und Zählerwerten entsprechender 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.
In einer bevorzugten Ausgestaltung des Bezahlsystems erfolgt das Registrieren von Prüfergebnissen und Zwischenprüfergebnissen betreffend eine jeweilige Modifikation oder einen Übertragungsvorgang zwischen Teilnehmereinheiten bzw. deren Sicherheitselementen und betreffend die Gültigkeit (insbesondere für ein Anzeigen) eines elektronischen Münzdatensatzes, insbesondere das Bestimmen von Prüfwerten und Zählerwerten entsprechender elektronischer Münzdatensätze nicht im Münzregister des Bezahlsystems, sondern in einem Überwachungsregister des Bezahl Systems.
In einer bevorzugten Ausgestaltung des Bezahlsystems ist das Überwachungsregister eingerichtet zum Speichern von anonymisierten und/oder pseudonymisierten Transaktionsdatensätzen, um eine Überwachung der Transaktionen im laufenden Betrieb des Bezahlsystems zu ermöglichen. Das Überwachungsregister ist eine von dem Münzregister getrennte Instanz des gleichen Bezahlsystems. Durch die Aufteilung von Münzregister und Überwachungsregister innerhalb eines Bezahlsystems kann das Münzregister weniger komplex ausgebildet sein und eine einfache Prüfung der Gültigkeit abbilden während im Überwachungsregister die Korrektheit von Übertragungsvorgängen, eine ggf. geforderte Deanonymisierung einer Teilnehmereinheit und/oder die Prüfung von Zählwerten bzw. Prüfwerten elektronischer Münzdatensätze erfolgt. Zudem enthält das Münzregister durch die Aufteilung (weniger bzw.) keine vertraulichen oder sicherheitskritischen Daten. Eine Kommunikation - insbesondere von Teilnehmereinheiten - mit dem Münzregister kann dadurch ohne (oder nur mit schwacher - Gruppenschlüssel/shared keys/...) Authentisierung erfolgen.
Sowohl das Münzregister als auch das Überwachungsregister können beispielsweise dezentrale öffentliche Datenbanken 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 das Überwachungsregister als ein Dienste- Server des Bezahlsystems ausgebildet. In einer bevorzugten Ausgestaltung sendet die erste Teilnehmereinheit den verschlüsselten Transaktionsdatensatz an das Transaktionsregister. In diesem Fall konnte nach dem Initiieren eine Kommunikation zwischen Teilnehmereinheit und Transaktionsregister erfolgreich aufgebaut und der verschlüsselte Transaktionsdatensatz erfolgreich versendet werden. In der Folge kann die erste Teilnehmereinheit lokal den Transaktionsdatensatz löschen, um Speicherplatz einzusparen.
In einer bevorzugten Ausgestaltung wird der verschlüsselte Transaktionsdatensatz kryptografisch transportgesichert an das Transaktionsregister gesendet. Dabei wird beispielsweise eine gegenseitige Authentifizierung zwischen Teilnehmereinheit und Transaktionsregister angewendet. Ein Schlüsselaustausch wird dabei entweder als Sitzungsschlüssel vorab ausgehandelt oder vorab ausgegeben. Diese zusätzliche Transportsicherung verhindert, dass ein Angreifer erfährt, dass nun ein Transaktionsdatensatz übertragen wird. Dies erhöht die Sicherheit beim Übertragen der Transaktionsdatensätze.
In einer bevorzugten Ausgestaltung wird der verschlüsselte Transaktionsdatensatz in der ersten Teilnehmereinheit gespeichert, wenn der Kommunikationsverbindungsaufbau (nach dem Initiieren) zum Transaktionsregister oder das Versenden des verschlüsselten Transaktionsdatensatzes fehlschlägt. Die Speicherung kann eine Zwischenspeicherung sein, solange der verschlüsselte Transaktionsdatensatz noch nicht erfolgreich an das Transaktionsregister gesendet wurde. Der gespeicherte verschlüsselte Transaktionsdatensatz dient so für eine notwendige Wiederholung (RETRY) des Sendens bei Verbindungsfehlem oder Authentisierungsproblemen und muss dann nicht neu erstellt und verschlüsselt werden.
In einer bevorzugten Ausgestaltung wird der verschlüsselte Transaktionsdatensatz vom ersten Sicherheitselement an das Transaktionsregister versendet, sobald der Kommunikationsverbindungsaufbau mit dem Transaktionsregister erfolgreich ist. Ein erfolgreicher Verbindungsaufbau bedeutet beispielsweise, dass eine Kommunikation von Daten über einen hergestellten Kommunikationskanal ermöglicht wird, also der Kommunikationskanal zwischen dem Transaktionsregister und der Teilnehmereinheit aufgebaut wurde. Damit wird das Transaktionsregister auf einem aktuellen Stand hinsichtlich erfolgter/geplanter Übertragung gehalten und kürzlich erfolgte Transaktionen werden prompt im Transaktionsregister archiviert. Das Versenden wird darüber hinaus priorisiert für den Fall, dass zum Zeitpunkt der Übertragung des Münzdatensatzes keine Verbindung zum Transaktionsregister verfügbar war und die Teilnehmereinheit bzw. dessen Sicherheitselement wird angehalten, bei (erkannter) verfügbarer Kommunikationsverbindung den verschlüsselten Transaktionsdatensatz prompt an das Transaktionsregister zu versenden. In einer bevorzugten Ausgestaltung wird der elektronische Münzdatensatz von der ersten Teilnehmereinheit an die zweite Teilnehmereinheit übertragen. Das Übertragen erfolgt beispielsweise unmittelbar vor dem Erzeugen-Schritt, sodass der Transaktionsdatensatz einen zu übertragenden Münzdatensatz betrifft. Das Übertragen erfolgt beispielsweise unmittelbar nach dem Erzeugen- Schritt aber vor dem Verschlüsseln-Schritt, sodass das Übertragen ein Teil der oben beschriebenen atomaren Operation sein könnte und nur die gesamte Kette von Erzeugen- Übertragen-Verschlüsseln ausgeführt werden kann. Damit werden Differenzen zwischen erzeugtem Transaktionsdatensatz und tatsächlich übertragenem Münzdatensatz vermieden. Das Übertragen erfolgt beispielsweise unmittelbar nach dem Verschlüsseln-Schritt und vor dem Initiieren-Schritt, sodass der Transaktionsdatensatz einen zu übertragenden Münzdatensatz betrifft. Das Übertragen erfolgt beispielsweise unmittelbar nach dem Initiieren-Schritt, sodass der Transaktionsdatensatz einen bereits übertragenen Münzdatensatz betrifft
Zum Übertragen des elektronischen Münzdatensatzes zur zweiten Teilnehmereinheit ist nicht zwingend eine Netzwerk-Datenverbindung zu übrigen Instanzen des Bezahlsystems vorhanden. Um ein Übertragungsprotokoll sicher auszugestalten, werden die elektronischen Münzdatensätze beispielsweise durch Sicherheitselemente innerhalb jeweiliger Teilnehmereinheiten verwaltet und auch durch diese übertragen. In einer (Offline)- Übertragungsumgebung ist es wichtig, dass Übertragungsfehler oder Übertragungskonflikte ohne dazwischengeschaltete zentrale Instanzen eines Bezahlsystems, beispielsweise dem Münzregister oder dem Überwachungsregister, gelöst werden können. Ein Übertragungsprotokoll kann durch Prüfen des Vorhandenseins einer Empfangsnachricht und Verwendung von Sicherheitselementen sicherstellen, dass ein Übertragungsprozess (Bezahlvorgang), obwohl er asynchron ausgeführt wird, vertrauenswürdig ist. Ein zweistufiges Übertragen (Senden, dann Löschung) ist bevorzugt zu gewährleisten, so dass geldwerte Beträge nicht vernichtet werden noch, dass sie im aktiven Zustand dupliziert werden.
In einer bevorzugten Ausgestaltung wird der erzeugte Transaktionsdatensatz in der ersten Teilnehmereinheit, bevorzugt nicht-flüchtig, gespeichert. Die Speicherung kann eine Zwischenspeicherung sein, solange der elektronische Münzdatensatz noch nicht erfolgreich an die zweite Teilnehmereinheit übertragen wurde. Die Speicherung erfolgt dabei lokal. Der Transaktionsdatensatz kann im Falle einer fehlerhaften Übertragung herangezogen werden, um den Übertragungsvorgang zwischen den Teilnehmereinheiten zu wiederholen. Dabei muss am Münzdatensatz oder dem Transaktionsdatensatz selbst keine Veränderung vorgenommen werden. Der gespeicherte Transaktionsdatensatz dient so für eine notwendige Wiederholung (RETRY) der Übertragung bei Verbindungsfehlern oder Authentisierungsproblemen bei der Übertragung.
Zusätzlich oder alternativ dient der gespeicherte Transaktionsdatensatz zur Rückabwicklung (ROLLBACK) bei fehlgeschlagener Übertragung des Münzdatensatzes. Damit stellt das Verfahren sowohl ein Abwicklungsverfahren als auch ein Wiederholungsverfahren bereit, um im Übertragungsfehlerfall, bei dem das Übertragen des Münzdatensatzes nicht zu Ende geführt wurde, die Transkation rückabwickeln zu können oder wiederholen zu können.
Damit wird die Übertragung im Wiederholungsfall ganz abgeschlossen oder komplett ungeschehen gemacht.
In einer bevorzugten Ausgestaltung wird in einem Übertragungsfehlerfall anhand des gespeicherten Transaktionsdatensatzes der elektronische Münzdatensatz erneut gesendet. Dabei wird angenommen, dass die Übertragung des elektronischen Münzdatensatzes fehlgeschlagen ist, der Übertragungsvorgang dennoch abzuschließen ist. Das Übertragen des elektronischen Münzdatensatzes wird prompt wiederholt. Der erneut zu versendende elektronische Münzdatensatz entspricht dem elektronischen Münzdatensatz, bei dessen Übertragung ein Übertragungsfehlerfall eintrat. Am Münzdatensatz sind also für das erneute Versenden keine Veränderungen erforderlich. In einer Ausgestaltung wird zu Protokollzwecken ein weiterer Transaktionsdatensatz generiert
Ein Übertragungsfehlerfall wird beispielsweise angenommen, wenn eine Empfangsbestätigung nicht innerhalb einer vordefinierten Zeitdauer im ersten Sicherheitselement empfangen wurde. Dazu wird beispielsweise ein Timer gestartet, bevorzugt wird der Timer während des Senden- Schritts des elektronischen Münzdatensatzes gestartet.
Der Übertragungsfehlerfall kann alternativ oder zusätzlich durch eine Fehlermeldung des ersten oder des zweiten Sicherheitselements angezeigt werden. Damit wird der Fehlerfall explizit angezeigt.
Der Übertragungsfehlerfall kann auch durch eine erkannte Verbindungsstörung (Connectivity failure) angenommen werden. Damit wird der Fehlerfall implizit angezeigt.
Der Übertragungsfehlerfall kann auch aufgrund von misslungener Authentifizierung (authenti cation failure) eintreten.
Der Übertragungsfehlerfall kann auch durch das Abschalten eines Endgeräts (device shutdown), in dem eines der Sicherheitselement betriebsbereit eingebracht ist, oder durch Überschreiten der Übertragungsreichweite (exceeded distance) aufgrund einer Bewegung eines Teilnehmers eintreten.
Der Übertragungsfehlerfall kann auch durch einen internen Fehler (internal error) im ersten oder zweiten Sicherheitselement, in einer Applikation des Endgeräts, oder im jeweiligen Endgerät eintreten, beispielsweise durch einen Speicherungsfehler oder fehlendem Speicherplatz. In einer bevorzugten Ausgestaltung fragt das erste Sicherheitselement in vordefinierten periodischen Zeitabständen das zweite Sicherheitselement ab und fordert eine Empfangsbestätigung aktiv an, alternativ auch, wenn ein Zeitwert eines Timers überschritten ist.
In einer bevorzugten Ausgestaltung wird nach dem Üb ertragen- Schritt ein erfolgreiches Übertragen in der ersten Teilnehmereinheit angezeigt. Dabei kann eine Benutzeranzeige aktualisiert werden oder der geldwerte Betrag aus einer Liste verfügbarer geldwerter Beträge gelöscht werden. Einem Teilnehmer (Benutzer) am Bezahlsystem wird durch dieses Anzeigen visualisiert, dass der Übertragungsvorgang erfolgreich war. Zudem oder alternativ wird ein verfügbarer geldwerter Betrag aktualisiert, insbesondere entsprechend des übertragenen geldwerten Betrags reduziert.
In einer bevorzugten Ausgestaltung wird im Anzeigen- Schritt der elektronische Münzdatensatz als Eingangsparameter einer Applikation der ersten Teilnehmereinheit ausgewertet. Die Transaktionsdaten dieses elektronischen Münzdatensatzes steuern damit aktiv den Übertragungsvorgang ungeachtet einer Applikation, die in der ersten Teilnehmereinheit ausführbar eingebracht ist. Änderungen am elektronischen Münzdatensatz werden für einen Benutzer durch die Applikation auf der ersten Teilnehmereinheit visualisiert, der Benutzer erhält demnach prompte Rückmeldung über die Gültigkeit/den Status des zu übertragenden/übertragenen elektronischen Münzdatensatzes.
In einer bevorzugten Ausgestaltung wird der Üb ertragen- Schritt erst ausgeführt, wenn ein Prüfen- Schritt ergibt, dass ein Prüfwert für eine Anzahl von Übertragungen an die zweite Teilnehmereinheit oder an eine oder mehrere weitere Teilnehmereinheiten bei fehlgeschlagenem Kommunikationsverbindungsaufbau zum Transaktionsregister oder fehlgeschlagenem Versenden des verschlüsselten Transaktionsdatensatz an das Transaktionsregister unterhalb oder gleich einem vordefinierten Schwellwert ist. Damit wird die Anzahl von Übertragungen von Münzdatensätze von der ersten Teilnehmereinheit auf einen Maximalwert begrenzt, wenn in der Zwischenzeit kein Senden der jeweiligen Transaktionsdatensätze an das Transaktionsregister erfolgt ist bzw. erfolgen konnte. Damit wird die erste Teilnehmereinheit gezwungen, stets zu prüfen, ob ein Schwellwert, beispielsweise 100, mehr bevorzugt 50, mehr bevorzugt 10 Übertragungen, idealerweise 5 Übertragungen, erreicht ist.
In einer bevorzugten Ausgestaltung muss bei Überschreiten eines vordefinierten Schwellwerts eines Prüfwerts für eine Anzahl von Übertragungen an die zweite Teilnehmereinheit oder an eine oder mehrere weitere Teilnehmereinheiten bei fehl geschlagenem
Kommunikationsverbindungsaufbau zum Transaktionsregister oder fehlgeschlagenem Versenden des verschlüsselten Transaktionsdatensatz an das Transaktionsregister ein Versenden des verschlüsselten Transaktionsdatensatzes und/oder eines gespeicherten Transaktionsdatensatzes an das Transaktionsregister vor dem Übertragen des elektronischen Münzdatensatzes erfolgen. Damit wird die Anzahl von Übertragungen von Münzdatensätze von der ersten Teilnehmereinheit auf einen Maximalwert begrenzt, wenn in der Zwischenzeit kein Senden der jeweiligen Transaktionsdatensätze an das Transaktionsregister erfolgt ist bzw. erfolgen konnte. Damit wird die erste Teilnehmereinheit gezwungen, die verschlüsselten Transaktionsdatensätze zu senden. Ein Übertragen von Münzdatensätzen ist bis zum Erfolgreichen Versenden der Transaktionsdatensätze unterbunden. Der Schwellwert ist beispielsweise 100, mehr bevorzugt 50, mehr bevorzugt 10 Übertragungen, idealerweise 5 Übertragungen.
In einer bevorzugten Ausgestaltung wird bei erfolgreicher Übertragung des elektronischen Münzdatensatzes und fehlgeschlagenem Kommunikationsverbindungsaufbau zum Transaktionsregister oder fehlgeschlagenem Versenden des verschlüsselten Transaktionsdatensatz an das Transaktionsregister ein Prüfwert in der ersten Teilnehmereinheit inkrementiert. Auf diese Weise ist der zu prüfende Prüfwert stets aktuell in Bezug auf übertragene Münzdatensätze, deren korrespondierender Transaktionsdatensatz noch nicht von der Teilnehmereinheit an das Transaktionsregister versendet wurde.
In einer bevorzugten Ausgestaltung weist das Verfahren die weiteren Schritte auf: Maskieren des elektronischen Münzdatensatzes durch Anwenden einer homomorphen Einwegfunktion auf den elektronischen Münzdatensatz zum Erhalten eines maskierten elektronischen Münzdatensatzes und Registrieren des maskierten elektronischen Münzdatensatzes in einem Münzregister des Bezahlsystems, wobei das Registrieren bevorzugt für ein Umschalten, Aufteilen oder Verbinden maskierter elektronischer Münzdatensätze. Damit werden Modifikationen am Münzdatensatz in dem Münzregister nachgehalten und dokumentiert, ohne dass eine Anonymität im Bezahlsystem aufgehoben ist. Das Maskieren wird später erläutert.
Die Aufgabe wird zudem durch eine zuvor beschriebene Teilnehmereinheit gelöst. Die Teilnehmereinheit weist eine Recheneinheit auf, die eingerichtet ist, das hier beschriebene Verfahren auszuführen. Die Teilnehmereinheit weist zudem Mittel zum Zugreifen auf einen Datenspeicher auf, wobei im Datenspeicher zumindest ein elektronischer Münzdatensatz abgelegt ist. Die Teilnehmereinheit weist zudem eine Schnittstelle auf, die eingerichtet ist zum Aufbau einer Kommunikationsverbindung zu einem Transaktionsregister, um einen verschlüsselten Transaktionsdatensatz an das Transaktionsregister zu senden.
Die Aufgabe wird zudem durch ein Verfahren in einem Transaktionsregister zum Aufbewahren von verschlüsselten Transaktionsdatensätzen eines Bezahlsystems mit den Verfahrensschritten gelöst: Empfangen eines verschlüsselten Transaktionsdatensatzes von einer ersten Teilnehmereinheit, wobei der empfangene verschlüsselte Transaktionsdatensatz durch das zuvor beschriebene Verfahren erzeugt und verschlüsselt wurde; und Ablegen des verschlüsselten Transaktionsdatensatzes in einem Speicherbereich des Transaktionsregisters.
Die Aufgabe wird zudem durch ein Verfahren zum Aufbewahren von verschlüsselten Transaktionsdatensätzen eines Bezahlsystems mit den Verfahrensschritten gelöst: Erzeugen, von einer ersten Teilnehmereinheit, eines Transaktionsdatensatzes bezüglich eines Übertragens des elektronischen Münzdatensatzes an eine zweite Teilnehmereinheit, bevorzugt ein zweites Sicherheitselement, oder bezüglich einer am Münzregister zu registrierenden Modifikation des elektronischen Münzdatensatzes; Verschlüsseln, von der ersten Teilnehmereinheit, des erzeugten Transaktionsdatensatzes mit einem kryptografischen Schlüssel, wobei der kryptografische Schlüssel aus zumindest zwei kryptografischen Teilschlüsseln, bevorzugt mindestens drei kryptografischen Teilschlüsseln, jeweils verschiedener entfernter Instanzen zusammengesetzt ist, Senden des verschlüsselten Transaktionsdatensatzes an ein Transaktionsregister; Empfangen eines verschlüsselten Transaktionsdatensatzes, wobei der empfangene verschlüsselte Transaktionsdatensatz insbesondere durch das zuvor beschriebene Verfahren erzeugt und verschlüsselt wurde; und Ablegen des verschlüsselten Transaktionsdatensatzes in einem Speicherbereich des Transaktionsregisters.
In einer bevorzugten Ausgestaltung ist das Ablegens in dem Transaktionsregister zeitlich auf einen vordefinierten Zeitraum begrenzt. Dieser Zeitraum beginnt beispielsweise mit dem Zeitpunkt des Empfangens des verschlüsselten Transaktionsdatensatzes im Transaktionsregister oder wird durch einen Transaktionszeitpunkt, der als Metadatum am verschlüsselten Transaktionsdatensatz angefügt ist, gestartet. Dieser Zeitraum beträgt beispielsweise einer gesetzlichen Vorgabe, also einer Mindest- oder Maximalzeitdauer zur Aufbewahrung der Transaktionsdatensätze, beispielsweise im Rahmen einer Vorratsdatenspeicherung, beispielsweise X- Monate oder Y- Jahre.
In einer bevorzugten Ausgestaltung umfasst das Verfahren den weiteren Schritt des Entschlüsselns des verschlüsselten Transaktionsdatensatzes mit einem kryptografischen Schlüssel, wobei der Schlüssel zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes aus zumindest zwei kryptografischen Teilschlüsseln jeweiliger verschiedener entfernter Instanzen in dem Transaktionsregister zusammengesetzt wird.
In einer bevorzugten Ausgestaltung erfolgt das Zusammensetzen durch eine Additions-Operation oder eine bitweise XOR-Operation.
In einer bevorzugten Ausgestaltung ist der kryptografische Schlüssel zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes aus einer vordefinierten Anzahl von kryptografischen Teilschlüsseln verschiedener entfernter Instanzen zusammengesetzt, wobei die vordefinierte Anzahl geringer ist als die Gesamtanzahl der verschiedenen Instanzen.
In einer bevorzugten Ausgestaltung erfolgt das Entschlüsseln nur auf externe Anfrage. Diese Anfrage kann das Ergebnis eines Ermittlungsverfahrens sein, in dessen Rahmen zu Prüfen ist, ob eine Transaktion tatsächlich erfolgt ist.
In einer bevorzugten Ausgestaltung weist das Transaktionsregister ein Hardware Security Module, kurz HSM, auf, wobei das Hardware Security Module ein sicherer Schlüsselspeicher ist, in welchem verschiedene Generationen der Teilschlüssel der jeweiligen entfernten Instanzen aufbewahrt sind. Somit können Teilschlüssel einzelner entfernter Instanzen erneuert bzw. ausgetauscht werden, ohne dass die bis dahin abgelegten verschlüsselten Transaktionsdatensätze umverschlüsselt werden müssen oder gar unentschlüsselbar im Transaktionsregister verbleiben müssten. Das Nachhalten der Schlüssel-Generationen erfolgt bevorzugt durch ein HSM des T ransaktionsregi sters .
In einer bevorzugten Ausgestaltung weist das Transaktionsregister ein Hardware Security Module auf gegenüber dem sich die verschiedenen Instanzen vor dem Entschlüsseln des abgelegten verschlüsselten Transaktionsdatensatzes authentisieren. Das HSM kann demnach verschiedene Funktionen erfüllen, es ist primär ein sicherer Schlüsselspeicher und eine sichere Verarbeitungseinheit. Das HSM-Modul kann beispielsweise verschiedene Schlüsselgenerationen der Teilschlüssel enthalten, wobei die entfernten Instanzen sich gegenüber dem HSM authentisieren, um die Entschlüsselung mit allen Generationen freizugeben.
In einer bevorzugten Ausgestaltung wird nach dem Empfangen des verschlüsselten Transaktionsdatensatzes von der ersten Teilnehmereinheit der verschlüsselte Transaktionsdatensatz umverschlüsselt. Damit wird stets beim Empfang der verschlüsselten Transaktionsdaten umverschlüsselt (d.h. entschlüsselt und neu verschlüsselt) und so vermieden, dass im Transaktionsregister Transaktionsdatensätze verschieden verschlüsselt abgelegt sind. Dies vereinfacht die Administration der verschlüsselten Transaktionsdatensätze im Transaktionsregister.
Alternativ wird nach dem Empfangen eines aktualisierten Teilschlüssels von einer der Instanzen der verschlüsselte Transaktionsdatensatz umverschlüsselt. Damit wird bei einem Schlüsselwechsel einer Instanz vermieden, dass im Transaktionsregister Transaktionsdatensätze verschieden verschlüsselt abgelegt sind.
In einer bevorzugten Ausgestaltung wird nach dem Empfangen des verschlüsselten Transaktionsdatensatzes von der ersten Teilnehmereinheit der verschlüsselte Transaktionsdatensatz entschlüsselt und eine Kennung einer (ersten und/oder zweiten) Teilnehmereinheit durch ein Pseudonym im Transaktionsdatensatz ersetzt, um einen entschlüsselten pseudonymisierten Transaktionsdatensatz zu erhalten. Das Ablegen der empfangen verschlüsselten Transaktionsdatensätze ist in einer Ausgestaltung des Verfahrens davon unberührt.
In einer bevorzugten Ausgestaltung ist eine Kennung einer Teilnehmereinheit (beispielsweise Teilnehmer-ID eines Endgeräts) im Bezahlsystem eindeutig einer natürlichen Person zugeordnet. Diese Personenzuordnung wird beispielsweise von einer Herausgeberinstanz des Bezahlsystems oder einer Bankinstanz des Bezahlsystems durchgeführt und ggf. auch dort verwaltet. Diese Personenzuordnung kann auch von einer Dienste-Instanz, beispielsweise einer Instanz, die eine Geldbörse- Applikation für das Endgerät bereitstellt oder die einen Online-Zugang zu einer Cloud- Geldbörse bereitstellt, verwaltet. Diese Zuordnung von Person zu Kennung wird von der jeweiligen Instanz erst nach erfolgreicher Identifizierung der Person, beispielsweise durch Vorlage eines amtlichen Identifikationsdokuments, wie Personalausweis oder Pass, durchgeführt.
In einer bevorzugten Ausgestaltung wird nach dem Empfangen des verschlüsselten Transaktionsdatensatzes von der ersten Teilnehmereinheit der verschlüsselte Transaktionsdatensatz entschlüsselt und ein geldwerter Betrag eines elektronischen Münzdatensatzes durch eine oder mehrere Betragskategorie im Transaktionsdatensatz ersetzt, um einen entschlüsselten betragskategorisierten Transaktionsdatensatz zu erhalten. Eine Betragskategorie ist beispielsweise ein Betragsbereich (von-bis), in dem der geldwerte Betrag des Münzdatensatzes liegt. Eine Betragskategorie ist beispielsweise ein gerundeter Betragswert des geldwerten Betrags, entweder auf- oder abgerundet. Das Ablegen der empfangen verschlüsselten Transaktionsdatensätze ist in einer Ausgestaltung des Verfahrens davon unberührt.
In einer bevorzugten Ausgestaltung wird der entschlüsselte pseudonymisierte oder entschlüsselte betragskategorisierte Transaktionsdatensatz an ein Überwachungsregister des Bezahlsystems gesendet und dort abgelegt. Im Überwachungsregister können so anonymisierte oder pseudonymisierte Transaktionsdatensätze gespeichert werden und dadurch eine Überwachung der Transaktionen im laufenden Betrieb ermöglicht
Mit dem Erstellen von pseudonymisierten Transaktionsdatensätzen wird eine Anonymitätsstufe für den jeweiligen Transaktionsdatensatz geändert. Der pseudonymisierte Transaktionsdatensatz weist immer eine höhere Anonymität auf als der (nicht-pseudonymisierte) Transaktionsdatensatz. Mit dieser höheren Anonymitätsstufe kann der pseudonymisierte Transaktionsdatensatz - in einer Vorgabe des Bezahlsystems - auch unverschlüsselt in den Registerinstanzen (Münzregister, Überwachungsregister, Transaktionsregister) abgelegt werden und für weitergehende Validitäts- Prüfungen im Bezahlsystem verwendet werden. Damit könnten Betrugsfälle oder Manipulationen im Bezahlsystem durch das Bezahlsystem selbst verbessert aufgedeckt werden, eine behördliche Anfrage (richterlicher Beschluss) ist dann ggf. nicht notwendig.
Eine Anonymitätsstufe eines Datensatzes spiegelt einen Grad an Anonymität des (Münz- oder Transaktions-) Datensatzes, also eine Möglichkeit der Zuordnung einer konstanten Identität, wie Teilnehmerkennung, ID-Nummer, natürliche Person, etc., zu einem Datensatz. Bevorzugt wird zwischen mehreren Stufen, beispielsweise 3 Stufen, im Verfahren unterschieden: vollständig anonym (Stufe 1), pseudonym (Stufe 2) oder nicht-anonym (Stufe 3). Ziel des Bezahlsystems ist es, geldwerte Beträge anonym zu übertragen (Stufe 1), d.h. einem Teilnehmer am Bezahlsystem soll es - in Anlehnung an analoges Bargeld - nicht möglich sein, ausgehend von einem empfangenen Münzdatensatz auf die konstante Identität des Teilnehmers zu schließen. Für die Strafverfolgung ist es im Gegenzug aber wichtig, eine konstante Identität zu einem Münzdatensatz zweifelsfrei zuordnen zu können. Deshalb sind die erzeugten Transaktionsdatensätze nicht anonym (Stufe 3), sie sind also eindeutig einer konstanten Identität zugeordnet, beispielsweise einer Teilnehmerkennung, die über eine Personenzuordnung zu einer natürlichen Person führen kann.
Eine Mischform ist ein Pseudonym (stufe 2). Dies ist die temporäre oder dauerhafte Zuordnung einer abgeleiteten Identität zu einem Datensatz. Die Ableitung wird beispielsweise in einer vertrauenswürdigen Instanz, wie einem Überwachungsregister, generiert.
Eine Teilnehmerkennung im verschlüsselten Transaktionsdatensatz weist bevorzugt eine Stufe 3 Anonymität auf, sodass ein Entschlüsseln des Transaktionsdatensatzes die konstante Teilnehmerkennung anzeigt.
Ein geldwerter Betrag im verschlüsselten Transaktionsdatensatz weist bevorzugt eine Stufe 3 Anonymität auf, sodass ein Entschlüsseln des Transaktionsdatensatzes den exakten Betrag anzeigt.
In einer bevorzugten Ausgestaltung ist die Anonymitätsstufe einer Teilnehmerkennung im Transaktionsdatensatz von einer Anonymitätsstufe einer Betragskategorie verschieden, sodass Mischformen (unterschiedliche Abstufungen) in einem pseudonymisierten Transaktionsdatensatz vorhanden sein können.
Die Aufgabe wird zudem durch ein Transaktionsregister für ein Bezahlsystem gelöst. Das Transaktionsregister weist eine Recheneinheit auf, die eingerichtet ist zum Ausführen des Verfahrens des vorhergehend beschrieben Verfahrens in einem Transaktionsregister. Das Transaktionsregister weist zudem Mittel zum Zugreifen auf einen Datenspeicher auf, wobei im Datenspeicher zumindest ein verschlüsselter Transaktionsdatensatz abgelegt ist. Das Transaktionsregister weist zudem eine Schnittstelle auf, die eingerichtet ist zur Kommunikation mit einer Teilnehmereinheit, um einen verschlüsselten Transaktionsdatensatz von der Teilnehmereinheit zu empfangen.
Bevorzugt weist das System Mittel zum Ausführen des Erzeugen-Schritts und des Verschlüsseln- Schritts des vorhergehend beschriebenen Verfahrens auf. Der verschlüsselte Transaktionsdatensatzes kann an ein Transaktionsregister gesendet werden.
In einer bevorzugten Ausgestaltung weist das Transaktionsregister weiter auf: ein Hardware Security Modul, eingerichtet zum sicheren Aufbewahren von Teilschlüsseln unterschiedlicher Generationen; und Entschlüsseln von verschlüsselten Transaktionsdatensätzen.
In einer bevorzugten Ausgestaltung ist das HSM des Transaktionsregister eingerichtet zum Entschlüsseln von verschlüsselten Transaktionsdatensätzen; Ersetzen von einer Kennung einer Teilnehmereinheit durch ein Pseudonym im Transaktionsdatensatz, um einen entschlüsselten pseudonymisierten Transaktionsdatensatz zu erhalten.
In einer bevorzugten Ausgestaltung ist das HSM des Transaktionsregister eingerichtet zum Entschlüsseln von verschlüsselten Transaktionsdatensätzen und zum Ersetzen eines geldwerten Betrags eines elektronischen Münzdatensatzes durch eine Betragskategorie im Transaktionsdatensatz, um einen entschlüsselten betragskategorisierten Transaktionsdatensatz zu erhalten.
In einer bevorzugten Ausgestaltung ist die Schnittstelle eingerichtet zum Senden des entschlüsselten pseudonymisierten oder des entschlüsselten betragskategorisierten Transaktionsdatensatzes an ein Überwachungsregister des Bezahl Systems.
Die Aufgabe wird zudem durch ein Bezahlsystem aufweisend zumindest eine zuvor beschriebene Teilnehmereinheit, wobei die Teilnehmereinheit zum Ausführen des zuvor beschriebenen Verfahrens in einer ersten Teilnehmereinheit eingerichtet ist; und ein zuvor beschriebenes Transaktionsregister, wobei das Transaktionsregister zum Ausführen des zuvor beschriebenen Verfahrens in einem Transaktionsregister eingerichtet.
In einer bevorzugten Ausgestaltung weist das Bezahlsystem weiter auf eine Herausgeberinstanz auf, die ausgebildet ist, einen elektronischen Münzdatensatzes für das Bezahlsystem zu erstellen; und/oder ein Münzregister auf, das eingerichtet ist zum Registrieren eines maskierten elektronischen Münzdatensatzes, wobei das Registrieren bevorzugt für ein Umschalten, Aufteilen oder Verbinden maskierter elektronischer Münzdatensätze ist; und/oder ein Überwachungsregister auf, das eingerichtet ist zum Empfangen eines pseudonymisierten maskierten elektronischen Münzdatensatzes von der Teilnehmereinheit oder zum Empfangen eines entschlüsselten pseudonymisierten oder entschlüsselten betragskategorisierten Transaktionsdatensatzes von dem Transaktionsregister.
Bevorzugt ist das Bezahlsystem auch dazu eingerichtet, elektronische Münzdatensätze von weiteren Herausgeberinstanzen und/oder monetäre Beträge als Buchgeld zu verwalten.
In einer vorteilhaften Ausgestaltung weist der elektronische Münzdatensatz einen monetären Betrag, also ein Datum, das einen Geldwert des elektronischen Münzdatensatzes darstellt, und einen Verschleierungsbetrag, beispielsweise eine Zufallszahl, auf. Darüber hinaus kann der elektronische Münzdatensatz weitere Metadaten aufweisen, beispielsweise welche Währung der monetäre Betrag repräsentiert. Ein elektronischer Münzdatensatz wird durch diese wenigstens zwei Daten (monetärer Betrag, Verschleierungsbetrag) eindeutig repräsentiert. Jeder, der Zugriff auf diese Daten eines elektronischen Münzdatensatzes hat, kann diesen elektronischen Münzdatensatz zum Bezahlen verwenden. Die Kenntnis dieser zwei Daten (monetärer Betrag, Verschleierungsbetrag) ist also gleichbedeutend mit dem Besitz des digitalen Geldes. Dieser elektronische Münzdatensatz kann zwischen zwei Teilnehmereinheiten direkt übertragen werden. In einer Ausgestaltung der Erfindung ist zum Austausch von digitalem Geld nur die Übertragung des monetären Betrags und des Verschleierungsbetrags notwendig. In einer Ausgestaltung wird auch ein Status (aktiv, inaktiv) des elektronischen Münzdatensatzes mit zum Münzdatensatzes hinzugezählt, sodass dieser dann aus drei Daten (monetärer Betrag, Verschleierungsbetrag, Status) besteht. Alternativ wird der Status eines Münzdatensatzes nicht an den Münzdatensatz angefügt und nur im Sicherheitselement selbst und/oder dem Münzregister geführt.
In einer bevorzugten Ausgestaltung wird im jeweiligen Verfahren jedem elektronischen Münzdatensatz ein entsprechender maskierter elektronischer Münzdatensatz zugeordnet. Die Kenntnis eines maskierten elektronischen Münzdatensatzes berechtigt nicht dazu, das digitale Geld, das durch den elektronischen Münzdatensatz repräsentiert wird, auszugeben. Dies stellt einen wesentlichen Unterschied zwischen den maskierten elektronischen Münzdatensätzen und den (nicht maskierten) elektronischen Münzdatensätzen dar. Ein maskierter elektronischer Münzdatensatz ist einzigartig und zudem eindeutig einem elektronischen Münzdatensatz zuzuordnen, es gibt also eine 1-zu-l Beziehung zwischen einem maskierten elektronischen Münzdatensatz und einem (nicht-maskierten) elektronischen Münzdatensatz. Das Maskieren des elektronischen Münzdatensatzes erfolgt bevorzugt durch eine Recheneinheit der Teilnehmereinheit. Die Teilnehmereinheit weist zumindest einen elektronischen Münzdatensatz auf. Alternativ kann das Maskieren durch eine Recheneinheit einer den elektronischen Münzdatensatz empfangende Teilnehmereinheit erfolgen.
Dieser maskierte elektronische Münzdatensatz wird durch Anwenden einer homomorphen Einwegfunktion, insbesondere einer homomorphen kryptographi sehen Funktion, erhalten. Diese Funktion ist eine Einwegfunktion, also eine mathematische Funktion, die komplexitätstheoretisch „leicht“ berechenbar, aber „schwer“ bis praktisch unmöglich umzukehren ist. Hierbei wird unter Einwegfunktion auch eine Funktion bezeichnet, zu der bislang keine in angemessener Zeit und mit vertretbarem Aufwand praktisch ausführbare Umkehrung bekannt ist. Somit ist die Berechnung eines maskierten elektronischen Münzdatensatzes aus einem elektronischen Münzdatensatz vergleichbar mit der Generierung eines öffentlichen Schlüssels in einem Verschlüsselungsverfahren über eine Restklassengruppe. Vorzugsweise wird eine Einwegfunktion verwendet, die auf eine Gruppe operiert, in der das diskrete Logarithmusproblem schwer zu lösen ist, wie z. B. ein kryptographisches Verfahren analog einer elliptischer-Kurve-Verschlüsselung, kurz ECC, aus einem privaten Schlüssel eines entsprechenden Kryptographie-Verfahrens. Die umgekehrte Funktion, also die Erzeugung eines elektronischen Münzdatensatzes aus einem maskierten elektronischen Münzdatensatz, ist dabei - äquivalent zur Erzeugung des privaten Schlüssels aus einem öffentlichen Schlüssel in einem Verschlüsselungsverfahren über einer Restklassengruppe - sehr zeitintensiv. Wenn im vorliegenden Dokument von Summen und Differenzen oder anderen mathematischen Operationen die Rede ist, dann sind dabei im mathematischen Sinn die jeweiligen Operationen auf der entsprechenden mathematischen Gruppe zu verstehen, beispielsweise der Gruppe der Punkte auf einer elliptischen Kurve.
Die Einwegfunktion ist homomorph, also ein kryptographisches Verfahren, welches über Homomorphie-Eigenschaften verfügt. Somit können mit dem maskierten elektronischen Münzdatensatz mathematische Operationen durchgeführt werden, die parallel dazu auch auf dem (nicht-maskierten) elektronischen Münzdatensatz durchgeführt und somit nachvollzogen werden können. Mit Hilfe der homomorphen Einwegfunktion können Berechnungen mit maskierten elektronischen Münzdatensätzen in dem Münzregister und/oder dem Überwachungsregister nachvollzogen werden, ohne dass die entsprechenden (nicht maskierten) elektronischen Münzdatensätze dort bekannt sind. Daher können bestimmte Berechnungen mit elektronischen Münzdatensätzen, beispielsweise für ein Verarbeiten des (nicht maskierten) elektronischen Münzdatensatzes (zum Beispiel Aufteilen oder Verbinden), auch parallel mit den dazugehörigen maskierten elektronischen Münzdatensätzen im Münzregister nachgewiesen werden, beispielsweise zu Validierungsprüfungen (=Gültigkeiten). Zudem kann parallel die Überwachung über die Rechtmäßigkeit des jeweiligen elektronischen Münzdatensatzes im Überwachungsregister nachgewiesen werden. Die Homomorphie-Eigenschaften treffen zumindest auf Additions- und Subtraktionsoperationen zu, sodass ein Umschalten (=Switch), Aufteilen (=Split) oder Kombinieren (=Verbinden) von elektronischen Münzdatensätzen auch mittels der entsprechend maskierten elektronischen Münzdatensätze im Münzregister bzw. der Prüfung, ob der elektronische Münzdatensatz zurückzugeben (löschen) oder Umzumünzen ist im Überwachungsregister festgehalten und von anfragenden Teilnehmereinheiten bzw. deren Sicherheitselementen und/oder von dem Münzregister und/oder von dem Überwachungsregister nachvollzogen werden kann, ohne Kenntnis über den monetären Betrag und die durchführende Teilnehmereinheit zu erlangen.
Die Homomorphie-Eigenschaft ermöglicht es also, eine Eintragung von gültigen und ungültigen elektronischen Münzdatensätzen auf Basis ihrer maskierten elektronischen Münzdatensätze in einem Münzregister und einem Überwachungsregister zu führen, ohne Kenntnis der elektronischen Münzdatensätze, auch wenn diese elektronische Münzdatensätze verarbeitet (aufgeteilt, verbunden, umschalten) oder direkt übertragen werden, also eine Aktion mit diesen elektronischen Münzdatensätzen durchgeführt wird. Dabei wird stets sichergestellt, dass kein zusätzlicher monetärer Betrag geschaffen wurde oder dass eine Identität der Teilnehmereinheiten bzw. deren Sicherheitselementen in dem Münzregister oder dem Überwachungsregister festgehalten wird. Das Maskieren ermöglicht ein hohes Maß an Sicherheit, ohne einen Einblick in den monetären Betrag oder die Teilnehmereinheit zu geben.
Beim direkten Übertragen eines elektronischen Münzdatensatzes von der ersten Teilnehmereinheit an eine zweite Teilnehmereinheit haben zwei Teilnehmereinheiten gleichzeitig Kenntnis über den zu übertragenden elektronischen Münzdatensatz. Es gilt zu verhindern, dass die sendende erste Teilnehmereinheit den elektronischen Münzdatensatz bei einer anderen (dritten) Teilnehmereinheit ebenfalls zum Bezahlen verwendet (sogenanntes Double-Spending). Dabei kann vor dem Übertragen ein Status des elektronischen Münzdatensatzes auf Inaktiv-Status gesetzt, um den elektronischen Münzdatensatz zu invalidieren, dann erfolgt das Senden (als erster Schritt des Übertragens) an die zweite Teilnehmereinheit und bei Vorhandensein einer Empfangsbestätigung von der zweiten Teilnehmereinheit erfolgt ein Löschen des elektronischen Münzdatensatzes in der ersten Teilnehmereinheit (als zweiter Schritt des Übertragens). Eine Löschungsbestätigung von der ersten Teilnehmereinheit kann an das Münzregister oder die zweite Teilnehmereinheit gesendet werden, um ein erfolgreiches Löschen (durchgeführt in der ersten Teilnehmereinheit) des elektronischen Münzdatensatzes anzuzeigen.
Zudem kann der übertragene elektronische Münzdatensatz von der ersten Teilnehmereinheit an eine zweite Teilnehmereinheit umgeschaltet (=switch) werden. Das Umschalten kann bevorzugt automatisch beim Empfangen der Löschungsbestätigung eines elektronischen Münzdatensatzes in der zweiten Teilnehmereinheit geschehen. Zusätzlich kann es auch auf Anforderung, beispielsweise eines Befehls von der ersten Teilnehmereinheit und/oder der zweiten Teilnehmereinheit erfolgen. Zusätzlich kann ein elektronischer Münzdatensatz auch in zumindest zwei elektronische Münzteildatensätze aufgeteilt werden („Split“). Zusätzlich können zwei elektronische Münzdatensätze zu einem elektronischen Münzdatensatz verbunden werden („Merge“). Das Umschalten, das Aufteilen und das Verbinden sind verschiedene Modifikation an einem elektronischen Münzdatensatz, also Aktionen mit dem elektronischen Münzdatensatz. Diese Modifikationen bedingen ein Registrieren des maskierten Münzdatensatzes im Münzregister des Bezahlsystems. Das konkrete Durchführen der einzelnen Modifikationen wird später erläutert.
Ein Umschalten erfolgt zudem, wenn ein elektronischer Münzdatensatz verändert, beispielsweise aufgeteilt oder mit anderen elektronischen Münzdatensätzen verbunden wurde, insbesondere um einen zu zahlenden monetären Betrag passend begleichen zu können.
Nachstehend wird dieses Pseudonymisieren näher erläutert: Das Übertragen von elektronischen Münzdatensätzen im Bezahlsystem ist anonym soweit die Anonymität nicht explizit durch zusätzliche Maßnahmen aufgehoben werden soll. Es könnte eine Forderung im Bezahlsystem sein, die Anonymität in Abhängigkeit eines Werts für monetäre Beträge aufzuheben. Mit anderen Worten: Eine typische Anforderung im Bezahlsystem könnte sein, monetäre Beträge, unterhalb eines bestimmten Grenzwerts anonym zu senden. Wird dieser Grenzwert überschritten, erfolgt die Übertragung im System deanonymisiert.
In einer bevorzugten Ausgestaltung weist das Verfahren die weiteren Schritte auf: Maskieren des elektronischen Münzdatensatzes durch Anwenden einer homomorphen Einwegfunktion auf den elektronischen Münzdatensatz zum Erhalten eines maskierten elektronischen Münzdatensatzes; Verknüpfen des maskierten elektronischen Münzdatensatzes mit einem Pseudonym zum Erhalten eines pseudonymisierten maskierten elektronischen Münzdatensatzes; und Senden des pseudonymisierten maskierten elektronischen Münzdatensatzes an ein Überwachungsregister des Bezahlsystems. Damit werden Modifikationen am elektronischen Münzdatensatz in dem Münzregister nachgehalten und in der Überwachungsregister unter einem Pseudonym dokumentiert, ohne dass eine Anonymität im Bezahlsystem aufgehoben ist. Das Überwachungsregister kann somit auch bei Kenntnis der Zugehörigkeit von Pseudonym und Teilnehmereinheit die bei der Teilnehmereinheit ausgehenden Transaktionen identifizieren.
Im oben erwähnten erfindungsgemäßen Verfahren wird der pseudonymisierter maskierter elektronischer Münzdatensatz bevorzugt im Erzeugen- Schritt durch die erste Teilnehmereinheit, weiter bevorzugt anstelle des maskierten elektronischen Münzdatensatzes, mit in den Transaktionsdatensatz eingebracht und somit in verschlüsselter Form an das Transaktionsregister gesendet. Eine spätere Entschlüsselung deckt dann auch das Pseudonym auf, unter dem die Transkation stattgefunden hat.
Dieses Verfahren stellt eine Alternative zu dem oben beschriebenen Bereitstellen der pseudonymisierten Transaktionsdaten des Transaktionsregister dar und könnte parallel oder zusätzlich zu diesem Verfahren im Überwachungsregister eingesetzt sein. Die Auswahl des jeweiligen Pseudonymisier-Verfahrens kann im Bezahlsystem flexibel eingestellt und an die tatsächlichen Anforderungen des Bezahlsystems angepasst werden, beispielsweise an die Rechenleistung des Transaktionsregisters oder des Überwachungsregisters oder eine Übertragungskapazität im Bezahlsystem.
Da eine digitale Bezahltransaktion (das Übertragung von elektronischen Münzdatensätzen) eines großen geldwerten Betrags auch in mehrere digitale Bezahltransaktionen kleinerer geldwerter Beträge aufgeteilt werden könnte, die jeweils unterhalb des Grenzwertes liegen können, muss der Grenzwert teilnehmereinheitenspezifisch und/oder zeitraumabhängig sein. Aufgrund der intransparenten vielfachen (direkten) Übertragung eines Münzdatensatzes zwischen einer Vielzahl von verschiedenen Teilnehmereinheiten, ist diese Forderung nach einer Deanonymisierung, auch Re-Identifikation genannt, zudem nicht auf einzelne Übertragungen (Transaktionen) zwischen zwei Teilnehmereinheiten gerichtet, sondern betrifft in der Regel die Summe aller Transaktionen innerhalb einer bestimmten Zeiteinheit (Zeitdauer), die von einer Teilnehmereinheit empfangen und/oder gesendet werden. Es wird daher ein Mechanismus bereitgestellt, mit dem festgestellt werden kann, wie hoch die Summe aller monetären Beträge, die von einer Teilnehmereinheit gesendet oder empfangen wurden, innerhalb einer bestimmten Zeiteinheit ist. Dazu wird ein Verfahren beschrieben, das die Aufhebung der Anonymität einer sendenden Teilnehmereinheit bei Überschreitung eines Grenzwertes pro Zeiteinheit ermöglicht.
Um einen solchen Mechanismus zur Deanonymisierung zu ermöglichen, wird in einer bevorzugten Ausgestaltung des Verfahrens ein Pseudonymisieren durchgeführt. Dazu wird vor dem Maskieren-Schritt ein Verknüpfen-Schritt durchgeführt, um ein Pseudonym der ersten Teilnehmereinheit mit dem elektronischen Münzdatensatz zu verknüpfen. Das Pseudonym ist bevorzugt teilnehmereinheitenspezifisch. Ein Pseudonym ist jegliche Art von verschleierter Identität, die es ermöglicht, dass nicht in bloßer Kenntnis des elektronischen Münzdatensatzes direkt auf die Teilnehmereinheit und die damit durchgeführten Transaktionen zurückgeschlossen werden kann.
Die Teilnehmereinheit muss für jeden empfangenen Münzdatensatz eine Modifikation (Aufteilen, Umschalten, Verbinden) durchführen, um das Pseudonym mit dem Münzdatensatz zu verknüpfen. Das mit jeder Modifikation (für das Validieren der Modifikation) einhergehende Registrieren in dem Münzregister ist ausreichend, um alle Münzdatensatz-Transaktionen, die mit der Teilnehmereinheit durchgeführt wurden, aufgrund des verknüpften Pseudonyms eindeutig dieser Teilnehmereinheit zuordnen zu können. Ein Überwachungsregister kann bei Kenntnis der Zugehörigkeit von Pseudonym und Teilnehmereinheit die bei der Teilnehmereinheit eingehenden Transaktionen identifizieren. Somit werden Modifikationen des elektronischen Münzdatensatzes mit einem auf der Teilnehmereinheit gespeicherten Pseudonym verknüpft. Dieses Pseudonym kann entweder dauerhaft oder nur für einen bestimmten Zeitraum gültig sein.
Der Unterschied zwischen einem anonymen maskierten elektronischen Münzdatensatz und einem pseudonymisierten maskierten elektronischen Münzdatensatz liegt also in der Identifizierbarkeit der Teilnehmereinheit durch das Überwachungsregister, wenn es das Pseudonym verwendet. Ein anonymer maskierter elektronischer Münzdatensatz enthält keinerlei Information über seine Herkunft, kann also nicht mit einer Teilnehmereinheit in Verbindung gebracht werden. Dementgegen hat ein pseudonymisierter maskierter elektronischer Münzdatensatz eine Verknüpfung mit einem Pseudonym der Teilnehmereinheit, so dass die Teilnehmereinheit, was den pseudonymisierten maskierten elektronischen Münzdatensatz an das Überwachungsregister versendet hat, über das verknüpfte Pseudonym identifiziert werden kann.
Der beschriebene Mechanismus ist ausreichend, um zu bestimmen, ob die Summe der monetären Beträge aller Transaktionen einer Teilnehmereinheit unterhalb eines Grenzwertes, bevorzugt innerhalb einer bestimmten Zeiteinheit, liegen. Wird erkannt, dass der Grenzwert durch eine gewünschte Modifikation überschritten wird, könnte das Überwachungsregister eine derartige Modifikation prompt unterbinden, indem es die Registrierung des entsprechenden elektronischen Münzdatensatzes in dem Münzregister blockiert bzw. ablehnt. Alternativ oder zusätzlich könnte die Teilnehmereinheit informiert werden, dass die Modifikation (und damit die Transkation) nur durchgeführt würde, wenn die Teilnehmereinheit sich deanonymisiert, also beispielsweise persönliche Zugangsdaten offenlegt, bevor die Modifikation registriert und der elektronische Münzdatensatz auf gültig gesetzt wird, wodurch die Transaktion akzeptiert würde.
In einer bevorzugten Ausgestaltung des Pseudonymisierens wird durch das Senden des pseudonymisierten maskierten elektronischen Münzdatensatzes anstelle eines anonymen maskierten elektronischen Münzdatensatzes die Anzahl von Bereichsbestätigungen oder Bereichsnachweisen, welche das Überwachungsregister von der ersten Teilnehmereinheit anfordert, reduziert.
Das Überwachungsregister, das Münzregister und/oder die erste Teilnehmereinheit können die maskierten elektronischen Münzdatensätze in einem anonymen oder in einem pseudonymen Modus verarbeiten. Das Überwachungsregister fordert in einem anonymen Modus notwendige und weitere (nachholbare) Bereichsnachweise oder Bereichsbestätigungen an. Im pseudonymen Modus fordert das Überwachungsregister zumindest eine der weiteren Bereichsnachweise oder Bereichsbestätigungen nicht an, prüft jedoch für das Pseudonym ob ein (Nachhol -)Kriterium erfüllt ist. Ein elektronischer Münzdatensatz kann bereits als gültig behandelt werden, wenn die notwendigen Prüfungen erfolgt sind. Erst wenn das (Nachhol -)Kriterium erfüllt ist, werden Bereichsnachweise oder ein Summenbereichsnachweis (bzw. -bestätigung) von der Teilnehmereinheit angefordert. Als (Nachhol -)Kriterien können beispielsweise für das Pseudonym ein Zeitraum oder eine Anzahl maskierter elektronischer Münzdatensätze verwendet werden.
In einer weiter bevorzugten Ausgestaltung des Pseudonymisierens empfängt die erste Teilnehmereinheit eine Anforderung für eine Summenbereichsbestätigung oder eines Summenbereichsnachweises von dem Überwachungsregister, und sendet die angeforderte Summenbereichsbestätigung oder den angeforderten Summenbereichsnachweis an das Überwachungsregister.
In einer alternativen Ausgestaltung erstellt die erste Teilnehmereinheit eine unaufgeforderte Summenbereichsbestätigung oder einen unaufgeforderten Summenbereichsnachweis, und sendet die unaufgeforderte Summenbereichsbestätigung oder den angeforderten Summenbereichsnachweises an das Überwachungsregister.
Eine Summenbereichsbestätigung bzw. ein Summenbereichsnachweis ist dabei eine Angabe der Teilnehmereinheit über eine Summe von monetären Beträgen einer Mehrzahl von elektronischen Münzdatensätzen, bevorzugt direkt zwischen Teilnehmereinheiten übertragenen elektronischen Münzdatensätzen. Diese Summenangabe wird in dem Überwachungsregister mit einer Bereichsangabe abgeglichen. Bei Überschreitung der Bereichsangabe erfolgt ein Deanonymisieren der elektronischen Münzdatensätze, um das Übertragen großer monetärer Beträge abzusichern bzw. kontrollieren zu können.
Bevorzugt bildet die erste Teilnehmereinheit dazu eine Summe aus monetären Beträgen mehrerer elektronischer Münzdatensätze bestätigt mit der Summenbereichsbestätigung, dass die gebildete Summe in einem Bereich liegt. Die Summenbereichsbestätigung wird in dem Überwachungsregister als eine Anzeige der Teilnehmereinheit verstanden und die Teilnehmereinheit wird als vertrauenswürdig eingestuft.
In einer alternativen Ausgestaltung des Pseudonymisierens erstellt die erste Teilnehmereinheit für mehrere elektronische Münzdatensätze einen durch das Überwachungsregister überprüfbaren Summenbereichsnachweis. Der Summenbereich wird dann also von dem Überwachungsregister geprüft und dort erfolgt die Bestätigung, dass die Summe im Bereich liegt (oder nicht). Der Summenbereichsnachweis ist bevorzugt auch Teil des Transaktionsdatensatzes für das Transaktionsregister.
In einer bevorzugten Ausgestaltung des Pseudonymisierens umfassen die mehreren elektronischen Münzdatensätze nur ausgewählte elektronische Münzdatensätze. Somit wird die Summenbereichsbestätigung bzw. der Summenbereichsnachweis nicht für alle elektronische Münzdatensätze der Teilnehmereinheiten durchgeführt, sondern nur für eine gezielte Auswahl. Die Auswahl betrifft in einer Ausgestaltung nur elektronische Münzdatensätze von gesendeten pseudonymisierten maskierten elektronischen Münzdatensätzen. In einer alternativen Ausgestaltung des Pseudonymisierens sind nur elektronische Münzdatensätze von gesendeten anonymen maskierten elektronischen Münzdatensätzen oder gesendeten pseudonymisierten maskierten elektronischen Münzdatensätzen betroffen. In einer alternativen Ausgestaltung des Pseudonymisierens sind nur elektronische Münzdatensätze von gesendeten anonymen maskierten elektronischen Münzdatensätzen, gesendeten pseudonymisierten maskierten elektronischen Münzdatensätzen und/oder nicht an das Überwachungsregister gesendeten maskierten elektronischen Münzdatensätzen betroffen. In einer bevorzugten Ausgestaltung des Pseudonymisierens werden die mehreren elektronischen Münzdatensätze nach einem vorausgewählten Zeitraum als Auswahlkriterium ausgewählt. Als Zeitraum kann ein Tag, eine Woche oder auch ein viel geringerer Zeitraum ausgewählt werden.
Diese Auswahl wird bevorzugt maskiert und dann als Teil des Transaktionsdatensatzes dem Transaktionsregister in verschlüsselter Form gesendet.
In einer alternativen oder zusätzlichen Ausgestaltung des Pseudonymisierens ist als Auswahlkriterium eine Liste in der ersten Teilnehmereinheit oder dem Überwachungsregister zu verwenden, anhand derer Liste die elektronischen Münzdatensätze ausgewählt werden.
Diese Liste wird bevorzugt maskiert und dann als Teil des Transaktionsdatensatzes dem Transaktionsregister in verschlüsselter Form gesendet.
In einer bevorzugten Ausgestaltung des Pseudonymisierens fordert das Überwachungsregister im Rahmen einer Summenprüfung Bereichsbestätigungen oder Bereichsnachweise von Teilnehmereinheiten an. Vorzugsweise wendet das Überwachungsregister für anonyme maskierte elektronische Münzdatensatze einen ersten Summenprüfmodus an. Vorzugsweise wendet das Überwachungsregister für pseudonymisierte maskierte elektronische Münzdatensätze einen zweiten Summenprüfmodus an.
In einer bevorzugten Ausgestaltung des Pseudonymisierens prüft das Überwachungsregister für jeden empfangenen modifizierten elektronischen Münzdatensatz einen Bereichsnachweis.
In einer bevorzugten Ausgestaltung des Pseudonymisierens fordert das Überwachungsregister regelmäßig oder quasizufällig Bereichsbestätigungen oder Bereichsnachweise von Teilnehmereinheiten an. Dies erfolgt beispielsweise in dem ersten Summenprüfmodus. In einer alternativen oder zusätzlichen Ausgestaltung des Pseudonymisierens fordert das Überwachungsregister erst ab einer Anzahl von für ein Pseudonym empfangenen Münzdatensätzen von der Teilnehmereinheit eine Bereichsbestätigung oder einen Bereichsnachweis an. Dies erfolgt beispielsweise in dem zweiten Summenprüfmodus. Diese Anzahl ist bevorzugt abhängig vom Teilnehmereinheitentyp und/oder vom Münzbetragsbereich. Damit können die Bereichsnachweise bzw. Bereichsbestätigungen flexibel auf eine bestimmte Nutzer Situation abgestimmt werden und erhöhen so die Sicherheit des Bezahl Systems.
Ausreichend ist prinzipiell das Identifizieren der ausgehenden Transaktionen oder der eingehenden Transaktionen, sodass in einer Ausgestaltung das Maskieren des elektronischen Münzdatensatzes und Verknüpfen des maskierten elektronischen Münzdatensatzes in der zweiten Teilnehmereinheit mit einem Pseudonym der zweiten Teilnehmereinheit in der zweiten Teilnehmereinheit und Senden des pseudonymisierten maskierten elektronischen Münzdatensatzes an das Überwachungsregister nicht durchgeführt wird.
Diese identifizierten ausgehenden Transaktionen werden bevorzugt als Teil des Transaktionsdatensatzes dem Transaktionsregister in verschlüsselter Form gesendet.
Der Verknüpfen-Schritt des Pseudonymisierens wird bevorzugt durch ein Signieren des jeweiligen maskierten elektronischen Münzdatensatzes in der zweiten Teilnehmereinheit mit einem privaten Signaturschlüssel der zweiten Teilnehmereinheit zum Erhalten eines signierten maskierten elektronischen Münzdatensatzes als pseudonymisierter maskierter elektronischer Münzdatensatz oder als pseudonymisierter maskierter übertragener elektronischer Münzdatensatz durchgeführt.
Das Signieren erfolgt mit einem privaten Signaturschlüssel der Teilnehmereinheit. Dieser Signaturschlüssel ist bevorzugt teilnehm ereinheitenspezifi sch, d.h. in Kenntnis des Verifikationsschlüssels kann nachvollzogen werden, wer den Münzdatensatz zuletzt modifiziert (umgeschaltet, aufgeteilt, verbunden) hat. Der signierte maskierte elektronische Münzdatensatz wird in dem Überwachungsregister registriert.
Im oben erwähnten erfindungsgemäßen Verfahren wird der signierte maskierte elektronische Münzdatensatz bevorzugt im Erzeugen- Schritt durch die erste Teilnehmereinheit, weiter bevorzugt anstelle des maskierten elektronischen Münzdatensatzes, mit in den Transaktionsdatensatz eingebracht und somit in verschlüsselter Form an das Transaktionsregister gesendet. Eine spätere Entschlüsselung deckt dann auch die Signatur auf, unter der die Transkation stattgefunden hat.
Zum Erzeugen einer Signatur wird demnach bevorzugt ein asymmetrisches Kryptosystem, bei dem die Teilnehmereinheit mit Hilfe eines geheimen Signaturschlüssels, hier als privater Signaturschlüssel oder „Private Key“ bezeichnet, zu einem Datensatz einen Wert berechnet. Dieser Wert ermöglicht es jedem, mit Hilfe eines öffentlichen Verifikationsschlüssels, dem „Public Key“, die Urheberschaft und Integrität des Datensatzes zu prüfen.
Bevorzugt wird mit dem Schritt des Registrierens eine Prüfung der Signatur in der Überwachungsregister erfolgen, wobei das Überwachungsregister dazu den öffentlichen Verifikationsschlüssel der Signatur aufweist. Die Signatur kann nun von dem Überwachungsregister geprüft werden, indem ein öffentlicher Verifikationsschlüssel der Signatur dort bekannt ist.
Der öffentliche Verifikationsschlüssel zum Prüfen der Signatur ist bevorzugt nur dem Überwachungsregister bekannt, wodurch das Verfahren für die Teilnehmereinheiten untereinander weiterhin anonym bleibt.
Bevorzugt registriert das Münzregister jegliches Modifizieren, also das Umschalten, Aufteilen und/oder Verbinden zusammen mit der Signatur der Teilnehmereinheit. Auf diese Weise kann eine Überwachung und Bestimmung der Summe von monetären Beträgen für alle Transaktionen einer Teilnehmereinheit durch das Münzregister und/oder das Überwachungsregister erfolgen. Die Signatur ist beispielsweise ein Teil des Transaktionsdatensatzes und wird entweder in verschlüsselter Form oder auch im Klartext an das Transaktionsregister gesendet und dort abgelegt (archiviert).
Bevorzugt ist die Signatur innerhalb einer bestimmten Zeiteinheit gültig, wobei die bestimmte Zeiteinheit bevorzugt ein Tag ist. Somit kann für diese bestimmte Zeiteinheit das Transaktionsvolumen (=Summe der monetären Beträge bei Transaktionen) pro Teilnehmereinheit geprüft werden.
Jede Teilnehmereinheit hat demnach ein asymmetrisches Schlüsselpaar, um jede Modifikation mit dem privaten Signaturschlüssel zu signieren. Der öffentliche Schlüssel ist dem Überwachungsregister (und auch dem Münzregister) bekannt. Somit kann das Überwachungsregister jede Transaktion mit der Teilnehmereinheit als Absender oder Empfänger des Münzdatensatzes verknüpfen.
Der beschriebene Mechanismus ist ausreichend, um zu erfassen (messen), ob die Summe aller monetären Beträge pro Teilnehmereinheit (=Transaktionen) innerhalb eines Grenzwertes pro Zeiteinheit, beispielsweise einem Tagesgrenzwert, liegt.
Nachfolgend wird das Erkennen von Rückgabekriterien für bereits ausgegebene Münzdatensätze, beispielsweise dass eine Münzdatensatz verfallen soll, erläutert: Die elektronischen Münzdatensätze werden von einer zentralen Herausgeberinstanz ausgegeben, wobei jeder elektronische Münzdatensatz zusätzlich einen Prüfwert aufweist. Der Prüfwert wird bei direktem Übertragen des elektronischen Münzdatensatzes zwischen zwei Teilnehmereinheiten inkrem entiert oder der Prüfwert ist invariant bei einer, von Teilnehmereinheiten mit dem elektronischen Münzdatensatz durchgeführten Aktion (Modifikation). Das Verfahren umfasst den folgenden Schritt: Bestimmen durch die Teilnehmereinheit anhand des Prüfwertes eines elektronischen Münzdatensatzes, ob dieser elektronische Münzdatensatz von der Teilnehmereinheit bei dem Bezahlsystem angezeigt wird oder Bestimmen durch die Teilnehmereinheit anhand des Prüfwerts des elektronischen Münzdatensatzes, ob der elektronische Münzdatensatz an die zentrale Herausgeberinstanz zurückgegeben wird. Somit wird in einer bevorzugten Ausgestaltung für das Erkennen von Rückgabekriterien anhand des bereits oben erwähnten Prüfwerts für nichtgesendete Transaktionsdatensätze oder anhand eines weiteren Prüfwerts auch bestimmt, ob der elektronische Münzdatensatz von der ersten Teilnehmereinheit bei dem Bezahlsystem, insbesondere einem Münzregister, angezeigt wird und/oder ob der elektronische Münzdatensatz an die zentrale Herausgeberinstanz zurückgegeben wird.
Jeder Prüfwert des elektronischen Münzdatensatzes wird im Verfahren verwendet, um eine Kontrollfunktion im Bezahlsystem zu ermöglichen beziehungsweise zu verbessern. Jeder Prüfwert ist bevorzugt ein Datenelement des elektronischen Münzdatensatzes das von der Teilnehmereinheit ausgelesen werden kann oder ein Datenelement in der Teilnehmereinheit und dessen Wert kann von der Teilnehmereinheit bestimmt werden. Der Prüfwert für die Rückgabekriterien ist an einen elektronischen Münzdatensatz gekoppelt.
Der Prüfwert für die Rückgabekriterien wird in einer ersten Ausgestaltung bei direktem Übertragen des elektronischen Münzdatensatzes zwischen zwei Teilnehmereinheiten inkrementiert (=schrittweise erhöht). Das Inkrementieren erfolgt entweder von einer sendenden Teilnehmereinheit unmittelbar vor dem Senden des Münzdatensatzes an ein empfangendes Endgerät inkrementiert. Oder das Inkrementieren erfolgt in einer empfangenden Teilnehmereinheit unmittelbar nach dem Empfang des Münzdatensatzes. Somit wird die Anzahl von direkten Übertragungen zwischen Teilnehmereinheiten für jeden Münzdatensatz festgehalten.
Der Prüfwert ist in einer zweiten (alternativ zur ersten) Ausgestaltung invariant bei einer, von Teilnehmereinheiten mit dem elektronischen Münzdatensatz durchgeführten Aktion (aktionsinvariant). Aktionsinvariant bedeutet, dass bei einer Aktion mit dem Münzdatensatz der Prüfwert unverändert erhalten bleibt. Der aktionsinvariante Prüfwert ist nicht-individuell für den elektronischen Münzdatensatz, sondern gruppenspezifisch und gilt daher für eine Mehrzahl von unterschiedlichen Münzdatensätzen, um eine Anonymität zu bewahren und eine Münzdatensatz verfolgung zu verhindern. Als Aktion mit einem Münzdatensatz wird jede von einem Endgerät durchgeführte Modifikation am Münzdatensatz, also insbesondere das Umschalten, das Aufteilen, das Kombinieren, wie später noch beschrieben wird. Zudem ist als Aktion jedes Übertragen des Münzdatensatzes, beispielsweise zu einer (anderen) Teilnehmereinheit oder auch einer Instanz im Bezahlsystem, gemeint. Zudem ist als Aktion das Einlösen des Münzdatensatzes zum Gutschreiben eines monetären Betrags des Münzdatensatzes oder das Wechseln des Währungssystems gemeint. Diese Aktionen werden von Teilnehmereinheiten durchgeführt und verändern den Prüfwert nicht.
Anhand des Prüfwerts des elektronischen Münzdatensatzes wird durch die Teilnehmereinheit bestimmt, ob dieser elektronische Münzdatensatz bei dem Bezahlsystem angezeigt (=gemeldet) wird. Beispielsweise wenn die Anzahl von Übertragungen zwischen Teilnehmereinheiten einen vordefinierten Schwellwert übersteigt, wird so dem Bezahlsystem der elektronischen Münzdatensatz angezeigt. Das Anzeigen entspricht in einer beispielhaften Ausgestaltung des Verfahrens dem Senden eines Umschalten-Kommando an ein Münzregister des Bezahlsystems, um dort ein Umschalten des Münzdatensatz auf die den Münzdatensatz sendende Teilnehmereinheit zu veranlassen. Das Anzeigen veranlasst in einer alternativen beispielhaften Ausgestaltung des Verfahrens ein Markieren des Münzdatensatzes in einem Überwachungsregister des Bezahl Systems. Der Prüfwert und/oder der Münzdatensatz kann, muss aber nicht, für den Zweck des Anzeigens an das Bezahlsystem übertragen werden. Die Rückgabe des elektronischen Münzdatensatzes durch die Teilnehmereinheit bedingt entweder das Einlösen eines mit dem elektronischen Münzdatensatz verbundenen monetären Betrags oder das Ausgeben eines neuen elektronischen Münzdatensatzes mit einem identischen monetären Betrag.
Die Rückgabe des elektronischen Münzdatensatzes durch die Teilnehmereinheit kann ein Zurücksetzen oder Löschen aller zu dem elektronischen Münzdatensatz vorhandenen Einträge in dem Überwachungsregister im Bezahlsystem auslösen. Damit werden digitale Spuren des elektronischen Münzdatensatzes gelöscht und die Anonymität des Verfahrens abgesichert.
Alternativ wird anhand des Prüfwerts des elektronischen Münzdatensatzes durch die Teilnehmereinheit bestimmt, ob der elektronische Münzdatensatz an die zentrale Herausgeberinstanz zurückgegeben wird. Damit kann mit dem Prüfwert ein Kriterium für die Rückgabe eines elektronischen Münzdatensatzes definiert werden. Auf diese Weise können elektronische Münzdatensätze beispielsweise aufgrund ihrer Lebensdauer oder der Anzahl von mit dem Münzdatensatz durchgeführten Aktionen verfallen, um die Sicherheit am Bezahlsystem zu erhöhen.
In einer bevorzugten Ausgestaltung wird der elektronische Münzdatensatz in Folge des Anzeigens von dem Bezahlsystem (dem Überwachungsregister) an die zentrale Herausgeberinstanz zurückgegeben. Durch das Anzeigen beim Bezahlsystem wird also im Bezahlsystem bestimmt, ob der Münzdatensatz zurückzugeben ist. Das Bestimmen, ob eine Rückgabe erfolgen muss, wird in dieser Ausgestaltung im Bezahlsystem anstelle der Teilnehmereinheit durchgeführt. Das Ergebnis des Bestimmens wird der Teilnehmereinheit mitgeteilt und die Teilnehmereinheit wird von dem Bezahlsystem aufgefordert, den elektronischen Münzdatensatz zurückzugeben.
In einer bevorzugten Ausgestaltung fordert das Bezahlsystem (das Überwachungsregister) in Folge des Anzeigens das Modifizieren des elektronischen Münzdatensatzes. Ein Modifizieren, beispielsweise ein Aufteilen, Kombinieren oder Umschalten, bedingt ein Registrieren des elektronischen Münzdatensatzes in dem Bezahlsystem. In vielen Ausgestaltungen des digitalen Währungs-Systems ist eine Rückgabe an die Herausgeberinstanz nicht notwendig und manchmal auch nicht sinnvoll. Dies gilt insbesondere, wenn der Münzdatensatz prompt nach seiner Ausgabe schnell modifiziert wurde. In dieser Ausgestaltung wird der Münzdatensatz nicht zurückgegeben, er gilt aber als zurückgegeben.
In einer bevorzugten Ausgestaltung wird ein Zählerwert im Bezahlsystem (dem Überwachungsregister) betreffend diesen elektronischen Münzdatensatz in Folge des Anzeigens durch das Bezahlsystem unter Verwendung des Prüfwerts des elektronischen Münzdatensatzes bestimmt. Der Prüfwert des Münzdatensatzes wird bevorzugt von der Teilnehmereinheit an das Bezahlsystem (dem Überwachungsregister) übertragen. Der Zählerwert ist dabei kein Bestandteil des Münzdatensatzes. Bevorzugt wird der Zählerwert im Bezahlsystem verwaltet. Bevorzugt wird der Zählerwert mit jeder Aktion (Modifikation, Übertragung, Einlösung) betreffend den elektronischen Münzdatensatz erhöht. Bevorzugt wird für unterschiedliche Aktionen der Zählerwert mit unterschiedlicher Gewichtung erhöht. Dadurch ist es möglich, die Rückgabe entsprechend unterschiedlicher Aktionen verbessert zu steuern. Somit ist im Münzdatensatz der Prüfwert als Datenelement vorgesehen, der insbesondere mit jeder direkten Übertragung zwischen Teilnehmereinheiten inkrementiert wird. Der Zählerwert im Bezahlsystem bezieht den Prüfwert ein, beispielsweise durch Addieren des bisherigen Zählerwerts mit dem Prüfwert.
In einer bevorzugten Ausgestaltung weist jeder elektronische Münzdatensatz einen ersten Prüfwert und einen zweiten Prüfwert auf. Der erste Prüfwert wird dann entsprechend beim direkten Übertragen des elektronischen Münzdatensatzes zwischen zwei Teilnehmereinheiten inkrementiert, wobei anhand des ersten Prüfwertes des elektronischen Münzdatensatzes bestimmt wird, ob der elektronische Münzdatensatz von der Teilnehmereinheit beim Bezahlsystem angezeigt wird. Anhand zumindest des zweiten Prüfwertes des elektronischen Münzdatensatzes wird bestimmt, ob der elektronische Münzdatensatz an die zentrale Herausgeberinstanz zurückgegeben wird. Somit ist ein Anzeige-Prüfwert getrennt von einem Rückgabe-Prüfwert im Münzdatensatz vorgesehen. Bevorzugt ist der zweite Prüfwert invariant bei einer, von Teilnehmereinheiten mit dem elektronischen Münzdatensatz durchgeführten Aktion, wobei bevorzugt der zweite Prüfwert zumindest ein Wert aus der folgenden Liste ist: Rückgabedatum des elektronischen Münzdatensatzes; Ausgabedatum des elektronischen Münzdatensatzes; Registrierungsdatum des elektronischen Münzdatensatzes; und Identifizierungswert des elektronischen Münzdatensatzes. Der aktionsinvariante Prüfwert ist nicht-individuell für den elektronischen Münzdatensatz, sondern gruppenspezifisch und gilt daher für eine Mehrzahl von unterschiedlichen Münzdatensätzen, um eine Anonymität zu bewahren und eine Münzdatensatz-verfolgung zu verhindern. Der zweite aktionsinvariante Prüfwert ist dabei nicht individuell für den elektronischen Münzdatensatz, sondern gilt für eine Mehrzahl von unterschiedlichen Münzdatensätzen (Gruppen-ID), um eine Anonymität zu bewahren und eine Münzdatensatz verfolgung zu verhindern.
In einer vorteilhaften Ausgestaltung ist der zweite Prüfwert variabel und umfasst den ersten Prüfwert, um zu bestimmen, ob der elektronische Münzdatensatz zurückgegeben wird. Dabei könnte eine Summe gebildet werden und diese Summe mit einem vordefinierten Schwellwert verglichen werden. Beispielsweise könnte die Anzahl von Direktübertragungen ein Rückgabekriterium sein, sodass keine Infrastruktur zur Auswertung der Münzdatensätze hinsichtlich der Rückgabe des Münzdatensätze in dem Bezahlsystem vorzuhalten wäre, also eine einfachere und sicherere Verwaltung unter Schaffung der Kontrollfunktionen ermöglicht wäre.
In einer vorteilhaften Ausgestaltung wird das Überschreiten eines Schwellwerts des Prüfwerts des elektronischen Münzdatensatzes durch ein erstes Endgerät festgestellt und eine Aktion mit diesem elektronischen Münzdatensatz, insbesondere das direkte Übertragen dieses elektronischen Münzdatensatzes von dem ersten Endgerät an ein zweites Endgerät, wird nur dann durchgeführt, wenn im ersten Endgerät festgestellt wurde, dass kein anderer elektronischer Münzdatensatz im ersten Endgerät vorhanden ist. Auf diese Weise wird sichergestellt, dass mit dem Münzdatensatz eine Bezahltransaktion zwischen zwei Endgeräten trotz hoher Anzahl von direkten Übertragungen dieses Münzdatensatzes zwischen Endgeräten mangels alternativer Münzdatensätze in dem Endgerät dennoch durchgeführt und abgeschlossen werden kann.
In einer vorteilhaften Ausgestaltung wird das Überschreiten eines Blockier-Schwellwerts des Prüfwerts des elektronischen Münzdatensatzes durch eine erste Teilnehmereinheit festgestellt und eine Aktion mit diesem elektronischen Münzdatensatz, insbesondere das direkte Übertragen dieses elektronischen Münzdatensatzes von der ersten Teilnehmereinheit an eine zweite Teilnehmereinheit, blockiert wird, unabhängig davon, ob in der ersten Teilnehmereinheit ein anderer elektronischer Münzdatensatz vorhanden ist oder nicht. Somit wird ein Schwellwert definiert, bei dessen Erreichen eine direkte Weitergabe (Übertragung) zwischen Teilnehmereinheiten vollständig unterbunden (blockiert) wird. Beispielsweise könnte dieser Münzdatensatz in einen sicheren Speicherbereich abgelegt werden, zudem nur ein Rückgabe- Prozess aber kein Aktionsprozess der Teilnehmereinheit Zugriff hat.
Das drohende Blockieren kann der Teilnehmereinheit vorab erfasst werden und einem Nutzer der Teilnehmereinheit mitgeteilt werden, um das Blockieren des Münzdatensatzes durch sofortiges Rückgeben des Münzdatensatzes zu unterbinden. Zusätzlich oder alternativ kann die Teilnehmereinheit bei Erkennen des Überschreitens des Blockier-Schwellwerts den elektronischen Münzdatensatz zurückgeben.
Bevorzugt ist der Schwellwert des Prüfwerts geringer als der Blockier-Schwellwert des Prüfwerts. Der Blockier-Schwellwert kann ein Vielfaches des Schwellwertes sein, um den Münzdatensatz nicht zu früh zu blockieren. Der Schwellwert liegt beispielsweise bei zehn, oder beispielsweise bei fünf oder beispielsweise bei 3. Der Blockier-Schwellwert liegt entsprechend bei 30, oder beispielsweise bei 15 oder beispielsweise bei 10.
In einer bevorzugten Ausgestaltung fragt die Herausgeberinstanz in vordefinierten periodischen Zeitabständen oder gezielt gesteuert Prüfwerte von Münzdatensätzen ab und fordert einen elektronischen Münzdatensatz automatisch zurück, wenn ein Prüfwert des elektronischen Münzdatensatzes überschritten ist.
In einer bevorzugten Ausgestaltung des Rückgabe-Verfahrens wird durch das Überwachungsregister des Bezahlsystems ein Zählerwert im Überwachungsregister betreffend den elektronischen Münzdatensatz unter Verwendung des Prüfwerts des elektronischen Münzdatensatzes bestimmt. Bei Überschreiten eines Schwellwertes des Zählerwertes, wird der elektronische Münzdatensatz (direkt oder indirekt) an die zentrale Herausgeberinstanz zurückgegeben. Dabei werden im Überwachungsregister bevorzugt ausschließlich maskierte Münzdatensätze verwaltet. Die Herausgeberinstanz oder das Bezahlsystem fordert den entsprechenden Münzdatensatz von der Teilnehmereinheit an oder stellt eine entsprechende Information vom Bezahlsystem an die Teilnehmereinheit zur (direkten) Rückgabe bereit. Der Zählerwert wird bevorzugt mit jeder Aktion am elektronischen Münzdatensatzes erhöht, wobei bevorzugt für unterschiedliche Aktionen der Zählerwert mit unterschiedlicher Gewichtung erhöht wird. Auf die oben genannten Vorteile bei einem derartigen Verfahren wird verwiesen.
In einer bevorzugten Ausgestaltung des Rückgabe-Verfahrens wird bei einer Durchführung einer Aktion mit dem elektronischen Münzdatensatz durch das Überwachungsregister der Prüfwert des elektronischen Münzdatensatzes von dem Bezahlsystem zurückgesetzt. Das vereinfacht das Verfahren, da die Teilnehmereinheit nicht an die Summe aller erlaubten Aktionen angepasst werden muss, sondern nur an die Summe nacheinander erlaubter direkter Übertragungen. In einer bevorzugten Ausgestaltung wird beim Kombinieren (=Verbinden) von elektronischen Münzteildatensätzen zu einem kombinierten elektronischen Münzdatensatz durch das Bezahlsystem der höchste Prüfwert der elektronischen Münzteildatensätze bestimmt und dieser höchste Prüfwert als der Prüfwert des kombinierten elektronischen Münzdatensatzes übernommen wird.
In einer bevorzugten Ausgestaltung wird beim Kombinieren von elektronischen Münzteildatensätzen zu einem kombinierten elektronischen Münzdatensatz durch das Überwachungsregister ein neuer Prüfwert aus der Summe aller Prüfwerte der elektronischen Münzteildatensätzen geteilt durch das Produkt der Anzahl der Münzteildatensätze mit einem konstanten Korrekturwert bestimmt, wobei dieser neue Prüfwert als der Prüfwert des kombinierten elektronischen Münzdatensatzes übernommen wird, wobei der Korrekturwert größer gleich 1 ist und wobei bevorzugt der Korrekturwert von einer maximalen Abweichung der einzelnen Prüfwerte der elektronischen Münzteildatensätze oder von einem maximalen Prüfwert einer der elektronischen Münzteildatensätze abhängt, wobei weiter bevorzugt der Korrekturwert kleiner gleich 2 ist. Der Korrekturwert ist bezahl System weit konstant.
In einer bevorzugten Ausgestaltung erfolgt das Zurückgeben des elektronischen Münzdatensatzes von dem Überwachungsregister an die Herausgeberinstanz, wenn das Endgerät das Einlösen eines geldwerten Betrag des elektronischen Münzdatensatzes auf ein Konto des Bezahlsystems veranlasst und/oder wenn die Teilnehmereinheit einen Wechsel des geldwerten Betrags des elektronischen Münzdatensatzes in ein anderes Währungssystem des Bezahlsystems anfordert.
Ein elektronischer Münzdatensatz kann in einer Teilnehmereinheit aufgeteilt werden und dieses Aufteilen wird anschließend in dem Münzregister registriert. Das hat den Vorteil, dass ein Besitzer des zumindest einen elektronischen Münzdatensatzes nicht gezwungen ist, stets den gesamten monetären Betrag auf einmal zu übertragen, sondern nunmehr entsprechende monetäre Teilbeträge zu bilden und zu übertragen. Der Geldwert kann ohne Einschränkungen symmetrisch oder asymmetrisch aufgeteilt werden, solange alle elektronische Münzdatenteilsätze einen positiven monetären Betrag aufweisen, der kleiner ist als der monetäre Betrag des elektronische Münzdatensatzes, von dem aus aufgeteilt wird und die Summe der elektronischen Münzteildatensätze gleich dem aufzuteilenden elektronischen Münzteildatensatzes ist. Alternativ oder zusätzlich können feste Denominationen genutzt werden. Die Aufteilung in Teilbeträge ist beliebig. Das Aufteilen löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der maskierte aufgeteilte elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein. Das Verfahren weist bevorzugt die weiteren folgenden Schritte auf: Umschalten des übertragenen elektronischen Münzteildatensatzes; und/oder Verbinden des übertragenen elektronischen Münzdatensatzes mit einem zweiten elektronischen Münzdatensatz zu einem (neuen) verbundenen elektronischen Münzdatensatz.
Beim Umschalten ergibt der von der ersten Teilnehmereinheit erhaltene elektronische Münzteildatensatz einen neuen elektronischen Münzdatensatz, bevorzugt mit gleichem monetärem Betrag, dem sogenannten umzuschaltenden elektronischen Münzdatensatz. Der neue elektronische Münzdatensatz wird von der zweiten Teilnehmereinheit generiert, vorzugsweise indem der monetäre Betrag des erhaltenen elektronischen Münzdatensatzes als monetärer Betrag des umzuschaltenden elektronischen Münzdatensatzes verwendet wird. Dabei wird ein neuer Verschleierungsbetrag, beispielsweise eine Zufallszahl, generiert. Der neue Verschleierungsbetrag wird beispielsweise zum Verschleierungsbetrag des erhaltenen elektronischen Münzdatensatzes addiert, damit die Summe beider Verschleierungsbeträge (neu und erhalten) als Verschleierungsbetrag des umzuschaltenden elektronischen Münzdatensatzes dient. Nach dem Umschalten wird bevorzugt der erhaltene elektronische Münzteildatensatz und der umzuschaltende elektronische Münzteildatensatz in der Teilnehmereinheit durch Anwenden der homomorphen Einwegfunktion auf jeweils den erhaltenen elektronischen Münzteildatensatz und den umzuschaltenden elektronischen Münzteildatensatz maskiert, um entsprechend einen maskierten erhaltenen elektronischen Münzteildatensatz und einen maskierten umzuschaltenden elektronischen Münzteildatensatz zu erhalten. Das Umschalten löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der maskierte umzuschaltende elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
Das Umschalten wird also durch Hinzufügen eines neuen Verschleierungsbetrags zum Verschleierungsbetrag des erhaltenen elektronischen Münzdatensatz abgesichert, wodurch ein Verschleierungsbetrag erhalten wird, den nur die zweite Teilnehmereinheit kennt. Neu geschaffene Verschleierungsbeträge müssen eine hohe Entropie aufweisen, da sie als Blendungsfaktor für die entsprechenden maskierten elektronischen Münzteildatensätze verwendet werden. Bevorzugt wird dazu ein Zufallszahlengenerator auf dem Sicherheitselement verwendet. Diese Absicherung kann in dem Münzregister nachverfolgt werden.
Im Rahmen des Umschaltens werden bevorzugt zusätzliche Informationen, die zum Registrieren des Umschaltens des maskierten elektronischen Münzdatensatzes in dem Münzregister benötigt werden, in der Teilnehmereinheit berechnet. Bevorzugt beinhalten die zusätzlichen Informationen einen Bereichsnachweis über den maskierten umzuschaltenden elektronischen Münzdatensatz und einen Bereichsnachweis über den maskierten erhaltenen elektronischen Münzdatensatz. Bei dem Bereichsnachweis handelt es sich um einen Nachweis, dass der monetäre Betrag des elektronischen Münzdatensatzes nicht negativ ist, der elektronische Münzdatensatz gültig erstellt und/ oder der monetäre Betrag und der Verschleierungsbetrag des elektronischen Münzdatensatzes dem Ersteller des Bereichsnachweises bekannt sind. Insbesondere dient der Bereichsnachweis dazu, diese(n) Nachweis(e) zu führen ohne den monetären Betrag und/oder den Verschleierungsbetrag des maskierten elektronischen Münzdatensatzes zu offenbaren. Diese Bereichsnachweise werden auch „Zero-Knowledge-Range-Proofs“ genannt. Bevorzugt werden als Bereichsnachweis Ringsignaturen verwendet. Anschließend erfolgt ein Registrieren des Umschaltens des maskierten elektronischen Münzdatensatzes in dem entfernten Münzregister. Das Registrieren löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der maskierte umzuschaltende elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
Der Schritt des Registrierens wird vorzugsweise dann ausgeführt, wenn die zweite Teilnehmereinheit mit dem Münzregister verbunden ist. Während die elektronischen Münzdatensätze für direktes Bezahlen zwischen zwei Teilnehmereinheiten verwendet werden, können die maskierten Münzdatensätze mit einem Pseudonym in dem Münzregister registriert werden. Das Registrieren löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der pseudonymisierte maskierte umzuschaltende elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
In einer weiter bevorzugten Ausgestaltung des Verfahrens wird für ein Verbinden von elektronischen Münzteildatensätzen ein weiterer elektronischer Münzdatensatz (verbundener elektronischer Münzdatensatz) aus einem ersten und einem zweiten elektronischen Münzteildatensatz bestimmt. Dabei wird der Verschleierungsbetrag für den zu verbindenden elektronischen Münzdatensatz durch Bilden der Summe aus den jeweiligen Verschleierungsbeträgen des ersten und des zweiten elektronischen Münzdatensatzes berechnet. Weiterhin wird vorzugsweise der monetäre Betrag für den verbundenen elektronischen Münzdatensatz durch Bilden der Summe aus den jeweiligen monetären Beträgen des ersten und des zweiten elektronischen Münzdatensatzes berechnet.
Nach dem Verbinden wird der erste elektronische Münzteildatensatz, der zweite elektronische Münzteildatensatz, sowie der zu verbindende elektronische Münzdatensatz in der (ersten und/ oder zweiten) Teilnehmereinheit durch Anwenden der homomorphen Einwegfunktion auf jeweils den ersten elektronischen Münzteildatensatz, den zweiten elektronischen Münzteildatensatz, sowie den zu verbindenden elektronischen Münzdatensatz maskiert, um entsprechend einen maskierten ersten elektronischen Münzteildatensatz, einen maskierten zweiten elektronischen Münzteildatensatz, sowie einen maskierten zu verbindenden elektronischen Münzdatensatz zu erhalten. Des Weiteren werden zusätzliche Informationen, die zum Registrieren des Verbindens der maskierten elektronischen Münzdatensätze in dem entfernten Münzregister benötigt werden, in der Teilnehmereinheit berechnet. Bevorzugt beinhalten die zusätzlichen Informationen einen Bereichsnachweis über den maskierten ersten elektronischen Münzteildatensatz und einen Bereichsnachweis über den maskierten zweiten elektronischen Münzteildatensatz. Bei dem Bereichsnachweis handelt es sich um einen Nachweis, dass der monetäre Betrag des elektronischen Münzdatensatzes nicht negativ ist, der elektronische Münzdatensatz gültig erstellt und/ oder der monetäre Betrag und der Verschleierungsbetrag des elektronischen Münzdatensatzes dem Ersteller des Bereichsnachweises bekannt sind. Insbesondere dient der Bereichsnachweis dazu, diese(n) Nachweis zu führen ohne den monetären Wert und/oder den Verschleierungsbetrag des maskierten elektronischen Münzdatensatzes zu offenbaren. Diese Bereichsnachweise werden auch „Zero-Knowledge-Range-Proofs“ genannt. Bevorzugt werden als Bereichsnachweis Ringsignaturen verwendet. Anschließend erfolgt ein Registrieren des Verbindens der beiden maskierten elektronischen Münzteildatensätze in dem entfernten Münzregister. Das Registrieren löst beispielsweise das Ausführen des oben beschriebenen Verfahrens zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus und der maskierte verbundene elektronische Münzteildatensatz kann Teil eines Transaktionsdatensatzes für das Transaktionsregister sein.
Mit dem Schritt des Verbindens können zwei elektronische Münzdatensätze bzw. zwei elektronische Münzteildatensätze zusammengefasst werden. Dabei werden die monetären Beträge sowie auch die Verschleierungsbeträge addiert. Wie beim Aufteilen kann somit auch beim Verbinden eine Validität der beiden ursprünglichen Münzdatensätze durchgeführt werden.
In einer bevorzugten Ausgestaltung umfasst der Registrieren- Schritt das Empfangen des maskierten umzuschaltenden elektronischen Münzteildatensatzes in dem Münzregister, das Prüfen des maskierten umzuschaltenden elektronischen Münzteildatensatzes auf Validität; und das Registrieren des maskierten umzuschaltenden elektronischen Münzdatensatzes in dem Münzregister, wenn der Prüfen-Schritt erfolgreich ist, wodurch der umzuschaltende elektronische Münzteildatensatz als überprüft gilt.
Somit ergibt sich beispielsweise ein zumindest dreischichtiges Bezahlsystem. In einer ersten Schicht (Direkttransaktionsschicht) werden elektronische Münzdatensätze zwischen einzelnen Teilnehmereinheiten bzw. deren Sicherheitselementen direkt übertragen. In einer zweiten Schicht (Prüfschicht) werden maskierte elektronische Münzdatensätze in einem Münzregister und einem Überwachungsregister registriert und geprüft. In der zweiten Schicht werden bevorzugt keine Bezahltransaktionen festgehalten, sondern ausschließlich maskierte elektronische Münzdatensätze, deren Status, ggf. Prüfwerte, Signaturen und Modifikationen zum Zweck der Verifizierung der Gültigkeit von (nicht maskierten) elektronischen Münzdatensätzen. So wird die Anonymität der Teilnehmer des Bezahlsystems gewährleistet. Die zweite Schicht gibt Auskunft über gültige und ungültige elektronische Münzdatensätze, um beispielsweise eine Mehrfach- Ausgabe des gleichen elektronischen Münzdatensatzes zu vermeiden oder die Echtheit des elektronischen Münzdatensatzes als gültig herausgegebenes elektronisches Geld zu verifizieren oder die Summe monetärer Beträge pro Sicherheitselement zu erfassen, um diese Summe mit einem Grenzwert zu vergleichen und eine Modifikation entsprechend zu unterbinden oder zu gestatten. Die zweite Schicht kann anhand eines Zählerwerts eines elektronischen Münzdatensatzes bestimmen, ob der elektronische Münzdatensatz verfallen ist und zurückzugeben ist, oder entsprechend zu modifizieren ist, sodass er als zurückgegeben gilt. In einer dritten Schicht (Archivierungsschicht) werden verschlüsselte Transaktionsdatensätze in einem Transaktionsregister abgelegt und auf behördliche Anfrage wie oben dargestellt entschlüsselt um geprüft zu werden.
Darüber hinaus umfasst das Bezahlsystem beispielsweise auch eine Herausgeberinstanz, die elektronische Münzdatensätze generiert (Erstellen) und wieder einfordert (Löschen). Bei der Herausgabe eines elektronischen Münzdatensatzes von der Herausgeberinstanz an eine Teilnehmereinheit kann parallel ein maskierter elektronischer Münzdatensatz von der Herausgeberinstanz an das Münzregister und/oder das Überwachungsregister des Bezahlsystems zur Registrierung des elektronischen Münzdatensatzes mit ausgegeben werden.
Eine Teilnehmereinheit kann vorliegend ein Sicherheitselement aufweisen oder selbst ein Sicherheitselement sein, in dem der elektronische Münzdatensatz sicher abgelegt ist. Auf der Teilnehmereinheit kann eine Applikation betriebsbereit eingebracht sein, die Teile des Übertragen-Verfahrens steuert oder zumindest initiiert.
Die Übertragung von elektronischen Münzdatensätzen kann jeweils unter Zuhilfenahme von Endgeräten als Teilnehmereinheit erfolgen, die mit den Sicherheitselementen logisch und/oder physisch verbunden sind.
Die Kommunikation zwischen zwei Teilnehmereinheiten, ggf. mit den jeweiligen Sicherheitselementen, 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.
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 etabli erter B lockchain-T echnol ogi e .
In einer bevorzugten Ausgestaltung erfolgt das Übertragen der Münzdatensätze als APDU Kommandos. Dazu ist der Münzdatensatz bevorzugt in einer (embedded) 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.
Darüber hinaus ist es vom Vorteil, dass die elektronischen Münzdatensätze in beliebiger Formatierung übertragen werden können. 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.
Als eine Teilnehmereinheit wird insbesondere ein mobiles Telekommunikationsendgerät, beispielsweise ein Smartphone angesehen. 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. 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.
Beispielsweise stellen zwei Teilnehmereinheiten eine lokale drahtlos Kommunikationsverbindung über deren Protokoll dann die Übertragung zwischen den beiden darin befindlichen Sicherheitselementen eingebracht ist.
In einer Ausgestaltung kann vorgesehen sein, dass das erste und/ oder zweite Sicherheitselement die empfangenen elektronischen Münzdatensätze bei Vorliegen oder Empfang mehrerer elektronischer Münzdatensätze diese entsprechend ihrer monetären Wertigkeit abarbeitet. So kann vorgesehen sein, dass elektronische Münzdatensätze mit höherer monetärer Wertigkeit vor elektronische Münzdatensätze mit niedriger monetärer Wertigkeit verarbeitet. In einer Ausgestaltung kann die Teilnehmereinheit ausgebildet sein, nach Empfang eines elektronischen Münzdatensatzes diesen in Abhängigkeit von beigefügter Information, beispielsweise einer Währung oder Denomination, mit bereits in der Teilnehmereinheit vorhandenem elektronischen Münzdatensatz zu verbinden und entsprechend einen Schritt des Verbindens auszuführen. Weiterhin kann die Teilnehmereinheit auch zum automatisierten Ausführen eines Umschaltens nach Empfang des elektronischen Münzdatensatzes ausgebildet sein.
In einer Ausgestaltung werden beim Übertragen weitere Informationen, insbesondere Metadaten, von der ersten Teilnehmereinheit bzw. ersten Sicherheitselement auf die zweite Teilnehmereinheit bzw. zweite Sicherheitselement übermittelt, beispielsweise eine Währung. Diese Information kann in einer Ausgestaltung vom elektronischen Münzdatensatz umfasst sein.
Die Verfahren sind 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.
Die Verfahren ermöglichen 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.
Bevorzugt wird der zumindest eine initiale elektronische Münzdatensatz ausschließlich 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 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, im 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 kann die Herausgeberinstanz einen elektronischen Münzdatensatz, der sich in ihrem Besitz befindet (also von dem sie den monetären Betrag und den Verschleierungsbetrag kennt) deaktivieren, indem sie den maskierten zu deaktivierenden elektronischen Münzdatensatz mit der homomorphen Einwegfunktion maskiert und einen Deaktivieren-Befehl für das Münzregister vorbereitet. Ein Teil des Deaktivieren-Befehls ist bevorzugt neben dem maskierten zu deaktivierenden elektronischen Münzdatensatzes auch der Nachweis, dass der Deaktivieren Schritt von der Herausgeberinstanz initiiert wurde, beispielsweise in Form des signierten maskierten zu deaktivierenden elektronischen Münzdatensatzes. Als zusätzliche Information könnten im Deaktivieren-Befehl Bereichsprüfungen für den maskierten zu deaktivierenden elektronischen Münzdatensatz enthalten sein. Das Deaktivieren kann die Folge eines Zurückgebens sein. Anschließend erfolgt ein Registrieren des Deaktivierens des maskierten elektronischen Münzdatensatzes in dem entfernten Münzregister. Mit dem Deaktivieren-Befehl wird der Schritt des Deaktivierens ausgelöst.
Die Schritte Erstellen und Deaktivieren erfolgen bevorzugt an gesicherten Orten, insbesondere nicht in den Teilnehmereinheiten. In einer bevorzugten Ausgestaltung werden die Schritte des Erstellens und Deaktivierens nur von der Herausgeberinstanz durchgeführt bzw. angestoßen. Vorzugsweise finden diese Schritte an einen gesicherten Ort statt, beispielsweise in einer Hard- und Software- Architektur, die zur Verarbeitung von sensiblem Datenmaterial in unsicheren Netzen entwickelt wurde. Das Deaktivieren des entsprechenden maskierten elektronischen Münzdatensatz bewirkt, dass der entsprechende maskierte elektronische Münzdatensatz nicht mehr für weitere Verarbeitung, insbesondere Transaktionen, verfügbar ist. Jedoch kann in einer Ausführungsform vorgesehen sein, dass der deaktivierte maskierte elektronische Münzdatensatz bei der Herausgeberinstanz archivarisch bestehen bleibt. Dass der deaktivierte maskierte elektronische Münzdatensatz nicht mehr gültig bzw. zurückgegeben wird, kann beispielsweise mithilfe eines Flags oder einer anderen Codierung gekennzeichnet oder der deaktivierte maskierte elektronische Münzdatensatz kann zerstört und/ oder gelöscht werden. Der deaktivierte elektronische Münzdatensatz wird auch physisch von der Teilnehmereinheit bzw. dem Sicherheitselement entfernt. Durch das erfindungsgemäße Verfahren werden verschiedene Verarbeitungsoperationen (Modifikationen) für die elektronischen Münzdatensätze und die entsprechenden maskierten elektronischen Münzdatensätze ermöglicht. Jeder der Verarbeitungsoperationen (insbesondere das Erstellen, Deaktivieren, Aufteilen, Verbinden und Umschalten) wird dabei in dem Münzregister registriert und dort in unveränderlicher Form an die Liste der vorherigen Verarbeitungsoperationen für den jeweiligen maskierten elektronischen Münzdatensatz angehängt. Jede der Verarbeitungsoperationen löst beispielsweise das Verfahren zum Erzeugen und Verschlüsseln eines Transaktionsdatensatzes aus. Die Registrierung ist dabei vom Bezahlvorgang zwischen den Teilnehmereinheiten sowohl zeitlich als auch örtlich (räumlich) unabhängig. Die Verarbeitungsoperationen „Erstellen“ und „Deaktivieren“ (=Zurückgeben), die die Existenz des monetären Betrags an sich betreffen, also die Schaffung und die Vernichtung bis hin der Zerstörung von Geld bedeuten, bedürfen einer zusätzlichen Genehmigung, beispielsweise in Form einer Signatur, durch die Herausgeberinstanz, um in dem Münzregister registriert (also protokolliert) zu werden. Die übrigen Verarbeitungsoperationen (Aufteilen, Verbinden, Umschalten), von denen das Aufteilen und das Verbinden auch von einer Teilnehmereinheit auch an eine weitere Teilnehmereinheit delegiert werden können, bedürfen keiner Autorisierung durch die Herausgeberinstanz oder durch den Befehlsinitiator (= Zahler, bspw. Teilnehmereinheit oder Sicherheitselement).
Eine Verarbeitung in der Direkttransaktionsschicht betrifft nur die Besitzverhältnisse und/ oder die Zuordnung der Münzdatensätze zu Teilnehmereinheiten der jeweiligen elektronischen Münzdatensätze. Eine Registrierung der jeweiligen Verarbeitung in dem Münzregister bzw. dem Überwachungsregister wird beispielsweise durch entsprechende Listeneinträge in einer Datenbank realisiert, die eine Reihe von Markierungen umfasst, die von dem Münzregister durchgeführt werden müssen. Eine mögliche Struktur für einen Listeneintrag umfasst beispielsweise Spalte(n) für einen Vorgänger-Münzdatensatz, Spalte(n) für einen Nachfolger-Münzdatensatz, eine Signatur-Spalte für die Herausgeberinstanz, eine Signatur-Spalte für das sendende und/oder empfangende Sicherheitselement, eine Signatur-Spalte für Münzteilungsvorgänge und zumindest eine Markierungsspalte. Eine Änderung (Modifikation) ist endgültig, wenn und die erforderlichen Markierungen durch das Münzregister oder das Überwachungsregister validiert wurden, d.h. nach der entsprechenden Prüfung beispielsweise vom Status "0" in den Status "1" gewechselt wurden. Scheitert eine Prüfung oder dauert zu lang, so wird sie stattdessen beispielsweise vom Status in den Status "0" gewechselt. Weitere Statuswerte sind denkbar und/oder die hier genannten Statuswerte sind austauschbar. Die Status bezüglich der Modifikationen sind unabhängig vom Status während des Übertragenvorgangs (Inaktiv/ Aktiv). Bevorzugt wird die Gültigkeit der jeweiligen (maskierten) elektronischen Münzdatensätze aus den Statuswerten der Markierungen zusammengefasst jeweils in einer Spalte für jeden maskierten elektronischen Münzdatensatz, der im Registrieren der Verarbeitung involviert ist, dargestellt. In einem weiteren Ausführungsbeispiel können wenigstens zwei vorzugsweise drei oder sogar alle der vorhergenannten Markierungen auch durch eine einzige Markierung ersetzt werden, die dann gesetzt wird, wenn alle Prüfungen erfolgreich abgeschlossen wurden. Des Weiteren lassen sich die je zwei Spalten für Vorgänger-Datensätze und Nachfolger-Datensätze zu jeweils einem zusammenfassen, in welchem alle Münzdatensätze gemeinsam ausgelistet sind. Dadurch könnten dann auch mehr als zwei elektronische Münzdatensätze je Feldeintrag verwaltet werden, und somit z.B. eine Aufspaltung in mehr als zwei Münzdatensätze realisiert werden.
Die Prüfungen durch das Überwachungsregister, um zu prüfen, ob eine Verarbeitung endgültig ist sind bereits oben beschrieben und sind insbesondere:
Sind die maskierten elektronischen Münzdatensätze der Vorgänger-Spalte(n) gültig?
- Ergibt eine Überwachung den korrekten Prüfwert?
Sind die Bereichsnachweise für die maskierten elektronischen Münzdatensätze erfolgreich?
Ist die Signatur des maskierten elektronischen Münzdatensatzes eine gültige Signatur der Herausgeberinstanz?
- Überschreitet die sendende/empfangende Teilnehmereinheit (Pseudonym) einen Grenzwert für einen maximal zulässigen monetären Betrag, insbesondere pro Zeiteinheit? Ist der Münzdatensatz Inaktiv aufgrund Übertragen zwischen Teilnehmereinheiten?
Bevorzugt gilt zudem, dass ein maskierter elektronischer Münzdatensatz ungültig ist, wenn einer der folgenden Prüfungen zutrifft, also wenn:
(1) der maskierte elektronische Münzdatensatz nicht in dem Münzregister registriert ist;
(2) die letzte Verarbeitung des maskierten elektronischen Münzdatensatzes angibt, dass es für ihn Vorgänger-Münzdatensätze gibt, diese letzte Verarbeitung aber nicht endgültig ist; oder
(3) die letzte Verarbeitung des maskierten elektronischen Münzdatensatzes angibt, dass es für ihn Nachfolger-Münzdatensätze gibt und diese letzte Verarbeitung endgültig ist;
(4) der maskierte elektronische Münzdatensatz nicht der Nachfolger von einem gültigen maskierten elektronischen Datensatz ist, es sei denn er ist von der Herausgeberinstanz signiert;
(5) der monetäre Betrag des maskierten elektronischen Münzdatensatzes dazu führt, dass ein Grenzwert für einen maximal zulässigen monetären Betrag, insbesondere pro Zeiteinheit, überschritten wird und die geforderte Deanonymisierung von der entsprechenden Teilnehmereinheit abgelehnt wird;
(6) Ein Aktiv-Status für ein Sicherheitselement im Münzregister eingetragen ist, aber eine andere Teilnehmereinheit eine Aktion (Umschalten, Kombinieren, Aufteilen) unter Besitzanzeige anfragt.
Bevorzugt ist das Bezahlsystem zum Durchführen des oben genannten Verfahrens und/ oder wenigstens einer der Ausführungsvarianten ausgebildet. Ein weiterer Aspekt betrifft ein Währungssystem umfassend eine Herausgeberinstanz, eine Münzregister Schicht, ein erstes Sicherheitselement und ein zweites Sicherheitselement, wobei die Herausgeberinstanz ausgebildet ist, einen elektronischen Münzdatensatzes zu erstellen. Der maskierte elektronische Münzdatensatz ist ausgebildet, nachweisbar durch die Herausgeberinstanz erstellt zu sein. Die Prüfschicht ist zum Ausführen eines Registrier schritts wie in dem oben genannten Verfahren ausgeführt, ausgebildet. Vorzugsweise sind die Sicherheitselemente, d.h. wenigstens das erste und zweite Sicherheitselement zum Ausführen eines der oben genannten Verfahren (i) zum Übertragen und (ii) zum Erzeugen + Verschlüsseln + Initiieren geeignet.
In einer bevorzugten Ausführung des Währungssystems ist lediglich die Herausgeberinstanz berechtigt, einen elektronischen Münzdatensatz initial zu erstellen und final zurückzunehmen. Eine Verarbeitung, beispielsweise der Schritt des Verbindens, des Aufteilens und/ oder des Umschaltens, kann und wird vorzugsweise durch eine Teilnehmereinheit durchgeführt. Der Verarbeitungsschritt des Deaktivierens kann vorzugsweise nur von der Herausgeberinstanz ausgeführt werden.
Bevorzugt sind das Münzregister, das Überwachungsregister und die Herausgeberinstanz in einer gemeinsamen Serverinstanz angeordnet oder liegen als Computerprogrammprodukt auf einem Server und/ oder einem Computer vor.
Bevorzugt ist das Transaktionsregister in einer von der gemeinsamen Serverinstanz verschiedenen Serverinstanz angeordnet oder liegt dort als Computerprogrammprodukt vor.
Ein elektronischer Münzdatensatz kann dabei in einer Vielzahl von unterschiedlichen Erscheinungsformen vorliegen und damit über verschiedene Kommunikationskanäle, nachfolgend auch Schnittstellen genannt, 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 des Sicherheitselements und/oder des Endgeräts interpretieren 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 die 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 die 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 empfangen 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 bzw. Endgeräten unterschiedlicher technischer Ausrüstung unter Verwendung unterschiedlicher Übertragungsmedien (Luft, Papier, drahtgebunden) und unter Berücksichtigung der technischen Ausgestaltung einer Teilnehmereinheit. 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 einem einfachen Fall ist der Datenspeicher ein interner Datenspeicher der Teilnehmereinheit. Hier werden die elektronischen Münzdatensätze abgelegt. Ein einfacher Zugriff auf elektronische Münzdatensätze ist somit gewährleistet.
Der Datenspeicher ist insbesondere ein 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.
Ist das Münzregister eine entfernte Instanz, so verfügt die Teilnehmereinheit bevorzugt über eine Schnittstelle zur Kommunikation mittels einem üblichen Internet-Kommunikationsprotokoll, beispielsweise TCP, IP, UDP oder HTTP. Die Übertragung kann eine Kommunikation über das Mobilfunknetz beinhalten. In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Ausgeben (=Senden) des zumindest einen elektronischen Münzdatensatzes 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 WL AN- Verbindungen oder Mobilfunkverbindungen denkbar. Der elektronische Münzdatensatz wird dann gemäß den Protokolleigenschaften angepasst oder in das Protokoll integriert und übertragen.
In einer bevorzugten Ausgestaltung ist die Schnittstelle zum Ausgeben des zumindest einen elektronischen Münzdatensatzes 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 spezifisches Dateiformat verwendet werden. In einfachster Form wird der Münzdatensatz als ASCII- Zeichenfolge oder als Textnachricht, beispielsweise SMS, MMS, Instant-Messenger-Nachricht (wie Threema oder WhatsApp) übertragen. In einer alternativen Form wird der Münzdatensatz als APDU-Zeichenfolge übertragen. Es kann auch eine Geldbörsen-Applikation vorgesehen sein. Hierbei stellen die austauschenden Teilnehmereinheiten bevorzugt sicher, dass ein Austausch mittels der Applikation möglich ist, also dass beide Teilnehmereinheiten die Applikation aufweisen und austauschbereit sind.
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 ist die Schnittstelle zum Empfangen des zumindest einen elektronischen Münzdatensatzes eine Datenschnittstelle zum Empfangen des elektronischen Münzdatensatzes von der anderen Teilnehmereinheit mittels einer Applikation. Diese Applikation empfängt sodann den Münzdatensatz in einem entsprechenden Dateiformat. Es kann ein für Münzdatensätze spezifisches Dateiformat verwendet werden. In einfachster Form wird der Münzdatensatz als ASCII-Zeichenfolge oder als Textnachricht, beispielsweise SMS, MMS, Threema oder WhatsApp übertragen. In einer alternativen Form wird der Münzdatensatz als APDU-Zeichenfolge übertragen. Zusätzlich kann die Übertragung mittels einer Geldbörsen- Applikation erfolgen.
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.
In einer bevorzugten Ausgestaltung 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.
Vorgeschlagen wird hierbei also eine Lösung, die digitales Geld in Form von elektronischen Münzdatensätzen herausgibt, die an die Verwendung von konventionellen (analogen) Banknoten und/oder Münzen angelehnt ist. Das digitale Geld wird hierbei durch elektronische Münzdatensätze abgebildet. Wie bei (analogen) Banknoten werden auch diese elektronischen Münzdatensätze für alle Formen von Zahlungen, einschließlich Peer-to-Peer-Zahlungen und/oder POS-Zahlungen, verwendbar. Die Kenntnis aller Bestandteile (insbesondere monetärer Betrag und Verschleierungsbetrag) eines gültigen elektronischen Münzdatensatzes ist gleichbedeutend mit dem Besitz (Eigentum) des digitalen Geldes. Es ist daher ratsam, diese gültigen elektronischen Münzdatensätze vertraulich zu behandeln, also beispielsweise in einem Sicherheitselement/ Tresormodul (eines Endgeräts) aufzubewahren und dort zu verarbeiten. Um über die Authentizität eines elektronischen Münzdatensatzes zu entscheiden und Doppelausgaben zu verhindern, werden in dem Münzregister maskierte elektronische Münzdatensätze als einzigartige, korrespondierende öffentliche Darstellung des elektronischen Münzdatensatzes vorgehalten. Die Kenntnis oder der Besitz eines maskierten elektronischen Münzdatensatzes stellt nicht den Besitz von Geld dar. Vielmehr gleicht dies dem Überprüfen der Echtheit des analogen Zahlungsmittels.
Das Münzregister enthält beispielsweise auch Markierungen über durchgeführte und geplante Verarbeitungen des maskierten elektronischen Münzdatensatzes. Aus den Markierungen zu den Verarbeitungen wird ein Status des jeweiligen maskierten elektronischen Münzdatensatzes abgeleitet, der angibt, ob der entsprechende (nicht maskierte) elektronische Münzdatensatz gültig, d.h. zahlungsbereit ist. Daher wird ein Empfänger eines elektronischen Münzdatensatzes zunächst einen maskierten elektronischen Münzdatensatz erzeugen und sich durch das Münzregister die Gültigkeit der maskierten elektronischen Münzdatensatz authentifizieren lassen. Ein großer Vorteil dieser erfindungsgemäßen Lösung ist, dass das digitale Geld auf Endgeräte, Händler, Banken und andere Nutzer des Systems verteilt wird, aber kein digitales Geld oder weitere Metadaten bei dem Münzregister oder dem Überwachungsregister - also gemeinsamer Instanzen - gespeichert wird.
Die vorgeschlagene Lösung kann in bestehende Zahlsysteme und Infrastrukturen eingebunden werden. Insbesondere können eine Kombination aus analogen Zahlungsvorgängen mit Geldscheinen und Münzen und digitale Zahlungsvorgänge gemäß der vorliegenden Lösung vorliegen. So kann ein Bezahlvorgang mit Banknoten und/ oder Münzen erfolgen, das Wechselgeld bzw. Rückgeld liegt aber als elektronischer Münzdatensatz vor. Zur Transaktion können beispielsweise ATMs mit entsprechender Konfiguration, insbesondere mit geeigneter Kommunikationsschnittstelle, und/ oder mobile Endgeräte vorgesehen sein. Weiterhin ist ein Umtausch von elektronischem Münzdatensatz in Banknoten bzw. Münzen denkbar.
Die vorliegend aufgeführten Schritte des Erstellens, Umschaltens, Aufteilens, Verbinden und Deaktivierens (Zurückgebens) werden jeweils durch einen entsprechenden Erstell-, Umschalt-, Aufteil-, Verbinden- bzw. Deaktivier-Befehl (Rückgabe-Befehle) ausgelöst.
KURZE 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.la,b ein Ausführungsbeispiel eines Bezahlsystems gemäß dem Stand der Technik;
Fig.2 ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung;
Fig.3 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens in einer Teilnehmereinheit; Fig.4 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens in einem Transaktionsregister;
Fig.5 ein Ausführungsbeispiel einer Verschlüsselung und Entschlüsselung eines Transaktionsdatensatzes;
Fig. 6 eine Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der Fig. 2;
Fig. 7 eine alternative Weiterbildung des Ausführungsbeispiels eines Bezahlsystems der
Fig. 2;
Fig.8 ein Ausführungsbeispiel eines Münzregisters und Überwachungsregisters;
Fig. 9 ein Ausführungsbeispiel eines Systems gemäß der Erfindung zum Aufteilen und Umschalten und Direkt-Übertragen von elektronischen Münzdatensätzen;
Fig. 10 ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung zum Verbinden von elektronischen Münzdatensätzen;
Fig.11 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechenden Verarbeitungsschritte eines
Münzdatensatzes;
Fig.12 ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens und entsprechenden Verarbeitungsschritte eines
Münzdatensatzes;
Fig. 13 ein Ausführungsbeispiel eines erfindungsgemäßen Sicherheitselements;
Fig. 14ein Bezahlsystem gemäß der Erfindung;
Fig. 15 ein Ausführungsbeispiel eines Ablaufs von erfindungsgemäßen Bezahl Vorgängen unter Überwachung der monetären Beträge pro Teilnehmereinheit; und
Fig. 16 ein Ausführungsbeispiel eines Ablaufs einer erfindungsgemäßen Bereichsbestätigung. FIGURENBESCHREIBUNG
Die Fig. la und Fig. lb zeigen ein Ausführungsbeispiel eines Bezahlsystems gemäß dem Stand der Technik. Diese Fig.la und Fig.lb sind in der Beschreibungseinleitung bereits beschrieben. Wiederholend wird darauf hingewiesen, dass ein Endgerät M8 den Münzdatensatz Cc als den Münzdatensatz Ce an dem Münzregister 2 registrieren lassen möchte und das Münzregister 2 feststellt, dass der Münzdatensatz Cb bereits ungültig ist. In der Folge akzeptiert das Münzregister 2 weder den vermeintlich gültigen Münzdatensatz Cc noch den umzuschaltenden Münzdatensatz Ce.
Das Problem kann auftreten, wenn beispielsweise ein Angreifer mit Endgerät Ml einen Münzdatensatz Cb (unerlaubt) an zwei Endgeräte M2 und M3 direkt weitergibt. Sobald einer der zwei Teilnehmer mit Endgerät M2 den Münzdatensatz in dem Münzregister 2 auf sich registrieren lässt (sogenanntes Ummünzen), wird der Münzdatensatz Cb ungültig. Ein argloser Teilnehmer mit Endgerät M3 gibt stattdessen den Münzdatensatz Cb direkt an Endgerät M5 weiter, ohne ihn registrieren zu lassen. Erst das Endgerät M7 durchbricht die direkte Übertragungskette und zeigt den Münzdatensatz Cb beim Münzregister 2. Parallel dazu teilt der Teilnehmer mit Endgerät M2 den Münzdatensatz Cb in den Münzdatensatz Cc und Cx auf und gibt Cc direkt an Endgerät M4 weiter. Endgerät M4 gibt den Münzdatensatz Cc direkt an Endgerät M6 weiter. Endgerät M6 gibt den Münzdatensatz Cc direkt an Endgerät M8 weiter. Erst das Registrieren von Münzdatensatz Cc bei dem Münzregister 2 lässt die Ungültigkeit vom Münzdatensatz Cb und in der Folge das Double- Spending erkennen. Ein Angriff (doppeltes Ausgeben eines elektronischen Münzdatensatz) von Ml wird im Stand der Technik also erst spät entdeckt und es wurden eine Vielzahl von Direktübertragungen in unerlaubter Weise ausgeführt. 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 wurden.
In einem Bezahlsystem soll daher bei Übersteigen einer gewissen Lebensdauer oder Anzahl von Aktionen insgesamt am/mit dem Münzdatensatz, der Münzdatensatz verfallen, also einerseits die Anzahl des direkten Übertragens von Münzdatensätzen limitiert werden und andererseits im Fall eines erkannten Angriffs nachvollzogen werden können, wer den Angriff (hier Endgerät Ml) durchgeführt hat. Für eine Beweis Sicherung wird nachfolgend ein Verfahren/System beschrieben, bei dem Transaktionsdaten von Teilnehmereinheiten (Endgeräte bzw. Sicherheitselemente) in einem entfernten Transaktionsregister archiviert werden und bei behördlichem Beschluss, geprüft werden können.
Das erfindungsgemäße Bezahlsystem umfasst dazu zumindest zwei, bevorzugt eine Vielzahl von Teilnehmereinheiten TEs, die nachfolgend auch als Sicherheitselemente SEx bzw. Endgeräte Mx bezeichnet oder dargestellt sind und ein Transaktionsregister. Das Bezahlsystem kann darüber hinaus beispielsweise zumindest eine Herausgeberinstanz 1, eine oder mehrere Geschäftsbanken, ein (oder mehrere) zentrale Münzregister 2, die die Registrierung der Münzdatensätze vornimmt und die Modifikationen am Münzdatensatz prüft und protokolliert. Weitere erfindungsgemäße Beispiele für Bezahlsysteme sind in Figs. 6, 7, 14 und 16 dargestellt.
Die Fig. 2 zeigt ein Ausführungsbeispiel eines Bezahlsystems BZ gemäß der Erfindung. Das Bezahlsystem BZ umfasst zumindest zwei Sicherheitselemente 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. Zudem ist ein Transaktionsregister 4 des Bezahlsystems BZ dargestellt.
Im Bezahlsystem der Fig. 2 ist zudem eine Herausgeberinstanz 1, beispielsweise eine Zentralbank vorgesehen, die neben der Personenzuordnung 7 auch den elektronischen Münzdatensatz C erzeugt. Zu dem elektronischen Münzdatensatz C wird ein maskierter elektronische Münzdatensatz Z erzeugt und in einem Münzregister 2 des Bezahlsystems registriert 104. Der elektronische Münzdatensatz C wird im Schritt 102 von der Herausgeberinstanz 1 an das erste Endgerät Ml ausgegeben. 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 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.
Bei einer geplanten oder bereits durchgeführten Übertragung 105 eines elektronischen Münzdatensatzes C, wie es nachfolgend noch ausführlich beschrieben wird, wird im ersten Endgerät Ml ein Transaktionsdatensatz TDS erzeugt. Der Transaktionsdatensatz TDS weist eine Teilnehm er-ID des sendenden Endgeräts Ml, eine Teilnehm er-ID des empfangenden Endgeräts M2, optional eine Transaktionsnummer, optional einen geldwerten Betrag des Münzdatensatzes, optional einen zum elektronischen Münzdatensatz C korrespondierenden maskierten Münzdatensatz Z (Maskierung wird später erläutert) und optional einen Transaktionszeitpunkt auf. Jede Teilnehmer-ID eines Endgeräts ist bezahl System weit einer natürlichen Person zugeordnet. Diese Personenzuordnung 7 wird hier beispielsweise von einer Herausgeberinstanz durchgeführt und auch verwaltet. Diese Zuordnung 7 wird erst nach erfolgreicher Identifizierung der Person durch Vorlage eines Personalausweises oder Passes durchgeführt. Diese Zuordnung 7 kann auf Wunsch der Person geändert werden, beispielsweise bei Wechsel der Teilnehmereinheit oder Hinzufügen einer weiteren Teilnehmereinheit.
Nach der Erzeugung des Transaktionsdatensatzes TDS wird dieser von dem ersten Endgerät Ml mit einem kryptografi sehen Schlüssel verschlüsselt. Dieser kryptografische Schlüssel ist beispielsweise ein öffentlicher Schlüsselteil eines korrespondierenden zusammengesetzten privaten Schlüsselteils. Dieser private Schlüsselteil ist aus drei Teilschlüsseln 8a, 8b, 8c zusammengesetzt, wobei die Teilschlüssel 8a, 8b, 8c beispielsweise addiert oder XOR-verknüpft wurden. Diese Verknüpfung der Teilschlüssel 8a, 8b, 8c erfolgt entweder in dem ersten Endgerät Ml oder in dem Transaktionsregister 4. Diese Verknüpfung der Teilschlüssel 8a, 8b, 8c ist beispielsweise systemweit geheim. Die Kenntnis oder der Besitz nur eines Teilschlüssels 8a, 8b, 8c ermöglicht keine Entschlüsselung des Transaktionsdatensatzes TDS. Fig. 5 zeigt ein Ausführungsbeispiel zum Verschlüsseln und Entschlüsseln eines Transaktionsdatensatzes TDS.
In Fig. 2 wird der verschlüsselte Transaktionsdatensatz TDS von dem ersten Endgerät Ml an das Transaktionsregister 4 gesendet und dort abgelegt. Der Zeitpunkt des Sendens ist bevorzugt eng mit dem Übertragen 105 des elektronischen Münzdatensatzes verknüpft, sodass das Transaktionsregister 4 stets auf einem aktuellen Stand der im Bezahlsystem BZ durchgeführten Transaktionen ist.
Bei Betrugsverdachtsfällen könnte im Rahmen eines behördlichen Beschlusses, beispielsweise eine Gerichtsentscheidung, angeordnet werden, den verschlüsselten Transaktionsdatensatz TDS zu entschlüsseln, um die damit aufgezeichnete Transaktion (das Übertragen 105) aufzudecken und zu analysieren. Mittels des behördlichen Beschlusses würden dann beispielsweise an dem Transaktionsregister 4 für ein Endgerät M (mittels der Kennung) über einen bestimmten Zeitpunkt bzw. eine bestimmte Zeitdauer alle abgelegten Transaktionen abgefragt werden. Darüber hinaus könnten weitere Attribute der Transaktionsdaten, wie die Höhe geldwerter Beträge der Münzdatensätze, die jeweiligen Transaktionspartner etc. abgefragt werden.
Als Ergebnis der Gerichtsentscheidung können die Transaktionsdaten entschlüsselt werden, indem eine Mehrzahl von entfernten Instanzen als autorisierte Parteien durch Kombination ihrer Teilschlüssel, einen Entschlüsselungsschlüssel generiert (bzw. bereitstellen). Die entfernten Instanzen sind beispielsweise Vollzugsbehörden, Notare, das Justizministerium, eine Zentralbank oder andere.
Alle entfernten Instanzen (berechtigte Parteien) besitzen nur Teilschlüssel 8a, 8b, 8c des Entschlüsselungsschlüssels. Alle Mitglieder bzw. eine Mindestanzahl n von m entfernten Instanzen sind erforderlich, um den Transaktionsdatensatz TDS gemeinsam zu entschlüsseln. Technisch gesehen werden die einzelnen Teilschlüssel 8a, 8b, 8c der verschiedenen entfernten Instanzen durch Addition oder durch bitweise XOR-Verknüpfung zu einem gemeinsamen privaten Schlüsselteil zusammengesetzt. Dieser private Schlüsselteil (der zum entsprechenden öffentlichen Schlüsselteil der Verschlüsselung korrespondiert) wird dann zur Entschlüsselung des Transaktionsdatensatzes TDS verwendet. Dieses Konzept garantiert, dass keine entfernte Instanz allein den Transaktionsdatensatz TDS entschlüsseln kann und damit andere Instanzen umgehen könnte. Wenn das Konzept nicht auf die Verfügbarkeit aller m entfernten Instanzen angewiesen sein sollte, könnte eine Schwellenwert-kryptographie angewendet werden, um eine Untermenge n dieser Teilschlüssel 8a, 8b, 8c zu verwenden. Diese Untermenge n definiert dann die Mindestanzahl von zu kombinierenden Teilschlüsseln 8a, 8b, 8c.
Das in Fig. 2 gezeigte Bezahlsystem ist dreischichtig aufgebaut. In einer ersten Schicht, ist die Herausgeberinstanz 1, beispielsweise eine Zentralbank, für die Geldschöpfung und -Vernichtung verantwortlich, wie später noch erläutert wird. Geschäftsbanken (nicht dargestellt) können Münzdatensätze C lagern, beispielsweise in Tresormodulen, die als hochsichere Module, beispielsweise als HSM, ausgestaltet sind. Verteilt Geld an Benutzer und sendet oder empfängt Geld an die/von der Zentralbank.
In einer zweiten Schicht sind das Münzregister 2 und das Transaktionsregister 4 vorgesehen. Diese Schicht dient der Prüfung der Münzdatensätze C, insbesondere der Gültigkeit und Echtheit der im Umlauf befindlichen Münzdatensätze C und prüft, ob Münzdatensätze C doppelt ausgegeben wurden. Um ein Strafverfolgungssystem einzurichten, ist das Transaktionsregister 4 vorgesehen. Es ist auch denkbar, dieses Transaktionsregister 4 vom Bezahlsystem BZ zu entkoppeln, um dem Prinzip der "Trennung der Belange" zu folgen. Der Einfachheit halber wird das Transaktionsregister 4 nachfolgend der zweiten Schicht des Bezahlsystems BZ zugeordnet. Das Transaktionsregister 4 ist als vertrauenswürdige Instanz dafür verantwortlich, die Privatsphäre der Menschen in regulären Situationen zu schützen und verschlüsselte Transaktionsdatensätze TDS offenzulegen, wenn dies aufgrund von Gerichtsentscheidungen erforderlich ist. Damit kann geprüft werden, dass keine irregulären Transaktionen oder Geldoperationen stattfinden, insbesondere dass kein (neues) Geld illegal geschaffen oder vernichtet wird. Das Transaktionsregister 4 stellt eine Erweiterung für Anwendungsfälle in der Strafverfolgung dar, mit dem Ziel, verdächtige Transaktionsdaten aufzudecken. Das Transaktionsregister 4 speichert verschlüsselte Datensätze über Transaktionen, die von den beteiligten Teilnehmern gemeldet werden (müssen) und gibt sie nach einem ordnungsgemäßen Verfahren an die Behörden weiter. In dem Transaktionsregister 4 werden die Transaktionsdatensätze TDS in verschlüsselter Form gespeichert. Dadurch wird sichergestellt, dass ein ordnungsgemäßes Verfahren eingehalten werden muss und niemand auf diese sensible Transaktionsdaten nach Belieben zugreifen kann. Zusätzlich kann im Transaktionsregister eine Re- Verschlüsselungs-Einheit eingesetzt werden, die eine Umverschlüsselung der TDS durchführt, so dass eine Strafverfolgungsbehörde nur Zugang zu den behördlich genehmigten Daten erhält. Metadaten, wie Transaktionszeitpunkt und Teilnehm er-ID, dienen dazu, die angefragten Daten bereitzustellen. Die Umverschlüsselungseinheit kann auf alle Daten zugreifen und diese entschlüsseln.
Die dritte Schicht ist eine Direkttransaktionsschicht 3, an der alle Teilnehmer, also Verbraucher, Händler, etc. gleichermaßen über ihre Teilnehmereinheiten TE teilnehmen, um elektronische Münzdatensätze C auszutauschen. Jede Teilnehmereinheit TE kann eine Geldbörse- Applikation aufweisen, um Münzdatensätze C zu verwalten. Die Münzdatensätze C können lokal in der Teilnehmereinheit TE abgelegt sein oder diese sind in einem Online-Speicher (=Cloud-Speicher) abgelegt und die Teilnehmereinheit TE kann diese fernverwalten. Im Falle eines Offline- Szenarios, bei dem eine Übertragung 105 ohne Kontrollinstanzen bzw. Registerinstanzen 2, 4, 6 des Bezahlsystems BZ erfolgen, können Teilnehmereinheiten TE unmittelbar (direkt) mit anderen Teilnehmereinheiten TE interagieren. Die tatsächliche Datenübertragung für eine Münzdatensatz kann weitere dazwischengeschaltete Instanzen umfassen. Dieses Offline-Design des Bezahlsystems BZ macht es erforderlich, dass die Münzdatensätze C in zertifizierten Bereichen, beispielsweise einer Geldbörsen-Applikation aufbewahrt werden, idealerweise innerhalb von Sicherheitselementen SE, beispielsweise Smartcards oder einer eSim Umgebung, um eine Vertrauenswürdigkeit im Bezahlsystem BZ zu erhalten.
Um einen elektronischen Münzdatensatz C zu erzeugen wird folgendes Verfahren vorgeschlagen.
Die Übertragung 105 erfolgt beispielsweise drahtlos über WLAN, NFC oder Bluetooth, also bevorzugt lokal. Die Übertragung 105 kann durch kryptografische Verschlüsselungsverfahren zusätzlich abgesichert sein, indem beispielsweise ein Sitzungsschlüssel ausgehandelt wird oder eine PKI-Infrastruktur angewendet wird. Die Übertragung 105 kann auch unter Einbeziehen eines Online-Datenspeichers erfolgen, aus dem der elektronische Münzdatensatz C an das TE2 (M2, SE2) übertragen wird.
Im Übertragenschritt 105 wird beispielsweise ein sicherer Kanal zwischen dem SEI und dem SE2 aufgebaut, in dessen Rahmen beide SEs sich gegenseitig authentifizieren. Die Übertragungsstrecke zwischen SEI und SE2 ist nicht zwingend unmittelbar direkt, sondern kann eine Internet- oder auch Nahfeldkommunikationsstrecke mit dazwischengeschalteten Instanzen (Endgeräte, Router, Switches, Applikationen) sein. Durch die Verwendung von SEs als sichere Umgebung anstelle von Endgeräten ME als TEs wird eine höhere Vertrauensstufe, englisch Level- of-Trust, erzeugt, also eine Vertrauenswürdigkeit im Bezahlsystem BZ erhöht. Gleichzeitig mit dem Senden des eMD C bzw. unmittelbar davor oder danach wird optional ein Timer gestartet. Zuvor kann der eMD C invalidiert werden und dann nicht mehr vom SEI für Aktionen (wie unten beschrieben) verwendet werden. Der eMD C ist damit im Bezahlsystem BZ blockiert aufgrund eines bereits angestoßenen (und noch nicht beendeten) Übertragungsvorgang 105. Damit wird ein Doublespending unterbunden. Das Invalidieren ermöglicht eine einfache Handhabung während des Übertragungsvorgangs 105.
Bei ordnungsgemäßem Empfang des eMD C im SE2 wird vom SE2 eine Empfangsbestätigung generiert und an das SEI zurückgesendet. Die Empfangsbestätigung vom SE2 kann als eine Löschungsaufforderung gesendet werden, denn erst nach dem Löschen der eMD C im SEI kann (darf) die eMD C im SE2 validiert und verwendet werden. Optional kann das Löschen des eMD C vom SEI angezeigt werden. Dabei wird beispielsweise eine Betragsanzeige des SEI (oder eines Endgeräts ME1, in dem sich das SEI logisch befindet) aktualisiert. Beispielsweise wird der monetäre Betrag des eMD C von einem für Bezahltranskationen zur Verfügung stehenden Betrag des SEI subtrahiert. Es kann eine Löschbestätigung vom SEI an das SE2 versendet werden. Dies dient einer Quittierung, dass der eMD C im SEI nicht mehr vorhanden ist und somit im SE2 validiert werden kann. Mit Erhalt der Löschbestätigung im SE2 kann das SE2 einen Status des eMD C im SE2 in einen Aktiv-Status umsetzen, die eMD C ist damit validiert und kann ab diesem Zeitpunkt für weitere Bezahltranskationen oder Aktionen (Aufteilen, Kombinieren, Umschalten) im SE2 verwendet werden. Optional wird das eMD C des SE2 im Münzregister 2 auf das SE2 umgeschaltet (siehe unten), wodurch das eMD C auf das SE2 registriert ist (Schritt 104).
Ein Übertragungs-Fehlerfall des Übertragens 105 kann im SEI festgestellt werden, beispielsweise durch Überschreiten einer vordefinierten Zeitdauer, indiziert durch einen Timer oder durch das Empfangen einer Fehlermeldung vom SE2 oder dem Endgerät Ml bzw. dem anderen Endgerät M2 (nicht dargestellt). Beispielsweise kann mit jedem erneuten Sendeversuch zum Übertragen des eMD C (RETRY) ein Zählerwert inkrementiert werden und bei Überschreitung einer maximal zulässigen Anzahl von Wiederholungsversuchen, beispielsweise 10 oder 5 oder 3 mal, wird im Schritt 308 automatisch und unabhängig vom Fehlerfall entschieden, dass kein erneuter Sendeversuch (RETRY) durchgeführt wird, sondern das Übertragen 105 als erfolglos zu beenden ist und ein ROLLBACK zu erfolgen hat.
In einer alternativen Ausgestaltung des Übertragen-Verfahrens 105 wird der Status des eMD vom SEI an das Münzregister 2 gemeldet. Dann wird eine Verbindung mit dem Münzregister 2 zur Statusabfrage zu dem eMD C aufgebaut. Wenn das Münzregister 2 weiterhin einen inaktiven Status zum eMD C (registriert auf das SEI) zurückmeldet, wird kein Transaktionsfehler (Manipulationsversuch) angenommen. Wenn das Münzregister 2 aber einen aktiven Status zum eMD C oder eine Registrierung auf einen anderen SE zurückmeldet, wird ein Transaktionsfehler (Manipulationsversuch) angenommen und das Bezahlsystem alarmiert. Zum Beleg wird der Transaktionsdatensatz TDS des SEI verwendet.
Der elektronischer Münzdatensatz C kann vorab bei einer Herausgeberinstanz 1 angefragt und optional von einem Endgerät M (oder einem SE) oder der Herausgeberinstanz 1 oder einem anderen Bezahlsystem empfangen werden. Die Schritte 104 und 105 können den Schritten 104 und 105 der Fig. 11 entsprechen. Eine Aktion (Aufteilen, Verbinden, Umschalten, Übertragen, Einlösen, Wechseln) am eMD C kann einer der Aktionen der Fig. 9 bis 12 entsprechen.
Beispielsweise wird als Verschleierungsbetrag n eine echte Zufallszahl erzeugt. Der Verschleierungsbetrag n wird mit einem monetären Betrag Ui verknüpft. Ein erfindungsgemäßer i-ten elektronischen Münzdatensatz könnte demnach lauten: Ci = {Ό,; r,} (1)
Ein gültiger elektronischer Münzdatensatz kann zur Bezahlung eingesetzt werden. Der Besitzer der beiden Werte Ui und r, 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 maskierten elektronischen Münzdatensatz Zi. Ein maskierter elektronischer Münzdatensatz Zi wird durch Anwenden einer homomorphen Einwegfunktion f (Ci) gemäß Gleichung (2) erhalten:
Z =f(C.) (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, = v, · H + r, · G (3) 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 Ui manipuliert wird und trotzdem ein gültiges Zi berechnet werden könnte. Die Gleichung (3) ist ein „Pederson-Commitment für ECC“, das sicherstellt, dass der monetäre Betrag Ui einem Münzregister 2 zugestanden, also „commited“, werden kann, ohne diesen dem Münzregister 2 zu offenbaren. Dem öffentliche und entfernte Münzregister 2 wird daher nur der maskierte Münzdatensatz Zi zugesendet (offenbart), was in Fig. 2 als Schritt 104 (Registrieren) dargestellt ist.
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 Gleichung (3) ermöglicht 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:
Z, + Zj = (v, H + r, · G) (vj · H + h G) = (u, + u,) H (r, + 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: v, = Vj + Vk (7) r, = /? + n (8)
Für die entsprechenden maskierten Münzdatensätze gilt:
Z Z, + Z* (9)
Mit Gleichung (9) kann beispielsweise auf einfache Weise eine „symmetrische oder asymmetrische Aufteilen“ -Verarbeitung bzw. ein „symmetrischer oder asymmetrischer Aufteilen“ -Verarbeitungsschritt eines Münzdatensatzes gemäß Fig. 9 oder 12 geprüft werden, ohne dass das Münzregister 2 Kenntnis von Ci, , Ck hat. Insbesondere wird die Bedingung der Gleichung (9) geprüft, um aufgeteilte Münzdatensätze und Ck für gültig zu erklären und den Münzdatensatz Ci für ungültig zu erklären. Ein derartiges Aufteilen eines elektronischen Münzdatensatzes Ci ist in Fig. 9 oder 12 gezeigt. Auf die gleiche Weise können elektronische Münzdatensätze C auch zusammengefügt (verbunden) werden, siehe dazu Fig. 10 oder 11 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 einem Überwachungsregister 6 nachweisen können, dass alle monetären Beträge Ui in einer Verarbeitungs-Operation innerhalb eines Wertebereichs von [0, ..., n] liegen, ohne dem Münzregister 2 dabei die monetären Beträge Ui 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 u als auch der Verschleierungsbetrag r eines elektronischen Münzdatensatzes C in Bitdarstellung aufgelöst. Es gilt:
Ui=Zaj-2J für 0 < j < n und aj e (0; 1 } (9a) sowie ri=Zbj-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 Ringsignatur durchzuführen.
In Fig. 3 ist ein Ausführungsbeispiel eines Verfahrensablauf diagramms eines erfindungsgemäßen Verfahrens 300 in einer Teilnehmereinheit TE, nachfolgend auch als Endgeräte M oder Sicherheitselemente SE genannt, dargestellt. Die gestrichelt dargestellten Blöcke des Verfahrens 300 sind dabei optional. Jeder dieser Schritte kann eine Teilnehmerinteraktion oder zumindest ein Teilnehmerinformieren beinhalten, beispielsweise über eine GUI der TE.
Im Schritt 301 wird ein Transaktionsdatensatz TDS erzeugt. Der Transaktionsdatensatz TDS umfasst die Teilnehmer-Kennungen von der ersten Teilnehmereinheit TE1 (sendende TE) und von der zweiten Teilnehmereinheit TE2. Zudem sind Informationen über den zu übertragenden (bzw. den übertragenen) elektronischen Münzdatensatz C enthalten, beispielsweise der geldwerte Betrag v. Anstelle der Informationen über den zu übertragenden (bzw. den übertragenen) elektronischen Münzdatensatz C kann der maskierte elektronische Münzdatensatz Z in den TDS eingebracht werden. Zudem kann ein Transaktionszeitpunkt im TDS enthalten sein, der den Zeitpunkt der Übertragung 105 des elektronischen Münzdatensatzes C zwischen beiden Teilnehmereinheiten TE kennzeichnet. Der Zeitpunkt des Erzeugens 301 kann zeitlich eng mit dem Zeitpunkt des Übertragens 105 gekoppelt sein. In einer Vorgabe des Bezahlsystems BZ kann gefordert sein, dass zuerst der elektronische Münzdatensatz C übertragen werden muss (Schritt 105), bevor der verschlüsselte Transaktionsdatensatz TDS zu versenden ist.
Nach dem Erzeugen- Schritt 301 wird der erzeugte Transaktionsdatensatz TDS verschlüsselt. Dazu weist die erste Teilnehmereinheit TE1 einen öffentlichen Schlüsselteil K auf, der aus Teilschlüsseln verschiedener entfernter Instanzen zusammengesetzt ist. Die Schlüsselzusammensetzung ist beispielsweise in Fig. 5 gezeigt. Alternativ empfängt die Teilnehmereinheit TE1 einen entsprechenden kryptografischen Schlüssel K im Schritt 302, beispielsweise auf Anfrage des Schlüssels bei dem Transaktionsregister 4. Der Schlüssel K kann ein Schlüssel einer PKI-Struktur oder ein symmetrischer Schlüssel sein.
Im Schritt 303 erfolgt dann das Verschlüsseln des Transaktionsdatensatzes TDS mit dem kryptografischen Schlüssel K in der ersten Teilnehmereinheit TE1, beispielsweise durch ein Verschlüsselungsmodul oder eine Recheneinheit der ersten Teilnehmereinheit TE1.
Nicht in der Fig. 3 dargestellt ist ein optionaler Anknüpfen-Schritt von (Klartext-) Metadaten an den verschlüsselten Transaktionsdatensatz TDS, beispielsweise einer Kennung der ersten Teilnehmereinheit TE1, einer Kennung der zweiten Teilnehmereinheit TE2 und/oder einem Transaktionszeitpunkt. Diese Metadaten erlauben es, den lokal und/oder im Transaktionsregister 4 abgelegten verschlüsselten TDS zu indexieren oder zu katalogisieren.
Im Schritt 304 wird dann eine Kommunikationsverbindung zum Transaktionsregister 4 initiiert. Damit wird versucht, einen Kommunikationskanal zwischen der ersten Teilnehmereinheit TE1 und dem Transaktionsregister 4 herzustellen. Das Initiieren umfasst auch, dass die jeweilige Teilnehmereinheit TE erkennt/weiß, dass momentan eine Offline-Transaktion geplant/durchgeführt ist und keine Verbindung zu dem entfernten Transaktionsregister 4 aufgebaut werden kann oder soll.
Im nachfolgenden Prüfschritt 305 wird in der Teilnehmereinheit TE1 abgefragt, ob eine Verbindung im Schritt 304 aufgebaut werden konnte.
Im Ja-Fall des Prüfschritts 305 wird der verschlüsselte Transaktionsdatensatz TDS im Schritt 306 an das Transaktionsregister 4 versendet. Ggf. werden auch weitere Transaktionsdatensätze TDS von früheren Übertragungen von elektronischen Münzdatensätzen C gesendet, sollte diese Kommunikationsverbindung erstmalig seit diesen Übertragungen erstellt worden sein. In diesem Zusammenhang wird dann auch ein Prüfwert zurückgesetzt (nicht dargestellt in Fig. 3), der eine Anzahl von Übertragungen von elektronischen Münzdatensätzen C, die ohne Versenden eines Transaktionsdatensatzes TDS erfolgt sind, repräsentiert. In einem Prüfschritt 305a wird ggf. abgefragt, ob ein Sendefehler beim Senden 305 des verschlüsselten Transaktionsdatensatzes TDS aufgetreten ist. Im Nein-Fall des Prüfschritts 305a wird dann optional der verschlüsselte und/oder der unverschlüsselte Transaktionsdatensatz TDS lokal in der ersten Teilnehmereinheit TE2 zu Archivierungszwecken oder zur Speicherung einer Historie oder für Abfragen aufgrund behördlicher Anfrage gespeichert. Anschließend wird der elektronische Münzdatensatz C im Schritt 105 an die zweite Teilnehmereinheit TE2 übertragen, falls eine Vorgabe im Bezahlsystem BZ ist, dass zuerst der verschlüsselte Transaktionsdatensatz TDS zu versenden ist, bevor der elektronische Münzdatensatz C im Schritt 105 übertragen werden darf. In einer Ausgestaltung des Verfahrens 300 erfolgt nach dem Übertragen 105 zwingend ein Registrieren 104 des maskierten elektronischen Münzdatensatzes Z in dem Münzregister 2. In einer Ausgestaltung des Verfahrens 300 wird im Schritt 104 ein pseudonymisierter maskierter Münzdatensatz in dem Münzregister 2 oder dem Überwachungsregister 6 registriert, wie es in den Figuren 7, 15 und 16 beschrieben ist.
Im Nein-Fall des Prüfschritts 305 (Offline-Transaktion, Flug-Modus, kein Senden der Transaktionsdaten TDS (vom Teilnehmer) gewünscht) und auch im Ja-Fall des Prüfschritts 305a (Übertragungsfehler, Verbindungsabbruch) wird ein Verbindungsfehler im Schritt 307 festgestellt. Daran anschließend wird im Prüfschritt 308 ein Prüfwert p in derersten Teilnehmereinheit TE1 mit einem Schwellwert X verglichen. Der Prüfwert im Schritt 308 repräsentiert eine Anzahl von (offline) Übertragungen 105 von elektronischen Münzdatensätzen C, die ohne Versenden eines Transaktionsdatensatzes TDS erfolgt sind. Diese (offline) Übertragungen 105 ausgehend von der ersten Teilnehmereinheit TE1 können zu einer x-beliebigen anderen Teilnehmereinheit TEx übertragen worden sein. Im Ja-Fall des Prüfschritts 308, also wenn dieser Prüfwert p größer ist als der Schwellwert X, beispielsweise 100 oder 50 oder 10 Übertragungen, wird der Transaktionsdatensatz TDS gespeichert (verschlüsselt und/oder unverschlüsselt) und zwingend der Schritt 304 wiederholt. Im Nein-Fall des Prüfschritts 308 erfolgt das Übertragen 105 falls eine Vorgabe im Bezahlsystem BZ ist, dass zuerst der verschlüsselte Transaktionsdatensatz TDS zu versenden ist, bevor der elektronische Münzdatensatz C im Schritt 105 übertragen werden darf. Im Schritt 310 wird dann der Prüfwert p inkrementiert, d.h. stufenweise erhöht, bevorzugt um 1 erhöht.
Mit den Schritten 308 bis 310 wird sichergestellt, dass das Offline- Verhalten der Teilnehmereinheiten TE überwacht bleibt und nicht über einen vordefinierten bestimmten (bezahl systemvorgegebenen) Schwellwert X von Übertragungsanzahlen hinausgehend möglich ist. Nicht sofort sendbare Transaktionsdatensätze TDS einer Offline-Transaktion, also einem Übertragen 105 ohne Registrieren 104 oder Berichten zu einer der Registerinstanz 2, 4, 6 des Bezahlsystems BZ, werden im Schritt 309 zwischengespeichert und zu einem späteren Zeitpunkt gesendet. Die Anzahl der Offline-Transaktionen, die eine Teilnehmereinheit TE durchführen darf, wird bezahl systemtechnisch begrenzt und mittels des Prüfwerts p kontrolliert im Schritt 308. Ist der Schwellwert X erreicht müssen zunächst die Transaktionsdatensätze TDS gesendet werden, bevor eine weitere Offline-Transaktion 105 möglich ist (siehe Schritt 309 zu Schritt 304). Dieser Prüfwert p kann unabhängig von anderen Prüfungen in der Teilnehmereinheit TE erfasst und geführt werden. Dieser Prüfwert p kann mit anderen Prüf- bzw. Zählwerten pu, pu, des Münzdatensatzes C zur Prüfung im Münzregister 2 oder dem Überwachungsregister 6 kombiniert werden, siehe Bezahlsystem BZ der Fig. 6.
Einzelne Verfahrensschritte können dabei vertauscht werden. So kann eine generelle erste Vorgabe im Bezahlsystem BZ sein, dass Münzdatensätze C erst zwischen TEs übertragen werden, bevor ein Transaktionsdatensatz TDS dazu erstellt wird. Dann würde ein TDS immer ein bereits übertragenen Münzdatensatz C betreffen, der Schritt 105 wäre vor dem dazugehörigen Schritten 301, 303 durchzuführen.
Alternativ kann eine generelle erste Vorgabe im Bezahlsystem BZ sein, dass Münzdatensätze C erst zwischen TEs erst übertragen (Schritt 105) werden, nachdem ein Transaktionsdatensatz TDS dazu erstellt wurde (Schritt 301). Dann würde ein TDS immer ein noch zu übertragenden Münzdatensatz C betreffen, der Schritt 105 wäre nach dem dazugehörigen Schritt 301 durchzuführen.
Eine zweite generelle Vorgabe im Bezahlsystem BZ könnte die lokale Speicherung der TDS im TE betreffen. So kann gefordert sein, dass TDS auch lokal (also Historie oder Archivierung) abzulegen sind. Der Speicherschritt 309 ist dann nicht nur für Übertragen-Wiederholungen (im Fehlerfall eines ersten Übertragenversuchs) vorzusehen. Es kann dabei ein Vorgabedetail sein, dass die TDS auch verschlüsselt im TE zu speichern sind. Diese lokale Speicherung des TDS, die redundant zur Speicherung des TDS im Transaktionsregister 4 ist, kann im Rahmen einer behördlichen Anfrage (einem Gerichtsbeschluss) mit ausgelesen werden, der Teilnehmer also gezwungen werden, diese lokale Speicherung bereitzustellen bzw. kann der Transfer der lokalen Speicherung in einem (Hintergrund-)Prozess der Teilnehmereinheit TE ohne Teilnehmerinteraktion erfolgen.
Eine dritte generelle Vorgabe im Bezahlsystem BZ kann sein, pseudonymisierte TDS* in einem Überwachungsregister 6 des Bezahlsystems BZ abzulegen. Diese pseudonymisierten TDS* werden bei der Gültigkeit der Münzdatensätze mit berücksichtigt, um Betrugsszenarien bereits bezahlsystemintern entdecken zu können. Eine vierte generelle Vorgabe im Bezahlsystem BZ kann sein, verschlüsselte TDS nicht an das Transaktionsregister 4 zu senden, wenn eine Offline-Transaktion geplant/durchgeführt ist. Diese Vorgabe kann eng mit dem Prüfwert p gekoppelt sein, sodass eine Teilnehmereinheit TE eine Warnung bereits vor der Auswahl eines Übertragenmodus (Online oder Offline) an den Teilnehmer ausgibt, dass ein Prüfwert p einen Schwellwert für die maximale Anzahl von Ofline- Übertragungen 105 überschritten hat und ohne vorhergehendes Versenden (alter) TDS an das Transaktionsregister 4 (mit Zurücksetzen des Prüfwert-Zählers) keine weitere Offline- Übertragung möglich ist.
In der Fig. 4 ist ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines erfindungsgemäßen Verfahrens 400 in einem Transaktionsregister 8 gezeigt. Die gestrichelt dargestellten Blöcke des Verfahrens 400 sind dabei optional.
Dabei wird im Schritt 401 ein verschlüsselter Transaktionsdatensatz TDS von einer Teilnehmereinheit TE in dem Transaktionsregister 4 empfangen. Dieser Transaktionsdatensatz TDS ist gemäß dem in Fig. 3 dargestellten Verfahren erzeugt worden.
Im optionalen Prüfschritt 402 wird geprüft, ob verschiedene Generationen von Teilschlüsseln im Bezahlsystem BZ, beispielsweise dem Transaktionsregister 4, bevorzugt einem HSM-Modul innerhalb des Transaktionsregisters 4 als Schlüsselspeicher, vorhanden sind. Im Ja-Fall des Schritts 402 wird der Transaktionsdatensatz TDS mit dem privaten Schlüsselteil k des kryptografi sehen Schlüssels als Entschlüsselungsschlüssel im Schritt 403 entschlüsselt und mit einem kryptografi sehen Schlüssel wieder verschlüsselt, beispielsweise mit einem HSM-Schlüssel des Transaktionsregisters 4. Auf diese Weise kann das Ablegen von verschieden verschlüsselten Transaktionsdatensätzen TDS, die mit verschiedenen Schlüsselversionen der entfernten Instanzen verschlüsselt sind, im Transaktionsregister 4 verhindert werden. Der Verwaltungsaufwand im Transaktionsregister 4 ist damit verringert.
Nach dem Umverschlüsseln-Schritt 403 oder im Nein-Fall des Prüfschritts 402 wird der Transaktionsdatensatz TDS in einem Speicherbereich abgelegt und dort archiviert. Ggf. weist der Transaktionsdatensatz TDS Metadaten im Klartext auf, die in einer Datenbank des Transaktionsregisters 4 eingetragen bzw. nachgehalten werden. Wenn beispielsweise ein Transaktionszeitpunkt als Metadatum des TDS vorhanden ist, kann ein Löschzeitpunkt im Rahmen einer Vorratsdatenspeicherung generiert werden. Der TDS würde dann automatisch nach Ablauf einer eingestellten Zeitspanne (dem Löschungszeitpunkt) aus dem Transaktionsregister 4 gelöscht werden.
Im Transaktionsregister 4 (bspw. eine Datenbank als vertrauenswürdige Entität) werden die TDS in verschlüsselter Form gespeichert, für deren Entschlüsselung mehrere Teilschlüssel erforderlich sind. Dadurch wird sichergestellt, dass ein ordnungsgemäßes Verfahren eingehalten werden muss und niemand nach Belieben auf sensible Transaktionsdaten TDS zugreifen kann.
Optional, beispielsweise bei Nichtvorhandensein eines Schlüsselspeichers im Transaktionsregister 4, werden im Schritt 405 Teilschlüssel des kryptografi sehen Schlüssels k empfangen und im Schritt 406 im Transaktionsregister 4 kombiniert, beispielsweise zum privaten Schlüsselteil des privaten Schlüsselteils bei Verwendung einer PKI-Schlüsselstruktur. Die Kombination ist beispielsweise geheim, um es Besitzern der Teilschlüssel 8a, 8b, 8c nicht zu ermöglichen, den Entschlüsselungsschlüssel zu kombinieren. Der kombinierte Schlüssel kann auch nur aus einer Untermenge von Teil schlüsseln zusammengesetzt werden, was durch Anwenden einer Schwellwert-Kryptographie möglich ist.
Im Rahmen einer - von außerhalb des Bezahlsystems BZ erzeugten - behördlichen Anfrage, insbesondere auf Basis eines richterlichen Beschlusses, wird im Schritt 407 eine Entschlüsselungsanfrage an das Transaktionsregister 4 gestellt. Dabei können die Metadaten der Transaktionsdatensätze mit Parametern der Entschlüsselungsfrage abgeglichen werden, beispielsweise um alle Transaktionsdatensätze mit einer bestimmten Teilnehmer-ID für einen bestimmten Zeitpunktpunkt oder Zeitraum abzufragen. In der Folge wird im Schritt 408 jede entfernte Instanz zur Authentifizierung am Transaktionsregister 4 aufgefordert. Alternativ wird nur eine benötigte Untermenge an entfernten Instanzen abgefragt, die notwendig ist, um den oder die gewünschten Transaktionsdatensätze TDS zu entschlüsseln. Im Schritt 409 erfolgt dann die Entschlüsselung mit dem kombinierten Schlüssel aus den gemeinsam vorhandenen Teilschlüsseln der entfernten Instanzen.
Optional wird im Schritt 410 beispielsweise auch ohne den Schritt 407 eine Teilnehm ereinheiten- Kennung im entschlüsselten Transaktionsdatensatz TDS durch ein Pseudonym der Teilnehmereinheit TE ersetzt. Das Pseudonym entspricht bevorzugt dem Pseudonym der Figuren 7, 15 und 16. Damit wird eine Anonymitätsstufe für das TDS geändert, sodass der TDS in unverschlüsselter Form für die Prüfung von Münzdatensätzen verwendet werden kann.
Optional wird im Schritt 411 beispielsweise auch ohne den Schritt 407 zusätzlich oder alternativ zum Schritt 410 ein geldwerter Betrag im entschlüsselten Transaktionsdatensatz TDS durch eine oder mehrere Betragskategorie ersetzt. In einer Ausgestaltung wird beispielsweise der geldwerte Betrag des Münzdatensatzes C auf oder abgerundet, beispielsweise:
• geldwerter Betrag von 1,97 wird zur Betragskategorie „2 Euro“
• geldwerter Betrag von 878,99 wird zur Betragskategorie „ 1000 Euro“
• geldwerter Betrag von 4,07 wird zur Betragskategorie „4 Euro“
• geldwerter Betrag von 2118,22 wird zur Betragskategorie „2000 Euro“ In einer weiteren Ausgestaltung erfolgt ein Einsortieren des geldwerten Betrags in eine oder mehrere Betragskategorien, die Betragsbereiche abbilden, beispielsweise:
• geldwerter Betrag von 1,97 wird zur Betragskategorie „kleiner 10 Euro“
• geldwerter Betrag von 878,99 wird zur Betragskategorie „zwischen 100 und 1000 Euro“)
• geldwerter Betrag von 4,07 wird zur Betragskategorie „größer 1 Euro“
Die Schritte 410 und/oder 411 können von einem HSM im Transaktionsregister 4 durchgeführt werden. Die pseudonymisierten Transaktionsdaten TDS* und/oder die betragskategorisierten Transaktionsdaten werden im Schritt 412 an das Überwachungsregister 6 oder die Teilnehmereinheit TE (zurück)gesendet. für den jeweiligen Transaktionsdatensatz geändert. Die verschlüsselten Transaktionsdatensätze TDS werden im Transaktionsregister abgelegt (Schritt 404 ggf. nach Schritt 412).
Der pseudonymisierte Transaktionsdatensatz TDS* weist immer eine höhere Anonymität auf als der (nicht-pseudonymisierte) Transaktionsdatensatz TDS. Mit dieser höheren Anonymitätsstufe kann der pseudonymisierte Transaktionsdatensatz TDS* - in einer Vorgabe des Bezahlsystems BZ - auch unverschlüsselt im Münzregister 2, Überwachungsregister 6 und/oder dem Transaktionsregister 4 abgelegt werden und für weitergehende Validitäts-Prüfungen im Bezahlsystem BZ verwendet werden. Damit könnten Betrugsfälle oder Manipulationen im Bezahlsystem BZ durch das Bezahlsystem BZ selbst verbessert aufgedeckt werden, eine behördliche Anfrage (richterlicher Beschluss) ist dann ggf. nicht notwendig.
In Fig. 5 ist ein Ausführungsbeispiel einer Verschlüsselung und Entschlüsselung eines Transaktionsdatensatzes TDS gezeigt. Die entfernten Instanzen 8a, 8b, 8c verfügen jeweils über Teilschlüssel, deren bitweise Addition einen privaten Schlüsselteil k eines kryptografi sehen Schlüssels (Schlüsselpaars) ergibt. Der private Schlüsselteil k wird beispielsweise in einem Schlüsselspeicher des Transaktionsregisters 4, beispielsweise einem Hardware-Security-Modul des Transaktionsregister 4, abgelegt.
Der öffentliche Schlüsselteil K wird vom privaten Schlüsselteil k abgeleitet und der Teilnehmereinheit TE zur Verfügung gestellt. Der Verschlüsselungsschritt 303 in Fig. 3 des erzeugten Transaktionsdatensatzes TDS oder der Umverschlüsselungsschritt 403 in Fig. 4 des entschlüsselten Transaktionsdatensatzes TDS wird dann mit dem öffentlichen Schlüsselteil K erfolgen. Dieses asymmetrische Krypto-System muss sicherstellen sein, dass der öffentliche Schlüsselteil K tatsächlich der vom kombinierten privaten Schlüsselteil k abgeleitete Schlüsselteil ist und es sich hier nicht um eine Fälschung eines Betrügers handelt. Dazu dienen digitale Zertifikate, die die Authentizität des öffentlichen Schlüsselteils K bestätigen. Das digitale Zertifikat kann selbst durch eine digitale Signatur geschützt sein. Der mit dem öffentlichen Schlüsselteil K verschlüsselte Transaktionsdatensatz TDS wird im Transaktionsregister 4 abgelegt.
Vor einer Verwendung des privaten Schlüsselteils k zum Entschlüsseln der abgelegten verschlüsselten Transaktionsdatensätze TDS müssen sich die Untermenge oder alle entfernten Instanzen beim Transaktionsregister 4 authentisieren. Bei erfolgreicher Authentisierung wird der Transaktionsdatensatz TDS unter Verwendung des privaten Schlüsselteils k entschlüsselt.
Der erzeugte Transaktionsdatensatz bestehend beispielsweise aus einer Transaktionsnummer, einer Empfängeradresse (hier von TE2), einer Sendeadresse (hier von TE1) und einem geldwerten Betrag des eMD C. Der erzeugte Transaktionsdatensatz kann im TE1 auch zum Protokollieren des Übertragens 105 verwendet werden, um im Übertragungs-Fehlerfall eine Rückabwicklung (ROLLBACK) oder Wiederholung (RETRY) des Übertragens 105 durchzuführen.
Die Fig. 6 zeigt eine Weiterbildung des Ausführungsbeispiels eines Systems der Fig. 2. Auf die Ausführungen der Fig. 2 wird zur Vermeidung von Wiederholungen verwiesen.
Gemäß Fig. 6 kann in dem elektronischen Münzdatensatz C zusätzlich noch mindestens ein Prüfwert pu als weiteres Datenelement geführt werden. Dieser Prüfwert pu wird bei jeder direkten Übertragung 105 dieses elektronischen Münzdatensatzes C zwischen Teilnehmereinheiten TE1, TE2, also Endgeräten Ml, M2 oder Sicherheitselementen SEI, SE2 als Teilnehmereinheiten TE1, TE2 inkrementiert.
Im Bezahlsystem BZ kann zudem ein Zählerwert pu geführt oder bestimmt werden, der den Prüfwert pu einbezieht, beispielsweise als Summe des bisherigen (registrierten) Zählerwerts pu und des Prüfwerts pu, um zu bestimmen, ob der Münzdatensatz C zurückzugeben ist. Jede Aktion mit dem Münzdatensatz C erhöht diesen Zählerwert pu. Verschiedene Aktionstypen gewichten den Zählerwert pu unterschiedlich, sodass beispielsweise eine direkte Weitergabe des Münzdatensatzes C ein höheres Gewicht hat als eine Modifikation (Aufteilen, Kombinieren, Umschalten). Auf diese Weise wird die Lebensdauer und die darin geführten Aktionen eines Münzdatensatzes C bewertet und Kriterien für dessen Rückgabe entsprechend der geführten Aktionen definiert. Der Prüfwert pn und auch der Zählerwert pu bilden den Lebenszyklus des Münzdatensatzes C ab, anhand dessen dann über eine Rückgabe entschieden wird.
Wie bereits mit Fig. 3 beschrieben wurde, kann im Bezahlsystem BZ in einer Teilnehmereinheit TE (also den in Fig. 6 dargestellten Endgeräten Ml, M2 oder Sicherheitselementen SEI, SE2) ein Prüfwert p vorgesehen sein, der die Anzahl bereits übertragener Münzdatensätze C ohne (unmittelbares) dazugehöriges Senden eines verschlüsselten Transaktionsdatensatzes TDS an das Transaktionsregister 4 repräsentiert. Dieser Prüfwert p wird bei Feststellen eines Verbindungsfehlers im Schritt 307 mit einem Schwellwert X verglichen. Dabei wird festgestellt, ob eine weitere (Offline) Übertragung 105 durchgeführt werden darf (Bezahl systemvorgabe) oder nicht.
In Fig. 6 ist das Transaktionsregister 4 dargestellt, das bereits mit den Figuren 2 bis 5 beschrieben wurde. Zudem kann das Transaktionsregister 4 mit dem Überwachungsregister 6 in Kommunikationsverbindung stehen, um pseudonymisierte Transaktionsdatensätze TDS* im Überwachungsregister 6 zu registrieren. Dazu wird gemäß Schritt 410 beispielsweise eine Teilnehm ereinheiten-Kennung im entschlüsselten Transaktionsdatensatz TDS durch ein Pseudonym P der Teilnehmereinheit TE ersetzt. Zudem wird gemäß Schritt 411 beispielsweise zusätzlich oder alternativ zum Schritt 410 ein geldwerter Betrag im entschlüsselten Transaktionsdatensatz TDS durch eine Betragskategorie ersetzt. Die Schritte 410 und/oder 411 können von einem HSM im Transaktionsregister 4 durchgeführt werden. Die pseudonymisierten Transaktionsdaten TDS* und/oder die betragskategorisierten Transaktionsdaten TDS* werden gemäß Schritt 412 an das Überwachungsregister 6 gesendet, während die verschlüsselten Transaktionsdatensätze TDS im Transaktionsregister 4 abgelegt sind.
In Fig. 6 wird vom elektronischen Münzdatensatz Ci mittels der Gleichung (3) ein maskierter elektronischer Münzdatensatz Zi, beispielsweise im SEI, errechnet und dieser maskierte Münzdatensatz Zi wird zusammen mit zumindest dem zweiten Prüfwert pu in einem Überwachungsregister 6 registriert.
Im SE2 wird der übertragene elektronische Münzdatensatz Ci als Ci* erhalten. Mit dem Erhalt des elektronischen Münzdatensatzes Ci* ist das SE2 im Besitz des digitalen Geldes, den der elektronische Münzdatensatz Ci* repräsentiert. Mit der direkten Übertragung 105 steht es dem SE2 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) der maskierte übertragene elektronische Münzdatensatz Zi* errechnet werden. Der maskierte übertragene elektronische Münzdatensatz Zi* wird dann an das Münzregister 2 im Schritt 104 übertragen und dort gesucht. Bei Übereinstimmung mit einem registrierten und gültigen maskierten elektronischen Münzdatensatz 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 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 Überwachungsregister 6 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 Verarbeitungsschritt 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, 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 Anzahl der Operationen für die einzelnen Verarbeitungen ist in der Tabelle 1 mit „0“, „1“ oder „2“ gekennzeichnet. Die Anzahl „0“ zeigt dabei an, dass ein Teilnehmereinheit TE oder die Herausgeberinstanz 1 diese Operation für diese Verarbeitung des elektronischen Münzdatensatzes C nicht durchführen muss. Die Anzahl „1“ zeigt dabei an, dass das Teilnehmereinheit TE bzw. die Herausgeberinstanz 1 diese Operation für diese Verarbeitung des elektronischen Münzdatensatzes C einmal durchführen können muss. Die Anzahl „2“ zeigt dabei an, dass das Teilnehmereinheit TE bzw. die Herausgeberinstanz 1 diese Operation zweimal für diese Verarbeitung des elektronischen Münzdatensatzes durchführen können muss.
Grundsätzlich kann in einer Ausgestaltung auch vorgesehen sein, dass eine Bereichsprüfung durch die Herausgeberinstanz 1 auch beim Erzeugen und/ oder Löschen durchgeführt wird.
In der nachfolgenden Tabelle 2 sind für die einzelnen Verarbeitungen die für das Münzregister 2 und/oder das Überwachungsregister 6 benötigten Operationen aufgelistet:
Tabelle 2 - Anzahl pro Verarbeitung eines C in dem Münzregister durchführbaren Operationen
Weitere Operationen, die in Tabelle 2 nicht aufgeführt sind, können benötigt werden. Anstelle der angeführten Implementierung sind andere Umsetzungen denkbar, die andere Operationen implizieren. Alle Operationen der Tabelle 2 können in dem Münzregister 2 durchgeführt werden, die als vertrauenswürdige Instanz, beispielsweise als Serverinstanz, beispielsweise als Distributed- Trusted-Server, für eine ausreichende Integrität der elektronischen Münzdatensätze C sorgt.
Die Tabelle 3 zeigt die für die Systemteilnehmer im Bezahlsystem der Fig. 1 bevorzugt zu installierenden Komponenten:
Tabelle 3 - Bevorzugte Einheiten in den Systemkomponenten
Tabelle 3 zeigt eine Übersicht über die bevorzugt zu verwendenden Komponenten in jedem Systemteilnehmer, also der Herausgeberinstanz 1, einer Teilnehmereinheit TE und den Registerinstanzen, nämlich dem Münzregister 2, dem Überwachungsregister 6, dem Transaktionsregister 4.
Die Teilnehmereinheiten TE können mittels e-Wallet für elektronische Münzdatensätze Ci (mit den Prüfwert p, pn pn) 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, der Transaktionsregister 4 und/oder das Überwachungsregister 6 auf einem Server oder auf einer DLT basiert und von einer Reihe vertrauenswürdiger Marktteilnehmer betrieben wird.
Die Fig. 7 zeigt eine zu Fig. 6 alternative Weiterbildung des Ausführungsbeispiels eines Systems der Fig. 2. Auf die Ausführungen der Fig. 2 und der Fig. 6 wird zur Vermeidung von Wiederholungen verwiesen. Die Ausgestaltungen der Fig. 7 können auch mit den Ausgestaltungen der Fig. 6 kombiniert werden.
Fig. 7 zeigt ein Ausführungsbeispiel eines Bezahlsystems BZ mit Endgeräten Ml und M2 (als Beispiele für Teilnehmereinheiten TE), einer Herausgeberinstanz 1, einem Münzregister 2, einem Überwachungsregister 6 und einem Transaktionsregister 4. Die Endgeräte Ml und M2 können dabei auch Geräte oder Sicherheitselemente SEI, SE2 sein.
Das Münzregister 2 enthält ein Register 210, in welchem gültige maskierte elektronische Münzdatensatz Zi gespeichert sind. Der elektronische Münzdatensatz Ci repräsentiert einen monetären Betrag Ui. Der elektronische Münzdatensatz Ci wird an ein erstes Endgerät Ml ausgegeben. Elektronische Münzdatensätze Ci, bevorzugt für welche ein maskierter elektronischer Münzdatensatz Zi registriert ist, können zur Bezahlung verwendet werden. Der maskierte elektronische Münzdatensatz Zi kann auch als betragsmaskierter elektronischer Münzdatensatz bezeichnet werden, da der monetäre Betrag Ui für das Münzregister 2 unbekannt ist (und auch im weiteren Verlauf unbekannt bleibt). Ein Empfänger, hier beispielsweise ein zweites Endgerät M2, des elektronischen Münzdatensatzes Ci kann dessen Gültigkeit mit Hilfe des Münzregisters 2 prüfen. Das Münzregister 2 kann die Gültigkeit des elektronischen Münzdatensatzes Ci mit Hilfe des maskierten elektronischen Münzdatensatzes Zi bestätigen. Für das Münzregister 2 ist der maskierte elektronische Münzdatensatz Zi ein anonymer elektronischer Münzdatensatz, insbesondere da es einen Besitzer des zugehörigen elektronischen Münzdatensatz Ci nicht kennt. Die Anonymitätsstufe eines maskierten Münzdatensatzes Zi in dem Register 201 des Münzregisters 2 ist demnach Stufe 1 (vollständig anonym).
In Fig. 7 ist dargestellt, dass das zweite Endgerät M2 maskierte elektronische Münzdatensätze Zi* in einem anonymen Modus M2a anonym an das Münzregister 2 sendet, also insbesondere nur den maskierten elektronischen Münzdatensatz Zi* sendet. Das Münzregister 2 bearbeitet die anonym gesendeten maskierten elektronischen Münzdatensatz Zi* in einem anonymen Modus 2a, in welchem beispielsweise dem zweiten Endgerät M2 nur bestätigt wird, dass der gesendete maskierte elektronische Münzdatensatz Zi* gültig ist. Das Münzregister 2 speichert in dem Register 210 anonyme (betrags)maskierte Münzdatensätze Zi von elektronischen Münzdatensätzen Ci der Herausgeberinstanz 1 oder von modifizierten elektronischen Münzdatensätzen der Endgeräte M.
In Fig. 7 ist weiterhin dargestellt, dass das zweite Endgerät M2 maskierte elektronische Münzdatensätze Si* auch in einem pseudonymen Modus M2p pseudonymisiert an das Überwachungsregister 6 senden kann. Das zweite Endgerät M2 verknüpft beispielsweise den maskierten elektronischen Münzdatensatz Zi* mit einem Pseudonym PM2 und sendet den pseudonymisierten maskierten elektronischen Münzdatensatz Si* an das Überwachungsregister 6. Das zweite Endgerät M2 könnte einen pseudonymisierten maskierten elektronischen Münzdatensatz Si* durch Anhängen des Pseudonyms PM2 an den maskierten elektronischen Münzdatensatz Zi* erzeugen. In der dargestellten Ausgestaltung erstellt das zweite Endgerät M2 eine Signatur über den maskierten elektronischen Münzdatensatz Zi* und fügt die Signatur dem Münzdatensatz Zi* hinzu. Als Pseudonym PM2 kann beispielsweise der öffentliche Schlüssel des Signaturschlüsselpaares dienen. Alternativ ist als Pseudonym PM2 eine Ableitung von einer Teilnehmerkennung, wie Endgerätenummer, IMEI, IMSI oder einer vergleichbar abgeleiteten Kennung.
Das Pseudonym P kann eine Ableitung der oben erwähnte Teilnehm ereinheiten-Kennung sein. Das Pseudonym P kann zusätzlich in der Personenzuordnung 7 der Herausgeberinstanz 1 (oder alternativ eines Diensteanbieters, bspw. einem Geldbörsen-Applikations-Anbieter oder eines Online-Speicher-Bereitstellers) neben der Teilnehm ereinheiten-Kennung aufgelistet sein. Zum Schutz der natürlichen Person kann das Pseudonym P ggf. nur in einer vertrauenswürdigen Instanz einer natürlichen Person zugeordnet werden.
Das Überwachungsregister 6 bearbeitet die pseudonym gesendeten maskierten elektronischen Münzdatensatz Si* in einem pseudonymen Modus 2p, in welchem dem zweiten Endgerät M2 ebenfalls bestätigt wird, dass der gesendete maskierte elektronische Münzdatensatz Zi* gültig ist. Jedoch wird zusätzlich in einer Datenstruktur 220 des Überwachungsregister 6 die Zuordnung des maskierten elektronischen Münzdatensatzes Zi zum Pseudonym PM2 gespeichert. Wie in den weiteren Ausgestaltungen deutlich wird, kann die Datenstruktur 220 als ein Register für noch zu prüfende maskierte elektronische Münzdatensatze Zi verwendet werden, also auch die Funktion eines Münzregisters 2 erfüllen. Das Überwachungsregister 6 verschiebt oder überspringt im pseudonymen Modus 2p insbesondere einen im anonymen Modus 2a (häufiger oder stets) ausgeführten Prüfungsschritt. Im Prüfungsschritt wird geprüft - bevorzugt weiterhin in Unkenntnis des monetären Betrages Ui, ob der monetäre Betrag Ui des maskierten elektronischen Münzdatensatzes Zi in einem Bereich liegt. Die anschließend beschriebenen Aspekte, bauen zumindest teilweise auf Details dieser Ausgestaltung der Fig. 2, 6 oder 7 auf. Beschrieben wird dort primär der komplexere pseudonyme Modus 2p bzw. M2p, da der einfachere anonyme Modus 2a bzw. M2a ohne Pseudonym (bzw. Signatur) abläuft. In den Figuren 15 und 16 werden dagegen Ausgestaltungen beschrieben, die nur optional mit den Details der anderen Ausgestaltungen kombiniert werden können.
Fig. 8 zeigt eine Datenstruktur für ein Münzregister 2 und/oder ein Überwachungsregisters 6 der vorhergehenden Figuren. In der Fig. 8 sind Daten des Münzregisters 2 und/oder des Überwachungsregisters 6 zur Veranschaulichung in einer gemeinsamen Datenstruktur als Tabelle gemeinsam dargestellt. In den Registern 2, 6 sind die maskierten elektronischen Münzdatensätze Zi und ggf. ihre Verarbeitungen registriert. Das Münzregister 2 und das Überwachungsregister 6 können in einer gemeinsamen Serverinstanz untergebracht sein und sind nur logisch voneinander getrennt, um den Rechenaufwand für die einzelnen Überprüfungen durch strikte Zuweisungen reduzieren zu können. Alternativ sind die Register 2, 6 auch physisch voneinander getrennt. Beide Register 2, 6 sind 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 Verarbeitungen „Erstellen“ und „Deaktivieren“, die die Existenz des monetären Betrags Ui, an sich betreffen, also die Schaffung und die Vernichtung von Geld bedeuten, bedürfen einer zusätzlichen Genehmigung durch die Herausgeberinstanz 1, um in dem Münzregister 2 und/oder dem Überwachungsregister 6 registriert (also protokolliert) zu werden. Die übrigen Verarbeitungsoperationen (Aufteilen, Verbinden, Umschalten) bedürfen keiner Autorisierung durch die Herausgeberinstanz 1 oder durch den Befehlsinitiator (= Zahler, bspw. das erste Endgerät Ml). Die übrigen Verarbeitungsoperationen sind jedoch hinsichtlich verschiedener Prüfkriterien zu prüfen.
Eine Registrierung der jeweiligen Verarbeitung wird beispielsweise durch entsprechende Listeneinträge in der Datenbank gemäß Fig. 8 realisiert. Jeder Listeneintrag hat dabei weitere Markierungen 25 bis 28, die die Zwischenergebnisse der jeweiligen Verarbeitung dokumentiert, die von dem Münzregister 2 und/oder dem Überwachungsregister 6 durchgeführt werden müssen. Bevorzugt werden die Markierungen 25 bis 28 als Hilfestellung benutzt und nach Abschluss der Befehle von dem Münzregister 2 und/oder dem Überwachungsregister 6 verworfen.
Für anonyme Münzdatensätze sind stets alle Prüfungen auszuführen, so dass auch alle Markierungen 25 -28 verworfen werden könnten. Für pseudonymisierte Münzdatensätze kann dagegen eine Prüfung auch entfallen bzw. später ausgeführt werden.
In Fig. 8 sind beispielsweise die Prüfungen, die den Markierungen 27b und 27c entsprechen, für pseudonymisierte Münzdatensätze nicht nötig, weil sie später in anderer Form durchgeführt werden. Die Prüfungsschritte der Markierungen 25, 26, 27a und 28 sind dagegen notwendig. Im Folgenden wird entsprechend teilweise von notwendigen bzw. gültigkeitsrelevanten Prüfungsschritten und nachholbaren bzw. gültigkeitsunabhängigen Prüfungsschritten gesprochen, da sie die direkt oder indirekt nachgeholt werden. Ein Münzdatensatz kann als gültig behandelt werden, wenn die notwendigen Prüfungen erfolgt sind. Die in Fig. 8 fett hervorgehobenen Daten in den Spalten 24, 28 und 29 sind nur für pseudonymisiert erhaltene Münzdatensätze relevant und betreffen daher vorrangig Eintragungen im Überwachungsregister 6.
Eine optionale Markierung 29 kann beispielsweise den Abschluss der Verarbeitung anzeigen. Die Markierungen 29 sind bei Eingehen eines Verarbeitung-Befehls beispielsweise im Zustand und werden nach erfolgreichem Absolvieren aller Prüfungen (zu Markierungen 25-28) auf den Zustand „1“ gesetzt und bei mindestens einer gescheiterten Prüfung auf den Zustand „0“ gesetzt. Eine (Abschluss-)Markierung 29 könnte mit dem Wert „2“ beispielsweise anzeigen, dass nur die notwendigen Prüfungen abgeschlossen und nachholbare Prüfungen ausgelassen wurden. Werden später von dem Endgerät mit dem Pseudonym Prüfungen für einen oder mehrere Einträge nachgeholt, kann die Markierung auf den Wert „1“ gesetzt werden. Anstelle einer solchen Verwendung der Abschluss-Markierung 29 könnten natürlich auch die Markierungen 27b und 27c der nachzuholenden Prüfungen verwendet und/oder eine separate Pseudonym-Markierung eingesetzt werden.
Eine mögliche Struktur für einen Listeneintrag eines Münzdatensatzes umfasst beispielsweise zwei Spalten 22a, 22b für einen Vorgänger-Münzdatensatz (Ol, 02), zwei Spalten 23a, 23b für einen Nachfolger-Münzdatensatz (Sl, S2), eine Signatur-Spalte 24 für Signaturen von Herausgeberinstanz(en) 1 und Signaturen von Endgeräten M, und sechs Markierungsspalten 25, 26, 27a, 27b und 27c sowie 28. Jeder der Einträge in den Spalten 25 bis 28 weist drei alternative Zustände oder „0“ auf.
Die Spalte 25 (O-Flag) zeigt an, ob eine Gültigkeitsprüfung bezüglich eines elektronischen Vorgänger-Münzdatensatzes in Spalte 22a/b erfolgreich war. Der Zustand „1“ bedeutet, dass eine Validitäts-Prüfung ergab, dass der elektronische Münzdatensatz der Spalte 22a/b gültig ist und der Zustand „0“ anzeigt, dass eine Validitäts-Prüfung ergab, dass der elektronische Münzdatensatz der Spalte 22a/b ungültig und der Zustand anzeigt, dass eine Validitäts-Prüfung noch nicht abgeschlossen ist. Für mehrere Vorgänger-Münzdatensätze wird bevorzugt ein gemeinsames O- Flag eingesetzt (beide gültig), anstatt zwei getrennte O-Flags. Die Spalte 26 (C-Flag) zeigt an, ob eine erste Prüfberechnung für die maskierten elektronischen Münzdatensätze erfolgreich war. Mit der ersten Prüfberechnung wird insbesondere überprüft, ob der Befehl betragsneutral ist, also primär dass die Summe der beteiligten monetären Beträge Null ergibt. Der Zustand „1“ bedeutet, dass eine Berechnung erfolgreich war und der Zustand „0“ gibt an, dass Berechnung nicht erfolgreich war und der Zustand anzeigt, dass eine Berechnung noch nicht abgeschlossen ist.
Die in Spalte 26 durchzuführende Berechnung lautet beispielsweise:
(Zoi + Z02) - (Zsi + Zs2) == 0 (10)
Die Spalte 27a (RI -Flag) zeigt an, ob eine erste Prüfung eines Bereichsnachweises oder des Bereichsnachweises erfolgreich war. Gleiches gilt für die weiteren Spalten 27b (R2-Flag) und 27c (R3-Flag). Der Zustand „1“ bedeutet, dass eine Validitäts-Prüfung ergab, dass die
Bereichsnachweise oder der Bereichsnachweis nachzuvollziehen sind oder ist und der Zustand „0“ zeigt an, dass eine Validitäts-Prüfung ergab, dass die Bereichsnachweise oder der
Bereichsnachweis nicht nachvollzogen werden konnten oder konnte und der Zustand zeigt an, dass eine Validitäts-Prüfung noch nicht abgeschlossen ist, nicht erfolgreich war. Der erste Bereichsnachweis der Spalte 27a ist immer nötig, damit der oder die Münzdatensätze als gültig betrachtet werden können. Ein typisches Beispiel für eine notwendige Prüfung ist die Prüfung, dass der monetäre Betrag nicht negativ ist (bzw. keiner der monetären Beträge negativ ist). Der zweite und dritte Bereichsnachweis beeinflusst die Gültigkeit des Münzdatensatzes nicht und kann/können für pseudonymisierte maskierte Münzdatensätze, beispielsweise bei einer späteren Transaktion des Pseudonyms, nachgeholt werden. Mit dem Bereichsnachweis der Spalte 27b wird geprüft, ob der monetäre Betrag des maskierten Münzdatensatzes (bzw. jedes Münzdatensatzes) unter einem Maximalbetrag liegt. Der Maximalbetrag kann systemweit oder für bestimmte Endgerätetypen vorbestimmt sein. Mit dem Bereichsnachweis der Spalte 27c wird beispielsweise eine Summe monetärer Beträge, die die Teilnehmereinheit TE (gesendet oder) in einem bestimmten Zeitraum - wie 24 Stunden - empfangen hat, mit einem Summengrenzwert verglichen oder beispielsweise eine Transaktionsanzahl pro Zeiteinheit für die Teilnehmereinheit TE geprüft, wie maximal 5 pro Minute oder 100 pro Tag. Die Grenzwerte können vom Bezahlsystem BZ systemweit vorgegeben oder für bestimmte Teilnehm ereinheiten-Typen (also teilnehmereinheitenspezifisch) definiert werden. Beispielsweise kann eine Kaffeemaschine vom Typ X gerätebedingt nur vier Portionen Heißgetränke pro Minute ausgeben und dementsprechend sind nur vier Münztransaktionen pro Minute gestattet. Die Spalte 28 (S-Flag) zeigt an, ob eine Signatur des elektronischen Münzdatensatzes mit der Signatur der Spalte 24 übereinstimmt, wobei Zustand „1“ bedeutet, dass eine Validitäts-Prüfung ergab, dass die Signatur als die der Herausgeberinstanz identifiziert werden konnte und der Zustand „0“ anzeigt, dass eine Validitäts-Prüfung ergab, dass die Signatur nicht als die der Herausgeberinstanz identifiziert werden konnte und der Zustand anzeigt, dass eine Validitäts- Prüfung noch nicht abgeschlossen ist.
Eine Änderung des Status eines der Markierungen (auch als „Flag“ bezeichnet) bedarf der Genehmigung durch das Münzregister 2 und/oder das Überwachungsregister 6 und muss sodann unveränderlich in der Datenstruktur der Fig. 8 gespeichert werden. Eine Verarbeitung ist im anonymen Modus (bzw. für einen anonymen maskierten Münzdatensatz) endgültig, wenn und nur wenn die erforderlichen Markierungen 25 bis 28 durch das Münzregister 6 validiert wurden, d.h. nach der entsprechenden Prüfung vom Zustand „0“ in den Zustand „1“ oder den Zustand „1“ gewechselt wurden. Eine Verarbeitung ist im pseudonymen Modus (bzw. für einen pseudonymisiert maskierten Münzdatensatz) abgeschlossen, wenn die Prüfungen zu den Markierungen 25 bis 27a und 28 durch das Überwachungsregister 6 erfolgt sind.
Im Folgenden wird von einer Datenstruktur ohne Abschlussmarkierungen 29 ausgegangen und zunächst die Gültigkeit anonymer Münzdatensätze betrachtet. Um festzustellen, ob ein maskierter elektronischer Münzdatensatz Z gültig ist, sucht das Münzregister 2 nach der letzten Änderung, die den maskierten elektronischen Münzdatensatz Z betrifft. Es gilt, dass der maskierte elektronische Münzdatensatz Z gültig ist, sofern der maskierte elektronische Münzdatensatz Z für seine letzte Verarbeitung in einer der Nachfolger-Spalten 23a, 23b aufgeführt ist, wenn und nur wenn diese letzte Verarbeitung die entsprechende endgültige Markierung 25 bis 28 aufweist. Es gilt auch, dass der maskierte elektronische Münzdatensatz Z gültig ist, sofern der maskierte elektronische Münzdatensatz Z für seine letzte Verarbeitung in einer der Vorgänger-Spalten 22a, 22b aufgeführt ist, wenn und nur wenn diese letzte Verarbeitung fehlgeschlagen ist, also zumindest einer der entsprechend geforderten Zustände der Markierungen 25 bis 28 auf „0“ gesetzt ist.
Wenn der maskierte elektronische Münzdatensatz Z nicht in dem Münzregister 2 gefunden wird, ist er ungültig. Es gilt zudem, dass der anonyme maskierte elektronische Münzdatensatz Z für alle übrigen Fälle nicht gültig ist. Beispielsweise wenn die letzte Verarbeitung des maskierten elektronischen Münzdatensatzes Z in einer der Nachfolger-Spalten 23a, 23b aufgeführt ist, diese letzte Verarbeitung aber nie endgültig wurde oder wenn die letzte Verarbeitung des maskierten elektronischen Münzdatensatzes Z in einer der Vorgänger-Spalten 22a, 22b ist und diese letzte Verarbeitung endgültig ist. Die Prüfungen, die durch das Münzregister 2 und/oder das Überwachungsregister 6 erfolgen, um festzustellen, ob eine Verarbeitung endgültig ist, werden durch die Spalten 25 bis 28 abgebildet: Der Zustand in der Spalte 25 zeigt an, ob der/die maskierten elektronischen Münzdatensätze gemäß Vorgänger-Spalten 22a, 22b gültig sind. Der Zustand in der Spalte 26 gibt an, ob die Berechnung des maskierten elektronischen Münzdatensatzes gemäß Gleichung (10) stimmt. Der Zustand in der Spalte 27a gibt an, ob die Bereichsnachweise für die maskierten elektronischen Münzdatensätze Z erfolgreich geprüft werden konnten. Der Zustand in Spalte 28 zeigt an, ob die Signatur in der Spalte 24 des maskierten elektronischen Münzdatensatzes Z eine gültige Signatur der Herausgeberinstanz 1 ist.
Der Zustand „0“ in einer Spalte 25 bis 28 zeigt dabei an, dass die Prüfung nicht erfolgreich war. Der Zustand „1“ in einer Spalte 25 bis 28 zeigt dabei an, dass die Prüfung erfolgreich war. Der Zustand in einer Spalte 25 bis 28 zeigt dabei an, dass keine Prüfung erfolgt ist. Die Zustände können auch einen anderen Wert aufweisen, solange eindeutig zwischen Erfolg/Misserfolg einer Prüfung unterschieden werden kann und ersichtlich ist, ob eine bestimmte Prüfung durchgeführt wurde.
Beispielhaft sind fünf verschiedene Verarbeitungen definiert, die hier im Einzelnen erläutert werden. Dabei wird auf den entsprechenden Listeneintrag in der Fig. 8 verwiesen.
Eine Verarbeitung ist beispielsweise „Erzeugen“ eines elektronischen Münzdatensatzes Ci. Das Erzeugen in der Direkttransaktionsschicht 3 durch die Herausgeberinstanz 1 beinhaltet das Wählen eines monetären Betrags Ui und das Erstellen eines Verschleierungsbetrags n, wie mit Gleichung (1) bereits beschrieben wurde. Wie in Fig. 8 gezeigt, bedarf es bei der Verarbeitung „Erzeugen“ keiner Eintragungen/Markierungen in den Spalten 22a, 22b, 23b und 25 bis 27. In der Nachfolger- Spalte 23a wird der maskierte elektronische Münzdatensatz Zi registriert. Diese Registrierung erfolgt bevorzugt vor dem Übertragen 105 an eine Teilnehmereinheit TE, insbesondere oder bereits beim Generieren durch die Herausgeberinstanz 1, wobei in beiden Fällen dazu die Gleichung (3) ausgeführt werden muss. Der maskierte elektronische Münzdatensatz Zi ist beim Erstellen von der Herausgeberinstanz 1 signiert, diese Signatur ist in der Spalte 24 eingetragen, um sicherzustellen, dass der elektronische Münzdatensatz Ci tatsächlich von einer Herausgeberinstanz 1 erstellt wurde, wobei auch andere Verfahren dafür in Frage kommen. Stimmt die Signatur eines erhaltenen Zi mit der Signatur in Spalte 24 überein, so wird die Markierung in Spalte 28 gesetzt (von „0“ auf „1“). Die Markierungen gemäß Spalte 25 bis 27 benötigen keine Statusänderung und können ignoriert werden. Der Bereichsnachweis wird nicht benötigt, da das Münzregister 2 und/oder das Überwachungsregister 6 darauf vertrauen kann, dass die Herausgeberinstanz 1 keine negativen monetären Beträge ausgibt. In einer alternativen Ausführung kann er aber von der Herausgeberinstanz 1 im Erstellen-Befehl mitgesendet werden und von dem Münzregister 2 und/oder dem Überwachungsregister 6 geprüft werden. Eine Verarbeitung ist beispielsweise „Deaktivieren“. Das Deaktivieren, also das Geldvernichten, bewirkt, dass der maskierte elektronische Münzdatensatz Zi nach erfolgreichem Ausführen des Deaktivieren-Befehls durch die Herausgeberinstanz 1 ungültig wird. Man kann also den zu deaktivierenden (maskierten) elektronischen Münzdatensatz in dem Münzregister 2 und/oder in dem Überwachungsregister 6 nicht mehr weiterverarbeiten. Um Verwirrung zu vermeiden, sollten die entsprechenden (nicht maskierten) elektronischen Münzdatensätze Ci auch in der Direkttransaktionsschicht 3 deaktiviert werden. Beim „Deaktivieren“ wird die Vorgängerspalte 22a mit dem elektronischen Münzdatensatz Zi beschrieben, aber keine Nachfolgerspalte 23a, 23b besetzt. Der maskierte elektronische Münzdatensatz Zi ist beim Deaktivieren daraufhin zu prüfen, ob die Signatur mit der Signatur gemäß Spalte 24 übereinstimmt, um sicherzustellen, dass der elektronische Münzdatensatz Ci tatsächlich von einer Herausgeberinstanz 1 erstellt wurde, wobei wieder andere Mittel für diese Prüfung verwendet werden können. Kann das signierte Zi, das im Deaktivieren-Befehl mitgesendet wird, als von der Herausgeberinstanz 1 signiert bestätigt werden, wird die Markierung 28 gesetzt (von „0“ auf „1“). Die Markierungen gemäß Spalte 26 bis 27 benötigen keine Statusänderung und können ignoriert werden. Die Markierungen gemäß Spalte 25 und 28 werden nach entsprechender Prüfung gesetzt.
Eine Verarbeitung (Modifikation) ist beispielsweise das „Aufteilen“. Das Aufteilen, also das Teilen eines elektronischen Münzdatensatzes Zi in eine Anzahl n, beispielsweise 2, von elektronischen Münzteildatensätzen Zj und Zk erfolgt zunächst in der Direkttransaktionsschicht 3, so wie es in den Figuren 9, 11 und 12 noch gezeigt wird, wobei die monetären Beträge Uj und des Verschleierungsbetrags h generiert werden. Vk und rk ergeben sich durch Gleichungen (7) und (8). In dem Münzregister 2 und/oder dem Überwachungsregister 6 werden die Markierungen 24 bis 27 gesetzt, die Vorgängerspalte 22a wird mit dem elektronischen Münzdatensatz Zi beschrieben, Nachfolgerspalte 23a wird mit Zj und Nachfolgerspalte 23b wird mit Zk beschrieben. Die gemäß Spalten 24 bis 27 benötigten Statusänderungen erfolgen nach der entsprechenden Prüfung durch das Münzregister 2 und/oder das Überwachungsregister 6 und dokumentieren das jeweilige Prüfungsergebnis. Die Markierung gemäß Spalte 28 wird insbesondere im anonymen Modus ignoriert. Ein erster Bereichsnachweis RI nach Spalte 27a muss beispielsweise erbracht werden, um zu zeigen, dass kein monetärer Betrag negativ ist. Ein zweiter Bereichsnachweis R2 in Spalte 27b ist nicht nötig, da die monetären Teilbeträge der Nachfolger stets kleiner als der monetäre Ausgangsbetrag des Vorgängers sind. Ein Summenbereichsnachweis R3 in Spalte 27c ist ebenfalls in der Regel nicht erforderlich (keine neuen monetären Beträge). Die Spalte 24 wird zum Einträgen einer den Münzdatensatz aufteilenden Teilnehmereinheit TE erzeugten Signatur verwendet.
Eine Verarbeitung ist beispielsweise „Verbinden“. Das Verbinden, also das Zusammenfügen zweier elektronischer Münzdatensätze Zi und Zj zu einem elektronischen Münzdatensatz Zm erfolgt zunächst in der Direkttransaktionsschicht 3, so wie es in Figuren 10 und 11 noch gezeigt wird, wobei der monetäre Betrag um und der Verschleierungsbetrag rm berechnet werden. In dem Münzregister 2 und/oder dem Überwachungsregister 6 werden die Markierungen 25 bis 28 gesetzt, die Vorgängerspalte 22a wird mit dem elektronischen Münzdatensatz Zi beschrieben, Vorgängerspalte 22b wird mit Zj und Nachfolgerspalte 23b wird mit Zm beschrieben. Die Markierungen in den Spalten 25 bis 28 benötigen Statusänderungen und das Münzregister 2 und/oder das Überwachungsregister 6 führt die entsprechenden Prüfungen durch. Ein erster Bereichsnachweis RI nach Spalte 27a muss erbracht werden, um zu zeigen, dass kein neues Geld generiert wurde. Ein zweiter Bereichsnachweis R2 in Spalte 27b ist sinnvoll, da der neue monetäre Betrag des Nachfolgers größer sein könnte als ein Maximalwert. Ein Summenbereichsnachweis R3 in Spalte 27c ist ebenfalls in der Regel sinnvoll, da das Endgerät neu empfangene Vorgänger nutzen könnte. Die Markierung gemäß Spalte 28 kann ignoriert werden. Die Spalte 24 wird zum Einträgen einer den Münzdatensatz verbindenden Teilnehmereinheit TE erzeugten Signatur verwendet.
Eine weitere Verarbeitung ist beispielsweise „Umschalten“. Das Umschalten ist dann nötig, wenn ein elektronischer Münzdatensatz auf eine andere Teilnehmereinheit TE übertragen wurde und ein erneutes Ausgeben durch die übertragende Teilnehmereinheit TE ausgeschlossen werden soll. Beim Umschalten, auch „switch“ genannt, wird der von der ersten Teilnehmereinheit TE1 erhaltene elektronische Münzdatensatz Ck gegen einen neuen elektronischen Münzdatensatz Ci mit gleichem monetärem Betrag ausgetauscht. Der neue elektronische Münzdatensatz Ci wird von der zweiten Teilnehmereinheit TE2 generiert. Dieses Umschalten ist notwendig, um den von der ersten Teilnehmereinheit TE2 erhaltenen elektronischen Münzdatensatz Ck zu invalideren (ungültig machen), wodurch ein erneutes Ausgeben des gleichen elektronischen Münzdatensatzes Ck vermieden wird. Denn, solange der elektronische Münzdatensatz Ck nicht umgeschaltet ist, kann - da die erste Teilnehmereinheit TE1 in Kenntnis des elektronischen Münzdatensatzes Ck ist - die erste Teilnehmereinheit TE1 diesen elektronischen Münzdatensatz Ck an eine drittes Teilnehmereinheit TE weitergeben. Das Umschalten erfolgt beispielsweise durch Hinzufügen eines neuen Verschleierungsbetrags radd zum Verschleierungsbetrag rk des erhaltenen elektronischen Münzdatensatz Ck, wodurch ein Verschleierungsbetrag n erhalten wird, die nur die zweite Teilnehmereinheit TE2 kennt. Dies kann auch in dem Münzregister 2 oder dem Überwachungsregister 6 erfolgen. Um zu beweisen, dass nur ein neuer Verschleierungsbetrag radd zum Verschleierungsbetrag rk des maskierten erhaltenen elektronischen Münzdatensatzes Zk hinzugefügt wurde, der monetäre Betrag aber gleichgeblieben ist, und also Gleichung (11):
Vk = (11) gilt, so muss die zweite Teilnehmereinheit TE2 nachweisen können, dass sich Zi-Zk als skalares Vielfaches von G also als radd*G darstellen lässt. Das heißt, dass nur ein Verschleierungsbetrag radd erzeugt wurde und der monetäre Betrag von Zi gleich dem monetären Betrag von Zk ist, also Zi=Zk+ radd*G. Dies erfolgt durch das Erzeugen einer Signatur mit dem öffentlichen Schlüssel Zi- Zk — radd*G.
Die Modifikationen „Aufteilen“ und „Verbinden“ an einem elektronischen Münzdatensatz können auch von einer Teilnehmereinheit TE1 an eine andere Teilnehmereinheit TE delegiert werden, beispielsweise wenn eine Kommunikationsverbindung zu dem Münzregister 2 und/oder zu dem Überwachungsregister 6 nicht vorhanden ist.
In Fig. 9 ist ein Ausführungsbeispiel eines Bezahlsystems BZ gemäß der Erfindung zu den Aktionen „Aufteilen“, „Verbinden“ und „Umschalten“ von elektronischen Münzdatensätzen C gezeigt. In Fig. 9 hat die erste Teilnehmereinheit TE1 den Münzdatensatz Ci erhalten und möchte nun eine Bezahltransaktion nicht mit dem gesamten monetären Betrag Ui, sondern nur mit einem Teilbetrag Vk durchführen. Dazu wird der Münzdatensatz Ci aufgeteilt. Dazu wird zunächst der monetäre Betrag geteilt:
V, = Vj + Ok (12)
Dabei muss jeder der erhaltenen Beträge Uj, Uk, größer 0 sein, denn negative monetäre Beträge sind nicht zulässig.
In einer bevorzugten Ausgestaltung erfolgt eine symmetrische Aufteilung des monetären Betrags Ui in eine Anzahl n aus gleichgroßen monetäre Teilbeträge Uj.
Vj = / n (12a)
Die Anzahl n ist dabei eine Ganzzahl größer gleich zwei. Beispielsweise kann ein monetärer Betrag von 10 Einheiten in 2 Teilbeträge von 5 Einheiten (n=2) oder in 5 Teilbeträge von jeweils 2 Einheiten (n=5) oder 10 Teilbeträge von jeweils einer Einheit (n=10) aufgeteilt werden.
Zudem werden neue Verschleierungsbeträge abgeleitet:
Wenn symmetrisch aufgeteilt wird, wird für jeden Münzteilbetrag ein individueller, einzigartiger Verschleierungsbetrag h in der Teilnehmereinheit TE1 gebildet, wobei die Summe der Anzahl n von Verschleierungsbeträgen h der Münzteildatensätze gleich dem Verschleierungsbetrag r, des aufgeteilten Münzdatensatz ist: r = l = rj_ (13a) Es gilt insbesondere, dass der letzte Verschleierungsteilbetrag h_h gleich der Differenz des Verschleierungsbetrags n und der Summer der restlichen Verschleierungsteilbeträge ist:
Auf diese Weise können die Verschleierungsbeträge h_i bis r, n-i beliebig gewählt werden und die Vorschrift der Gleichung (13a) wird durch entsprechende Berechnung des „letzten“ individuellen Verschleierungsbetrags h_h erfüllt.
Bei einem asymmetrischen Aufteilen werden maskierte Münzdatensätze Zj und Zk gemäß Gleichung (3) aus den Münzdatensätzen und Ck erhalten und in dem Münzregister 2 und/oder dem Überwachungsregister 6 registriert. Für das Aufteilen werden die Vorgängerspalte 22a mit dem Münzdatensatz Zi, die Nachfolgerspalte 23a mit Zj und die Nachfolgerspalte 23b mit Zk beschrieben. Zusätzliche Informationen für den Bereichsnachweis (zero-knowledge-proof) sind zu generieren. Die Markierungen in den Spalten 25 bis 27 benötigen Statusänderung und das sMünzregister 2 und/oder das Überwachungsregister 6 führt die entsprechenden Prüfungen durch. Die Markierung gemäß Spalte 28 und der Stauts gemäß Spalte 29 werden ignoriert.
Bei einem symmetrischen Aufteilen wird in der jeweiligen Teilnehmereinheit TE eine Signatur berechnet. Dazu wird für den k-te Münzteildatensatz Q k der folgende Signaturschlüssel sig verwendet: sig = r, - n rj-k (13c)
Dabei ist n die Anzahl der symmetrisch geteilten Münzteildatensätze. Bei einem symmetrischen Aufteilen kann die Signatur des k-ten Münzteildatensatz k gemäß (13c) mit folgendem Verifikationsschlüssel Sig geprüft werden:
Sig = Zt n Zj _k (i3d)
Dabei ist Zj k der maskierte k-te Münzteildatensatz und n ist die Anzahl der symmetrisch geteilten Münzteildatensätze. Diese Vereinfachung ergibt sich aus dem Zusammenhang mit Gleichung (3):
Zi - n · Zj = (Oi- n Vj_k)-H + fr,- n rjjJ-G wobei durch die Symmetrieeigenschaften der Aufteilung gilt:
(Oi- n - Vj-k)-H = 0 sodass die Gleichung 13e vereinfacht wird zu: Z, n Zjj = (r, - n rj J-G
(13g)
Die Vereinfachung aufgrund Gleichung 13f ermöglicht den kompletten Verzicht auf Zero- Knowledge-Nachweise, wodurch die Anwendung einer symmetrischen Aufteilung enorm Rechenleistung und Datenvolumen einspart.
Dann wird ein Münzteildatensatz, hier Ck von der ersten Teilnehmereinheit TE1 an die zweite Teilnehmereinheit TE2 übertragen. Um ein doppeltes Ausgeben zu verhindern, ist eine Umschalt- Operation sinnvoll, um den von der ersten Teilnehmereinheit TE1 erhaltenen elektronischen Münzdatensatz Ck gegen einen neuen elektronischen Münzdatensatz Ci mit gleichem monetären Betrag auszutauschen. Der neue elektronische Münzdatensatz Ci wird von der zweiten Teilnehmereinheit TE2 generiert. Dabei wird der monetäre Betrag des Münzdatensatzes Ci übernommen und nicht verändert, siehe Gleichung (11).
Dann wird gemäß Gleichung (14) ein neuer Verschleierungsbetrag raddzum Verschleierungsbetrag rk des erhaltenen elektronischen Münzdatensatz Ck hinzugefügt, wodurch ein Verschleierungsbetrag n erhalten wird, die nur die zweite Teilnehmereinheit TE2 kennt. Um zu beweisen, dass nur ein neuer Verschleierungsbetrag radd zum Verschleierungsbetrag rk des erhaltenen elektronischen Münzdatensatz Zk hinzugefügt wurde, der monetäre Betrag aber gleichgeblieben ist (uk = ui ), muss die zweite Teilnehmereinheit TE2 nachweisen können, dass sich Zi-Zk als Vielfaches von G darstellen lässt. Dies erfolgt mittels öffentlicher Signatur Radd gemäß Gleichung (15):
Radd r add ' G (15)
Zi- Zk=(vi-Vk) *H+(rk+radd-rk) *G wobei G der Generatorpunkt der ECC ist. Dann wird der umzuschaltende Münzdatensatz Ci maskiert mittels der Gleichung (3), um den maskierten Münzdatensatz Z\ zu erhalten. In dem Münzregister 2 und/oder dem Überwachungsregister 6 kann dann die private Signatur radd genutzt werden um beispielsweise den maskierten umzuschaltenden elektronischen Münzdatensatz Z\ zu signieren, was als Beweis gilt, dass die zweite Teilnehmereinheit TE2 nur ein Verschleierungsbetrag radd zum maskierten elektronischen Münzdatensatz hinzugefügt hat und keinen zusätzlichen monetären Wert, d.h. vi = Vk.
Der Beweis lautet wie folgt:
Zk = Vk H + G (16) Die Fig. 10 zeigt ein Ausführungsbeispiel eines Bezahlsystems gemäß der Erfindung zum Verbinden (auch Kombinieren genannt) von elektronischen Münzdatensätzen. Dabei werden in der zweiten Teilnehmereinheit TE2 die beiden Münzdatensätze Ci und erhalten. In Anlehnung an das Aufteilen gemäß Fig. 9 wird nun ein neuer Münzdatensatz Zm erhalten, indem sowohl die monetären Beträge als auch der Verschleierungsbetrag der beiden Münzdatensätze Ci und addiert werden. Dann wird der erhaltene zu verbindende Münzdatensatz Cm maskiert und der maskierte Münzdatensatz Zm wird in dem Münzregister 2 registriert. Sodann wird beim „Verbinden“ die Signatur der zweiten Teilnehmereinheit TE2 eingetragen, da dieses die Münzdatensätze Ci und erhalten hat.
Bei einem Kombinieren durch das Bezahlsystem BZ wird der höchste der beiden einzelnen Prüfwert der jeweiligen elektronischen Münzteildatensätze Ci und bestimmt. Dieser höchste Prüfwert wird als der Prüfwert Ci und des kombinierten elektronischen Münzdatensatzes übernommen.
Alternativ wird beim Kombinieren (= Verbinden) durch ein Bezahlsystem BZ ein neuer Prüfwert aus der Summe aller Prüfwerte der elektronischen Münzteildatensätzen Ci und geteilt durch das Produkt der Anzahl (hier zwei) der Münzteildatensätze Ci und mit einem konstanten Korrekturwert bestimmt. Der Korrekturwert ist bezahl System weit konstant. Der Korrekturwert ist größer gleich 1. Bevorzugt ist der Korrekturwert von einer maximalen Abweichung der einzelnen Prüfwerte der elektronischen Münzteildatensätze Ci und oder von einem maximalen Prüfwert einer der elektronischen Münzteildatensätze Ci und abhängig. Weiter bevorzugt ist der Korrekturwert kleiner gleich 2. Dieser neue Prüfwert wird als der Prüfwert des kombinierten elektronischen Münzdatensatzes Cm übernommen.
In den Figuren 11 und 12 ist jeweils ein Ausführungsbeispiel eines Verfahrensablaufdiagramms eines Verfahrens 100. Nachfolgend werden die Figuren 11 und 12 gemeinsam erläutert. In den optionalen Schritten 101 und 102 wird ein Münzdatensatz angefragt und seitens der Herausgeberinstanz 1 der ersten Teilnehmereinheit TE1 nach Erstellen des elektronischen Münzdatensatzes bereitgestellt. Ein signierter maskierter elektronischer Münzdatensatz wird im Schritt 103 an das Münzregister 2 und/oder das Überwachungsregister 6 gesendet. Im Schritt 103 erfolgt ein Maskieren des erhaltenen elektronischen Münzdatensatzes Ci gemäß der Gleichung (3) und ein Signieren im Schritt 103p gemäß Gleichung (3a). Dann wird im Schritt 104 der maskierte elektronische Münzdatensatz Zi in dem Münzregister 2 bzw. dem Überwachungsregister 6 registriert. Optional kann die Teilnehmereinheit TE1 den erhaltenen elektronischen Münzdatensatz umschalten, dann würde eine Signatur Si in dem Münzregister 2 bzw. dem Überwachungsregister 6 eingetragen. 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 eine Validitäts-Prüfung mit vorheriger Maskierung, bei der im Gutfall das Münzregister 2 und/oder das Überwachungsregister 6 die Gültigkeit des Münzdatensatzes Zi bzw. Ci bestätigt wird.
Im optionalen Schritt 108 erfolgt dann 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 v/,- des übertragenen Münzdatensatzes Ck als „neuer“ monetärer Betrag verwendet. Zudem wird, wie bereits mit Gleichungen (14) bis (17) erläutert, der 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 wird der maskierte Münzdatensatz signiert und der signierte maskierte umzuschaltende Münzdatensatz Zi an das Münzregister 2 und/oder das Überwachungsregister 6 gesendet und das Umschalten von Ck auf Ci beauftragt. Zudem wird eine Signatur Sk von der ersten Teilnehmereinheit TE1 oder der zweiten Teilnehmereinheit TE2 erstellt und in dem Münzregister 2 und/oder dem Überwachungsregister 6 hinterlegt. Zudem oder alternativ könnte auch eine Signatur Si erstellt und in dem Münzregister 2 und/oder Überwachungsregister 6 hinterlegt werden, wenn sendende Teilnehmereinheiten TE anstelle empfangende Teilnehmereinheiten TE registriert würden.
Im Schritt 108‘ erfolgt die entsprechende Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6. Dabei wird Zk in die Spalte 22a gemäß Tabelle in Fig. 8 eingetragen und in Spalte 23b der umzuschreibende Münzdatensatz Zi. Es erfolgt sodann eine Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6, 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, 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, ansonsten auf „0“. Nun erfolgt eine Prüfung, die Berechnung gemäß Gleichung (10) ergibt, dass Zk und Zigültig 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. Dann wird die Signatur Si mit dem entsprechend in dem Münzregister 2 und/oder dem Überwachungsregister 6 vorhandenen öffentlichen Verifikationsschlüssel verifiziert und entsprechend protokolliert. Wenn alle Prüfungen erfolgreich waren, und dies entsprechend unveränderlich in dem Münzregister 2 und/oder dem Überwachungsregister 6 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. Beim Prüfen der Signatur kann im pseudonymen Modus 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. Wenn der Grenzwert überschritten ist, verweigert das Münzregister 2 und/oder das Überwachungsregister 6 zunächst das Umschalten des Münzdatensatzes Ci und fordert die zweite Teilnehmereinheit TE2 auf, sich zu deanonymisieren. Systembedingt ist ein deanonymisiertes Umschalten möglicherweise gestattet.
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 um aus den beiden monetären Beträgen Uk und Ui gebildet. Dazu wird der Verschleierungsbetrag rm aus den beiden Verschleierungsbeträgen rk und r, gebildet. Zudem wird mittels Gleichung (3) der maskierte zu verbindende Münzdatensatz Zm erhalten und dieser (mit anderen Informationen zusammen) an das Überwachungsregister 6 und/oder 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.
Im Schritt 109‘ erfolgt die entsprechende Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6. Dabei wird Zm in die Spalte 23b gemäß Tabelle in Fig. 2 eingetragen, was auch gleich einer Umschreibung. Es erfolgt sodann eine Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6, 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, 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, ansonsten auf „0“. Nun erfolgt eine Prüfung, die Berechnung gemäß Gleichung (10) ergibt, 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. 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. Wenn der Grenzwert überschritten ist, verweigert das Münzregister 2 und/oder das Überwachungsregister 6 zunächst das Verbinden des Münzdatensatzes Cm und fordert die zweite Teilnehmereinheit TE2 auf, sich zu deanonymisieren. Ein deanonymisiertes Verbinden ist dann möglicherweise gestattet.
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 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 r, in die beiden Verschleierungsbeträge rk und r, aufgeteilt. Zudem werden mittels Gleichung (3) die maskierten Münzteildatensätze Zkund Zj erhalten und diese mit weiteren Informationen, beispielsweise den Bereichsprüfungen (Zero-knowledge-proofs), an das Münzregister 2 und/oder das Überwachungsregister 6 gesendet und das Aufteilen als Verarbeitung erbeten. Zudem wird eine Signatur Si erstellt und an das Münzregister 2 und/oder an das Überwachungsregister 6 gesendet.
Im Schritt 110‘ erfolgt die entsprechende Prüfung in dem Münzregister 2 und/oder dem Überwachungsregister 6. Dabei werden Zj und Zk in die Spalten 23a/b gemäß Tabelle in Fig. 2 eingetragen. Es erfolgt sodann eine Prüfung in dem Überwachungsregister 6 und/oder 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. Wenn der Grenzwert überschritten ist, verweigert das Münzregister 2 und/oder das Überwachungsregister 6 zunächst das Aufteilen des Münzdatensatzes Ci und fordert die zweite Teilnehmereinheit TE2 auf, sich zu deanonymisieren. Ein deanonymisiertes Aufteilen ist dann möglicherweise gestattet.
In der Fig. 13 ist ein Ausführungsbeispiel einer erfindungsgemäßen ersten Teilnehmereinheit TElgezeigt. Die erste Teilnehmereinheit TE1 kann ein Gerät Ml sein, in dem ein Sicherheitselement SEI eingebracht ist. Zur Vereinfachung wird nachfolgend der Begriff Gerät Ml verwendet. Im Gerät Ml kann elektronische Münzdatensätze Ci in einem Datenspeicher 10, 10‘ ablegen. Dabei können die elektronischen Münzdatensätze Ci auf dem Datenspeicher 10 des Geräts Ml liegen oder in einem externen Datenspeicher 10‘ verfügbar sein. Bei Verwenden eines externen Datenspeichers 10‘ könnten die elektronischen Münzdatensätze Ci in einem Online- Speicher abgelegt sein, beispielsweise einem Datenspeicher 10‘ eines Anbieters für digitale Geldbörsen. Zusätzlich könnten auch private Datenspeicher, bspw. ein Network- Attached- Storage, NAS in einem privaten Netzwerk verwendet werden.
In einem Fall ist der elektronische Münzdatensatz Ci als ein Ausdruck auf Papier dargestellt. Dabei kann der elektronische Münzdatensatz durch einen QR-Code, ein Bild eines QR-Codes dargestellt werden, oder aber auch eine Datei oder eine Zeichenfolge (ASCII) sein.
Das Gerät Ml hat mindestens eine Schnittstelle 12 als Kommunikationskanal zum Ausgeben des Münzdatensatzes Ci zur Verfügung. Diese Schnittstelle 12 ist beispielsweise eine optische Schnittstelle, beispielsweise zum Darstellen des Münzdatensatzes Ci auf einem Anzeigeeinheit (Display), oder einen Drucker zum Ausdrucken des elektronischen Münzdatensatzes Ci als Papier- Ausdruck. Diese Schnittstelle 12 kann auch eine digitale Kommunikationsschnittstelle, beispielsweise für Nahfeldkommunikation, wie NFC, Bluetooth, oder eine Intemetfähige Schnittstelle, wie TCP, IP, UDP, HTTP oder ein Zugriff auf eine Chipkarte als Sicherheitselement sein. Diese Schnittstelle 12 ist beispielsweise eine Datenschnittstelle, sodass der Münzdatensatz Ci über eine Applikation, beispielsweise einem Instant-Messenger-Dienst oder als Datei oder als Zeichenfolge zwischen Geräten übertragen wird.
Zudem ist die Schnittstelle 12 oder eine weitere Schnittstelle (nicht dargestellt) des Geräts Ml dazu eingerichtet, mit dem Münzregister 4 zu interagieren. Das Gerät Ml ist dazu bevorzugt onlinefähig.
Darüber hinaus kann das Gerät Ml auch eine Schnittstelle zum Empfang von elektronischen Münzdatensätzen aufweisen. Diese Schnittstelle ist eingerichtet visuell präsentierte Münzdatensätze, beispielsweise mittels Erfassungsmodul wie Kamera oder Scanner, oder digital präsentierte Münzdatensätze, empfangen via NFC, Bluetooth, TCP, IP, UDP, HTTP oder mittels einer Applikation präsentierte Münzdatensätze zu empfangen.
Das Gerät Ml umfasst auch eine Recheneinheit 13, die das oben beschriebene Verfahren zum Maskieren von Münzdatensätzen und die Verarbeitungen an Münzdatensätzen durchführen kann.
Das Gerät Ml ist onlinefähig und kann bevorzugt mittels eines Standorterkennungs-Moduls 15 erkennen, wenn es mit einem WLAN verbunden ist. Optional kann ein spezifisches WLAN-Netz als bevorzugt markiert sein (=Standortzone), sodass das Gerät Ml besondere Funktionen nur ausführt, wenn es in diesem WLAN-Netz angemeldet ist. Alternativ erkennt das Standorterkennungs-Modul 15, wenn das Gerät Ml in vordefinierten GPS-Koordinaten inklusive eines definierten Radius ist und führt die besonderen Funktionen entsprechend der so definierten Standortzone durch. Diese Standortzone kann entweder manuell in das Gerät Ml oder via andere Einheiten/Module in das Gerät Ml eingebracht werden. Die besonderen Funktionen, die das Gerät Ml bei Erkennen der Standortzone durchführt, sind insbesondere das Übertragen von elektronischen Münzdatensätzen von/zum externen Datenspeicher 10 von/zu einem Tresormodul 14 und ggf. das Übertragen maskierter Münzdatensätze Z an das Münzregister 4 und/oder das Überwachungsregister 6, beispielsweise im Rahmen von den o.g. Verarbeitungen an einem Münzdatensatz. Das Gerät Ml ist demnach dazu eingerichtet, das Verfahren gemäß Fig. 3 auszuführen. Das Gerät Ml ist dazu eingerichtet, einen Transaktionsdatensatz TDS zu erstellen und zu verschlüsseln. Das Gerät Ml ist dazu eingerichtet eine Kommunikation zu einem Transaktionsregister zu initiieren. Das Gerät Ml ist dazu eingerichtet den verschlüsselten Transaktionsdatensatz TDS an das Transaktionsregister zu versenden. Das Gerät Ml ist dazu eingerichtet, an den Transaktionsdatensatz TDS Metadaten (im Klartext) anzuknüpfen. Das Gerät Ml ist dazu eingerichtet, den Transaktionsdatensatz TDS lokal (zwischen-) zu speichern.
Im einfachsten Fall werden im Gerät Ml alle Münzdatensätze Ci nach Erhalt automatisch zu einem Münzdatensatz verbunden (siehe Verbinden-Verarbeitung bzw. Verbinden-Schritt). Das heißt, sobald ein neuer elektronischer Münzdatensatz empfangen wird, wird ein Verbinden bzw. Umschalten-Befehl an das Münzregister 4 gesendet. Das Gerät Ml kann elektronische Münzdatensätze auch in algorithmisch festgelegten Denominationen vorbereiten und im Datenspeicher 10, 10‘ Vorhalten, damit auch ohne Datenverbindung zum Münzregister 4 und/oder Überwachungsregister 6 ein Bezahlvorgang möglich ist.
In Fig. 14 ist ein Bezahlsystem zum besseren Verständnis dargestellt. Das erfindungsgemäße Gesamtsystem umfasst eine Herausgeberinstanz (Zentralbank) la. Zudem können weitere Herausgeberinstanzen lb, lc vorgesehen sein, die beispielsweise elektronische Münzdatensätze in einer anderen Währung ausgeben. Zudem ist mindestens ein Bezahlsystem BZ dargestellt, in dem mindestens ein Münzregister 2, ein Überwachungsregister 6 und ein Transaktionsregister 4 des Bezahlsystems BZ vorgesehen sind, um eine Registrierung der Münzdatensätze Ci bzw. Zi vorzunehmen und die Modifikationen am Münzdatensatz Ci zu prüfen und zu protokollieren. Die Herausgeberinstanz la kann auch als Teil des Bezahlsystems BZ vorgesehen sein. Zudem können Bankinstanz(en) zwischen der Herausgeberinstanzen la-c und den Bezahlsystem BZ angeordnet sein. Die Register 2, 4, 6 sind beispielsweise in einer Serverinstanz zusammen untergebracht und dort logisch voneinander getrennt. Alternativ sind die Register 2, 4, 6 auch räumlich/physisch voneinander getrennt. Das Transaktionsregister 4 kann auch als eine zum Bezahlsystem BZ externe Einheit angeordnet sein. Zudem ist eine richterliche/gerichtliche Behörde 9 gezeigt, die bei einem Betrugsverdacht eine richterliche Anfrage zum Entschlüsseln von verschlüsselten Transaktionsdatensätzen TDS beim Bezahlsystem BZ (oder direkt dem Transaktionsregister) anfragt. Entfernte Instanzen 8a-c mit entsprechenden Teilschlüsseln sind ebenfalls dargestellt, um im Fall einer Anfrage, ihre Teilschlüssel dem Transaktionsregister 4 zur Verfügung zu stellen, damit ein kryptografi scher Schlüssel als Entschlüsselungsschlüssel erhalten wird.
Zudem ist in der Fig. 14 eine Vielzahl von Teilnehmern, die als Endgeräte Mx (mit jeweiligen SEx) dargestellt sind, vorgesehen. Die Endgeräte Ml bis M6 können Münzdatensätze Ci in der Direkttransaktionsschicht 3 direkt austauschen. Beispielsweise überträgt das Endgerät M5 einen Münzdatensatz an das Endgerät M4. Beispielsweise überträgt das Endgerät M4 den Münzdatensatz an das Endgerät M3. Beispielsweise überträgt das Endgerät M6 einen Münzdatensatz an das Endgerät Ml. In jedem sendenden Endgerät Mx bzw. jedem empfangenden Endgerät Mx wird der Prüfwert pn des zu sendenden bzw. zu empfangenden Münzdatensatzes und ggf. der Zählerwert p verwendet, um zu prüfen, ob der Münzdatensatz beim Bezahlsystem angezeigt wird und/oder ob der Münzdatensatz bei der Herausgeberinstanz la zurückzugeben ist. Das Bezahlsystem BZ prüft beispielsweise anhand des Prüfwerts pn bzw. eines vom Prüfwert pn abgeleiteten Zählerwertes p für jeden Münzdatensatz C, ob der Münzdatensatz C zurückzugeben ist oder nicht. Zudem ist ein Prüfwert in jedem Endgerät Mx vorgesehen, um eine Anzahl von noch nicht gesendeten Transaktionsdatensätzen TDS trotz übertragener Münzdatensätze zu überwachen.
In Fig. 15 ist ein Ablaufschema eines Verfahrens gezeigt, mit dem beispielsweise das Einhalten eines Grenzwertes für monetäre Beträge pro Zeiteinheit ermöglicht wird.
Im oberen Teil der Figur ist das Bezahlsystem BZ bestehend aus drei Endgeräten Ml, M2, M3 gezeigt. Im unteren Teil der Figur sind drei Datenstrukturen 910, 920, 930 der jeweiligen Register 2, 4, 6 gezeigt. In der Datenstruktur 910 des Münzregister 2 sind die gültigen maskierten Münzdatensätze Zi gespeichert. Die Datenstruktur 920 des Überwachungsregisters 6 umfasst die Zuordnung pseudonym gesendeter maskierten Münzdatensätze zu dem Pseudonym und von kann als Überwachungsregister 6 noch zu prüfender pseudonym gesendeter Münzdatensätze betrachtet werden. Anhand der Daten in der Datenstruktur 920 kann das Überwachungsregister 6 entscheiden, ob für ein Pseudonym ein Bereichsnachweis angefordert wird. In der Datenstruktur 930 des Transaktionsregisters sind verschlüsselte Transaktionsdatensätze TDS abgelegt.
Folgende Transaktionen wurden durchgeführt:
1. Das erste Endgerät Ml hat eine Münze aufgeteilt 901. Das Münzregister 2 weiß daher, dass die Münze Ci ein Ergebnis dieser Aufteilung ist und speichert den maskierten Münzdatensatz Zi in der Datenstruktur 910. Das erste Endgerät Ml könnte die Aufteilung dem Überwachungsregister 6 anonym oder pseudonym senden. In der Darstellung wird davon ausgegangen, dass die Endgeräte Ml und M3 ihre maskierten Münzdatensätze anonym an das Überwachungsregister 6 senden. 2. Das erste Endgerät Ml sendet die Münze Ci direkt an das zweite Endgerät M2 in einem direkten Übertragungsschritt 902. Weder das Münzregister 2 noch das Überwachungsregister 6 erhalten hierüber eine Informationen. Das erste Endgerät Ml erzeugt einen Transaktionsdatensatz TDS902 bezüglich des Übertragenschritts 902, verschlüsselt diesen Transaktionsdatensatz TDS902 und sendet diesen an das Transaktionsregister 4. Der verschlüsselte Transaktionsdatensatz TDS902 beinhaltet eine Kennung des ersten Endgeräts Ml, eine Kennung des zweiten Endgeräts M2 und den geldwerten Betrag ui der Münze Ci.
3. Das zweite Endgerät M2 wandelt die Münze Ci in die Münze C2 um (schaltet um) 903. In der Datenstruktur 910 des Münzregister 2 wird der neue maskierte Münzdatensatz Z2 gespeichert und der alte maskierte Münzdatensatz Zi gelöscht (bzw. als ungültig markiert). Das zweite Endgerät M2 sendet seine maskierten (oder zumindest die dargestellten) Münzdatensätze pseudonymisiert an das Überwachungsregister 6. Somit erhält das Überwachungsregister 6 zudem die Information, dass das zweite Endgerät M2 mit dem Pseudonym PM2 die Münze Ci empfangen hat (und nun Münze C2 besitzt) und speichert entsprechend in der Datenstruktur 920 des Überwachungsregisters 6 den maskierten Münzdatensatz Z2 (und/oder den maskierten Münzdatensatz Zi) für PM2. Zudem wird das Überwachungsregister 6 mindestens einen Prüfungsschritt, wie einen Bereichsnachweis für den Münzdatensatz Z2 oder einen Summenbereichsnachweis für das Endgerät M2, überspringen.
4. Das zweite Endgerät M2 sendet die Münze C2 in einem weiteren direkten Übertragungsschritt 905 an das dritte Endgerät M3. Weder das Münzregister 2 noch das Überwachungsregister 6 erhalten hierüber eine Informationen. Das zweite Endgerät M2 erzeugt einen Transaktionsdatensatz TDS905 bezüglich des Übertragenschritts 905, verschlüsselt diesen Transaktionsdatensatz TDS905 und sendet diesen an das Transaktionsregister 4. Der verschlüsselte Transaktionsdatensatz TDS905 beinhaltet eine Kennung des zweiten Endgeräts M2, eine Kennung des dritten Endgeräts M3 und den geldwerten Betrag 02 der Münze C2.
5. Das dritte Endgerät M3 verbindet im Schritt 904 die empfangene Münze C2 zur verbundenen Münze C3 und sendet diese Information mit anonymen maskierten Münzdatensätzen an das Münzregister 2. Das Münzregister 2 führt alle Prüfungsschritte aus, also insbesondere alle Bereichsnachweise für die beteiligten maskierten Münzdatensätze Z2 ... und Z3 oder auch einen Summenbereichsnachweis für das dritte Endgerät M3. Das Münzregister 2 löscht erst danach den maskierten Münzdatensatz Z2 (sowie die anderen Münzdatensätze des Vorgangs) aus der Datenstruktur 910 und speichert den neuen maskierten Münzdatensatz Z3 als gültigen maskierten Münzdatensatz ab. 6. Das dritte Endgerät M3 sendet im Schritt 906 die Münze C3 direkt an das zweite Endgerät M2. Weder das Münzregister 2 noch das Überwachungsregister 6 erhalten hierüber eine Informationen. Das dritte Endgerät M3 erzeugt einen Transaktionsdatensatz TDS906 bezüglich des Übertragenschritts 906, verschlüsselt diesen Transaktionsdatensatz TDS906 und sendet diesen an das Transaktionsregister 4. Der verschlüsselte Transaktionsdatensatz TDS906 beinhaltet eine Kennung des dritten Endgeräts M3, eine Kennung des zweiten Endgeräts M2 und den geldwerten Betrag 03 der Münze C3.
7. Das zweite Endgerät M2 wandelt in einem weiteren Schritt 903 die Münze C3 in die Münze C4 um (umschalten) und sendet einen maskierten Münzdatensatz Z4 zusammen mit seinem Pseudonym an das Überwachungsregister 6. Das Überwachungsregister 6 erhält die Information führt die notwendigen Prüfungen aus. Mit Hilfe der Datenstruktur 920 bestimmt das Überwachungsregister 6, ob nun für das Pseudonym des Endgerätes M2 eine oder mehrere Prüfungen nachgeholt werden sollen. Ist das Kriterium für ein Nachholen, wie Zeitablauf oder Anzahl an Transaktionen für ein Pseudonym, noch nicht erfüllt, vermerkt lediglich den weiteren maskierten Münzdatensatz Z4 für das Pseudonym in der Datenstruktur 920 des Überwachungsregisters 6. Das Münzregister 2 speichert den maskierten Münzdatensatz Z4 in die Datenstruktur 910 und löscht dort den maskierten Münzdatensatz Z3. Ist ein Kriterium für einen nachholbaren Prüfungsschritt dagegen erfüllt, führt es dagegen zunächst den nachholbaren Prüfungsschritt aus (oder dessen Äquivalent).
Das Überwachungsregister 6 hat im konkreten Beispiel die Information, dass das zweite Endgerät M2 die Münze C2 hatte (siehe Schritt 3). Da die Summe der monetären Beträge von Münze C2 und Münze C4 einen Münzschwellwert überschreiten könnte, fordert das Überwachungsregister 6 von dem zweiten Endgerät M2 einen Summenbereichsnachweis (oder eine Summenbereichsbestätigung) an. Der Summenbereichsnachweis zeigt, dass die Summe der monetären Beträge der Münzen C2 und C4 noch nicht das - beispielsweise tägliche - Limit der Transaktionen für das zweite Endgerät M2 überschreitet. Das Überwachungsregister 6 kann auch ein Limit für eine zeitunabhängige Anzahl von Transaktionen überwachen (Bereichsnachweis nach 3/5/10/... Transaktionen). Alternativ oder zusätzlich zu einer Summenprüfung mehrerer Münzdatensätze kann das Überwachungsregister 6 eine Bereichsprüfung für die einzelnen Münzdatensätze nachholen, die in der Datenstruktur 920 des Überwachungsregisters 6 mit dem Pseudonym PM2 verknüpft sind (Ist der monetäre Betrag jedes Münzdatensatzes Z2 und Z4 kleiner als X?). Wurden Prüfungen erfolgreich nachgeholt, können auch die entsprechenden Datensätze in der Datenstruktur 920 des Überwachungsregisters 6 gelöscht werden.
Das Transaktionsregister 4 hat in seiner Datenstruktur 930 die Transaktionsdatensätze TDS902, TDS905 und TDS906 in verschlüsselter Form. In einer nicht gezeigten Ausgestaltung der Fig. 15 werden die Transaktionsdatensätze entschlüsselt und pseudonymisiert. Bei der Pseudonymisierung werden die Kennungen der Endgerät Ml bis M3 durch die Pseudonyme P ersetzt und der jeweilige Betrag wird in Betragskategorien umgesetzt. Die pseudonymisierten unverschlüsselten Transaktionsdatensätze werden an das Überwachungsregister 6 gesendet. Da die Summe der monetären Beträge von Münze C2 und Münze C4 einen Münzschwellwert überschreiten könnte, fordert das Überwachungsregister 6 von dem zweiten Endgerät M2 einen Summenbereichsnachweis (oder eine Summenbereichsbestätigung) an. Alternativ sind die Betragskategorien in den pseudonymisierten Transaktionsdatensätze TDS* derart aussagekräftig, dass das Überwachungsregister 6 den Summenbereichsnachweis anhand der pseudonymisierten Transaktionsdatensätze TDS* selbst durchführen kann. Alternativ oder zusätzlich zu einer Summenprüfung kann das Überwachungsregister 6 nun auch eine Bereichsprüfung für die einzelnen Münzdatensätze anhand der pseudonymisierten Transaktionsdatensätze TDS* nachholen.
In Fig. 16 ist ein weiteres Ausführungsbeispiel eines Ablaufs in einem Bezahlsystem BZ mit maskierten Münzdatensätzen gezeigt. Ein erstes Endgerät Ml sendet in Schritten 151 anonyme maskierte Münzdatensätze an das Münzregister 2. Ein zweites Endgerät M2 sendet dagegen in Schritten 161 pseudonymisierte maskierte Münzdatensätze an das Überwachungsregister 6.
Das Münzregister 2 reagiert auf jeden der anonymen Sendeschritte 151 des ersten Endgerätes Ml (in seinem anonymen Modus) mit einer (nachholbaren) Prüfung für den maskierten Münzdatensatz oder das erste Endgerät Ml. Die gegebenenfalls zusätzlichen, notwendigen Prüfungen sind in Fig. 11 nicht dargestellt. In Schritt 152 fordert das Münzregister 2 für jeden maskierten Münzdatensatz einen Bereichsnachweis, dass der monetäre Betrag des maskierten Münzdatensatzes aus dem Schritt 151 unter einem Maximalwert liegt (oder eine entsprechende Bereichsbestätigung). Alternativ oder zusätzlich fordert das Münzregister 2 mit Schritt 152 einen Summenbereichsnachweis (oder - bestätigung) von dem ersten Endgerät Ml. Den (oder die) angeforderten Nachweis(e) muss das erste Endgerät Ml in Schritt 153 erstellen und in Schritt 154 senden, damit der (mindestens eine) maskierte Münzdatensatz des Schrittes 151 in dem Münzregister 2 als gültig behandelt wird.
Das Überwachungsregister 6 reagiert auf den ersten Sendeschritte 161 des zweiten Endgerätes M2 (in seinem pseudonymen Modus) mit dem Überspringen einer (nachholbaren) Prüfung für den maskierten Münzdatensatz oder das zweite Endgerät M2. Der pseudonym gesendete maskierte Münzdatensatz wird als gültig registriert. Es erfolgen beispielsweise hier nicht dargestellte notwendige Prüfungen, die jedoch nicht eine weitere Kommunikation mit dem zweiten Endgerät M2 voraussetzen. Wie zuvor an anderen Beispielen beschrieben, speichert das das Überwachungsregister 6 eine Zuordnung zwischen dem Pseudonym und dem(/n) pseudonym gesendeten maskierten Münzdatensatz(-sätzen). In dem gezeigten Beispiel reagiert das Überwachungsregister 6 auch auf einen zweiten (oder weitere) Sendeschritte 161 des zweiten Endgerätes M2 analog. Sie prüft dabei jeweils für das Pseudonym, ob ein Nachholkriterium erfüllt ist.
Erst im dritten dargestellten Schritt 161 stellt das Überwachungsregister 6 fest, dass für das Pseudonym eine Prüfung nachgeholt werden soll. Es sendet eine Aufforderung 162 an das zweite Endgerät M2, beispielsweise Bereichsnachweise für mehrere Münzdatensätze oder eine Summenbereichsnachweis zu erstellen. In Schritt 163 erstellt das zweite Endgerät M2 mehrere Bereichsnachweise, eine Summenbereichsnachweis oder eine Summenbereichsbestätigung und sendet diese in Schritt 164 an das Überwachungsregister 6. Im Schritt 163 werden beispielsweise mehrere Münzdatensätze des zweiten Endgeräts M2 ausgewählt und über deren monetären Beträge eine Summe gebildet. Diese Münzdatensätze betreffen entweder nur pseudonymisierte Münzdatensätze oder anonyme und pseudonymisierte Münzdatensätze (hierbei wird auf die bereits versendeten maskierten Münzdatensätze abgestellt und die Summe wird aus den monetären Beträgen der korrespondierenden unmaskierten Münzdatensätzen gebildet). Die Auswahl kann anhand von Kriterien getroffen werden, die entweder systembedingt bekannt sind oder im Schritt 162 von dem Überwachungsregister 6 übertragen wurden. Die Kriterien sind beispielsweise ein Zeitraum, insbesondere eine vordefinierte Zeitspanne in der eine Summe aller monetären Beträge einen bestimmten Bereich nicht überschreiten sollten/dürfen, beispielsweise ein monetärere Betrag x Euro pro Zeiteinheit y. Das Kriterium kann alternativ oder zusätzlich auch eine Liste im ersten Endgerät Ml oder dem Überwachungsregister 6 sein. Damit wird eine gewisse Randomisierung des Bereichs möglich, mit der das System noch weiter abgesichert wird. Die gebildete Summe wird dann mit dem Bereich (und ggf. unter Anwendung des Kriteriums) abgeglichen. Im Schritt 164 wird die angeforderte Summenbereichsbestätigung (oder der angeforderte Summenbereichsnachweis) von dem zweiten Endgerät M2 an das Überwachungsregister 6 übertragen.
Da eine Bezahltransaktion (Übertragung von Münzdatensätzen) eines großen geldwerten Betrags auch in mehrere Bezahltransaktionen kleinerer geldwerter Beträge aufgeteilt werden kann, die jeweils unterhalb eines Bereichs liegen könnten, wird mit dem Verfahren der Bereich (=Grenzwert) gegebenenfalls endgerätspezifisch und zeitraumabhängig definiert. Der Bereich betrifft in der Regel eine Summe aller Transaktionen innerhalb einer bestimmten Zeiteinheit, die von einem Endgerät empfangen und/oder gesendet werden. Es wird daher ein Mechanismus geschaffen, mit dem festgestellt wird, wie hoch die Summe aller monetären Beträge, die von einem Endgerät gesendet oder empfangen wurden, innerhalb einer bestimmten Zeiteinheit ist.
Im Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/oder beanspruchten Elemente beliebig miteinander kombiniert werden. BEZUGSZEICHENLISTE
BZ Bezahlsystem
1, la-c Herausgeberinstanz oder Bank
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 Berechnungsprüfung
27 Markierung der Bereichsnachweisprüfung
28 Markierung der Signatur-Prüfung
29 Abschluss-Markierung
3 Direkttransaktionsschicht
4 Transaktionsregister
5 Applikation gemeinsame Geldbörse
6 Überwachungsregister
7 Zuordnung von Person zu Kennung 8a-c Teilschlüssel von entfernter Instanz 9 Gerichtliche Behörde
10, 10‘ Datenspeicher
11 Anzeige
12 Schnittstelle
13 Recheneinheit
14 Tresormodul
15 Standorterkennungs-Modul
Mx x-tes Gerät
Ci elektronischer Münzdatensatz
Q, Ck aufgeteilter elektronischer Münzteildatensatz,
Q k k-ter aufgeteilter elektronischer Münzteildatensatz bei symmetrischer Aufteilung
Ci umzuschaltender elektronischer Münzdatensatz
Cm zu verbindendender elektronischer Münzdatensatz
Zi maskierter elektronischer Münzdatensatz
Zj, Zk maskierter aufgeteilter elektronischer Münzteildatensatz
Zi maskierter umzuschaltender elektronischer Münzdatensatz
Zm maskierter zu verbindender elektronischer Münzdatensatz
S Signierter maskierter elektronischer Münzdatensatz
SEx x-tes Sicherheitselement
TEx x-te Teilnehmereinheit
TDS verschlüsselter Transaktionsdatensatz
TDS* Pseudonymisierter/anonymisierter Transaktionsdatensatz
Ui, Monetärer Betrag Dj, u. Aufgeteilter monetärer Betrag ui, Monetärer Betrag eines umzuschaltenden/umgeschalteten elektr. Münzdatensatzes
Um, Monetärer Betrag eines zu verbindenden/verbundenen elektr. Münzdatensatz pu, Prüfwert für Direktübertragung des Münzdatensatzes pu, Zählerwert für Alterung des Münzdatensatzes p Prüfwert für Transaktionsregister n Anzahl symmetrisch geteilter Münzteildatensätze n Verschleierungsbetrag, Zufallszahl h, h Verschleierungsbetrag eines aufgeteilten elektronischen Münzdatensatzes rm Verschleierungsbetrag eines zu verbindenden elektronischen Münzdatensatzes Ci* übertragener elektronischer Münzdatensatz *, Ck* übertragener aufgeteilter elektronischer Münzteildatensatz,
Zi* maskierter übertragener elektronischer Münzdatensatz
Zj*, Zk *maskierter übertragener aufgeteilter elektronischer Münzdatensatz f(C) Homomorphe Einwegfunktion
[Zi] Sig(PKi) Signatur der Herausgeberinstanz
101-110 Verfahrensschritte des Bezahlsystems gemäß einem Ausführungsbeispiel 301-310 Verfahrensschritte in der Teilnehmereinheit gemäß einem Ausführungsbeispiel 401-412 Verfahrensschritte in dem Transaktionsregister gemäß einem Ausführungsbeispiel

Claims

PATENTANSPRÜCHE
1. Ein Verfahren (300) in einer ersten Teilnehmereinheit (TE1), bevorzugt einem ersten Sicherheitselement (SEI), aufweisend einen elektronischen Münzdatensatz (C), der in einem Münzregister (2) eines Bezahlsystems (BZ) registriert ist (104), mit den Verfahrensschritten:
- Erzeugen (301) eines Transaktionsdatensatzes (TDS) bezüglich eines Übertragens (105) des elektronischen Münzdatensatzes (C) an eine zweite Teilnehmereinheit (TE2), bevorzugt ein zweites Sicherheitselement (SE2), oder bezüglich einer am Münzregister (2) zu registrierenden Modifikation des elektronischen Münzdatensatzes (C);
- Verschlüsseln (303) des erzeugten Transaktionsdatensatzes (TDS) mit einem kryptografischen Schlüssel (K), wobei der kryptografische Schlüssel (K) aus zumindest zwei kryptografischen Teilschlüsseln, bevorzugt mindestens drei kryptografischen Teilschlüsseln, jeweils verschiedener entfernter Instanzen (8a, 8b, 8c) zusammengesetzt ist; und
- Initiieren (304) einer Kommunikationsverbindung zu einem Transaktionsregister (4), um den verschlüsselten Transaktionsdatensatz (TDS) an das Transaktionsregister (4) zu senden.
2. Das Verfahren (300) nach Anspruch 1, wobei das erste Sicherheitselement (SEI) betriebsbereit in der ersten Teilnehmereinheit (TE1) eingebracht ist und bevorzugt das Erzeugen (301) und das Verschlüsseln (303) vom ersten Sicherheitselement (SEI) erfolgt.
3. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei die erste Teilnehmereinheit (TE1) den verschlüsselten Transaktionsdatensatz (TDS) an das Transaktionsregister (4) sendet (306).
4. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei der verschlüsselte Transaktionsdatensatz (TDS) kryptografisch transportgesichert an das Transaktionsregister (4) gesendet wird.
5. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei der Transaktionsdatensatz (TDS) zumindest aufweist:
- eine Kennung oder Adresse der ersten Teilnehmereinheit (TE1), und
- eine Kennung oder Adresse einer zweiten Teilnehmereinheit (TE2), und
- einen geldwerten Betrag (u) des elektronischen Münzdatensatzes (C).
6. Das Verfahren (300) nach Anspruch 5, wobei der Transaktionsdatensatz (TDS) weiter aufweist:
- eine Transaktionsnummer und/oder - einen maskierten elektronischen Münzdatensatz (Z) korrespondierend zu dem zu übertragenden oder einem zu modifizierenden oder einem modifizierten elektronischen Münzdatensatz (C), bevorzugt anstelle des geldwerten Betrags (u) des elektronischen Münzdatensatzes (C) und/oder
- einen Transaktionszeitpunkt.
7. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei die erste Teilnehmereinheit (TE1) einen Transaktionszeitpunkt dem verschlüsselten Transaktionsdatensatz (TDS) anfügt.
8. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei der verschlüsselte Transaktionsdatensatz (TDS) in der ersten Teilnehmereinheit (TE1) gespeichert wird (309), wenn der Kommunikationsverbindungsaufbau (304) zum Transaktionsregister (4) oder das Senden (306) des verschlüsselten Transaktionsdatensatzes (TDS) fehlschlägt (307).
9. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei der verschlüsselte Transaktionsdatensatz (TDS) von der ersten Teilnehmereinheit (TE1) an das Transaktionsregister (4) versendet wird, sobald der Kommunikationsverbindungsaufbau (304) mit dem Transaktionsregister (4) erfolgreich ist.
10. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei die erste Teilnehmereinheit (TE1) den elektronischen Münzdatensatz (C) an eine zweite Teilnehmereinheit (TE2) überträgt (105).
11. Das Verfahren (300) nach Anspruch 10, wobei der Schritt des Übertragens (105) unmittelbar vor oder nach dem Erzeugen-Schritt (301) oder dem Verschlüsseln-Schritt (303) oder dem Initiieren-Schritt (304) erfolgt.
12. Das Verfahren (300) nach Anspruch 10, wobei der Üb ertragen- Schritt (105) erst ausgeführt wird, wenn ein Prüfen-Schritt (308) ergibt, dass ein Prüfwert (p) für eine Anzahl von Übertragungen (105) an die zweite Teilnehmereinheit (TE2) oder an weitere Teilnehmereinheiten (TE) bei fehlgeschlagenem Kommunikationsverbindungsaufbau (307) zum Transaktionsregister (4) oder fehlgeschlagenem (305a) Senden (306) des verschlüsselten Transaktionsdatensatz (TDS) an das Transaktionsregister (4) unterhalb oder gleich einem vordefinierten Schwellwert (X) ist.
13. Das Verfahren (300) nach Anspruch 10, wobei bei Überschreiten eines vordefinierten Schwellwerts (X) eines Prüfwerts (p) für eine Anzahl von Übertragungen (105) an die zweite Teilnehmereinheit (TE2) oder an weitere Teilnehmereinheiten (TE) bei fehlgeschlagenem (307) Kommunikationsverbindungsaufbau (304) zum Transaktionsregister (4) oder fehlgeschlagenem (305a) Senden (306) des verschlüsselten Transaktionsdatensatz (TDS) an das Transaktionsregister (4) ein Senden (306) des verschlüsselten Transaktionsdatensatzes (TDS) und/oder eines gespeicherten Transaktionsdatensatzes (TDS) an das Transaktionsregister (4) vor dem Übertragen (105) des elektronischen Münzdatensatzes (C) erfolgen muss.
14. Das Verfahren (300) nach einem der Ansprüche 10 bis 12, wobei bei erfolgreicher Übertragung (105) des elektronischen Münzdatensatzes (C) und fehlgeschlagenem (307) Kommunikationsverbindungsaufbau (304) zum Transaktionsregister (4) oder fehlgeschlagenem (305a) Senden (306) des verschlüsselten Transaktionsdatensatz (TDS) an das Transaktionsregister (4) ein Prüfwert (p) in der ersten Teilnehmereinheit (TE1) inkrementiert wird (310).
15. Das Verfahren (300) nach Anspruch 14, wobei anhand des Prüfwerts (p) auch bestimmt wird, ob der elektronische Münzdatensatz (C) von der ersten Teilnehmereinheit (TE1) bei dem Bezahlsystem (BZ), insbesondere einem Münzregister (2) oder einem Überwachungsregister (6), angezeigt wird und/oder ob der elektronische Münzdatensatz (C) an die zentrale Herausgeberinstanz (1) zurückgegeben wird.
16. Das Verfahren (300) nach einem der Ansprüche 10 bis 15, wobei in einem Übertragungsfehlerfall anhand des Transaktionsdatensatzes (TDS) der elektronische Münzdatensatz (C) erneut gesendet (306) wird.
17. Das Verfahren (300) nach einem der vorhergehenden Ansprüche mit den weiteren Schritten:
Maskieren des elektronischen Münzdatensatzes (C) durch Anwenden einer homomorphen Einwegfunktion (f(C)) auf den elektronischen Münzdatensatz (C) zum Erhalten eines maskierten elektronischen Münzdatensatzes (Z);
Registrieren (104) des maskierten elektronischen Münzdatensatzes (Z) in einem Münzregister (2) und/oder einem Überwachungsregister (6) des Bezahlsystems (BZ), wobei das Registrieren (104) bevorzugt für ein Umschalten, Aufteilen oder Verbinden maskierter elektronischer Münzdatensätze (Z) ist.
18. Das Verfahren (300) nach einem der vorhergehenden Ansprüche mit den weiteren Schritten:
Maskieren des elektronischen Münzdatensatzes (C) durch Anwenden einer homomorphen Einwegfunktion (f(C)) auf den elektronischen Münzdatensatz (C) zum Erhalten eines maskierten elektronischen Münzdatensatzes (Z);
Verknüpfen des maskierten elektronischen Münzdatensatzes (Z) mit einem Pseudonym (P) zum Erhalten eines pseudonymisierten maskierten elektronischen Münzdatensatzes (S); und Senden des pseudonymisierten maskierten elektronischen Münzdatensatzes (S) an ein Überwachungsregister (6) des Bezahlsystems (BZ).
19. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei die kryptografi sehen Teilschlüssel jeweils von: einer Vollzugsbehördeninstanz; einer Notarinstanz; einer Justizministeriuminstanz; einer zentrale Herausgeberinstanz des Bezahlsystems; oder einer Geschäftsbankinstanz des Bezahlsystems sind.
20. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei der kryptografi sehe Schlüssel (K) zum Verschlüsseln ein öffentlicher Schlüsselteil einer asymmetrischen Schlüsselinfrastruktur ist, wobei der korrespondierende private Schlüsselteil (k) zum Entschlüsseln (409) des verschlüsselten Transaktionsdatensatzes (TDS) durch eine Additions-Operation oder eine bitweise XOR-Operation aus allen kryptografischen Teilschlüsseln der verschiedenen Instanzen (8a, 8b, 8c) zusammengesetzt (406) ist.
21. Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei der kryptografi sehe Schlüssel (K) zum Verschlüsseln ein öffentlicher Schlüsselteil einer asymmetrischen Schlüsselinfrastruktur ist, wobei der korrespondierende private Schlüsselteil (k) zum Entschlüsseln des verschlüsselten Transaktionsdatensatzes aus einer vordefinierten Anzahl (n) von kryptografischen Teilschlüsseln verschiedener Instanzen (8a, 8b, 8c) zusammengesetzt ist, wobei die vordefinierte Anzahl (n) geringer ist als die Gesamtanzahl (m) der verschiedenen Instanzen (8a, 8b, 8c) ist.
22. Das Verfahren (300) nach Anspruch 20 oder 21, wobei der öffentliche Schlüsselteil (K) von dem Transaktionsregister (4) vor dem Verschlüsseln-Schritt (303) in der ersten Teilnehmereinheit (TE1) empfangen (302) wird.
23. Das Verfahren (300) nach einem der Ansprüche 1 bis 19, wobei der kryptografi sehe Schlüssel (K) zum Verschlüsseln ein symmetrischer Schlüssel ist, der durch eine Additions- Operation oder eine bitweise XOR-Operation aus zumindest zwei kryptografischen Teilschlüsseln zusammengesetzt (406) ist.
24. Eine Teilnehmereinheit (TE), bevorzugt ein Sicherheitselement (SE), aufweisend:
- eine Recheneinheit (13), eingerichtet zum Ausführen des Verfahrens (300) der
Ansprüche 1 bis 23; - Mittel zum Zugreifen auf einen Datenspeicher (10, 10‘), wobei im Datenspeicher (10, 10‘) zumindest ein elektronischer Münzdatensatz (C) abgelegt ist; und
- eine Schnittstelle (12) eingerichtet zum (304) Aufbau einer Kommunikationsverbindung zu einem Transaktionsregister (4), um einen verschlüsselten Transaktionsdatensatz (TDS) an das Transaktionsregister (4) zu senden.
25. Ein Verfahren (400) zum Aufbewahren von verschlüsselten Transaktionsdatensätzen (TDS) eines Bezahlsystems (BZ) mit den Verfahrensschritten:
- Erzeugen (301), von einer ersten Teilnehmereinheit (TE1), eines Transaktionsdatensatzes (TDS) bezüglich eines Übertragens (105) des elektronischen Münzdatensatzes (C) an eine zweite Teilnehmereinheit (TE2), bevorzugt ein zweites Sicherheitselement (SE2), oder bezüglich einer am Münzregister (2) zu registrierenden Modifikation des elektronischen Münzdatensatzes (C);
- Verschlüsseln (303), von der ersten Teilnehmereinheit (TE1), des erzeugten Transaktionsdatensatzes (TDS) mit einem kryptografi sehen Schlüssel (K), wobei der kryptografische Schlüssel (K) aus zumindest zwei kryptografi sehen Teilschlüsseln, bevorzugt mindestens drei kryptografi sehen Teilschlüsseln, jeweils verschiedener entfernter Instanzen (8a, 8b, 8c) zusammengesetzt ist,
Senden des verschlüsselten Transaktionsdatensatzes (TDS) an ein Transaktionsregister
(4);
Empfangen (401) des verschlüsselten Transaktionsdatensatzes (TDS), wobei der empfangene verschlüsselte Transaktionsdatensatz (TDS) insbesondere durch das Verfahren (300) einer der Ansprüche 2 bis 23 erzeugt (301) und verschlüsselt (303) wurde, und Ablegen (404) des verschlüsselten Transaktionsdatensatzes (TDS) in einem Speicherbereich des Transaktionsregisters (4).
26. Das Verfahren (400) nach Anspruch 25 mit dem weiteren Verfahrensschritt:
- Entschlüsseln (409) des verschlüsselten Transaktionsdatensatzes (TDS) mit einem kryptografi sehen Schlüssel (k), wobei der Schlüssel (k) zum Entschlüsseln (409) des verschlüsselten Transaktionsdatensatzes (TDS) aus zumindest zwei kryptografi sehen Teilschlüsseln jeweiliger verschiedener entfernter Instanzen (8a, 8b, 8c) in dem Transaktionsregister (4) zusammengesetzt (406) wird.
27. Das Verfahren (400) nach Anspruch 26, wobei das Zusammensetzen (406) durch eine Additions-Operation oder eine bitweise XOR-Operation erfolgt.
28. Das Verfahren (400) nach Anspruch 26 oder 27, wobei der kryptografische Schlüssel (k) zum Entschlüsseln (409) des verschlüsselten Transaktionsdatensatzes (TDS) aus einer vordefinierten Anzahl (n) von kryptografi sehen Teil schlüsseln verschiedener entfernter Instanzen (8a, 8b, 8c) zusammengesetzt (406) ist, wobei die vordefinierte Anzahl (n) geringer als die Gesamtanzahl (m) der verschiedenen entfernten Instanzen (8a, 8b, 8c) ist.
29. Das Verfahren (400) nach einem der Ansprüche 26 bis 28, wobei das Entschlüsseln (409) nur auf eine externe Anfrage (407) hin erfolgt.
30. Das Verfahren (400) nach einem der Ansprüche 25 bis 29, wobei das Transaktionsregister (4) ein Hardware Security Module aufweist, wobei das Hardware Security Module ein sicherer Schlüsselspeicher ist, in welchem verschiedene Generationen der Teilschlüssel aufbewahrt werden.
31. Das Verfahren (400) nach einem der Ansprüche 25 bis 30, wobei das Transaktionsregister (4) ein Hardware Security Module aufweist gegenüber dem sich die verschiedenen entfernten Instanzen (8a, 8b, 8c) vor dem Entschlüsseln (409) des abgelegten verschlüsselten Transaktionsdatensatzes (TDS) authentisieren (408).
32. Das Verfahren (400) nach Anspruch 31, wobei erst nach erfolgreicher Authentisierung (408) jeder entfernten Instanz (8a, 8b, 8c) das Entschlüsseln (409) mit allen Generationen von Teilschlüsseln erfolgen darf.
33. Das Verfahren (400) nach einem der Ansprüche 25 bis 32, wobei nach dem Empfangen (401) des verschlüsselten Transaktionsdatensatzes (TDS) von der ersten Teilnehmereinheit (TE1) der verschlüsselte Transaktionsdatensatz (TDS) umverschlüsselt (403) wird.
34. Das Verfahren (400) nach einem der Ansprüche 25 bis 32, wobei nach dem Empfangen eines aktualisierten Teilschlüssels von einer der verschiedenen entfernten Instanzen (8a, 8b, 8c) der verschlüsselte Transaktionsdatensatz (TDS) umverschlüsselt (403) wird.
35. Das Verfahren (400) nach einem der Ansprüche 25 bis 34, wobei nach dem Empfangen (401) des verschlüsselten Transaktionsdatensatzes (TDS) von der ersten Teilnehmereinheit (TE1) der verschlüsselte Transaktionsdatensatz (TDS) entschlüsselt (409) und eine Kennung einer Teilnehmereinheit (TE1) durch ein Pseudonym (P) im Transaktionsdatensatz (TDS) ersetzt (410) wird, um einen entschlüsselten pseudonymisierten Transaktionsdatensatz (TDS*) zu erhalten.
36. Das Verfahren (400) nach einem der Ansprüche 25 bis 35, wobei nach dem Empfangen (401) des verschlüsselten Transaktionsdatensatzes (TDS) von der ersten Teilnehmereinheit (TE1) der verschlüsselte Transaktionsdatensatz (TDS) entschlüsselt (409) und ein geldwerter Betrag (u) eines elektronischen Münzdatensatzes (C) durch eine Betragskategorie im Transaktionsdatensatz (TDS) ersetzt (411) wird, um einen entschlüsselten pseudonymisierten Transaktionsdatensatz (TDS*) zu erhalten.
37. Das Verfahren (400) nach einem der Ansprüche 35 oder 36, wobei der entschlüsselte pseudonymisierte Transaktionsdatensatz (TDS*) an ein Überwachungsregister (6) des Bezahlsystems (BZ) gesendet (412) wird.
38. Ein Transaktionsregister (4) für ein Bezahlsystem (BZ) aufweisend:
- eine Recheneinheit (13), eingerichtet zum Ausführen des Verfahrens (400) der Ansprüche 25 bis 37;
- Mittel zum Zugreifen auf einen Datenspeicher (10, 10‘), wobei im Datenspeicher (10,
10‘) zumindest ein verschlüsselter Transaktionsdatensatz (TDS) abgelegt ist; und
- eine Schnittstelle (12) eingerichtet zur Kommunikation mit einer Teilnehmereinheit (TE), um einen verschlüsselten Transaktionsdatensatz (TDS) von der Teilnehmereinheit (TE) zu empfangen (401).
39. Das Transaktionsregister (4) nach Anspruch 38, weiter aufweisend:
- ein Hardware Security Modul, eingerichtet zum:
- sicheren Aufbewahren von Teilschlüsseln unterschiedlicher Generationen;
- Entschlüsseln (409) von verschlüsselten Transaktionsdatensätzen (TDS).
40. Das Transaktionsregister (4) nach Anspruch 39, wobei das Hardware Security Modul eingerichtet ist zum:
- Entschlüsseln (409) von verschlüsselten Transaktionsdatensätzen (TDS);
- Ersetzen (410) von einer Kennung einer Teilnehmereinheit (TE) durch ein Pseudonym (P) im Transaktionsdatensatz (TDS), um einen entschlüsselten pseudonymisierten Transaktionsdatensatz (TDS*) zu erhalten.
41. Das Transaktionsregister (4) nach Anspruch 39 oder 40, wobei das Hardware Security Modul eingerichtet ist zum:
- Entschlüsseln (409) von verschlüsselten Transaktionsdatensätzen (TDS);
- Ersetzen (411) eines geldwerten Betrags (u) eines elektronischen Münzdatensatzes (C) durch eine Betragskategorie im Transaktionsdatensatz (TDS), um einen entschlüsselten pseudonymisierten Transaktionsdatensatz (TDS*) zu erhalten.
42. Das Transaktionsregister (4) nach Anspruch 38 bis 41, wobei die Schnittstelle (12) eingerichtet ist zum Senden (412) des entschlüsselten pseudonymisierten Transaktionsdatensatzes (TDS) an ein Überwachungsregister (6) des Bezahlsystems (BZ).
43. Ein Bezahlsystem (BZ) aufweisend:
- zumindest eine Teilnehmereinheit (TE1, TE2) gemäß Anspruch 20, wobei die Teilnehmereinheit (TE1, TE2) zum Ausfuhren des Erzeugen- Schritts (301) und des Verschlüsseln-Schritts (302) des Verfahrens (300) nach einem der Ansprüche 1 bis 23 eingerichtet ist, wobei der verschlüsselte Transaktionsdatensatzes (TDS) an ein Transaktionsregister (4) gesendet wird; und
- das Transaktionsregister (4) nach einem der Ansprüche 38 bis 42, wobei das Transaktionsregister (4) zum Ausführen des Verfahrens (400) nach einem der Ansprüche 25 bis 37 eingerichtet ist.
44. Das Bezahlsystem (BZ) nach Anspruch 43, weiter aufweisend: eine Herausgeberinstanz (1), die ausgebildet ist, einen elektronischen Münzdatensatzes (C) für das Bezahlsystem (BZ) zu erstellen (102); und/oder ein Münzregister (2), eingerichtet zum Registrieren (104) eines maskierten elektronischen Münzdatensatzes (Z), wobei das Registrieren (104) bevorzugt für ein Umschalten, Aufteilen oder Verbinden maskierter elektronischer Münzdatensätze (Z) ist; und/oder ein Überwachungsregister (6), eingerichtet zum Empfangen eines pseudonymisierten maskierten elektronischen Münzdatensatzes (S) von der Teilnehmereinheit (TE) oder zum Empfangen eines entschlüsselten pseudonymisierten Transaktionsdatensatzes (TDS) von dem Transaktionsregister (4).
EP21739315.6A 2020-07-08 2021-06-30 Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen Pending EP4179487A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020004121.3A DE102020004121A1 (de) 2020-07-08 2020-07-08 Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
PCT/EP2021/068064 WO2022008322A1 (de) 2020-07-08 2021-06-30 Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen

Publications (1)

Publication Number Publication Date
EP4179487A1 true EP4179487A1 (de) 2023-05-17

Family

ID=76829539

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21739315.6A Pending EP4179487A1 (de) 2020-07-08 2021-06-30 Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen

Country Status (6)

Country Link
US (1) US20230259899A1 (de)
EP (1) EP4179487A1 (de)
CN (1) CN116057554A (de)
CA (1) CA3184856A1 (de)
DE (1) DE102020004121A1 (de)
WO (1) WO2022008322A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021005040A1 (de) 2021-09-24 2023-03-30 Giesecke+Devrient Advance52 Gmbh Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit
WO2023046317A1 (de) 2021-09-24 2023-03-30 Giesecke+Devrient Advance52 Gmbh Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
PL3073670T4 (pl) * 2015-03-27 2021-08-23 Black Gold Coin, Inc. System i sposób osobistej identyfikacji i weryfikacji
WO2019143852A1 (en) * 2018-01-17 2019-07-25 Medici Ventrues, Inc. Multi-approval system using m of n keys to perform an action at a customer device
DE102018127529A1 (de) * 2018-11-05 2020-05-07 Infineon Technologies Ag Elektronische Vorrichtung und Verfahren zum Signieren einer Nachricht
CN110419053B (zh) 2018-11-27 2023-12-01 创新先进技术有限公司 用于信息保护的系统和方法

Also Published As

Publication number Publication date
US20230259899A1 (en) 2023-08-17
WO2022008322A1 (de) 2022-01-13
DE102020004121A1 (de) 2022-01-13
CA3184856A1 (en) 2022-01-13
CN116057554A (zh) 2023-05-02

Similar Documents

Publication Publication Date Title
DE69534490T2 (de) Verfahren zur sicheren anwendung digitaler unterschriften in einem kommerziellen verschlüsselungssystem
EP3474172B1 (de) Zugangskontrolle unter verwendung einer blockchain
DE102016220656A1 (de) Bereitstellung und Prüfung der Gültigkeit eines virtuellen Dokuments
EP3956845A1 (de) Gerät zum direkten übertragen von elektronischen münzdatensätzen an ein anderes gerät sowie bezahlsystem
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
DE102019002732A1 (de) Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
EP3319006A1 (de) Verfahren zur offline-echtheitsprüfung eines virtuellen dokuments
EP4179487A1 (de) Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
EP4111399B1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
EP4254234A1 (de) Ausstellen eines digitalen credentials für eine entität
EP4179488A1 (de) Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem
WO2022200035A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
EP4179486A1 (de) Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
EP4111347B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
WO2022233454A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
WO2022008321A1 (de) Verfahren, endgerät sowie münzregister zum übertragen von elektronischen münzdatensätzen
DE102021000570A1 (de) Verfahren zum bereitstellen eines nachweisdatensatzes; verfahren zum prüfen eines nachweisdatensatzes; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102021004020A1 (de) Verfahren zum registrieren von token eines elektronischen transaktionssystems
EP4092958A1 (de) Ausstellen eines digitalen verifizierbaren credentials
WO2023202836A1 (de) Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen

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

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)