WO2024027869A1

WO2024027869A1 - Secure element, method for registering tokens, and token reference register

Info

Publication number: WO2024027869A1
Application number: PCT/DE2023/100487
Authority: WO
Inventors: Klaus ALFERT; Lars HUPEL; Matthias Fasching; Peter Zeller
Original assignee: Giesecke+Devrient Advance52 Gmbh
Priority date: 2022-08-01
Filing date: 2023-06-28
Publication date: 2024-02-08
Also published as: DE102022002780A1

Abstract

The invention relates to a secure element as a transaction unit of a transaction system having a token reference register, to a procedure in the token reference register, and to the token reference register. The secure element comprises a token store for tokens of the transaction system and is designed as a transaction unit for exchanging tokens of the transaction system directly with another transaction unit of the transaction system. Each token (T) of the transaction system (TS) is unambiguously assigned a token reference (TR) which can be registered in a token reference register (TRR) of the transaction system (TS). The secure element is designed in order, starting from at least one input token, to produce at least one output token and an output token reference (TRA) thereof. The secure element provides a modification detail, with an input token reference (TRE), a command (KO) and an output token reference (TRA), for the token reference register (TRR). In the present case, the secure element provides the at least one modification detail (MA) as a validity enquiry (GA). It is also designed to receive a validity confirmation (GB) for at least one output token reference, to be checked for validity, of the validity enquiry (GA).

Description

SECURE ELEMENT, METHOD FOR REGISTERING TOKENS AND TOKEN REFERENCE REGISTER

The invention relates to a method for registering tokens, in particular a secure element as a transaction unit, to a secure element and to a token reference register in which token references are stored that are clearly assigned to a token, as well as to the transaction system as a whole.

With the help of secure elements, such as chip cards, SIM modules, etc., as transaction units, it is known that a secure direct transfer between the transaction units can be achieved, whereby deliberate multiple spending of tokens, also known as double spending, is already ruled out.

For example, from DE 102009 038 645 A1 and DE 102009 034 436 A1, systems or portable data carriers are known as secure elements for transferring monetary amounts in the form of electronic data sets, in which payment with duplicates of the data set is prevented and a high degree of security against manipulation is provided is. Complex structures and complex encryption and signing processes are required for the transactions.

The security of transactions and the associated transaction data includes protecting the confidentiality of the data exchanged; as well as protecting the integrity of the data exchanged; as well as protecting the availability of the exchanged data.

As solutions for secure transaction systems, a distinction is often made between token-based systems and account-based systems. In addition to conventional account-based systems, such as credit or credit accounts, more novel account-based systems based on blockchain topologies have recently been discussed. The account-managing unit has access to the data record that represents the monetary amount. Although the newer account-based systems provide a high level of integrity protection, they also publish a lot of information, for example when records exist in a freely readable data structure and change hands there.

It is also already known to expand a token-based transaction system to include a token register. The secure element sends a registration request for its token to the register. The registry verifies the registration request and, for example, only stores a token reference for the token, so it does not know the token itself.

WO 2020/212337 Al describes a transaction system in which even modifications of tokens - for example by splitting the token, are possible offline, i.e. directly between the secure elements of the transaction system and without any further control instance. After receipt in a secure element or a participant unit, the tokens can be transferred immediately without having to register a modification in a token register of the transaction system. The registration of the modification in the token register can take place independently of the actual transaction, the transfer of the token. However, the secure elements are known to be resource-limited, particularly limited in terms of storage space, processing speed, transmission time and/or speed.

The invention is based on the object of providing a new method that is more suitable for a secure element as a transaction unit, and is therefore particularly resource-saving. The processes in the transaction system, such as the direct transfer of tokens between the transaction units and the registration of tokens in the register, as well as the associated advantages and possible uses should preferably be retained. In particular, several modification details of a transaction unit should be processed in a resource-saving manner.

The task is solved by the features described in the independent patent claims. Further advantageous refinements are described in the respective dependent patent claims.

A secure element of an electronic transaction system has a token storage for tokens of the transaction system and is set up to exchange tokens directly with another transaction unit of the transaction system. A token reference is uniquely assigned to each token in the transaction system. Token references (and thus the assigned tokens) can be registered in a token reference register of the transaction system. The secure element is further set up to generate at least one output token and its output token reference based on at least one input token. The secure element provides at least one modification indication for the token reference register, which includes at least one input token reference, a command and at least one output token reference. Now the secure element provides the at least one modification information as a validity request and receives a confirmation of validity for at least one output token reference of the validity request to be checked for validity.

Sending the modification information in a validity request enables, as explained in more detail below, a variety of initially seemingly small advances, which can ultimately be helpful for the secure element and even for the token reference register. Since the token reference register can process the validity request with (only optional) modification information faster on average than a conventional registration request, the connection or transmission time is reduced and thus the effort in the secure element to manage the connection, in particular to maintain it (timeouts. . .) or restore.

The validity request can preferably include the at least one output token reference to be checked and at least one output token reference not to be checked. This means that not all output token references need to be checked for validity.

The validity request can include the modification information and additionally a verification information that specifies the at least one (or more) output token reference(s) to be checked. The test information can, for example, contain the output token reference(s), contain one (or the) reference(s) to the output token references or also encoded by one (or more) set flag(s) for the output token reference(s). be. Flags are typically bits that are either set or unset. For example, for each output token reference of the validity request or the modification statement, a flag would be provided that could either be set or not set. Particularly preferably, the checking information relates to output token references of at least two different modification details of the validity request.

In particular for the benefit of the token reference register, the secure element could be set up to provide modification information either as a validity request or as a registration request. For example, the secure element could use the following as a selection criterion for sending as a validity request:

- a number of modification details stored in the secure element, in particular if there are more than two modification details, and/or

- use a time criterion, in particular with the help of a timestamp, for example a transaction and/or modification or the last communication with the token reference register, and/or - an origin criterion, for example if the modification information was received, in particular from another transaction unit.

However, such selection by the secure element is not really necessary. As will become clear below, the secure element can always send one (or more) modification information as a validity request.

In principle, it is conceivable to cryptographically secure the data exchange with the token reference register, including the validity request and confirmation, i.e. to encrypt and/or sign it. In particular, a confirmation of validity that has been manipulated by third parties would be recognized in this way.

It is particularly advantageous (and sufficient for securing a validity request) if the confirmation of validity includes a separate cryptographic confirmation, such as a checksum or signature, for each output token reference to be checked. It can also be advantageous if the confirmation of validity includes a common cryptographic confirmation, such as a checksum or signature, for all output token references to be checked (or only for these). The cryptographic confirmation(s) for the output token reference(s) to be checked are preferably stored in the secure element and/or transmitted to another transaction unit together with the associated token(s).

The validity request can include several modification details, in particular a stack and/or at least one sequence of modification details. Modification statements that are independent of one another (in their token references) are referred to here as a stack. The modification information of a batch can be processed in the token reference register in any order. Modification statements that depend on one another (in their token references), on the other hand, are referred to as a sequence (or sequence). At least one output token reference of one modification information is also the input token reference of another modification information. The sequence preferably comprises several output token references, which are also the input token reference of a subsequent modification statement in the sequence. The modification information of a sequence cannot be processed in any order in the token reference register. The token reference register will execute the modification information of the sequence(s) in particular in the order in which they are present in the validity request or which is specified in the validity request. In particular, the sequence can be constructed with or without branches, just for example “MAI => MA2 => ... => MAn” or “(MAI, MA2) => MA3 ... (MA4, MA5) => MA6 .. .”. The modification statement(s) of the validity request is (are) only to be carried out optionally. The token reference register can send a confirmation of validity even in the event of one (or more) incorrect modification details. Whether the token reference register checks and, if necessary, executes the modification information and/or which of the modification information has been checked and executed is independent of the confirmation of validity for the at least one (or more) output token reference(s) to be checked. .

The validity request can be a request for a token reference register that stores only the valid token references in a storage unit for token references to check whether the output token reference (s) to be checked is (are) already stored in the storage unit.

