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

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

[0001] SECURE ELEMENT, METHOD FOR REGISTERING TOKENS AND TOKEN REFERENCE REGISTER

[0002] 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 uniquely assigned to a token, as well as to the transaction system as a whole.

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

[0004] For example, DE 102009 038 645 A1 and DE 102009 034 436 A1 disclose systems or portable data storage devices as secure elements for transferring monetary amounts in the form of electronic data records. These systems prevent payment with duplicate data records and provide a high degree of security against manipulation. These require complex structures and elaborate encryption and signing processes for the transactions.

[0005] The security of transactions and the associated transaction data includes protecting the confidentiality of the exchanged data, protecting the integrity of the exchanged data, and protecting the availability of the exchanged data.

[0006] As solutions for secure transaction systems, a distinction is often made between token-based systems and account-based systems. In addition to traditional account-based systems, such as credit or loan accounts, more innovative account-based systems based on blockchain topologies have recently been discussed. The account-holding entity has access to the data record representing the monetary value. While these more innovative account-based systems provide a high level of integrity protection, they also publish a great deal of information, for example, when data records are stored in a freely readable data structure and change ownership there.

[0007] It is also already known to extend a token-based transaction system with a token registry. The secure element sends a registration request for its token to the registry. The registry verifies the registration request and, for example, only stores a token reference for the token, thus not knowing the token itself.

[0008] WO 2020 / 212337 A1 describes a transaction system in which even token modifications—for example, by splitting the token—are securely possible offline, i.e., directly between the secure elements of the transaction system and without any additional control authority. The tokens can be immediately transferred after receipt in a secure element or subscriber unit without the need 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, secure elements are known to be resource-limited, particularly with regard to storage space, processing speed, transmission time, and / or speed.

[0009] The invention is based on the object of providing a new method that is more suitable for a secure element as a transaction unit, thus particularly saving resources. 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 applications, should preferably be retained. In particular, multiple modification details of a transaction unit should also be processed in a resource-efficient manner.

[0010] The stated object is achieved by the features described in the independent patent claims. Further advantageous embodiments are described in the respective dependent patent claims.

[0011] A secure element of an electronic transaction system has a token memory for tokens of the transaction system and is configured to exchange tokens directly with another transaction unit of the transaction system. Each token of the transaction system is uniquely assigned a token reference. Token references (and thus the assigned tokens) can be registered in a token reference register of the transaction system. The secure element is further configured to generate at least one output token and its output token reference from at least one input token. The secure element provides at least one modification specification for the token reference register, which comprises at least one input token reference, a command, and at least one output token reference.The secure element then provides the at least one modification indication as a validity request and receives a validity confirmation for at least one output token reference of the validity request to be checked for validity.

[0012] Sending the modification information in a validity request, as explained in more detail below, enables a multitude of initially seemingly small advances, which, when added together, can be beneficial 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 more quickly on average than a conventional registration request, this already reduces the connection or transmission time and thus the effort required in the secure element to manage the connection, especially to maintain it (timeouts, etc.) or to re-establish it.

[0013] The validity query can preferably include at least one output token reference to be checked and at least one output token reference not to be checked. Therefore, not all output token references need to be checked for validity.

[0014] The validity request can comprise the modification specification and additionally a check specification that specifies the at least one (or more) output token reference(s) to be checked. The check specification can, for example, contain the output token reference(s), contain a reference(s) to the output token reference(s), or be encoded by one (or more) set flag(s) for the output token reference(s). Flags are generally bits that are either set or unset. For example, a flag would be provided for each output token reference of the validity request or the modification specification, which can be either set or unset. Particularly preferably, the check specification relates to output token references of at least two different modification specifications of the validity request.

[0015] Specifically for the benefit of the token reference register, the secure element could be configured to provide modification information either as a validity request or as a registration request. For example, the secure element could use the following selection criteria for sending a validity request:

[0016] - a number of modification details stored in the secure element, in particular more than two modification details, and / or

[0017] - a time criterion, in particular with the aid of a timestamp, for example of 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.

[0018] However, such a selection by the secure element is not actually required. As will become clear below, the secure element can always send one (or more) modification indications as a validity request.

[0019] In principle, it is conceivable to cryptographically secure the data exchange with the token reference register, including the validity request and confirmation, by encrypting and / or signing it. This would, in particular, make it possible to detect any tampered-with confirmation by third parties.

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

[0021] The validity request can comprise a plurality of modification specifications, in particular a stack and / or at least one sequence of modification specifications. Modification specifications that are independent of one another (in their token references) are referred to herein as a stack. The modification specifications of a stack can be processed in any order in the token reference register. Modification specifications that are dependent on one another (in their token references), in contrast, are referred to as a sequence. At least one output token reference of one modification specification is simultaneously the input token reference of another modification specification. Preferably, the sequence comprises a plurality of output token references that are simultaneously the input token reference of a subsequent modification specification in the sequence. The modification specifications of a sequence cannot be processed in any order in the token reference register.The token reference register will execute the modification specifications 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. The sequence can be structured, in particular, with or without branches, for example only "MAI => MA2 => ... => MAn" or "(MAI, MA2) => MA3 ... (MA4, MA5) => MA6 ...". The modification specification(s) of the validity request can, in particular, only be executed optionally. The token reference register can send a validity confirmation even in the event of one (or more) incorrect modification specification(s). Whether the token reference register checks the modification specification(s) and, if necessary, executes it and / or which of the modification specifications were checked and executed is independent of the validity confirmation for the at least one (or more) output token reference(s) to be checked.

[0022] The validity request may be a request for a token reference register, which stores only the valid token references in a token reference storage unit, to check whether the output token reference(s) to be checked is (are) already stored in the storage unit.

[0023] The secure element typically comprises a processor, in particular for executing the steps as a transaction unit, and / or an interface, in particular to a local terminal device, via which the validity request for the Token Reference Register (TRR) is provided. A transaction unit can be a subscriber unit or is sometimes referred to as such below.

