Secure element, method for depositing token 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 method in a token reference register and to a token reference register. The secure element comprises a token memory for tokens of the transaction system and is arranged as a transaction unit in order to exchange the tokens of the transaction system directly with other transaction units of the transaction system. Each token (T) of the transaction system (TS) is explicitly configured with a token reference (TR), which can be deposited in a token reference register (TRR) of the transaction system (TS). The security element is configured to generate at least one output token and an output token reference (TRA) thereof from at least one input token. The secure element provides a modification specification for a token reference register (TRR), the modification specification having an input token reference (TRE), an instruction (KO) and an output token reference (TRA). In this case, the secure element provides at least one modification specification (MA) as a validity request (GA). Furthermore, the security element is configured to receive a validity confirmation (GB) for at least one output token reference requiring a validity check for the validity request (GA).

Description

[0001] The invention relates to a method for registering a token, in particular a security element as a transaction unit, a security element and a token reference register, in which a token reference is stored, and a transaction system as a whole. The token reference is uniquely assigned to the token.

[0002] As is known, the use of secure elements such as chip cards, SIM modules, etc. as transaction units allows for secure direct transmission between transaction units, which excludes the possibility of intentional multiple issuance of tokens - also known as double spending.

[0003] For example, DE 10 2009 038 645 A1 and DE 10 2009 034 436 A1 disclose systems or portable data carriers as security elements for transferring monetary values ​​in the form of electronic data sets, wherein payment with copies of the data sets is prevented and a high level of security against manipulation is achieved. This requires a complex structure and complex encryption and signing processes for the transaction.

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

[0005] As solutions for secure hardware systems, token-based systems and account-based systems are usually distinguished. In addition to traditional account-based systems, such as deposit accounts or credit accounts, more recent account-based systems based on blockchain topologies are also being discussed. Here, account-oriented units each have access to a data set representing a monetary value. Although more recent account-based systems offer greater protection of integrity, they also disclose a lot of information, for example if the data set is present in a freely readable data structure and the owner changes there.

[0006] It is also known to expand token-based transaction systems with token registers. The security element sends a registration request for its token to the register. The register verifies the registration request and, for example, only stores a token reference for the token, and therefore does not know the token itself.

[0007] WO 2020 / 212337 A1 describes a trading system in which it is even possible to modify a token securely without a connection, i.e. directly between the security elements of the trading system and without the need for other checking mechanisms, for example by splitting the token. Once acquired in the security element or the participant unit, the token can be transferred further immediately without registering the modification in the token register of the trading system. The registration of the modification in the token register can be performed independently of the actual transaction, i.e. the transfer of the token. However, the resources of the security element, in particular in terms of storage space, processing speed, transmission time and / or transmission speed, are known to be limited.

[0008] The technical problem to be solved by the present invention is to provide a new method which is better suited as a security element for a transaction unit and which is in particular resource-saving. The processes in the transaction system, such as the direct transfer of tokens between the transaction units and the storage of tokens in a register, as well as the associated advantages and possibilities of use, should preferably remain unchanged. In particular, multiple modification specifications of the transaction unit should also be processed in a resource-saving manner.

[0009] This object is achieved according to the invention by the features described in the independent claim. Further advantageous embodiments are described in the corresponding dependent claims.

[0010] The security element of the electronic trading system has a token memory for tokens of the trading system and is configured to directly exchange tokens with other trading units of the trading system. Each token of the trading system is explicitly assigned a token reference. The token reference (and therefore the associated token) can be stored in a token reference register (Tokenreferenz-Register) of the trading system. In addition, the security element is configured to generate at least one output token and its output token reference from at least one input token. The security element provides at least one modification description for the token reference register, which includes at least one input token reference, instructions and at least one output token reference.

[0011] The secure element provides at least one modification specification as a validity request and receives a validity confirmation of at least one output token reference to be checked for validity in the validity request.

[0012] Sending the modification information in the validity request enables a number of initially seemingly small improvements which, in total, can at the latest help the security element and even the token reference register, as explained in more detail below. Since the token reference register can process the validity request with the (only optional) modification information faster on average than a conventional registration request, the connection or transmission time is already reduced and the effort for managing, in particular maintaining (Timeouts ...) or re-establishing the connection in the security element is therefore reduced.

[0013] The validity request may preferably include at least one output token reference that needs to be checked and at least one output token reference that does not need to be checked. Therefore, it is not necessary to check the validity of all output token references.

[0014] The validity request may include modification instructions and additionally include a check instruction that specifies at least one (or more) output token references to be checked. The check instruction may, for example, contain an output token reference, contain a reference to an output token reference or may also be encoded by an identifier set for one (or more) output token references. An identifier is usually a binary digit that is set or not set. For each output token reference of the validity request or modification instruction, for example, an identifier may be provided, which identifier may be set or not set. Particularly preferably, the check instruction relates to the output token references of at least two different modification instructions of the validity request.

[0015] Particularly advantageously for a token reference register, the security element can be configured to provide the modification description as a validity request or as a registration request. As selection criteria for sending as a validity request, the security element can use, for example:

[0016] - the number of modification instructions stored in the security element, in particular starting from more than two modification instructions, and / or

[0017] - a time standard, in particular by means of a timestamp, for example of a transaction and / or modification or of the last communication with a token reference register, and / or

[0018] - Origin criteria, for example if the modification information was received, in particular, from another trading unit.

[0019] However, this selection by the security element is not really necessary. As will be explained below, the security element can always send one (or more) modification instructions as a validity request.

[0020] In principle, it is conceivable to provide cryptographic security for the data exchange with the token reference register, including the validity request and the validity confirmation, ie encryption and / or signing. In particular, this makes it possible to detect a validity confirmation that has been tampered with by a third party.

[0021] It is particularly advantageous (and sufficient for the security of the validity request) if the validity confirmation includes a separate cryptographic confirmation, such as a checksum or a signature, for each output token reference that needs to be checked. It can also be advantageous if the validity confirmation includes a common cryptographic confirmation, such as a checksum or a signature, for all output token references that need to be checked (or only for output token references that need to be checked). The cryptographic confirmation for the output token references that need to be checked is preferably stored in the security element and / or transferred to other transaction units together with the associated token.

[0022] The validity request may include a plurality of modification instructions, in particular a stack of modification instructions and / or at least one series of modification instructions. Modification instructions that are independent of each other (in terms of their token references) are referred to herein as a stack. Modification instructions in a stack can be processed in any order in the token reference register. Conversely, modification instructions that are related to each other (in terms of their token references) are referred to as a series (or sequence). At least one output token reference of a modification instruction is also an input token reference of other modification instructions. Preferably, a series includes a plurality of output token references, which are also input token references of the following modification instructions in the series. The modification instructions of a series cannot be processed in any order in the token reference register. The token reference register executes the modification instructions of the series in particular in the order in which the modification instructions are present in the validity request or the order is preset in the validity request. The series can be constructed in particular with or without branches, for example "MA1=>MA2=>...=>MAn" or "(MA1,MA2)=>MA3...(MA4,MA5)=>MA6...".

[0023] In particular, the modification statement of the validity request can only be executed optionally. In the case of one (or more) faulty modification statements, the token reference register itself can send a validity confirmation. Whether the token reference register checks and, if necessary, executes the modification statement and / or which modification statements have been checked and executed is independent of the validity confirmation for at least one (or more) output token references to be checked.

[0024] For a token reference register that stores only valid token references in a memory unit for token references, a validity request may be a request to check whether an output token reference that needs to be checked is already stored in the memory unit.

[0025] The security element typically comprises a processor, in particular a processor for executing steps as a transaction unit, and / or comprises an interface, in particular an interface with a local terminal device, via which a validity request is provided for the token reference register (TRR). A transaction unit can be a participant unit or in the following part also referred to as a participant unit.