The secure element regularly comprises a processor, in particular for carrying out the steps as a transaction unit, and/or an interface, in particular to a local terminal, via which the validity request for the token reference register (TRR) is provided. A transaction unit can be a participant unit or is sometimes referred to as such below.

The or each token will comprise, as data elements, in particular a token value and a secret token element, which is in particular a secret key of a key pair. Token references can include, as data elements, a token value, in particular the token value of the token, and a public token element, in particular the public key of the token's key pair.

A modification is in particular a splitting and/connecting or switching of tokens. The command for the modification specification is, for example, “split”, “connect” or “switch”. One (or more) input tokens with one (total) token value can be split into several output tokens with a different token value (but the same total value). Two or more input tokens with a total value can be combined to form an output token with the total value. An input token with a token value can be switched to an output token with the same token value.

The transaction unit, for example the security element, can generate one (or more) output tokens, in particular including the token value and secret token element, as well as the assigned output token reference for the modification information. The transaction unit, for example the security element, stores your tokens and optionally one or more modification details. The modification information is stored together with or at least linked to the initial token.

The security element can preferably delete the modification information(s) stored in the security element and contained in the validity request in response to receipt of the validity confirmation.

Tokens can be directly exchanged with other transaction units. For tokens that have not yet been registered, the token must be transferred together with the modification information(s). Tokens that have already been registered can be transferred without the modification information.

The present invention provides a method for checking the validity of a token of a secure electronic transaction system. A token reference is uniquely assigned to each token in the transaction system. A token reference register of the transaction system includes a verification unit and a storage unit in which the token references of valid tokens are stored. The following steps are carried out in the token reference register:

- Receiving a validity request that includes a modification statement with at least one input token reference, at least one output token reference and a command;

- Checking at least one output token reference of the validity request to be checked for validity to see whether it is stored in the storage unit; and

- Sending a confirmation of validity for the at least one output token reference to be checked.

The validity request includes a check information that specifies the at least one output token reference to be checked and/or the modification information that is only optionally to be processed.

The checking (and optionally the receiving and sending) is preferably carried out by the verification unit of the token reference register. Receiving and sending can be done through an interface unit of the token reference register.

The verification unit preferably processes modification information, i.e. optionally also the modification information(s) of the validity request, with one or more of the sub-steps:

- Check whether the at least one input token reference is stored in the storage unit; and or - Verifying the modification information, in particular one (or more) signature(s) in the modification request and/or a value neutrality of the modification information and/or a syntax of the modification information; and or

- Execute the command (or the modification information) by storing an output token reference in the storage unit and in particular by deleting an input token reference in the storage unit.

In advantageous embodiments, the confirmation of validity is sent - in particular without further processing of the modification information - if the output token reference(s) to be checked of the validity request are already stored in the storage unit. Otherwise, the modification information(s) will be processed. The confirmation of validity can be sent alternatively or additionally after the processing of the (one or more) modification details that can only be processed optionally has been omitted completely or in partial steps, i.e. none of the partial steps have been carried out or not all partial steps have been carried out.

The validity request preferably includes at least one, more preferably several, output token reference(s) that cannot be checked for validity. Validation confirmation (GB) may include a separate cryptographic confirmation, such as signature or checksum, for each output token reference to be verified.

The output token reference to be checked for validity does not have to be explicitly displayed in the check details of the validity request. It can be one of the initial token references included in the modification statement. However, the token reference(s) to be checked is/are preferably received from the token reference register in the checking information, as an independent data element of the validity request. The check information can be formed by one (or more) reference(s) to the output token reference(s) to be checked (for example position or number of the output token reference in the validity request) or contain the output token reference(s).

The validity request may include multiple modification statements, each modification statement including one or more input token references, one or more output token references and a command. The modification information is preferably a stack of modification information and/or a sequence of modification information. Stacks consist of independent modification statements. Sequences consist of at least partially interdependent modification information. The token to be checked can be transferred directly between two transaction units of the transaction system in the direct transaction layer of the transaction system (but does not have to have been transferred yet). The token to be checked has preferably been modified in a transaction unit without the token being registered in the transaction system.

The confirmation of validity is preferably also sent if some of the several modification details cannot be carried out (the assignment of the token references to tokens of the transaction system is therefore partially not possible), in particular if these modification(s) are only made in the direct transaction layer without registering the modification(s). in the token reference register. It is therefore not a prerequisite for the validity check that all modification information in a validity query can be traced or carried out by the verification unit. Only the assignment of at least one token reference to be checked must be verifiable. Verification thus takes place independently of registration of one or more modifications from the modification information in the token reference register.

The verification unit of the token reference register can send memory queries and/or memory instructions to the storage unit of the token reference register. For example, it can query whether a token reference is stored in the storage unit and/or instruct a token reference to be saved or deleted. Preferably, the verification unit sends to the storage unit a common memory query for output token references of different modification information and/or for output token references and input token references of at least one modification information.

In particular, for a batch of modification information in the validity request, the token reference register can send a partial validity confirmation. The partial validity confirmation preferably concerns the valid output token references of the output token references of the stack to be checked for validity.

For a sequence of modification information in the validity request, the verification unit can only temporarily store at least one (or) output token reference(s) of at least one modification information internally (i.e. not store it in the storage unit). The buffered output token reference(s) is discarded if it is the input token reference of a further modification information or otherwise stored in the storage unit. At least one (or more) output token reference(s) of a modification statement is only stored in the storage unit after checking one, several or all further modification statements of the sequence. The token reference register can carry out the method with a transaction unit or the secure element already described.

The token reference register can further include further verification units and/or an archive unit which stores no longer valid token references and/or validity requests and/or registration requests that have already been carried out.

A token reference register for a transaction system is set up to carry out one of the aforementioned methods, in particular with a transaction unit TE of the transaction system or with one of the aforementioned secure elements.

The token reference register includes the storage unit for storing the valid token references in the transaction system; an interface set up to receive a validity request and the at least one verification unit.

A transaction system includes a register layer with the token reference register; and a direct transaction layer with a variety of transaction units, including a secure element.

The validity requests in the transaction system can be distributed to different verification units of a token reference register and these can therefore be processed in parallel by different verification units of the token reference register. This means that a large number of validity requests can be divided internally in the token reference register between different verification units (“load balancing”).

The confirmation of validity and/or the valid output token reference(s) to be checked is preferably signed with a private part of a key pair of the token reference register, preferably the verification unit (possibly one of a plurality of verification units). This signature is verified by the transaction entity upon receipt of the confirmation of validity with the public part of the key pair of the token reference register. This increases security because validity confirmations generated by unauthorized third parties - for example as part of man-in-the-middle attacks - are recognized by a transaction unit due to a missing or invalid signature. Such confirmations of validity can then be ignored by the transaction entity.

A token is a data record of a transaction system that can be directly exchanged between transaction units. With knowledge of the token, the receiving transaction entity is in possession of the token value that the token represents. When you swap, the token changes therefore automatically the owner. A token - a record that is transferable independently of a transaction topology, such as blockchain topologies - can be transferred directly between transaction entities without any intervening entities.

In one embodiment, the token is an electronic coin data record or payment token for exchanging monetary amounts between transaction units. Such a payment token is also colloquially referred to as a “digital coin” or “electronic coin” and represents cash in electronic form.

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

A first token element of each token of the transaction system is a token value, for example an asset, an asset, an asset and/or a monetary amount.

A second token element of each token of the transaction system is a private part of a token-specific key pair. This private part is a secret in the transaction system and is not published and may not be used multiple times. The generation of the private part must not be predictable. This private part can be a random number. The random number is preferably the result of a true random generator.

The token is formed from the token value (first token element) and the private part. This formation is preferably the chaining (concatenation) of these two token elements. Any other type of linking of these two token elements is not excluded according to the invention and includes, for example, appending one after the other, inserting them into a TLV data structure and/or logical linking.

