Method for securely generating issuable token, method for securely destroying token, and token issuer

Abstract

The invention relates to a method for securely generating a issuable token by means of a token issuer of an electronic transaction system having a token reference register. The invention also relates to a method for securely destroying a token of an electronic transaction system having a token reference register. The invention further relates to a token issuing device. In a token issuer unit comprising a secure token generation unit, the following steps are performed: generating a token element pair specific to the token, the token element pair comprising a secret token element and a common token reference element; generating an add instruction that instructs the token reference register to add a token reference including the generated common token reference element in the token reference register as an additional token reference; and sending the adding instruction to the token reference register. In this case, the generated token element pair is an internal, temporary token element pair of a token generation unit, the token generation unit receiving a token reference for the issuable token and generating a replacement instruction, the replacement instruction instructs the token reference register to register a token reference of the issuable token in place of a token reference of the temporary token element pair.

Description

[0001] The present invention relates to a method for securely generating issuable tokens by a token issuer of an electronic transaction system having a token reference register. The present invention also relates to a method for securely destroying tokens of an electronic transaction system having a token reference register. The present invention also relates to a token issuer.

[0002] It is known for token-based trading systems to provide a token reference register. A token issuer can initially register token references of tokens that can be issued in the token reference register or delete registered token references of tokens that need to be withdrawn. Conversely, participants in the trading system are only allowed to register token references of tokens in exchange for registered token references of tokens of equal value, for example.

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

[0004] WO 2022 / 008319 A1 describes a token issuer, which includes a separate token generation unit and a token output unit. The private key of the cryptographic key pair of the token issuer can be stored in the hardware security module of the token generation unit. At the request of the token output unit, the token generation unit generates a new token and a signed deposit data set, and the deposit data set can realize the deposit of the new token in the token reference register with the help of a token reference (or token index). The token output unit obtains the token to be issued and the token deposit data set. Before the token output unit outputs the new token to the participant unit of the trading system, the token output unit deposits the token to be issued in the token reference register with the help of the token deposit data set.

[0005] The technical problem to be solved by the present invention is to provide a more secure token issuer unit and a particularly secure method for securely generating or destroying tokens of a trading system. Preferably, the solution should be flexible and not compromise the security of the trading system.

[0006] This technical problem is solved by the technical solution of the independent claim. Other advantageous designs are described in the corresponding dependent claims.

[0007] The technical problem is solved in a first aspect, in particular, by a method for securely generating an issuable token by a token issuer of an electronic transaction system having a token reference register. In a token issuer unit including a secure token generation unit, the following steps are performed: a token-specific token element pair is generated in a secure token generation unit, the token element pair including a secret token element and a public token reference element; an addition instruction is generated in the secure token generation unit, the addition instruction instructing the token reference register to add a token reference including the generated public token reference element in the token reference register as an additional token reference; the addition instruction is sent 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 an issuable token. The token generation unit generates a replacement instruction, the replacement instruction instructing the token reference register to store the token reference of the issuable token instead of the token reference of the temporary token element pair.

[0008] The token contains the token value as the token element.

[0009] In one design, a token issuer unit includes a secure token storage unit (hereinafter also referred to as a token issuer participant unit), wherein the secure token storage unit generates token-specific token element pairs of issuable tokens.

[0010] In one design, the secret token element of an internal, temporary token element pair exists only in the token generation unit; and / or the secret token element of an issuable token exists only in the token generation unit.

[0011] The token contains a secret token element of a token element pair. The token reference contains a public token reference element of the token element pair. The public token reference element is explicitly assigned to the token and / or is derived from the secret token element of the token element pair. In one design, the secret token element is a random number and the public token reference element is the result of a cryptographic function of the secret token element. In one design, the secret token element is a private key of a cryptographic key pair and the public token reference element is a 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 the token issuance management, which is a unit of the token issuer unit, to the token generation unit. Alternatively, the token value is generated with a fixed denomination.

[0013] By means of the method, the internal temporary token generated by the generation step in the token generation unit is not directly transmitted to the token management unit. It is advantageous for the first aspect that the token generation unit generates a replacement instruction (especially a token value-neutral replacement, for example by switching modification, combining modification (with a token with a value of "0") or splitting modification (obtaining a token with a value of "0")) after generating the internal temporary token in order to combine it with the (new) token to be issued. To this end, the public token reference element (R) required for the replacement of the token element pair (r, R) is provided, for example, by a token issuer management unit (a unit of the token issuer unit) or a bank participant unit or a central bank participant unit.

[0014] As the token reference of the new token to be issued is deposited (or registered) in the token reference register, the new token is valid and can be used in the trading system.

[0015] In one embodiment, the token issuer reserves new issuable (but not yet issued) tokens in a secure memory area (e.g. in the token issuer participant unit). Upon request from a participant unit, e.g. a bank participant unit of a transaction system, the issuable tokens can then be immediately (without first executing a secure generation method) output to the requesting participant unit in the transaction system.

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

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

[0018] CDBC wallets may exist in participant units, such as bank participant units of a trading system, which interact with the token issuer unit in order to reserve (request, generate) or return (redeem, destroy) CDBC.

[0019] In the generation step, the issuable token is preferably signed by the private key of the token issuer unit, for example, with the private key of the token generation unit. By signing with the private key part, each participant unit of the transaction system having a public key part assigned thereto can verify whether the token has been reliably generated. This ensures that the token is generated by the token issuer, not by an attacker. By following the method of the present invention, neither the secret key part of the cryptographic key pair of the token issuer unit nor the secret token element will leave the token generation unit. It is therefore feasible to modularly decompose the token issuer into a token issuer management unit and a token generation unit. The two units of the token issuer unit can be arranged remotely from each other in position without compromising security. By being spatially remote, the token issuer unit can be constructed more flexibly and modularly.

[0020] Preferably, in the replacement instruction generation step, the new token is signed with the private part of the cryptographic key pair specific to the temporary token. Thus, the token generation unit shows that it knows the temporary token and the new token. The signature can be an obligation statement for the replacement instruction.

[0021] The validity of the replacement instruction in the token reference register is preferably checked for depositing issuable tokens by checking the signature of the token issuer unit with the aid of the public key portion of the token issuer unit.

[0022] Furthermore, the deposit request in the token reference register is preferably checked by checking the signature with the aid of a public token reference element of the token element pair.

[0023] Preferably, in a common sending step, the add instruction and the replace instruction are sent together to the token reference register. As a result of the common sending, 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 issuer unit.

[0024] The token reference register (Tokenreferenzregister) preferably sends a deposit confirmation (=replacement confirmation) when the replacement command is valid.

[0025] The token issuer management unit of the token issuer unit preferably transmits the new token to be issued to the participant unit, preferably the bank participant unit, after obtaining the deposit confirmation (= replacement confirmation), and the new token to be issued has the token value and the secret token element of the token element pair.

