Method for securely generating a token which can be issued, method for securely destroying a token, and token issuer

Abstract

The invention relates to a method for securely generating a token which can be issued by means of a token issuer of an electronic transaction system comprising a token reference register. The invention also relates to a method for securely destroying a token of an electronic transaction system comprising a token reference register and to a token issuer. In a token issuer unit which comprises a secure token generating unit, the following steps are carried out: a token-individual token element pair is generated which comprises a secret token element and a public token reference element; an addition command is generated which instructs the token reference register to add a token reference which comprises the generated public token reference element into the token reference register as an additional token reference; and the addition command is transmitted to the token reference register. Presently the generated token element pair is an internal temporary token element pair of the token generating unit. The token generating unit receives a token reference of the token which can be issued and generates a replacement command which instructs the token reference register to register the token reference of the token which can be issued in place of the token reference of the temporary token element pair.

Description

[0001] Method for the secure generation of an issueable token, method for the secure destruction of a token, and token issuer

[0002] The invention relates to a method for the secure generation of an issueable token by a token issuer of an electronic transaction system with a token reference register. The invention also relates to a method for the secure destruction of a token of an electronic transaction system with a token reference register. The invention also relates to a token issuer.

[0003] For token-based transaction systems, it is common practice to provide a token reference register. The token issuer can initially register a token reference of an issuable token in the token reference register or delete an already registered token reference of a token to be redeemed. Participants in the transaction system, on the other hand, may only register a token reference of the token in exchange for an already registered token reference of a token of the same value.

[0004] In central bank digital currency (CBDC) systems, particularly high security requirements are placed on the central system components, such as the token issuer.

[0005] WO 2022 / 008319 A1 describes a token issuer comprising an isolated token generation unit and a token issuance unit. A private key of a cryptographic key pair of the token issuer can be stored in a hardware security module of the token generation unit. Upon request from the token issuance unit, the token generation unit generates a new token and a signed registration record, which enables the registration of the new token using a token reference in the token reference register. The token issuance unit receives the token to be issued and the token registration record. It registers the token to be issued using the token registration record in the token reference register before issuing the new token to a participant unit of the transaction system.

[0006] The invention is based on the object of providing an even more secure token issuing unit and a particularly secure method for the secure generation or destruction of tokens of the transaction system. Preferably, the solution should be flexible without compromising the security of the transaction system.

[0007] The stated problem is solved by the subject matter of the independent patent claims. Further advantageous embodiments are described in the respective dependent patent claims.

[0008] In a first aspect, the object is achieved in particular by a method for the secure generation of an issueable token by a token issuer of an electronic transaction system with a token reference register. In a token issuer unit comprising a secure token generation unit, the following steps are carried out: generating a token-specific token element pair, which comprises a secret token element and a public token reference element, in the secure token generation unit; generating an addition command in the secure token generation unit, which instructs the token reference register to add a token reference, which comprises the generated public token reference element, as an additional token reference in the token reference register; sending the addition command to the token reference register. The generated token element pair 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 that 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.

[0009] A token contains a token value as a token element.

[0010] In one embodiment, the token issuing unit comprises a secure token storage unit (hereinafter also token issuing subscriber unit), wherein this secure token storage unit generates a token-individual token element pair of the issueable token.

[0011] In one embodiment, 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 issuable 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. In one embodiment, 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. In one embodiment, 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.

[0012] 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 as information from a token issuing management, which is a unit of the token issuing unit, to the token generation unit. Alternatively, token values ​​with fixed denominations are generated.