Anyone who holds a token or has full access to the token with its token elements can exchange that token with another transaction entity. Owning the token with its at least two token elements (token value and private part of the token-specific key pair) is therefore equivalent to owning the value that the token represents.

Each token in the transaction system is assigned a token reference. This assignment is one-to-one, which means that exactly one token reference is assigned to a token and exactly one token is assigned to each token reference. The token reference is a public data record that is stored in a storage unit of the token reference register of the transaction system in a verifiable manner for each transaction unit. Both the token and the token reference are unique. Due to the unique assignment, there is a 1-to-1 relationship between the token and the token reference.

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

A first token reference element at each token reference is the token value of the token uniquely assigned to the token reference. The token value of the token is therefore identical to the token value of the assigned token reference. For example, the token value of the token reference is a copy of the token value of the associated token.

A second token element of each token reference of the transaction system is a public 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.

This cryptographic function is a one-way function. This cryptographic function is therefore a mathematical function that is “easy” to calculate in terms of complexity theory, but “difficult” to practically impossible to reverse. The term one-way function also refers to a function for which there is currently no known reversal that can be practically carried out in a reasonable amount of time and with reasonable effort. Preferably, a one-way function is used that operates on a group in which the discrete logarithm problem is difficult to solve, such as B. a cryptographic process analogous to elliptic curve encryption, ECC for short, from a private key of a corresponding cryptography process. The reverse function, i.e. the creation of a token (or part of the electronic coin data set) from a token reference, is very time-consuming.

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

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. The token reference is formed from the token value (first token reference element) and the public part. This formation is preferably the concatenation of these two token reference elements. Any other type of linking of these two token reference elements is not excluded according to the invention and includes, for example, adding them one after the other, introducing them into a TLV data structure and/or logically linking them.

A token reference can preferably be generated by an electronic wallet of a transaction unit. To do this, the transaction unit must have knowledge of the token and its token elements. Generating the token reference can be done by an electronic wallet of a transaction entity that wants to send the token. Alternatively, the token reference can be generated by an electronic wallet of a transaction entity that has received the token.

The use of a token reference is not comparable to the use of addresses of transaction units in a blockchain-based transaction system, since no addresses of the transaction units are used in the token reference register according to the invention in order to prevent the tokens from being traceable.

The token reference register is a unit of the transaction register that stores the token references, thereby registering the tokens as valid tokens. This register can be a central database or storage unit. This register can be a decentralized ledger. The token reference register can separately maintain a history of the token references and/or the registration requests and/or the validity requests in an archive unit.

A token reference is only stored once in the token reference register. Since a token reference of a token only exists once in the transaction system, the verify step can determine whether attempts have been made to issue a token multiple times.

The token is stored in a token store that the transaction unit can access exclusively. This token memory can have a large number of tokens, for example the large number of tokens can be stored in a data memory of the transaction unit. For example, the data storage can be internal, external or virtual. In one embodiment, “connecting” can take place automatically when a token is received, so that preferably only one (or a certain number of) tokens are stored in the transaction unit. The transaction unit can be, for example, a mobile device, such as a smartphone, a tablet computer, a computer, a server or a machine. The transaction unit can be a smart card that is inserted into a terminal device ready for operation. The transaction unit is preferably a secure element.

The data storage is, for example, a wallet storage of an electronic wallet. The electronic wallet is, for example, a software application that is stored executable on a transaction unit. The electronic wallet (wallet) can enable the transaction entity to participate in the transaction system. The electronic wallet can generate a validity request to check the validity of a token. In addition, the electronic wallet can make modifications (switching, connecting, splitting) to a token and generate any necessary validity requests and send them to the token reference register. In addition, the electronic wallet can transfer tokens to another wallet (in a different transaction unit).

A transaction in the transaction system is preferably atomic.

According to the invention, a token reference register is provided for a transaction system which is set up to carry out the method steps according to the method described above.

The token reference register can be set up to receive a plurality of validity requests, which are verified in parallel in a plurality of verification units as to whether the at least one token reference contained in the validity request received in each case is valid.

According to the invention, a transaction system is provided which has a register layer with a token reference register of the previous type for registering token references and checking tokens using token references and a direct transaction layer with a large number of transaction units, set up for the direct exchange of tokens with one another.

According to the invention, a two-layer transaction system consisting of a direct transaction layer for directly exchanging tokens and a register layer is provided. No transactions are logged in the register layer Only token references are saved and modifications to tokens are saved via appropriately adapted token references for the purpose of verifying the validity of tokens. This ensures the anonymity of the participants in the transaction system.

The storage unit of the token reference register preferably only stores token references of tokens valid in the transaction system. As soon as a token is modified and a corresponding (modified) token reference is to be registered, the (old) token references become invalid and (only) the modified token references are stored in the storage unit.

In one embodiment, old (i.e. invalid) token references are deleted from the storage unit and archived in a (token reference) archive. The token reference archive can be part of the archiving unit, but it can also be provided as a separate unit in the token reference register or in the transaction system. The token reference archive can also be completely replaced by the archiving unit if all registration requests are completely stored there. The time-dependent deletion of registration requests can also apply to the deletion of old token references.

According to the invention, a transaction unit, preferably a secure element, in a secure electronic transaction system with: an interface that is set up to: transfer tokens to another transaction unit; Creating and sending, to a token reference register, a validity request for checking a token according to one of the preceding embodiments; an access means for a token memory or token memory, wherein at least one token of the transaction unit with modification information is stored in the token memory; and a computing unit configured to: apply a one-way cryptographic function to a private part of a token-specific key pair of a token of the token storage to obtain a token reference; and modifying tokens.

In addition, the transaction unit has access means to a token memory and/or the transaction unit has a token memory, with at least one token of the transaction unit containing the sequence of registration requests being stored in the token memory.

In addition, the transaction unit has a computing unit that is set up to apply a cryptographic one-way function to a private part of a token-specific key pair of a token of the token storage to obtain a token reference; and for modifying tokens. Modifying tokens includes, in particular, splitting Tokens, connecting tokens and/or switching tokens in the manner described above.

The transaction unit can be set up in such a way that only one token is stored in its token memory. This token is split (SPLIT) for direct transactions to produce a correct token value according to the transaction to be made. If tokens are received in the transaction unit, the received token is immediately combined with the token in the token store (MERGE).

To transfer a token to another transaction unit, this token of the token storage can be split (SPLIT), with a registration request being generated for this purpose. The registration request preferably has a token reference of the token to be divided and a token reference of the divided tokens.

When a token is received from another transaction entity, the received token is linked to the token in the token store, thereby generating a registration request. The registration request preferably has a token reference of the connected token and a respective token reference of the tokens to be connected.

In the present case, a transaction unit can be a secure element that has secured access to tokens in a token store. The secure element is, for example, installed in a terminal device ready for operation. The secure element and/or the terminal device have a special computer program product (electronic purse, wallet), in particular in the form of a secured runtime environment within an operating system of a terminal device, English Trusted Execution Environments, TEE, stored on a data storage device, for example a mobile terminal device, a machine, preferably ATM. Alternatively, the secure element is designed, for example, as special hardware, in particular in the form of a secured hardware platform module, Trusted Platform Module, TPM, or as an embedded security module, eUICC, eSIM. The secure element provides a trusted environment.

The communication between two transaction units for exchanging tokens can take place wirelessly or by wire, or, for example, optically, preferably via QR code or barcode, and can be designed as a secure channel. The exchange of tokens is, for example, additionally secured for transport by cryptographic keys, for example a session key negotiated for a token exchange or based on a key pair specific to the transaction unit. The invention and further embodiments and advantages of the invention are explained in more detail below using figures, with the figures only describing exemplary embodiments of the invention. The same components in the figures are given the same reference numbers. The figures are not to be viewed as true to scale; individual elements of the figures may be shown in an exaggeratedly large or oversimplified manner.

1 shows an exemplary embodiment of a transaction system according to the prior art;