[0026] In a second aspect, a method for securely destroying tokens by a token issuer of an electronic transaction system having a token reference register is provided, wherein, in a token issuer unit including a secure token destruction unit, the following steps are performed: generating a removal instruction in the token destruction unit, the removal instruction instructing the token reference register to remove the token reference of the stored token from the token reference register; sending the removal instruction to the token reference register. Before generating the removal instruction, the token destruction unit generates an internal, temporary token and generates a removal instruction for the token reference of the internal, temporary token. In addition, a replacement instruction is generated, the replacement instruction instructing the token reference register to store the token reference of the internal, temporary token to replace the token reference of the token that needs to be reclaimed.

[0027] Similar to the secure generation of tokens according to the first aspect, the second aspect is now used to destroy (delete) tokens in the transaction system. The advantages and technical problems to be solved are the same as the first aspect.

[0028] In particular, by the method according to the second aspect, the internal temporary token generated by the generation step in the token destruction unit is not directly transmitted to the token management unit. For the second aspect, it is advantageous that after the internal temporary token is generated, the token destruction unit generates a replacement instruction (especially a token value-neutral replacement, such as by switching modification, combining modification (with a token with a value of "0") or split modification (obtaining a token with a value of "0")) so as to deposit the token reference of the internal, temporary token instead of the token reference of the token that needs to be withdrawn (needs to be destroyed). To this end, the token reference required for the replacement of the token that needs to be withdrawn is provided, for example, by the token issuer management unit (a unit of the token issuer unit) or the bank participant unit or the central bank participant unit.

[0029] In order to prevent the token to be destroyed (=deleted) from being stolen during the process of being transmitted to the destruction unit of the token issuer, the replacement instruction is combined with the removal instruction according to the present invention.

[0030] The token issuer unit includes a secure token storage unit, wherein the secure token storage unit deactivates the tokens that need to be reclaimed.

[0031] The secret token element of the internal, temporary token preferably only exists in the token destruction unit.

[0032] In a common sending step, the removal instruction and the replacement instruction can be sent together to the token reference register. As a result of the sending, 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 issuer unit.

[0033] The token issuer unit may include a secure token management unit, wherein the token destruction request is received in the token management unit.

[0034] In one design, the tokens to be destroyed (deleted, redeemed) are taken from the deletion directory of the token issuer management device. The deletion directory is a storage area in the token issuer unit, and the participant units of the trading system store the tokens to be deleted (i.e., redeemed) in the storage area.

[0035] In a very preferred design, an air gap interface is implemented between the token generation unit and the token issuer management device. The air gap (English Air-Gap) or air wall (English Air-Wall, similar to a firewall) process is a process that separates the two units (the token generation unit and the token issuer management device) from each other, but still allows the transmission of user data, which is a token, a token element, a token element pair, a key component, etc. The air gap process is used to isolate two different trusted units from each other, but still ensure that the data of the corresponding other unit can be processed.

[0036] In a preferred design, the air gap transmission is configured to physically, logically, electrically and / or electronically separate the token generation unit from the token issuer management device. The two units are therefore formally electrically isolated from each other. In other words, data transmission is not performed only electrically / electronically. Therefore, an attacker who accesses the token issuer management device through a remote network cannot access the token generation unit. Therefore, an attacker cannot place data into the token generation unit and / or obtain data from the token generation unit (such as a temporary token or the private part of the token issuer key pair). To this end, there is no (permanent, physical) data connection (OSI layer 1) between the token generation unit and the token issuer management device.

[0037] In a preferred design, the transmission is realized in an air gap process using a portable electronic data storage device such as a USB disk, a memory card, a CD or the like. To this end, corresponding electronic interfaces such as a USB port, a memory card reader or a CD drive are provided on the token generation unit and the token issuer management device.

[0038] In a preferred design, the token generation unit is also configured to generate a token-representing mark (as a physical representation of the token) for transmission in an air gap process. The token issuer management device is configured to read in the token mark generated by the token generation unit. This is a relatively simple form of implementing the air gap process. The mark can be transported to the read-in area of ​​the token issuer management device, for example, by a mechanical transport mechanism. The transport box described can also be used for this, so that the mark is automatically arranged in the transport box by the token generation unit, for example, and then the mark is transported to the token issuer management device, especially its reading area, and the mark is read there.

[0039] In a preferred design, at the end of the predefined time period, all tokens that need to be deleted within the predefined time period are deleted as a stacking process (= batch processing). Thus, the number of transmission steps at only one specific time point is reduced to one, which greatly reduces the costs, especially in the air gap process.

[0040] Preferably, before executing the method according to the second aspect, all tokens that need to be deleted within the predefined time period are combined to form a common deletion token at the end of the predefined time period by applying one or more combination instructions, thereby greatly reducing the number of transmission steps and thus reducing the cost for generating and / or deleting tokens.

[0041] Preferably, the predefined time period is one month, preferably one week, more preferably one day, and further preferably one hour.

[0042] If the add instruction is valid and the temporary token reference has been added to the token reference register, the token reference register preferably sends an add confirmation. The token issuer unit, in particular the secure token issuer management unit, thereby knows that there is a temporary token reference in the token reference register.

[0043] 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 participant units can directly exchange (transfer) digital central bank money (CDBC) in the form of tokens with one another. Thus, for example, the transaction system is a payment transaction system for exchanging monetary values ​​in the form of payment tokens.

[0044] A token is a data set of a trading system that can be exchanged directly between participant units. By registering a token reference (Tokenreferenz) in a token reference register, the token is considered to have been generated and / or deleted and / or transferred, and from this point in time, the receiving participant unit owns the token value represented by the token. Therefore, through the transfer process, the token automatically changes hands (from the issuer to the participant unit). A token is a data set that can be transferred independently of the transaction topology, such as the blockchain topology "Bitcoin", "Ethereum" or "Neo". The token can be transferred directly between participant units or by the token issuer without connecting the units in the middle.

[0045] In one design, the token is an electronic coin data set or payment token to exchange monetary value between participant units. In layman's terms, this payment token is also called "digital coin" or "electronic coin", which means electronic cash.

[0046] Each token in the trading system is a data set consisting of at least two token elements.

[0047] The first token element of each token of the trading system is the token value, such as asset value, asset, economic item and / or monetary value.

[0048] The second token element of each token of the trading system is a secret token element of the token element pair, such as the private part of a token-specific key pair. This private part is a secret in the trading system, will not be published, and cannot be used multiple times. The generation of the private part is unpredictable. The private part can be a random number. The random number is preferably the result of a true random number generator.

[0049] The token is formed by a token value (a first token element) and a secret token element. The formation is preferably to link (connect in series) these two token elements. According to the present invention, any other combination of these two token elements is not excluded and includes, for example, adding them together in sequence, inserting them into a TLV data structure and / or logically combining them.

[0050] Tokens differ from data sets used for conventional data exchange or data transmission, because conventional data exchange is carried out, for example, according to the question-and-answer principle or mutual communication between data exchange partners. In contrast, tokens are unique and unambiguous in a transaction system. Tokens are in the context of security schemes, such as signatures or cryptographic encryption. The token contains all the data elements required for the receiving participant unit to verify, authenticate and forward the token to another participant unit. Therefore, mutual communication between the participant units that transfer the token is not necessary in principle for tokens.

