WO2024012624A1 - Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber - Google Patents

Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber Download PDF

Info

Publication number
WO2024012624A1
WO2024012624A1 PCT/DE2023/100452 DE2023100452W WO2024012624A1 WO 2024012624 A1 WO2024012624 A1 WO 2024012624A1 DE 2023100452 W DE2023100452 W DE 2023100452W WO 2024012624 A1 WO2024012624 A1 WO 2024012624A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
unit
issuer
trr
secure
Prior art date
Application number
PCT/DE2023/100452
Other languages
English (en)
French (fr)
Inventor
Lucas DOHMEN
Matthias Fasching
Klaus ALFERT
Original Assignee
Giesecke+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+Devrient Advance52 Gmbh filed Critical Giesecke+Devrient Advance52 Gmbh
Publication of WO2024012624A1 publication Critical patent/WO2024012624A1/de

Links

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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 for securely generating a releasable token by a token issuer of an electronic transaction system with a token reference register.
  • the invention also relates to a method for securely destroying a token of an electronic transaction system with a token reference register.
  • the invention also relates to a token issuer.
  • the token issuer can initially register a token reference of a token that can be issued in the token reference register or delete an already registered token reference of a token that is to be withdrawn. Participants in the transaction system, on the other hand, may only register a token reference of the token, for example, in exchange for an already registered token reference of a token of the same value.
  • CBDC systems digital central bank currency systems
  • high security requirements are placed on the central system components, for example the token issuer.
  • WO 2022/008319 A1 describes a token issuer which includes an isolated token generation unit and a token issuing unit.
  • a private key of a cryptographic key pair of the token issuer may be stored in a hardware security module of the token generation unit.
  • the token generation unit At the request of the token issuing unit, the token generation unit generates a new token and a signed registration data record, which enables the new token to be registered using a token reference in the token reference register.
  • the token issuing unit receives the token to be issued and the token registration record. It registers the token to be issued in the token reference register using the token registration data record before issuing the new token to a participant unit of the transaction system.
  • the invention is based on the object of providing an even more secure token issuer unit and a particularly secure method for this To provide generation or destruction of tokens of the transaction system.
  • the solution should preferably be flexible without endangering the security in the transaction system.
  • the task is solved in particular by a method for securely generating a releasable token by a token issuer of an electronic transaction system with a token reference register.
  • a token issuer unit which includes a secure token generation unit
  • the following steps are carried out: generating a token-specific token element pair, which includes a secret token element and a public token reference element, in the secure token generation unit; Generating an add command in the secure token generation unit that instructs the token reference register to add a token reference comprising the generated public token reference element as an additional token reference in the token reference register; Sending the add command to the token reference register.
  • the token element pair created is an internal, temporary token element pair of the token generation unit.
  • the token generation unit receives a token reference of the issueable token.
  • the token generation unit generates a replacement command which instructs the token reference register to register the token reference of the issueable token instead of the token reference of the temporary token element pair.
  • a token contains a token value as a token element.
  • the token issuer unit comprises a secure token storage unit (hereinafter also token issuer subscriber unit), this secure token storage unit generating a token-specific token element pair of the issueable token.
  • the secret token element of the internal, temporary token element pair is only present in the token generation unit and/or the secret token element of the issueable token is only present in the token generation unit.
  • a token contains a secret token element of the token element pair.
  • a token reference contains a public token reference element of the token element pair. The public token reference element is uniquely assigned to a token and/or derived from the secret token element of the token element pair.
  • the secret token element is a random number and the public token reference element is the result of a cryptographic function on the secret token element.
  • the secret token element is a private key of a cryptographic key pair and the public token reference element is the public key of the cryptographic key pair.
  • the token value of the internal temporary token corresponds to the token value of the token to be issued.
  • the token value can be transmitted to the token generation unit as information from a token issuer administration, which is a unit of the token issuer unit. Alternatively, token values with fixed denominations are created.
  • the internal temporary token generated in the token generation unit by a generate step is not transmitted directly to the token management unit.
  • the token generation unit after generating the internal temporary token, issues a replacement command (in particular a token value-neutral replacement, for example by a switching modification, a connecting modification (with a token of the value "0" or a splitting mod dification (receipt of a token with the value "0")), in order to reference a (new) token to be issued.
  • the public token reference element (R) of the token element pair (r, R) required for the replacement is used for this purpose, for example, by the token issuer management unit ( a unit of the token issuer unit) or a bank participant unit or a central bank participant unit.
  • the new token By registering the token reference of the new token to be issued with the token reference register, the new token is valid in the transaction system and can be used.
  • the token issuer holds newly issueable (but (not yet issued) tokens.
  • the issueable token can then be issued immediately (without having to carry out the secure generation process first) to the requesting participant unit in the transaction system.
  • a token generation request can be received, preferably in a secure token issuer administration of the token issuer unit.
  • This token generation request may have been sent by a subscriber unit, for example a bank subscriber unit of the transaction system. Alternatively, this token generation request may have been sent by a central bank entity.
  • CDBC wallets in the participant units, for example a bank participant unit of the transaction system, which interact with the token issuer unit for an order (request, generation) or return (redemption, destruction) of CDBC.
  • the issueable token is preferably signed with a private key of the token issuing unit, for example with a private key of the token generation unit.
  • a private key of the token generation unit By signing with the private key part, each participant unit of the transaction system can now use the associated public key part to check whether the token was generated in a trustworthy manner. This ensures that the token was issued by a token issuer and not an attacker.
  • neither the key part of the cryptographic key pair of the token issuing unit nor the secret token element leaves the token generation unit. It is therefore possible to modularly decompose the token issuer into a token issuer management unit and a token generation unit. Both units of the token issuer unit can now be located at a distance from one another without deteriorating security.
  • the token issuer unit can be constructed more flexibly and modularly.
  • the new token is preferably signed with the private part of the temporary token-specific cryptographic key pair.
  • the token generation unit thus indicates that it was aware of the temporary token and the new token.
  • This signature can be a mandatory information for the replacement command.
  • the replacement command in the token reference register is preferably checked for validity by checking a signature of the token issuer unit using a public key part of the token issuer unit.
  • the registration request in the token reference register is also checked for validity by checking a signature using the public token reference element of the token element pair.
  • the add command and the replace command are preferably sent together in a common sending step to the token reference register.
  • an addition acknowledgment (generated by the token reference register) and/or a replacement acknowledgment (generated by the token reference register) is received in the token issuer unit.
  • a method for the secure destruction of a token by a token issuer of an electronic transaction system with a token reference register wherein the following steps are carried out in a token issuer unit which includes a secure token destruction unit: generating a remove command in the token destruction unit, which instructs token reference register to remove a token reference of a registered token from the token reference register; and sending the remove message Commands to the token reference register.
  • the token destruction unit creates an internal temporary token before generating the remove command and generates the remove command for the token reference of the internal temporary token.
  • a replacement command is generated, which instructs the token reference register to register the token reference of the internal, temporary token instead of the token reference of the token to be taken back.
  • the second aspect - in analogy to the secure generation of a token according to the first aspect - is now aimed at destroying (deleting) a token in the transaction system.
  • Advantages and technical tasks correspond to those of the first aspect.
  • the method according to the second aspect means that the internal temporary token generated in the token destruction unit by a generating step is not transmitted directly to the token management unit.
  • the token destruction unit after generating the internal temporary token, issues a replacement command (in particular a token value-neutral replacement, for example by a switching modification, a connecting modification (with a token of the value "0") or a split - Modification (receiving a token with value "0")), created in order to register the token reference of the internal, temporary token instead of the token reference of the token to be taken back (destroyed).
  • the token reference of the token to be taken back required for the replacement is provided for this purpose, for example, by the token issuer management unit (a unit of the token issuer unit) or a bank participant unit or a central bank participant unit.
  • a replacement command is combined with the remove command.
  • the token issuer unit includes a secure token storage unit, wherein the secure token storage unit deactivates the token to be withdrawn.
  • the secret token element of the internal, temporary token is preferably only present in the token destruction unit.
  • the remove command and the replace command can be sent together in a common send step to the token reference register.
  • a removal acknowledgment generated by the token reference register
  • a replacement acknowledgment generated by the token reference register
  • the token issuer unit may include a secure token management unit, wherein a token destruction request is received in the token management unit.
  • the token to be destroyed was taken from a deletion directory of the token issuer administration.
  • This deletion directory is a storage area in the token issuer unit in which subscriber units of the transaction system store tokens to be deleted (i.e. redeemed).
  • an air gap interface is implemented between the token generation unit and the token issuer administration.
  • the air-gap or air-wall process is a process that separates the two units (token generation unit and token issuer management) from each other, but still allows the transmission of user data, here tokens, token elements, token element pairs, key parts, etc.
  • An air-gap process is used to isolate the two units that have different levels of trust from each other, but still ensure that data from the other unit can be processed.
  • the air-gap transmission is set up to physically, logically, electrically and/or electronically separate the token generation unit from the token issuer administration.
  • both units are electrically isolated from each other in terms of shape.
  • Data transmission does not take place exclusively electrically/electronic.
  • an attacker with remote network access to the token issuer management has no access to the token generation unit.
  • the attacker is therefore unable to introduce data into the token generation unit and/or data (e.g. the temporary token or the private part of the token issuer key pair) from the token generation unit.
  • the transfer takes place in the air-gap process using portable electronic data storage devices, such as USB sticks, memory cards, CDs, or similar.
  • portable electronic data storage devices such as USB sticks, memory cards, CDs, or similar.
  • appropriate electronic interfaces such as a USB port, memory card reader or CD drive, are provided on the token generation unit and the token issuer administration
  • the token generation unit is further set up to generate an expression representing the token (as a physical representative of a token).
  • the token issuer management is set up to read the token expression generated by the token generation unit.
  • the printout can, for example, be transported to a reading area of the token issuer administration via mechanical conveying mechanisms.
  • the transport boxes already described can also be used for this, so that, for example, a printout is automatically arranged in a transport box by the token generation unit, then transported to the token issuer administration, in particular its reading area, and read there.
  • all tokens to be deleted within a predefined time period are connected at the end of the predefined time period to form a common deletion token before executing the method according to the second aspect by applying one or more connect commands.
  • the predefined time period is preferably a month, preferably a week, more preferably a day, more preferably an hour.
  • the token reference register sends an add acknowledgment when the add command is valid and the temporary token reference has been added to the token reference register.
  • the token issuer unit in particular the secure token issuer management unit, thus learns that the temporary token reference is present in the token reference register.
  • An electronic transaction system for example a digital currency system or a digital central bank system, is a system in which at least two, preferably a large number of participant units can exchange (transfer) digital central bank money (CDBC) directly to one another in the form of tokens.
  • the transaction system is therefore, for example, a payment transaction system for exchanging monetary amounts in the form of payment tokens.
  • a token is a data record of a transaction system that can be directly exchanged between participant units.
  • a token reference is registered in the token reference register, the token is deemed to have been created and/or deleted and/or transferred and from this point on a receiving subscriber unit is in possession of the token value that the token represents.
  • the token is transferred, it automatically changes owner (from issuer to subscriber unit).
  • a token - a data set that is transferable independently of a transaction topology, such as blockchain topologies "Bitcoin”, “Ethereum” or “Neo” - can be transferred directly between participant units or by the token issuer without intermediary units.
  • the token is an electronic coin data record or payment token for exchanging monetary amounts between participant units.
  • a payment token is also colloquially referred to as a “digital coin” or “electronic coin” and represents cash in electronic form.
  • Each token in the transaction system is a data record comprising at least two token elements.
  • a first token element of each token of the transaction system is a token value, for example an asset, an asset, an economic asset and/or a monetary amount.
  • a second token element of each token of the transaction system is a secret token element of the token element pair, for example the private part of a token-specific key pair.
  • This private part is a secret in the transaction system and is not published and may not be used multiple times. The generation of the private part must not be predictable.
  • This private part can be a random number. The random number is preferably the result of a true random generator.
  • the token is formed from the token value (first token element) and the secret token element. This formation is preferably the chaining (concatenation) of these two token elements. Any other type of linking of these two token elements is not excluded according to the invention and includes, for example, adding them one after the other, introducing them into a TLV data structure and/or logically linking them.
  • the token differs from a data record for classic data exchange or data transfer, since, for example, a classic data exchange takes place on the basis of a question-answer principle or on intercommunication between the data exchange partners.
  • a token on the other hand, is unique and unique in the transaction system. The token is in the context of a security concept, which includes, for example, signatures or cryptographic encryption.
  • a token contains all data elements that are required for a receiving subscriber unit to verify, authenticate and pass on the token to another subscriber unit. Intercommunication between the subscriber units transmitting a token is therefore fundamentally not necessary with a token.
  • Each token in the transaction system is assigned a token reference. This assignment is one-to-one, which means that exactly one token reference is assigned to a token and exactly one token is assigned to each token reference.
  • the token reference is a public data record that is stored in a storage unit of the token reference register of the transaction system in a way that can be verified by each participant unit.
  • Both the token and the token reference are unique. Due to the unique assignment, there is a 1-to-1 relationship between the token and the token reference.
  • Each token reference in the transaction system is a data record comprising at least two token reference elements.
  • a first token reference element of each token reference is the token value of the token uniquely assigned to the token reference.
  • the token value of the token is therefore identical to the token value of the assigned token reference.
  • the token value of the token reference is a copy of the token value of the associated token.
  • a second token element of each token reference of the transaction system is a public token reference element of the token element pair, for example a public part of the token-specific key pair.
  • This public part of the token reference together with the private part of the token, forms the token-specific key pair.
  • the public part is obtained by applying a cryptographic function to the private part. Different: The public token reference element and the private token element form the token element pair.
  • This cryptographic function is a one-way function.
  • This cryptographic function is therefore a mathematical function that is “easy” to calculate in terms of complexity theory, but “difficult” to practically impossible to reverse.
  • the term one-way function also refers to a function for which there is currently no known reversal that can be practically carried out in a reasonable amount of time and with reasonable effort.
  • a one-way function is used that operates on a group in which the discrete logarithm problem is difficult to solve, such as B.
  • a Cryptographic process analogous to elliptic curve encryption, ECC for short, from a private key of a corresponding cryptography process.
  • the reverse function i.e. the creation of a token (or part of the electronic coin data set) from a token reference, is very time-consuming.
  • token reference element The (mere) knowledge or possession of a token reference does not authorize the use/transfer/issue of the token value (token reference element). This represents a key difference between the token reference and the token and is a core of the invention herein.
  • the public part of the token-specific key pair is obtained as the second token reference element.
  • the token reference is formed from the token value (first token reference element) and the public part. This formation is preferably the concatenation of these two token reference elements. Any other type of linking of these two token reference elements is not excluded according to the invention and includes, for example, adding them one after the other, introducing them into a TLV data structure and/or logically linking them.
  • a token reference can also be generated by an electronic wallet.
  • the use of a token reference is not comparable to the use of addresses of participant units in a blockchain-based transaction system, since no addresses of the participant units are used in the token reference register according to the invention in order to prevent the tokens from being traceable.
  • the method for registering provides a receiving step to receive a token reference in a token reference register as part of a registration request.
  • the registration request is sent by a subscriber unit or the token issuer administration (here as an addition command and a replacement command) of the transaction system.
  • the token reference register is a unit of the transaction register in which token references are stored, whereby the associated tokens are registered.
  • This register can be a central database or storage unit.
  • This Register can be a decentralized ledger, for example in a blockchain topology.
  • the token reference register can maintain a history of the token references and/or the registration requests.
  • the received registration request is verified by a verification unit in the token reference register. This verifies whether the at least one token reference of the received registration request is already stored in the token reference register. A token reference is only stored once in the token reference register. Since a token reference of a token only exists once in the transaction system, a verify step can be used to determine whether attempts were made to issue a token multiple times. In one embodiment, the verify step determines whether the signature(s) of the registration request is correct.
  • a switch modification can be applied.
  • the following procedural steps are carried out: receiving the token reference from the token issuer for the (new) token to be generated; Generating a registration request comprising the token reference of the temporary token and the token reference for the new (created) token.
  • Switching the token is a modification option for modifying a token.
  • the token references contained in the registration request can be linked together by concatenation. If a token is transferred from a subscriber unit directly to another subscriber unit, for example if the monetary amount is to be transferred as a token value as part of a payment transaction, the sending subscriber unit can now have the token value re-registered to itself. This means that the switchover is registered in the token reference register.
  • the token value of the temporary token is the same as the token value of the new token.
  • a token with the same token value but a new private part is registered in the token reference register.
  • the token reference register has knowledge of token references of tokens of the transaction system and preferably also carries out the processing or modifications to the tokens (token history).
  • the transactions with the tokens are not registered in the token reference register and take place in a Direct transaction layer of the transaction system takes place directly between participant units of the transaction system.
  • a token issuing unit of a transaction system may include: an interface to a token reference register; and a secure token generation unit for securely generating a releasable token using a method according to the first aspect; and/or a secure token destruction unit for securely destroying a token using a method according to the second aspect.
  • the token issuer unit can further comprise a token issuer subscriber unit, set up to store tokens and/or token references; and an interface to a bank subscriber unit or to a
  • Central bank unit configured to receive a token generation request and/or to receive a token destruction request.
  • the token issuer unit can further comprise a token management unit with an interface to a bank subscriber unit or to a central bank unit or a token issuer subscriber unit set up to issue the issueable token and/or store a completion of the secure destruction of the token and/or store a completion of the secure generation of the issueable token.
  • the token issuer unit may further comprise an air-gap interface between the token management unit and the secure token generation unit and/or the secure token destruction unit.
  • the token issuer includes an air-gap interface between the token issuer management and the token generation unit for at least one of the transmission steps of the method according to the first and/or second aspect.
  • the token reference registry can be an instance of a central currency system and each token can be a central bank digital money.
  • a digital currency system as the transaction system includes a plurality of the participant units described, the token reference register and a token issuer.
  • a subscriber unit for example a bank subscriber unit or an issuer subscriber unit, can in the present case be a secure element that has secured access to one or more tokens in a token store. The secure element is, for example, installed in a terminal device ready for operation.
  • the secure element and/or the terminal device have a special computer program product (electronic purse, wallet), in particular in the form of a secured runtime environment within an operating system of a terminal device, English Trusted Execution Environments, TEE, stored on a data storage, for example a mobile terminal, a machine or of an ATM.
  • the secure element is designed, for example, as special hardware, in particular in the form of a secured hardware platform module, English Trusted Platform Module, TPM, or as an embedded security module, eUICC, eSIM.
  • TPM English Trusted Platform Module
  • eUICC embedded security module
  • eSIM embedded security module
  • Fig. 1 shows an exemplary embodiment of a token issuing unit
  • FIG. 2 shows an exemplary embodiment of a sequence of steps of a method according to the first aspect in a token issuer unit
  • FIG. 3 shows an exemplary embodiment of a sequence of steps of a method according to the second aspect in a token issuer unit
  • FIG. 4 shows an exemplary embodiment of a flowchart for switching a token
  • Fig. 5 shows an exemplary embodiment of a flow diagram of connecting a token
  • Fig. 6 shows an exemplary embodiment of a transaction system.
  • Fig. 1 shows an exemplary embodiment of a token issuer TH for a transaction system TS.
  • the transaction system TS can be a digital central bank currency system.
  • the token issuer TH issues tokens T as digital coin data records to a subscriber unit TE, for example directly to a bank customer or preferably to a bank subscriber unit B-TE.
  • the token issuer unit TH provides an initial registration of the newly created (to be issued) token T in a token reference register TRR of the transaction system TS.
  • Each token T in the transaction system TS is initially (only) securely generated by the token issuing unit TH (in the TH-TG) and also securely destroyed (deleted) by the TH (in the TH-TV).
  • a token issuer TH is, for example, an instance of a central bank or an instance of a third-party provider that cooperates with a central bank.
  • the creation (creation, generation) of a token T is initiated in the token issuer TH.
  • the token issuer unit TH of the token issuer has a secure token generation unit TH-TG and a secure token issuer management unit TH-TW and, in some embodiments, also a token issuer subscriber unit TH-TE. Both units TH-TG and TH-TW (TH-TE) can be separated from each other and preferably have an air gap AG.
  • the Air-Gap AG serves to ensure that the highly sensitive security-relevant data and units in the token issuer unit TH, in particular a private key pKeyiH and secret token elements r (of a token element pair) of (new) tokens T to be issued, for example private parts of cryptographic key pairs (those from generated by a random generator) cannot be read out via a network attack on the token issuer TH and used for manipulation of the transaction system TS.
  • the TH-TG can be completely isolated.
  • the TH-TG does not have an interface to a network such as TCP/IP, the Internet, the mobile phone network, etc.
  • the destruction (deletion) of a token T is initiated in the token issuer TH.
  • the token issuer unit TH has a secure token destruction unit TH-TV and a secure token issuer management unit TH-TW and in some embodiments also a token issuer subscriber unit TH-TE. Both units TH-TV and TH-TW (TH-TE) can be separate from each other and preferably have an air gap AG.
  • the Air-Gap AG serves to ensure that the highly sensitive security-relevant data and units in the token issuer unit TH, in particular a private key pKeyiH and secret token elements r (of a pair of token elements) for tokens T to be deleted, for example private parts of cryptographic key pairs (which are generated by a random generator generated) cannot be read out via a network attack on the token issuer unit TH and used for manipulation of the transaction system TS.
  • the TH-TV can be completely insulated.
  • the TH-TV does not have an interface to a network such as TCP/IP, the Internet, the mobile phone network, etc.
  • a token issuer unit TH can have both a TH-TG and a TH-TV. It is alternatively possible for a first token issuer unit of the TS to have only a TH-TG but no TH-TV and for a second token issuer unit of the TS to have only a TH-TV but no TH-TG.
  • a token T is uniquely represented in the transaction system TS by a token value v and a secret token element, for example a random number r.
  • the token value v can be specified in a range of values from 1 to 2 31 -1.
  • the random number r can be a number in the range from 0 to 2 256 -1, i.e. the order of an elliptic curve, for example secp256rl.
  • the random number r - as an example of a secret token element of a token T - is a private part of a token-specific key pair r, R.
  • the random number r is unique and secret in the transaction system TS and may not be published or reused. The generation of the random number r must not be predictable and is generated using a real random number generator.
  • the token value v is a 32-bit token element of type integer.
  • the random number r is a 32-byte token element of type integer.
  • a token can be stored as a TLV-encoded data record in a token memory, for example in CBS, and then has a unique tag and length information, for example in the following format.
  • TLV encoded token in hexadecimal form is shown below:
  • ID IE 1F is the random number r as an integer.
  • a token generation request is optionally received at the TH-TM.
  • the token generation request can be sent by a central bank entity. This request can be for a single token T or a series of tokens T, for example "Generate 200 tokens with value 100". The request can be for a time period, for example "Generate 200 tokens with value 100 for today” or Generate 200 tokens with value 100 in the next hour”.
  • a request for a new token reference element is optionally received. This request can be received in the TH-TM or from the TH-TM to the TH-TE.
  • a new token element pair R ne w, r ne w is optionally generated.
  • a token element pair r, R includes in particular a secret token element r (a token element of the token T) of the token element pair and a public token reference element R (a token element of the token reference TR) of the token element pair.
  • step 203 the public token reference element Rnew is optionally provided (sent) within (or to) the TH-TM.
  • the optional steps 200-203 can proceed differently. 2, a general request 200 from the central bank "we need 200 tokens with a value of 100 today” or a request for a bank subscriber unit B-TE "we now need 20 tokens with a value of 50" can be made in the TH-TM " will be received.
  • a request from a bank for example a B-TE, "please a token with value 100 on R_new" could - alternatively - already include a new public token reference element Rnew, then TH-TE is not involved in generating the new token (to be issued). involved.
  • the B-TE (external to the TH) creates the new token element pair R new, Tnew in step 202.
  • the B-TE sends the request to the TH-TM.
  • step 211 a token generation request is then received from the TH-TM to the TH-TG.
  • step 212 an internal temporary token element pair Rtemp, rtemp is generated.
  • the secret token element rtemp of the internal, temporary token element pair is preferably only present in the token generation unit TH-TG.
  • step 214 an add command is generated in the TH-TG.
  • a signature from TH can be used for this purpose.
  • step 215 the addition command is sent by the secure token generation unit TH-TG to the TH-TW.
  • the command instructs the token reference register TRR to add a token reference TR, which includes the generated public token reference element, as an additional token reference TR in the token reference register TRR.
  • a replacement command is generated.
  • the command instructs the TRR to register the token reference TR ne w of the issueable token T ne w instead of the token reference TRtemp of the temporary token element pair.
  • the replacement command can be signed with the secret token element and is, for example:
  • step 219 the replacement command is sent from the TH-TG to the TH-TM.
  • step 221 the add command is sent to the TRR.
  • the TRR then adds the temporary token reference TRtemp to the database in step 222.
  • the add command is:
  • an add confirmation HB is optionally generated by the TRR.
  • the HB can be signed with a TRR key and reads, for example:
  • step 225 the addition confirmation HB is then optionally received from the TRR in the TH-TM.
  • step 231 the replacement command is then sent to the TRR.
  • the replacement command is:
  • step 232 the token reference TRtemp is then replaced with the token reference TR ne w.
  • a replacement confirmation RB is then optionally generated.
  • the RB can be signed with a key of the TRR and reads, for example:
  • step 235 the replacement acknowledgment RB is received from the TRR in the TH-TM.
  • the replacement confirmation EB is optionally received in the TH-TE.
  • the RB can be:
  • step 2308 the new token T new is optionally saved/activated.
  • step 239 a confirmation for issueable new tokens T new is optionally sent
  • step 240 the completion of the generation is optionally saved in the TH-TM, a kind of logging of the generation of the new token T new.
  • the TH-TM therefore remembers the completion of the generation in step 240.
  • step 250 the new token T new is optionally issued to a B-TE or another TE of the TS.
  • step 215 is optional because the commands of steps 214 and 218 can be transmitted together.
  • steps 221, 231 would be a joint transmission of the two commands and with joint transmission either only confirmation step 225 or only confirmation step 235 or both confirmation steps 225 and 235 would take place.
  • step 231 is carried out by TH-TE or even by B-TE.
  • step 221 in the TRR is only received by the TH, i.e. by the TH-TM or TH-TE.
  • the processes of steps 237, 238, 239 change accordingly in that the replacement confirmation RB can only come from TH-TE or B-TE, so that v ne w and / or RB in step 237 to the TH-TM comes and step 238 serves to ensure that the new token T is complete or is activated as issueable.
  • the following method can be carried out to generate a new token.
  • the TH-TM requests the public key Rneu of a new token T neu from a processor (payment processor) (TH-TE).
  • the payment processor (TH-TE) stores the associated private key r in a temporary wallet.
  • the TH-TM creates a “minting order”, i.e. a request to the TH-TG to provide a new token and in this request transmits the token value v and the public key Rnew (from step 1) to the TH-TG.
  • the TH-TG creates a temporary token Ttemp consisting of the token value v and a temporary private key part rtemp of a temporary token-specific key pair using a CREATE command (create command).
  • SWITCH command a switchover
  • the TH-TG only needs the public key Rnew provided by the TH-TM.
  • a registration request is created, which contains the command history (CmdHist) of the switch command and the create command.
  • the token value v and the private key rtemp and the registration request RA are made available to the TH-TM.
  • the TH-TM sends the registration request RA to the TRR and receives a registration confirmation RB.
  • the registration confirmation RB and also the registration request RA are sent to the payment processor TH-TE.
  • the token value v, private key rtemp, registration request RA and registration confirmation are checked and verified.
  • the private key r new is removed from the temporary wallet and stored together with v new as Tnew.
  • a token reference TR is stored in the token reference register TRR.
  • the token reference TR includes the token value v of the assigned token T and a public part R of the token-specific key pair.
  • the token reference TR of the token T can be viewed at any time in the TRR register of the transaction system TS. This means that the token value v of a token T is disclosed by the token reference register TRR.
  • the public part R of the token-specific key pair is generated by applying a cryptographic function to the private part r of the token-specific key pair. This function is difficult to reverse and thus gives the TS transaction system the necessary security.
  • R r * G, where G can be, for example, a global parameter of the transaction system TS, for example a generator point of an elliptic curve, here the secp256rl curve.
  • the token reference TR is then formed by the token value v of the token T and the public part R of the key pair.
  • the token reference TR is therefore the link or concatenation of token value v and public part R.
  • This token reference TR can be sent to the token reference register TRR as a registration request RA, if necessary together with a command regarding the token T.
  • the registration request RA can be signed with the private part r of the token-specific key pair. Signing makes it possible to verify whether the sender of the token reference TR was in possession of the token T, which further increases security in the transaction system TS.
  • the signed registration request RA Sig is stored in the subscriber unit TE as a so-called evidence data record, PR (for proof), for example in the following format:
  • This registration request RA can be sent to the token reference register TRR.
  • This registration request RA is received in the token reference register TRR.
  • the token reference TR is stored in the token reference register TRR, whereby the token T is registered in the transaction system TS. From this point on, the token T can be used in the transaction system TS.
  • This token reference TR is uniquely assigned to the token T and is used to register the token T in the transaction system TS.
  • the token reference TR is therefore the public representation of the token T.
  • the sole knowledge or possession of the token reference TR does not allow the token T to be transferred and is not equivalent to the TE being in possession of the token T.
  • the token reference TR is used to prevent multiple output attempts and checks whether token values v were generated in an inadmissible manner. Therefore, the token reference TR and, if necessary, the history of the tokens T and the corresponding registration requests RA from subscriber units TE are stored in the token reference register TRR.
  • the tokens T are stored, for example, in electronic purses, so-called wallets. These wallets are, for example, software applications within the subscriber units TE or a terminal device in which the TE is installed ready for operation. A wallet can be set up as an application on a smartphone, a smart card or a payment terminal. The wallet is used to securely manage token T of the TE, to generate token references TR, to modify token T and/or to exchange token T. Wallets are used to communicate with the token reference register TRR, to generate registration requests RA to the token reference register TRR and/or to carry out transactions from token T to a subscriber unit TE.
  • the token reference register TRR is a unit of the transaction system TS and is either a central register or a central database of the transaction system TS or a decentralized register or a decentralized database (DLT) of the transaction system TS.
  • the token reference register TRR manages in particular the storage location for the token references TR, shown as an example of a storage unit in the token reference register TRR.
  • the TR for the token T of the subscriber unit TE1 is entered in the database 1 as a representative.
  • the token reference register TRR can include at least one verification unit 2.
  • the verification unit 2 of the token reference register TRR verifies registration requests RA. Syntactic correctness or the correct specification of a command in the registration request RA can be verified. A history of old (past) registration requests RA regarding a token T can also be verified. The separation of this verification unit 2 from the database 1 distributes the storage and checking tasks and increases the speed in the token reference register TRR.
  • the token reference register TRR can include a checking unit (not explicitly shown) which checks whether a total token value Z in the transaction system TS is changed with the token value v of a received token reference TR. If this is the case, then a new token value v was created or an existing token value v was destroyed. Only privileged units, such as an issuer instance TH, in the transaction system TS are allowed to do this. If such a change in the total sum of the token values is detected by a token reference TR of a subscriber unit TE, then a case of fraud can be assumed. This means that illegal generation of token values v can be discovered and prevented very easily.
  • a registration request RA is preferably signed with the private part r.
  • the signature allows the syntactic authenticity of the command to be easily checked by the recipient (TRR or TE). This check is preferably carried out in the database 1 or the verification unit 2.
  • a register request RA can, for example, be syntactically validated by checking the signature and/or the token reference TR.
  • a token destruction request is optionally received.
  • the token destruction request can be sent by a central bank entity. This request can be for a single token T o id or a series of token T o id, for example "Destroy 200 tokens with value 100". The request can be for a time period, for example "Destroy 200 tokens with value 100 for today (or in the next hour)”.
  • a request for an old token reference element is optionally received. This request can be received in the TH-TM or from the TH-TM to the TH-TE.
  • step 302 the old token T o id in the TH-TE is optionally deactivated.
  • step 303 the old token reference element TR o id is optionally sent.
  • Steps 300-303 can proceed differently. According to the flow in Fig. 3, a general request 300 from the central bank "we are deleting 200 tokens with a value of 100 today" or a request for a bank "we are now deleting 20 tokens with a value of 50" can be received in the TH-TM.
  • a request from a bank for example a B-TE, "please delete a token with value 100 on R o id" could also - alternatively - already include a public token reference element R o id to be deleted, then TH-TE is not involved in the destruction of the token T o id to be deleted.
  • the B-TE (external to the TH) names the R o id in step 302.
  • the B-TE sends the request to the TH-TM.
  • the architecture of the TH would be less complex.
  • step 311 a destruction request is optionally received from the TH-TM to the TH-TV.
  • step 312 a temporary token element pair Rtem P 2, rtemp2 is generated.
  • step 313 the temporary token reference element Rtem P 2 is sent from the TH-TV to the TH-TM.
  • a remove command is generated.
  • the remove command can be signed with the TH key and reads, for example:
  • step 315 the generated removal command is sent by the secure token destruction unit TH-TV.
  • the remove command instructs the token reference register TRR to remove a token reference of a registered token from the token reference register TRR.
  • step 317 the temporary token reference element Rtem P 2 is received from the TH-TM in the TH-TE.
  • step 318 a replacement command is generated.
  • the command is used to instruct the TRR to register the token reference TRtem P 2 of the internal, temporary token Ttem P 2 instead of the token reference TR o id of the token T o id to be taken back.
  • the replacement command is:
  • step 319 the generated replacement command is sent from the TH-TE to the TH-TM.
  • step 321 the replacement command from step 318 is sent from the TH-TM to the TRR.
  • step 322 the token reference TR o id is replaced with the token reference TR te mp2 in the TRR.
  • a replacement confirmation is optionally received from the TRR to the TH-TM.
  • the replacement confirmation RB can be signed with a TRR key and reads, for example:
  • step 331 the remove command is then sent from the TH-TM to the TRR.
  • the remove command is:
  • step 332 the temporary token reference TRt em 2 is then removed in the TRR.
  • a removal confirmation EB is optionally generated.
  • the distance confirmation EB generated in step 334 is optionally received from the TRR to the TH-TM.
  • the EB can be signed with a TRR key and reads, for example:
  • step 337 the forwarded distance confirmation EB is optionally received by the TH-TE.
  • step 338 the old token T o id is deleted in the TH-TE.
  • step 339 a deletion confirmation is optionally received.
  • step 340 the completion of the destruction is optionally saved in the TH-TM.
  • step 315 is optional because the commands of steps 321 and 331 can be transmitted together and, if transmitted together, either only step 325 or only step 335 or both steps 325 and 335 would take place.
  • the following procedure can be carried out to destroy a token.
  • the TH-TM identifies a token T o id that is present in the payment processor (in a dedicated memory area, or a TH-TE) and is to be deleted.
  • the TH-TM requires the TH-TV to export a public key Rtem P 2 for the token T o id to be deleted.
  • the TH-TV stores the corresponding private key rtem P 2 in its secure memory.
  • TH-TM a switching command is executed from T o id to Tt em 2 creating a registration request RA, b) the registration request RA is sent to the TRR and c) a registration confirmation is received from the TRR with confirmation of the registration of the switch
  • the TH-TM exports a deletion request to the TH-TV ("Melting Order") to delete (destroy) the token Ttem P 2 and attaches the registration request RA and registration confirmation RB of the TRR.
  • the TH-TV verifies the deletion request, registration request RA and registration confirmation RB of the TRR.
  • the CMS executes a DELETE command (DESTROY) on the token Tt e m P 2 using the private key pKeyiH of the TH-TV and the private key rt emp 2.
  • DESTROY DELETE command
  • the TH-TV exports the delete command to the TH-TM creating a registration request RA.
  • the TH-TM sends the registration request RA regarding the DELETE command to the TRR. Once the DELETE command is registered in the TRR, the token Tt emp 2 is deleted (it no longer exists for the TRR).
  • the deletion process can be a fully automated process without manual interaction. If an Air-Gap AG is also required here (possibly a system requirement), a batch processing (batch run) can be carried out for all tokens to be deleted, in which all required public keys are requested in advance from the CMS, for example at the end of a business day (for the deletions of the business day). Alternatively, all tokens to be deleted are first combined (connected, MERGE) and only one connected token is finally deleted.
  • Each command can be signed in order to check that the sender of the token reference TR also has the associated token T.
  • An ECDSA scheme can be used as a signature.
  • a command is preferably signed with the secret token element, for example the private part r, of the token T.
  • a further signature from the token issuer unit TH can be required to ensure that these commands were generated by a privileged unit of the transaction system TS.
  • FIG. 4 shows an exemplary embodiment of a flow diagram of a method for transmitting a token T between a TE1 and a TE2 based on a switching command of an existing token T a .
  • a token T a is present in TE1.
  • the token T a has a token value v a and the private part r of the token-specific key pair.
  • the associated token reference TR a is registered on the TE1 in the token reference register TRR.
  • a token Tb with the token value vb is to be transferred between TE1 and TE2.
  • the TE1 sends transmission information Ü or token information (for example the token value vb itself) to the TE2.
  • This token information can be a declaration of intent from TE1 to TE2 to transfer the token Tb - for example as part of a payment transaction.
  • TE2 then generates a new random number rb, which serves as the private part (the secret) of a new cryptographic token-specific key pair.
  • the public part Rb of the key pair is generated in the TE2.
  • TE2 then sends the public part Rb of the key pair back to TE1. If TE2 already knows the token value vb (e.g. the token value expected as part of the payment transaction or the token information provided by TE1 is the token value vb), TE2 can also send the token reference TRb to TE1.
  • vb e.g. the token value expected as part of the payment transaction or the token information provided by TE1 is the token value vb
  • the token T a is now switched to the token Tb to be transmitted.
  • a registration request RA Sig T a is then created and sent from the TE1 to the TRR.
  • the registration request RA then contains the command "SWITCH" or a corresponding command code according to FIG. 2a, the input token reference TR a and the public part Rb or the output token reference TRb.
  • This registration request RA is with the random number r a of the token T a signed.
  • the signed registration request RA S ig_T a is sent by the subscriber unit TE1 to the token reference register TRR. There the signature is checked.
  • the token value v a is compared with the token value vb.
  • the token reference TR a is deleted or marked as deleted in the token reference register TRR and the token reference TRb is entered into the token reference register TRR. From this point on, the token Tb is registered on the TE2. The success of the registration is reported by the TRR to the TE1 as a registration confirmation RB.
  • the registration confirmation includes the token reference TRb. To secure the process, this registration confirmation can be signed by the TRR.
  • the registration confirmation RB can be sent from TE1 to TE2 to inform TE2 of the success of the registration.
  • TE2 can then validate the registration confirmation RB again. This means that the token Tb with the token value vb and the private part n? from TE1 to TE2 without having to transfer the token with both token elements from TE1 to TE2.
  • the generated public part Rb is therefore transferred to TE1.
  • TE1 takes over the registration using a switching command "SWITCH”.
  • a confirmation RB is sent back, if necessary with a signature of the TRR Sig (vb, Rb) for the generated public part Rb and the token value vb.
  • a final switching in TE2 is therefore unnecessary The process is therefore less complex.
  • FIG. 5 shows an exemplary embodiment of a flow diagram of a method for connecting a token Ta with a token T e and registering the connected token Tf in the TRR.
  • the required signed registration requests RA S ig_Td and RA S ig_Te as well as the command structure from both the perspective of the TE layer and the TR layer are shown in a table.
  • a random number rf is generated in a TE1 of the TE layer. Based on this, a public part Rf is then created. In addition, a sum is formed from the token values va and v e to the token value Vf based on the input tokens Td and T e .
  • a registration request RA then contains the command "MERGE" or the command code listed in FIG. 6a, the two input token references TRd and TR e as well as the output token reference TRf.
  • This registration request RA is signed once with the random number ra of the token Td, to receive a first signed registration request RA S ig_Td.
  • This registration request is also signed with the random number r e of the token T e to receive a second signed registration request RA S ig_Te.
  • Both signed registration requests RA S ig_Td and RA S ig_Te are sent by the Subscriber unit TE1 is sent to the token reference register TRR, where the signatures are stored the registration requests RA S ig_Td and RA S ig_Te checked.
  • the connected token Tf (which has since been transmitted from TE1 to TE2) can now be checked for validity by the subscriber unit TE2 in the TRR.
  • FIG. 6 shows a further embodiment of a token reference register TRR of a transaction system TS. It is indicated here that several storage units 1 can be kept in the token reference register TRR in order to accelerate the storage of a large number of token references TR. It is also indicated here that several verification units 2 can be kept in the token reference register TRR in order to accelerate verification of registration requests RA.
  • a subscriber unit B-TE is shown, which is arranged as a special bank subscriber unit between the token issuer TH and the subscriber unit TE1.
  • FIG. 6 also shows a registration request unit RAE, which can receive a sequence of registration requests RA from a subscriber unit TE1.
  • the TE connects a received token T with the token T stored in the token storage (MERGE).
  • the TE splits a token T to be sent from the token T stored in the token memory (SPLIT).
  • SPLIT token memory
  • These modifications to the token T can be carried out without a registration request RA and the token T can be passed on immediately after a modification. There may therefore be a sequence of modifications to token T that are not known to the TRR.
  • the sequence of registration requests RA consists of a combination of SPLIT and MERGE modifications. Each of these modifications is also saved as a “proof” (see above for FIG. 1) or signed registration request RA Sig with the token T. This creates a sequence of registration requests RAF in the TE.