Fig. 2a shows a registration request according to the prior art;

Fig. 2b shows a registration procedure for a registration request according to Fig. 2a according to the prior art;

Fig. 3a shows a first exemplary embodiment of a validity query according to the invention;

3b shows a first exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 3a according to the invention;

3c shows a second exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 3a according to the invention;

Fig. 4a shows a second embodiment of a validity query according to the invention;

4b shows a first exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 4a according to the invention;

4c shows a second exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 4a according to the invention;

Fig. 5a shows a third embodiment of a validity query according to the invention; 5b shows a first exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 5a according to the invention;

5c shows a second exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 5a according to the invention;

Fig. 6 shows a further exemplary embodiment of a transaction system with a token reference register according to the invention;

Fig. 1 shows an exemplary embodiment of a transaction system TS according to the prior art. The transaction system TS includes a register layer TRR layer in which a token reference register TRR is arranged. The TS also includes a direct transaction layer TE layer, in which a large number of transaction units (or subscriber units) TE can be provided; two transaction units TE1, TE2 are shown as representatives. The transaction units TE1, TE2 are preferably secure elements.

The transaction units TE of the transaction system TS are set up to exchange tokens T directly with one another. In the case of Fig. 1, the tokens are payment tokens, also referred to as digital coins. Each token T is generated by a token issuer TH (not shown in Fig. 1). Each token T can be modified, i.e. divided, connected or switched, by each transaction unit TE and can be generated and also deleted by the token issuer TH. A token issuer TH is, for example, a central bank.

A token T is uniquely represented in the transaction system TS by a token value v and a random number r as token elements. The token value v can be specified in a range of values from 1 to 2 ³¹ -1. The random number r can be a number in the range from 0 to 2 ²⁵⁶ -1, i.e. the order of an elliptic curve, for example secp256rl.

The random number r is a private part of a token-specific key pair. The random number r is unique and secret in the transaction system TS and may not be published or reused. The generation of the random number r must not be predictable.

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

For example, the random number r is a 32-byte token element of type integer. One Transaction unit TE has exclusive access to this token storage or includes this token storage in a data storage of the transaction unit TE.

For each token T, a token reference TR can be stored in the token reference register TRR. The token reference TR includes the token value v of the assigned token T and a public part R of the token-specific key pair. The token value v of a token T is therefore known in the token reference register TRR.

The public part R of the token-specific key pair is generated by applying a cryptographic function to the private part r of the token-specific key pair. This function is difficult to reverse and thus gives the TS transaction system the necessary security. R = r * G, where G can be, for example, a global parameter of the transaction system TS, for example a generator point of an elliptic curve, here the secp256rl curve.

The token reference TR is then formed by the token value v of the token and the public part R of the key pair. The token reference TR is therefore the concatenation of token value v and public part R.

A token reference TR can be sent to the token reference register TRR together with a modification information (see overview in Figures 6a and 6b) as a registration request RA regarding the token T. The modified token T is registered with its token reference in the token reference register TRR. In Fig. 1, the transaction unit TE1 generates a new token TA, the token reference TRA of which is to be stored in the token reference register TRR instead of the token reference TRß of the old token TE with the same token value v. The registration request can be sent by the transaction unit TE1 and/or - after transmission of the token TA together with its modification information to the transaction unit TE2 - by the transaction unit TE2.

A known token reference register TRR is initially shown in FIG.

The token reference register TRR manages in particular the storage location for the token references TR, which can optionally also store the previous registration requests RA, shown here as database 1 as an example of a storage unit in the token reference register TRR. The token reference TR for the token T of the transaction unit TE1 is entered in the database 1 as a representative. This database 1 can consist of a combination of many databases (see also FIG. 6) that are networked with each other. In addition, the token reference register TRR includes at least one verification unit 2. The verification unit 2 of the token reference register TRR verifies registration requests RA. Syntactic correctness or the correct specification of a command in the registration request RA can be verified. The history from old (past) registration requests RA can also be checked. The separation of this verification unit 2 from the database 1 distributes the storage and checking tasks and increases the speed in the token reference register TRR.

1 also already indicates that the token reference register TRR receives registration requests RA from transaction units TE 11 and, if necessary, sends a registration confirmation RB to the transaction unit 18.

An example of a registration request RA according to the prior art is shown in FIG. 2a. The registration request of FIG. 2a includes two input token references TRE, an output token reference TRA and a modification command KO.

In addition, the registration request RA can be signed with the private part r of the token-specific key pair (not shown). Signing makes it possible to verify whether the sender of the token reference TRE was in possession of the input token TE, which further increases security in the transaction system TS.

2b shows a process sequence for registering a token according to the prior art. In step 11, the RA is received in the TRR. In step 12 it is checked whether an input token reference TREH of the RA is stored in the TRR. If step 12 is no, it is checked in step 16 whether the registration request RA has already been executed and is stored in the storage unit 1 as part of the history of the registration requests. In the YES case, the registration is confirmed (again) 18. In the No case of step 16, the RA is not confirmed according to step 19 (error message).

If step 12 is yes, step 13 is executed. In step 13 it is checked whether an input token reference TREU from RA is stored in the TRR.

If step 13 is yes, step 14 is executed. In step 14 it is checked whether the command with the input token references TREU and TREU leads TO the output token reference TRAII of the RA, for example VEU + VEU = VAII and the signatures are valid. In step 14, the command is checked for errors. In the no case of step 13 or in the yes case of step 14, the RA is not confirmed according to step 19 (error message). In the No case of step 14, the TRAII of RA and the RA are stored in the TRR in step 15. The transaction unit is confirmed that registration has taken place in step 18.

The token reference register TRR is preferably not readable for the transaction units TE1, TE2. It is of little practical relevance but theoretically known that a transaction unit can query the status of a token, i.e. can query the status with which a token reference TR is stored in the token reference register TRR. However, such a status query is not a validity query in the present sense, as it will now be described in more detail.

A transaction unit TE1, TE2 can send one or more existing modification information MA, each of which links one (or more) output tokens to one (or more) input tokens via a command, to the token reference register as a validity request. The reduction in the burden on limited resources that can be achieved is particularly helpful for security elements as a transaction unit. Especially in security elements, there can be several modification details for different tokens (stack of modification details) and/or for one token (sequence of modification details).

The transaction unit TE1, TE2 sends the modification information(s) in a validity request for at least one token reference and receives a confirmation of validity from the token reference register TRR for the at least one requested token reference. The validation request includes multiple output token references. The token reference register TRR can provide a signature for each requested token reference in the validation confirmation.

The token reference register TRR shown in FIG. 1 is now also set up to verify validity requests GA. For this purpose, for example, the verification unit 2 of the TRR is provided. The verification unit 2 of the token reference register TRR then verifies registration requests RA and/or validity requests GA.

A history of old (past) validity requests GA regarding a token T can also be verified. However, the history is not required for processing GA validity requests. The storage unit 1 of the TRR can therefore advantageously only contain the valid token references TR. A history of previously valid token references TR and/or modification information that has already been carried out can be stored in a separate unit, a Archive unit. In the following, it will be briefly stated in short that it is checked whether a token reference is stored in the TRR, but it is checked in each case whether the token reference is stored as a valid token reference or, assuming that the storage unit 1 only contains the valid token references, whether it is stored in the storage unit 1.

Fig. 3a shows a first exemplary embodiment of a validity request GA according to the invention. The GA of FIG. 3a includes a (single) modification information MA. This MA includes input token references TREH, TREU and output token references TRAII TRAU and a modification command KO. The number of output token references TRA and the number of input token references TR^ in the modification request MA is not restrictive, it can be more (indicated by the dots) or even fewer. Examples of the number of input and output token references TR per specific modification command KO will be given later.

The modification information MA can optionally include one or more signatures 32. In addition to the detailed data 31 of the modification, the modification information MA includes a signature of the modification information. A signature 32 is preferably created with the private part r of an input token reference; in particular, a signature 32 with the associated private part TEU, TEI2 can be present for each input token reference TREU, TREU of the modification request MA.