[0026] The token or each token may comprise in particular a token value and a secret token element as data elements, the secret token element being in particular a private key of a key pair. A token reference may comprise as data elements a token value, in particular a token value of the token, and a public token element, in particular a public key of a token key pair.

[0027] The modification is in particular the splitting and / or combining or switching of tokens. The instruction for the modification description is correspondingly, for example, "split", "combine" or "switch". One (or more) input tokens with a (total) token value can be split into multiple 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 a total value. Input tokens with a token value can be switched to output tokens with the same token value.

[0028] The transaction unit, ie for example the secure element, can generate one (or more) output tokens, in particular including a token value and a secret token element, as well as an associated output token reference for modification instructions.

[0029] The transaction unit, ie, for example, a secure element, stores its token and optionally one or more modification instructions. The modification instructions are stored together with the output token or at least stored in association with the output token.

[0030] The secure element can preferably delete the modification information contained in the validity request and stored in the secure element in response to receiving the validity confirmation.

[0031] Tokens can be exchanged directly with other trading units. For tokens that have not been deposited, the tokens must be transferred together with the modification instructions. Tokens that have been deposited can be transferred without modification instructions.

[0032] A method for checking the validity of a token of a secure electronic transaction system is provided. Each token of the transaction system is explicitly assigned a token reference. A token reference register of the transaction system comprises a verification unit and a memory unit in which a token reference of a valid token is stored. The following steps are performed in the token reference register:

[0033] - receiving a validity request, the validity request comprising a modification specification having at least one input token reference, at least one output token reference and an instruction;

[0034] - checking whether at least one output token reference of the validity request that needs to be checked for validity is stored in the memory unit; and

[0035] - Send a validity confirmation for at least one output token reference that needs to be checked.

[0036] A validity request may include a check specification that specifies at least one output token reference that needs to be checked, and / or a modification specification that only optionally needs to be processed.

[0037] The checking (and optionally the receiving and sending) is preferably performed by a verification unit of the token reference register. The receiving and sending may be performed by an interface unit of the token reference register.

[0038] Preferably, the verification unit processes the modification specification, optionally also the modification specification of the validity request, by one or more sub-steps:

[0039] - checking whether at least one input token reference is stored in the memory unit; and / or

[0040] - verifying the modification statement, in particular the signature(s) in the modification statement and / or the value neutrality of the modification statement and / or the syntax of the modification statement; and / or

[0041] - executing instructions (or modifying instructions) by storing output token references in memory units and in particular by deleting input token references in memory units.

[0042] In an advantageous embodiment, if the output token reference to be checked of the validity request is already stored in the memory unit, the validity confirmation is sent, in particular without further processing of the modification description. Otherwise, the processing of the modification description is carried out. Alternatively or in addition, the validity confirmation can be sent after the processing of (one or more) modification descriptions that are only optionally to be processed has been omitted in its entirety or in part of the steps, i.e. after no part of the steps or not all part of the steps have been carried out.

[0043] The validity request preferably includes at least one, more preferably multiple, output token references that do not need to be checked for validity. The validity confirmation (GB) may include a separate cryptographic confirmation, such as a signature or checksum, for each output token reference that needs to be checked.

[0044] The output token reference to be checked for validity does not have to be explicitly indicated in the check description of the validity request. It can be one of the output token references contained in the modification description. However, the token reference to be checked in the check description is preferably received from the token reference register as a separate data element of the validity request. The check description can be formed by one (or more) references to the output token references to be checked (such as the position or number of the output token reference in the validity request), or contain the output token reference.

[0045] The validity request may include a plurality of modification specifications, wherein each modification specification includes one or more input token references, one or more output token references and instructions. The modification specification is preferably a stack of modification specifications and / or a series of modification specifications. A stack consists of unrelated modification specifications. A series consists of modification specifications that are at least partially related to each other.

[0046] The token to be checked can be transferred directly between two trading units of the trading system in the direct trading layer of the trading system (but need not have been transferred). The token to be checked is preferably modified in the trading unit, but the token has not been deposited in the trading system.

[0047] If some of the multiple modification specifications cannot be executed (i.e. the configuration of the token reference with the token of the trading system is partially not feasible), in particular if these modifications are only implemented at the direct trading level without registering the modifications in the token reference register, then preferably also a validity confirmation is sent. Therefore, a prerequisite for the validity check is not that all modification specifications of the validity request can be understood or executed by the verification unit. Only the configuration (or allocation) of at least one token reference to be checked must be verifiable. Therefore, the verification is independent of the registration of one or more modifications of the modification specifications in the token reference register.

[0048] The verification unit of the token reference register can send a storage request (or query) and / or a storage instruction to the memory unit of the token reference register. The verification unit can thereby, for example, query whether a token reference is stored in the memory unit and / or instruct to store or delete a token reference. For output token references of different modification specifications and / or for output token references and input token references of at least one modification specification, the verification unit sends a common storage request to the memory unit.

[0049] In particular, for a stack of modification specifications in a validity request, the token reference register may send a partial validity confirmation. The partial validity confirmation preferably relates to a valid output token reference of the stack whose output token reference needs to be checked for validity.

[0050] For a series of modification specifications in a validity request, the verification unit may only store at least one (or more) output token reference of at least one modification specification internally (i.e. not in the memory unit). If the intermediately stored output token reference is an input token reference of the next modification specification, this output token reference is discarded, otherwise the intermediately stored output token reference is stored in the memory unit. At least one (or more) output token reference of a modification specification is stored in the memory unit only after checking one, more or all modification specifications of the series.

[0051] The token reference register may be used to execute the method via a transaction unit or via a secure element as already described.

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

[0053] The token reference register for the transaction system is provided for carrying out the above-described method, in particular by means of a transaction unit TE of the transaction system or by means of the above-described secure element.

[0054] The token reference register comprises a memory unit for storing a valid token reference in a transaction system, an interface arranged for receiving a validity request and at least one verification unit.

[0055] The transaction system includes a register layer having a token reference register; and a direct transaction layer having a plurality of transaction units, including a security element.

[0056] Validity requests in the trading system can be distributed to different verification units of the token reference register, and thus these validity requests can be processed in parallel by different verification units of the token reference register. Thus, a large number of validity requests can be distributed to different verification units within the token reference register ("load balancing").

[0057] The validity confirmation and / or the valid output token reference to be checked is preferably signed with the private part of the key pair of the token reference register, preferably of a verification unit (possibly one of several verification units). Upon receipt of the validity confirmation, the signature is verified by the transaction unit with the public part of the key pair of the token reference register. This increases security, since validity confirmations generated by unauthorized third parties (e.g. within the scope of a man-in-the-middle attack) are recognized by the transaction unit as missing or invalid signatures. The transaction unit can then ignore these validity confirmations.

[0058] A token is a data set of a transaction system that can be exchanged directly between transaction units. With knowledge (or recognition) of the token, the receiving transaction unit has the token value represented by the token. Therefore, the token automatically changes hands when it is exchanged. A token is a data set that can be transmitted independently of the transaction topology, such as the blockchain topology. The token can be transmitted directly between transaction units without the need for an intermediate connecting unit.

[0059] In one design, the token is an electronic coin data set or a payment token to exchange monetary value between transaction units. In layman's terms, such a payment token is also called a "digital coin" or "electronic coin", which represents cash in electronic form.

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

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

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

[0063] The token is formed by a token value (first token element) and a private part. The formation is preferably a concatenation (concatenation) of the two token elements. Any other combination of the two token elements is not excluded according to the invention and includes, for example, adding them together in sequence, inserting them into a TLV data structure and / or combining them logically.

[0064] Anyone who owns a token or has unrestricted access to a token and its token elements can exchange said token with another trading unit. Therefore, owning a token and at least two of its token elements (the token value and the private part of a token-specific key pair) is equivalent to owning the value represented by the token.

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

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