Abstract

Die Erfindung betrifft ein Verfahren zur sicheren Generierung eines herausgebbaren Tokens durch einen Tokenherausgeber eines elektronischen Transaktionssystems mit Tokenreferenzregister. Die Erfindung betrifft auch ein Verfahren zur sicheren Vernichtung eines Tokens eines elektronischen Transaktionssystems mit Tokenreferenzregister. Die Erfindung betrifft auch einen Tokenherausgeber. In einer Tokenherausgebereinheit, welche eine sichere Tokengenerierungseinheit umfasst, werden folgende Schritte ausgeführt: Erzeugen eines tokenindividuellen Tokenelementpaares, welches ein geheimes Tokenelement und ein öffentliches Tokenreferenzelement umfasst; Erzeugen eines Hinzufügungs-Kommandos, welches das Tokenreferenzregister anweist, eine Tokenreferenz, die das erzeugte öffentliche Tokenreferenzelement umfasst, als zusätzliche Tokenreferenz in dem Tokenreferenzregister hinzuzufügen; und Senden des Hinzufügungs-Kommandos an das Tokenreferenzregister. Vorliegend ist das erzeugte Tokenelementpaar ein internes, temporäres Tokenelementpaar der Tokenerzeugungseinheit, wobei die Tokenerzeugungseinheit eine Tokenreferenz des herausgebbaren Tokens empfängt, und ein Ersetzungs-Kommando erzeugt, welches das Tokenreferenzregister anweist, anstelle der Tokenreferenz des temporären Tokenelementpaares die Tokenreferenz des herausgebbaren Tokens zu registrieren.