The validity query GA can optionally include a check information 33. The check specification specifies the one or more output token reference(s) to be checked for validity. In the example shown, the validity of the output token reference TRAU ZU must be checked. For a validity request GA without explicit verification information 33, for example, all output token references can be checked for validity. The MA of the GA includes at least one output token reference TRAU to be checked for validity and preferably one (or more) output token reference(s) TRAU not to be checked for validity.

3b shows a first exemplary embodiment of a method for checking the validity of a token T based on a validity request GA, for example according to FIG. 3a, according to the invention. In step 101, the TRR receives the GA and optionally checks the MA of the GA in further steps 103-105. In step 102, the TRR checks whether the MA's TRAU is stored as a valid token reference in the TRR (in particular in its storage unit 1). TRAu is the output token reference contained in GA audit statement 33. If step 102 is yes, a validity confirmation GB is sent to the TE in step 108 in response to the GA. The MA of the GA, however, will not be examined further. There is already an output token reference of the MA in the TRR. The TRR must have already executed the MA in the past.

Optionally, in a step 106, at least one signature of the TRR is created, in particular a signature of the TRR for the valid output token reference(s) TRAU. The validity confirmation GB may contain or be formed by the signature of the TRR for the valid output token reference(s).

In the no case of step 102, the TRR checks (verifies) the MA 103, 104 and, if necessary, executes them 105. In step 103, the TRR checks whether each input token reference TREU and TREI2 of the MA is stored in the TRR. If the input token references TREH and TREU of the MA are stored in the TRR (yes case), the TRR checks the MA for error 104. For example, the syntax of the MA is checked, in particular the command KO (e.g.: unknown KO type or KO- Type of TH) and/or the number of input and output token references (e.g.: no or too few output token references/input token references). The value neutrality of the token reference values (sum input value(s) = sum output value(s)) and/or the signature(s) 32 of the MA is checked.

If the verification 103, 104 of the MA is not successful, an invalidity confirmation UGB is sent for the GA 109. In contrast to treating the MA as a registration request, the history is no longer used to check whether the MA has already been carried out. Both in the no case of step 103 and in the case of an error in the MA (yes case of step 104), the UGB is sent in step 109.

If the verification 103, 104 of the MA is successful, the TRR executes the MA 105 and sends the validation confirmation GB for the GA in step 108. In step 105, the TRR deletes the input token reference(s) TREU and TREU and stores the output token reference(s) TRAU and TRAU of the MA in the TRR, or in the storage unit 1 of the TRR. Step 106 is again optionally carried out before step 108, so in the present example only TRAU is signed and the signature for TRAU is provided in the GB for the GA of the TRR of the transaction unit TE. With the method according to Fig. 3b, it is first checked whether the (specified) TRA of the GA is (are) stored as a valid TR in the TRR and only if the TRA in the TRR are not valid are TRE and KO checked (i.e. the MA verified). This reduces the effort involved in checking the validity. In addition, there is no longer a history check for the MA, since the MA was received in a GA validity request.

3c shows a second exemplary embodiment of a method sequence for checking the validity of a token T based on a validity request GA according to FIG. 3a according to the invention.

In step 101, the TRR receives the GA and now first checks 104 the MA of the GA for errors (particularly in syntax, value neutrality and/or signatures). In step 103, if MA itself is error-free, the TRR checks whether the input token reference(s) TREH and TREU of the MA are stored in the TRR. If the input token references TREU and TREU are stored in the TRR (yes case), the MA of the GA is executed 105.

On the other hand, if the MA is faulty (yes case of step 104) or the input token reference(s) of the MA are not stored in the TRR (no case of step 103), step 102 is executed. In particular, if the MA cannot be verified, it is checked in step 102 whether the (optionally specified) output token reference TRAU or the (optionally specified) output token references is stored in the storage unit 1 of the TRR.

If step 102 is yes, a validity confirmation GB is sent to the TE in step 108 in response to the GA. The (specified) output token reference (s) is (are) already stored in the TRR, in particular in its storage unit 1. The TRR has already carried out the MA with this TRA in the past. Optionally, a signature of the TRR for the (specified) output token reference(s), here TRA12, is created beforehand 106. In the case of no in step 102, the TRR sends 109 an invalidity confirmation UGB for the (specified(s)) MA output token reference(s).

If step 103 is yes, the TRR executes the MA's modification command KO in step 105 and then sends the validity confirmation 108. In the TRR, the MA's input token references are deleted in step 105 and the MA's output token references are saved.

The method according to FIG. 3 c is first used to check whether the MA is faulty and/or the TRE is not stored in the TRR. Otherwise, i.e. even though the MA of the GA cannot be executed, it is checked whether the (specified) TRA of the GA are already saved. The method according to Figure 3c also reduces the effort involved in checking the validity.

Fig. 4a shows a second exemplary embodiment of a validity request GA according to the invention. This GA includes two or more modification requests MA (MAi, MA2, . . . MA _X ). Each MA includes (one or) more input token references TREH, TREU and (one or) more output token references TRAII TRAU and a modification command KO. The number of output token references TRA and the number of input token references TRE in the modification request MA is not restrictive, it may be more or less. Examples of the typical number of input and output token references TR per specific command KO are listed later. Optional MA signatures are not shown separately here.

The GA’s MAs are verified individually. It is preferred that the youngest MA, Max, be verified first. In general, MA of the GA is optionally verified until either a GB or a UGB can be sent for the GA. In some cases, all MA of the GA can be checked and executed one after the other before a GB is sent. In some cases, however, a GB for the GA can be sent without checking a single MA (according to Fig. 4b, for example in the special case: TRAIJ = TRAIJ).

The modification requests MA of the GA can be present as a batch or as a sequence of modification requests MA.

In the case of a sequence of MAs, the MAs will essentially indicate consecutive modifications to tokens in time. At least one output token reference of one MA of the sequence will be input token reference of another MA of the sequence. Preferably, two or more consecutive MAs, for example MAx.i and _MA Accordingly, the modification requests MA of the GA are in the order MAi. . . _MA MA _X is the most recent MA and represents the last modification to a token.

However, Fig. 4a shows a stack of MA in the GA as an example. The input and output token references TR of the modification requests MA in the GA are essentially independent of each other (neither TRAII nor TRAU correspond to TRE21 or TREU, for example). Especially for larger stacks (e.g. with i > 5) and/or for stacks with MA only of a transaction unit, it can still happen that an output token reference of one MA of the stack is an input token reference of another MA of the stack.

As optional checking information 43, the validity query 40 shown includes one or more output token references TRAij (jth output token reference of the ith modification information) to be checked for validity. The specified output token reference(s) TRAij may include one, several or no output token references of the last modification indication (MA _X ) of the GA, even in the case of a sequence. In particular, the verification indication may include two or more output token references TRAij of the GA from different MAs, such as TRA21 and TRAXI. Furthermore, the test information cannot include two or more output token references TRAIJ of the GA, preferably from different MAs, such as TRAII, TRA22 and/or. TRAX2.

4b shows a first exemplary embodiment of a method for checking the validity of at least one token T based on a validity request GA with several MA, for example according to FIG. 4a. The sequence of the method in FIG. 4b essentially corresponds to the method according to FIG. 3b (identical steps 102, 103, 104, 105, 106) and in this regard reference is made to the statements in FIG. 3b.

The method according to FIG. 4b includes a loop 141, 142 for the modification requests MA of the GA (with loop index i=l to x for MAi). Starting with the first MA of the GA, MAi, it is checked 102 whether a specified output token reference, TRAIJ, or alternatively all output token references of the MA, TRAII and TRAII, of the MA are already stored (as a valid TR). If necessary, the modification request MAi is executed 105. In a variant of the method, not shown, a UGB could be sent in step 109 as soon as the current MA of the GA is not executable (no case of step 103 or yes case of step 104), if all TR of the GA must be checked for validity. In the example shown in Fig. 4b, on the other hand, loop 141, 142, including steps 102-106 (and 146), is executed for each MA, MAi. . . MA _X , which passes through GA.