[0051] Anyone who owns a token or has unrestricted access to a token and its token elements can exchange (= transfer) a token with another participant unit. Thus, owning a token and at least two of its token elements (token value and the private part of a token-specific key pair) is equivalent to owning the value represented by the token. In this context, tokens can also be transferred indirectly by depositing a token reference.

[0052] Each token in the trading system is configured with a token reference. This configuration is unambiguous, i.e. one token is configured with exactly one token reference, and each token reference is configured with exactly one token. The token reference is a public data set that is stored in a memory unit of the token reference register of the trading system in a manner verifiable to each participant unit.

[0053] Both the token and the token reference are unique. Due to the explicit configuration, there is a 1-to-1 relationship between the token and the token reference.

[0054] Each token reference in the trading system is a dataset consisting of at least two token reference elements.

[0055] The first token reference element of each token reference is the token value of the token explicitly assigned to the token reference. Therefore, the token value of the token is the same as the token value of the assigned token reference. For example, the token value of the token reference is a copy of the token value of the assigned token.

[0056] The second token element of each token reference of the trading system is the public token reference element of the token element pair, such as the public part of the token-specific key pair. The public part of the token reference and the private part of the token together constitute 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 a token element pair.

[0057] The cryptographic function (or encryption function) is a one-way function. Therefore, this cryptographic function is a mathematical function that is "easy" to calculate from the perspective of complexity theory, but "difficult" to reverse, or even impossible to reverse in practice. A one-way function also refers to a function whose reverse function is not yet known, which can be implemented in practice within a reasonable time and with reasonable effort. Preferably, a one-way function is used, which performs operations on groups that are difficult to solve the discrete logarithm problem from the private key of the corresponding cryptographic method, such as a cryptographic method similar to elliptic curve cryptography (ECC for short). Here, the reverse function, that is, generating a token (or part of an electronic coin data set) from a token reference, is very time-consuming.

[0058] (Rough) knowledge or possession of a token reference does not entitle the user to use / transfer / issue the token value (token reference element). This represents the essential difference between a token reference and a token, and is the core of the invention.

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

[0060] The token reference is formed by the token value (first token reference element) and the common part. The formation is preferably to link (concatenate) the two token reference elements. According to the present invention, any other way of combining the two token reference elements is not excluded and for example includes adding them together in sequence, inserting them into a TLV data structure and / or combining them logically.

[0061] The token reference can also be generated by an electronic wallet. The use of the token reference is different from the use of the participant unit address in the blockchain-based transaction system, because the participant unit address is not used in the token reference register according to the present invention to prevent the traceability of the token.

[0062] The method for depositing specifies a receiving step for receiving a token reference in a token reference register within the scope of a deposit request, for example, the deposit request is sent by a participant unit or a token issuer management device of a transaction system (herein as an add instruction and a replace instruction).

[0063] The token reference register is a unit of the transaction register in which token references are stored, thereby registering the relevant tokens. The register may be a central database or a memory unit. The register may be a decentralized ledger, such as a ledger in a blockchain topology. The token reference register may have a history of token references and / or registration requests.

[0064] The received deposit request is verified by a verification unit in the token reference register. Here, it is verified whether at least one token reference of the received deposit request has been stored in the token reference register. In the token reference register, a token reference is only stored once. Since the token reference of a token exists only once in the transaction system, it can be determined by the verification step whether someone has attempted to issue tokens multiple times. In one design, it is determined in the verification step whether the signature of the deposit request is correct.

[0065] A switching modification can be applied to a replacement token. For the switching modification, the following method steps are performed: a token reference for the (new) token to be generated is received from the token issuer; a deposit request is generated, the deposit request comprising a token reference for a temporary token and a token reference for the (generated) new token. Switching a token is a modification possibility for modifying a token. The token references contained in the deposit request can be combined with each other by linking (concatenation). If a token is transferred directly from one participant unit to another, for example if a monetary value should be transferred as a token value within the scope of a payment transaction, the sending participant unit can now re-deposit the token value in its own name. The switch is thus registered in the token reference register.

[0066] The token value of the temporary token corresponds to the token value of the new token. Thus, tokens with the same token value at the time of the switch but with a new private part are registered in the token reference register.

[0067] The token reference register knows the token references of the tokens of the trading system and preferably also has a record of the processing or modification of the tokens (token history). The transactions of tokens are not stored in the token reference register, but are implemented directly between the participant units of the trading system in the direct transaction layer of the trading system.

[0068] In another aspect, a token issuer unit of a trading system is provided. The token issuer unit may include: an interface with a token reference register; and a secure token generation unit for securely generating issuable tokens by means of a method according to the first aspect; and / or a secure token destruction unit for securely destroying tokens by means of a method according to the second aspect.

[0069] The token issuer unit may further include: a token issuer participant unit configured to store tokens and / or token references; and an interface with a bank participant unit or with a central bank unit, which is configured to receive a token generation request and / or to receive a token destruction request.

[0070] The token issuer unit may further include a token management unit having an interface with a bank participant unit or a central bank unit or a token issuer participant unit, and the token management unit is configured to output issuable tokens and / or complete secure destruction of stored tokens and / or complete secure generation of stored issuable tokens.

[0071] The token issuer unit may further include an air gap interface between the token management unit and the secure token generation unit and / or the secure token destruction unit.

[0072] Preferably, the token issuer comprises an air gap interface between the token issuer management device and the token generating unit for at least one transmission step of the method according to the first and / or second aspect.

[0073] The token reference register may be an institution of the central currency system and each token may be a central bank digital currency. The digital currency system as a transaction system comprises a plurality of said participant units, a token reference register and a token issuer.

[0074] A participant unit, such as a bank participant unit or an issuer participant unit, can be a secure element (Secure Element) that can securely access one or more tokens in a token storage. For example, the secure element is installed in an operational manner in a terminal device. The secure element and / or the terminal device has a special computer program product (electronic wallet, Wallet), especially in the form of a secure operating environment (Trusted Execution Environments, TEE) within the operating system of the terminal device, stored on a data storage device such as a mobile terminal device, a machine or an ATM. Alternatively, the secure element is designed, for example, in the form of special hardware, especially a secure hardware platform module (Trusted Platform Module, TPM) or as an embedded security module (eUICC, eSIM). The secure element provides a trustworthy environment.

[0075] The invention and further embodiments and advantages of the invention are explained in more detail below with reference to the accompanying drawings, wherein the drawings only describe embodiments of the invention. Identical components are provided with the same reference numerals in the drawings. The drawings should not be regarded as being to scale, and individual elements of the drawings may be exaggerated or oversimplified.

[0076] Figure 1 An embodiment of a token issuer unit is shown;

[0077] Figure 2 An embodiment of the step flow in the token issuer unit according to the method of the first aspect is shown;