[0067] Each token reference in the transaction system is a data set consisting of at least two token reference elements.

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

[0069] The second token element of each token reference of the trading system is the public part of the token-specific key pair. The public part of the token reference and the private part of the token together form the token-specific key pair. The public part is obtained by applying a cryptographic function to the private part.

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

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

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

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

[0074] The token reference can preferably be generated by the electronic wallet (=Wallet) of the transaction unit. For this purpose, the transaction unit must know the token and its token elements. The token reference can be generated by the electronic wallet of the transaction unit that wishes to send the token. Alternatively, the token reference can be generated by the electronic wallet of the transaction unit that receives the token.

[0075] The use of token references differs from the use of transaction unit addresses in blockchain-based transaction systems, as transaction unit addresses are not used in the token reference register according to the present invention to prevent traceability of tokens.

[0076] The token reference register is a unit of the transaction register that stores token references, thereby registering a token as a valid token. The register may be a central database or a memory unit. The register may be a decentralized ledger. The token reference register may store token references and / or a history of registration requests and / or validity requests separately in an archive unit.

[0077] In the Token Reference Register, a token reference is stored only once. Since the token reference of a token exists only once in the transaction system, it is possible to determine through the verification step whether someone has attempted to issue a token more than once.

[0078] The token is stored in a token storage, which the transaction unit can exclusively access. The token storage may have a large number of tokens, for example, a large number of tokens may be stored in a data storage of the transaction unit. For example, the data storage may be internal, external or virtual. In one design, the "connection" may be automatically performed when a token is received, so preferably only one (or a certain number of) tokens are stored in the transaction unit.

[0079] For example, the transaction unit can be a mobile terminal device, such as a smartphone, tablet, computer, server or machine. The transaction unit can be a ready-to-run smart card inserted into the terminal device. The transaction unit is preferably a secure element.

[0080] The data storage is, for example, a wallet storage of an electronic wallet. For example, the electronic wallet is a software application executablely stored on the transaction unit. The electronic wallet can enable the transaction unit to participate in the transaction system. For example, the electronic wallet can generate a validity request to check the validity of the token. In addition, the electronic wallet can modify the token (switch, combine, split) and generate a possibly necessary validity request, which is sent to the token reference register. In addition, the electronic wallet can transfer the token to another wallet (in another transaction unit).

[0081] Transactions in the trading system are preferably atomic transactions.

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

[0083] The token reference register may be arranged to receive a plurality of validity requests, which are verified in parallel in a plurality of verification units to determine whether at least one token reference contained in a respectively received validity request is valid.

[0084] According to the present invention, a transaction system is provided, which has a register layer and a direct transaction layer. The register layer has a token reference register of the aforementioned type for storing token references and checking tokens through the token references. The direct transaction layer has multiple transaction units that are configured for direct exchange of tokens between each other.

[0085] Therefore, according to the invention, a two-tier transaction system is provided, which consists of a direct transaction layer for directly exchanging tokens and a register layer. In the register layer, transactions are not recorded, but only token references are stored, and modifications to tokens are stored via correspondingly adjusted token references to verify the validity of the tokens. This ensures the anonymity of the participants in the transaction system.

[0086] The memory unit of the token reference register preferably stores only token references of tokens that are valid in the transaction system. As soon as a token is modified and the corresponding (modified) token reference is also to be registered, the (old) token reference becomes invalid and (only) the modified token reference is stored in the memory unit.

[0087] In one embodiment, old (i.e. expired) token references are deleted from the storage unit and archived in a (token reference) archive. The token reference archive can be part of the archive unit, but can also be provided as a token reference register or as a separate unit in the transaction system. If all deposit requests are completely stored in the archive unit, the token reference archive can also be completely replaced by the archive unit. Time-dependent deletion of deposit requests can also be used to delete old token references.

[0088] According to the present invention, the transaction unit is preferably a security element in a secure electronic transaction system, which has: an interface, which is configured to: transfer or transmit a token to another transaction unit; create and send a request for checking the validity of the token to a token reference register according to one of the aforementioned designs; an access device to one or more token memories, wherein at least one transaction unit with modification instructions is stored in the token memory; and a computing unit, which is configured to: apply a cryptographic one-way function to the private part of the token-specific key pair of the token in the token memory to obtain a token reference; and modify the token.

[0089] Furthermore, the transaction unit has access means to a token memory and / or the transaction unit has a token memory, wherein at least one token of the transaction unit is stored together with the sequence of deposit requests in the token memory.

[0090] Furthermore, the transaction unit has a calculation 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 storage to obtain a token reference and to modify the token. Modification of the token includes, in particular, token splitting, token combining and / or token switching in the manner described above.

[0091] The transaction unit can be set up so that only one token is stored in its token storage. For direct transactions, this token is split (SPLIT) in order to produce the correct token value corresponding to the transaction to be carried out. If a token is received in the transaction unit, the received token is immediately merged (MERGE) with the token of the token storage.

[0092] In order to transfer the token to another transaction unit, the token of the token storage can be split (SPLIT), wherein a deposit request is generated for this purpose. The deposit request preferably has a token reference of the token to be split and a token reference of the split token in each case.

[0093] When a token is received from another transaction unit, the received token is combined with the token in the token storage, wherein a deposit request is generated for this purpose. The deposit request preferably has a token reference of the combined token and a token reference of the token to be combined.

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

[0095] The communication between the two transaction units for exchanging tokens can be wireless or wired, or for example by optical means, preferably by QR code or barcode communication, and can be designed as a secure channel. In addition, the exchange of tokens is securely ensured in transmission by cryptographic keys, such as the session keys negotiated for the token exchange or keys based on a transaction unit-specific key pair.

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

[0097] FIG1 shows an embodiment of a trading system according to the prior art;

[0098] FIG2a shows a registration request according to the prior art;

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

[0100] Figure 3a A first embodiment of a validity request according to the present invention is shown;

[0101] Figure 3b The invention is shown for use according to Figure 3a A first embodiment of a method for checking the validity of a token in a validity request;

[0102] Figure 3c The invention is shown for use according to Figure 3a A second embodiment of a method for checking the validity of a token in a validity request;

[0103] Figure 4a A second embodiment of a validity request according to the present invention is shown;

[0104] Figure 4b The invention is shown for use according to Figure 4a A first embodiment of a method for checking the validity of a token in a validity request;

[0105] Figure 4c The invention is shown for use according to Figure 4a A second embodiment of a method for checking the validity of a token in a validity request;

[0106] Figure 5a A third embodiment of a validity request according to the present invention is shown;

[0107] Figure 5b The invention is shown for use according to Figure 5a A first embodiment of a method for checking the validity of a token in a validity request;

[0108] FIG. 5c shows a method for Figure 5a A second embodiment of a method for checking the validity of a token in a validity request;

[0109] Figure 6A further embodiment of a transaction system according to the invention is shown, which has a token reference register.

[0110] FIG1 shows an embodiment of a trading system TS according to the prior art. The trading system TS comprises a register layer TRR layer, in which a token reference register TRR is arranged. The TS also comprises a direct trading layer TE layer, in which a plurality of trading units (or participant units) TE may be arranged; two trading units TE1, TE2 are shown by way of example. The trading units TE1, TE2 are preferably security elements.

[0111] The trading units TE of the trading system TS are arranged to exchange tokens T directly with each other. In FIG1 , the tokens are payment tokens, also called digital coins. Each token T is generated by a token issuer TH (not shown in FIG1 ). Each token T can be modified, i.e. split, combined or switched, by each trading unit TE and can be generated and deleted by the token issuer TH. For example, the token issuer TH is a central bank.

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

[0113] The random number r is the private part of the token-specific key pair. The random number r is one-time and secret in the trading system TS and cannot be made public or reused. The generation of the random number r must be unpredictable.