Output token references TRAIJ that have already been previously saved according to step 102 or saved in step 105 can be buffered in the loop as TRA of the GA - recognized as valid or already signed. Optionally, in step 146 it is also cached that the specified TRAIJ of the MAi or the output token reference or references, TRAIJ, of the MAi are invalid. If all specified TRAIJ are valid or all output token references of the GA are valid, a validity confirmation GB for the GA, including optional signatures, is sent 108. Otherwise, an invalidation confirmation can be sent 109. Optionally, a partial validity confirmation TGB can be (created and) sent 148, unless all but at least one output token reference in question is valid (step 147) The partial validity confirmation TGB preferably only includes the signatures of the TRR for the valid output token references of the GA or the valid output token references TRAij to be checked for validity.

In step 141 it is checked whether the current modification information MAi is the last modification information of the GA (i.e. whether I == X). Alternatively or additionally, it can be checked whether all specified TRAij have already been recognized as valid and/or invalid. In the no case of step 141, the next MA of the GA is verified, indicated by step 142, which increments the running index "i" (the index i is at the start in step 101: i = 1). The next MA is then checked in further steps 102-106, 146. If an termination criterion for the loop is recognized (yes case of 141), depending on the case (step 107, 147), the validity confirmation GB for the GA is sent to the TE or the invalidity confirmation UGB is sent for the GA (or optionally a partial validity confirmation for the GA is sent) .

4c shows a further exemplary embodiment of a method for checking the validity of a token T based on a validity request GA with several MA, in particular according to FIG. 4a. The sequence of the method in FIG. 4c essentially corresponds to the method according to FIG. 3c (identical steps or sequence of steps 104, 103, 102, 105, 106) and in this regard reference is made to the statements in FIG. 3c.

4c also includes a loop 141, 142 with a termination criterion (all specified TRAIJs checked for validity or all MAs run through), which allows each MA of the GA to run through the step sequence 102-106, 146 until the termination criterion is reached. As before, depending on the case, the corresponding confirmation GB/UGB/TGB will be sent 108/109/149. Even in a process according to FIG. 4c, MA of the GA can remain unchecked and a validity confirmation GB can still be sent for the TRAIJ to be checked for validity.

Stacks of modification information MA are preferably checked using the method according to FIGS. 4b and 4c. The modification information contains independent token references. Fig. 5a shows a third exemplary embodiment of a validity request GA according to the invention. The GA includes several modification details MAi, MA2, . . . _MAX . The GA modification information is dependent on each other. The GA therefore includes a sequence of

Modification information, some of which has already been described in more detail before.

In the example shown, MAi's output token reference is TRAII

be the input token reference of the MA2. The output token reference TRA22 of MA2 could be an input token reference of another MA of the GA, for example the MA3, MA4 or MA _X . The first input token reference of MA _x is the output token reference TRA _X -I 1 of MA _x -i. As the GA's output token references TRAIJ to be checked for validity, the GA's check information 53 contains the output token references TRA21 and TRA _X 2. The MA's optional signatures are again not shown in the figure.

5b shows a first exemplary embodiment of a method for checking the validity of a token T based on a validity request GA with several, preferably interdependent, MAs - in particular according to FIG. 5a.

The GA is received 101 and in step 102 it is checked whether the token references TRAIJ to be checked for validity are stored as valid TRs in the TRR, in particular whether they are present in the storage unit 1 of the TRR, which only contains the valid TRs. If the specified output token references TRA21 and TRAX2 are already stored, the validity confirmation GB can be sent 108 - optionally after the signatures 106 have been created as a cryptographic confirmation of the TRR for the valid TR. In this case, none of the MA of the GA (for errors and/or or feasibility).

In a loop 153a-c, the x modification information MA of the sequence is checked one after the other

103, 104. For the respective MAi, it is checked in step 103 whether the input token reference(s) TREH and TREI2 are stored in the storage unit 1 of the TRR, i.e. are valid. In the no case, an invalidity confirmation UGB is sent 109. Likewise in the (yes) case of step

104 that a check of the MAi results in an error (as before: syntax, value neutrality, . . .).

In the No case of step 104 - since the method is aimed at a sequence whose token references depend on each other - the MA is not actually executed yet. The output token references TRA of the MAi are not yet saved. Deleting the input token references TRE of the MAi in the loop would be conceivable, but preferably only takes place in step 155. The verification unit 2 only temporarily stores the output token references TRA of the MAi to be saved (and the input token references TRE of the MAi to be deleted). Several of these cached output token references will be the input token reference of another MA of the GA (which would therefore have to be deleted again). Now they are simply removed from the verification unit's cache. An unnecessary writing access (or several unnecessary writing or deleting accesses) to the storage unit 1 can thus be avoided. Only in step 155 are the cached (and not deleted again) output token references written into the storage unit. Step 155 may also be referred to as selectively storing the overall output token references of the sequence. In the example of FIG. 5b, the output token references TRA21 TRAXI TRA _X 2 are saved and the input token references TREH TREI2 TRE21 are deleted. The validity confirmation for the output token references TRA2I,TRA _X 2 can then be sent.

5b shows, with steps 151, 152, optional steps that would prevent already executed modification information MA from incorrectly leading to an invalidity confirmation UGB as a result of MA of the GA. If it is determined in step 102 or 151 that a TRAnj has already been stored, this TR is signed in step 152 and the index of the loop is set to i=n+1. The modification specification MA _n has already been carried out. The processing of the sequence of modification information can therefore be started with the following modification information MA _n +i. In embodiments not shown, the sequence of the MA can be evaluated in order to recognize secondary branches of the sequence and take them into account as such in the processing of the sequence.

5c shows a further exemplary embodiment of a method for checking the validity of a token T based on a validity request GA with several MA, in particular according to FIG. 5a or a GA with a sequence of MA.

For the GA received in step 101, all modification information MAi to MA _X of the GA are first checked for errors in step 164a. If the MA contains an error (no case in step 164b), it is checked whether the specified output token references TRAIJ of the GA are all already stored 102. Depending on the case, the UGB is sent accordingly 109 or - after optional signing 106 of the TRAIJ - the validity confirmation GB is sent 108.

In the yes case of step 164b, all TRs of the GA are read 162 from the storage unit 1 (it is checked for all TRs whether they are already stored). If all specified output token references TRAij are present 102, the validity confirmation 108 is sent as before. If not (no case of step 162), in step 165 the overall output token references of the sequence are selectively saved and the input token references (if still saved) are deleted. The procedure according to Fig. 5c also leads to optimized processing of the GA with a sequence (or a stack).

After checking the GA of FIGS. 3a to 5c or the RA according to FIGS. 2a/b, the checked (verified) token references TR are stored in the token reference register TRR, whereby the modification to the token T is registered in the transaction system TS.

The token reference TR is uniquely assigned to the token T and is used to register the token T in the transaction system TS. The token reference TR is therefore the public representation of the token T from the direct transaction layer TE layer. The sole knowledge or possession of the token reference TR does not allow the transfer of the token T and does not mean that the TE is in possession of the token T. The token reference TR is used to prevent multiple issuance attempts. It is checked whether token values v were generated in an inadmissible manner. Therefore, the token reference TR and, if necessary, the history of the token T and corresponding modifications by registration requests RA sent by transaction units TE are stored in the token reference register TRR.

The tokens T are stored, for example, in token stores or electronic purses, so-called wallets, of a TE. A wallet is, for example, a software application within a transaction unit TE (in particular a secure element) or a terminal device in which the TE is installed ready for operation. A wallet can be set up as an application on a smartphone, a smart card or a payment terminal. The wallet is used to securely manage token T of the TE, to generate token references TR, to modify token T, to exchange token T and/or to initiate the checking of the validity of tokens. Wallets are used to communicate with the token reference register TRR, to generate registration requests RA for modifications of the token T to the token reference register TRR, to carry out transactions from token T to a transaction unit TE and/or to generate validity requests GA.