[0078] Figure 3 An embodiment of the step flow in the token issuer unit according to the method of the second aspect is shown;

[0079] Figure 4 An embodiment of a flow chart showing the switching of tokens;

[0080] Figure 5 One embodiment of a flow chart illustrating the binding of tokens; and

[0081] Figure 6 One embodiment of a transaction system is shown.

[0082] Figure 1 An embodiment of a token issuer unit TH for a trading system TS is shown. In this embodiment, the token is a digital currency, in which case the token issuer can only be a central bank, and the trading system TS is a central bank digital currency system. The token issuer unit TH issues the token T as a digital coin data set to the participant unit TE, for example directly to a bank customer or preferably to a bank participant unit B-TE. The token issuer unit TH provides an original deposit of the newly generated (to be issued) token T in the token reference register TRR of the trading system TS.

[0083] Each token T in the trading system TS is initially (only) securely generated by the token issuer unit TH (in TH-TG) and is also securely destroyed (deleted) by TH (in TH-TV).

[0084] At the request of the central bank or participant unit TE or bank participant unit (such as a commercial bank), the generation (creation, generation) of token T begins in the token issuer TH. For this purpose, 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 designs also a token issuer participant unit TH-TE. The two units TH-TG and TH-TW (TH-TE) can be separated from each other, preferably with an air gap AG. The air gap AG is used to ensure that highly sensitive security-related data and units in the token issuer unit TH, in particular the private key pKey TH The secret token element r (of the token element pair) of the (new) token T to be issued, such as the private part of the cryptographic key pair (generated by a random number generator), cannot be read out by a network attack on the token issuer TH and used to manipulate the trading system TS. TH-TG can be completely isolated here. For example, TH-TG has no interface with the network, such as TCP / IP, the Internet, the mobile phone network, etc.

[0085] At the request of the central bank or participant unit TE or bank participant unit (such as a commercial bank), the destruction (deletion) of the token T is initiated in the token issuer TH. For this purpose, the token issuer unit TH of the token issuer has a secure token destruction unit TH-TV and a secure token issuer management unit TH-TW, and in some designs also a token issuer participant unit TH-TE. The two units TH-TV and TH-TW (TH-TE) can be separated from each other, preferably with an air gap AG. The air gap AG is used to ensure that highly sensitive security-related data and units in the token issuer unit TH, in particular the private key pKey TH The secret token element r (of the token element pair) of the token T to be destroyed, such as the private part of the cryptographic key pair (generated by a random number generator), cannot be read out by a network attack on the token issuer unit TH and used to manipulate the trading system TS. The TH-TV can be completely isolated here. For example, the TH-TV has no interface with the network, such as TCP / IP, the Internet, the mobile phone network, etc.

[0086] The token issuer unit TH may have not only TH-TG but also TH-TV. Alternatively, it is feasible that the first token issuer unit of TS has only TH-TG but not TH-TV, and the second token issuer unit of TS has only TH-TV but not TH-TG.

[0087] In the trading system TS, a token T is uniquely represented by a token value v and a secret token element, such as a random number r. The token value v can be between 1 and 2. 31 The random number r can be between 0 and 2. 256 A number in the range -1, which is the order of the elliptic curve, such as secp256r1.

[0088] The random number r as an example of a secret token element of a token T is the private part of a token-specific key pair r, R. The random number r is one-time and secret in the transaction system TS and cannot be made public or reused. The generation of the random number r can be unpredictable and generated by a true random number generator.

[0089] For example, the token value v is a 32-bit token element of integer type. For example, the random number r is a 32-byte token element of integer type.

[0090] The token may be stored as a TLV-encoded data set in a token storage, such as in a CBS, and thus has a unique tag and length information, such as in the following format.

[0091] name Label (hexadecimal) length Token value v Public Token Elements TLV-encoded tokens 42 1 byte 4 bytes 32 bytes

[0092] An example representation of a TLV-encoded token in hexadecimal form is as follows:

[0093] 42 24 00 00 40 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 101112 13 14 15 16 17 18 191A 1B 1C 1D 1E 1F

[0094] And the explanation is as follows:

[0095] "42" is a label used to identify the TLV-encoded token T;

[0096] "24" indicates the length, which means this is a 36-byte data set;

[0097] “00 00 40 00” is the token value (integer) v=16384, so 163.84 euros;

[0098] "00 01 02 03 04 05 06 07 08 09 ... 1D 1E 1F" is a random number r which is an integer.

[0099] To ensure that the token issuer of the electronic transaction system TS having the token reference register TRR can safely generate the issuable token, the following steps of the method according to the first aspect of the present invention also refer to Figure 2 implement.

[0100] In step 200, a token generation request is optionally received in TH-TM. The token generation request may be sent by a central bank institution. The request may be for a single token T or for a range of tokens T, such as "generate 200 tokens worth 100". The request may relate to a time period, such as "generate 200 tokens worth 100 today" or "generate 200 tokens worth 100 in the next hour".

[0101] In step 201, a request for a new token reference element is optionally received. The request may be received in a TH-TM, or may be received from a TH-TM to a TH-TE.

[0102] In step 202, a new token element pair R is optionally generated. new 、r new The token element pair r, R comprises in particular a secret token element r of the token element pair (the token element of the token T) and a public token reference element r of the token element pair (the token element of the token reference TR).

[0103] In step 203, a public token reference element R is optionally provided (sent) in (or to) the TH-TM. new .

[0104] Optional steps 200-203 can be performed in different ways. Figure 2 The sequence shown in can receive in TH-TM a general request 200 from the central bank “we need 200 tokens with a value of 100 today” or a request from a bank participant unit B-TE “we need 20 tokens with a value of 50 now”.

[0105] However, the request of a bank (e.g. B-TE) “Please issue a token with a value of 100 on R_new” may alternatively also have included a new public token reference element R new In this case, TH-TE does not participate in the generation of the new token (to be issued). In this case, B-TE (external to TH) generates a new token element pair R in step 202. new 、r new In step 203, the B-TE sends a request to the TH-TM. In this case, the TH-TE may be advantageously not required in the TH, and the architecture of the TH may be less complex.

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

[0107] In step 212, an internal temporary token element pair R is generated. temp 、r temp The internal temporary token element is the secret token element r temp Preferably, it only exists in the token generation unit TH-TG.

[0108] In step 214, an add instruction is generated in TH-TG. For this purpose, the signature of TH can be used. The add instruction can be signed with the key of TH and is, for example:

[0109] SIG_T temp =sig(sKey TH ;CREATE||TR temp )

[0110] In step 215, an add instruction is sent to TH-TW via the secure token generation unit TH-TG. The instruction instructs the token reference register TRR to add the token reference TR including the generated public token reference element as an additional token reference TR in the token reference register TRR.

[0111] In step 218, a replacement instruction is generated. The instruction instructs TRR to deposit the token T that can be issued.new Token reference TR new To replace the temporary token element pair token reference TR temp The replacement instruction may be signed with a secret token element and be, for example:

[0112] SIG_T new =sig(r temp ; SWITCH||TR temp ,TR new )

[0113] Replacement refers to any value-neutral modification of a token, especially a switch instruction, but also refers to a token T new Merge command with a token value v=0, or also refers to the token T temp Split into Token T new And the token with token value v=0.

[0114] In step 219, a replacement instruction is sent from TH-TG to TH-TM.

[0115] In step 221, an add instruction is sent to the TRR. Then, in step 222, the TRR adds the temporary token to the reference TR temp Add to the database. For example, the add command is:

[0116] CREATE TR temp

[0117] In step 224, an addition confirmation HB is optionally generated by the TRR. The HB may be signed with the TRR's key and be, for example:

[0118] HB=sig(sKey TRR ;TR temp )

[0119] In step 225, an add confirmation HB is optionally received from the TRR into the TH-TM.

[0120] Then in step 231, a replacement instruction is sent to the TRR. The replacement instruction is, for example:

[0121] SWITCH TR temp, TR new

[0122] Then in step 232, use the token TR new Replacement token TR temp .

[0123] In step 234, a replacement confirmation RB is optionally generated. For example, the RB may be signed with the key of the TRR and be, for example:

[0124] RB=sig(sKey TRR ;TR new )

[0125] In step 235, the Replacement Confirmation RB is received from the TRR to the TH-TM.

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

[0127] RB(TR new ),v new

[0128] In step 238, the new token T is optionally stored / activated new .

[0129] In step 239, a new token T that can be issued is optionally sent new confirmation.

[0130] In step 240, the completion of the generation is optionally stored in TH-TM, which is a confirmation of the generation of the new token T new Therefore, TH-TM will remember the completion of the generation in step 240.

[0131] In step 250, the new token T new Issued to B-TE or another TE of TS.

[0132] exist Figure 2 In a design scheme, step 215 is optional, because the instructions of steps 214 and 218 can be transmitted together. Steps 221 and 231 will thus be the common transmission of two instructions. In the case of common transmission, either only confirmation step 225 is executed, or only confirmation step 235 is executed, or confirmation steps 225 and 235 are executed simultaneously.

[0133] exist Figure 2 In another design, step 231 is performed by the TH-TE or even by the B-TE.

[0134] exist Figure 2 In another design, step 221 in TRR is received only by TH, that is, by TH-TM or TH-TE. Then, the order of steps 237, 238 and 239 is changed accordingly, that is, the replacement confirmation RB can only come from TH-TE or B-TE, so v new And / or RB reaches TH-TM in step 237, and step 238 is used to ensure that the new token T is complete or activated as a token that can be issued.

[0135] In a design scheme, the following method can be used to generate new tokens.

[0136] TH-TM requests new token T from the processor (payment processor) (TH-TE) neu The public key R neu The payment processor (TH-TE) sends its private key r neu Stored in a temporary wallet.

[0137] TH-TM creates a "coin minting instruction", which is to request TH-TG to provide a new token and transmit the token value v and public key R to TH-TG in the request. neu (from step 1).

[0138] TH-TG creates a temporary token T when applying the CREATE instruction (generate instruction) temp The temporary token consists of the token value v and the temporary private key part r of the temporary token-specific key pair temp composition.

[0139] TH-TG executes from temporary token T temp To the new token T neu TH-TG only needs the public key R provided by TH-TM. neu Create a deposit request, which contains the switch command and the command history (CmdHist) of the generated command. temp And the registration request RA is provided to TH-TM.

[0140] TH-TM sends a registration request RA to TRR and obtains a registration confirmation RB.

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

[0142] Token value v, private key r temp , the deposit request RA and the deposit confirmation are checked and verified in the payment processor TH-TE. neu Removed from temporary wallet and associated with v neu are stored together as T neu .

[0143] For each token T, a token reference TR is stored in the token reference register TRR. The token reference TR includes the token value v of the associated token T and the public part R of the token-specific key pair. The token reference TR of token T can be viewed at any time in the register TRR of the trading system TS. Therefore, the token value v of token T is disclosed through the token reference register TRR.

[0144] 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 therefore provides the necessary security for the trading system TS. R=r*G applies, where G can be, for example, a global parameter of the trading system TS, such as a generator point of an elliptic curve, here a secp256r1 curve.

[0145] The token reference TR consists of the token value v of the token T and the public part R of the key pair. Therefore, the token reference TR is the combination or link of the token value v and the public part R.

[0146] The token reference TR can be sent to the token reference register TRR as a registration request RA, and when necessary, it can be sent to the token reference register TRR together with instructions related to the token T.

[0147] The deposit request RA can additionally be signed with the private part r of the token-specific key pair. The signature can verify whether the sender of the token reference TR has ever owned the token T, thereby further improving the security in the transaction system TS.

[0148] Signed Deposit Request RA sig It is stored in the participant unit TE as a so-called proof data set PR (for proof), for example in the following format:

[0149] type Label (hexadecimal) length data PR 4A N bytes

[0150] The following shows a hexadecimal form of PR (= RA sig ):

[0151] 4A 81 8F 03 11 12 13 14 15 16 17 18 19 1A1B 1C 1D 1E 1F 20 21 22 232425 26 27 28 29 2A2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A3B 3C 3D3E3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 5630 4611 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 2829 2A2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 4142 43 4445 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56

[0152] And the explanation is as follows:

[0153] "4A" is used to identify the TLV certification RA sig_Th Labels;

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

[0155] "03" indicates a switch (= SWITCH) registration request;

[0156] “11 12 13 14” is the token value v a ;

[0157] "15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 292A2B2C 2D 2E 2F 30 31 32 33 34 35" is the common part R a ;

[0158] "36 37 38 39 3A3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A4B 4C4D4E 4F 50 51 52 53 54 55 56" is the public part R h ;

[0159] "30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D3E3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56" is the signature as the X690 sequence.

[0160] The registration request RA may be sent to the token reference register TRR. The registration request RA is received in the token reference register TRR. After the token reference register TRR checks the registration request RA, the token reference TR is stored in the token reference register TRR, thereby registering the token T in the trading system TS. From this point in time, the token T can be used in the trading system TS.

[0161] The token reference TR is explicitly assigned to the token T and is used to deposit the token T in the trading system TS. The token reference TR is therefore a public representation of the token T. Knowing or possessing only the token reference TR does not allow the transfer of token T and is not equivalent to TE owning token T. The token reference TR is used to prevent multiple issuance attempts and to check whether the token value v is generated in an impermissible manner. Therefore, the token reference TR and, if necessary, the history of the token T and the corresponding deposit request RA of the participant unit TE are stored in the token reference register TRR.

[0162] The token T is stored, for example, in an electronic wallet, so-called Wallets. For example, these wallets are software applications in the participant unit TE or in a terminal device in which the participant unit TE is installed in an executable manner. The wallet can be set as an application on a smartphone, a smart card or a payment terminal. The wallet is used to securely manage the token T of TE, generate a token reference TR, modify the token T and / or exchange the token T. The wallet is used to communicate with the token reference register TRR, generate a registration request RA to the token reference register TRR and / or perform a transaction of the token T to the participant unit TE.