[0114] For example, the token value v is a 32-bit token element of integer type. For example, the random number r is a 32-byte token element of integer type. The transaction unit TE may have exclusive access to the token memory or include the token memory in a data memory of the transaction unit TE.

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

[0116] The public part R of the token-specific key pair is generated by applying a cryptographic function to the private part r of the token-specific key pair. This function is difficult to reverse and therefore provides the necessary security for the trading system TS. R=r*G applies, where G can be, for example, a global parameter of the trading system TS, such as a generator point of an elliptic curve, here a secp256r1 curve.

[0117] The token reference TR consists of the token value v of the token T and the public part R of the key pair. Therefore, the token reference TR is a link between the token value v and the public part R.

[0118] The token reference TR can be used together with the modification specification (see Figure 6 a and Figure 6 b) is sent as a registration request RA related to token T to the token reference register TRR. The modified token T and its token reference are registered in the token reference register TRR. In Figure 1, the transaction unit TE1 generates a new token T A , whose token reference is TR A should be stored in the token reference register TRR in place of the token reference TR of the old token TE with the same token value v E The deposit request can be made by the transaction unit TE1 and / or - after transferring the token T A After its modification instructions are transmitted to transaction unit TE2, it is sent by transaction unit TE2.

[0119] In FIG. 1 , firstly a known token reference register TRR is shown.

[0120] The token reference register TRR manages in particular the storage location of the token reference TR, which can optionally also store previous registration requests RA, and is here illustrated as a database 1 by way of example using a memory cell in the token reference register TRR. The token reference TR of the token T of the transaction unit TE1 is entered into the database 1 as an example. The database 1 can consist of a connection of a plurality of databases (see also Figure 6 ), these databases are interconnected.

[0121] Furthermore, the token reference register TRR comprises at least one verification unit 2. The verification unit 2 of the token reference register TRR verifies the registration request RA. The syntactic correctness or the correct description of the instructions in the registration request RA can be verified here. The history of old (past) registration requests RA can also be checked. The separation of the verification unit 2 from the database 1 distributes the tasks of storage and checking and increases the speed in the token reference register TRR.

[0122] As also shown in FIG. 1 , the token reference register TRR receives a registration request RA from the transaction unit TE11 and, if necessary, sends 18 a registration confirmation RB to the transaction unit.

[0123] An example of a deposit request RA according to the prior art is shown in FIG2a. The deposit request of FIG2a comprises two input token references TR E 、An output token reference TR A and a modification instruction KO.

[0124] The deposit request RA may additionally be signed with the private part r of a token-specific key pair (not shown). The signature may verify the identity of the token reference TR E Does the sender of own the input token T E , thereby further improving the security of the trading system TS.

[0125] FIG2 b shows a method flow of token deposit according to the prior art. In step 11, RA is received in TRR. In step 12, the input token of RA is checked against TRRR. E11 In the case of no in step 12, a check is made in step 16 whether the registration request RA has been executed and stored as part of the registration request history in the memory unit 1. In the case of yes, the registration is (re)confirmed 18. In the case of no in step 16, according to step 19, RA is not confirmed (error information).

[0126] If the answer in step 12 is yes, execute step 13. In step 13, check whether the input token reference TR of RA is stored in TRR. E12 .

[0127] If step 13 is yes, then step 14 is executed. In step 14, it is checked that the input token reference TR E12 and TR E11 Whether the instruction forms the output token of RA refers to TR A11 , for example, E11 +v E12 =v A11 , and the signature is valid. In step 14, the instruction is checked for errors in the same way.

[0128] If step 13 is no or step 14 is yes, RA is not confirmed (error message) according to step 19. If step 14 is no, in step 15, the TR of RA is stored in TRR. A11 In step 18, the transaction unit is confirmed that the deposit has been completed.

[0129] For transaction units TE1 and TE2, the token reference register TRR is preferably not readable. Of little practical significance but known in theory is that a transaction unit can query the status of a token, i.e. query in which state the token reference TR is stored in the token reference register TRR. However, such a status query is not a validity request in the sense of the present invention, which will now be described in detail.

[0130] The transaction units TE1, TE2 can send one or more existing modification instructions MA as validity requests to the token reference register, the modification instructions MA respectively connecting one (or more) output tokens with one (or more) input tokens by instructions. In particular, for the security element as a transaction unit, the burden reduction that can be achieved is helpful for its limited resources. In particular, in the security element, there may be multiple modification instructions (stack of modification instructions) for different tokens and / or multiple modification instructions (series of modification instructions) for one token.

[0131] The transaction unit TE1, TE2 sends a modification specification in a validity request for at least one token reference and receives a validity confirmation from a token reference register TRR for at least one requested token reference. The validity request comprises a plurality of output token references. The token reference register TRR may provide a signature for each requested token reference in the validity confirmation.

[0132] The token reference register TRR shown in Figure 1 is now also set up for verifying the validity request GA. For example, the verification unit 2 of the TRR is set up for this purpose. The verification unit 2 of the token reference register TRR then verifies the registration request RA and / or the validity request GA.

[0133] It is also possible to verify the history of old (past) validity requests GA related to the token T. However, the history is not required when processing the validity request GA. In this respect, the memory unit 1 of the TRR preferably contains only valid token references TR. The history of previously valid token references TR and / or executed modification instructions can be provided in a separate unit (archive unit). In the following, it is partially simplified to check whether the token reference is stored in the TRR, but here it is checked respectively whether the token reference is stored as a valid token reference or, in the case where it is assumed that the memory unit 1 only contains valid token references, whether the token reference is stored in the memory unit 1.

[0134] Figure 3a A first embodiment of a validity request GA according to the present invention is shown. Figure 3a The GA includes a (unique) modification specification MA. The MA includes the input token reference TR E11 ,TR E12 And the output token reference TR A11 TR A12 And the modification instruction KO. In the modification instruction MA, the output token reference TR A The number of input token references TRE is not limited and can be more (indicated by dots) or less. The following will illustrate the number of input and output token references TR for each specific modification instruction KO.

[0135] The modification specification MA may optionally include one or more signatures 32. In addition to the modification details 31, the modification specification MA also includes a signature of the modification specification. The signature 32 is preferably created by inputting the private part r of the token reference, for each input token reference TR of the modification specification MA. E11 ,TR E12 , in particular there may be a private part r E11 、r E12 Signature 32.

[0136] The validity request GA may optionally include a check specification 33. The check specification specifies one or more output token references whose validity needs to be checked. In the example shown, the output token references TR A12 For validity requests without explicit check instructions 33, the GA may, for example, check the validity of all output token references. The MA of the GA includes at least one output token reference TR that needs to be checked for validity. A12 and preferably one (or more) output tokens reference TR that do not need to be checked for validity A11 .

[0137] Figure 3b The invention is shown for use according to, for example, Figure 3a A first embodiment of a method for requesting a GA to check the validity of a token T. In step 101, the TRR receives the GA and optionally checks the MA of the GA in further steps 103-105.

[0138] In step 102, TRR checks the TR of MA A12 Whether it is stored in the TRR (specifically in its memory cell 1) as a valid token reference. A12 is the output token reference contained in the check statement 33 of the GA. In case of yes in step 102, in step 108, a validity confirmation GB is sent to the TE as a response to the GA. However, the MA of the GA is not checked further. The output token reference of the MA already exists in the TRR. The TRR must have executed the MA in the past.

[0139] Optionally, at least one signature of the TRR is created in step 106, in particular for a valid output token reference TR A12 The validity confirmation GB may contain or be formed from the TRR signature for a valid output token reference.