For a transaction with a transaction unit TE, it is not necessary for there to be a communication connection to the token reference register TRR of the transaction system TS. The transaction system TS is set up to carry out a transaction offline, i.e. without a communication connection with the token reference register TRR. A corresponding registration of token T can therefore take place after a transfer of the token T to a transaction unit TE. The token reference register TRR is a unit of the transaction system TS and is either a central register or a central database of the transaction system TS or a decentralized register or a decentralized database (DLT) of the transaction system TS.

According to the invention, the validity of a token T can be easily checked. For this purpose, a validity request GA is created by the transaction unit TE. The validity request GA includes the token reference TR of the token T, the validity of which is to be checked. The validity request GA also includes modification information about one or more modifications to the token T.

A token reference TR can be sent to the token reference register TRR together with a modification information as a validity request GA regarding the token T.

Additionally - as indicated in Fig. 1 - the validity request GA can be signed with the private part r of the token-specific key pair. Signing makes it possible to verify whether the sender of the token reference TR was in possession of the token T, which further increases security in the transaction system TS.

A validity request GA can be sent to the token reference register TRR to check whether the token T is valid. This validity request GA is received in the token reference register TRR. After checking the validity request GA by the token reference register TRR (or its verification unit2), the transaction unit TE is informed whether the token T is valid or not.

A validity request GA is preferably signed with the private part r. The signature allows the syntactic authenticity of the command to be easily checked by the recipient (TRR or TE). This check is preferably carried out in the database 1 or the verification unit 2. In addition, a validity query GA can, for example, be syntactically validated by checking the signature and/or the token reference TR.

Even if a signature can be checked in a transaction unit TE, this does not ensure that multiple issuance of the same token T has not been attempted. Therefore, registration in the token reference register TRR is intended. In addition, the TE transaction units provide a secure hardware platform. With an available connection to the token reference register TRR, the token references TR are transmitted and the multiple issuance attempt can be detected in the token reference register TRR. If a token reference TR is not yet known in the token reference register TRR, it is added (saved).

An archiving unit can also be kept in the token reference register TRR (not shown in FIG. 1). Registration requests RA and/or validity requests and/or token references that are no longer valid are stored in this archiving unit.

For example, the following modifications to an existing token T can be present as commands KO: for example “Switch”, “Split” or “Merge”. Commands KO, which are reserved for the token issuer, can also affect the creation (=Create) of a token T or the deletion (Destroy) of an existing token T. In theory, another type of command for checking the validity of an unmodified token T in the TRR was also known. The following table shows example command encodings (0x01 to 0x05). The coding shown here and also the order of the data elements in the MA used in the figures is interchangeable or only an example.

The following table shows examples of possible signature syntax. Input token T and input token references TR are specified (“used”) for each command. Output token T and output token references TR are specified (“generated”) for each command.

A modification statement (e.g. a registration request RA or a validity request GA) has the basic structure of the following three elements: command type, input token reference(s), output token reference(s).

Each command KO has a partially characteristic number (one or more) of input token reference(s) (“inputs”) and output token reference(s) (“outputs”). A switch, for example, preferably has exactly one input token reference and exactly one output token reference. A split has exactly one (or more) input token reference and at least two (or more) output token references. A connect has at least two (or more) input token references and exactly one (or more) output token reference(s).

6 shows a further embodiment of a token reference register TRR of a transaction system TS. It is indicated here that several storage units 1 can be kept in the token reference register TRR in order to save one

6 shows a further embodiment of a token reference register TRR of a transaction system TS. It is indicated here that several storage units 1 can be kept in the token reference register TRR in order to accelerate the storage of a large number of token references TR. It is also indicated here that several verification units 2 can be kept in the token reference register TRR in order to accelerate verification of validity requests GA and/or registration requests RA. In addition, a transaction unit from a bank TEB is shown, which can serve as an interface between the transaction system TS and a bookkeeping system (lending, account management). It can enable transaction units TE to transfer tokens T of the transaction system TS into another transaction system TS. This transfer is possible bidirectionally. The token issuer, TH, is solely responsible for generating token T and also deleting token T in the TS.

6 also shows a registration request unit RAE, which can receive a validity request GA (and/or RA) from a transaction unit TE1 and forwards the GA (and/or RA) to the TRR.

The TRR also contains an archive unit 5 in which RA and/or GA that have already been executed and/or token references that are no longer valid are stored, in particular as a linked graph.

Transaction units TE can send their RA and/or GA to the TRR via a first interface 3 of the TRR. However, only the token issuer TH is allowed to send commands to the TRR via the second interface 4 of the TRR.