Description

VERFAHREN ZUR SICHEREN GENERIERUNG EINES HERAUSGEBBAREN TOKENS, VERFAHREN ZUR SICHEREN VERNICHTUNG EINES TOKENS UND TOKENHERAUSGEBER
Die Erfindung bezieht sich auf ein Verfahren zur sicheren Generierung eines herausgebbaren Tokens durch einen Tokenherausgeber eines elektronischen Transaktionssystems mit Tokenreferenzregister. Die Erfindung bezieht sich auch auf ein Verfahren zur sicheren Vernichtung eines Tokens eines elektronischen Transaktionssystems mit Tokenreferenzregister. Die Erfindung bezieht sich auch auf einen Tokenherausgeber.
Für tokenbasierte Transaktionssysteme ist es bekannt, ein Tokenreferenz-Register bereit zu stellen. Der Tokenherausgeber kann eine Tokenreferenz eines herausgebbaren Tokens initial im Tokenreferenz-Register registrieren oder eine bereits registrierte Tokenreferenz eines zurückzunehmenden Tokens löschen. Teilnehmer des Transaktionssystems dürfen dementgegen eine Tokenreferenz des Tokens beispielsweise nur im Austausch gegen eine bereits registrierte Tokenreferenz eines wertgleichen Tokens registrieren.
In digitalen Zentralbank-Währungs-Systemen (CBDC-Systeme) werden besonders hohe Sicher heitsanf or derungen an die zentralen Systemkomponenten, beispielsweise an den Tokenherausgeber, gestellt.
Die WO 2022/008319 Al beschreibt einen Tokenherausgeber, welcher eine isolierte Tokengenerierungseinheit und eine Tokenausgabeeinheit umfasst. Ein privater Schlüssel eines kryptografischen Schlüsselpaars des Tokenherausgebers kann in einem Hardware-Sicherheitsmodul der Tokengenerierungseinheit gespeichert sein. Auf Anforderung der Tokenausgabeeinheit generiert die Tokengenerierungseinheit einen neuen Token sowie einen signierten Registrierungsdatensatz, welcher die Registrierung des neuen Token mittels einer Tokenreferenz im Tokenreferenzregister ermöglicht. Die Tokenausgabeeinheit erhält den herauszugebenden Token und den Tokenregistrierungsdatensatz. Sie registriert den herauszugebenden Token mittels des Tokenregistrierungsdatensatz im Tokenreferenzregister, bevor sie den neuen Token an eine Teilnehmereinheit des Transaktionssystems ausgibt.
Der Erfindung liegt nun die Aufgabe zu Grunde, eine noch sichere Tokenherausgebereinheit und ein besonders sicheres Verfahren zur sicheren Generierung oder Vernichtung von Token des Transaktionssystems bereitzustellen. Vorzugsweise soll die Lösung flexibel sein, ohne die Sicherheit im Transaktionssystem zu gefährden.
Die gestellte Aufgabe wird gelöst durch den Gegenstand der unabhängigen Patentansprüche. Weitere vorteilhafte Ausgestaltungen sind in den jeweils abhängigen Patentansprüchen beschrieben.
In einem ersten Aspekt wird die Aufgabe insbesondere durch ein Verfahren zur sicheren Generierung eines herausgebbaren Tokens durch einen Tokenherausgeber eines elektronischen Transaktionssystems mit Tokenreferenzregister gelöst. In einer Tokenherausgebereinheit, welche eine sichere Tokengenerierungseinheit, umfasst, werden folgende Schritte ausgeführt: Erzeugen eines tokenindividuellen Tokenelementpaares, welches ein geheimes Tokenelement und ein öffentliches Tokenreferenzelement umfasst, in der sicheren Tokenerzeugungseinheit ; Erzeugen eines Hinzufügungs-Kommandos in der sicheren Tokenerzeugungseinheit, welches das Tokenreferenzregister anweist, eine Tokenreferenz, die das erzeugte öffentliche Tokenreferenzelement umfasst, als zusätzliche Tokenreferenz in dem Tokenreferenzregister hinzuzufügen; Senden des Hinzufügungs-Kommandos an das Tokenreferenzregister. Das erzeugte Tokenelementpaar ist ein internes, temporäres Tokenelementpaar der Tokenerzeugungseinheit. Die Tokenerzeugungseinheit empfängt eine Tokenreferenz des herausgebbaren Tokens. Die Tokenerzeugungseinheit erzeugt ein Ersetzungs-Kommando, welches das Tokenreferenzregister anweist, anstelle der Tokenreferenz des temporären Tokenelementpaares die Tokenreferenz des herausgebbaren Tokens zu registrieren.
Ein Token enthält einen Tokenwert als Tokenelement.
In einer Ausgestaltung umfasst die Tokenherausgebereinheit eine sichere Tokenspeichereinheit (nachfolgend auch Tokenherausgeber-Teilnehmereinheit), wobei diese sichere Tokenspeichereinheit ein tokenindividuelles Tokenelementpaar des herausgebbaren Token erzeugt.
In einer Ausgestaltung liegt das geheime Tokenelement des internen, temporären Tokenelementpaares nur in der Tokengenerierungseinheit vor und/ oder das geheime Tokenelement des herausgebbaren Token liegt nur in der Tokengenerierungseinheit vor. Ein Token enthält ein geheimes Tokenelement des Tokenelementpaares. Eine Tokenreferenz enthält ein öffentliches Tokenreferenzelement des Tokenelementpaars. Das öffentliche Tokenreferenzelement ist eindeutig einem Token zugeordnet und/oder aus dem geheimen Tokenelement des Tokenelementpaares abgeleitet. In einer Ausgestaltung ist das geheime Tokenelement eine Zufallszahl und das öffentliche Tokenreferenzelement das Ergebnis einer kryptografischen Funktion auf das geheime Tokenelement. In einer Ausgestaltung ist das geheime Tokenelement ein privater Schlüssel eines kryptografischen Schlüsselpaars und das öffentliche Tokenreferenzelement ist der öffentliche Schlüssel des kryptografischen Schlüsselpaars.
Der Tokenwert des internen temporären Tokens entspricht dem Tokenwert des herauszugebenden Tokens. Der Tokenwert kann als Information von einer Tokenherausgeberverwaltung, die eine Einheit der Tokenherausgebereinheit ist, an die Tokenerzeugungseinheit übermittelt werden. Alternativ werden Tokenwerte mit festen Denominationen erzeugt.
Durch dieses Verfahren wird der in der Tokengenerierungseinheit durch ein Erzeugen-Schritt erzeugte interne temporäre Token nicht direkt an die Tokenverwaltungseinheit übermittelt. Für den ersten Aspekt vorteilhaft ist, dass die Tokengenerierungseinheit nach dem Erzeugen des internen temporären Tokens ein Ersetzungskommando (insbesondere ein tokenwertneutrales Ersetzen, beispielsweise durch eine Umschalten-Modifikation, eine Verbinden-Modifikation (mit einem Token vom Wert „0" oder eine Aufteilen-Mo difikation (Erhalt eines Tokens mit Wert „0")), erzeugt, um auf einen herauszugebenden (neuen) Token zu referenzieren. Das für das Ersetzen benötigte öffentliche Tokenreferenzelement (R) des Tokenelementpaares (r, R) wird dazu beispielsweise von der Tokenherausgeberverwaltungseinheit (einer Einheit der Tokenherausgebereinheit) oder einer Bankenteilnehmereinheit oder einer Zentralbank-Teilnehmereinheit bereitgestellt.
Mit dem Registrieren der Tokenreferenz des herauszugebenden neuen Tokens beim Tokenreferenzregister ist der neue Token im Transaktionssystem gültig und kann verwendet werden.
In einer Ausgestaltung hält der Tokenherausgeber in einem sicheren Speicherbereich (beispielsweise in der Tokenherausgeber-Teilnehmereinheit) neu herausgebbare (aber noch nicht herausgegebene) Token vor. Auf Anfrage von einer Teilnehmereinheit, beispielsweise einer Bankenteilnehmereinheit des Transaktionssystems, kann dann sofort (ohne das sichere Generierungs-Verfahren dann erst durchführen zu müssen) der herausgebbare Token an die anfragende Teilnehmereinheit im Transaktionssystem ausgegeben werden.
In einer alternativen Ausgestaltung kann vor dem Erzeugen des tokenindividuellen Tokenelementpaares eine Tokengenerierungsanfrage, bevorzugt in einer sicheren Tokenherausgeberverwaltung der Tokenherausgebereinheit, empfangen werden.
Diese Tokengenerierungsanfrage kann von einer Teilnehmereinheit, beispielsweise einer Bankenteilnehmereinheit des Transaktionssystems, gesendet worden sein. Alternativ kann diese Tokengenerierungsanfrage von einer Zentralbankinstanz gesendet worden sein.
Es können CDBC-Wallets (=Geldbörsen) in den Teilnehmereinheiten, beispielsweise einer Bankenteilnehmereinheit des Transaktionssystems, vorhanden sein, die mit der Tokenherausgebereinheit interagieren für eine Bestellung (Anfrage, Generierung) oder Rückgabe (Einlösung, Vernichtung) von CDBC.
Bevorzugt wird im Erzeugen-Schritt der herausgebbare Token mit einem privaten Schlüssel der Tokenherausgebereinheit, beispielsweise mit einem privaten Schlüssel der Tokengenerierungseinheit signiert. Durch die Signatur mit dem privaten Schlüsselteil kann nun jede Teilnehmereinheit des Transaktionssystems mit dem dazugehörigen öffentlichen Schlüsselteil prüfen, ob der Token vertrauenswürdig erzeugt wurde. So wird sichergestellt, dass der Token von einem Tokenherausgeber und nicht von einem Angreifer ausgestellt wurde. Durch das erfindungsgemäße Verfahren verlassen weder der Schlüsselteil des kryptographischen Schlüsselpaares der Tokenherausgebereinheit noch das geheime Tokenelement die Tokengenerierungseinheit. Es ist damit möglich, den Tokenherausgeber modular in eine Tokenherausgeber-Verwaltungseinheitund eine Tokengenerierungseinheit zu zerlegen. Beide Einheiten der Tokenherausgebereinheit können nun örtlich voneinander entfernt angeordnet sein, ohne dass die Sicherheit verschlechtert wird. Mit der räumlichen Entferntheit kann die Tokenherausgebereinheit flexibler und modularer aufgebaut werden. Bevorzugt wird im Ersetzungs-Kommando-Erzeugenschritt der neue Token mit dem privaten Teil des temporären tokenindividuellen kryptografischen Schlüsselpaars signiert. Damit zeigt die Tokengenerierungseinheit an, dass sie in Kenntnis von dem temporären Token und dem neuen Token war. Diese Signatur kann eine Pflichtangabe für das Ersetzungs-Kommando sein.
Bevorzugt wird zum Registrieren des herausgebbaren Tokens das Ersetzungskommando im Tokenreferenzregister auf Gültigkeit geprüft, indem eine Signatur der Tokenherausgebereinheit mittels eines öffentlichen Schlüsselteils der Tokenherausgebereinheit geprüft wird.
Bevorzugt wird die Registrieranfrage im Tokenreferenzregister zudem auf Gültigkeit geprüft, indem eine Signatur mittels dem öffentlichen Tokenreferenzelements des Tokenelementpaars geprüft wird.
Das Hinzufügungs-Kommando und das Ersetzungs-Kommando werden bevorzugt zusammen in einem gemeinsamen Sendeschritt an das Tokenreferenzregister gesendet. In Folge des gemeinsamen Sendens wird eine Hinzufügungs-Bestätigung (erzeugt vom Tokenreferenzregister) und/ oder eine Ersetzungs-Bestätigung (erzeugt vom Tokenreferenzregister) in der Tokenherausgebereinheit empfangen.
Bevorzugt sendet das Tokenreferenzregister eine Registrierbestätigung (= Ersetzungsbestätigung), wenn das Ersetzungs-Kommando gültig ist.
Bevorzugt überträgt die Tokenherausgeber -Verwaltungseinheit der Tokenherausgebereinheit nach Erhalten der Registrierbestätigung (= Ersetzungsbestätigung), den neu herauszugebenden Token aufweisend den Tokenwert und das geheime Tokenelement des Tokenelementepaars an eine Teilnehmereinheit, bevorzugt eine Bank-Teilnehmereinheit.
In einem zweiten Aspekt ist ein Verfahren zur sicheren Vernichtung eines Tokens durch einen Tokenherausgeber eines elektronischen Transaktionssystems mit Tokenreferenzregister vorgesehen, wobei in einer Tokenherausgebereinheit, welche eine sichere Tokenvernichtungseinheit umfasst, die folgenden Schritte ausgeführt werden: Erzeugen eines Entfernen-Kommandos in der Tokenvernichtungseinheit, welches das Tokenreferenzregister anweist, eine Tokenreferenz eines registrierten Tokens aus dem Tokenreferenzregister zu entfernen; und Senden des Entfernen- Kommandos an das Tokenreferenzregister. Die Tokenvernichtungseinheit erzeugt vor dem Erzeugen des Entfernen-Kommandos einen internen, temporärer Token und erzeugt das Entfernen-Kommando für die Tokenreferenz des internen, temporären Tokens. Zudem erfolgt das Erzeugen eines Ersetzungs-Kommandos, welches das Tokenreferenzregister anweist, anstelle der Tokenreferenz des zurück zu nehmenden Tokens die Tokenreferenz des internen, temporären Tokens zu registrieren.
Der zweite Aspekt ist - in Analogie zum sicheren Generieren eines Tokens gemäß erstem Aspekt - nun auf das Vernichten (Löschen) eines Tokens im Transaktionssystem gerichtet. Vorteile und technische Aufgaben entsprechen denen des ersten Aspekts.
Insbesondere wird durch das Verfahren gemäß dem zweiten Aspekt der in der Tokenvernichtungseinheit durch ein Erzeugen-Schritt erzeugte interne temporäre Token nicht direkt an die Tokenverwaltungseinheit übermittelt. Für den zweiten Aspekt vorteilhaft ist, dass die Tokenvernichtungseinheit nach dem Erzeugen des internen temporären Tokens ein Ersetzungs-Kommando (insbesondere ein tokenwertneutrales Ersetzen, beispielsweise durch eine Umschalten-Modifikation, eine Verbinden-Modifikation (mit einem Token vom Wert „0" oder eine Aufteilen- Modifikation (Erhalt eines Tokens mit Wert „0")), erzeugt, um anstelle der Tokenreferenz des zurück zu nehmenden (zu vernichtenden) Tokens die Tokenreferenz des internen, temporären Tokens zu registrieren. Die für das Ersetzen benötigte Tokenreferenz des zurück zu nehmenden Tokens wird dazu beispielsweise von der Tokenherausgeberverwaltungseinheit (einer Einheit der Tokenherausgebereinheit) oder einer Bankenteilnehmereinheit oder einer Zentralbank-Teilnehmereinheit bereitgestellt.
Damit verhindert werden kann, dass der zu vernichtende (=zu löschende) Token während der Übergabe an die Tokenherausgeber-Vernichtungseinheit gestohlen wird, wird erfindungsgemäß ein Ersetzungs-Kommando mit dem Entfernen-Kommando kombiniert.
Die Tokenherausgebereinheit umfasst eine sichere Tokenspeichereinheit, wobei die sichere Tokenspeichereinheit den zurück zu nehmenden Token deaktiviert.
Das geheime Tokenelement des internen, temporären Tokens liegt bevorzugt nur in der Tokenvernichtungseinheit vor. Das Entfernen-Kommando und das Ersetzungs-Kommando können zusammen in einem gemeinsamen Sendeschritt an das Tokenreferenzregister gesendet werden. In Folge des Sendens kann eine Entfernungs-Bestätigung (erzeugt vom Tokenreferenzregister) und/ oder eine Ersetzungs-Bestätigung (erzeugt vom Tokenreferenzregister) in der Tokenherausgebereinheit empfangen werden.
Die Tokenherausgebereinheit kann eine sichere Tokenverwaltungseinheit umfassen, wobei in der Tokenverwaltungseinheit eine Tokenvernichtungsanfrage empfangen wird.
In einer Ausgestaltung wurde der zu vernichtende (zu löschende, zurückzunehmende) Token aus einem Löschverzeichnis der Tokenherausgeberverwaltung entnommen. Dieses Löschverzeichnis ist ein Speicherbereich in der Tokenherausgebereinheit, in den Teilnehmereinheiten des Transaktionssystems zu löschende (d.h. einzulösende) Token ablegen.
In einer stark bevorzugten Ausgestaltung wird zwischen Tokenerzeugungseinheit und Tokenherausgeberverwaltung eine Air-Gap-Schnittstelle realisiert. Als Air-Gap (englisch für „Luftspalt") oder Air-Wall (englisch für „Luftmauer", in Analogie zu einer Firewall)-Prozess wird hierbei ein Prozess bezeichnet, der die beiden Einheiten (Tokenerzeugungseinheit und Tokenherausgeberverwaltung) voneinander trennt, aber dennoch die Übertragung von Nutzdaten, hier Token, Tokenelementen, Tokenelementpaare, Schlüsselteilen etc., zulässt. Ein Air-Gap-Prozess wird hierbei eingesetzt, um die beiden unterschiedlich vertrauenswürdigen Einheiten voneinander zu isolieren, aber dennoch sicherzustellen, dass Daten der jeweils anderen Einheit verarbeitet werden können.
In einer bevorzugten Ausgestaltung ist die Air-Gap-Übermittlung dazu eingerichtet, die Tokenerzeugungseinheit von der Tokenherausgeberverwaltung physisch, logisch, elektrisch und/oder elektronisch zu trennen. Damit sind beide Einheiten elektrotechnisch voneinander in der Form isoliert. Mit anderen Worten: Eine Datenübertragung findet nicht ausschließlich elektrisch/ elektronisch statt. Somit hat ein Angreifer mit Netzwerkfernzugriff auf die Tokenherausgeberverwaltung keinen Zugriff auf die Tokenerzeugungseinheit. Dem Angreifer ist es deshalb nicht möglich, Daten in die Tokenerzeugungseinheit einzubringen und/oder Daten (beispielsweise den temporären Token oder den privaten Teil des Tokenherausgeber-Schlüsselpaars) von der Tokenerzeugungseinheit abzugreifen. Dazu fehlt eine (permanente, physische) Datenverbindung (OSI-Schicht 1) zwischen der Tokenerzeugungseinheit und der Tokenherausgeberverwaltung.
In einer bevorzugten Ausgestaltung erfolgt das Übertragen im Air-Gap-Prozess unter Verwendung von portablen elektronischen Datenspeichern, wie USB-Stick, Speicherkarte, CD, oder ähnlichem. Dafür sind an der Tokenerzeugungseinheit und der Tokenherausgeberverwaltung entsprechende elektronische Schnittstellen, wie USB- Anschluss, Speicherkarten-Lesegerät oder CD-Laufwerk vorgesehen
In einer bevorzugten Ausgestaltung ist zum Übermitteln im Air-Gap-Prozess die Tokenerzeugungseinheit ferner eingerichtet, einen, den Token repräsentierenden, Ausdruck (als physischen Repräsentanten eines Tokens) zu erzeugen. Die Tokenherausgeberverwaltung ist dazu eingerichtet, den von der Tokenerzeugungseinheit erzeugten Token-Ausdruck einzulesen. Dies stellt eine vergleichsweise einfache Form der Realisierung eines Air-Gap-Prozesses dar. Der Ausdruck kann beispielsweise über mechanische Fördermechanismen in einen Einlese-Bereich der Tokenherausgeberverwaltung transportiert werden. Auch hierzu können die bereits beschriebene Transportboxen verwendet werden, sodass beispielsweise ein Ausdruck automatisch von der Tokenerzeugungseinheit in einer Transportbox angeordnet wird, dann zur Tokenherausgeberverwaltung, insbesondere deren Lesebereich, transportiert wird, und dort eingelesen wird.
In einer bevorzugten Ausgestaltung erfolgt das Löschen aller, innerhalb eines vordefinierten Zeitabschnitts, zu löschenden Token als Stapelverarbeitung (=Batchverarbeitung) am Ende des vordefinierten Zeitabschnitts. Damit werden die Übermitteln-Schritte an nur einem bestimmten Zeitpunkt innerhalb einer reduziert, wodurch der Aufwand - insbesondere bei Air-Gap-Prozessen - stark minimiert wird.
Bevorzugt werden alle, innerhalb eines vordefinierten Zeitabschnitts, zu löschenden Token am Ende des vordefinierten Zeitabschnitts zu einem gemeinsamen Löschtoken vor dem Ausführen des Verfahrens gemäß dem zweiten Aspekt durch Anwenden von einem oder mehreren Verbinden-Kommandos verbunden. Damit reduziert sich die Anzahl der Übermitteln-Schritte enorm, woraufhin der Aufwand für Erzeugen und/ oder Löschen von Token Bevorzugt ist der vordefinierte Zeitabschnitt ein Monat, bevorzugt eine Woche, mehr bevorzugt ein Tag, weiter bevorzugt eine Stunde.
Bevorzugt sendet das Tokenreferenzregister eine Hinzufügungs-Bestätigung, wenn das Hinzufügungskommando gültig ist und die temporäre Tokenreferenz im Tokenreferenzregister hinzugefügt wurde. Damit erfährt die Tokenherausgebereinheit, insbesondere die sichere Tokenherausgeber- Verwaltungseinheit, dass die temporäre Tokenreferenz im Tokenreferenzregister vorhanden ist.
Ein elektronisches Transaktionssystem, beispielsweise ein digitales Währungssystem bzw. ein digitales Zentralbanksystem ist ein System in dem zumindest zwei, bevorzugt eine Vielzahl von Teilnehmereinheiten digitales Zentralbankgeld (CDBC) in Form von Token direkt untereinander austauschen (übertragen) können. Das Transaktionssystem ist damit beispielsweise ein Bezahltransaktionssystem zum Austausch von geldwerten Beträgen in Form von Bezahl-Token.
Ein Token ist ein zwischen Teilnehmereinheiten direkt austauschbarer Datensatz eines Transaktionssystems. Mit Registrieren einer Tokenreferenz im Tokenreferenz-Register gilt der Token als erzeugt und/oder gelöscht und/oder übertragen und ab diesem Zeitpunkt ist eine empfangende Teilnehmereinheit im Besitz des Tokenwerts, den der Token repräsentiert. Mit dem Übertragenvorgang wechselt der Token demnach automatisch den Besitzer (von Herausgeber an Teilnehmereinheit). Ein Token - ein Datensatz, der unabhängig von einer Transaktionstopologie, wie Blockchain- Topologien „Bitcoin", „Ethereum" oder „Neo", übertragbar ist - kann direkt zwischen Teilnehmereinheiten bzw. von dem Tokenherausgeber ohne dazwischengeschaltete Einheiten übertragen werden.
In einer Ausgestaltung ist der Token ein elektronischer Münzdatensatz oder Bezahl- Token, um geld werte Beträge zwischen Teilnehmer einheiten zu tauschen. Umgangssprachlich wird ein derartiger Bezahl-Token auch als „digitale Münze" oder „elektronische Münze", englisch „digital/ electronic coin" bezeichnet und repräsentiert Bargeld in elektronischer Form.
Jeder Token im Transaktionssystem ist ein Datensatz umfassend zumindest zwei T okenelemente. Ein erstes Tokenelement jedes Tokens des Transaktionssystems ist ein Tokenwert, bspw. ein Vermögenswert, ein Vermögens gegenstand, ein Wirtschafts gut und/oder ein geldwerter Betrag.
Ein zweites Tokenelement jedes Tokens des Transaktionssystems ist ein geheimes Tokenelement des Tokenelementepaars, beispielsweise der private Teil eines tokenindividuellen Schlüsselpaars. Dieser private Teil ist ein Geheimnis im Transaktionssystem und wird nicht veröffentlicht und darf nicht mehrfach verwendet werden. Die Erzeugung des privaten Teils darf nicht vorhersagbar sein. Dieser private Teil kann eine Zufallszahl sein. Bevorzugt ist die Zufallszahl das Ergebnis eines echten Zufallsgenerators.
Aus dem Tokenwert (erstes Tokenelement) und dem geheimen Tokenelement wird der Token gebildet. Dieses Bilden ist bevorzugt das Verketten (Konkatenation) dieser beiden Tokenelemente. Jede andere Art der Verknüpfung dieser beiden Tokenelemente ist erfindungsgemäß nicht ausgeschlossen und umfasst beispielsweise das Hintereinander- Anfügen, das Einbringen in eine TLV-Datenstruktur und/oder das logische Verknüpfen.
Der Token unterscheidet sich von einem Datensatz zum klassischen Datenaustausch oder Datentransfer, da beispielsweise ein klassischer Datenaustausch auf Basis eines Frage-Antwort-Prinzips bzw. auf einer Interkommunikation zwischen den Partnern des Datenaustauschs stattfindet. Ein Token ist dementgegen einmalig und eindeutig im Transaktionssystem. Der Token steht im Kontext eines Sicherheitskonzepts, welches beispielsweise Signaturen oder kryptografische Verschlüsselungen umfasst. In einem Token sind alle Datenelemente enthalten, die für eine empfangende Teilnehmereinheit bezüglich Verifikation, Authentisierung und Weitergeben des Tokens an eine andere Teilnehmereinheit benötigt werden. Eine Inter kommunikation zwischen den einen Token übertragenden Teilnehmereinheiten ist daher bei einem Token grundsätzlich nicht erforderlich.
Jeder, der im Besitz eines Tokens oder uneingeschränkten Zugriff auf den Token mit seinen Tokenelementen hat, kann diesen Token mit einer anderen Teilnehmereinheit austauschen (=übertragen). Der Besitz des Tokens mit seinen zumindest zwei Tokenelementen (Tokenwert und privater Teil des tokenindividuellen Schlüsselpaars) ist also gleichbedeutend mit dem Besitz des Wertes, den der Token repräsentiert. Hier kann der Token auch indirekt durch Registrieren einer Tokenreferenz übertragen werden.
Jedem Token im Transaktionssystem wird eine Tokenreferenz zugeordnet. Diese Zuordnung ist eineindeutig, das heißt, einem Token ist genau eine Tokenreferenz zugeordnet und jeder Tokenreferenz ist genau ein Token zugeordnet. Die Tokenreferenz ist ein öffentlicher Datensatz, der in einer Speichereinheit des Tokenreferenz-Registers des Transaktionssystems für jede Teilnehmereinheit überprüfbar abgespeichert ist.
Sowohl der Token als auch die Tokenreferenz sind einzigartig. Durch die eineindeutige Zuordnung herrscht eine 1-zu-l Beziehung zwischen dem Token und der Tokenreferenz.
Jede Tokenreferenz im Transaktionssystem ist ein Datensatz umfassend zumindest zwei Tokenreferenz-Elemente.
Ein erstes Tokenreferenz-Element jeder Tokenreferenz ist der Tokenwert des der Tokenreferenz eindeutig zugeordneten Tokens. Der Tokenwert des Tokens ist damit identisch zum Tokenwert der zugeordneten Tokenreferenz. Beispielsweise ist der Tokenwert der Tokenreferenz eine Kopie des Tokenwerts des zugeordneten Tokens.
Ein zweites Tokenelement jeder Tokenreferenz des Transaktionssystems ist ein öffentliches Tokenreferenzelement des Tokenelementpaars, beispielsweise ein öffentlicher Teil des tokenindividuellen Schlüsselpaars. Dieser öffentliche Teil der Tokenreferenz bildet zusammen mit dem privaten Teil des Tokens das tokenindividuelle Schlüsselpaar. Der öffentliche Teil wird durch Anwenden einer kryptografischen Funktion auf den privaten Teil erhalten. Anders: Das öffentliche Tokenreferenzelement und das private Tokenelement bilden das Tokenelementpaar.
Diese kryptografische Funktion ist eine Einwegfunktion. Diese kryptografische Funktion ist demnach 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. 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 Kry ptographie-Verf ährens. Die umgekehrte Funktion, also die Erzeugung eines Tokens (oder des Teils des elektronischen Münzdatensatzes) aus einer Tokenreferenz ist dabei sehr zeitintensiv.
Die (bloße) Kenntnis oder der Besitz einer Tokenreferenz berechtigt nicht dazu, den Tokenwert (Tokenreferenz-Element) zu verwenden/ übertragen/ auszugeben. Dies stellt einen wesentlichen Unterschied zwischen der Tokenreferenz und dem Token dar und ist ein Kern der hier vorliegenden Erfindung.
Nach dem Anwenden der kryptografischen Funktion auf den privaten Teil des tokenindividuellen Schlüsselpaars wird der öffentliche Teil des tokenindividuellen Schlüsselpaars als zweites Tokenreferenz-Element erhalten.
Aus dem Tokenwert (erstes Tokenreferenz-Element) und dem öffentlichen Teil wird die Tokenreferenz gebildet. Dieses Bilden ist bevorzugt das Verketten (Konkatenation) dieser beiden Tokenreferenz-Elemente. Jede andere Art der Verknüpfung dieser beiden Tokenreferenz-Elemente ist erfindungsgemäß nicht ausgeschlossen und umfasst beispielsweise das Hintereinander- Anfügen, das Einbringen in eine TLV- Datenstruktur und/ oder das logische Verknüpfen.
Eine Tokenreferenz kann auch durch eine elektronische Geldbörse (= Wallet) erzeugt werden. Die Verwendung einer Tokenreferenz ist nicht mit der Verwendung von Adressen von Teilnehmereinheiten in einem Blockchain-basierten Transaktionssystem vergleichbar, da im erfindungsgemäßen Tokenreferenz-Register keine Adressen der Teilnehmereinheiten verwendet werden, um eine Verfolgbarkeit der Token zu verhindern.
Das Verfahren zum Registrieren sieht einen Empfangen-Schritt vor, um eine Tokenreferenz in einem Tokenreferenz-Register im Rahmen einer Registrieranfrage zu empfangen. Beispielsweise wird die Registrieranfrage von einer Teilnehmereinheit oder der Tokenherausgeberverwaltung (hier als Hinzufügungs-kommando und Ersetzungskommando) des Transaktionssystems gesendet.
Das Tokenreferenz-Register ist eine Einheit des Transaktionsregisters, in denen Tokenreferenzen abgelegt werden, wodurch die dazugehörigen Token registriert sind. Dieses Register kann eine zentrale Datenbank oder Speichereinheit sein. Dieses Register kann ein dezentraler Ledger, beispielsweise in einer Blockchain-Topologie sein. Das Tokenreferenz-Register kann eine Historie zu den Tokenreferenzen und/ oder den Registrieranfragen führen.
Die empfangene Registrieranfrage wird durch eine Verifiziereinheit im Tokenreferenz-Register verifiziert. Dabei wird verifiziert, ob die zumindest eine Tokenreferenz der empfangenen Registrieranfrage in dem Tokenreferenz-Register bereits gespeichert ist. Im Tokenreferenz-Register ist eine Tokenreferenz nur ein einziges Mal gespeichert. Da eine Tokenreferenz eines Tokens nur ein einziges Mal im Transaktionssystem vorhanden ist, kann durch einen Verifizieren-Schritt festgestellt werden, ob versucht wurde, einen Token mehrfach auszugeben. In einer Ausgestaltung wird im Verifizieren-Schritt festgestellt, ob Signatur (en) der Registrieranfrage korrekt ist.
Zum Ersetzen des Tokens kann eine Umschalte-Modifikation angewendet werden, Für eine Umschalte-Modifikation werden die folgenden Verfahrensschritte durchgeführt: Empfangen der Tokenreferenz von dem Tokenherausgeber für den zu erzeugenden (neuen) Token; Erzeugen einer Registrieranfrage umfassend die Tokenreferenz des temporären Tokens und die Tokenreferenz für den neuen (erzeugten) Token. Die Umschaltung des Tokens ist eine Modifikationsmöglichkeit zur Modifikation eines Tokens. Die in der Registrieranfrage enthaltenen Tokenreferenzen können durch Verkettung (Konkatenation) aneinandergefügt sein. Wird ein Token von einer Teilnehmereinheit direkt an eine andere Teilnehmereinheit übertragen, beispielsweise wenn im Rahmen einer Bezahltransaktion der geldwerte Betrag als Tokenwert übertragen werden soll, so kann die sendende Teilnehmereinheit nun den Tokenwert auf sich umregistrieren lassen. Damit wird im Tokenreferenz-Register die Umschaltung registriert.
Der Tokenwert des temporären Tokens entspricht dem Tokenwert des neuen Tokens. Beim Umschalten wird demnach ein Token mit gleichem Tokenwert aber neuem privaten Teil bei dem Tokenreferenz-Register registriert.
Das Tokenreferenz-Register hat Kenntnis über Tokenreferenzen von Token des Transaktionssystems und führt bevorzugt auch die Verarbeitungen bzw. Modifikationen an den Token (Token-Historie). Die Transaktionen mit den Token wird in dem Tokenreferenz-Register nicht registriert und findet in einer Direkttransaktionsschicht des Transaktionssystems direkt zwischen Teilnehmereinheiten des Transaktionssystems statt.
In einem weiteren Aspekt ist eine Tokenherausgebereinheit eines Transaktionssystems vorgesehen. DieTokenherausgebereinheit kann umfassen: eine Schnittstelle zu einem Tokenreferenzregister; und eine sichere Tokengenerierungseinheit zur sicheren Generierung eines herausgebbaren Tokens mittels eines Verfahrens gemäß dem ersten Aspekt; und/ oder eine sichere Tokenvernichtungseinheit zur sicheren Vernichtung eines Tokens mittels eines Verfahrens gemäß dem zweiten Aspekt.
Die Tokenherausgebereinheit kann weiter umfassen eine Tokenherausgeber- Teilnehmereinheit, eingerichtet zum Ablegen von Token und/ oder Tokenreferenzen; und eine Schnittstelle zu einer Bank-Teilnehmereinheit oder zu einer
Zentralbankeinheit, eingerichtet zum Empfangen einer Tokengenerierungsanfrage und/ oder zum Empfangen einer Tokenvernichtungsanfrage.
Die Tokenherausgebereinheit kann weiter umfassen eine Tokenverwaltungseinheit mit einer Schnittstelle zu einer Bank-Teilnehmereinheit oder zu einer Zentralbankeinheit oder einer Tokenherausgeber-Teilnehmereinheit eingerichtet zum Ausgeben des herausgebbaren Tokens und/ oder Speichern eines Abschlusses der sicheren Vernichtung des Tokens und/ oder Speichern eines Abschlusses der sicheren Generierung des herausgebbaren Tokens.
Die Tokenherausgebereinheit kann weiter umfassen eine Air-Gap-Schnittstelle zwischen der Tokenverwaltungseinheit und der sicheren Tokengenerierungseinheit und/ oder der sicher Tokenvernichtungseinheit.
Bevorzugt umfasst der Tokenherausgeber eine Air-Gap-Schnittstelle zwischen der Tokenherausgeberverwaltung und der Tokenerzeugungseinheit für zumindest einen der Übermitteln-Schritte des Verfahrens gemäß dem ersten und/ oder zweiten Aspekt.
Das Tokenreferenzregister kann eine Instanz eines Zentralwährungssystems sein und jeder Token kann ein digitales Zentralbankgeld sein. Ein digitales Währungs-System als das Transaktionssystem umfasst eine Vielzahl der beschriebenen Teilnehmereinheiten, das Tokenreferenzregister und einen Tokenherausgeber. Eine Teilnehmereinheit, beispielsweise eine Bank-Teilnehmereinheit oder eine Herausgeberteilnehmereinheit kann vorliegend ein sicheres Element (Secure Element) sein, das einen gesicherten Zugriff auf einen oder mehrere Token in einem Tokenspeicher hat. Das sichere Element ist beispielsweise betriebsbereit in einem Endgerät eingebracht. Das sichere Element und oder das Endgerät haben ein spezielles Computerprogrammprodukt (elektronische Geldbörse, Wallet), insbesondere in Form einer abgesicherten Laufzeitumgebung innerhalb eines Betriebssystems eines Endgeräts, englisch Trusted Execution Environments, TEE, gespeichert auf einem Datenspeicher, beispielsweise eines mobilen Endgeräts, einer Maschine oder eines Bankautomaten. Alternativ ist das sichere Element beispielsweise als spezielle Hardware, insbesondere in Form eines gesicherten Hardware-Plattform- Moduls, englisch Trusted Platform Module, TPM oder als ein eingebettetes Sicherheitsmodul, eUICC, eSIM, ausgebildet. Das sichere Element stellt eine vertrauenswürdige Umgebung bereit.
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.
Fig. 1 zeigt ein Ausführungsbeispiel einer Tokenherausgebereinheit;
Fig. 2 zeigt ein Ausführungsbeispiel eines Ablaufs von Schritten eines Verfahrens gemäß dem ersten Aspekt in einer Tokenherausgebereinheit;
Fig. 3 zeigt ein Ausführungsbeispiel eines Ablaufs von Schritten eines Verfahrens gemäß dem zweiten Aspekt in einer Tokenherausgebereinheit;
Fig. 4 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines Umschaltens eines Tokens;
Fig. 5 zeigt ein Ausführungsbeispiel eines Ablauf diagrams eines Verbindens eines Tokens; und
Fig. 6 zeigt ein Ausführungsbeispiel eines Transaktionssystems. Fig. 1 zeigt ein Ausführungsbeispiel eines Tokenherausgebers TH für ein Transaktionssystem TS. Das Transaktionssystem TS kann ein digitales Zentralbank- Währungs-System sein. Der Tokenherausgeber TH gibt Token T als digitale Münzdatensätze an eine Teilnehmereinheit TE, beispielsweise direkt an einen Bankkunden oder bevorzugt an eine Bank-Teilnehmereinheit B-TE heraus. Die Tokenherausgebereinheit TH stellt eine initiale Registrierung des neu-erzeugten (herauszugebenden) Tokens T in einem Tokenreferenzregister TRR des Transaktionssystems TS bereit.
Jeder Token T im Transaktionssystem TS wird initial (nur) von der Tokenherausgebereinheit TH sicher generiert (in der TH-TG) und auch von dem TH sicher vernichtet (gelöscht) (in der TH-TV). Ein Tokenherausgeber TH ist beispielsweise eine Instanz einer Zentralbank oder eine Instanz eines Drittanbieters, der mit einer Zentralbank kooperiert.
Auf Anfrage von einer Zentralbank oder einer Teilnehmereinheit TE oder einer Bank- Teilnehmereinheit (bspw. einer Geschäftsbank) wird das Erzeugen (Erstellen, Generieren) eines Tokens T in dem Tokenherausgeber TH veranlasst. Die Tokenherausgebereinheit TH des Tokenherausgebers hat dazu eine sichere Tokengenerierungseinheit TH-TG und eine sichere Tokenherausgeber- Verwaltungseinheit TH-TW und in einigen Ausgestaltungen auch eine Tokenherausgeber-Teilnehmereinheit TH-TE. Beide Einheiten TH-TG und TH-TW (TH-TE) können voneinander getrennt sein und weisen bevorzugt einen Air-Gap AG auf. Das Air-Gap AG dient dazu, dass die in der Tokenherausgebereinheit TH hochsensiblen sicherheitsrelevanten Daten und Einheiten, insbesondere ein privater Schlüssel pKeyiH und geheime Tokenelemente r (eines Tokenelementepaares) von herauszugebenden (neuen) Token T, beispielsweise private Teile von kryptografischen Schlüsselpaaren (die von einem Zufallsgenerator erzeugt werden) nicht über einen Netzwerkangriff auf den Tokenherausgeber TH ausgelesen und für Manipulationen am Transaktionssystem TS verwendet werden können. Die TH-TG kann dabei vollständig isoliert sein. Beispielsweise ist die TH-TG ohne Schnittstelle zu einem Netzwerk, wie TCP/IP, dem Internet, dem Mobilfunknetz, etc.
Auf Anfrage von einer Zentralbank oder einer Teilnehmereinheit TE oder einer Bank- Teilnehmereinheit (bspw. einer Geschäftsbank) wird das Vernichten (Löschen) eines Tokens T in dem Tokenherausgeber TH veranlasst. Die Tokenherausgebereinheit TH des Tokenherausgebers hat dazu eine sichere Tokenvernichtungseinheit TH-TV und eine sichere Tokenherausgeber-Verwaltungseinheit TH-TW und in einigen Ausgestaltungen auch eine Tokenherausgeber-Teilnehmereinheit TH-TE. Beide Einheiten TH-TV und TH-TW (TH-TE) können voneinander getrennt sein und weisen bevorzugt einen Air-Gap AG auf. Das Air-Gap AG dient dazu, dass die in der Tokenherausgebereinheit TH hochsensiblen sicherheitsrelevanten Daten und Einheiten, insbesondere ein privater Schlüssel pKeyiH und geheime Tokenelemente r (eines Tokenelementepaares) für zu löschende Token T, beispielsweise private Teile von kryptografischen Schlüsselpaaren (die von einem Zufallsgenerator erzeugt werden) nicht über einen Netzwerkangriff auf die Tokenherausgebereinheit TH ausgelesen und für Manipulationen am Transaktionssystem TS verwendet werden können. Die TH-TV kann dabei vollständig isoliert sein. Beispielsweise ist die TH-TV ohne Schnittstelle zu einem Netzwerk, wie TCP/IP, dem Internet, dem Mobilfunknetz, etc.
Eine Tokenherausgebereinheit TH kann sowohl eine TH-TG als auch eine TH-TV aufweisen. Es ist alternativ möglich, dass eine erste Tokenherausgebereinheit des TS nur eine TH-TG aber keine TH-TV aufweist und dass eine zweite Tokenherausgebereinheit des TS nur eine TH-TV aber keine TH-TG aufweist.
Ein Token T wird durch einen Tokenwert v und einen geheimes Tokenelement, beispielsweise eine Zufallszahl r eindeutig im Transaktionssystem TS repräsentiert. Der Tokenwert v kann in einem Wertebereich von 1 bis 231-1 angegeben werden. Die Zufallszahl r kann eine Zahl im Bereich von 0 bis 2256 -1, also die Ordnung einer elliptischen Kurve, beispielsweise secp256rl, sein.
Die Zufallszahl r - als Beispiel für ein geheimes Tokenelement eines Tokens T - ist dabei ein privater Teil eines tokenindividuellen Schlüsselpaars r, R. Die Zufallszahl r ist im Transaktionssystem TS einmalig und geheim und darf nicht veröffentlicht oder wiederverwendet werden. Die Erzeugung der Zufallszahl r darf nichtvorhersehbar sein und wird mittels Echtzufallszahlengenerator erzeugt.
Beispielsweise ist der Tokenwert v ein 32 Bit großes Tokenelement vom Typ integer.
Beispielsweise ist die Zufallszahl r ein 32 Byte großes Tokenelement vom Typ integer. Ein Token kann als ein TLV kodierter Datensatz in einem Tokenspeicher, beispielsweise im CBS abgelegt sein und weist dann einen eindeutigen Tag und eine Längeninformation auf, beispielsweise in folgendem Format auf.
Figure imgf000020_0001
Ein Beispiel eines TLV-codierten Token in hexadezimaler Form ist nachfolgend dargestellt:
4224 00 0040 00 00 01 02 03 04 05 06 0708 09 0A OB 0C 0D 0E 0F 10 11 1213 14 15 16 17 18 191A 1B IC ID IE 1F und wird wie folgt interpretiert:
"42" ist der Tag zur Identifizierung des TLV-kodierten Tokens T;
"24" zeigt die Länge an, hier also, dass es sich um einen 36 Byte großen Datensatz handelt;
"00 0040 00" ist der Tokenwert (integer) v = 16384 und beträgt demnach € 163,84;
"00 01 02 03 04 05 06 0708 09 ... ID IE 1F" ist die Zufallszahl r als integer.
Zur sicheren Generierung eines herausgebbaren Tokens durch einen Tokenherausgeber eines elektronischen Transaktionssystems TS mit Tokenreferenzregister TRR werden auch unter Bezugnahme auf Fig. 2 die folgenden Schritte des Verfahrens gemäß dem ersten Aspekt der Erfindung durchgeführt.
Im Schritt 200 erfolgt optional das Empfangen einer Tokengenerierungsanfrage bei der TH-TM. Die Tokengenerierungsanfrage kann von einer Zentralbankinstanz gesendet werden. Diese Anfrage kann für einen einzelnen Token T oder eine Reihe von Token T sein, beispielsweise „Generiere 200 Token mit Wert 100". Die Anfrage kann einen Zeitraum betreffen, beispielsweise „Generiere 200 Token mit Wert 100 für heute" oder Generiere 200 Token mit Wert 100 in der nächsten Stunde". Im Schritt 201 erfolgt ein optionales Empfangen einer Anfrage für ein neues Tokenreferenzelement. Diese Anfrage kann in der TH-TM bzw. von der TH-TM an die TH-TE empfangen werden.
Im Schritt 202 erfolgt ein optionales Erzeugen eines neuen Tokenelementpaares Rnew, rnew. Ein Tokenelementepaar r, R umfasst insbesondere ein geheimes Tokenelement r (ein Tokenelement des Tokens T) des Tokenelementpaares und ein öffentliches Tokenreferenzelement R (ein Tokenelement der Tokenreferenz TR) des Tokenelementpaares.
Im Schritt 203 erfolgt ein optionales Bereitstellen (Senden) des öffentlichen Tokenreferenzelement Rnew innerhalb der (bzw. an die) TH-TM.
Die optionalen Schritte 200-203 können dabei unterschiedlich ablaufen. Gemäß dem gezeigten Ablauf in der Fig. 2 kann im TH-TM eine allgemeine Anforderung 200 der Zentralbank „wir brauchen heute 200 Token mit Wert 100" oder eine Anforderung für eine Bank-Teilnehmereinheit B-TE „wir brauchen jetzt 20 Token mit Wert 50" empfangen werden.
Eine Anforderung einer Bank, beispielsweise einer B-TE, „bitte ein Token mit Wert 100 auf R_new" könnte jedoch auch - alternativ - bereits einen neues öffentliches Tokenreferenzelement Rnew umfassen, dann ist TH-TE nicht an der Generierung des neuen (herauszugebenden) Tokens beteiligt. In diesem Fall erzeugt die (von der TH externe) B-TE im Schritt 202 das neue Tokenelementpaares R new, Tnew. Im Schritt 203 sendet die B-TE die Anforderung an das TH-TM. In diesem Fall wäre in vorteilhafter Weise keine TH-TE im TH notwendig, die Architektur der TH wäre weniger aufwendig.
Im Schritt 211 erfolgt sodann ein Empfangen einer Tokenerzeugungsanfrage von der TH-TM an die TH-TG.
Im Schritt 212 erfolgt ein Erzeugen eines internen temporären Tokenelementpaares Rtemp, rtemp. Das geheime Tokenelement rtemp des internen, temporären Tokenelementpaares liegt bevorzugt nur in der Tokenerzeugungseinheit TH-TG vor.
Im Schritt 214 erfolgt ein Erzeugen eines Hinzufügungs-Kommandos in der TH-TG. Dazu kann eine Signatur der TH verwendet werden. Das Hinzufügungs-Kommando kann mit einem Schlüssel der TH signiert sein und lautet beispielsweise: SIG_TtemP = sig (sKeym ; CREATE | | TRtemp)
Im Schritt 215 erfolgt ein Senden des Hinzufügungs-Kommandos durch die sichere Tokenerzeugungseinheit TH-TG an die TH-TW. Das Kommando weist das Tokenreferenzregister TRR an, eine Tokenreferenz TR, die das erzeugte öffentliche Tokenreferenzelement umfasst, als zusätzliche Tokenreferenz TR in dem Tokenreferenzregister TRR hinzuzufügen.
Im Schritt 218 erfolgt ein Erzeugen eines Ersetzungs-Kommandos. Das Kommando weist das TRR an, anstelle der Tokenreferenz TRtemp des temporären Tokenelementpaares die Tokenreferenz TRnew des herausgebbaren Tokens Tnew zu registrieren. Das Ersetzungs-Kommando kann mit dem geheimen Tokenelement signiert sein und lautet beispielsweise:
SIG_Tnew = sig (rtemp SWITCH I | TRtemp, TRnew)
Mit einem Ersetzen ist jedwedes betragsneutrales Modifizieren des Tokens gemeint, insbesondere ein Umschalten (Switch)-Kommando, aber auch ein Verbinden (Merge)- Kommando von dem Token Tnew mit einem Token mit einem Tokenwert v = 0 oder auch ein Aufteilen des Tokens Ttemp zu einem Token Tnew und einem Token mit Tokenwert v = 0.
Im Schritt 219 folgt ein Senden des Ersetzungs-Kommandos von der TH-TG an das TH-TM.
Im Schritt 221 erfolgt ein Senden des Hinzufügungs-Kommandos an das TRR. Daraufhin fügt das TRR im Schritt 222 die temporäre Tokenreferenz TRtemp zum Datenbestand hinzu. Das Hinzufügungs-Kommando lautet beispielsweise:
CREATE TRtemp
Im Schritt 224 wird optional durch das TRR eine Hinzufügungs-Bestätigung HB erzeugt. Die HB kann mit einem Schlüssel des TRR signiert sein und lautet beispielsweise:
HB = sig(sKeyTRR; TRtemp) Im Schritt 225 erfolgt dann optional ein Empfangen der Hinzufügungs-Bestätigung HB von dem TRR im TH-TM.
Im Schritt 231 erfolgt dann das Senden des Ersetzungs-Kommandos an das TRR. Das Ersetzungs-Kommando lautet beispielsweise:
SWITCH TRtemp, TRnew
Im Schritt 232 erfolgt dann das Ersetzen der Tokenreferenz TRtemp mit der Tokenreferenz TRnew.
Im Schritt 234 erfolgt dann optional das Erzeugen einer Ersetzungs-Bestätigung RB. Die RB kann mit einem Schlüssel des TRR signiert sein und lautet beispielsweise lautet beispielsweise:
RB = sig(sKeyTRR; TRnew)
Im Schritt 235 erfolgt das Empfangen der Ersetzungs-Bestätigung RB von dem TRR im TH-TM.
Im Schritt 237 erfolgt optional das Empfangen der Ersetzungsbestätigung EB in der TH-TE. Die RB kann lauten:
RB (TR new)/ Vnew
Im Schritt 238 erfolgt optional ein Speichern/ Aktivieren des neuen Token Tnew.
Im Schritt 239 erfolgt optional ein Senden einer Bestätigung für herausgebbare neue Token Tnew
Im Schritt 240 erfolgt optional das Speichern des Abschluss der Generierung in der TH-TM, eine Art Protokollierung des Generierens des neuen Token Tnew. Das TH-TM merkt sich demnach den Abschluss der Generierung in Schritt 240.
Im Schritt 250 erfolgt optional das Ausgaben des neuen Token Tnew an eine B-TE oder eine andere TE des TS. In einer Ausgestaltung der Fig. 2 ist der Schritt 215 optional, denn die Kommandos der Schritte 214 und 218 können gemeinsam übertragen werden. Dann wären die Schritte 221, 231 eine gemeinsame Übertragung der beiden Kommandos und es würde bei gemeinsamer Übertragung entweder nur Bestätigungsschritt 225 oder nur Bestätigungsschritt 235 oder beide Bestätigungsschritt 225 und 235 erfolgen.
In einer weiteren Ausgestaltung der Fig. 2 erfolgt der Schritt 231 von TH-TE oder sogar von der B-TE.
In einer weiteren Ausgestaltung der Fig. 2 wird der Schritt 221 im TRR nur von der TH empfangen, also von der TH-TM oder TH-TE. Dann ändern sich die Abläufe der Schritte 237, 238, 239 entsprechend dahingehend, dass die Ersetzungs-Bestätigung RB nur von TH-TE oder B-TE kommen kann, so dass vnew und/ oder RB in Schritt 237 an das TH-TM kommt und Schritt 238 dazu dient, dass der neue Token T vollständig ist oder als herausgebbar aktiviert ist.
In einer Ausgestaltung kann folgendes Verfahren zur Ausführung kommen, um einen neuen Token zu generieren.
Das TH-TM fordert bei einem Prozessor (Bezahlprozessor) (TH-TE) den öffentlichen Schlüssel Rneu eines neuen Token Tneu an. Der Bezahlprozessor (TH-TE) speichert den dazugehörigen privaten Schlüssel rneu in einer temporären Brieftasche.
Das TH-TM erstellt eine „Minting Order", also eine Anfrage am TH-TG, einen neuen Token bereitzustellen und übermittelt in dieser Anfrage den Tokenwert v und den öffentlichen Schlüssel Rneu (aus Schritt 1) an das TH-TG.
Das TH-TG erstellt einen temporären Token Ttemp bestehend aus dem Tokenwert v und einem temporären privaten Schlüsselteil rtemp eines temporären tokenindividuellen Schlüsselpaars unter Anwendung eines CREATE-Kommandos (Erzeugen-Kommando).
Das TH-TG führt ein Umschalten (=SWITCH-Kommando) von dem temporären Token Ttemp auf den neuen Token Tneu durch. Für das Umschalten benötigt das TH-TG nur den vom TH-TM zur Verfügung gestellten öffentlichen Schlüssel Rneu. Es wird eine Registrieranfrage erstellt, diese enthält die Befehlshistorie (CmdHist) des Umschalte-Kommandos und des Erzeugen-Kommandos. Der Tokenwert v und der private Schlüssel rtemp und die Registrieranfrage RA werden dem TH-TM zur Verfügung gestellt.
Das TH-TM sendet die Registrieranfrage RA an das TRR und erhält eine Regis trier bestätigung RB.
Die Registrierbestätigung RB und auch die Registrieranfrage RA wird an den Bezahlprozessor TH-TE gesendet.
Im Bezahlprozessor TH-TE werden Tokenwert v, privater Schlüssel rtemp, Registrieranfrage RA und Registrierbestätigung geprüft und verifiziert. Der private Schlüssel rneu wird aus dem temporären Wallet entfernt und zusammen mit vneu als Tneu gespeichert.
Für jeden Token T wird im Tokenreferenz-Register TRR eine Tokenreferenz TR gespeichert. Die Tokenreferenz TR umfasst den Tokenwert v des zugeordneten Tokens T und einen öffentlichen Teil R des tokenindividuellen Schlüsselpaars. Die Tokenreferenz TR des Tokens T kann jederzeit im Register TRR des Transaktionssystems TS eingesehen werden. Damit ist der Tokenwert v eines Tokens T durch das Tokenreferenz-Register TRR offengelegt.
Der öffentliche Teil R des tokenindividuellen Schlüsselpaars wird durch Anwenden einer kryptografischen Funktion auf den privaten Teil r des tokenindividuellen Schlüsselpaars erzeugt. Diese Funktion ist schwer umkehrbar und gibt dem Transaktionssystem TS so die gebotene Sicherheit. Es gilt R = r * G, wobei G beispielsweise ein globaler Parameter des Transaktionssystems TS, bspw. ein Generatorpunkt einer elliptischen Kurve, hier der secp256rl-Kurve, sein kann.
Die Tokenreferenz TR wird dann gebildet durch den Tokenwert v des Tokens T und den öffentlichen Teil R des Schlüsselpaars. Die Tokenreferenz TR ist somit die Verknüpfung oder Verkettung von Tokenwert v und öffentlichem Teil R.
Diese Tokenreferenz TR kann als Registrieranfrage RA ggf. zusammen mit einem Kommando bezüglich des Tokens T an das Tokenreferenz-Register TRR gesendet werden. Zusätzlich kann die Registrieranfrage RA mit dem privaten Teil r des tokenindividuellen Schlüsselpaars signiert werden. Das Signieren ermöglicht es, zu verifizieren, ob der Sender der Tokenreferenz TR im Besitz des Tokens T war, wodurch die Sicherheit im Transaktionssystem TS weiter erhöht ist.
In der Teilnehmereinheit TE wird die signierte Registrieranfrage RASig als ein sogenannter Beweisdatensatz, PR (für Proof) abgelegt, beispielsweise in folgendem Format:
Figure imgf000026_0001
Ein Beispiel eines PR (=RASig) in hexadezimaler Form ist nachfolgend dargestellt:
4A 81 8F 03 11 12 13 14 15 16 17 18 19 1A 1B IC ID IE 1F 20 21 22 23 24 25 26 2728 29 2A 2B 2C 2D 2E 2F 30 31 3233 34 35 36 3738 393A 3B 3C 3D 3E 3F 4041 4243444546 4748 494A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 30 46 11 12 13 14 15 16 17 18 19 1A 1B IC ID IE 1F 20 21 22 23 24 25 26 2728 292A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 3738 393A 3B 3C 3D 3E 3F 4041 42434445464748494A 4B 4C 4D 4E 4F 50 51 5253 54 55 56 und wird wie folgt interpretiert:
"4A" ist der Tag zur Identifizierung des TLV-Proof RASI^TH;
"81 8F" zeigt die Länge an;
"03" zeig an, dass es sich um eine Umschalte (=SWITCH) Registrieranfrage handelt;
"11 1213 14" ist der Tokenwert va;
"15 16 17 18 19 1A 1B IC ID IE 1F 20 21 22 23 24 25 26 2728 29 2A 2B 2C 2D 2E 2F 30 31 3233 3435" ist der öffentliche Teil Ra;
"36 3738 39 3A 3B 3C 3D 3E 3F 40 41 4243 44 45 46 4748 494A 4B 4C 4D 4E 4F 50 51 525354 5556" ist der öffentliche Teil Rh; "30 46 11 1213 14 15 16 17 18 19 1A IB 1C ID IE IF 20 21 2223 24 25 26 2728 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 3738 393A 3B 3C 3D 3E 3F 40 41 424344 45 4647 48 494A 4B 4C 4D 4E 4F 5051 5253 5455 56" ist die Signatur als X690-Sequenz.
Diese Registrieranfrage RA kann an das Tokenreferenz-Register TRR gesendet werden. Im Tokenreferenz-Register TRR wird diese Registrieranfrage RA empfangen. Nach Prüfung der Registrieranfrage RA durch das Tokenreferenz-Register TRR wird die Tokenreferenz TR im Tokenreferenz-Register TRR abgelegt, wodurch der Token T im Transaktionssystem TS registriert ist. Ab diesem Zeitpunkt kann der Token T im Transaktionssystem TS verwendet werden.
Diese Tokenreferenz TR ist dem Token T eindeutig zugeordnet und dient zur Registrierung des Tokens T im Transaktionssystem TS. Die Tokenreferenz TR ist demnach die öffentliche Repräsentation des Tokens T. Das alleinige Wissen oder nur der Besitz der Tokenreferenz TR erlaubt es nicht, den Token T zu übertragen und ist nicht gleichbedeutend damit, dass die TE im Besitz des Tokens T ist. Die Tokenreferenz TR dient zur Verhinderung von Mehrfachausgabe-Versuchen und prüft, ob Tokenwerte v in unzulässiger Weise generiert wurden. Deshalb wird im Tokenreferenz-Register TRR die Tokenreferenz TR und ggf. die Historie über die Token T und die entsprechenden Registrieranfragen RA von Teilnehmereinheiten TE abgelegt.
Die Token T werden beispielsweise in elektronischen Geldbörsen, sogenannten Wallets, abgelegt. Diese Wallets sind beispielsweise Softwareapplikationen innerhalb der Teilnehmereinheiten TE oder eines Endgeräts, in dem die TE betriebsbereit eingebracht ist. Ein Wallet kann als Applikation auf einem Smartphone, einer Smartcard oder einem Bezahlterminal eingerichtet sein. Das Wallet dient dazu, Token T der TE sicher zu verwalten, Tokenreferenzen TR zu erzeugen, Token T zu modifizieren und/oder Token T auszutauschen. Wallets dienen dazu, mit dem Tokenreferenz-Register TRR zu kommunizieren, Registrieranfragen RA an das Tokenreferenz-Register TRR zu generieren und/oder Transaktion von Token T zu einer Teilnehmereinheit TE vorzunehmen.
Für eine Direkt-Transaktion von Token T ist es nicht notwendig, dass eine Kommunikations Verbindung zu dem Tokenreferenz-Register TRR des Transaktionssystems TS besteht. Das Transaktionssystem TS ist dazu eingerichtet, eine Transaktion „offline", also ohne Kommunikationsverbindung mit dem Tokenreferenz- Register TRR, durchzuführen. Eine entsprechende Registrierung von Token T kann daher einer Übertragung des Token T zu einer Teilnehmereinheit TE zeitlich nachgelagert sein.
Das Tokenreferenz-Register TRR ist eine Einheit des Transaktionssystems TS und ist entweder ein zentrales Register oder eine zentrale Datenbank des Transaktionssystems TS oder ein dezentrales Register oder eine dezentrale Datenbank (DLT) des Transaktionssystems TS.
Das Tokenreferenz-Register TRR verwaltet insbesondere den Speicherort für die Tokenreferenzen TR, als Beispiel einer Speichereinheit im Tokenreferenz-Register TRR dargestellt. Stellvertretend ist in der Datenbank 1 das TR zum Token T der Teilnehmereinheit TE1 eingetragen.
Zudem kann das Tokenreferenz-Register TRR zumindest eine Verifiziereinheit 2 umfassen. Die Verifiziereinheit 2 des Tokenreferenz-Registers TRR verifiziert Registrieranfragen RA. Dabei kann eine syntaktische Korrektheit oder auch die korrekte Angabe eines Kommandos in der Registrieranfrage RA verifiziert werden. Auch eine Historie aus alten (vergangenen) Registrieranfragen RA bezüglich eines Tokens T kann dabei verifiziert werden. Die Trennung dieser Verifiziereinheit 2 von der Datenbank 1 verteilt die Aufgaben von Ablegen und Prüfen und erhöht die Geschwindigkeit im Tokenreferenz-Register TRR.
Zudem kann das Tokenreferenz-Register TRR eine Prüfeinheit umfassen (nicht explizit dargestellt), die prüft, ob mit dem Tokenwert v einer empfangenen Tokenreferenz TR ein Gesamt-Tokenwert Z im Transaktionssystem TS verändert wird. Ist dies der Fall, dann wurde ein neuer Tokenwert v geschaffen oder ein existierender Tokenwert v vernichtet. Dies dürfen nur privilegierte Einheiten, wie einer Herausgeberinstanz TH, im Transaktionssystem TS. Wenn ein derartiges Verändern der Gesamtsumme der Tokenwerte durch eine Tokenreferenz TR einer Teilnehmereinheit TE erkannt wird, dann kann von einem Betrugsfall ausgegangen werden. Somit kann eine illegale Generierung von Tokenwerten v sehr leicht entdeckt und verhindert werden.
Die Prüfung des Gesamt-Tokenwerts durch die Prüfeinheit stellt ein weiteres Sicherheitskonzept im Transaktionssystem TS dar. Eine Registrieranfrage RA ist bevorzugt mit dem privaten Teil r signiert. Durch die Signatur kann eine syntaktische Echtheit des Kommandos durch den Empfänger (TRR oder TE) einfach geprüft werden. Diese Prüfung erfolgt bevorzugt in der Datenbank 1 oder der Verifiziereinheit 2. Zudem kann eine Registeranfrage RA beispielsweise syntaktisch validiert werden durch Prüfen der Signatur und/ oder der Tokenreferenz TR.
Auch wenn eine Signatur in einer Teilnehmereinheit TE geprüft werden kann, so wird damit nicht sichergestellt, dass keine Mehrfachausgabe des gleichen Tokens T versucht wurde. Daher ist das Registrieren im Tokenreferenz-Register TRR vorgesehen. Zudem wird durch die Teilnehmereinheiten TE eine sichere Hardwareplattform vor gehalten. Mit verfügbarer Verbindung zum Tokenreferenz- Register TRR werden die Tokenreferenzen TR übertragen und im Tokenreferenz- Register TRR kann der Mehrfachausgabe-Versuch entdeckt werden.
Wenn eine Tokenreferenz TR im Tokenreferenz-Register TRR noch nicht bekannt ist, wird sie hinzugefügt.
In Fig. 3 ist ein Verfahrensablauf zum Vernichten eines Tokens T aus dem Transaktionssystem TS beschrieben. Um zu verhindern, dass der zu vernichtende (=zu löschende) Token Toid während der Übergabe an die TH-TV gestohlen wird, wird erfindungsgemäß ein Ersetzungs-Kommando mit dem Entfernen-Kommando kombiniert.
Im Schritt 300 erfolgt ein optionales Empfangen einer Tokenvernichtungsanfrage. Die Tokenvernichtungsanfrage kann von einer Zentralbankinstanz gesendet werden. Diese Anfrage kann für einen einzelnen Token Toid oder eine Reihe von Token Toid sein, beispielsweise „Vernichte 200 Token mit Wert 100". Die Anfrage kann einen Zeitraum betreffen, beispielsweise „Vernichte 200 Token mit Wert 100 für heute (oder in der nächsten Stunde)".
Im Schritt 301 erfolgt ein optionales Empfangen einer Anfrage für ein altes Tokenreferenzelement. Diese Anfrage kann in der TH-TM bzw. von der TH-TM an die TH-TE empfangen werden.
Im Schritt 302 erfolgt optional ein Deaktivieren des/ der alten Token Toid in der TH-TE. Im Schritt 303 erfolgt optional ein Senden des alten Tokenreferenzelements TRoid.
Die Schritte 300-303 können unterschiedlich ablaufen. Gemäß dem Ablauf in der Fig. 3 kann im TH-TM eine allgemeine Anforderung 300 der Zentralbank „wir löschen heute 200 Token mit Wert 100" oder eine Anforderung für eine Bank „wir löschen jetzt 20 Token mit Wert 50" empfangen werden.
Eine Anforderung einer Bank, beispielsweise einer B-TE, „bitte ein Token mit Wert 100 löschen auf Roid" könnte jedoch auch - alternativ - bereits einen zu löschenden öffentliches Tokenreferenzelement Roid umfassen, dann ist TH-TE nicht an der Vernichtung des zu löschenden Tokens Toid beteiligt. In diesem Fall benennt die (von der TH externe) B-TE im Schritt 302 das Roid. Im Schritt 303 sendet die B-TE die Anforderung an das TH-TM. In diesem Fall wäre in vorteilhafter Weise keine TH-TE im TH notwendig, die Architektur der TH wäre weniger aufwendig.
Im Schritt 311 erfolgt ein optionales Empfangen einer Vernichtungs-Anforderung von der TH-TM an die TH-TV.
Im Schritt 312 erfolgt ein Erzeugen eines temporären Tokenelementpaares RtemP2, rtemp2.
Im Schritt 313 erfolgt ein Senden des temporären Tokenreferenzelements RtemP2 von der TH-TV an das TH-TM.
Im Schritt 314 erfolgt das Erzeugen eines Entfernen-Kommandos. Das Entfernen- Kommando kann mit dem Schlüssel der TH signiert sein und lautet beispielsweise:
SIG_TtemP2 = sig (sKeyiH; DESTROY | | TRtemP2)
Im Schritt 315 erfolgt ein Senden des erzeugten Entfernen-Kommandos durch die sichere Tokenvernichtungseinheit TH-TV. Das Entfernen-Kommando weist das Tokenreferenzregister TRR an, eine Tokenreferenz eines registrierten Tokens aus dem Tokenreferenzregister TRR zu entfernen.
Im Schritt 317 erfolgt ein Empfangen des temporären Tokenreferenzelementes RtemP2 von der TH-TM in der TH-TE. Im Schritt 318 erfolgt ein Erzeugen eines Ersetzungs-Kommandos. Das Kommando dient dazu, dem TRR anzuweisen anstelle der Tokenreferenz TRoid des zurück zu nehmenden Tokens Toid die Tokenreferenz TRtemP2 des internen, temporären Tokens TtemP2 zu registrieren. Das Ersetzungs-Kommando lautet beispielsweise:
SWITCH TRoid, TRtemp2
Mit Ersetzen ist jedwedes betragsneutrales modifizieren des Tokens gemeint, insbesondere ein Umschalten (Switch)-Kommando, aber auch ein Verbinden (Merge)- Kommando von dem Token mit einem Token mit einem Tokenwert v = 0 oder auch ein Aufteilen des Tokens zu einem Token und einem Token mit Tokenwert v = 0.
Im Schritt 319 erfolgt ein Senden des erzeugten Ersetzungs-Kommandos von der TH- TE an die TH-TM.
Im Schritt 321 erfolgt ein Senden des Ersetzungs-Kommandos aus dem Schritt 318 von der TH-TM an das TRR.
Im Schritt 322 erfolgt ein Ersetzen der Tokenreferenz TRoid mit der Tokenreferenz TRtemp2 im TRR.
Im Schritt 325 erfolgt optional ein Empfangen einer Ersetzungs-Bestätigung von dem TRR an das TH-TM. Die Ersetzungs-Bestätigung RB kann mit einem Schüssel der TRR signiert sein und lautet beispielsweise:
RB = sig(sKeyTRR, TRtem 2)
Im Schritt 331 erfolgt dann ein Senden des Entfernen-Kommandos von der TH-TM an das TRR. Das Entfernen-Kommando lautet beispielsweise:
DESTROY TRtemP2
Im Schritt 332 erfolgt dann ein Entfernen der temporären Tokenreferenz TRtem 2 im TRR.
Im Schritt 334 erfolgt optional ein Erzeugen einer Entfernungsbestätigung EB. Im Schritt 335 erfolgt optional ein Empfangen der im Schritt 334 erzeugten Entfernungsbestätigung EB von dem TRR an die TH-TM. Die EB kann mit einem Schlüssel der TRR signiert sein und lautet beispielsweise:
EB = sig(sKeyTRR; TRtem 2)
Im Schritt 337 erfolgt optional ein Empfangen der weitergeleiteten Entfernungsbestätigung EB an die TH-TE.
Im Schritt 338 erfolgt ein Löschen des alten Tokens Toid in der TH-TE.
Im Schritt 339 erfolgt optional ein Empfangen einer Löschbestätigung.
Im Schritt 340 erfolgt optional ein Speichern des Abschlusses der Vernichtung in der TH-TM.
In einer Ausgestaltung der Fig. 3 ist der Schritt 315 optional, denn die Kommandos der Schritte 321 und 331 können gemeinsam übertragen werden und es würde bei gemeinsamer Übertragung entweder nur Schritt 325 oder nur Schritt 335 oder beide Schritte 325 und 335 erfolgen.
In einer Ausgestaltung kann folgendes Verfahren zur Ausführung kommen, um einen Token zu vernichten.
Das TH-TM identifiziert einen Token Toid, der im Bezahlprozessor (in einem speziell dafür vorgesehenen Speicherbereich, oder einer TH-TE) vorhanden ist und gelöscht werden soll.
Das TH-TM verlangt von dem TH-TV den Export eines öffentlichen Schlüssels RtemP2 für den zu löschenden Token Toid. Der TH-TV speichert den entsprechenden privaten Schlüssel rtemP2 in seinem sicheren Speicher ab.
Im TH-TM wird a) ein Umschalten-Kommando von Toid auf Ttem 2 unter Erstellen einer Registrieranfrage RA ausgeführt, b) die Registrieranfrage RA an das TRR gesendet und c) eine Registrierbestätigung vom TRR erhalten mit Bestätigung der Registrierung der Umschaltung Das TH-TM exportiert eine Löschanfrage an das TH-TV („Melting Order") zum Löschen (Destroy, Vernichten) des Tokens TtemP2 und fügt die Registrieranfrage RA und Registrierbestätigung RB des TRR bei.
Das TH-TV verifiziert die Löschanfrage, Registrieranfrage RA und Registrierbestätigung RB des TRR. Das CMS führt ein LÖSCH-Kommando (DESTROY) auf den Token TtemP2 aus unter Verwendung des privaten Schlüssels pKeyiH des TH-TV und dem privaten Schlüssels rtemp2.
Das TH-TV exportiert den Lösch-Befehl an das TH-TM unter Erstellen einer Registrieranfrage RA.
Das TH-TM sendet die Registrieranfrage RA bezüglich des LÖSCH-Kommandos an das TRR. Ab Registrierung des LÖSCH-Kommandos im TRR ist der Token Ttemp2 gelöscht (er existiert für das TRR nicht mehr).
Der Löschvorgang kann ein vollautomatischer Prozess ohne manuelle Interaktion sein. Falls hier auch ein Air-Gap AG erforderlich ist (ggf. Systemvoraussetzung) kann eine Stapelverarbeitung (Batchlauf) für alle zu löschenden Token durchgeführt werden, bei dem alle benötigten öffentlichen Schlüssel im Voraus von der CMS angefordert werden, beispielsweise am Ende eines Geschäftstages (für die Löschungen des Geschäftstages). Alternativ werden zunächst alle zu löschenden Token kombiniert (verbunden, MERGE) und nur ein verbundener Token schließlich gelöscht.
Jedes Kommando kann signiert werden, um prüfen zu können, dass der Sender der Tokenreferenz TR auch im Besitz des dazugehörigen Tokens T ist. Als Signatur kann ein ECDSA-Schema angewendet werden. Ein Kommando wird bevorzugt mit dem geheimen Tokenelement, beispielsweise dem privaten Teil r, des Tokens T signiert. Für Kommandos „Erzeugen" und „Löschen" kann eine weitere Signatur der Tokenherausgebereinheit TH verlangt werden, um sicherzustellen, dass diese Kommandos von einer privilegierten Einheit des Transaktionssystems TS generiert worden sind.
In Fig. 4 ist ein Ausführungsbeispiel eines Ablauf diagrams eines Verfahrens zum Übertragen eines Tokens T zwischen einer TE1 und einer TE2 auf Basis eines Umschalten-Kommandos eines vorhandenen Tokens Ta gezeigt. Zudem ist die dazu benötigte signierte Registrieranfrage RASig_Ta und eine Registrierbestätigung RB mit Kommandostruktur dargestellt.
In der TE1 ist ein Token Ta vorhanden. Der Token Ta hat einen Tokenwert va und den privaten Teil r des tokenindividuellen Schlüsselpaars. Die dazugehörige Tokenreferenz TRa ist im Tokenreferenz-Register TRR auf die TE1 registriert. Zwischen TE1 und TE2 soll ein Token Tb mit dem Tokenwert vb übertragen werden.
Die TE1 sendet dazu eine Übertragungsinformation Ü oder eine Tokeninformation (beispielsweise den Tokenwert vb selbst) an die TE2. Diese Tokeninformation kann eine Absichtserklärung von TE1 an TE2 sein, den Token Tb - beispielsweise im Rahmen einer Bezahltransaktion - zu übertragen. Daraufhin erzeugt TE2 eine neue Zufallszahl rb, die als privater Teil (das Geheimnis) eines neuen kryptografischen tokenindividuellen Schlüsselpaars dient. Durch Anwenden einer kryptografischen Einwegfunktion wird der öffentliche Teil Rb des Schlüsselpaars in der TE2 erzeugt.
Anschließend sendet TE2 den öffentlichen Teil Rb des Schlüsselpaars an TE1 zurück. Wenn TE2 bereits in Kenntnis des Tokenwerts vb ist (bspw. der im Rahmen der Bezahltransaktion zu erwartende Tokenwert oder die von TE1 bereitgestellt Tokeninformation ist der Tokenwert vb), kann TE2 auch die Tokenreferenz TRb an TE1 senden.
In der TE1 wird nun der Token Ta auf den zu übertragenden Token Tb umgeschaltet. Anschließend erfolgt das Erstellen und Senden einer Registrieranfrage RASigTa von der TE1 an das TRR. Die Registrieranfrage RA enthält sodann das Kommando „SWITCH" oder einen entsprechenden Kommandocode gemäß Fig. 2a, die Eingangs- Tokenreferenz TRa und den öffentlichen Teil Rb bzw. die Ausgangs-Tokenreferenz TRb. Diese Registrieranfrage RA wird mit der Zufallszahl ra des Tokens Ta signiert. Die signierte Registrieranfrage RASig_Ta wird von der Teilnehmereinheit TE1 an das Tokenreferenz-Register TRR gesendet. Dort wird die Signatur geprüft. Zudem wird der Tokenwert va mit dem Tokenwert vb verglichen. Wenn va = vb gilt und die Signaturprüfung erfolgreich ist, dann wird die Tokenreferenz TRa in dem Tokenreferenz-Register TRR gelöscht oder als gelöscht markiert und die Tokenreferenz TRb in das Tokenreferenz-Register TRR eingetragen. Ab diesem Zeitpunkt ist der Token Tb auf die TE2 registriert. Der Erfolg der Registrierung wird von dem TRR an die TE1 als Registrierbestätigung RB angezeigt. Die Registrierbestätigung umfasst die Tokenreferenz TRb. Zur Absicherung des Verfahrens kann diese Registrier bestätigung mit einer Signatur des TRR versehen sein.
Die Registrierbestätigung RB kann vom TE1 an das TE2 gesendet werden, um TE2 den Erfolg der Registrierung mitzuteilen. Sodann kann TE2 nochmals die Registrierbestätigung RB validieren. Damit gilt der Token Tb mit dem Tokenwert vb und dem privaten Teil n? von TE1 an TE2 übertragen, ohne dass der Token mit beiden Tokenelementen von TE1 an TE2 übertragen werden musste.
Übertragen wird demnach der erzeugte öffentliche Teil Rb an TE1. TE1 übernimmt die Registrierung durch ein Umschaltkommando „SWITCH". Eine Bestätigung RB wird ggf. mit Signatur des TRR Sig (vb, Rb) für den erzeugten öffentliche Teil Rb und den Tokenwert vb zurückgesendet. Ein abschließendes Umschalten in der TE2 wird damit überflüssig, das Verfahren ist demnach weniger komplex.
In Fig. 5 ist ein Ausführungsbeispiel eines Ablauf diagrams eines Verfahrens zum Verbinden eines Tokens Ta mit einem Token Te und Registrieren des verbundenen Tokens Tf im TRR gezeigt. Zudem sind die dazu benötigten signierten Registrieranfragen RASig_Td und RASig_Te sowie die Kommandostruktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
Dabei wird in einer TE1 der TE-Schicht eine Zufallszahl rf erzeugt. Basierend darauf wird dann ein öffentlicher Teil Rf erzeugt. Zudem erfolgt das Bilden einer Summe aus den Tokenwerten va und ve zum Tokenwert Vf basierend auf den Eingangs-Token Td und Te.
Sodann wird die Ausgangs-Tokenreferenz TRf erzeugt. Eine Registrieranfrage RA enthält sodann das Kommando „MERGE" bzw. den in Fig. 6a gelisteten Kommandocode, die zwei Eingangs-Tokenreferenzen TRd und TRe sowie die Ausgangs-Tokenreferenz TRf. Diese Registrieranfrage RA wird einmal mit der Zufallszahl ra des Tokens Td signiert, um eine erste signierte Registrieranfrage RASig_Td zu erhalten. Diese Registrieranfrage wird zudem mit der Zufallszahl re des Tokens Te signiert, um eine zweite signierte Registrieranfrage RASig_Te zu erhalten. Beide signierte Registrieranfragen RASig_Td und RASig_Te werden von der Teilnehmereinheit TE1 an das Tokenreferenz-Register TRR gesendet. Dort werden jeweils die Signaturen der Registrieranfragen RASig_Td und RASig_Te geprüft. Zudem wird die Summe von den Tokenwerten va und ve gebildet und mit dem Tokenwert Vf verglichen. Wenn Vf = vd + ve gilt und beide Signaturprüfungen erfolgreich sind, dann werden TRd und TRe in dem Tokenreferenz-Register TRR gelöscht oder als gelöscht markiert und die Tokenreferenz TRf in das Tokenreferenz-Register TRR eingetragen. Der verbundene Token Tf (der zwischenzeitlich von TE1 an TE2 übertragen wurde) kann nun von der Teilnehmereinheit TE2 im TRR auf Gültigkeit geprüft werden.
In Fig. 6 ist eine weitere Ausgestaltung eines Tokenreferenz-Registers TRR eines Transaktionssystems TS gezeigt. Hierbei ist angedeutet, dass mehrere Speichereinheiten 1 im Tokenreferenz-Register TRR vorgehalten sein können, um ein Abspeichern einer Vielzahl von Tokenreferenzen TR zu beschleunigen. Hierbei ist zudem angedeutet, dass mehrere Verifiziereinheiten 2 im Tokenreferenz-Register TRR vorgehalten sein können, um eine Verifizierung von Registrieranfragen RA zu beschleunigen. Zudem ist eine Teilnehmereinheit B-TE dargestellt, die als spezielle Bank-Teilnehmereinheit zwischen dem Tokenherausgeber TH und der Teilnehmereinheit TE1 angeordnet ist.
Zudem zeigt Fig. 6 eine Registrierungsanfrage-Einheit RAE, die von einer Teilnehmereinheit TE1 eine Folge von Registrierungsanfragen RA erhalten kann.
Es ist von Vorteil, wenn pro Teilnehmer einheit TE (hier als ein sicheres Element, bspw. Smart Card oder TEE) nur ein Token T verwendet wird. Das bedeutet, dass das TE einen erhaltenen Token T mit dem im Tokenspeicher abgelegten Token T verbindet (MERGE). Das bedeutet auch, dass das TE einen zu versendenden Token T von dem im Tokenspeicher abgelegten Token T abteilt (SPLIT). Diese Modifikationen am Token T können ohne Registrieranfrage RA durchgeführt werden und der Token T kann nach einer Modifikation sofort weitergegeben werden. Es kann also zu einer Folge von Modifikationen am Token T kommen, die dem TRR nicht bekannt sind. Typischerweise besteht die Folge von Registrieranfragen RA aus einer Kombination von SPLIT und MERGE Modifikationen. Jede dieser Modifikationen wird auch als „Proof" (siehe oben zur Fig. 1) bzw. signierte Registrieranfrage RASig mit dem Token T abgespeichert. Damit entsteht in der TE eine Folge von Registrieranfragen RAF. BEZUGSZEICHENLISTE
TS Transaktionssystem
TH Tokenherausgebereinheit
TH-TG Tokengenerierungseinheit
TH-TV Tokenvernichtungseinheit
TH-TM T okenherausgeber-V erwaltungseinheit
TH-TE Tokenherausgeber-Teilnehmereinheit
AG Air Gap
TE1 Teilnehmereinheit Benutzer
B-TE Bank-Teilnehmereinheit
TRR Tokenreferenzregister
T Token
TR Tokenreferenz
R, r Tokenelementepaar
R öffentliches Tokenreferenzelement des Tokenelementpaars r geheimes Tokenelement des Tokenelementpaars v Tokenwert
HB Hinzufügungs-Bestätigung
RB Ersetzungs-Bestätigung
EB Entfernungs-Bestätigung sKEyiH privater Teil des Tokenherausgeber-Schlüsselpaars
200 Empfangen Tokengenerierungsanfrage
201 Empfangen Anfrage für neues Tokenreferenzelement
202 Erzeugen eines neuen Tokenelementpaare
203 Senden des öffentlichen Tokenreferenzelement
211 Empfangen einer Tokenerzeugungsanfrage
212 Erzeugen eines temporären Tokenelementpaares
214 Erzeugen eines Hinzufügungs-Kommandos
215 Senden des Hinzufügungs-Kommandos
218 Erzeugen eines Ersetzungs-Kommandos
219 Senden des Ersetzungs-Kommandos
221 Senden des Hinzufügungs-Kommandos an TRR
222 Hinzufügen der temporären Tokenreferenz
224 Erzeugen einer Hinzufügungs-Bestätigung
225 Empfangen der Hinzufügungs-Bestätigung von TRR 231 Senden des Ersetzungs-Kommandos an TRR
232 Ersetzen der Tokenreferenzen
234 Erzeugen einer Ersetzungs-Bestätigung
235 Empfangen der Ersetzungs-Bestätigung von TRR
237 Empfangen der Ersetzungsbestätigung
238 Speichern/ Aktivieren des neuen Token
239 Senden Bestätigung für herausgebbaren neuen Token
240 Abschluss der Generierung speichern
250 Ausgabe des neuen Token
300 Empfangen einer Tokenvernichtungsanfrage
301 Empfangen Anfrage altes Tokenreferenzelement
302 Deaktivieren alter Token
303 Senden des alten Tokenreferenzelements
311 Empfangen einer Vernichtungs- Anforderung
312 Erzeugen eines temporären Tokenelementpaares
313 Senden des temporären Tokenreferenzelements
314 Erzeugen eines Entfernen-Kommandos
315 Senden des erzeugten Kommandos
317 Empfangen des temporären Tokenreferenzelements
318 Erzeugen eines Ersetzungs-Kommandos
319 Senden des erzeugten Kommandos
321 Senden des Ersetzungs-Kommandos an TRR
322 Ersetzen der Tokenreferenzen
325 Empfangen einer Ersetzungs-Bestätigung von TRR
331 Senden des Entfernen-Kommandos
332 Entfernen der temporären Tokenreferenz
334 Erzeugen einer Entfernungsbestätigung
335 Empfangen der Entfernungsbestätigung von TRR
337 Empfangen der weitergeleiteten Entfernungsbestätigung
338 Löschen des alten Tokens
339 Empfangen Löschbestätigung
340 Abschluss der Vernichtung speichern

Claims

Patentansprüche
1. Ein Verfahren zur sicheren Generierung eines herausgebbaren Tokens durch einen Tokenherausgeber eines elektronischen Transaktionssystems (TS) mit Tokenreferenzregister (TRR), wobei in einer Tokenherausgebereinheit (TH), welche eine sichere Tokengenerierungseinheit (TH-TG) umfasst, folgende Schritte ausgeführt werden:
- Erzeugen (212) eines tokenindividuellen Tokenelementpaares, welches ein geheimes Tokenelement und ein öffentliches Tokenreferenzelement umfasst, in der sicheren Tokenerzeugungseinheit (TH-TG);
- Erzeugen (214) eines Hinzufügungs-Kommandos in der sicheren Tokenerzeugungseinheit (TH-TG), welches das Tokenreferenzregister (TRR) anweist, eine Tokenreferenz (TR), die das erzeugte öffentliche Tokenreferenzelement umfasst, als zusätzliche Tokenreferenz (TR) in dem Tokenreferenzregister (TRR) hinzuzufügen;
- Senden (221) des Hinzufügungs-Kommandos an das Tokenreferenzregister (TRR); dadurch gekennzeichnet, dass das erzeugte Tokenelementpaar ein internes, temporäres Tokenelementpaar (rtemp, Rtemp) der Tokenerzeugungseinheit (TH-TG) ist, die Tokenerzeugungseinheit (TH-TG) eine Tokenreferenz (TRnew) des herausgebbaren Tokens empfängt (211), und die Tokenerzeugungseinheit (TH-TG) ein Ersetzungs-Kommando erzeugt (218), welches das Tokenreferenzregister (TRR) anweist, anstelle der Tokenreferenz (TRtemp) des temporären Tokenelementpaares die Tokenreferenz (TRnew) des herausgebbaren Tokens (T new ) zu registrieren.
2. Das Verfahren nach Anspruch 1, wobei die Tokenherausgebereinheit (TH) eine sichere Tokenspeichereinheit (TH-TE) umfasst, wobei die sichere Tokenspeichereinheit (TH-TE) ein tokenindividuelles Tokenelementpaar des herausgebbaren Token erzeugt (202).
3. Das Verfahren nach Anspruch 1 oder 2, wobei das geheime Tokenelement (rtemp) des internen, temporären Tokenelementpaares nur in der Tokengenerierungseinheit (TH-TG) vorliegt; und/ oder das geheime Tokenelement (rnew) des herausgebbaren Token nur in der Tokengenerierungseinheit (TH-TE) vorliegt.
4. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei das Hinzufügungs-Kommando und das Ersetzungskommando zusammen in einem gemeinsamen Sendeschritt an das Tokenreferenzregister (TRR) gesendet (221, 231) werden.
5. Das Verfahren nach Anspruch 4, wobei in Folge des Sendens (221, 231) eine Hinzufügungs-Bestätigung (HB) und/ oder eine Ersetzungs-Bestätigung (RB) in der Tokenherausgebereinheit (TH) empfangen (225, 235) wird.
6. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tokenherausgebereinheit (TH) eine sichere Tokenverwaltungseinheit (TH-TM) umfasst, wobei in der sicheren Tokenverwaltungseinheit (TH-TM) eine Tokengenerierungsanfrage empfangen (200) wird.
7. Das Verfahren nach Anspruch 6, wobei die Tokengenerierungsanfrage das öffentliche Tokenreferenzelement (Rnew) bereits umfasst.
8. Ein Verfahren zur sicheren Vernichtung eines Tokens durch einen Tokenherausgeber eines elektronischen Transaktionssystems (TS) mit Tokenreferenzregister (TRR), wobei in einer Tokenherausgebereinheit (TH), welche eine sichere Tokenvernichtungseinheit (TH-TV) umfasst, folgende Schritte ausgeführt werden:
- Erzeugen (314) eines Entfernen-Kommandos in der Tokenvernichtungseinheit (TH-TV), welches das Tokenreferenzregister (TRR) anweist, eine Tokenreferenz eines registrierten Tokens aus dem Tokenreferenzregister (TRR) zu entfernen;
- Senden (321) des Entfernen-Kommandos an das Tokenreferenzregister (TRR); dadurch gekennzeichnet, dass die Tokenvernichtungseinheit (TH-TV) vor dem Erzeugen des Entfernen- Kommandos (314) einen internen, temporärer Token (Ttemp?) erzeugt (312) und das Entfernen-Kommando für die Tokenreferenz des internen, temporären Tokens (TRtemp?) erzeugt; und
Erzeugen (318) eines Ersetzungs-Kommandos, welches das Tokenreferenzregister (TRR) anweist, anstelle der Tokenreferenz (TRoid) des zurück zu nehmenden Tokens (Toid) die Tokenreferenz (TRtemp?) des internen, temporären Tokens (Ttemp2) zu registrieren.
9. Das Verfahren nach Anspruch 8, wobei die Tokenherausgebereinheit (TH) eine sichere Tokenspeichereinheit (TH-TE) umfasst, wobei die sichere Tokenspeichereinheit (TH-TE) den zurück zu nehmenden Token (Toid) deaktiviert (202).
10. Das Verfahren nach Anspruch 8 oder 9, wobei das geheime Tokenelement (rtemP2) des internen, temporären Tokens (Ttemp?) nur in der Tokenvernichtungseinheit (TH-TV) vorliegt.
11. Das Verfahren nach einem der vorhergehenden Ansprüche 8 bis 10, wobei das Entfernen-Kommando und das Ersetzungskommando zusammen in einem gemeinsamen Sendeschritt an das Tokenreferenzregister (TRR) gesendet (321, 331) werden.
12. Das Verfahren nach Anspruch 11, wobei in Folge des Sendens (321, 331) eine Entfernungs-Bestätigung (EB) und/ oder eine Ersetzungs-Bestätigung (RB) in der Tokenherausgebereinheit (TH) empfangen (325, 335) wird.
13. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tokenherausgebereinheit (TH) eine sichere Tokenverwaltungseinheit (TH-TM) umfasst, wobei in der Tokenverwaltungseinheit eine Token Vernichtungsanfrage empfangen (300) wird.
14. Tokenherausgebereinheit (TH) umfassend: eine Schnittstelle zu einem Tokenreferenzregister (TRR); und eine sichere Tokengenerierungseinheit (TH-TG) zur sicheren Generierung eines herausgebbaren Tokens mittels eines Verfahrens gemäß einem der vorhergehenden Ansprüche 1 bis 7; und/ oder eine sichere Tokenvernichtungseinheit (TH-TV) zur sicheren Vernichtung eines Tokens mittels eines Verfahrens gemäß einem der vorhergehenden Ansprüche 8 bis 13.
15. Tokenherausgebereinheit (TH) nach Anspruch 14, weiter umfassend: eine Tokenherausgeber-Teilnehmereinheit (TH-TE), eingerichtet zum
Ablegen von Token und/ oder Tokenreferenzen; und eine Schnittstelle zu einer Bank-Teilnehmereinheit (B-TE) oder zu einer Zentralbankeinheit, eingerichtet zum Empfangen (200) einer Tokengenerierungsanfrage und/ oder zum Empfangen (300) einer Tokenvernichtungsanfrage.
16. Tokenherausgebereinheit (TH) nach Anspruch 14 oder 15, umfassend - eine Tokenverwaltungseinheit (TH-TM) mit einer Schnittstelle zu einer Bank-
Teilnehmereinheit (B-TE) oder zu einer Zentralbankeinheit oder einer Tokenherausgeber-Teilnehmereinheit (TH-TE), eingerichtet zum:
- Ausgeben (250) des herausgebbaren Tokens (Tnew); und/ oder
- Speichern eines Abschlusses der sicheren Vernichtung des Tokens (Toid) und/oder
- Speichern eines Abschlusses der sicheren Generierung des herausgebbaren Tokens (T new).
17. Tokenherausgebereinheit (TH) gemäß einem der Ansprüche 14 bis 16, weiter umfassend eine Air-Gap-Schnittstelle zwischen der Tokenverwaltungseinheit (TH- TM) und der sicheren Tokengenerierungseinheit (TH-TG) und/ oder der sicher Tokenvernichtungseinheit (TH-TV) .
PCT/DE2023/100452 2022-07-11 2023-06-14 Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber WO2024012624A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022002518.3A DE102022002518A1 (de) 2022-07-11 2022-07-11 Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber
DE102022002518.3 2022-07-11

Publications (1)

Publication Number Publication Date
WO2024012624A1 true WO2024012624A1 (de) 2024-01-18

Family

ID=87036443

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2023/100452 WO2024012624A1 (de) 2022-07-11 2023-06-14 Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber

Country Status (2)

Country Link
DE (1) DE102022002518A1 (de)
WO (1) WO2024012624A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170293912A1 (en) * 2016-04-12 2017-10-12 Digicash Pty Ltd. Secure transaction controller for value token exchange systems
WO2022008319A1 (de) 2020-07-08 2022-01-13 Giesecke+Devrient Gmbh Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10373158B1 (en) 2018-02-12 2019-08-06 Winklevoss Ip, Llc System, method and program product for modifying a supply of stable value digital asset tokens

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170293912A1 (en) * 2016-04-12 2017-10-12 Digicash Pty Ltd. Secure transaction controller for value token exchange systems
WO2022008319A1 (de) 2020-07-08 2022-01-13 Giesecke+Devrient Gmbh Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem
DE102020004116A1 (de) * 2020-07-08 2022-01-13 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DAVID CHAUM ET AL: "How to Issue a Central Bank Digital Currency", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 27 February 2021 (2021-02-27), XP081893466 *

Also Published As

Publication number Publication date
DE102022002518A1 (de) 2024-01-11

Similar Documents

Publication Publication Date Title
DE69814406T2 (de) Tragbare elektronische vorrichtung für systeme zur gesicherten kommunikation und verfahren zur initialisierung der parameter
DE60023705T2 (de) Sichere verteilung und schutz einer schlüsselinformation
DE102018122997A1 (de) Blockkettenentität, kettenexterne entität, zertifizierungsvorrichtung für blockkettenoperationen und verfahren zum durchführen einer kooperation zwischen einer blockkettenentität und einer kettenexternen entität
EP3726438A1 (de) Verfahren und steuersystem zum steuern und/oder überwachen von geräten
WO2020212331A1 (de) Gerät zum direkten übertragen von elektronischen münzdatensätzen an ein anderes gerät sowie bezahlsystem
WO2020212337A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten sowie bezahlsystem
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
EP3743844B1 (de) Blockchain-basiertes identitätssystem
EP1967976A2 (de) Verfahren zur authentisierten Übermittlung eines personalisierten Datensatzes oder programms an ein Hardware-Sicherheitsmodul, insbesondere einer Frankiermaschine
DE60313087T2 (de) Sichere Übertragung digitaler Wertmarken
WO2023011761A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
WO2023036458A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
DE69636612T2 (de) Zahlungsverfahren in einer Datenübertragungsanordnung und Anordnung zu dessen Implementierung
EP4111399B1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
WO2024012624A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber
EP3699851B1 (de) Ableitung eines tokens mittels eines transaktions-bezogenen einmalschlüssels
WO2023011756A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
WO2024027869A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
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
WO2022069247A1 (de) Gerät und verfahren zur einrichtung einer dienstbezogenen authentisierung
WO2022002502A1 (de) Anonymisiertes bereitstellen eines dienstes
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
WO2023011759A1 (de) Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit
WO2023011758A1 (de) Münzdepot-verwaltungseinheit sowie verfahren in einer münzdepot-verwaltungseinheit

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23734454

Country of ref document: EP

Kind code of ref document: A1