[0140] In case of a negative in step 102, the TRR checks (verifies) 103, 104 the modification specification MA and, if necessary, executes 105 the modification specification MA. In step 103, the TRR checks that each input token of the MA refers to the TR E11 and TR E12 Whether it is stored in TRR. If the input token of MA refers to TR E11 and TR E12 Stored in TRR (in the case of yes), TRR checks 104 whether the modification description MA has errors. For example, the syntax of the MA is checked, in particular the instruction KO (e.g.: unknown KO type or KO type of TH) and / or the number of input and output token references (e.g.: no output token reference / input token reference or too few). The value neutrality of the token reference value (total input value = total output value) and / or the signature 32 of the MA is checked.

[0141] If the verification 103, 104 of the MA is unsuccessful, an invalidity confirmation UGB is sent 109 for the GA. Unlike treating the MA as a registration request, it is no longer checked from the history whether the MA has been executed. In the case of no in step 103 and an error in the MA (yes in step 104), a UGB is sent in step 109.

[0142] If the verification 103, 104 of the MA is successful, the TRR executes 105 the modification specification MA and sends a validity confirmation GB for the GA in step 108. In step 105, the TRR deletes the input token reference TR E11 and TR E12 , and the output token of MA is referenced to TR A11 and TR A12 is stored in the TRR, or in the memory unit 1 of the TRR. Step 106 may also be optionally performed before step 108, that is, in this example, only the TR A12 Signature, and for TR A12 The signature of provides the GA of the TRR for the transaction unit TE in GB.

[0143] according to Figure 3b The method first checks the (specified) TR of the GA A Is it stored in TRR as a valid TR? A When invalid, check TR E and KO (i.e. verifying MA). This reduces the cost of validity checking. In addition, since MA is received in the validity request GA, the history record is no longer checked for MA.

[0144] Figure 3c The invention is shown for use according to Figure 3aA second embodiment of the method flow in which the validity request GA checks the validity of the token T.

[0145] In step 101, the TRR receives the GA and now first checks 104 whether the MA of the GA has errors (especially syntax, value neutrality and / or signature). In step 103, if the MA itself has no errors, the TRR checks the input tokens of the MA with reference to the TR E11 and TR E12 Whether it is stored in TRR. If the input token refers to TR E11 and TR E12 If it is stored in TRR (in the case of yes), the MA of the GA is executed at 105.

[0146] On the contrary, if the MA has an error (in the case of yes in step 104) or the input token reference of the MA is not stored in the TRR (in the case of no in step 103), step 102 is executed. In particular, if the MA cannot be verified, the (optionally specified) output token reference TR is checked in step 102. A12 Or whether multiple (optionally specified) output token references are stored in memory unit 1 of the TRR.

[0147] In the case of yes in step 102, as a response to GA, a validity confirmation GB is sent to TE in step 108. The specified output token reference is already stored in the TRR, in particular in its memory unit 1. The TRR has executed a transaction with this TR in the past. A The signature of the TRR is optionally created 106 before for the (specified) output token reference, here TRA12. However, in case of no in step 102, the TRR sends 109 an invalidity confirmation UGB for the (specified) output token reference of the MA.

[0148] In case of yes in step 103, the TRR executes the modification instruction KO of the MA in step 105 and then sends a validity confirmation 108. In step 105, the input token reference of the MA is deleted in the TRR, and the output token reference of the MA is stored.

[0149] according to Figure 3c The method first checks whether the MA has errors and / or TR E If not stored in TRR. Otherwise, even though GA's MA is not executable, GA's (specified) TR is checked. A Whether it has been stored.

[0150] according to Figure 3c This approach also reduces the cost of validity checking.

[0151] Figure 4aA second embodiment of a validity request GA according to the present invention is shown. The GA comprises two or more modification specifications MA (MA1, MA2, ... MA x ). Each MA includes (one or) multiple input token references TR E11 ,TR E12 and (one or) more output tokens reference TR A11 TR A12 And modification instruction KO. Modification instructions MA output token reference TR A The number and input tokens refer to TR E There is no limit to the number of, it can be more or less. Examples of typical numbers of input and output token references TR for each specific instruction KO will be listed later. The optional signature of MA is not shown separately here.

[0152] The MAs of the GA are verified individually. It is preferred to verify the latest MA first, i.e., Max. In general, the MAs of the GA are optionally verified until the GB or UGB for the GA can be sent. In some cases, all MAs of the GA can be checked and executed in sequence before sending the GB. However, in some cases, it is also possible to send the GB for the GA without checking a single MA (according to Figure 4b For example, in the special case: TR Aij =TR A1j ).

[0153] The modification specifications MA of the GA may exist as a stack of modification specifications MA or as a series of modification specifications MA.

[0154] In the case of a series of MAs, the MAs will specify substantially temporally consecutive modifications to the token. At least one output token reference of one MA in the series will be an input token reference of another MA in the series. Preferably, two or more consecutive MAs of a GA, such as MAx -1 and MA x The input token reference of is the output token reference of the previous MA of GA. Accordingly, the modification instructions of GA will be in the order of MA1…MA x The modification instructions are present in the GA in the order in which they are executed. x is the most recent MA, representing the last modification to the coin.

[0155] but Figure 4a Shown is the MA stack in the GA. The modifications in the GA illustrate that the input and output token references of the MA are essentially independent of each other (e.g., TR A11 and TR A12 None of them corresponds to TR E21 or TR E12). Especially for larger stacks (e.g. i>5) and / or for stacks with MAs with only one transaction unit, it may still happen that the output token reference of one MA in the stack is the input token reference of another MA in the stack.

[0156] As an optional check specification 43, the validity request 40 shown includes one or more output token references TR that need to be checked for validity. Aij (The jth output token reference of the i-th modification specification). The specified output token reference TR Aij Can include the last modification notes of GA (MA x ), or no output token reference, including in the case of a series. In particular, the inspection statement may include two or more output token references TR from GAs of different MAs. Aij , such as TR A21 and TR Ax1 In addition, the check statement may not include two or more output token reference TRs of a GA that are preferably from different MAs Aij , such as TR A11 ,TR A22 and / or TR Ax2 .

[0157] Figure 4b A first embodiment of a method for checking the validity of at least one token T according to a validity request GA is shown, the validity request having, for example, Figure 4a Multiple MAs. Figure 4b The method flow in the core is in accordance with Figure 3b The method is corresponding (same steps 102, 103, 104, 105, 106), and reference can be made to Figure 3b Instructions in .

[0158] according to Figure 4b The method includes loops 141, 142 for modifying the MA for GA (for MA i , loop index i=1 to x). Starting from the first MA of the GA, MA1, check 102 whether the specified output token reference TR is already stored. A1j Or alternatively store all output tokens of MA with reference to TR A11 and TR A11 (as a valid TR). If necessary, execute 105 to modify the MA i In a method variant not shown, if it is necessary to check whether all TRs of the GA are valid, once the current MA of the GA is not executable (in the case of No in step 103 or Yes in step 104), the UGB can be sent in step 109. Figure 4bIn the example shown, for each MA of the GA, MA1…MA x The operation loop 141, 142 includes steps 102-106 (and 146).

[0159] The output token reference TR that has been previously stored according to step 102 or stored in step 105 Aij TR that can be recognized as valid or signed as GA A Intermediate storage in the loop. In step 146, the specified TR of MA1 is optionally stored intermediately. A1j Or one or more output tokens of MA1 refer to TR A1j invalid.

[0160] If all specified TR Aij If all or all output token references of the GA are valid, a validity confirmation GB for the GA, including an optional signature, is sent 108. Otherwise, an invalidity confirmation can be sent 109. Optionally, if not all but at least one of the relevant output token references is valid (step 147), a partial validity confirmation TGB can be (created and) sent 148. The partial validity confirmation TGB preferably only includes the TRR signatures of the valid output token references for the GA or the valid output token references TR that need to be checked for validity. Aij .