It can be advantageous if only one (or a few) token T is used per transaction unit TE (here as a secure element, e.g. smart card or TEE). This means that the TE connects a received token T with the token T stored in the token storage (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 carried out without a registration request RA or a validity request GA and the token T can be passed on immediately after a modification. There may therefore be a sequence of modifications to token T that are not known to the TRR. Typically, the sequence of modification statements MA consists of a combination of SPLIT and MERGE modifications. Each of these modifications is also referred to as a “proof” (see above for FIG. 1) or is stored as, preferably signed, modification information MA with the token T. This creates the sequence of modification information MAp or. in the TE1 for the token T. MAi, MA2, ... _MA

According to the invention, a validity query GA is now provided to check a token for validity. The terminal device receives the GA and/or the MA or MAF. Alternatively or additionally, a registration request unit RAE can also be provided as a switching entity between the TE and the TRR, see Fig. 6. The RAE then receives the GA and/or the MA or MAF from the TE or the terminal. A GA is sent to the TRR.

The terminal (not shown in Figure 6) or the RAE attempts to transmit the GA to the TRR. This means that the end device or the RAE only carries out a protocol translation, for example from APDU between end device/RAE and TE to HTTP(S). GA and/or the MA or MAF are neither evaluated nor interpreted by the end device nor by the RAE. The order of the modification information in a GA of a sequence MAF is not changed by the terminal or the RAE. A validity confirmation GB (or a registration confirmation RB) of the TRR is then transmitted from the terminal and/or the RAE to the TE. Each GA and/or the MA or MAF can be signed with the private part r (the random number r) of the relevant token-specific key pair. Therefore, the modification information MA, which is stored in the TE (in the token memory), is sometimes also referred to as a proof.

The verification unit 2 of the TRR checks the validity, in particular using a method according to FIGS. 3b to 5c. A GB is sent back to the secure element or the TE (possibly via the RAE or the end device).

For example, assume a TE1 has performed the following modification sequence on a token A:

Split: A - B, C (Token A is split into Tokens B and C)

Switch: C - D (Token C switched to Token D)

The token D is transferred to TE2 with the two modifications (proofs) “Split” and “Switch”. TE2 also carries out:

Merge: D, E - F (tokens D and E are merged to form token F)

Validity check of token F: Only token F should be checked for validity. For this purpose, a GA is generated and the token reference of the token F (as a checking specification) together with the modification information MA consisting of the three modifications (proofs) “Split”, “Switch” and “Merge” are sent from the TE2 to the TRR as a GA. According to the GA, which only specifies the token F as the token to be checked using its token reference, the output token reference TRB of the first MA of the GAs is not to be checked or is not checked for validity by the TRR. In this case example, the first two modification details of the GA are only carried out optionally, for example if TE1 (or another TE) has not yet sent an RA or GA with these two MA to the TRR.

The GB can of the TRR can optionally be returned in the form of a status message that also encodes additional information, for example:

200: Token is valid, all modifications of the modification information could be resolved

400: Token is valid, some modifications of the modification information could not be resolved 500: Internal error

600: Token is invalid.

The cryptographic confirmations, in particular signatures, of the TRR can be attached to such a status message. The GB can or the valid TR can be signed with a private key pKey RR of a key pair of the verification unit 2.

REFERENCE SYMBOL LIST

PKey H public part of the token issuer key pair pKey H private part of the token issuer key pair

PKey RR public part of the verification unit key pair pKey RR private part of the verification unit key pair

R public part of the token-specific key pair r private part of the token-specific key pair

GA validity request

GAsig T validity request signed with private part of the token individual

key pair

GB validity confirmation

UGB confirmation of invalidity

GB sig TRR validation signed with private part of the token reference register

key pair

RA registration request

RAsig T registration request signed with private part of the token-specific key pair

RAsig TH registration request signed with private part of the token issuer key pair

MA modification information

RAE Registration Request Unit

RB registration response, registration confirmation

T tokens

TE transaction unit

TEB transaction unit bank

TE layer Direct action layer

TRR layer register layer

TH token issuer

TR _X token reference of the GA

TRE input token reference

TRA output token reference

KO command, modification command

TRR token reference register

TS transaction system v, TW token value a-h indices for various tokens and token references

S Total token value of the transaction system

1 database, storage unit

2 verification unit

11-19 Process steps in the prior art

3 Subscriber interface / MA receiving unit

4 Publisher interface / re-registration unit

5 MA archiving unit

6 total sum checking unit 30 Validity Request

31 Modification information

32 Signature of the modification statement

33,43,53 Test information

40 Validity request for batch of MA

50 Validity request for sequence of MA

101 Receive GA

102 Check whether TRA is saved

103 Check whether TRE is saved

Check 104 MA for errors

105 Save TRA

106 Create signature

108 Send confirmation of validity

109 Send invalidity confirmation

141,142 Edit loop for MAi

146 Note invalidity for TRA

107 Check whether overall validity has been established

147 Check whether partial validity has been determined

148 Send partial validity confirmation

151 Check whether a TRAÜ is saved

152 Signing the TRAÜ

153a, 153b, 153c Editing loop for MAi

155 Selective storage for TRA of the MA sequence

164a Verify the MA sequence

164b Check whether sequence is verified

165 Selective storage for TRA of the MA sequence

Claims

Patent claims

1. Secure element of an electronic transaction system (TS), the secure element having a token storage for tokens (T) of the transaction system (TS); wherein the secure element is set up as a transaction unit (TE) to exchange tokens (T) of the transaction system directly with another transaction unit (TE) of the transaction system (TS); wherein each token (T) of the transaction system is uniquely assigned a token reference (TR), which can be registered in a token reference register (TRR) of the transaction system; wherein the secure element is set up to generate at least one output token (TA) and its output token reference (TRA) based on at least one input token (TE); wherein the secure element provides at least one modification information (MA), which comprises at least one input token reference (TRE), one command (KO) and at least one output token reference (TRA), for the token reference register (TRR), characterized in that that the secure element is set up to provide the at least one modification information (MA) as a validity request (GA), and the secure element is set up to provide a validity confirmation for at least one output token reference (TRAIJ) of the validity request (GA) to be checked for validity. to recieve.

2. Secure element according to claim 1, characterized in that the validity request comprises the at least one output token reference (TRAIJ) to be checked and at least one output token reference not to be checked.

3. Secure element according to claim 1 or 2, characterized in that the validity request includes, in addition to the modification information (MA), a verification information (33; 43; 53) which specifies the at least one output token reference (TRAIJ) to be checked.

4. Secure element according to one of claims 1 to 3, characterized in that the secure element is set up to provide modification information either as a validity request (GA) or as a registration request (RA).

5. Secure element according to one of claims 1 to 4, characterized in that the confirmation of validity is a separate one for each output token reference (TRAIJ) to be checked cryptographic confirmation, preferably stored in the secure element; or the confirmation of validity for all output token references to be checked (TRAij) comprises a common cryptographic confirmation, which is preferably stored in the secure element.

6. Secure element according to one of claims 1 to 5, characterized in that the validity request comprises several modification details (MA), in particular a stack and / or a sequence of modification details.

7. Secure element according to one of claims 1 to 6, characterized in that the secure element further comprises a processor, in particular for carrying out the steps as

Transaction unit, and/or an interface, in particular to a local terminal, via which the validity request for the token reference register (TRR) is provided; and or

Tokens (T) comprise as data elements a token value (v) and a secret token element (r); and or

Token references (TR) include a token value (v) and a public token element (R) as data elements.

8. Method for checking the validity of a token (T) of a secure electronic transaction system (TS), a token reference (TR) being uniquely assigned to each token (T) of the transaction system, a token reference register (TRR) of the transaction system (TS) a verification unit (2) and a storage unit (1), in which the token references (TR) of valid tokens (T) are stored, with the following method steps in the token reference register (TRR):

- Receiving (101) a validity request (GA), which includes a modification information (MA) with at least one input token reference (TRE), at least one output token reference (TRA) and a command (KO);

- Checking (102) at least one output token reference (TRAij) of the validity request (GA) to be checked for validity to see whether it is stored in the storage unit (1); and

- Sending (108) a confirmation of validity (GB) for the at least one output token reference (TRAij) to be checked; wherein the validity request (GA) includes the modification information (MA; MAI) that can only be processed optionally and/or a verification information (33; 43; 53) which specifies the at least one output token reference (TRAij) to be checked.

. Method according to claim 8, characterized in that the verification unit (2) processes modification information (MA) with one or more of the sub-steps:

- Check (103) whether the at least one input token reference (TRE) is stored in the storage unit (1);

- Verifying (104) the modification information (MA) by the verification unit (2), in particular a signature in the modification request (MA) and/or a value neutrality of the modification information (MA) and/or a syntax of the modification information (MA); and or

- Executing the command (KO) by storing (105) an output token reference in the storage unit (1) and in particular by deleting an input token reference in the storage unit (1).

10. The method according to claim 8 or 9, wherein the validity request (GA) comprises at least one, preferably several, output token reference (s) (TRAII) that cannot be checked for validity; and/or the validity confirmation (GB) comprises a separate cryptographic confirmation for each output token reference (TRAij) to be checked.

11. The method according to any one of claims 8 to 10, wherein the validity request (GA) comprises a plurality of modification information (MAI, MA2, ... MAx), each modification information (MA) containing one or more input token references (TRE), one or more Output token references (TRA) and a modification command (KO), wherein the modification information is preferably a stack (40) of modification information and / or a sequence (50) of modification information (MA), in particular stacks consisting of independent modification information (MA). or consequences include at least partially interdependent modification information (MA).

12. The method according to one of claims 8 to 11, wherein the verification unit (2) directs a common memory query to the storage unit (1) for output token references of different modification information and / or for output token references and input token references of at least one modification information (MA ).

13. The method according to one of claims 11 or 12, wherein a partial validity confirmation (TGB) is sent for the batch of modification information (MA); and/or at least one output token reference of a modification information (MA) is only cached internally for a sequence of modification information and/or is only stored in the storage unit (1) after checking one, several or all further modification details (MA) of the sequence.

14. The method according to one of claims 8 to 13, wherein the token reference register (TRR) carries out the method with a transaction unit TE or the secure element according to one of claims 1 to 7 and / or the token reference register (TRR) further comprises :

- further verification units (2) and/or one

- Archive unit (5), which stores no longer valid token references and/or validity requests (GA) and/or registration requests (RA) that have already been carried out.

15. A token reference register (TRR) for a transaction system (TS), set up to carry out the method steps according to one of the preceding claims 8 to 14, in particular with a transaction unit TE or the secure element according to one of claims 1 to 7.

16. The token reference register (TRR) according to claim 15, comprising: the storage unit (1) for storing token references (TR) for registering tokens (T) in the transaction system (TS); an interface (3) set up to receive a validity request (GA); the at least one verification unit (2).

17. A transaction system (TS) comprising: a register layer (TRR layer) with a token reference register (TRR) according to claims 15 or 16 for registering token references (TR); and a direct transaction layer (TE layer) with a plurality of transaction units (TE), including a secure element according to one of claims 1 to 7.