[0024] 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 may comprise, 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.

[0025] A modification is, in particular, the splitting and / or joining or switching of tokens. The command for the modification specification is, for example, "split," "join," or "switch." One (or more) input tokens with a (total) token value can be split into several output tokens with different token values ​​(but the same total value). Two or more input tokens with a total value can be combined into one 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.

[0026] The transaction unit, for example, the security element, can generate one (or more) output tokens, including the token value and secret token element, as well as the associated output token reference for the modification information. The transaction unit, for example, the security element, stores its tokens and, optionally, one or more modification information. The modification information is stored together with, or at least linked to, the output token.

[0027] Preferably, in response to receiving the validation confirmation, the security element may delete the modification information stored in the security element that was / were contained in the validation request.

[0028] Tokens can be exchanged directly with other transaction units. For tokens that are not yet registered, the token must be transferred along with the modification information(s). Already registered tokens can be transferred without the modification information.

[0029] This article provides a method for verifying the validity of a token in a secure electronic transaction system. Each token in the transaction system is uniquely assigned a token reference. A token reference register of the transaction system comprises a verification unit and a storage unit in which the token references of valid tokens are stored. The following steps are performed in the token reference register:

[0030] - Receiving a validity request comprising a modification statement with at least one input token reference, at least one output token reference and a command;

[0031] - 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

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

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

[0034] Checking (and optionally receiving and sending) is preferably performed by the verification unit of the token reference register. Receiving and sending can be performed by an interface unit of the token reference register.

[0035] Preferably, the verification unit processes modification information, i.e. optionally also the modification information(s) of the validity request, with one or more of the following sub-steps:

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

[0037] - Executing the command (or modification statement) by storing an output token reference in the storage unit and, in particular, by deleting an input token reference in the storage unit.

[0038] In advantageous embodiments, the validity confirmation is sent—in particular without further processing of the modification information—if the output token reference(s) of the validity request to be checked are already stored in the storage unit. Otherwise, the modification information(s) are processed. The validity confirmation can be sent alternatively or additionally after the processing of the (one or more) optionally processed modification information(s) has been omitted completely or in part, i.e., none of the substeps have been executed or not all substeps have been executed.

[0039] The validity request preferably includes at least one, more preferably several, output token reference(s) that are not to be checked for validity. The validity confirmation (GB) can include a separate cryptographic confirmation, such as a signature or checksum, for each output token reference to be checked.

[0040] The output token reference to be checked for validity does not need to be explicitly indicated in the check specification of the validity request. It can be one of the output token references contained in the modification specification. However, the token reference(s) to be checked are preferably received from the token reference register in the check specification, as a separate data element of the validity request. The check specification can be formed by one (or more) reference(s) to the output token reference(s) to be checked (e.g., the position or number of the output token reference in the validity request) or can contain the output token reference(s).

[0041] The validity request can comprise multiple modification specifications, each modification specification comprising one or more input token references, one or more output token references, and a command. The modification specifications are preferably a stack of modification specifications and / or a sequence of modification specifications. Stacks consist of independent modification specifications. Sequences consist of at least partially interdependent modification specifications. The token to be verified is transferable in the direct transaction layer of the transaction system directly between two transaction units of the transaction system (but does not have to have been transferred yet). The token to be verified has preferably been modified in a transaction unit without the token being registered in the transaction system.

[0042] Preferably, the validity confirmation is also sent if some of the multiple modification details are not executable (i.e., the assignment of the token references to tokens of the transaction system is partially not possible), especially if these modification(s) were 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 details of a validity request are traceable or executable by the verification unit. Only the assignment of at least one token reference to be checked must be verifiable. Thus, the verification takes place independently of the registration of one or more modifications from the modification details in the token reference register.

[0043] 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 stored or deleted. Preferably, the verification unit sends a common memory query to the storage unit for output token references of different modification specifications and / or for output token references and input token references of at least one modification specification.

[0044] In particular, for a batch of modification specifications 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 batch's output token references to be checked for validity.

[0045] For a sequence of modification specifications in the validity request, the verification unit can only cache at least one (or) output token reference(s) of at least one modification specification internally (i.e., not store them in the storage unit). The cached output token reference(s) are discarded if they are the input token reference(s) of another modification specification, or otherwise stored in the storage unit. At least one (or more) output token reference(s) of a modification specification are only stored in the storage unit after one, several, or all other modification specifications of the sequence have been verified. The token reference register can execute the method with a transaction unit or the secure element already described.

[0046] The token reference register may further comprise additional verification units and / or an archive unit which stores token references that are no longer valid and / or validity requests and / or registration requests that have already been executed.

[0047] A token reference register for a transaction system is configured 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.

[0048] The token reference register comprises the storage unit for storing the valid token references in the transaction system; an interface configured to receive a validity request and the at least one verification unit.

[0049] A transaction system includes a register layer containing the token reference register; and a direct transaction layer containing a plurality of transaction units, including a secure element.

[0050] Validation requests in the transaction system can be distributed among different verification units of a token reference register, allowing them to be processed in parallel by different verification units of the token reference register. This allows a large number of validity requests to be distributed internally within the token reference register among different verification units (“load balancing”).

[0051] The validation and / or the valid output token reference(s) to be verified are 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 unit upon receipt of the validation against the public part of the key pair of the token reference register. This increases security, because validation certificates generated by unauthorized third parties—for example, in the context of man-in-the-middle attacks—are recognized by a transaction unit due to a missing or invalid signature. Such validation certificates can then be ignored by the transaction unit.

[0052] A token is a record of a transaction system that is directly exchangeable between transaction units. With knowledge of the token, the receiving transaction unit is in possession of the token value represented by the token. Upon exchange, the token therefore automatically changes hands. A token—a record that is transferable independently of a transaction topology, such as blockchain topologies—can be transferred directly between transaction units without any intermediaries.