[0161] In step 141, the current modification description MA is checked. i Is this the last modification statement of the GA (ie, whether I == X). Alternatively or additionally, it can be checked whether all specified TR Aij All have been identified as valid and / or invalid. If step 141 is the negative case, the next MA of the GA is verified, represented by step 142, which increases the running index "i" (index i at the beginning of step 101 is: i=1). Then the next MA is checked in repeated steps 102-106 and 146. If the interruption criterion of the cycle is identified (the case of yes in 141), a validity confirmation GB for the GA or a confirmation of invalidity UGB for the GA is sent to the TE according to the situation (steps 107, 147) (or a partial validity confirmation for the GA is optionally sent).

[0162] Figure 4c A further embodiment of a method for checking the validity of a token T according to a validity request GA is shown, the validity request having in particular Figure 4a Multiple MAs. Figure 4c The method flow is in the core and follows Figure 3c The method corresponds to (the same steps or step sequence 104, 103, 102, 105, 106), and reference can be made to Figure 3c Instructions in .

[0163] according to Figure 4c The method also includes loops 141, 142, which have an interruption criterion (checking all specified TR Aij The loop allows each MA of the GA to run the series of steps 102-106, 146 until the interruption criterion is reached. As before, the corresponding confirmation GB / UGB / TGB is then sent 108 / 109 / 149 according to the situation. Figure 4c In the process, the GA's MA can also remain unchecked and can still send TRs that need to be checked for validity. Aij The validity of GB is confirmed.

[0164] Preferably by following Figure 4b and Figure 4c The method checks the stack of modification instructions MA. Modification instructions contain token references that are independent of each other.

[0165] Figure 5a A third embodiment of a validity request GA according to the invention is shown. GA comprises a plurality of modification specifications MA1, MA2, ... MA x The modification instructions of the GA are relevant. In this respect, the GA comprises a series of modification instructions, as has also been partially explained in detail above.

[0166] In the example shown, the output tokens of MA1 refer to TR A11 The input token reference of MA2. The output token reference of MA2 is TR A22 It can be another MA of GA, such as MA3, MA4 or MA x Input token reference of MA x The first input token reference is MA x-1 Output tokens refer to TR Ax-11 As the output token of GA that needs to check validity, refer to TR Aij , GA's inspection statement 53 contains the output token reference TR A21 and TR Ax2 The optionally present signature of the MA is also not shown in the drawing.

[0167] Figure 5b A first exemplary embodiment of a method for checking the validity of a token T based on a validity request GA is shown, the validity request having a plurality of preferably mutually related, in particular according to Figure 5a MA.

[0168] The GA is received 101 and in step 102 is checked against the token reference TR whose validity needs to be checked Aijare stored in the TRR as valid TRs, in particular checking whether they are present in memory cell 1 of the TRR, which contains only valid TRs. If the specified output token reference TR is already stored A21 and TR Ax2 , a validity confirmation GB can optionally be sent 108 as a cryptographic confirmation of the TRR for a valid TR after the creation of the signature 106. In this case, none of the MAs of the GA are checked (for errors and / or executability).

[0169] In loops 153a-c, the x modification descriptions MA in the series are checked 103, 104 one after the other. i , in step 103, the input token reference TR is checked Ei1 and TR Ei2 Whether it is stored in the memory unit 1 of the TRR, that is, whether it is valid. If it is not, then send 109 invalidity confirmation UGB. Similarly, if step 104 is yes, the MA i The checks will find errors (as mentioned before: syntax, value neutrality, etc.).

[0170] But in case of NO in step 104 - because the method is based on series whose token references are related to each other - the MA has not actually been executed. i Output tokens refer to TR A Not stored yet. Delete MA in loop i Input token reference TR E It is conceivable, but this is preferably performed in step 155. The verification unit 2 only stores the MA i The output tokens that need to be stored refer to TR A (and MA i The input token reference TR that needs to be deleted E ). Among these intermediately stored output token references, there are several that will be input token references of another MA of the GA (and therefore originally had to be deleted again). Now they only need to be deleted from the intermediate memory of the verification unit. This can avoid unnecessary write accesses to the memory unit 1 (or multiple unnecessary write or delete accesses). Only in step 155 are the intermediately stored (not deleted again) output token references written to the memory unit. Step 155 can also be described as a selective storage of all output token references of the series. Figure 5b In the example, the output token reference TR A21 TR Ax1 TR Ax2 Stored and entered token reference TR E11 TR E12 TR E21is deleted. Then send the output token reference TR A21 ,TR Ax2 Confirmation of validity.

[0171] Figure 5b Steps 151 and 152 show optional steps that can prevent the modification MA performed in the MA series of the GA from erroneously leading to invalidity confirmation UGB. Anj If it has been stored, the TR is signed in step 152 and the loop index is set to i=n+1. n The processing of the series of modification instructions can therefore start from the next modification instruction MA in the series. n+1 In a not shown embodiment, the series of MAs can be analyzed to identify minor branches of the series and to take them into account when processing the series.

[0172] FIG. 5c shows a method for using a plurality of Figure 5a Another embodiment of a method of checking the validity of a token T by requesting a GA or a GA with a series of MAs.

[0173] For the GA received in step 101, all modification specifications MA1 to MA2 of the GA are first checked in step 164a. x Is there an error? If the MA contains an error (the case of no in step 164b), check the GA's designated output token reference TR Aij Have they all been stored 102? Depending on the situation, send 109 invalidity confirmation UGB or optionally TR Aij After the signature 106 a validity confirmation GB is sent 108 .

[0174] In case of yes in step 164b, all TRs of the GA are read 162 from memory unit 1 (checking whether all TRs are stored). If all designated output tokens refer to TR Aij If all are present 102, a validity confirmation is sent 108 as before. If not (a no case at step 162), all output token references of the series are selectively stored at step 165 and the input token references are deleted (if any are still stored).

[0175] The method according to FIG. 5 c can also optimize a GA having a series (or stack).

[0176] In Check Figure 3aAfter the GA of FIG. 5c or the RA of FIG. 2a / b, the checked (verified) token reference TR is stored in the token reference register TRR, thereby registering (or registering) the modification of the token T in the transaction system TS.

[0177] The token reference TR is clearly assigned to the token T and is used to deposit the token T in the trading system TS. The token reference TR is therefore a public representation of the token T in the direct trading layer TE. Merely knowing or possessing the token reference TR does not allow the transfer of the token T nor is it equivalent to TE owning the token T. The token reference TR is used to prevent multiple issuance attempts. It is checked whether the token value v was generated in an unauthorized manner. Therefore, the token reference TR and, if necessary, the history of the token T and the corresponding modifications are stored in the token reference register TRR via the deposit request RA sent by the trading unit TE.

[0178] For example, the token T is stored in the token memory or electronic wallet of TE, the so-called Wallets. For example, the wallet is a software application in the transaction unit TE (especially the security element) or in the terminal device where TE is installed in an executable manner. The wallet can be set as an application on a smartphone, a smart card or a payment terminal. The wallet is used to securely manage the token T of TE, generate a token reference TR, modify the token T, exchange the token T and / or check the validity of the token. The wallet is used to communicate with the token reference register TRR, generate a registration request RA for modifying the token T to the token reference register TRR, execute transactions of the token T to the transaction unit TE and / or generate a validity request GA.

[0179] For transactions with the trading unit TE, a communication connection to the token reference register TRR of the trading system TS is not required. The trading system TS is configured to carry out transactions "offline", i.e. without a communication connection to the token reference register TRR. Thus, a corresponding registration of the token T can be carried out in time after the transfer of the token T to the trading unit TE.

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

[0181] 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 modification information about one or more modifications to the token T.

[0182] The token reference TR may be sent together with the modification instructions as a validity request GA relating to the token T to the token reference register TRR.

[0183] Additionally, as shown in Figure 1, the validity request GA can be signed with the private part r of the token-specific key pair. The signature can verify whether the sender of the token reference TR owns the token T, thereby further improving the security in the transaction system TS.

[0184] A validity request GA can be sent to the token reference register TRR in order 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 unit 2), the transaction unit TE will be informed whether the token T is valid.