[0163] For direct transactions of tokens T, no communication connection with the token reference register TRR of the trading system TS is required. The trading system TS is arranged for transactions "offline", i.e. without a communication connection with the token reference register TRR. Therefore, the corresponding deposit of tokens T can be carried out in time after the transfer of tokens T to the participant unit TE.

[0164] The Token Reference Register TRR is a unit of the Trading System TS and is a central register or central database of the Trading System TS or a decentralized register or decentralized database (DLT) of the Trading System TS.

[0165] The token reference register TRR manages in particular storage locations for token references TR, as an example of memory cells in the token reference register TRR. For example, the TR of the token T of the participant unit TE1 is entered into the database 1 .

[0166] Furthermore, the token reference register TRR may comprise at least one verification unit 2. The verification unit 2 of the token reference register TRR verifies the registration request RA. In this process, the syntactic correctness or the correct description of the instructions in the registration request RA can be verified. Here, the history of old (past) registration requests RA related to the token T can also be verified. Separating the verification unit 2 from the database 1 can disperse the storage and checking tasks and increase the speed of the token reference register TRR.

[0167] Furthermore, the token reference register TRR may include a checking unit (not explicitly shown) which checks whether the total token value Σ in the trading system TS has been changed by the token value v of the received token reference TR. If this is the case, a new token value v has been created or an existing token value v has been destroyed. Only authorized units, such as the issuer organization TH, can perform such operations in the trading system TS. If such a change in the sum of the token values ​​is identified by the token reference TR of the participant unit TE, it can be considered a fraudulent act. Therefore, the illegal generation of the token value v can be easily discovered and prevented.

[0168] Checking the total token value through the checking unit is another security solution in the trading system TS.

[0169] The registration request RA is preferably signed with the private part r. By means of the signature, the recipient (TRR or TE) can conveniently check the grammatical authenticity of the instruction. This check is preferably performed in the database 1 or in the verification unit 2. The registration request RA can also be verified grammatically, for example, by checking the signature and / or the token reference TR.

[0170] Even if the signature can be checked in the participant unit TE, it cannot be ensured that the same token T has not been issued multiple times. Therefore, the registration in the token reference register TRR is provided. In addition, a secure hardware platform is provided by the participant unit TE. The token reference TR is transmitted via an available connection to the token reference register TRR and multiple issuance attempts can be found in the token reference register TRR.

[0171] If the token reference TR is not already known in the token reference register TRR, it is added.

[0172] exist Figure 3 The method flow of destroying token T from the trading system TS is described in old If the transmission to the TH-TV is stolen, the replacement instruction is combined with the removal instruction according to the present invention.

[0173] In step 300, a token destruction request is optionally received. The token destruction request may be sent by a central bank institution. The request may be for a single token T old Or for a series of tokens T old , such as "destroy 200 tokens worth 100". The request can also involve a time period, such as "destroy 200 tokens worth 100 today (or in the next hour)".

[0174] In step 301, a request for an old token reference element is optionally received. The request may be received in the TH-TM, or may be received from the TH-TM to the TH-TE.

[0175] In step 302, the old token / tokens are optionally deactivated in TH-TE. old .

[0176] In step 303, the old token reference element TR is optionally sent old .

[0177] Steps 300-303 can be performed in different ways. Figure 3 The sequence shown in can receive in TH-TM a general request from the central bank 300 “we delete 200 tokens worth 100 today” or a request from a bank “we delete 20 tokens worth 50 now”.

[0178] However, the requirement of banks (such as B-TE) to “Please old "delete a token with a value of 100" may alternatively already include a public token reference element R to be deleted old In this case, TH-TE does not participate in the token T to be deleted. old In this case, the B-TE (external to TH) names R in step 302. old In step 303, the B-TE sends a request to the TH-TM. In this case, the TH-TE may be advantageously not required in the TH, and the architecture of the TH may be less complex.

[0179] In step 311, a destroy request from the TH-TM to the TH-TV is optionally received.

[0180] In step 312, a temporary token element pair R is generated. temp2 、r temp2 .

[0181] In step 313, the temporary token reference element R temp2 Send from TH-TV to TH-TM.

[0182] In step 314, a removal instruction is generated. The removal instruction may be signed with the TH's key and may be, for example:

[0183] SIG_T temp2 =sig(sKey TH ;DESTROY||TR temp2 )

[0184] In step 315, the generated removal instruction is sent via the secure token destruction unit TH-TV. The removal instruction instructs the token reference register TRR to remove the token reference of the registered token from the token reference register TRR.

[0185] In step 317, the temporary token reference element R temp2 Received from TH-TM to TH-TE.

[0186] In step 318, a replacement instruction is generated. This instruction is used to instruct TRR to store an internal, temporary token T temp2 Token reference TR temp2 To replace the token T that needs to be withdrawn old Token reference TR old . An example of a replacement instruction is:

[0187] SWITCH TR old, TR temp2

[0188] Replacement refers to any value-neutral modification of a token, in particular a switch instruction, but also refers to a merge instruction of the token with a token whose token value is v=0, or also refers to splitting the token into one token and one token whose token value is v=0.

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

[0190] In step 321, the replacement instruction of step 318 is sent from TH-TM to TRR.

[0191] In step 322, the token reference TR old Replaced with the token reference TR in TRR temp2 .

[0192] In step 325, a replacement confirmation is optionally received from the TRR into the TH-TM. The replacement confirmation RB may be signed with the TRR's key and be, for example:

[0193] RB=sig(sKey TRR ,TR temp2)

[0194] Then in step 331, a removal instruction is sent from TH-TM to TRR. The removal instruction is, for example:

[0195] DESTROY TR temp2

[0196] Then in step 332, the temporary token TR in TRR is removed temp2 .

[0197] In step 334, a removal confirmation EB is optionally generated.

[0198] In step 335, the removal confirmation EB generated in step 334 is optionally received from the TRR to the TH-TM. The EB may be signed with the TRR's key and may be, for example:

[0199] EB=sig(sKey TRR ;TR temp2 )

[0200] In step 337, a forwarded removal confirmation EB is optionally received at TH-TE.

[0201] In step 338, the old token T is deleted in TH-TE old .

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

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

[0204] exist Figure 3 In one design scheme, step 315 is optional because the instructions of steps 321 and 331 can be transmitted together, and in the case of common transmission, either only the confirmation step 325 is executed, or only the step 335 is executed, or steps 325 and 335 are executed simultaneously.

[0205] In one design, tokens can be destroyed in the following way.

[0206] TH-TM Identification Token T old , the token exists in the payment processor (in a storage area specifically set up for this, or in TH-TE) and should be deleted.

[0207] TH-TM requires TH-TV to output the public key R temp2 , for the token T to be deleted old TH-TV will send the corresponding private key r temp2 stored in its secure memory.