[0053] In one embodiment, the token is an electronic coin 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.

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

[0055] A first token element of each token of the transaction system is a token value, e.g. an asset, a property, a commodity and / or a monetary amount.

[0056] A second token element of each token in the transaction system is a private part of a token-specific key pair. This private part is a secret within the transaction system and is not published and may not be used multiple times. The generation of the private part must be unpredictable. This private part can be a random number. Preferably, the random number is the result of a truly random number generator.

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

[0058] Anyone who owns a token or has unrestricted access to it and its token elements can exchange that token with another transaction unit. Ownership of the token and its at least two token elements (token value and the private part of the token's unique key pair) is therefore equivalent to ownership of the value represented by the token.

[0059] Each token in the transaction system is assigned a token reference. This assignment is unique, meaning that each token is assigned exactly one token reference, and each token reference is assigned exactly one token. The token reference is a public record that is verifiably stored for each transaction unit in a storage unit of the transaction system's token reference register. Both the token and the token reference are unique. This unique assignment creates a 1-to-1 relationship between the token and the token reference.

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

[0061] The first token reference element of each token reference is the token value of the token uniquely assigned to the token reference. The token value of the token is thus identical to the token value of the assigned token reference. For example, the token value of the token reference is a copy of the token value of the assigned token.

[0062] A second token element of each token reference in 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.

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

[0064] The (mere) knowledge or possession of a token reference does not authorize the use / transfer / issue of the token value (token reference element). This represents a fundamental difference between the token reference and the token and is a core of the present invention.

[0065] 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 preferably involves concatenating these two token reference elements. Any other type of linking of these two token reference elements is not excluded by the invention and includes, for example, concatenating them, incorporating them into a TLV data structure, and / or logical linking.

[0066] A token reference can preferably be generated by an electronic wallet of a transaction entity. For this to happen, the transaction entity must have knowledge of the token and its token elements. The token reference can be generated by an electronic wallet of a transaction entity that wishes to send the token. Alternatively, the token reference can be generated by an electronic wallet of a transaction entity that has received the token.

[0067] The use of a token reference is not comparable to the use of addresses of transaction units in a blockchain-based transaction system, since the token reference register according to the invention does not use addresses of the transaction units to prevent traceability of the tokens.

[0068] The token reference registry is a unit of the transaction registry that stores the token references, thereby registering the tokens as valid tokens. This registry can be a centralized database or storage unit. This registry can be a decentralized ledger. The token reference registry can maintain a separate history of token references and / or registration requests and / or validity requests in an archiving unit.

[0069] A token reference is stored only once in the token reference register. Since a token reference for a token exists only once in the transaction system, the verification step can determine whether multiple attempts have been made to spend a token.

[0070] The token is stored in a token memory to which the transaction unit has exclusive access. This token memory can have a plurality of tokens; for example, the plurality of tokens can be stored in a data memory of the transaction unit. The data memory can be internal, external, or virtual, for example. In one embodiment, a "connection" can take place automatically upon receipt of a token, 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 device ready for operation. The transaction unit is preferably a secure element.

[0071] The data storage is, for example, the wallet memory of an electronic wallet. The electronic wallet is, for example, a software application stored executably on a transaction unit. The electronic wallet can enable the transaction unit to participate in the transaction system. The electronic wallet can generate a validity request to verify the validity of a token. Furthermore, 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. Furthermore, the electronic wallet can transfer tokens to another wallet (in another transaction unit).

[0072] A transaction in the transaction system is preferably atomic.

[0073] According to the invention, a token reference register is provided for a transaction system which is configured to carry out the method steps according to the method described above.

[0074] The token reference register can be configured to receive a plurality of validity requests, which are verified in parallel in a plurality of verification units to determine whether the at least one token reference contained in the respective received validity request is valid.

[0075] According to the invention, a transaction system is provided which comprises a register layer with a token reference register of the preceding type for registering token references and checking tokens by means of token references and a direct transaction layer with a plurality of transaction units, configured for the direct exchange of tokens among each other.

[0076] According to the invention, a two-layer transaction system is provided, consisting of a direct transaction layer for the direct exchange of tokens and a register layer. The register layer does not log any transactions; instead, it stores only token references, and modifications to tokens are stored 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.

[0077] The token reference register's storage unit preferably stores only 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.

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

[0079] According to the invention, a transaction unit, preferably a secure element, in a secure electronic transaction system comprises: an interface configured to: transfer tokens to another transaction unit; create and send, to a token reference register, a validity request for checking a token according to one of the preceding embodiments; access means to a token memory or token storage, 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 cryptographic one-way function to a private part of a token-specific key pair of a token of the token memory to obtain a token reference; and modify tokens.

[0080] In addition, the transaction unit has means for accessing a token memory and / or the transaction unit has a token memory, wherein at least one token of the transaction unit with the sequence of registration requests is stored in the token memory.

[0081] In addition, the transaction unit has a computing unit configured to apply a cryptographic one-way function to a private part of a token-specific key pair of a token in the token storage to obtain a token reference; and to modify tokens. Modifying tokens includes, in particular, splitting tokens, joining tokens, and / or switching tokens in the manner described above.

[0082] The transaction unit can be configured so that only one token is stored in its token store. This token is split for direct transactions (SPLIT) to generate a correct token value corresponding to the transaction to be made. When tokens are received in the transaction unit, the received token is immediately merged with the token in the token store.

[0083] To transfer a token to another transaction unit, this token in the token store can be split (SPLIT), whereby a registration request is generated for this purpose. The registration request preferably includes a token reference of the token to be split and a token reference of each of the split tokens.

[0084] Upon receiving a token from another transaction unit, the received token is linked to the token in the token store, generating a registration request for this purpose. The registration request preferably includes a token reference of the linked token and a token reference of each of the tokens to be linked.

[0085] In this case, a transaction unit can be a secure element that has secure access to tokens in a token memory. The secure element is, for example, integrated into a terminal device in a ready-to-use state. The secure element and / or the terminal device have a special computer program product (electronic wallet), in particular in the form of a secured runtime environment within a terminal device's operating system, a Trusted Execution Environment (TEE), stored on a data storage device, for example, a mobile device or a machine, preferably an ATM. Alternatively, the secure element is embodied, for example, as special hardware, in particular in the form of a secured hardware platform module, a Trusted Platform Module (TPM), or as an embedded security module, eUICC, eSIM. The secure element provides a trusted environment.

[0086] Communication between two transaction units for exchanging tokens can be wireless or wired, or e.g. optically, preferably via QR code or barcode, and can be designed as a secure channel. The exchange of tokens is additionally transport-secured, for example, by cryptographic keys, for example a session key negotiated for a token exchange or on the basis of a key pair specific to each transaction unit. The invention and further embodiments and advantages of the invention are explained in more detail below with reference to figures, wherein the figures merely describe exemplary embodiments of the invention. Identical components in the figures are provided with the same reference numerals. The figures are not to be regarded as true to scale; individual elements of the figures may be exaggeratedly large or exaggeratedly simplified.

[0087] Fig. 1 shows an embodiment of a transaction system according to the prior art;

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

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

[0090] Fig. 3a shows a first embodiment of a validity request according to the invention;

[0091] Fig. 3b shows a first embodiment of a method for checking the validity of a token based on a validity request according to Fig. 3a according to the invention;

[0092] Fig. 3c shows a second embodiment of a method for checking the validity of a token based on a validity request according to Fig. 3a according to the invention;

[0093] Fig. 4a shows a second embodiment of a validity request according to the invention;

[0094] Fig. 4b shows a first embodiment of a method for checking the validity of a token based on a validity request according to Fig. 4a according to the invention;

[0095] Fig. 4c shows a second embodiment of a method for checking the validity of a token based on a validity request according to Fig. 4a according to the invention;

[0096] Fig. 5a shows a third embodiment of a validity request according to the invention; Fig. 5b shows a first embodiment of a method for checking the validity of a token using a validity request according to Fig. 5a according to the invention;

[0097] Fig. 5c shows a second embodiment of a method for checking the validity of a token based on a validity request according to Fig. 5a according to the invention;

[0098] Fig. 6 shows another embodiment of a transaction system with a token reference register according to the invention;

[0099] Fig. 1 shows an embodiment of a transaction system TS according to the prior art. The transaction system TS comprises a register layer (TRR layer), in which a token reference register (TRR) is located. The TS also comprises a direct transaction layer (TE layer), in which a plurality of transaction units (or subscriber units) TE can be provided. Two transaction units TE1, TE2 are shown as representative units. The transaction units TE1, TE2 are preferably secure elements.

[0100] The transaction units TE of the transaction system TS are configured to exchange tokens T directly among themselves. 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., split, linked, or switched—by any transaction unit TE, and can be generated and deleted by the token issuer TH. A token issuer TH, for example, is a central bank.

[0101] 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 in a range of 1 to 2 31 -1. The random number r can be a number in the range from 0 to 2 256 -1, i.e. the order of an elliptic curve, for example secp256rl.

[0102] 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 be unpredictable.

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

[0104] For example, the random number r is a 32-byte token element of type integer. A transaction unit TE has exclusive access to this token store or includes this token store in a data store of the transaction unit TE.

[0105] For each token T, a token reference TR can be stored in the token reference register TRR. The token reference TR comprises the token value v of the associated token T and a public part R of the token-specific key pair. Thus, the token value v of a token T is known in the token reference register TRR.

[0106] The public part R of the token-specific key pair is generated by applying a cryptographic function to the private part r of the token-specific key pair. This function is difficult to reverse and thus provides the transaction system TS with the required security. R = r * G applies, where G can be, for example, a global parameter of the transaction system TS, e.g., a generator point of an elliptic curve, in this case the secp256rl curve.

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

[0108] 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, whose token reference TRA 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 transmitting the token TA together with its modification information to the transaction unit TE2 - the transaction unit TE2.

[0109] In Fig. 1, a known token reference register TRR is shown.

[0110] The token reference register TRR specifically manages the storage location for the token references TR, which can optionally also store previous registration requests RA, represented 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 database 1. This database 1 can consist of a combination of many databases (see also Fig. 6) that are interconnected. Furthermore, the token reference register TRR includes at least one verification unit 2. Verification unit 2 of the token reference register TRR verifies registration requests RA. Syntax correctness or the correct specification of a command in the registration request RA can be verified. The history of old (past) registration requests RA can also be checked.The separation of this verification unit 2 from the database 1 distributes the tasks of storing and checking and increases the speed in the token reference register TRR.

[0111] As already indicated in Fig. 1, 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.

[0112] Fig. 2a shows an example of a registration request RA according to the prior art. The registration request in Fig. 2a includes two input token references TRE, one output token reference TRA, and one modification command KO.

[0113] Additionally, 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, further increasing security in the transaction system TS.

[0114] Fig. 2b illustrates a method flow for registering a token according to the prior art. In step 11, the RA is received in the TRR. In step 12, a check is made to determine whether an input token reference TREH of the RA is stored in the TRR. If step 12 is negative, step 16 checks whether the registration request RA has already been executed and is stored in the memory unit 1 as part of the registration request history. If the answer is yes, the registration is (re)confirmed 18. If step 16 is negative, the RA is not confirmed according to step 19 (error message).

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

[0116] If step 13 is "yes," step 14 is executed. In step 14, a check is performed to determine whether the command with the input token references TREU and TREU ZU leads to the output token reference TRAII of the RA, for example, VEU + VEU = VAII, and whether the signatures are valid. In step 14, the command is checked for errors. If step 13 is "no" or step 14 is "yes," the RA is not confirmed (error message) according to step 19. If step 14 is "no," the RA's TRAII and the RA are saved in the TRR in step 15. The transaction unit is confirmed that registration has been completed in step 18.

[0117] The token reference register TRR is preferably not readable by the transaction units TE1 and TE2. It is of little practical relevance, but theoretically known, that a transaction unit can query the status of a token, i.e., query the status of a token reference TR stored in the token reference register TRR. However, such a status query is not a validity query in the present sense, as described in more detail below.

[0118] A transaction unit TE1, TE2 can send one or more existing modification statements 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 resulting relief of the limited resources is particularly useful for security elements as transaction units. Especially in security elements, multiple modification statements can exist for different tokens (stacks of modification statements) and / or for one token (sequence of modification statements).

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

[0120] The token reference register TRR shown in Fig. 1 is now also configured to verify validity requests GA. Verification unit 2 of the TRR, for example, is provided for this purpose. Verification unit 2 of the token reference register TRR then verifies registration requests RA and / or validity requests GA.

[0121] A history of old (past) validity queries GA relating to a token T can also be verified. However, the history is not required for processing validity queries GA. Therefore, storage unit 1 of the TRR can advantageously contain only the valid token references TR. A history of previously valid token references TR and / or modification specifications already executed can be provided in a separate unit, an archive unit. In the following, it is partly stated in abbreviated form that a check is carried out to determine whether a token reference is stored in the TRR. However, it is checked in each case whether the token reference is stored as a valid token reference or, assuming that storage unit 1 only contains valid token references, whether it is stored in storage unit 1.

[0122] Fig. 3a shows a first embodiment of a validity request GA according to the invention. The GA of Fig. 3a comprises a (single) modification indication 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; there may be more (indicated by the dots) or fewer. Examples of the number of input and output token references TR per specific modification command KO will be given later.

[0123] 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, for each input token reference TREU, TREU of the modification request MA, a signature 32 with the associated private part TEU, TEI2 can be present.

[0124] The validity request GA can optionally include a check specification 33. The check specification specifies the one or more output token references to be checked for validity. In the example shown, the validity of the output token reference TRAU is to be checked. For a validity request GA without an explicit check specification 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 references TRAU not to be checked for validity.

[0125] Fig. 3b shows a first 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 TRAU of the MA is stored as a valid token reference in the TRR (in particular in its memory unit 1). TRAu is the output token reference contained in the check specification 33 of the GA. If step 102 is yes, in step 108 a validity confirmation GB is sent to the TE in response to the GA. The MA of the GA, however, is not checked further. An output token reference of the MA already exists in the TRR. The TRR must have already executed the MA in the past.

[0126] 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 can contain the signature of the TRR for the valid output token reference(s) or be formed by it.

[0127] If step 102 is negative, the TRR checks (verifies) the MAs 103, 104 and executes them if necessary 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 errors 104. For example, the syntax of the MA is checked, in particular the KO command (e.g.: unknown KO type or KO type of the 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 of input value(s) = sum of output value(s)) and / or the signature(s) 32 of the MA are checked.

[0128] If the MA verification 103, 104 is unsuccessful, an invalidation confirmation (UGB) for the GA is sent 109. Unlike treating the MA as a registration request, the history is no longer checked to determine whether the MA has already been executed. Both in the negative 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.

[0129] If the verification 103, 104 of the MA is successful, the TRR executes the MA 105 and sends the validity 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 executed before step 108; 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. Using 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. Only if the TRA in the TRR is invalid are TRE and KO checked (i.e., the MA is verified). This reduces the complexity of the validity check. In addition, there is no longer any history check for the MA, since the MA was received in a GA validity request.

[0130] In Fig. 3c, a second embodiment of a method flow for checking the validity of a token T based on a validity request GA according to Fig. 3a according to the invention is shown.

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

[0132] If, however, 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, step 102 checks whether the (optionally specified) output token reference TRAU or the (optionally specified) output token references are stored in storage unit 1 of the TRR.

[0133] If step 102 is answered "yes," in step 108 a validity confirmation GB is sent to the TE 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 executed the MA with this TRA in the past. Optionally, a TRR signature is created 106 beforehand for the (specified) output token reference(s), in this case TRA12. If step 102 is answered "no," the TRR sends 109 an invalidation confirmation UGB for the (specified) output token reference(s) of the MA.

[0134] If step 103 is answered 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 and the MA's output token references are saved in step 105.

[0135] The method shown in Fig. 3c first checks 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 is not executable, it checks whether the (specified) TRA of the GA is already stored. The method shown in Figure 3c also reduces the complexity of the validity check.

[0136] Fig. 4a shows a second embodiment of a validity request GA according to the invention. This GA comprises two or more modification requests MA (MAi, MA2, . . . MA XEach MA comprises (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 can be more or fewer. Examples of the typical number of input and output token references TR per specific command KO are listed later. Optional signatures of the MA are not shown separately here.

[0137] The MAs of the GA are verified individually. Preferably, the most recent MA, Max, is verified first. Generally, MAs of the GA are optionally verified until either a GB or a UGB can be sent for the GA. In some cases, all MAs of the GA can be checked and executed sequentially before a GB is sent. However, in some cases, a GB for the GA can also be sent without checking a single MA (as shown in Fig. 4b, for example, in the special case: TRAIJ = TRAIJ).

[0138] The GA modification requests MA can be present as a batch or as a sequence of modification requests MA.

[0139] In the case of a sequence of MAs, the MAs will essentially specify temporally consecutive modifications to tokens. At least one output token reference of an MA in the sequence will be the input token reference of another MA in the sequence. Preferably, two or more consecutive MAs, for example, MAx.i and MA X, the GA is an input token reference, which is the output token reference of a previous MA of the GA. Accordingly, the modification requests MA of the GA are in the order MAi . . . MA X in the form in which they are presented in the GA. MA X is the most recent MA and represents the last modification to a token.

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

[0141] As an optional check specification 43, the validity request 40 shown includes one or more output token references TRAij (j-th output token reference of the i-th modification specification) to be checked for validity. The specified output token reference(s) TRAij may be one, several, or no output token reference of the last modification specification (MA X ) of the GA, even in the case of a sequence. In particular, the check specification may include two or more output token references TRAij of the GA from different MAs, such as TRA21 and TRAXI. Furthermore, the check specification may not include two or more output token references TRAIJ of the GA, preferably from different MAs, such as TRAII, TRA22, and / or TRAX2.

[0142] Fig. 4b shows a first embodiment of a method for checking the validity of at least one token T based on a validity request GA with multiple MAs, 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 explanations in Fig. 3b.

[0143] The method according to Fig. 4b comprises a loop 141, 142 for the modification requests MA of the GA (with loop index i=1 to x for MAi). Starting with the first MA of the GA, MAi, a check is made 102 to determine 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 valid TRs). If so, 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 TRs of the GA are to be checked for validity. In the example shown in Fig. 4b, however, the loop 141, 142, including steps 102-106 (and 146), is repeated for each MA, MAi. . . MA X , the GA passed.

[0144] Output token references TRAIJ already saved according to step 102 or saved in step 105 can be temporarily stored in the loop as TRA of the GA that have been recognized as valid or have already been signed. Optionally, in step 146 it is also temporarily stored that the specified TRAIJ of the MAi or the output token reference(s) 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 invalidity confirmation can be sent 109. Optionally, a partial validity confirmation TGB can be (created and) sent 148, provided that not all but at least one questionable output token reference 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 orthe valid output token references TRAij to be checked for validity.

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

[0146] Fig. 4c shows a further embodiment of a method for checking the validity of a token T based on a validity request GA with multiple MAs, 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 step sequence 104, 103, 102, 105, 106), and in this regard, reference is made to the explanations in Fig. 3c.

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

[0148] With the method according to Figs. 4b and 4c, stacks of modification information MA are preferably checked. The modification information contains independent token references. Fig. 5a shows a third embodiment of a validity request GA according to the invention. The GA comprises several modification information MAi, MA2, . . . MA X The modification details of the GA are interdependent. The GA therefore comprises a sequence of

[0149] Modification information, some of which has already been described in more detail above.

[0150] In the example shown, the output token reference TRAII of MAi is a

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

[0152] Fig. 5b shows a first embodiment of a method for checking the validity of a token T based on a validity request GA with several, preferably mutually dependent, MA - in particular according to Fig. 5a.

[0153] The GA is received 101, and in step 102, a check is made to determine whether the token references TRAIJ to be validated are stored as valid TRs in the TRR, specifically whether they are present in the TRR's storage unit 1, which contains only valid TRs. If the specified output token references TRA21 and TRAX2 are already stored, the validity confirmation GB can be sent 108—optionally after creating the signatures 106 as cryptographic confirmation of the TRR for the valid TRs. In this case, none of the MAs of the GA are checked (for errors and / or executability).

[0154] In a loop 153a -c the x modification specifications MA of the sequence are checked one after the other

[0155] 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 memory unit 1 of the TRR, i.e., are valid. If not, an invalidation confirmation UGB is sent 109. Likewise, in the (yes) case of step

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

[0157] If step 104 is "no," the MA is not yet actually executed, since the method is directed toward a sequence whose token references are interdependent. 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 occurs in step 155. 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 temporarily stored output token references will be input token references of another MA of the GA (and would therefore have to be deleted again). They are then simply removed from the verification unit's buffer. Unnecessary write access (or multiple unnecessary write or delete accesses) to storage unit 1 can thus be avoided.Only in step 155 are the buffered (and not deleted) output token references written to the memory unit. Step 155 can also be referred to as selectively storing the entire output token references of the sequence. In the example in Fig. 5b, the output token references are TRA21 TRAXI TRA. X 2 and the input token references TREH TREI2 TRE21 are deleted. After that, the validity confirmation for the output token references TRA2I,TRA X 2 be sent.

[0158] Fig. 5b shows optional steps 151 and 152 that prevent previously executed modification statements MA from falsely leading to an invalidation confirmation UGB in the sequence of MA of the GA. If it is determined in step 102 or 151 that a TRAnj is already stored, this TR is signed in step 152 and the loop index is set to i = n + 1. The modification statement MA nhas already been executed. The processing of the sequence of modification specifications can therefore be continued with the subsequent modification specification MA n +i. In embodiments not shown, the sequence of MAs can be evaluated to identify sub-branches of the sequence and to consider them as such when processing the sequence.

[0159] Fig. 5c shows a further embodiment of a method for checking the validity of a token T using a validity request GA with several MA, in particular according to Fig. 5a or a GA with a sequence of MA.

[0160] For the GA received in step 101, all modification information MAi to MA XThe GA is checked for errors. If the MA contains an error (no case of step 164b), a check is carried out to determine whether the specified output token references TRAIJ of the GA have all already been saved 102. Depending on the case, the UGB is sent 109 or – after optional signing 106 of the TRAIJ – the validity confirmation GB is sent 108.

[0161] If step 164b is "yes," all TRs of the GA are read 162 from storage unit 1 (checking whether all TRs have already been 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, all output token references of the sequence are selectively stored, and the input token references (if still stored) are deleted. The procedure according to Fig. 5c also leads to optimized processing of the GA with a sequence (or a stack).

[0162] After checking the GA of Fig. 3a to 5c or the RA according to Fig. 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.

[0163] 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 is not synonymous with the TE being in possession of the token T. The token reference TR serves to prevent multiple spend attempts. It checks whether token values ​​v were generated in an impermissible manner. Therefore, the token reference TR and, if applicable, 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).

[0164] The tokens T are stored, for example, in token storage 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 integrated and ready for use. A wallet can be set up as an application on a smartphone, a smart card, or a payment terminal. The wallet is used to securely manage tokens T of the TE, generate token references TR, modify tokens T, exchange tokens T, and / or initiate the verification of token validity. Wallets are used to communicate with the token reference register TRR, generate registration requests RA for modifications of the token T to the token reference register TRR, carry out transactions from token T to a transaction unit TE, and / or generate validity requests GA.

[0165] For a transaction with a transaction unit TE, it is not necessary for a communication connection to the token reference register TRR of the transaction system TS to exist. The transaction system TS is configured to execute a transaction offline, i.e., without a communication connection to the token reference register TRR. A corresponding registration of token T can therefore be performed after a transfer of token T to a 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.

[0166] 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 whose validity is to be checked. The validity request GA also includes a modification specification for one or more modifications to the token T.

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

[0168] 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, further increasing the security of the transaction system TS.

[0169] 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 the validity request GA is checked by the token reference register TRR (or its verification unit2), the transaction unit TE is informed whether the token T is valid or not.

[0170] A validity request GA is preferably signed with the private part r. The signature allows the recipient (TRR or TE) to easily verify the syntactical authenticity of the command. This verification is preferably performed in database 1 or verification unit 2. Furthermore, a validity request GA can be syntactically validated, for example, by checking the signature and / or the token reference TR.

[0171] Even if a signature can be verified in a transaction unit (TE), this does not guarantee that multiple issuance of the same token (T) has not been attempted. Therefore, registration in the token reference register (TRR) is required. Furthermore, the transaction units (TE) 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 (stored).

[0172] The token reference register TRR can also contain an archiving unit (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.

[0173] The following modifications to an existing token T can be present as KO commands: for example, "Switch", "Split" or "Merge". KO commands reserved for the token issuer can also concern the creation (=Create) of a token T or the deletion (=Destroy) of an existing token T. In theory, another command type for checking the validity of an unmodified token T was also known in the TRR. The following table provides example command codings (0x01 to 0x05). The coding shown here and the order of the data elements in the MA used in the figures are interchangeable or only exemplary.

[0174] The following table provides examples of conceivable signature syntax. Input tokens T and input token references TR are specified for each command ("consumed"). Output tokens T and output token references TR are specified for each command ("generated").

[0175] A modification statement (for example, 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).

[0176] Each KO command has a partially characteristic number (one or more) of input token reference(s) ("inputs") and output token reference(s) ("outputs"). For example, a switch preferably has exactly one input token reference and exactly one output token reference. A split has exactly one (or more) input token references and at least two (or more) output token references. A join has at least two (or more) input token references and exactly one (or more) output token reference(s).

[0177] Fig. 6 shows a further embodiment of a token reference register TRR of a transaction system TS. It is indicated that several memory units 1 can be provided in the token reference register TRR in order to store a

[0178] Fig. 6 shows a further embodiment of a token reference register TRR of a transaction system TS. It is indicated here that multiple storage units 1 can be provided in the token reference register TRR in order to accelerate the storage of a large number of token references TR. It is also indicated here that multiple verification units 2 can be provided in the token reference register TRR in order to accelerate the verification of validity requests GA and / or registration requests RA. Furthermore, a transaction unit of a bank TEB is shown, which can serve as an interface between the transaction system TS and a book money system (lending, account management). It can enable transaction units TE to transfer tokens T of the transaction system TS to another transaction system TS. This transfer is possible bidirectionally.The token issuer TH is solely responsible for the generation of token T and also the deletion of token T in the TS.

[0179] In addition, Fig. 6 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.

[0180] The TRR further contains an archive unit 5 in which already executed RA and / or GA and / or no longer valid token references are stored, in particular as a linked graph.

[0181] Transaction units (TE) can send their RA and / or GA to the TRR via a first interface (3) of the TRR. Only the token issuer (TH), however, is permitted to send commands to the TRR via the second interface (4) of the TRR.

[0182] It can be advantageous if only one (or a few) tokens T are used per transaction unit TE (here as a secure element, e.g., smart card or TEE). This means that the TE combines a received token T with the token T stored in the token memory (MERGE). This also means that the TE splits a token T to be sent from the token T stored in the token memory (SPLIT). These modifications to the token T can be performed without a registration request RA or a validity request GA, and the token T can be passed on immediately after a modification. This can result in a sequence of modifications to the token T that are unknown to the TRR. Typically, the sequence of modification details MA consists of a combination of SPLIT and MERGE modifications. Each of these modifications is also referred to as a "proof" (see Fig. 1 above) or is stored with the token T as a preferably signed modification detail MA.This creates the sequence of modification specifications MAp or MAi, MA2, ... MA in the TE1 for the token T. X .

[0183] According to the invention, a validity request (GA) is provided to check the validity of a token. The terminal device receives the GA and / or the MA or MAF for this purpose. Alternatively or additionally, a registration request unit (RAE) can also be provided as an intermediary 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 device. A GA is sent to the TRR.

[0184] The terminal device (not shown in Fig. 6) or the RAE attempts to transmit the GA to the TRR. This means that the terminal device or the RAE only performs a protocol translation, for example, from APDU between the terminal device / RAE and the TE to HTTP(S). The GA and / or the MA or MAF are neither evaluated nor interpreted by the terminal device or the RAE. The order of the modification information in a GA of a sequence of MAFs is not changed by the terminal device or the RAE. A validity confirmation GB (or a registration confirmation RB) of the TRR is then transmitted from the terminal device 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 stored in the TE (in the token memory) is sometimes referred to as a proof.

[0185] The verification unit 2 of the TRR checks the validity, in particular using a method according to Fig. 3b to 5c. A GB is sent back to the secure element or the TE (if necessary via the RAE or the terminal).

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

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

[0188] Switch: C - D (Token C was switched to Token D)

[0189] Token D is transferred to TE2 with the two modifications (proofs) "Split" and "Switch." TE2 also performs:

[0190] Merge: D, E - F (Tokens D and E are combined to form token F)

[0191] Validation of token F: Only token F is to be checked for validity. For this purpose, a GA is generated and the token reference of token F (as a verification specification) together with the modification specifications MA consisting of the three modifications (proofs) "Split", "Switch", and "Merge" is sent from TE2 to the TRR as a GA. According to the GA, which only specifies token F via its token reference as the token to be checked, the output token reference TRB of the first MA of the GAs does not need to be checked or is not checked for validity by the TRR. In this case, the first two modification specifications of the GA are only executed optionally, for example, if TE1 (or another TE) has not yet sent an RA or GA with these two MAs to the TRR.

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

[0193] 200: Token is valid, all modifications of the modification specification could be resolved

[0194] 400: Token is valid, some modifications of the modification specification could not be resolved 500: Internal error

[0195] 600: Token is invalid.

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

[0197] LIST OF REFERENCE SYMBOLS

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

[0199] PKey RR public part of the verifier key pair pKey RR private part of the verifier key pair

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

[0201] GA validity request

[0202] GAsig T Validation request signed with private part of the token-individual

[0203] Key pair

[0204] GB Validation Confirmation

[0205] UGB invalidity confirmation

[0206] GB sig TRR Validation confirmation signed with private part of the token reference register-

[0207] Key pair

[0208] RA registration request

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

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

[0211] MA modification information

[0212] RAE Registration Request Unit

[0213] RB registration response, registration confirmation

[0214] T Token

[0215] TE transaction unit

[0216] TEB Transaction Unit Bank

[0217] TE layer Direct action layer

[0218] TRR layer register layer

[0219] TH Token Issuer

[0220] TR X Token reference of the GA

[0221] TRE input token reference

[0222] TRA output token reference

[0223] KO command, modification command

[0224] TRR Token Reference Register

[0225] TS transaction system v, TW token value ah indices for various tokens and token references

[0226] S Total token value of the transaction system

[0227] 1 database, storage unit

[0228] 2 Verification unit

[0229] 11-19 Process steps in the state of the art

[0230] 3 Subscriber interface / MA receiver unit

[0231] 4 Publisher interface / new registration unit

[0232] 5 MA archiving unit

[0233] 6 Total sum check unit 30 Validation request

[0234] 31 Modification information

[0235] 32 Signature of the modification information

[0236] 33,43,53 Examination information

[0237] 40 Validation request for batch of MA

[0238] 50 Validation request for sequence of MA

[0239] 101 Receive GA

[0240] 102 Check if TRA is saved

[0241] 103 Check if TRE is saved

[0242] 104 Check employees for errors

[0243] 105 Save TRA

[0244] 106 Create Signature

[0245] 108 Send Validation Confirmation

[0246] 109 Send invalidation confirmation

[0247] 141,142 Processing loop for MAi

[0248] 146 Invalidity for TRA note

[0249] 107 Check whether overall validity has been established

[0250] 147 Check whether partial validity has been established

[0251] 148 Send partial validity confirmation

[0252] 151 Check if a TRAÜ is saved

[0253] 152 Signing the TRAÜ

[0254] 153a, 153b, 153c Processing loop for MAi

[0255] 155 Selective storage for TRA of the MA sequence

[0256] 164a Verifying the MA sequence

[0257] 164b Check if sequence is verified

[0258] 165 Selective storage for TRA of the MA sequence

Claims

Patent claims 1. A secure element of an electronic transaction system (TS), wherein the secure element has a token memory for tokens (T) of the transaction system (TS); wherein the secure element is configured 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 configured 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 indication (MA), which comprises at least one input token reference (TRE), a command (KO) and at least one output token reference (TRA), for the token reference register (TRR), characterized in that the secure element is configured to provide the at least one modification indication (MA) as a validity request (GA), and the secure element is configured to receive a validity confirmation for at least one output token reference (TRAIJ) of the validity request (GA) to be checked for validity.; 2. Secure element according to claim 1, characterized in that the validity request comprises the at least one output token reference to be checked (TRAIJ) 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 comprises, in addition to the modification indication (MA), a check indication (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 arranged 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 validity confirmation for each output token reference (TRAIJ) to be checked is a separate cryptographic confirmation, which is preferably stored in the secure element; or the validity confirmation 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 a plurality of modification information (MA), in particular a stack and / or a sequence of modification information.

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) as data elements include a token value (v) and a public token element (R).

8. A method for checking the validity of a token (T) of a secure electronic transaction system (TS), wherein each token (T) of the transaction system is uniquely assigned a token reference (TR), wherein a token reference register (TRR) of the transaction system (TS) comprises 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) comprising a modification indication (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 as to whether it is stored in the storage unit (1); and - Sending (108) a validity confirmation (GB) for the at least one output token reference (TRAij) to be checked; wherein the validity request (GA) comprises the modification information (MA; MAI) to be processed only optionally and / or a check 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 following sub-steps: - checking (103) whether the at least one input token reference (TRE) is stored in the memory 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 memory unit (1) and in particular by deleting an input token reference in the memory 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 are not to 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 one of claims 8 to 10, wherein the validity request (GA) comprises a plurality of modification information (MAI, MA2, ... MAx), wherein each modification information (MA) comprises 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), wherein in particular stacks consist of independent modification information (MA) or sequences comprise at least partially mutually dependent modification information (MA).

12. The method according to one of claims 8 to 11, wherein the verification unit (2) sends a common memory query to the memory 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 stack of modification information (MA); and / or for a sequence of modification information, at least one output token reference of a modification information (MA) is only buffered internally and / or is only stored in the storage unit (1) after checking one, several or all further modification information (MA) of the sequence.

14. The method according to any one of claims 8 to 13, wherein the token reference register (TRR) executes the method with a transaction unit TE or the secure element according to any one of claims 1 to 7 and / or the token reference register (TRR) further comprises: - further verification units (2) and / or a - Archive unit (5), which stores token references that are no longer valid and / or validity requests (GA) and / or registration requests (RA) that have already been executed.

15. A token reference register (TRR) for a transaction system (TS), configured 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) configured 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 claim 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 any one of claims 1 to 7.

Images