[0185] The validity request GA is preferably signed with the private part r. The signature allows the recipient (TRR or TE) to conveniently check the syntactic authenticity of the instruction. This check is preferably performed in the database 1 or the verification unit 2. The validity request GA can also be verified syntactically, for example, by checking the signature and / or the token reference TR.

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

[0187] If the token reference TR is not already known in the token reference register TRR, it is added (stored).

[0188] An archive unit (not shown in FIG. 1 ) may also be reserved in the token reference register TRR. Registration requests RA and / or validity requests and / or token references that are no longer valid are stored in the archive unit.

[0189] For example, the following modifications to an existing token T can exist as instructions KO, such as: "Switch", "Split" or "Merge". The instructions KO reserved for the token issuer can also involve generating (=Create) a token T or deleting (Destroy) an existing token T. In theory, other instruction types are also known for checking the validity of an unmodified token T in the TRR. The instruction encodings (0x01 to 0x05) are specified by way of example in the table below. The encodings shown here and the order of data elements in the MA used in the accompanying drawings can be interchangeable or are only exemplary.

[0190]

[0191] Examples of conceivable signature syntaxes are specified in the table below. Here, for each instruction, an input token T and an input token reference TR are specified ("use"). Here, for each instruction, an output token T and an output token reference TR are specified ("generate").

[0192]

[0193]

[0194] The basic structure of a modification description (eg a registration request RA or a validity request GA) consists of the following three elements: instruction type, input token reference, output token reference.

[0195] Each instruction KO has a partially representative number (one or more) of input token references ("inputs") and output token references ("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 references.

[0196] Figure 6 Another embodiment of a token reference register TRR of a transaction system TS is shown. It is pointed out that a plurality of memory cells 1 can be reserved in the token reference register TRR for storing token references.

[0197] Figure 6 Another design of a token reference register TRR of a trading system TS is shown. It is pointed out that a plurality of memory cells 1 can be reserved in the token reference register TRR in order to accelerate the storage of a large number of token references TR. It is also pointed out that a plurality of verification units 2 can be reserved in the token reference register TRR in order to accelerate the verification of validity requests GA and / or registration requests RA.

[0198] In addition, the bank transaction unit TE is displayed B , which can be used as an interface between the trading system TS and the book currency system (lending, account management). It enables the trading unit TE to transfer the token T of the trading system TS to another trading system TS. This transfer can be achieved in both directions. The token issuer TH is solely responsible for generating tokens T and deleting tokens T in TS.

[0199] Figure 6Also shown is a registration request unit RAE which can receive a validity request GA (and / or RA) from the transaction unit TE1 and forward the GA (and / or RA) to the TRR.

[0200] Furthermore, the TRR comprises an archive unit 5 in which executed RAs and / or GAs and / or token references which are no longer valid are stored, in particular as a link graph.

[0201] The transaction unit TE can send its RA and / or GA to the TRR via the first interface 3 of the TRR. On the other hand, only the token issuer TH can send instructions to the TRR via the second interface 4 of the TRR.

[0202] It may be advantageous if only one (or fewer) tokens T are used per transaction unit TE (here as a security element, such as a smart card or TEE). This means that the TE combines (MERGE) the received token T with the token T stored in the token memory. This also means that the TE splits (SPLIT) the token T to be sent from the token T stored in the token memory. These modifications to the token T can be performed without a registration request RA or a validity request GA, and the token T can be sent immediately after the modification. Therefore, there may be a series of modifications to the token T, which the TRR is not aware of. Typically, the series of modification instructions MA consists of a combination of SPLIT and MERGE modifications. Each of these modifications is also called a "proof" (see Figure 1 above) or is stored as a preferably signed modification instruction MA together with the token T. This forms a series of modification instructions MA in TE1 regarding the token T. F or MA1,MA2,…MA x .

[0203] According to the invention, a validity request GA is now provided to check the validity of the token.

[0204] For this purpose, the terminal receives GA and / or MA or MA F Alternatively or additionally, a registration request unit RAE can also be provided between TE and TRR as a switching mechanism, see Figure 6 The RAE then receives GA and / or MA or MA from the TE or terminal equipment. F . Send GA to TRR.

[0205] Terminal equipment ( Figure 6 The terminal device or RAE attempts to transfer the GA to the TRR. This means that the terminal device or RAE only performs a protocol conversion, such as conversion from APDU to HTTP(S) between the terminal device / RAE and TE. The terminal device or RAE does not analyze or interpret the GA and / or MA or MAF The terminal equipment or RAE will not change the serial MA F The validity confirmation GB of the TRR (or the registration confirmation RB) is then transmitted from the terminal equipment and / or RAE to the TE. Each GA and / or MA or MA F Each can be signed with the private part r (random number r) of the key pair specific to the relevant token. Therefore, the modification description MA stored in TE (token storage) is sometimes also called a proof.

[0206] The verification unit 2 of the TRR is particularly implemented by Figure 3b The method to Figure 5c checks validity. The GB is sent back to the secure element or TE (via the RAE or terminal device if necessary).

[0207] Assume, for example, that TE1 performs the following sequence of modifications on token A:

[0208] Split: A→B,C (token A is split into tokens B and C)

[0209] Switch: C→D (token C switches to token D)

[0210] Token D is transferred to TE2 with two modifications (proofs) “Split” and “Switch”. TE2 also performs:

[0211] Combination: D, E → F (tokens D and E are combined into token F)

[0212] Validity check of token F: Only the validity of token F should be checked. For this purpose, a GA is generated and the token reference of token F (as a check description) is sent from TE2 to TRR as a GA together with the modification description MA consisting of the three modifications (proofs) "split", "switch" and "join". The GA only specifies token F as the token to be checked by its token reference. According to the GA, the output token reference TR of the first MA of the GA is B Will not be checked or not checked for validity by the TRR. In the example of this case, the first two modification specifications of the GA are only optionally performed, for example if TE1 (or other TE) has not sent a RA or GA with these two MAs to the TRR.

[0213] The GB may optionally return the TRR in the form of status information which also encodes additional information, for example:

[0214] 200: The token is valid and all changes in the modification instructions can be resolved

[0215] 400: Token is valid, some changes in the modification instructions cannot be resolved

[0216] 500: Internal Error

[0217] 600: Invalid token.

[0218] A cryptographic confirmation, in particular a signature, of the TRR may be attached to such state information.

[0219] GB or a valid TR can use the private key pKey of the key pair of verification unit 2 TRR sign.

[0220] List of Reference Numerals

[0221] PKey TH The public part of the token issuer key pair

[0222] pKey TH The private portion of the token issuer key pair

[0223] PKey TRR Verify the public part of the unit key pair

[0224] pKey TRR Verify the private part of the unit key pair

[0225] The public part of the R token-specific key pair

[0226] rThe private part of the token-specific key pair

[0227] GA Validity Request

[0228] GA sig_T A validity request signed with the private portion of the token-specific key pair

[0229] GB validity confirmation

[0230] UGB Invalidity Confirmation

[0231] GB sig_TRR Confirmation of validity of signature using the private part of the token reference register key pair

[0232] RA Deposit Request

[0233] RA sig_T A deposit request signed with the private portion of the token-specific key pair

[0234] RA sig_TH A deposit request signed with the private portion of the token issuer's key pair

[0235] MA Modification Instructions

[0236] RAE register request unit

[0237] RB deposit response, deposit confirmation

[0238] T Token

[0239] TE Trading Unit

[0240] TE B Trading unit bank

[0241] TE-Schicht Direct Trading Layer

[0242] TRR-Schicht Register Layer

[0243] TH Token Issuer

[0244] TR x GA Token Reference

[0245] TR E Input Token Reference

[0246] TR A Output Token Reference

[0247] KO instruction, modification instruction

[0248] TRR Token Reference Register

[0249] TS Trading System

[0250] v. TW Token Value

[0251] ah tokens for different tokens and token references ∑ total token value of the trading system 1 database, memory unit

[0252] 2 Verification Unit

[0253] 11-19 Method steps in the prior art

[0254] 3Participant interface / MA receiving unit

[0255] 4Issuer interface / new register unit

[0256] 5MA Archive Unit

[0257] 6. Total inspection unit

[0258] 30 Validity Request

[0259] 31 Modification Notes

[0260] 32 Signature of modification instructions

[0261] 33, 43, 53 inspection instructions

[0262] 40 Validity request for MA stack 50 Validity request for MA series 101 Receive GA

[0263] 102 Check TR AIs it stored?

[0264] 103 Check TR E Is it stored?

[0265] 104 Check if MA has any errors 105 Store TR A

[0266] 106 Create Signature

[0267] 108 Send validity confirmation

[0268] 109 Send invalid confirmation

[0269] 141, 142 for MA i Processing loop

[0270] 146 for TR A Marking invalidity

[0271] 107 Check whether the total validity is determined

[0272] 147 Check if partial validity is confirmed

[0273] 148 Send partial validity confirmation

[0274] 151 Check TR An Is it stored?

[0275] 152 pairs of TR An sign

[0276] 153a, 153b, 153c for MA i Processing loop

[0277] 155 pairs of TR of MA series A Selective storage

[0278] 164a Verification MA Series

[0279] 164b Check if the series is verified

[0280] 165 pairs of TR of MA series A Selective storage

Claims

1. A security element for an electronic transaction system (TS), in, The secure element has a token storage for a token (T) of a transaction system (TS); Wherein, the security element is configured as a transaction unit (TE) so as to directly exchange tokens (T) of the transaction system with other transaction units (TE) of the transaction system (TS); Each token (T) of the trading system is explicitly assigned a token reference (TR), which can be stored in a token reference register (TRR) of the trading system. The security element is configured to receive at least one input token (T E ) generates at least one output token (T A ) and its output token reference (TR A ); The security element provides at least one modification instruction (MA) for a token reference register (TRR), wherein the modification instruction includes at least one input token reference (TRR) E ), instructions (KO) and at least one output token reference (TR A ), It is characterized in that The security element is configured to provide at least one modification specification (MA) as a validity request (GA), and The secure element is configured to receive at least one output token reference (TR) to be checked for validity in response to a validity request (GA). Aij )’s validity confirmation.