[0013] With this method, the internal temporary token generated in the token generation unit by a generation step is not transmitted directly to the token management unit. For the first aspect, it is advantageous that, after generating the internal temporary token, the token generation unit generates a replacement command (in particular a token value-neutral replacement, for example, by a toggle modification, a connect modification (with a token with the value "0" or a split modification (receiving a token with the value "0")) 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 provided, 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.

[0014] By registering the token reference of the new token to be issued with the token reference registry, the new token is valid in the transaction system and can be used.

[0015] In one embodiment, the token issuer maintains newly issuable (but not yet issued) tokens in a secure storage area (e.g., in the token issuer participant unit). Upon request from a participant unit, e.g., a bank participant unit of the transaction system, the issuable token can then be issued immediately (without first having to perform the secure generation process) to the requesting participant unit in the transaction system.

[0016] In an alternative embodiment, a token generation request can be received, preferably in a secure token issuer management of the token issuing unit, before the token-individual token element pair is generated.

[0017] This token generation request may have been sent by a participant unit, such as a bank participant unit of the transaction system. Alternatively, this token generation request may have been sent by a central bank authority.

[0018] CDBC wallets can be present in the participant units, for example a bank participant unit of the transaction system, which interact with the token issuing unit for an order (request, generation) or return (redemption, destruction) of CDBC.

[0019] Preferably, in the generation step, the issueable token is signed with a private key of the token issuing unit, for example, with a private key of the token generation unit. By signing with the private key portion, each participant unit of the transaction system can then use the corresponding public key portion to verify whether the token was generated trustworthy. This ensures that the token was issued by a token issuer and not by an attacker. With the method according to the invention, neither the key portion of the cryptographic key pair of the token issuing unit nor the secret token element leave the token generation unit. It is thus possible to modularly decompose the token issuer into a token issuing management unit and a token generation unit.Both units of the token issuing unit can now be located at different locations without compromising security. This spatial distance allows the token issuing unit to be designed more flexibly and modularly. Preferably, the new token is signed with the private part of the temporary, token-specific cryptographic key pair during the replacement command generation step. This indicates that the token generation unit was aware of the temporary token and the new token. This signature can be required for the replacement command.

[0020] Preferably, to register the issueable token, the replacement command in the token reference register is checked for validity by checking a signature of the token issuing unit using a public key part of the token issuing unit.

[0021] Preferably, the registration request in the token reference register is also checked for validity by verifying a signature using the public token reference element of the token element pair.

[0022] The add command and the replace command are preferably sent together to the token reference register in a single transmission step. Following the joint transmission, an add confirmation (generated by the token reference register) and / or a replace confirmation (generated by the token reference register) is received in the token issuing unit.

[0023] Preferably, the token reference register sends a registration confirmation (= replacement confirmation) if the replacement command is valid.

[0024] Preferably, the token issuing management unit of the token issuing unit, after receiving the registration confirmation (= replacement confirmation), transmits the newly issued token comprising the token value and the secret token element of the token element pair to a subscriber unit, preferably a bank subscriber unit.

[0025] In a second aspect, a method for securely destroying a token by a token issuer of an electronic transaction system with a token reference register is provided, wherein the following steps are performed in a token issuing unit comprising a secure token destruction unit: generating a remove command in the token destruction unit, which instructs the token reference register to remove a token reference of a registered token from the token reference register; and sending the remove command to the token reference register. The token destruction unit generates an internal, temporary token before generating the remove command and generates the remove command for the token reference of the internal, temporary token.In addition, 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 withdrawn.

[0026] The second aspect—analogous to the secure generation of a token according to the first aspect—is now focused on destroying (deleting) a token in the transaction system. The advantages and technical tasks correspond to those of the first aspect.

[0027] In particular, the method according to the second aspect does not transmit the internal temporary token generated in the token destruction unit by a generation step directly to the token management unit. Advantageous for the second aspect is that, after generating the internal temporary token, the token destruction unit generates a replacement command (in particular, a token-value-neutral replacement, for example, by a toggle modification, a join modification (with a token with the value "0," or a split modification (receiving a token with the value "0")) to register the token reference of the internal, temporary token instead of the token reference of the token to be withdrawn (destroyed).The token reference required for the replacement of the token to be withdrawn is provided, 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.

[0028] In order to prevent the token to be destroyed (=deleted) from being stolen during transfer to the token issuer destruction unit, a replacement command is combined with the removal command.

[0029] The token issuing unit comprises a secure token storage unit, wherein the secure token storage unit deactivates the token to be withdrawn.

[0030] The secret token element of the internal, temporary token is preferably only available in the token destruction unit. The removal command and the replacement command can be sent together to the token reference register in a single transmission step. Following the transmission, a removal confirmation (generated by the token reference register) and / or a replacement confirmation (generated by the token reference register) can be received in the token issuing unit.

[0031] The token issuing unit may comprise a secure token management unit, wherein a token destruction request is received in the token management unit.

[0032] In one embodiment, the token to be destroyed (deleted, redeemed) was taken from a deletion directory of the token issuer management system. This deletion directory is a storage area in the token issuer unit in which tokens to be deleted (i.e., redeemed) are stored.

[0033] In a highly preferred embodiment, an air-gap interface is implemented between the token generation unit and the token issuer management unit. An air-gap or air-wall process (analogous to a firewall) is a process that separates the two units (token generation unit and token issuer management unit) from each other while still allowing the transmission of payload data, in this case, tokens, token elements, token element pairs, key parts, etc. An air-gap process is used to isolate the two units with different levels of trust from each other while still ensuring that data from the other unit can be processed.

[0034] In a preferred embodiment, the air-gap transmission is configured to physically, logically, electrically, and / or electronically separate the token generation unit from the token issuer management unit. This electrically isolates both units from each other. In other words, data transmission does not take place exclusively electrically / electronically. Thus, an attacker with remote network access to the token issuer management unit has no access to the token generation unit. The attacker is therefore unable to insert data into the token generation unit and / or intercept data (e.g., the temporary token or the private part of the token issuer key pair) from the token generation unit. For this purpose, a (permanent, physical) data connection (OSI Layer 1) between the token generation unit and the token issuer management unit is missing.

[0035] In a preferred embodiment, the transfer takes place in the air-gap process using portable electronic data storage devices, such as USB sticks, memory cards, CDs, or similar. For this purpose, appropriate electronic interfaces, such as USB ports, memory card readers, or CD drives, are provided on the token generation unit and the token issuer management unit.

[0036] In a preferred embodiment, for transmission in the air-gap process, the token generation unit is further configured to generate a printout representing the token (as a physical representative of a token). The token issuer management is configured to read the token printout generated by the token generation unit. This represents a comparatively simple form of implementing an air-gap process. The printout can be transported, for example, via mechanical conveyor mechanisms into a reading area of ​​the token issuer management. The transport boxes already described can also be used for this purpose, so that, for example, a printout is automatically placed in a transport box by the token generation unit, then transported to the token issuer management, in particular its reading area, and read there.

[0037] In a preferred embodiment, the deletion of all tokens to be deleted within a predefined time period is performed as a batch process at the end of the predefined time period. This reduces the number of transmission steps to a single point in time, significantly minimizing the effort involved—especially in air-gap processes.

[0038] Preferably, all tokens to be deleted within a predefined time period are combined into a common deletion token at the end of the predefined time period by applying one or more combine commands before executing the method according to the second aspect. This greatly reduces the number of transmission steps, resulting in a significant reduction in the effort required to generate and / or delete tokens. The predefined time period is preferably one month, preferably one week, more preferably one day, and even more preferably one hour.

[0039] Preferably, the token reference register sends an addition confirmation if the addition command is valid and the temporary token reference has been added to the token reference register. This informs the token issuing unit, in particular the secure token issuing management unit, that the temporary token reference is present in the token reference register.

[0040] An electronic transaction system, such as a digital currency system or a digital central bank system, is a system in which at least two, preferably a plurality of, participating units can directly exchange (transfer) digital central bank money (CDBC) in the form of tokens. The transaction system is thus, for example, a payment transaction system for exchanging monetary amounts in the form of payment tokens.

[0041] A token is a data record of a transaction system that is directly exchangeable between participating entities. Upon registering a token reference in the token reference register, the token is considered created and / or deleted and / or transferred, and from that point on, a receiving participating entity is in possession of the token value represented by the token. With the transfer process, the token therefore automatically changes ownership (from issuer to participating entity). A token—a data record that is transferable independently of a transaction topology, such as the blockchain topologies "Bitcoin," "Ethereum," or "Neo"—can be transferred directly between participating entities or from the token issuer without any intermediaries.

[0042] In one embodiment, the token is an electronic coin record or payment token for exchanging monetary amounts between participating units. Such a payment token is also colloquially referred to as a "digital coin" or "electronic coin" and represents cash in electronic form.

[0043] Each token in the transaction system is a data set comprising at least two token elements. The first token element of each token in the transaction system is a token value, e.g., an asset, a property, a commodity, and / or a monetary amount.

[0044] A second token element of each token in 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 within 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. Preferably, the random number is the result of a truly random number generator.

[0045] The token is formed from the token value (first token element) and the secret token element. This formation preferably involves concatenating these two token elements. Any other type of linking of these two token elements is not excluded by the invention and includes, for example, concatenating them, incorporating them into a TLV data structure, and / or logical linking.

[0046] A token differs from a data record for traditional data exchange or data transfer, as a traditional data exchange, for example, is based on a question-and-answer principle or on intercommunication between the partners in the data exchange. A token, in contrast, is unique and unambiguous in the transaction system. The token is part of a security concept that includes, for example, signatures or cryptographic encryption. A token contains all data elements required by a receiving participant unit for verification, authentication, and forwarding the token to another participant unit. Intercommunication between the participant units transmitting a token is therefore fundamentally unnecessary with a token.

[0047] Anyone in possession of a token or with unrestricted access to the token and its token elements can exchange (=transfer) this token with another participating entity. Ownership of the token and its at least two token elements (token value and the private part of the token-specific key pair) is therefore equivalent to ownership of the value represented by the token. Here, the token can also be transferred indirectly by registering a token reference.

[0048] Each token in the transaction system is assigned a token reference. This assignment is unique, meaning that each token is assigned exactly one token reference, and each token reference is assigned exactly one token. The token reference is a public record that is verifiably stored in a storage unit of the transaction system's token reference register for each participating unit.

[0049] Both the token and the token reference are unique. This unique mapping creates a one-to-one relationship between the token and the token reference.

[0050] Each token reference in the transaction system is a data record comprising at least two token reference elements.

[0051] The 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 thus identical to the token value of the associated token reference. For example, the token value of the token reference is a copy of the token value of the associated token.

[0052] 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. In other words: the public token reference element and the private token element form the token element pair.

[0053] This cryptographic function is a one-way function. This cryptographic function is therefore a mathematical function that is "easy" to compute in terms of complexity theory, but "difficult" or practically impossible to reverse. A one-way function also refers to a function for which no practical inversion is known to date that can be performed within a reasonable time and with reasonable effort. Preferably, a one-way function is used that operates on a group in which the discrete logarithm problem is difficult to solve, such as a cryptographic method analogous to elliptic curve encryption, or ECC for short, from a private key of a corresponding cryptography method. The reverse function, i.e., the generation of a token (or part of the electronic coin record) from a token reference, is very time-consuming.

[0054] 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 fundamental difference between the token reference and the token and is a core of the present invention.

[0055] After applying the cryptographic function to the private part of the token-specific key pair, the public part of the token-specific key pair is obtained as the second token reference element.

[0056] 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, concatenation, insertion into a TLV data structure, and / or logical linking.

[0057] A token reference can also be generated using an electronic wallet. The use of a token reference is not comparable to the use of participant unit addresses in a blockchain-based transaction system, since the token reference register according to the invention does not use participant unit addresses, preventing traceability of the tokens.

[0058] The registration process includes a receiving step for receiving a token reference in a token reference register as part of a registration request. For example, the registration request is sent by a subscriber unit or the token issuer management (here as an add command and a replace command) of the transaction system.

[0059] The token reference register is a unit of the transaction register in which token references are stored, thereby registering the associated tokens. This register can be a centralized 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 token references and / or registration requests.

[0060] The received registration request is verified by a verification unit in the token reference register. This verifies whether at least one token reference of the received registration request is already stored in the token reference register. A token reference is stored only once in the token reference register. Since a token reference for a token exists only once in the transaction system, a verification step can be used to determine whether an attempt has been made to issue a token multiple times. In one embodiment, the verification step determines whether the signature(s) of the registration request are correct.

[0061] A token change modification can be used to replace the token. The following procedural steps are performed for a token change modification: 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 (generated) token. Token change is one modification option for modifying a token. The token references contained in the registration request can be concatenated. If a token is transferred directly from one subscriber unit to another subscriber unit, for example, if a monetary amount is to be transferred as a token value within the scope of a payment transaction, the sending subscriber unit can now have the token value re-registered to itself. This registers the change in the token reference register.

[0062] The token value of the temporary token corresponds to the token value of the new token. Therefore, upon switching, a token with the same token value but a new private part is registered in the token reference register.

[0063] The token reference register has knowledge of token references of tokens in the transaction system and preferably also carries out processing or modifications to the tokens (token history). Transactions with tokens are not recorded in the token reference register and take place in a direct transaction layer of the transaction system directly between participating units of the transaction system.

[0064] In a further aspect, a token issuing unit of a transaction system is provided. The token issuing unit may comprise: an interface to a token reference register; and a secure token generation unit for securely generating an issueable 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.

[0065] The token issuing unit may further comprise a token issuing subscriber unit configured to store tokens and / or token references; and an interface to a bank subscriber unit or to a

[0066] Central banking unit configured to receive a token generation request and / or to receive a token destruction request.

[0067] The token issuing unit may further comprise a token management unit having an interface to a bank subscriber unit or to a central bank unit or a token issuing subscriber unit configured 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.

[0068] The token issuing 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.

[0069] Preferably, the token issuer comprises 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.

[0070] The token reference register can be an instance of a central currency system, and each token can be central bank digital currency. A digital currency system, as the transaction system, comprises a plurality of the described subscriber units, the token reference register, and a token issuer. A subscriber unit, for example, a bank subscriber unit or an issuer subscriber unit, can be a secure element that has secure access to one or more tokens in a token store. The secure element is, for example, incorporated in a terminal device in a ready-to-use state.The secure element and / or the end device have a special computer program product (electronic wallet), particularly in the form of a secured runtime environment within a device's operating system, a Trusted Execution Environment (TEE), stored on a data storage device, for example, a mobile device, a machine, or an ATM. Alternatively, the secure element is implemented, for example, as special hardware, particularly in the form of a secured hardware platform module, a Trusted Platform Module (TPM), or an embedded security module, eUICC, eSIM. The secure element provides a trusted environment.

[0071] The invention and further embodiments and advantages of the invention are explained in more detail below with reference to figures, whereby the figures merely describe exemplary embodiments of the invention. Identical components in the figures are provided with the same reference numerals. The figures are not to be considered to scale; individual elements of the figures may be exaggeratedly large or oversimplified.

[0072] Fig. 1 shows an embodiment of a token issuing unit;

[0073] Fig. 2 shows an embodiment of a sequence of steps of a method according to the first aspect in a token issuing unit;

[0074] Fig. 3 shows an embodiment of a sequence of steps of a method according to the second aspect in a token issuing unit;

[0075] Fig. 4 shows an embodiment of a flowchart of switching a token;

[0076] Fig. 5 shows an embodiment of a flow diagram of connecting a token; and

[0077] Fig. 6 shows an embodiment of a transaction system. Fig. 1 shows an 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 generated (to be issued) token T in a token reference register TRR of the transaction system TS.

[0078] Each token T in the transaction system TS is initially (only) securely generated by the token issuing entity TH (in the TH-TG) and also securely destroyed (deleted) by the TH (in the TH-TV). A token issuing entity TH is, for example, an entity of a central bank or an entity of a third party that cooperates with a central bank.

[0079] Upon request from a central bank, a subscriber unit (TE), or a bank subscriber unit (e.g., a commercial bank), the creation (production, generation) of a token T is initiated in the token issuer (TH). The token issuer's token issuer unit (TH) 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 airgap AG serves to prevent the highly sensitive security-relevant data and units in the token issuing 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 (generated by a random generator), from being read via a network attack on the token issuing unit TH and used to manipulate the transaction system TS. The TH-TG can be completely isolated. For example, the TH-TG has no interface to a network, such as TCP / IP, the Internet, the mobile network, etc.

[0080] Upon request from a central bank, a subscriber unit (TE), or a bank subscriber unit (e.g., a commercial bank), the destruction (deletion) of a token T is initiated in the token issuer (TH). The token issuer's 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 separated from each other and preferably have an air gap (AG).The airgap AG serves to prevent the highly sensitive security-relevant data and units in the token issuing unit TH, in particular a private key pKeyiH and secret token elements r (of a token element pair) for tokens T to be deleted, for example, private parts of cryptographic key pairs (generated by a random number generator), from being read via a network attack on the token issuing unit TH and used to manipulate the transaction system TS. The TH-TV can be completely isolated. For example, the TH-TV has no interface to a network, such as TCP / IP, the Internet, the mobile network, etc.

[0081] A token issuing unit TH can have both a TH-TG and a TH-TV. Alternatively, a first token issuing unit of the TS can have only a TH-TG but no TH-TV, and a second token issuing unit of the TS can have only a TH-TV but no TH-TG.

[0082] 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 in a range of 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.

[0083] 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 be unpredictable and is generated using a true random number generator.

[0084] For example, the token value v is a 32-bit token element of type integer.

[0085] For example, 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 store, for example, in the CBS, and then has a unique tag and length information, for example, in the following format.

[0086] An example of a TLV-encoded token in hexadecimal form is shown below:

[0087] 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 and is interpreted as follows:

[0088] "42" is the tag identifying the TLV-encoded token T;

[0089] "24" indicates the length, in this case that it is a 36-byte data record;

[0090] "00 0040 00" is the token value (integer) v = 16384 and is therefore € 163.84;

[0091] "00 01 02 03 04 05 06 0708 09 ... ID IE 1F" is the random number r as an integer.

[0092] For the secure generation of an issueable token by a token issuer of an electronic transaction system TS with token reference register TRR, the following steps of the method according to the first aspect of the invention are carried out, also with reference to Fig. 2.

[0093] In step 200, a token generation request is optionally received by the TH-TM. The token generation request can be sent by a central bank authority. This request can be for a single token T or a series of tokens T, for example, "Generate 200 tokens with a value of 100." The request can refer to a time period, for example, "Generate 200 tokens with a value of 100 for today" or "Generate 200 tokens with a value of 100 in the next hour." In step 201, 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.

[0094] In step 202, a new token element pair R is optionally created ne w, r new. A token element pair r, R comprises 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.

[0095] In step 203, the public token reference element Rnew is optionally provided (sent) within (or to) the TH-TM.

[0096] The optional steps 200-203 can be executed differently. According to the process shown in Fig. 2, the TH-TM can receive 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 need 20 tokens with a value of 50 now."

[0097] However, a request from a bank, for example, a B-TE, "please issue a token with value 100 to R_new," could also - alternatively - already include a new public token reference element Rnew. In this case, the TH-TE is not involved in the generation of the new (to be issued) token. In this case, the B-TE (external to the TH) generates the new token element pair Rnew, Tnew in step 202. In step 203, the B-TE sends the request to the TH-TM. In this case, advantageously, no TH-TE would be necessary in the TH, and the architecture of the TH would be less complex.

[0098] In step 211, a token generation request is then received from the TH-TM to the TH-TG.

[0099] In 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 present only in the token generation unit TH-TG.

[0100] In step 214, an addition command is generated in the TH-TG. A signature from the TH can be used for this purpose. The addition command can be signed with a key from the TH and is, for example, SIG_Ttem P = sig (sKeym ; CREATE | | TR te mp)

[0101] In step 215, the secure token generation unit TH-TG sends the addition command 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.

[0102] In step 218, a replacement command is generated. This command instructs the TRR to replace the token reference TRtemp of the temporary token element pair with the token reference TR ne w of the issueable token T new to register. The replacement command can be signed with the secret token element and is, for example:

[0103] SIG_Tnew = sig (rtemp SWITCH I | TRtemp, TRnew)

[0104] A replacement means any amount-neutral modification of the token, in particular a switch command, but also a merge command of the token T ne w with a token with a token value v = 0 or splitting the token Ttemp to a token T ne w and a token with token value v = 0.

[0105] In step 219, the replacement command is sent from the TH-TG to the TH-TM.

[0106] In 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, for example:

[0107] CREATE TRtemp

[0108] In step 224, the TRR optionally generates an addition confirmation HB. The HB can be signed with a TRR key and is, for example, as follows:

[0109] HB = sig(sKeyTRR; TRtemp) In step 225, the addition confirmation HB is then optionally received from the TRR in the TH-TM.

[0110] In step 231, the replacement command is then sent to the TRR. The replacement command is, for example:

[0111] SWITCH TRtemp, TRnew

[0112] In step 232, the token reference TRtemp is replaced with the token reference TR ne w.

[0113] In step 234, a replacement confirmation RB is optionally generated. The RB can be signed with a TRR key and is, for example, as follows:

[0114] RB = sig(sKeyTRR; TR new )

[0115] In step 235, the replacement confirmation RB is received from the TRR in the TH-TM.

[0116] In step 237, the replacement confirmation EB is optionally received in the TH-TE. The RB can be:

[0117] RB (TR new) / Vnew

[0118] In step 238, the new token T is optionally saved / activated. ne w.

[0119] In step 239, a confirmation for new tokens T that can be issued is optionally sent. new

[0120] In 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 ne w. The TH-TM therefore remembers the completion of the generation in step 240.

[0121] In step 250, the new token T is optionally issued new to a B-TE or another TE of the TS. In one embodiment of Fig. 2, step 215 is optional, because the commands of steps 214 and 218 can be transmitted together. Then, steps 221, 231 would be a joint transmission of the two commands, and with a joint transmission, either only confirmation step 225 or only confirmation step 235, or both confirmation steps 225 and 235 would occur.

[0122] In a further embodiment of Fig. 2, step 231 is performed by TH-TE or even by B-TE.

[0123] In a further embodiment of Fig. 2, step 221 in the TRR is only received by the TH, i.e., by the TH-TM or TH-TE. Then, the sequences of steps 237, 238, 239 change accordingly, such that the replacement confirmation RB can only come from the TH-TE or B-TE, so that v new and / or RB arrives at the TH-TM in step 237 and step 238 serves to ensure that the new token T is complete or activated as issueable.

[0124] In one embodiment, the following method may be executed to generate a new token.

[0125] The TH-TM requests the public key Rnew of a new token T from a processor (payment processor) (TH-TE) ne u. The payment processor (TH-TE) stores the corresponding private key r ne u in a temporary wallet.

[0126] The TH-TM creates a "minting order", i.e. a request to the TH-TG to provide a new token and transmits the token value v and the public key Rnew (from step 1) to the TH-TG in this request.

[0127] 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.

[0128] The TH-TG performs a switch (=SWITCH command) from the temporary token Ttemp to the new token T ne u. To switch, the TH-TG only needs the public key Rneu provided by the TH-TM. A registration request is created, containing the command history (CmdHist) of the switch command and the create command. The token value v and the private key rtemp, as well as the registration request RA, are provided to the TH-TM.

[0129] The TH-TM sends the registration request RA to the TRR and receives a registration confirmation RB.

[0130] The registration confirmation RB and the registration request RA are sent to the payment processor TH-TE.

[0131] In 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 ne u is removed from the temporary wallet and together with v ne u saved as Tnew.

[0132] For each token T, a token reference TR is stored in the token reference register TRR. The token reference TR comprises the token value v of the associated 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 register TRR of the transaction system TS. Thus, the token value v of a token T is disclosed by the token reference register TRR.

[0133] 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 provides the transaction system TS with the required security. R = r * G applies, where G can be, for example, a global parameter of the transaction system TS, e.g., a generator point of an elliptic curve, in this case the secp256rl curve.

[0134] 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 thus the link or concatenation of the token value v and the public part R.

[0135] This token reference TR can be sent to the token reference register TRR as a registration request RA, possibly together with a command regarding the token T. Additionally, 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, thereby further increasing security in the transaction system TS.

[0136] In the subscriber unit TE, the signed registration request RA Sig stored as a so-called evidence record, PR (for Proof), for example in the following format:

[0137] An example of a PR (=RA Sig ) in hexadecimal form is shown below:

[0138] 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 and is interpreted as follows:

[0139] "4A" is the tag for identifying the TLV proof RASI^TH;

[0140] "81 8F" indicates the length;

[0141] "03" indicates that it is a switch registration request;

[0142] "11 1213 14" is the token value v a ;

[0143] "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" is the public part R a ;

[0144] "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" is the public part 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" is the signature as an X690 sequence.

[0145] 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. After the registration request RA is verified by the token reference register TRR, the token reference TR is stored in the token reference register TRR, thereby registering the token T in the transaction system TS. From this point on, the token T can be used in the transaction system TS.

[0146] This token reference TR is uniquely assigned to token T and serves to register token T in the transaction system TS. The token reference TR is therefore the public representation of token T. The sole knowledge or possession of the token reference TR does not permit the transfer of token T and is not synonymous with the TE being in possession of token T. The token reference TR serves to prevent multiple issuance attempts and checks whether token values ​​v have been generated improperly. Therefore, the token reference TR and, if applicable, the history of token T and the corresponding registration requests RA from subscriber units TE are stored in the token reference register TRR.

[0147] The tokens T are stored, for example, in electronic wallets. These wallets are, for example, software applications within the subscriber units (TE) or a terminal device in which the TE is integrated and ready for use. 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 the TE's tokens T, generate token references TR, modify tokens T, and / or exchange tokens T. Wallets are used to communicate with the token reference register (TRR), generate registration requests RA to the token reference register (TRR), and / or perform transactions from token T to a subscriber unit (TE).

[0148] For a direct transaction of token T, it is not necessary for a communication connection to the token reference register TRR of the transaction system TS to exist. The transaction system TS is configured to execute a transaction "offline," i.e., without a communication connection to the token reference register TRR. A corresponding registration of token T can therefore be performed after a transfer of token T to a subscriber unit TE.

[0149] 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.

[0150] The token reference register TRR specifically manages 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 database 1 as a representative.

[0151] In addition, 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. Syntactical 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. Separating this verification unit 2 from the database 1 distributes the storage and checking tasks and increases the speed of the token reference register TRR.

[0152] In addition, the token reference register TRR can include a verification unit (not explicitly shown) that checks whether the token value v of a received token reference TR changes a total token value Z in the transaction system TS. If this is the case, then a new token value v has been created or an existing token value v has been destroyed. This is permitted only by privileged entities, such as an issuing entity TH, in the transaction system TS. If such a change to the total sum of the token values ​​is detected by a token reference TR of a subscriber unit TE, then fraud can be assumed. This makes it very easy to detect and prevent the illegal generation of token values ​​v.

[0153] The verification of the total token value by the verification unit represents another security concept in the TS transaction system. A registration request RA is preferably signed with the private part r. The signature allows the recipient (TRR or TE) to easily verify the syntactical authenticity of the command. This verification preferably takes place in database 1 or verification unit 2. Furthermore, a registration request RA can be syntactically validated, for example, by verifying the signature and / or the token reference TR.

[0154] Even if a signature can be verified in a subscriber unit (TE), this does not guarantee that multiple issuance of the same token (T) has not been attempted. Therefore, registration in the token reference register (TRR) is required. Furthermore, the subscriber units (TE) maintain a secure hardware platform. With an available connection to the token reference register (TRR), the token references (TR) are transmitted, and multiple issuance attempts can be detected in the token reference register (TRR).

[0155] If a token reference TR is not yet known in the token reference register TRR, it is added.

[0156] Fig. 3 describes a process flow for destroying a token T from the transaction system TS. To prevent the token T to be destroyed (=deleted) o id is stolen during the transfer to the TH-TV, a replacement command is combined with the removal command.

[0157] In step 300, a token destruction request is optionally received. The token destruction request can be sent by a central bank authority. This request can be for a single token T o id or a series of tokens T o id, for example, "Destroy 200 tokens with a value of 100". The request can concern a time period, for example, "Destroy 200 tokens with a value of 100 for today (or in the next hour)."

[0158] In step 301, 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.

[0159] In step 302, the old token(s) T are optionally deactivated. o id in the TH-TE. In step 303, the old token reference element TR is optionally sent o id.

[0160] Steps 300-303 can be executed differently. According to the sequence in Fig. 3, the TH-TM can receive 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 deleting 20 tokens with a value of 50 now."

[0161] 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 contain a public token reference element R that is to be deleted. o id, then TH-TE is not involved in the destruction of the token T to be deleted o id involved. In this case, the B-TE (external to the TH) names the R o id. In step 303, the B-TE sends the request to the TH-TM. In this case, advantageously, no TH-TE would be necessary in the TH, and the architecture of the TH would be less complex.

[0162] In step 311, an optional reception of a destruction request from the TH-TM to the TH-TV takes place.

[0163] In step 312, a temporary token element pair Rtem is generated P 2, rtemp2.

[0164] In step 313, the temporary token reference element Rtem is sent P 2 from the TH-TV to the TH-TM.

[0165] In step 314, a removal command is generated. The removal command can be signed with the TH key and is, for example:

[0166] SIG_Ttem P 2 = sig (sKeyiH; DESTROY | | TR te m P 2)

[0167] In step 315, the generated remove 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.

[0168] In step 317, the temporary token reference element Rtem is received P 2 from the TH-TM in the TH-TE. In step 318, a replacement command is generated. This command is used to instruct the TRR to replace the token reference TR o id of the token to be withdrawn T o id the token reference TRtem P 2 of the internal, temporary token Ttem P 2. The replacement command is, for example:

[0169] SWITCH TRoid, TRtemp2

[0170] Replacing means any amount-neutral modification of the token, in particular a switch command, but also a merge command of the token with a token with a token value v = 0 or a splitting of the token into a token and a token with a token value v = 0.

[0171] In step 319, the generated replacement command is sent from the TH-TE to the TH-TM.

[0172] In step 321, the replacement command from step 318 is sent from the TH-TM to the TRR.

[0173] In step 322, the token reference TR is replaced o id with the token reference TR te mp2 in TRR.

[0174] In step 325, a replacement confirmation is optionally received from the TRR to the TH-TM. The replacement confirmation RB can be signed with a key from the TRR and is, for example:

[0175] RB = sig(sKeyTRR, TR te m2)

[0176] In step 331, the TH-TM sends the removal command to the TRR. The removal command is, for example,

[0177] DESTROY TRtem P 2

[0178] In step 332, the temporary token reference TRt is removed em 2 in the TRR.

[0179] In step 334, a removal confirmation EB is optionally generated. In step 335, the removal confirmation EB generated in step 334 is optionally received from the TRR to the TH-TM. The EB can be signed with a key of the TRR and is, for example, as follows:

[0180] EB = sig(sKeyTRR; TR te m2)

[0181] In step 337, the forwarded removal confirmation EB is optionally received by the TH-TE.

[0182] In step 338 the old token T is deleted o id in the TH-TE.

[0183] In step 339, a deletion confirmation is optionally received.

[0184] In step 340, the completion of the destruction is optionally saved in the TH-TM.

[0185] In one embodiment of Fig. 3, 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.

[0186] In one embodiment, the following method may be executed to destroy a token.

[0187] The TH-TM identifies a token T o id that is present in the payment processor (in a specially designated memory area, or a TH-TE) and is to be deleted.

[0188] The TH-TM requires the TH-TV to export a public key Rtem P 2 for the token T to be deleted o id. The TH-TV stores the corresponding private key rtem P 2 in its secure storage.

[0189] In the TH-TM a) a switching command from T o id on Tt em2 under Create 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 switchover 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.

[0190] The TH-TV verifies the deletion request, registration request RA, and registration confirmation RB of the TRR. The CMS executes a DESTROY command on the token Tt. e m P 2 using the private key pKeyiH of the TH-TV and the private key rt emp 2.

[0191] The TH-TV exports the deletion command to the TH-TM by creating a registration request RA.

[0192] The TH-TM sends the registration request RA regarding the DELETE command to the TRR. Upon registration of the DELETE command in the TRR, the token Tt emp 2 deleted (it no longer exists for the TRR).

[0193] The deletion process can be fully automated, requiring no manual interaction. If an air-gap AG is also required (a system requirement, if applicable), a batch run can be performed for all tokens to be deleted, in which all required public keys are requested from the CMS in advance, for example, at the end of a business day (for the deletions of that business day). Alternatively, all tokens to be deleted are first combined (MERGEd), and only one connected token is finally deleted.

[0194] Each command can be signed to verify that the sender of the token reference TR also possesses the corresponding 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. For "Create" and "Delete" commands, an additional signature from the token issuing unit TH can be required to ensure that these commands were generated by a privileged unit of the transaction system TS.

[0195] Fig. 4 shows an embodiment of a flow diagram of a method for transferring a token T between a TE1 and a TE2 based on a switch command of an existing token T a In addition, the required signed registration request RA S ig_Ta and a registration confirmation RB with command structure are shown.

[0196] In the TE1 there is a token Ta present. The token T a has a token value v a and the private part r of the token-specific key pair. The corresponding token reference TR a is registered in the token reference register TRR to TE1. A token Tb with the token value vb is to be transferred between TE1 and TE2.

[0197] To do this, TE1 sends a transfer information Ü or token information (for example, the token value vb itself) to 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. By applying a cryptographic one-way function, the public part Rb of the key pair is generated in TE2.

[0198] 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 in 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.

[0199] In the TE1 the token T a switched to the token Tb to be transferred. Subsequently, a registration request RA is created and sent Sig T a 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 generated with the random number r a of the token T a signed. The signed registration request RA S ig_T ais sent by the subscriber unit TE1 to the token reference register TRR. There, the signature is verified. In addition, the token value v a compared with the token value vb. If v a = vb and the signature verification is successful, then the token reference TR a in the token reference register TRR is deleted or marked as deleted, and the token reference TRb is entered in the token reference register TRR. From this point on, the token Tb is registered to TE2. The successful registration is indicated by the TRR to 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.

[0200] The registration confirmation RB can be sent from TE1 to TE2 to inform TE2 of the successful 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? is transferred from TE1 to TE2 without the token having to be transferred from TE1 to TE2 with both token elements.

[0201] The generated public part Rb is then transferred to TE1. TE1 takes over the registration by issuing a "SWITCH" command. A confirmation RB is returned, if necessary, with a signature of the TRR Sig (vb, Rb) for the generated public part Rb and the token value vb. A final switchover in TE2 is thus unnecessary, making the process less complex.

[0202] In Fig. 5 is an embodiment of a flow diagram of a method for connecting a token Ta with a token T eand registering the associated 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 TE layer and the TR layer perspective are shown in tabular form.

[0203] A random number rf is generated in a TE1 of the TE layer. Based on this, a public part Rf is then generated. Furthermore, a sum of the token values ​​va and v is calculated. e to the token value Vf based on the input tokens Td and T e .

[0204] The output token reference TRf is then generated. 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 and the initial token reference TRf. This registration request RA is signed once with the random number ra of the token Td to create a first signed registration request RA Sig_Td. This registration request is also supplemented with the random number r e of the token T e signed to 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 to the token reference register TRR. There, the signatures of the registration requests RA S ig_Td and RA S ig_Te is checked. In addition, the sum of the token values ​​va and v e formed and compared with the token value Vf. If Vf = vd + v e applies and both signature checks are successful, then TRd and TR e in the token reference register TRR is deleted or marked as deleted, and the token reference TRf is entered into the token reference register TRR. The associated token Tf (which has been transferred from TE1 to TE2 in the meantime) can now be checked for validity by the subscriber unit TE2 in the TRR.

[0205] Fig. 6 shows a further embodiment of a token reference register TRR of a transaction system TS. It is indicated here that multiple storage units 1 can be provided in the token reference register TRR to accelerate the storage of a large number of token references TR. It is also indicated here that multiple verification units 2 can be provided in the token reference register TRR to accelerate the verification of registration requests RA. Furthermore, 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.

[0206] In addition, Fig. 6 shows a registration request unit RAE, which can receive a sequence of registration requests RA from a subscriber unit TE1.

[0207] It is advantageous if only one token T is used per subscriber unit TE (here as a secure element, e.g., smart card or TEE). This means that the TE combines a received token T with the token T stored in the token memory (MERGE). This also means that the TE splits a token T to be sent from the token T stored in the token memory (SPLIT). These modifications to the token T can be performed without a registration request RA, and the token T can be forwarded immediately after a modification. This can result in a sequence of modifications to the token T that are unknown to the TRR. Typically, the sequence of registration requests RA consists of a combination of SPLIT and MERGE modifications. Each of these modifications is also referred to as a "proof" (see Fig. 1 above) or a signed registration request RA. Sig stored with the token T. This creates a sequence of registration requests RAF in the TE. REFERENCE SYMBOL LIST

[0208] TS transaction system

[0209] TH Token Issuer Unit

[0210] TH-TG token generation unit

[0211] TH-TV token destruction unit

[0212] TH-TM Token Issuer Management Unit

[0213] TH-TE Token Issuer Participant Unit

[0214] AG Air Gap

[0215] TE1 Subscriber Unit User

[0216] B-TE Bank Subscriber Unit

[0217] TRR Token Reference Register

[0218] T Token

[0219] TR Token Reference

[0220] R, r token element pair

[0221] R public token reference element of the token element pair r secret token element of the token element pair v token value

[0222] HB Addition Confirmation

[0223] RB replacement confirmation

[0224] EB Distance Confirmation sKEyiH private part of the token issuer key pair

[0225] 200 Received token generation request

[0226] 201 Received request for new token reference element

[0227] 202 Creating a new token element pair

[0228] 203 Sending the public token reference element

[0229] 211 Receiving a token generation request

[0230] 212 Creating a temporary token element pair

[0231] 214 Creating an Addition Command

[0232] 215 Sending the add command

[0233] 218 Creating a replacement command

[0234] 219 Sending the replacement command

[0235] 221 Sending the add command to TRR

[0236] 222 Adding the temporary token reference

[0237] 224 Generating an Addition Confirmation

[0238] 225 Receive the addition confirmation from TRR 231 Send the replacement command to TRR

[0239] 232 Replacing the token references

[0240] 234 Generating a replacement confirmation

[0241] 235 Receive replacement confirmation from TRR

[0242] 237 Receiving the replacement confirmation

[0243] 238 Save / Activate the new token

[0244] 239 Send confirmation for new token to be issued

[0245] 240 Save the completion of the generation

[0246] 250 Issue of the new token

[0247] 300 Receiving a token destruction request

[0248] 301 Received request old token reference element

[0249] 302 Deactivating old tokens

[0250] 303 Sending the old token reference element

[0251] 311 Receiving a destruction request

[0252] 312 Creating a temporary token element pair

[0253] 313 Sending the temporary token reference element

[0254] 314 Creating a Remove Command

[0255] 315 Sending the generated command

[0256] 317 Receiving the temporary token reference element

[0257] 318 Creating a replacement command

[0258] 319 Sending the generated command

[0259] 321 Sending the replacement command to TRR

[0260] 322 Replacing the token references

[0261] 325 Received a replacement confirmation from TRR

[0262] 331 Sending the remove command

[0263] 332 Removing the temporary token reference

[0264] 334 Generating a removal confirmation

[0265] 335 Receiving removal confirmation from TRR

[0266] 337 Receiving the forwarded removal confirmation

[0267] 338 Deleting the old token

[0268] 339 Received deletion confirmation

[0269] 340 Save completion of destruction

Claims

Patent claims 1. A method for the secure generation of an issueable token by a token issuer of an electronic transaction system (TS) with a token reference register (TRR), wherein the following steps are carried out in a token issuer unit (TH) comprising a secure token generation unit (TH-TG): - generating (212) a token-specific token element pair comprising a secret token element and a public token reference element in the secure token generation unit (TH-TG); - generating (214) an addition command in the secure token generation unit (TH-TG) which instructs the token reference register (TRR) to add a token reference (TR) comprising the generated public token reference element as an additional token reference (TR) in the token reference register (TRR); - sending (221) the addition command to the token reference register (TRR); characterized in that the generated token element pair is an internal, temporary token element pair (rtemp, Rtemp) of the token generation unit (TH-TG), the token generation unit (TH-TG) has a token reference (TR ne w) of the issueable token (211), and the token generation unit (TH-TG) generates (218) a replacement command which instructs the token reference register (TRR) to replace the token reference (TRtemp) of the temporary token element pair with the token reference (TR ne w) of the issueable token (T new ).

2. The method according to claim 1, wherein the token issuing unit (TH) comprises a secure token storage unit (TH-TE), wherein the secure token storage unit (TH-TE) generates a token-individual token element pair of the issueable token (202).

3. The method according to claim 1 or 2, wherein the secret token element (rtemp) of the internal, temporary token element pair is present only in the token generation unit (TH-TG); and / or the secret token element (r ne w) the issuable token is only present in the token generation unit (TH-TE).

4. The method according to any one of the preceding claims, wherein the addition command and the replacement command are sent (221, 231) together in a common sending step to the token reference register (TRR).

5. The method according to claim 4, wherein as a result of the sending (221, 231) an addition confirmation (HB) and / or a replacement confirmation (RB) is received (225, 235) in the token issuing unit (TH).

6. The method according to one of the preceding claims, wherein the token issuing unit (TH) comprises a secure token management unit (TH-TM), wherein a token generation request is received (200) in the secure token management unit (TH-TM).

7. The method of claim 6, wherein the token generation request already includes the public token reference element (Rnew).

8. A method for the secure destruction of a token by a token issuer of an electronic transaction system (TS) with a token reference register (TRR), wherein the following steps are carried out in a token issuer unit (TH) comprising a secure token destruction unit (TH-TV): - generating (314) a remove command in the token destruction unit (TH-TV) which instructs the token reference register (TRR) to remove a token reference of a registered token from the token reference register (TRR); - sending (321) the removal command to the token reference register (TRR); characterized in that the token destruction unit (TH-TV) generates (312) an internal, temporary token (Ttemp?) before generating the removal command (314) and generates the removal command for the token reference of the internal, temporary token (TRtemp?); and Generating (318) a replacement command which instructs the token reference register (TRR) to replace the token reference (TR o id) of the token to be withdrawn (T o id) the token reference (TRtemp?) of the internal, temporary token (Tt emp 2) to register.

9. The method according to claim 8, wherein the token issuing unit (TH) comprises a secure token storage unit (TH-TE), wherein the secure token storage unit (TH-TE) stores the token to be withdrawn (T o id) deactivated (202).

10. The method according to claim 8 or 9, wherein the secret token element (rtem P2) the internal, temporary token (Ttemp?) is only present in the token destruction unit (TH-TV).

11. The method according to one of the preceding claims 8 to 10, wherein the remove command and the replace command are sent (321, 331) together in a common sending step to the token reference register (TRR).

12. The method according to claim 11, wherein as a result of the sending (321, 331) a removal confirmation (EB) and / or a replacement confirmation (RB) is received (325, 335) in the token issuing unit (TH).

13. The method according to any one of the preceding claims, wherein the token issuing unit (TH) comprises a secure token management unit (TH-TM), wherein a token destruction request is received (300) in the token management unit.

14. Token issuing unit (TH) comprising: an interface to a token reference register (TRR); and a secure token generation unit (TH-TG) for securely generating an issueable token using a method according to one of the preceding claims 1 to 7; and / or a secure token destruction unit (TH-TV) for securely destroying a token using a method according to one of the preceding claims 8 to 13.

15. Token issuing unit (TH) according to claim 14, further comprising: a token issuing subscriber unit (TH-TE) configured to Storing tokens and / or token references; and an interface to a bank subscriber unit (B-TE) or to a central bank unit, configured to receive (200) a Token generation request and / or to receive (300) a token destruction request.

16. Token issuing unit (TH) according to claim 14 or 15, comprising - a token management unit (TH-TM) with an interface to a bank- Participating Unit (B-TE) or to a Central Bank Unit or a Token Issuer Participating Unit (TH-TE), established to: - Issue (250) the issueable token (T ne w); and / or - Saving a completion of the secure destruction of the token (T o id) and / or - Storing a completion of the secure generation of the issueable token (T new).

17. Token issuing unit (TH) according to one of claims 14 to 16, further comprising an air-gap interface between the token management unit (TH-TM) and the secure token generation unit (TH-TG) and / or the secure token destruction unit (TH-TV).

Images