[0208] In TH-TM, a) by creating a registration request RA, execute the old to T temp2 b) sending a registration request RA to TRR; c) obtaining a registration confirmation from TRR to confirm the switching registration.

[0209] TH-TM sends a deletion request (“circuit breaker”) to TH-TV to delete (destroy) token T temp2 , and attach the registration request RA and TRR's registration confirmation RB.

[0210] TH-TV verifies the deletion request, registration request RA and registration confirmation RB of TRR. CMS uses TH-TV's private key pKey TH and the private key r temp2 In the case of token T temp2 Execute the delete command (DESTROY).

[0211] TH-TV outputs a deletion instruction to TH-TM by creating a registration request RA.

[0212] TH-TM sends a request RA to TRR regarding the deletion instruction. From the moment the deletion instruction is registered in TRR, the token T temp2 is deleted (the token no longer exists for TRR).

[0213] The deletion process can be a fully automatic process without human interaction. If an air gap AG is also required here (maybe a system requirement), a stacking process (batch operation) can be performed for all tokens to be deleted, wherein all required public keys are requested from the CMS in advance, for example at the end of a working day (for deletion of a working day). Alternatively, all tokens to be deleted are first combined (merged, MERGE) and only one combined token is deleted at the end.

[0214] Each instruction can be signed in order to be able to check whether the sender of the token reference TR also owns the corresponding token T. The ECDSA scheme can be used as a signature. The instruction is preferably signed with a secret token element of the token T, for example the private part r. For the instructions "generate" and "delete", a further signature of the token issuer unit TH may be required to ensure that these instructions were generated by an authorized unit of the trading system TS.

[0215] exist Figure 4 The following table shows the usage of the existing token T a An embodiment of a flow chart of a method for transferring a token T between TE1 and TE2 by means of a switching instruction. Also shown is a signed registration request RA required for this purpose. sig_Ta And the register confirmation RB with instruction structure.

[0216] There is a token T in TE1 a Token T a Has token value v a and the private part of the token-specific key pair r. The associated token reference TR a Stored in TE1 in the token reference register TRR. Has a token value of v b Token T b Should be transferred between TE1 and TE2.