2. The security element according to claim 1, characterized in that A validity request includes at least one output token reference (TR Aij ) and at least one output token reference that does not need to be checked.

3. The safety element according to claim 1 or 2, characterized in that: In addition to the modification specification (MA), the validity request includes a specification of at least one output token reference (TR Aij ) inspection instructions (33; 43; 53).

4. The security element according to any one of claims 1 to 3, characterized in that The secure element is configured to provide a modification specification as a validity request (GA) or as a registration request (RA).

5. The security element according to any one of claims 1 to 4, characterized in that For each output token reference (TR Aij ), the validity confirmation comprises a separate cryptographic confirmation, which is preferably stored in a secure element; or For all output token references that need to be checked (TR Aij ), the validity confirmation includes a common cryptographic confirmation, which is preferably stored in a security element.

6. The security element according to any one of claims 1 to 5, characterized in that The validity request includes a plurality of modification specifications (MA), in particular a stack and / or a series of modification specifications.

7. The security element according to any one of claims 1 to 6, characterized in that The security element comprises a processor, in particular a processor for executing steps as a transaction unit, and / or comprises an interface, in particular an interface with a local terminal device, via which a validity request is provided for the token reference register (TRR); and / or The token (T) includes a token value (v) and a secret token element (r) as data elements; and / or The Token Reference (TR) includes the token value (v) and the public token elements (R) as data elements.

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 explicitly assigned a token reference (TR), wherein a token reference register (TRR) of the transaction system (TS) comprises a verification unit (2) and a memory unit (1), in which a token reference (TR) of a valid token (T) is stored, the method comprising the following steps in the token reference register (TRR): - receiving (101) a validity request (GA), said validity request comprising an amendment specification (MA), said amendment specification having at least one input token reference (TR E ), at least one output token reference (TR A ) and instructions (KO); - Check (102) at least one output token reference (TR) of the validity request (GA) for which validity is to be checked Aij ) is stored in the memory unit (1); and - Send (108) at least one output token reference (TR) to be checked Aij ) validity confirmation (GB); The validity request (GA) includes a modification specification (MA; MA1) and / or a check specification (33; 43; 53) that only optionally needs to be processed, which specifies at least one output token reference (TR Aij ).

9. The method according to claim 8, characterized in that The verification unit (2) processes the modification description (MA) in one or more sub-steps: - Check (103) at least one input token reference (TR E ) is stored in the memory unit (1); - verifying (104) the modification description (MA), in particular the signature in the modification description (MA) and / or the value neutrality of the modification description (MA) and / or the syntax of the modification description (MA) by means of the verification unit (2); and / or - executing the instruction (KO) by storing (105) the output token reference in the memory unit (1) and in particular by deleting the input token reference in the memory unit (1).

10. The method according to claim 8 or 9, wherein: The validity request (GA) includes at least one, and preferably multiple, output token references (TRs) that do not need to be checked for validity. A11 ); and / or validity check (GB) for each output token reference (TR Aij ) includes separate cryptographic confirmation.

11. The method according to any one of claims 8 to 10, wherein: The validity request (GA) includes a plurality of modification specifications (MA1, MA2, ... MAx), wherein each modification specification (MA) includes one or more input token references (TR E ), one or more output token references (TR A ) and a modification instruction (KO), wherein the modification instructions are preferably a stack (40) of modification instructions and / or a series (50) of modification instructions (MA), wherein in particular the stack consists of independent modification instructions (MA) or the series includes modification instructions (MA) that are at least partially related to each other.

12. The method according to any one of claims 8 to 11, wherein: For output token references of different modification specifications and / or for output token references and input token references of at least one modification specification (MA), the verification unit (2) issues a common storage request to the memory unit (1).

13. The method according to claim 11 or 12, wherein: For stacks of modification instructions (MA), a partial validity confirmation (TGB) is sent; and / or For a series of modification specifications, at least one output token reference of the modification specifications (MA) is only stored temporarily internally and / or stored in the memory unit (1) after checking one, several or all modification specifications (MA) of the series.

14. The method according to any one of claims 8 to 13, wherein: The token reference register (TRR) executes the method via a transaction unit TE or a security element according to one of claims 1 to 7, and / or The Token Reference Register (TRR) also includes: - other verification units (2) and / or An archiving unit (5) which stores token references that are no longer valid and / or already executed validity requests (GA) and / or registration requests (RA).

15. A token reference register (TRR) for a transaction system (TS), configured to perform the steps of the method according to one of the preceding claims 8 to 14, in particular by means of a transaction unit TE or a security element according to one of claims 1 to 7.

16. A Token Reference Register (TRR) according to claim 15, having: - a memory unit (1) for storing a token reference (TR) for registering a token (T) in a transaction system (TS); - providing an interface (3) for receiving a validity request (GA); - At least one verification unit (2).

17. A trading system (TS) comprising: - a hosting layer (TRR layer) having a token reference register (TRR) according to claim 15 or 16 for hosting token references (TR); and A direct transaction layer (TE layer) having a plurality of transaction units (TE) comprising a security element according to one of claims 1 to 7.

Images