[0217] To this end, TE1 sends a transfer message to TE2. Or token information (such as token value v b The token information may be a transfer of token T from TE1 to TE2, for example within the scope of a payment transaction. b Then, TE2 generates a new random number r b , which is used as the private part (secret) of the new cryptographic token-specific key pair. By applying a cryptographic one-way function, the public part of the key pair R is generated in TE2 b .

[0218] Then, TE2 converts the public part of the key pair R b Send back to TE1. If TE2 already knows the token value v b (For example, the expected token value within the scope of the payment transaction or the token information provided by TE1 is the token value v b ), TE2 can also send a token reference TR to TE1 b .

[0219] Now, in TE1, token T a Switch to the token T to be transferred b Then create a registration request RA sigTa, and sends a registration request from TE1 to TRR. The registration request RA contains the instruction "SWITCH" or follows Figure 2 a's corresponding instruction code, input token reference TR a and the common part R b Or output token reference TR b . Deposit request RA uses token T a The random number r a Signature. Signed Deposit Request RA sig_Ta From the participant unit TE1 is sent to the token reference register TRR. There the signature is checked. In addition, the token value v a With the token value v b For comparison. If v a =v b And the signature check is successful, then the token reference TR a The token reference register TRR is deleted or marked as deleted, and the token reference TR b Enter the token reference register TRR. From this point in time, the token T b Stored on TE2.

[0220] The success of the deposit is shown to TE1 by TRR as a deposit confirmation RB. The deposit confirmation includes the token reference TR b To ensure the security of the method, the deposit confirmation can be equipped with the signature of the TRR.

[0221] The deposit confirmation RB can be sent by TE1 to TE2 to inform TE2 that the deposit is successful. Then, TE2 can verify the deposit confirmation RB again. Therefore, it has a token value v b and the private part b Token T b Transferred from TE1 to TE2 without transferring the token along with the two token elements from TE1 to TE2.

[0222] Therefore, the resulting common part R b Transferred to TE1. TE1 takes over the registration via the switch command "SWITCH". Confirmation RB is sent back, with the common part R generated if necessary b and token value v b TRR signature Sig(v b ,R b ). The final switch in TE2 is therefore superfluous, and the method is thus less complicated.

[0223] exist Figure 5 The following table shows the method used to convert the token T d With Token T eCombine and deposit the combined token T in TRR f In addition, the required signed registration request RA is shown in a table form from the perspective of the TE layer and the TR layer. sig_Td and RA sig_Te and instruction structure.

[0224] Generate a random number r in TE1 of the TE layer f Then the common part R is generated on this basis f In addition, based on the input token T d and T e , the token value v d With v e Sum to form the token value v f .

[0225] Then generate the output token reference TR f The register request RA contains the instruction "MERGE" or Figure 6 The instruction codes listed in a and the two input tokens refer to TR d and TR e And the output token reference value TR f The deposit request RA uses the token T once. d The random number r d Signature to obtain the first signed deposit request RA sig_Td The deposit request also uses the token T e The random number r e Sign to obtain the signed second deposit request RA sig_Te . Two signed deposit requests RA sig_Td and RA sig_Te are sent by the participant unit TE1 to the token reference register TRR. There, the registration request RA sig_Td and RA sig_Te The signatures of are checked separately. In addition, the token value v is formed d and v e and the token value v f For comparison. If v f =v d +v e And both signature checks are successful, then TR d and TR e Deleted or marked as deleted in the token reference register TRR, and the token reference TR is entered in the token reference register TRR f . Combined Token T f (The token in question has been transferred from TE1 to TE2 in the meantime) can now be checked for validity in the TRR by participant unit TE2.

[0226] exist Figure 6 Another design of a token reference register TRR of a trading system TS is shown in FIG. It is noted that a plurality of memory cells 1 can be reserved in the token reference register TRR to speed up the storage of a large number of token references TR. It is also noted that a plurality of verification units 2 can be reserved in the token reference register TRR to speed up the verification of the deposit request RA. A participant unit B-TE is also shown, which is arranged as a special bank participant unit between the token issuer TH and the participant unit TE1.

[0227] Figure 6 Also shown is an registration request unit RAE which can receive a sequence of registration requests RA from the participant unit TE1.

[0228] Advantageously, each participant unit TE (here a security element, such as a smart card or a TEE) uses only one token T. This means that the TE combines (MERGE) the acquired token T with the token T stored in the token memory. This also means that the TE splits (SPLIT) the token T to be sent from the token T stored in the token memory. These modifications to the token T can be performed without the need for a registration request RA and the token T can be further transmitted immediately after the modification. Therefore, there may be a series of modifications to the token T that are unknown to the TRR. Typically, the sequence of registration requests RA is formed by a combination of SPLIT and MERGE modifications. Each of these modifications also serves as a "proof" (see above Figure 1 ) or a signed deposit request RA sig Stored together with the token T. Therefore, a sequence RA of registration requests is formed in TE F .

[0229] List of Reference Numerals

[0230] TS Trading System

[0231] TH Token Issuer Unit

[0232] TH-TG Token Generation Unit

[0233] TH-TV Token Destruction Unit

[0234] TH-TM Token Issuer Management Unit

[0235] TH-TE Token Issuer Participant Unit

[0236] AG Air Gap

[0237] TE1 Participant Unit User

[0238] B-TE Bank Participant Unit

[0239] TRR Token Reference Register

[0240] T Token

[0241] TR Token Reference

[0242] R, r token element pair

[0243] R Public token reference element of the token element pair

[0244] r The secret token element of the token element pair

[0245] v Token Value

[0246] HB Add Confirmation

[0247] RB Replacement Confirmation

[0248] EB Removal Confirmation

[0249] ikB TH The private part of the token issuer key pair

[0250] 200 Receive token generation request

[0251] 201 Receive request for new token reference element

[0252] 202 Generate new token element pair

[0253] 203 Send public token reference element

[0254] 211 Receive token generation request

[0255] 212 Generate a temporary token element pair

[0256] 214 Generate add command

[0257] 215 Send add command

[0258] 218 Generate replacement instructions

[0259] 219 Send replace command

[0260] 221 Send add command to TRR

[0261] 222 Add temporary token reference

[0262] 224 Generate add confirmation

[0263] 225 Receive add confirmation from TRR

[0264] 231 Send replacement command to TRR

[0265] 232 Replacement Token Reference

[0266] 234 Generate replacement confirmation

[0267] 235 Receive replacement confirmation from TRR

[0268] 237 Receive Replacement Confirmation

[0269] 238 Store / Activate New Token

[0270] 239 Send confirmation for new tokens to be issued

[0271] 240 Storage generation completed

[0272] 250 New token issuance

[0273] 300 Receive token destruction request

[0274] 301 Receive request for old token reference element

[0275] 302 Deactivate old token

[0276] 303 Send old token reference element

[0277] 311 Received destruction request

[0278] 312 Generate a temporary token element pair

[0279] 313 Send temporary token reference element

[0280] 314 Generate removal instruction

[0281] 315 Send the generated command

[0282] 317 Receive temporary token reference element

[0283] 318 Generate replacement instructions

[0284] 319 Send the generated command

[0285] 321 Send replacement command to TRR

[0286] 322 Replacement Token Reference

[0287] 325 Receive replacement confirmation from TRR

[0288] 331 Send removal command

[0289] 332 Remove temporary token reference

[0290] 334 Generate removal confirmation

[0291] 335 Receive removal confirmation from TRR

[0292] 337 Received the transmitted removal confirmation

[0293] 338 Delete old tokens

[0294] 339 Receive deletion confirmation

[0295] 340 Storage destruction completed

Claims

1. A method for securely generating issuable tokens by a token issuer of an electronic transaction system (TS) having a token reference register (TRR), wherein: In the Token Issuer Unit (TH) comprising a secure Token Generation Unit (TH-TG), the following steps are performed: - generating (212) a token-specific token element pair in a secure token generation unit (TH-TG), the token element pair comprising a secret token element and a public token reference element; - generating (214) an add instruction in a secure token generation unit (TH-TG), the add instruction instructing a token reference register (TRR) to add a token reference (TR) comprising the generated public token reference element in the token reference register (TRR) as an additional token reference (TR); - sending (221) said add instruction to a token reference register (TRR); It is characterized in that The generated token element pair is an internal, temporary token element pair (r temp , R temp ), The token generation unit (TH-TG) receives (211) a token reference (TR new ),and The token generation unit (TH-TG) generates (218) a replacement instruction, wherein the replacement instruction instructs the token reference register (TRR) to store the token (T new ) token reference (TR new ) to replace the temporary token element pair token reference (TR temp ).

2. The method according to claim 1, wherein: The token issuer unit (TH) comprises a secure token storage unit (TH-TE), wherein the secure token storage unit (TH-TE) generates (202) token-specific token element pairs of issuable tokens.

3. The method according to claim 1 or 2, wherein: The secret token element of the internal, temporary token element pair (r temp ) exists only in the Token Generation Unit (TH-TG); and / or the secret token element of the token that can be issued (r new ) only exists in the token generation unit (TH-TE).

4. The method according to claim 1, wherein: In a common sending step, the add instruction and the replace instruction are sent together (221, 231) to the token reference register (TRR).

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

6. The method according to claim 1, wherein: The token issuer 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 according to claim 6, wherein: The token generation request already includes the public token reference element (R new ).

8. A method for securely destroying tokens by a token issuer of an electronic transaction system (TS) having a token reference register (TRR), wherein: In the Token Issuer Unit (TH) including the Secure Token Destruction Unit (TH-TV), the following steps are performed: - generating (314) a removal instruction in the token destruction unit (TH-TV), the removal instruction instructing the token reference register (TRR) to remove the token reference of the registered token from the token reference register (TRR); - sending (321) a remove instruction to the Token Reference Register (TRR); It is characterized in that - Before generating (314) the removal instruction, the token destruction unit (TH-TV) generates (312) an internal, temporary token (T temp2 ) and generates a token reference (TR) for the internal, temporary token temp2 ) removal instructions; and - generating (318) a replacement instruction, the replacement instruction instructing the token reference register (TRR) to store an internal, temporary token (T temp2 ) token reference (TR temp2 ) to replace the tokens that need to be withdrawn (T old ) token reference (TR old ).

9. The method according to claim 8, wherein: The token issuer unit (TH) includes a secure token storage unit (TH-TE), wherein the secure token storage unit (TH-TE) stores the tokens to be withdrawn (T old ) is disabled.

10. The method according to claim 8 or 9, wherein: Internal, temporary token (T temp2 )'s secret token element (r temp2 ) only exists in the token destruction unit (TH-TV).

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

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

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

14. A token issuer unit (TH), comprising: -Interface with the Token Reference Register (TRR); and - a secure token generation unit (TH-TG) for securely generating issuable tokens by means of a method according to any of the preceding claims 1 to 7; and / or - A secure token destruction unit (TH-TV) for securely destroying tokens by means of a method according to one of the preceding claims 8 to 13.

15. The token issuer unit (TH) according to claim 14, further comprising: - a Token Issuer Participant Element (TH-TE), arranged to store tokens and / or token references; and - An interface with a bank participant unit (B-TE) or with a central bank unit, arranged to receive (200) a token generation request and / or to receive (300) a token destruction request.

16. The token issuer unit (TH) according to claim 14 or 15, comprising - a token management unit (TH-TM) having an interface with a bank participant unit (B-TE) or with a central bank unit or a token issuer participant unit (TH-TE), configured to: - Output (250) tokens that can be issued (T new ); and / or -Storage Token (T old )’s secure destruction and / or -Storage of issued tokens (T new ) is completed with secure generation.

17. The token issuer unit (TH) according to any one of claims 14 to 16 further comprises 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