SECURE ELEMENT, METHOD FOR REGISTERING TOKENS AND TOKEN REFERENCE REGISTER

Description

[0001] The invention relates to secure elements as transaction units, a method for registering tokens of an electronic transaction system, which in particular comprises the secure elements as transaction units and a token reference register. The invention also relates to the token reference register, in which the token references uniquely assigned to a token are stored.

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

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

[0004] Different approaches are known to ensure the security of an electronic transaction system; particularly in the field of central bank digital currencies (CBDC), a distinction is regularly made between token-based and access-based systems.

[0005] For access-based systems, such as WO 2016 / 200885 A1, a method for encrypting an amount transferred via a blockchain ledger while maintaining the verifiability of the transaction has already been described. These transaction systems based on blockchain topologies provide a high level of integrity protection. When records change hands in a blockchain topology, a large amount of information is published. For example, a unique address of a participant unit is verifiably registered in the blockchain. Thus, blockchain transactions are not anonymous. Furthermore, these transactions are very computationally intensive and therefore energy-intensive.

[0006] It is also already known to extend a token-based transaction system with a token register. The secure element sends a registration request for its token to the register. The register verifies the registration request and stores only a token reference for the token, thus preferably not knowing the token itself. The invention uses a method for registering tokens that are transmitted as part of direct communication between subscriber units.

[0007] WO 2020 / 212337 A1 describes a transaction system in which even modifications to the token – for example, by splitting the token – are securely possible offline, i.e., directly between the secure elements of the transaction system and without any additional control authority. The tokens can be immediately transferred after receipt in a secure element or subscriber unit without having to register a modification in a token register of the transaction system. However, the secure elements are known to be resource-limited, particularly with regard to storage space, processing speed, and / or transmission speed.

[0008] DE 102019002732 A1 also describes a token register and shows the preamble of claim 1.

[0009] Participating units, especially secure elements, of a transaction system should be able to pay flexibly with tokens within the transaction system. This is particularly challenging for secure elements when a sequence of transactions involving a token, a portion of it, or in combination with other tokens, has taken place directly between participating units, and only then is a token to be registered, along with all the modifications to the token, to be processed.

[0010] The invention utilizes a method for registering tokens that can be transferred directly between subscriber units. In particular, the invention relates to processing a group, hereinafter also referred to as a batch or sequence, of registration requests.

[0011] The invention is based on the object of creating a method for registering tokens of a transaction system in which a sequence of transactions between different participant units of the transaction system using a token or a part thereof or in combination with other tokens is designed to be secure yet simple. This sequence of transactions should remain anonymous to third parties, i.e. a received token should be secret from all participant units not involved in the transaction. Tokens should be able to be reused immediately after receipt in a participant unit in order to enable a transaction even without a connection to a remote unit, for example a central register or a decentralized ledger.Each participant unit in the transaction system should be able to verify a received token. In particular, multiple spending attempts and attempts to transfer nonexistent token values ​​should be detectable by a participant unit or generally within the transaction system. The number of consecutive transactions should be unlimited. The registration of a sequence of transactions should be simple and secure.

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

[0013] The object is achieved in particular by a method for registering tokens of an electronic transaction system, wherein each token of the transaction system has at least one token value and a private part of a token-specific key pair as token elements.

[0014] The method comprises the steps of: receiving, in a token reference register of the transaction system, a sequence of registration requests, wherein each registration request of the sequence has a first token reference and at least one second token reference, and wherein at least one token reference of a first registration request of the sequence and one token reference of a second registration request of the sequence are the same;Verifying, by a verification unit of the token reference register, whether at least one of the at least one token reference contained in the received sequence of registration requests can be uniquely assigned to a first token of the transaction system, wherein the token reference is checked to determine whether it is or was stored in the token reference register, storing at least one token reference from the sequence of registration requests other than the checked token reference in the storage unit of the token reference register for registering the token uniquely assigned to this token reference in the transaction system, if it is determined in the verification step that the checked token reference of the received sequence of register requests can be uniquely assigned to the first token of the transaction system and if the other token reference is not yet stored in the token reference register;

[0015] After the receive, verify and save step, the next registration request in the sequence of registration requests can be processed.

[0016] Security of transactions and the associated transaction data means protecting the confidentiality of the exchanged data, as well as protecting the integrity of the exchanged data, and protecting the availability of the exchanged data.

[0017] In this way, a sequence of transactions in a direct transaction layer of the transaction system can be carried out directly between participant units with a token and, if applicable,

[0018] Modifications are verified. The token reference register then receives a registration request for each transaction in the sequence and checks the extent to which token references can be assigned to tokens in the transaction system in order to verify the tokens and thus also the transactions.

[0019] The sequence of registration requests concerns requests to register tokens that are not yet registered in the transaction system. These tokens have been exchanged directly between participating units and may have been modified multiple times. In order to register (all) of these tokens relating to these registration requests, these registration requests no longer need to be made individually, but can be processed as a sequence of registration requests.

[0020] A sequence of registry requests represents a plurality of different registration requests concerning a token in the transaction system. This sequence can also be referred to as a block or a bundle. The token to be stored or in question has been modified multiple times (at least twice), and none of these modifications has been recorded in the token reference register to register the token with its modifications.

[0021] Receiving preferably takes place at an interface of the token reference register, preferably an interface of the verification unit of the token reference register.

[0022] Each registration request in the sequence therefore has at least two token references. For a split or merge modification of a token, three token references are provided per registration request. For a switch modification of a token, two token references are provided per registration request.

[0023] The token references of a sequence of registration requests are not independent of one another; at least two or more token references of the sequence are linked or mapped to one another. Thus, at least one token reference of a first registration request of the sequence and one token reference of a second registration request of the sequence are identical, i.e., the token reference of the first registration request of the sequence is identical to the token reference of the second registration request of the sequence.

[0024] A transaction system is a system in which at least two, preferably a plurality of, participant units can exchange (transfer) tokens directly with each other. The transaction system is, for example, a payment transaction system for exchanging monetary amounts in the form of payment tokens.

[0025] Preferably, each token reference from the sequence of registration requests was (past) or is (present) uniquely assigned to a token in the transaction system. This assignment will be explained in more detail later. These tokens were transferred directly between participant units of the transaction system in a direct transaction layer of the transaction system or were modified by one or more participant units without these transferred tokens and / or modified tokens being registered in the transaction system. In particular, the (input) token references of transferred tokens and / or modified tokens contained in the sequence of registration requests were not stored in the token reference register.

[0026] A modification to a token is, in particular, the splitting (SPLIT) of a token (or its token value), the combining (MERGE) of at least two tokens (or their token values), or the switching (SWITCH) of the token from one subscriber unit to another subscriber unit. These modifications are described in more detail below.

[0027] Preferably, the entire sequence of registration requests is received in the token reference register before the verification step is performed, whereby each (input) token reference from each registration request must be verified. Each registration request from the sequence is received and verified in the token reference register, and then stored or not stored in the storage unit based on the verification result.

[0028] Saving can occur before another registration request in the sequence is verified. Saving can occur immediately after verification, for example, before another registration request is received and / or verified.

[0029] Preferably, the entire sequence of registration requests is sent from a participant unit of the transaction system to a registration request unit of the transaction system before the verification step is executed. The registration request unit is an instance of the transaction system that manages the registration of the entire sequence for a participant unit. The participant unit thus delegates the registration of the entire sequence to the registration request unit. This reduces the number of (individual) registration requests from the participant unit to the token reference register and also reduces the administrative overhead per participant unit.

[0030] The token reference register sequentially receives and verifies each registration request from the registration request unit before the next registration request from the registration request unit is received and verified. Thus, all registration requests are processed sequentially and, after verification, stored in the storage unit according to the verification result.

[0031] In a less preferred embodiment, the token reference register sequentially receives and verifies each registration request from the sequence of registration requests from the subscriber unit before the next registration request from the sequence of registration requests is received and verified by the subscriber unit. Thus, all registration requests are processed sequentially and, after verification, stored in the memory unit according to the verification result.

[0032] The token reference register can verify (especially its verification unit) and store (especially its storage unit) individual registration requests (i.e., individual registration requests concerning a token and / or its modification) or registration request stacks (i.e., a plurality of individual registration requests concerning different tokens and / or their one modification) or even sequences of registration requests (i.e., a plurality of individual registration requests concerning the same token and / or its modification).

[0033] Individual registration requests or parts of a registration request batch can be distributed among different verification units of a token reference register, allowing them to be processed in parallel by different verification units of the token reference register. This allows a large number of registration requests to be distributed internally within the token reference register among different verification units ("load balancing").

[0034] Each sequence of registration requests can and should be processed sequentially. In one embodiment, the subscriber unit and / or the registration request unit sends each registration request from the sequence of registration requests sequentially as an individual registration request to the token reference register, without the token reference register, specifically the verification unit, being aware that this individual registration request is part of a sequence of registration requests. The sequence of registration requests is typically provided by a subscriber unit.

[0035] Each registration request in the sequence includes at least one token reference as output token reference and at least one input token reference.

[0036] In a SWITCH modification, the registration request includes exactly one token reference as the output token reference and exactly one input token reference. In a SPLIT modification, the registration request includes exactly one (or more) input token references and at least two token references as output token references. In a MERGE modification, the registration request includes at least two token references as input token references and exactly one (or more) output token references.

[0037] The registration requests of the sequence are linked to each other via their token references; in particular, an output token reference of a registration request of the sequence forms an input token reference (of) the next registration request(s) of the sequence.

[0038] In a preferred embodiment, the method comprises the further steps: creating, by the verification unit of the token reference register, a registration response, wherein the registration response indicates a result of the verification step and sending the registration response to a subscriber unit sending the registration request from the sequence of registration requests or registration request unit of the transaction system, wherein preferably the subscriber unit has the token of the at least one token reference of the sequence of registration requests.

[0039] Preferably, the registration response to the subscriber unit concerns all registration requests in the sequence. If the sequence is sent to the token reference register as part of individual registration requests, the registration response concerns only the respective individual registration request.

[0040] A registration response includes information, preferably registration status information (status, status code) regarding the result from the verification step.

[0041] For example, if it is determined in the verification step that the at least one token reference of the received register request can be uniquely assigned to a token of the transaction system and, as a result, the token is registered in the transaction system by storing the token reference, this information comprises a positive registration status.

[0042] A positive registration status of a registration response can apply to the entire sequence of registration requests, for example, if at least one token reference of the chronologically last registration request in the sequence of registration requests can be uniquely assigned to a token of the transaction system. If a token is successfully assigned to the chronologically last token reference within a sequence of registration requests, it is assumed that all other token references in the sequence of registration requests can also be uniquely assigned to a token or could have been in the past. The subscriber unit then receives only the registration response of one (of the last) registration requests.

[0043] For example, if it is determined in the verification step that the at least one token reference of the received register request cannot be clearly assigned to a token of the transaction system and, as a result, the token is not registered, this information includes a negative registration status.

[0044] In addition to the registration status information, the registration response preferably also includes the registration request to which the registration response refers. This allows the subscriber unit to check whether the registration response is valid or whether there has been an attempt at manipulation.

[0045] If the registration status is positive, the registration request contained in the registration response may concern the most recently received registration request from the sequence of registration requests.

[0046] In the case of a negative registration status, the registration request contained in the registration response may refer to the first (chronologically first) registration request in the sequence of registration requests that follows a registration request in the sequence whose token reference could be uniquely assigned to a token of the transaction system. The included registration request is thus the chronologically first registration request for which no unique assignment of a token could be verified in the verification step.

[0047] The registration response is preferably signed with a private part of a key pair of the token reference register, preferably the verification unit (or one of a plurality of verification units). This signature is verified by the subscriber unit upon receipt of the registration response with the public part of the key pair of the token reference register. This increases security, because registration responses generated by unauthorized third parties—for example, as part of man-in-the-middle attacks—are recognized by a subscriber unit due to a missing or invalid signature. Such registration responses can then be ignored by the subscriber unit.

[0048] In one embodiment, a registration response with a token reference signature is created from the sequence of registration requests only for the (chronologically) last verified registration request (token reference can be assigned to a token), and this signed registration response is sent to the subscriber unit or the registration request unit.

[0049] In one embodiment, for all successfully verified registration requests (each token reference can then be uniquely assigned to a token), a registration response with a token reference signature is created from the sequence of registration requests and this signed registration response is sent to the subscriber unit or the registration request unit.

[0050] In a preferred embodiment, the sequence of registration requests is stored in an archiving unit. This allows all registration requests to be archived in the token reference register. This allows for verification of token references even at a much later time.

[0051] Preferably, the archiving unit is a unit of the token reference register.

[0052] In one embodiment, each registration request also includes information about a command type. This command type informs the token reference register about the type of modification made to the token and thus indicates to the token reference register what information is subsequently contained in the registration request.

[0053] In one embodiment, the registration requests are stored in their entirety in the archiving unit. This saves the registration requests and the token references they contain, as well as a command type. This allows for a check of all token references in the event of an error, so that tokens can still be registered at a later time.

[0054] In one embodiment, a registration request is deleted from the archiving unit when a predefined period of time has elapsed since the registration request was archived in the archiving unit. This predefined period of time is, for example, 1 year or a number of months, such as 12 months, 9 months, or 6 months. After this period of time, the probability that this registration request will need to be reviewed again decreases. The archiving unit thus serves to review old registration requests, with an automatic deletion process after the expiration of the period ensuring that the amount of data in the archiving unit is not unnecessarily large.

[0055] In a preferred embodiment, each registration request is stored in an archiving unit of the token reference register, preferably in a first part of the archiving unit, if it is determined in the verification step that the at least one token reference of one of the registration requests in the sequence of registration requests cannot be uniquely assigned to a token of the transaction system. Accordingly, registration requests for which the token reference could not be uniquely assigned to a token in the verification step are stored in the archiving unit (for example, in the first part thereof). This is the case, for example, if the token of the token reference is the result of a splitting modification and the token reference register only knows one token reference of the at least two token references of the split tokens.This is also the case, for example, if no token exists for the token reference, i.e. token values ​​have been generated illegally.

[0056] In a preferred embodiment, each registration request is stored in an archiving unit of the token reference register, preferably in a first part of the archiving unit, if it is determined in the verification step that the at least one token reference of one of the registration requests in the sequence of registration requests is already stored in the token reference register. Registration requests that are already stored in the token reference register are therefore stored in the archiving unit (for example, in a first part thereof). This is the case, for example, if an unauthorized attempt has been made to issue a token multiple times.

[0057] Preferably, a sequence of registration requests with token references is stored in a second part of the archiving unit if all token references of the sequence of registration requests can each be uniquely assigned to a token of the transaction system.

[0058] With the archiving unit, the token reference register is advantageously able to resume aborted processing or only partial processing of a sequence of registration requests.

[0059] This interruption or partial processing (processing) can occur due to network or transmission errors. During the registration of the sequence of registration requests, i.e., after one of the registration requests in the sequence has been registered by saving the token reference in the storage unit but before the last registration request in the sequence has been registered, problems occur during the data transmission of the subsequent registration requests from the sequence. The storage unit has already been partially updated, but the sequence has not been fully processed. To map and resolve this error scenario, the archiving unit is provided, in which the already processed part of the sequence is archived.

[0060] This interruption or partial processing (processing) can occur due to incorrect behavior on the part of a subscriber unit. For example, a malicious subscriber unit has intentionally changed either the order of the registration requests or the syntax of the registration requests, resulting in the token reference register being unable to verify a registration request (fraud attempt). For example, due to incorrect behavior on the part of the subscriber unit, data transmission errors, or other reasons, invalid registration requests were received in a sequence of registration requests. The storage unit has already been partially updated, but the sequence has not been fully processed. To map and resolve this error scenario, the archiving unit is provided, in which the already processed part of the sequence is archived.

[0061] This abort or partial processing (execution) can occur due to a non-assignable token reference. For example, there was never an assignable token (fraud attempt), or the assignable token has already been modified and a token reference exists in the token reference register for this modification (splitting, joining, switching), or the assignable token has already been issued (illegal multiple issue attempt), or the assignable token has been deleted (token value has been redeemed). To map and resolve this error scenario, the archiving unit is provided, in which the already processed part of the sequence is archived.

[0062] The memory unit of the token reference register has been updated in an incomplete manner in all these aborted or only partial processings (processings) of a sequence of registration requests and the archiving unit is now provided for the complete processing of the sequence of the registration request when the registration of the sequence is repeated in order to detect any attempts at manipulation (e.g. the changing of the sequence by the subscriber unit).

[0063] The division into a first part (= passive part) and a second part (= active part) in the archiving unit enables easier resumption of processing of an incompletely processed sequence, because registration requests from incompletely processed sequences can be processed in the second part.

[0064] The token reference register can now easily recognize the newly or repeatedly received registration request of the sequence of registration requests with the cooperation and calling of the archiving unit and finally process the sequence completely.

[0065] If the sequence of registration requests is completely processed, it can be transferred from the first part to the second part of the archiving unit.

[0066] The first part of the archiving unit can also be called from the token reference register if a token reference is not stored in the token reference register, in order to ensure that this token reference is not part of an incompletely processed sequence.

[0067] The first part of the archiving unit can also be called by an instance of the transaction system when a token is to be deleted or redeemed. This instance can then use an assignable token reference to verify whether the token was part of an incompletely processed sequence of registration requests.

[0068] In a preferred embodiment, the token references of the sequence of registration requests are verified chronologically backward. For example, a registration response is created for the last successfully verified registration request or all successfully verified registration requests in the sequence of registration requests. This can then be additionally signed with the private part of the key pair of the token reference register. The registration response is sent to the subscriber unit or the registration request unit as confirmation of the registration.

[0069] If the last registration request of the sequence was successfully verified and this was sent to the subscriber unit or the registration request unit as a confirmation (registration response), all registration requests of the sequence can be deleted in the subscriber unit.

[0070] A token is a record of a transaction system that can be directly exchanged between participating entities. Once the token is known, the receiving participating entity owns the token value represented by the token. Upon exchange, the token automatically changes ownership. A token—a record that is transferable independently of a transaction topology, such as the blockchain topologies "Bitcoin," "Ethereum," or "Neo"—can be transferred directly between participating entities without any intermediaries.

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

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

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

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

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

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

[0077] Anyone who owns a token or has unrestricted access to the token with its token elements can exchange this token with another participating entity. Ownership of the token with its at least two token elements (token value and the private part of the token-specific key pair) is therefore equivalent to ownership of the value represented by the token.

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

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

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

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

[0082] A second token element of each token reference in the transaction system is a public part of the token-specific key pair. This public part of the token reference, together with the private part of the token, forms the token-specific key pair. The public part is obtained by applying a cryptographic function to the private part.

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

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

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

[0086] The token reference is formed from the token value (first token reference element) and the public part. This formation is preferably the concatenation of these two token reference elements. Any other type of linking of these two token reference elements is not excluded according to the invention and includes, for example, concatenation, insertion into a TLV data structure, and / or logical linking.

[0087] A token reference can preferably be generated by an electronic wallet of a subscriber unit. To do this, the subscriber unit must have knowledge of the token and its token elements. The token reference can be generated by an electronic wallet of a subscriber unit that wishes to send the token. Alternatively, the token reference can be generated by an electronic wallet of a subscriber unit that has received the token.

[0088] The use of a token reference is not comparable to the use of addresses of participant units in a blockchain-based transaction system, since no addresses of the participant units are used in the token reference register according to the invention in order to prevent traceability of the tokens.

[0089] The registration method includes a receiving step to receive a token reference in a token reference register as part of a registration request.

[0090] For example, the registration request is sent by a participant unit of the transaction system or a token issuer of the transaction system.

[0091] The token reference register is a unit of the transaction register that stores the token references, which registers the assignable tokens. This register can be a centralized database or storage unit. This register can be a decentralized ledger, for example, in a blockchain topology. The token reference register can maintain a history of the token references and / or registration requests.

[0092] The received registration request is verified by a verification unit in the token reference register. This verifies whether at least one token reference of the received registration request is already stored in the token reference register.

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

[0094] In one embodiment, in the verification step, the verification unit of the token reference register also determines whether the token reference in the received registration request can be uniquely assigned to a token. For this purpose, the token reference or a derivative of the token reference or a history (archive) of the token reference must be stored in the token reference register (e.g., the archiving unit), which can be assigned to the token reference of the received registration request.

[0095] In one embodiment, the verification step determines whether the received registration request is syntactically correct. This checks, for example, whether the registration request is plausible, whether a command type was correctly specified in the registration request, whether the token uniquely assigned to the token reference actually exists (can exist), and / or whether a subtraction of token values ​​in the registration request matches a command type specified in the registration request.

[0096] In one embodiment, the verification step determines whether a signature of the registration request is correct.

[0097] In one embodiment, the verification step also determines whether the sum of token values ​​of all token references within the registration request is zero. The input and output token values ​​of the registration request are summed. For registration requests originating from subscriber units, the sum of all token values ​​of the registration request must be zero. If the sum is not zero, an additional token value was created in the transaction system without authorization, or a token value was destroyed from the transaction system. This makes it easier to detect fraud attempts using nonexistent or unauthorizedly generated tokens. Previously, complex zero-knowledge proofs (ZKP) were necessary, which can be eliminated with this procedure.

[0098] The received token reference is stored in a storage unit of the token reference register. Saving the token uniquely assigned to the received token reference is registered in the transaction system. Saving only occurs if the verification step determines that at least one token reference of the received register request is not stored in the token reference register.

[0099] The basic principle of registering a token is that a received registration request is verified to determine whether the token reference assigned to the token is already known in the token reference register. If the token reference is already known, it is not saved again. If the token reference is unknown, it is entered (saved) in the token reference register to be available for future verification and checking steps in the transaction system.

[0100] In one embodiment, the received registration request is signed with the private part of the token-specific key pair in order to check or verify the association of the token reference with the token. If the verification step is successful, i.e., the signature can be verified, then the sender of the registration request must be in possession of the token or have knowledge of the token. This allows for the detection of attempted fraud using nonexistent or unauthorized tokens.

[0101] In one embodiment, the token reference is obtained by masking the associated token by applying a homomorphic one-way function to the token.

[0102] In one embodiment, the token reference register comprises one or more storage units for storing token references for registering the tokens in the transaction system.

[0103] This storage unit(s) can be managed as a central database of the transaction system. The use of multiple storage units enables—similar to the use of multiple verification units—parallel processing of registration requests and accelerates registration in the transaction system.

[0104] For example, the verification unit(s) compares a command type of the received registration request with the token values ​​of the received registration request. If a command type expects no token values ​​to be added to or subtracted from the transaction system, a check is performed to determine whether this is also being observed with the token values ​​of the received token references. If the verification fails, a fraud is detected and registration is prevented.

[0105] In one embodiment, the token reference register has a checking unit for checking a sum of token values ​​relating to the received registration request. This checking unit compares the received registration request with a data set in the storage unit and, in particular, checks a total sum of all token values ​​for changes due to the registration request. This allows the validity of the token value to be checked to determine whether a new token value was generated unauthorized. This could also be used to check old registration requests and their success; this registration request history could be used to process duplicate registration requests without burdening the storage unit of the token reference register.

[0106] In one embodiment, the token reference register has a re-registration unit for registering token references to newly generated tokens (=new tokens) or deleted tokens (deactivated tokens) of a token issuer. These newly generated tokens and these deleted tokens can be entered into this re-registration unit of the token reference register. With the re-registration unit, a reference value relating to the total token value of the tokens in the transaction system can be updated based on the generated and / or deleted tokens in the token reference register (for example, in a checking unit thereof). If, for example, a new token is generated, its token value is added to the total token value. If, for example, a token is deleted, its token value is subtracted from the total token value.

[0107] In one embodiment, the token reference has at least one count value as a further token reference element and / or the token has a count value as a further token element. The count value can, for example, represent the number of offline transactions of the token. The count value can be greater than the number of registration requests in the sequence. An offline transaction is a direct transaction between participant units in the transaction system for transferring tokens without the token being registered in the token reference register. The count value increases (increments) with each offline transaction. It can be provided by the system that tokens must be automatically registered in the token reference register when a predefined threshold for the count value is exceeded.

[0108] In one embodiment, the token reference includes at least one identity of a subscriber unit or an owner of the subscriber unit as a further token reference element. The identity can be another token element. This identity serves, for example, in the verification step to validate or verify the token reference. This removes anonymity in the transaction system and allows fraud to be detected more quickly.

[0109] In one embodiment, the token reference includes at least a pseudonym of a subscriber unit or an owner of the subscriber unit as an additional token reference element. The pseudonym can be an additional token element. This pseudonym serves, for example, to validate or verify the token reference in the verification step. This does not compromise anonymity in the transaction system, yet a fraud case can be detected more quickly if a unit of the transaction system resolves the pseudonym.

[0110] To create the token reference, each additional token reference element can be added by concatenation with the first and / or second token reference element.

[0111] In one embodiment, the registration request relates to a splitting of a token, and preferably, the registration request includes a token reference of the token to be split and a token reference of each of the (at least two) split tokens. The token references contained in the registration request can be concatenated. Splitting is a modification option for a token that allows a token value of a token to be divided into at least two (smaller) token values. This makes it possible to reduce the token value and respond to a transaction request with greater token value precision. This invalidates the split token, and the (at least two) split tokens are registered in the token reference register to become verifiable in the transaction system.

[0112] Alternatively or additionally, the splitting process involves dividing the token value of the token to be split into at least a first token value and a second token value. The splitting can be performed symmetrically, so that the split token values ​​are equal. The splitting can be performed asymmetrically, so that the split token values ​​are unequal.

[0113] Alternatively or additionally, the splitting process involves: generating a new private part of a token-specific key pair for a first split token; applying a cryptographic function to obtain a corresponding public part of the token-specific key pair for the first split token; generating a new private part of a token-specific key pair for a second split token; applying a cryptographic function to obtain a corresponding public part of the token-specific key pair for the second split token; splitting the token value into a first token sub-value and a second token sub-value, taking into account that the sum of the first token sub-value and the second token sub-value corresponds to the token value of the token to be split;Generating a token reference for the first split token comprising the first token partial value and the public part of the token-specific key pair of the first split token; generating a token reference for the second split token comprising the second token partial value and the public part of the token-specific key pair of the second split token; and creating the registration request using the token reference of the token to be split, the token reference for the first split token, and the token reference for the second split token.

[0114] In one embodiment, the registration request relates to a token switch, and preferably, the registration request includes a token reference of the token to be switched. Switching the token is a further modification option. The token references contained in the registration request can be concatenated. If a token is transferred directly from one subscriber unit to another subscriber unit, for example, if a monetary amount is to be transferred as a token value within the scope of a payment transaction, the receiving subscriber unit can now have the token value re-registered to itself. The switch is thus registered in the token reference register.

[0115] When a token is transmitted between two subscriber units, both subscriber units simultaneously have knowledge of the token. To prevent the transmitting subscriber unit from also using the token on another (third) subscriber unit (so-called multiple token distribution), the transmitted token is preferably switched from the first subscriber unit to the second subscriber unit. The switching can preferably occur automatically upon receipt of a token in the second subscriber unit.

[0116] Alternatively or additionally, the switching process involves: generating a new private part of a token-specific key pair; applying a cryptographic function to obtain a corresponding public part of the token-specific key pair; creating the registration request using the token reference for the token to be switched and the public part of the token-specific key pair for the switched token.

[0117] The token value of the token to be switched corresponds to the token value of the token being switched. Therefore, during the switchover, a token with the same token value but a new private part is registered in the token reference register.

[0118] In one embodiment, the registration request relates to a linking of at least two tokens, and the registration request preferably includes a token reference of the linked token and a token reference of each of the tokens to be linked. The token references contained in the registration request can be concatenated. A merge is a modification option for a token that connects, or links, two token values. This makes it possible to merge two token values ​​into one token value in order to respond to a transaction request with token value accuracy. This invalidates the tokens to be linked, and the linked token is registered in the token reference register so that it can be verified in the transaction system.

[0119] Alternatively or additionally, the connection provides for: generating a new private part of a token-specific key pair; applying a cryptographic function to obtain a corresponding public part of the token-specific key pair for the connected token; calculating the token value for the connected token by forming the sum of the respective token values ​​of the at least two tokens to be connected; generating a token reference for the connected token comprising the calculated token value and the public part of the token-specific key pair for the connected token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token.

[0120] In one embodiment, a registration request is sent by a token issuer, wherein the registration request concerns the creation of a token or the deletion of a token.

[0121] In contrast to a participant unit, a token issuer is a privileged entity in the transaction system that can create and delete tokens. A participant unit cannot create or delete tokens; it can only modify tokens (switch, split, join).

[0122] The token is stored in a token memory to which the subscriber unit has exclusive access. This token memory can contain a plurality of tokens; for example, the plurality of tokens can be stored in a data memory of the subscriber unit. The data memory can be internal, external, or virtual, for example. In one embodiment, a "connection" can occur automatically upon receipt of a token, so that preferably only one (or a specific number) of tokens is stored in the subscriber unit.

[0123] The subscriber unit can be, for example, a mobile device such as a smartphone, a tablet computer, a computer, a server, or a machine. The subscriber unit can be a smart card that is inserted into a terminal device in a ready-to-use state.

[0124] The data storage is, for example, the wallet memory of an electronic wallet. The electronic wallet is, for example, a software application stored in an executable manner on a subscriber unit. The electronic wallet can enable the subscriber unit to participate in the transaction system. The electronic wallet can generate a registration request to register a token in a token reference register. Furthermore, the electronic wallet can make modifications (switching, connecting, splitting) to a token and generate any necessary registration requests and send them to the token reference register. Furthermore, the electronic wallet can transfer tokens to another wallet (in another subscriber unit).

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

[0126] The token reference register therefore has knowledge of token references of tokens in the transaction system and also performs the processing or modification of the tokens (token history). Transactions with tokens are not recorded in the token reference register and take place in a direct transaction layer of the transaction system directly between participating units of the transaction system.

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

[0128] In one embodiment, the token reference register comprises: at least one storage unit for storing token references for registering tokens in the transaction system; at least one verification unit for verifying whether a token reference of a received registration request is stored in the token reference register; an archiving unit for storing sequences of registration requests; and / or a re-registration unit for registering tokens newly generated by a token issuer or tokens deleted by a token issuer.

[0129] In a preferred embodiment, the storage unit is configured such that a subscriber unit or a registration request unit has only write access to the storage unit and / or the archiving unit and / or the verification unit has write and read access to the storage unit.

[0130] Separating the token reference register into a storage unit (no read access for a subscriber unit) and a verification unit (with write and read access to the storage unit) enables rapid processing of registration requests. This allows the storage unit to be updated based on a registration request, while a verification unit can read the storage unit for this purpose. The token reference register can be implemented in a DLT architecture or be designed as a central register with, if necessary, a plurality of verification units and, if necessary, a plurality of parallel-operating storage units.

[0131] The token reference register is configured to receive a plurality of registration requests, which are verified in parallel in a plurality of verification units to determine whether the at least one token reference contained in the respective received registration request can be uniquely assigned to a token of the transaction system. All registration requests in a sequence of registration requests are verified sequentially in the same verification unit. This allows the verification unit(s) to process individual registration requests, batches of registration requests, or even sequences of registration requests, enabling the aforementioned "load balancing." The sequences of registration requests can be processed sequentially. The verification unit does not require knowledge of whether the received registration request is part of a sequence of registration requests.

[0132] According to the invention, a transaction system is provided which comprises a register layer with a token reference register of the preceding type for registering token references and a direct transaction layer with a plurality of subscriber units, configured for the direct exchange of tokens among themselves.

[0133] According to the invention, a two-layer transaction system is provided, consisting of a direct transaction layer for the direct exchange of tokens and a register layer. No transactions are logged in the register layer; instead, only token references are stored, and modifications to tokens are stored via appropriately adapted token references for the purpose of verifying the validity of tokens. This ensures the anonymity of the transaction system's participants. The token reference register provides information upon request about the token references that are uniquely assigned to the transaction system's tokens, for example, to prevent multiple issuance of the same token or to verify the authenticity of the token.

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

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

[0136] According to the invention, a subscriber unit in a transaction system is also provided with: an interface which is arranged to transmit tokens to another subscriber unit and to send, to a token reference register or a registration request unit of the transaction system, a registration request from a sequence of registration requests, each registration request containing at least one token reference.

[0137] In addition, the subscriber unit has means of access to a token memory and / or the subscriber unit has a token memory, wherein at least one token of the subscriber unit with the sequence of registration requests is stored in the token memory.

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

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

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

[0141] Upon receiving a token from another subscriber unit, the received token is linked to the token in the token memory, generating a registration request for this purpose. Preferably, the registration request includes a token reference of the linked token and a token reference of each of the tokens to be linked.

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

[0143] Communication between the end device and the secure element as a subscriber unit can be carried out using APDUs. Communication between the end device and the token reference register or issuing unit can be carried out using API calls. The end device acts only as a protocol translator and does not modify the registration requests.

[0144] Communication between two subscriber units for exchanging tokens can be wireless, wired, or, for example, optical, preferably via QR code or barcode, and can be implemented as a secure channel. The exchange of tokens is additionally secured during transport, for example, by cryptographic keys, such as a session key negotiated for a token exchange or based on a key pair specific to each subscriber unit.

[0145] The invention and further embodiments and advantages of the invention are explained in more detail below with reference to figures, wherein the figures merely describe exemplary embodiments of the invention. Identical components in the figures are provided with the same reference numerals. The figures are not to be considered true to scale; individual elements of the figures may be exaggeratedly large or oversimplified. Fig. 1 shows an embodiment of a transaction system according to the invention; Fig. 2 shows an embodiment of a token reference register according to the invention; Fig. 3a shows an overview of inventive commands for tokens; Fig. 3b shows an overview of inventive signed registration requests for the inventive commands; Fig. 4shows an embodiment of a flowchart of a method according to the invention for creating and registering a token and an overview of the command details depending on the transaction layer; Fig. 5 shows an embodiment of a flowchart of a method according to the invention for deleting a token and registering it; Fig. 6 shows an embodiment of a flowchart of a method according to the invention for splitting and registering a token and an overview of the command details depending on the transaction layer; Fig. 7 shows an embodiment of a flowchart of a method according to the invention for connecting and registering a token and an overview of the command details depending on the transaction layer; Fig. 8shows an embodiment of a flowchart of a method according to the invention for switching and registering a token and an overview of the command details depending on the transaction layer; and Fig. 9 shows another embodiment of a token reference register according to the invention.

[0146] Fig. 1 shows an embodiment of a transaction system TS according to the invention. The transaction system TS comprises a register layer (TRR layer), in which a token reference register (TRR) is arranged. The TS also comprises a direct transaction layer (TE layer), in which a plurality of subscriber units (TE) can be provided; two subscriber units (TE1, TE2) are shown as representative.

[0147] The participant units TE of the transaction system TS are set up to exchange tokens T directly among themselves. In the case of Fig. 1The tokens are payment tokens, also known as digital coins. Each token T is generated by a token issuer TH (in Fig. 1 not shown, see Fig. 2 ). Each token T can be modified, divided, connected or switched by each subscriber unit TE (see Figures 6 to 8 ) and can be generated by the token issuer TH (See Fig. 4 ) and also deleted (see Fig. 5 ). A token issuer TH is, for example, a central bank.

[0148] A token T is uniquely represented in the transaction system TS by a token value v and a random number r as token elements. The token value v can be specified in a range from 1 to 2 31 < -1. The random number r can be a number in the range from 0 to 2 256 < -1, i.e., the order of an elliptic curve, for example, secp256r1.

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

[0150] For example, the token value v is a 32-bit token element of type integer. For example, the random number r is a 32-byte token element of type integer. A subscriber unit TE has exclusive access to this token memory or includes this token memory in a data memory of the subscriber unit TE.

[0151] A token can be stored as a TLV-encoded data record in a token store and then has a unique tag and length information, for example in the following format. name Day (hex) length Token value v Random number r TLV-encoded token 42 1 byte 4 bytes 32 bytes

[0152] An example of a TLV-encoded token in hexadecimal form is shown below: 42 24 00 00 40 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F and is interpreted as follows: "42" is the tag identifying the TLV-encoded token T; "24" indicates the length, in this case, that it is a 36-byte data record; "00 00 40 00" is the token value (integer) v = 16384, which is therefore €163.84; "00 01 02 03 04 05 06 07 08 09 ... 1D 1E 1F" is the random number r as an integer.

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

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

[0155] The token reference TR is then formed by the token value v of the token and the public part R of the key pair. The token reference TR is thus the link or concatenation of the token value v and the public part R.

[0156] This token reference TR can be used as a registration request RA, if necessary together with a command (see overview in Figures 3a and 3b ) regarding the token T are sent to the token reference register TRR.

[0157] Additionally, the registration request RA can be signed with the private part r of the token-specific key pair. Signing makes it possible to verify whether the sender of the token reference TR was in possession of the token T, further increasing the security of the transaction system TS.

[0158] In the subscriber unit, the signed registration request RAsig is stored as a so-called PROOF, for example in the following format: type Day (hex) length Data PROOF 4A N bytes

[0159] An example of a PROOF (=RA sig ) in hexadecimal form is shown below: 4A 81 8F 03 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 and is interpreted as follows (see also Fig. 8on the structure of a switch registration request): "4A" is the tag to identify the TLV proof RA sig_Th ; "81 8F" indicates the length; "03" indicates that it is a switch registration request; "11 12 13 14" is the token value vg ; "15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35" is the public part R g ; "36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56" is the public part R h ; "30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 3233 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 4142 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56" is the signature as an X690 sequence.

[0160] This registration request RA can be sent to the token reference register TRR. This registration request RA is received in the token reference register TRR. After the registration request RA is verified by the token reference register TRR, the token reference TR is stored in the token reference register TRR, thereby registering the token T in the transaction system TS.

[0161] The token reference TR is uniquely assigned to the token T and is used to register the token T in the transaction system TS. The token reference TR is therefore the public representation of the token T from the direct transaction layer (TE layer). The sole knowledge or possession of the token reference TR does not allow the transfer of the token T and is not synonymous with the TE being in possession of the token T. The token reference TR is used to prevent multiple issuance attempts and checks whether token values ​​v have been generated in an impermissible manner. Therefore, the token reference TR and, if applicable, the history of the token T and the corresponding registration requests RA from participant units (TE) are stored in the token reference register (TRR).

[0162] The tokens T are stored, for example, in token storage or electronic wallets of a TE. These wallets are, for example, software applications within the subscriber units TE or a terminal device in which the TE is integrated and ready for use. A wallet can be set up as an application on a smartphone, a smart card, or a payment terminal. The wallet is used to securely manage the TE's tokens T, generate token references TR, modify tokens T, and / or exchange tokens T. Wallets are used to communicate with the token reference register TRR, generate registration requests RA to the token reference register TRR, and / or perform transactions from token T to a subscriber unit TE.

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

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

[0165] For example, a token reference TR is transmitted from an electronic wallet as an APDU command(s) to a terminal device (smartphone) as a subscriber unit (TE). An APDU is a combined command / data block of a connection protocol between the secure element and the terminal device. The structure of the APDU is defined by the ISO-7816-4 standard. The terminal device unpacks the APDU command(s) and transmits the data in API calls to the token reference register (TRR), where it is converted into HTTP code.

[0166] In Fig. 2 an embodiment of a token reference register TRR of the invention is shown.

[0167] The token reference register TRR manages, in particular, the storage location for the token references TR, shown here as database 1 as an example of a storage unit in the token reference register TRR. The TR for the token T of the subscriber unit TE1 is entered in database 1. This database 1 can consist of a combination of many databases (see also Fig. 9 ), which are interconnected. To easily locate a token reference TR, the public part R of the token reference TR is simultaneously a database index in database 1, because both an index of a database and a public part R of a token reference TR must be unique in the transaction system TS.

[0168] In addition, the token reference register TRR can comprise at least one verification unit 2. The verification unit 2 of the token reference register TRR verifies registration requests RA. Syntactical correctness or the correct specification of a command in the registration request RA can be verified. In particular, the registration request RA can be checked for value neutrality. A history of old (past) registration requests RA regarding a token T can also be verified. Separating this verification unit 2 from the database 1 distributes the storage and checking tasks and increases the speed of the token reference register TRR.

[0169] In addition, the token reference register TRR can include a checking unit 3 that checks whether a total token value Σ in the transaction system TS has been changed (for example, using the token value v of a received token reference TR). The checking unit 3 compares a total reference value with the actual sum of the token values ​​stored in the database 1. If this is the case, then a new token value v has been created or an existing token value v has been destroyed. This is only permitted by privileged units, such as an issuing entity TH, in the transaction system TS. If such a change to the total sum of the token values ​​is detected by a token reference TR of a subscriber unit TE, then a case of fraud can be assumed. This makes it very easy to detect and prevent the illegal generation of token values ​​v.

[0170] The verification of the total token value by verification unit 3 represents a further security concept in the TS transaction system.

[0171] In addition, the token reference register TRR can include a re-registration unit 4, in which newly generated token references TR of a token issuer TH are initially registered, or token references TR to be deleted are deregistered. This achieves a functional separation between token references TR of privileged participants, such as a token issuer TH, and token references TR of unprivileged participants, such as the subscriber units TE. The token values ​​v of newly generated token references TR or token references TR to be deleted have a direct influence on a change in the total token value, which is monitored in the verification unit 3. The total reference value is adjusted accordingly when the token issuer TH initially registers or deregisters tokens.

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

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

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

[0175] In the token reference register TRR, an archiving unit 5 may also be present. Processed registration requests RA and / or processed sequences of registration requests RA F are stored in this archiving unit 5. Further details on the archiving unit are provided in Fig. 9 made.

[0176] The token reference register TRR, in particular the verification unit 2 of the TRR, receives and processes a registration request RA of a subscriber unit and / or receives a sequence of registration requests RA F as a sequence and processes this sequence RA F .

[0177] In Fig. 3aAn overview of CO commands that can be performed on a token T is shown. These CO commands can be modifications to an existing token T, for example, "Switch," "Split," or "Merge." The CO commands can also create a token T or destroy an existing token T. Fig. 3a Example command codes are given (0x01 to 0x05), which can then be part of a registration request RA.

[0178] In Fig. 3b An overview of CO commands and their signed registration request syntax RA is shown. Input tokens T and input token references TR are "consumed" for each CO command. Output token references TR are "generated" for each CO command.

[0179] A command CO (Registration Request RA) has the basic structure of the following three elements: command type, input token reference(s), output token reference(s).

[0180] Each command CA has a characteristic number of input token reference(s) ("inputs") and output token reference(s) ("outputs"), which are stored in the Figures 4 to 8 are explained and illustrated in more detail.

[0181] It should be noted that for the CO "Split," "Switch," and "Join" commands, the difference between the token values ​​v of all participating tokens T or token references TR must be zero. In other words, these CO "Split," "Switch," and "Join" commands do not create any token values ​​v and do not destroy any token values ​​v. This can be verified by the CO command itself or by the verification unit 3 of the token reference register TRR and is a verification criterion for a register query RA.

[0182] It should also be noted that only for the commands CO "Create" and "Delete" a difference between the token values ​​v of the involved token T or token references TR is permitted, but only up to the amount of the token value v of the token T and not beyond.

[0183] Each registration request RA can be signed to verify that the sender of the token reference TR also owns the corresponding token T. An ECDSA scheme can be used as the signature. The registration request RA is preferably signed with the private part r of the token T.

[0184] For signed registration requests RA sig of the command types CO "Create" and "Delete", an additional signature Sig TH of a token issuer TH is required to ensure that these commands have been generated by a privileged unit of the transaction system TS.

[0185] In Fig. 4An exemplary embodiment of a flowchart of a method according to the invention for creating a token T and registering it in the TRR is shown. In addition, the signed registration request RA sig and the command structure are shown in tabular form from the perspective of both the TE layer and the TR layer.

[0186] During creation, there are no input parameters in the TE layer. A privileged unit, here the token issuer TH, generates a random number r. Based on the random number r, a public part R is calculated, as described above. Thus, in the token issuer TH, a token reference TR can be formed from the token value v and the public part R by concatenating v and R.

[0187] A registration request RA consisting of the command "CREATE" or the command code according to Fig. 3aand the generated token reference TR is signed in the token issuer TH. The private key pKey of the token issuer TH is used for this purpose.

[0188] In the TE layer, the token T is issued to the TE1. In the TRR layer, the signed registration request RA sig is issued to the TRR.

[0189] In the token reference register (TRR), the signature of the registration request (RA) is verified against the public key (PKey) of the issuing entity (TH). This public key (PKey TH) is known throughout the transaction system or has been made available to the token reference register (TRR) in advance. If the signature verification is successful, the token reference (TR) is entered into the token reference register (TRR).

[0190] In one embodiment, the total token value of the transaction system TS in the checking unit 3 of the token reference register TRR is increased by the token value v by the re-registration unit 4 of the token reference register TRR.

[0191] In Fig. 5 An exemplary embodiment of a flowchart of a method according to the invention for deleting a token T and registering the deleted T in the TRR is shown. In addition, the required signed registration requests RA sig_TH and RA sig_T, as well as the command structure from both the TE layer and the TR layer, are shown in tabular form.

[0192] During deletion, the token T to be deleted is used as input parameter in the TE layer and the token reference TRR to be deleted and two signed registration requests RA sig_TH and RA sig_T are used in the TRR layer.

[0193] The registration request RA consisting of the command "DESTROY" and the token reference TR to be deleted is signed once with the private key pKey of the token issuer TH.

[0194] A further registration request RA consisting of the command "DESTROY" and the token reference TR to be deleted is also signed with the private part r of the token T.

[0195] Both signed registration requests are sent to the token reference register (TRR). In the token reference register (TRR), the signature is verified with the public key of the issuing entity (TH). This public key is known throughout the transaction system or was made available to the token reference register (TRR) in advance. Furthermore, the signature of the subsequent registration request (RA) is verified with the public part of the token reference (TR). If both signature verifications are successful, the token reference (TR) is deleted from the TRR or marked as deleted.

[0196] In one embodiment, the total token value of the transaction system TS is reduced by the token value v in the checking unit 3 of the token reference register TRR by the re-registration unit 4 of the token reference register TRR.

[0197] The token reference register TRR or the token issuer TH also initiates the deletion of the token T in the subscriber unit TE1.

[0198] In Fig. 6 An exemplary embodiment of a flowchart of a method according to the invention for splitting a token T a and registering the split tokens T b T c in the token reference register TRR is shown. In addition, the required signed registration request RA sig_Ta and the command structure from both the TE layer and the TR layer are shown in tabular form.

[0199] In the TE layer, TE1 generates a first random number rb and a second random number rc. Based on these, a public part Rb and Rc are then generated. The token Ta to be split is available as an input parameter in the TE layer. In the TE layer, the token value va is split into a first token sub-value vb and a second token sub-value vc. The sum of the token sub-value vb and the token sub-value vc must equal the token value va. This ensures that no new token value v is created and that no token value v is destroyed.

[0200] The token references TR b and TR c are then generated by TE1. The registration request RA then contains the command "SPLIT" or the corresponding Fig. 3ashown command code, the input token reference TR a and the output token references TR b and TR c . This registration request RA is signed with the random number ra of the token T a. The signed registration request RA sig_Ta is sent from TE1 to the token reference register TRR. There, the signature is verified and the sum of vb and vc is calculated and compared with the token value va. If va = vb + vc and the signature verification is successful, the token reference TR a is deleted from the token reference register TRR or marked as deleted, and the token references TR b and TR c are entered into the token reference register TRR.

[0201] In one embodiment, the token value difference between the input token reference TR a and the output token references TR b and TR c is calculated and checked in the token reference register in the verification unit 2; this difference is zero. If the difference is not zero, a token value v was generated or destroyed in an unauthorized manner. Furthermore, the total token value of the transaction system TS can also be checked in the verification unit 3 of the token reference register TRR before or after the registration of the token references TR b and TR c. The total token value v in the verification unit 3 must not have changed and must correspond to the value before the registration request was processed in the token reference register TRR.

[0202] The split token T b (or T c ) (which has been transferred from TE1 to TE2 in the meantime) can now be checked for validity by the subscriber unit TE2 in the TRR.

[0203] The registration request RA sigTa can be confirmed by the token reference register TRR through a registration confirmation RB.

[0204] In Fig. 7 An exemplary embodiment of a flowchart of a method according to the invention for connecting a token T d with a token T e and registering the connected token T f in the TRR is shown. In addition, the required signed registration requests RA sig_Td and RA sig_Te, as well as the command structure from both the TE layer and the TR layer, are shown in tabular form.

[0205] A random number rf is generated in a TE1 of the TE layer. Based on this number, a public part R f is then generated. Furthermore, the token values ​​vd and ve are summed to form the token value vf based on the input tokens T d and T e .

[0206] The output token reference TR f is then generated. A registration request RA then contains the command "MERGE" or the Fig. 3alisted command code, the two input token references TR d and TR e as well as the output token reference TR f . This registration request RA is signed once with the random number rd of the token T d in order to obtain a first signed registration request RA sig _Td. This registration request is also signed with the random number re of the token T e in order to obtain a second signed registration request RA sig_Te. Both signed registration requests RA sig _Td and RA sig_Te are sent by the subscriber unit TE1 to the token reference register TRR. There, the signatures of the registration requests RA sig_Td and RA sig_Te are checked. In addition, the sum of the token values ​​vd and ve is calculated and compared with the token value vf. If vf = vd + ve and both signature checks are successful, then TR d and TR e are deleted or marked as deleted in the token reference register TRR and the token reference TR f is entered in the token reference register TRR.The associated token T f (which has been transferred from TE1 to TE2 in the meantime) can now be checked for validity by the subscriber unit TE2 in the TRR.

[0207] In Fig. 8 An exemplary embodiment of a flowchart of a method according to the invention for switching a token T g to a token T h and registering the switched token T h in the token reference register TRR is shown. In addition, the required signed registration requests RA sig_Tg and the command structure from both the TE layer and the TR layer are shown in tabular form.

[0208] A random number rh is generated in a TE1. Based on this, a public part R h is then generated. Furthermore, the token value vh, which is identical to the token value vg of the input token T g, is generated.

[0209] The token reference TR h is then generated. A registration request RA then contains the command "SWITCH" or a corresponding command code according to Fig. 3a , the input token reference TR g and the generated public part R h (or the output token reference TR h ). This registration request RA is signed with the random number rg of the token T g . The signed registration request RA sig_Tg is sent by the subscriber unit TE1 to the token reference register TRR. There, the signature is verified. In addition, the token value vg is compared with the token value vh. If vg = vh and the signature verification is successful, the token reference TR g is deleted from the token reference register TRR or marked as deleted, and the token reference TR h is entered into the token reference register TRR.

[0210] In Fig. 9A further embodiment of a token reference register (TRR) of a transaction system (TS) is shown. Optional units are represented by dashed lines.

[0211] It is indicated here that multiple storage units 1 can be stored in the token reference register TRR. Storing a large number of token references TR in the token reference register TRR can thus be accelerated. It is also indicated that multiple verification units 2 can be stored in the token reference register TRR. The verification units 2 can accelerate the verification of registration requests RA. In particular, verification units 2 and / or storage units 1 can operate in parallel, for example, processing registration requests for different token references in parallel.

[0212] In addition, another participant unit TE B , for example a bank or a financial service provider, is shown. The token issuer TH can issue tokens directly to the participant units TE or indirectly via the another participant unit TE B to the participant units TE. This can function as an interface between the transaction system TS and a book money system (lending, account management). The another participant unit TE B also enables participant units TE to transfer tokens T of the transaction system TS to another transaction system. This transfer is bidirectional and optionally takes place with the use of the token issuer TH. The token issuer TH is solely responsible for generating token T and also for deleting token T.

[0213] In addition, Fig. 9An optional registration request unit RAE, which receives a sequence of registration requests RA F from a subscriber unit TE1. The registration request unit RAE can, for example, forward the RA F sequence to the TRR in its entirety or sequentially in individual RAs. Alternatively—not in accordance with the present solution—an RAE could also send only the individual RAs to the TRR, so that the TRR would have no knowledge of the presence of the RA F sequence.

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

[0215] In the previous Figures 1 to 8 a registration request RA was sent from a sequence of registration requests RA F. The TRR may initially remain unaware of whether the RA is an RA from a sequence RA F of RA or not.

[0216] It is now advantageous if the TE provides the entire sequence RA F of the registration request RA to the TRR as a sequence. The TRR can then also process the sequence RA F as a sequence. In particular, the TE can now receive only one registration response (also called registration confirmation) RB for the entire sequence RA F from the TRR.

[0217] Between the TE and the TRR a terminal device (not shown in Fig. 9) into which the TE is inserted and ready for operation. The terminal device can access the TE, for example, using an electronic wallet. The terminal device forwards the registration requests RA to the TRR. The terminal device receives the sequence RA F . Alternatively or additionally, a registration request unit RAE can also be provided as a mediating instance between the TE and the TRR, see Fig. 9 The RAE then receives the sequence RA F from the TE or the terminal device.

[0218] According to Fig. 9 The RAE receives the sequence RA F and sends individual RAs from the sequence RA F as part of the sequence to the TRR. The registration of the individual RAs is carried out according to the same scheme as in the Fig. 1 to 8 shown and explicitly referenced. Alternatively or additionally, the TRR receives the entire sequence RA F at once before the verification is performed, for example, in an API request. The TRR then processes each RA of this RA F individually.

[0219] The terminal device (not shown in Fig. 9 ) or the RAE attempts to transmit the entire RA F sequence to the TRR. This means that the terminal or the RAE only performs a protocol translation, for example from APDU between terminal / RAE and TE to HTTP(S). The RA F are neither evaluated nor interpreted by the terminal or the RAE. The order of the RA in the RA F sequence is not changed by the terminal or the RAE. The registration confirmation RB of the TRR is then transmitted by the terminal and / or the RAE to the TE. Each RA (as described above in the Figs. 1 to 8 shown) is signed with a private part r (the random number r) of a token-specific key pair. A corresponding proof (i.e., the respective RA) is stored in the TE (in the token memory).

[0220] The verification unit 2 of the TR checks the validity of all individual RAs in the sequence RA F (also called payload) one after the other and translates the final result for all RAs into a single RB. This RB has registration status information, for example, " 200 ", if all RA of the sequence RA F could be successfully verified and, for example, "400", if not all RAs in sequence RA F could be successfully verified. The RB is returned to the TE (possibly via the RAE or the terminal device). The RB can be signed with a private key pKey TRR of a key pair of verification unit 2. The RB can also include an RA sig, for example, all RAs in sequence RA F or only the last RA in sequence RA F .

[0221] The RAE or the terminal device receives an RB for the entire sequence RA F . This RB is sent to the TE so that the TE can check the validity of the RB and, if the validity is confirmed, remove the sequence RA F from the token memory (= delete all proofs of this token T).

[0222] If all RAs of the sequence RA F have been successfully verified, the verification unit 2 of the TRR (or an equivalent unit of the TRR) uses only the RA sig_T of the chronologically last RA of the sequence in its RB to the TE.

[0223] If one of the RAs of the sequence RA F could not be verified, the verification unit 2 of the TRR (or an equivalent unit of the TRR) uses only the RA sig_T of the first non-verifiable RA of the sequence RA F in its RB to the TE (a TR to which no T can be assigned).

[0224] The TE checks the registration information of the RB and behaves differently depending on whether all RAs in the sequence RA F have been verified successfully (e.g. status "200") or whether the verification of one RA in the sequence RA F has failed (e.g. status "400").

[0225] If all RAs in the sequence RA F are successfully verified (e.g. status "200"), the following algorithm is triggered in the TE: Step 1: Load the chronologically last RA of the sequence RA F from the token memory; Step 2: Verify the signature RA sig_T from the RB with the public part R. If the signature RA sig_T is not verifiable, continue with step 6; Step 3: If the RA sig_T of the RB is verifiable, the signature of Verification Unit 2 is verified with the public part PKey TRR of the key pair of Verification Unit 2; Step 4: If the signature of Verification Unit 2 is verifiable, delete all RAs of the sequence RA F from the token memory of the TE. If the chronologically last RA can be successfully verified in Verification Unit 2, then this means that all previous RAs of the sequence RA F must also have been verified. This occurs, for example, whenever the TE always holds (only) one token T and uses modifications (split / merge) to subtract or add further token values ​​v from the token value v of the token T.Step 5: If the signature of verifier 2 is not verifiable, the protocol has been violated. A man-in-the-middle attack is assumed; the registration requests RA are not deleted from the TE's token store. Step 6: If RA sig_T from the RB is not verifiable, the entire sequence is iteratively checked to find the RA for which the RA sig_T from the RB is verifiable. The sequence RA F can be iterated in two directions, either from the oldest RA to the newest RA or from the newest RA to the oldest RA. If a matching RA is found in the sequence RA F, steps 3 to 5 are executed.

[0226] This algorithm will now be explained using an example in which two modifications are made to a token T: Modification 1 (SPLIT, see also Fig. 6): The token value va of the token T a is divided by v = 100 into vb = 30 and into vc = 70. Modification 2 (MERGE, see also Fig. 7 ): The token value vb = 70 is combined with a token value vd = 50 of another token T d to form a new token value ve = 120.

[0227] The corresponding RA for the two modifications are: RA 1 = SPLIT , 100 , 8 , 30 , 9 , 70 , 10 RA 2 = MERGE , 70 , 10 , 50 , 6 , 120 , 11

[0228] The TE calculates (see also Figures 6 and 7 ) three RA sig_T : RA Sig 1 = sig r 1 , RA 1 RA Sig 2 A = sig r 2 , RA 2 RA Sig 2 B = sig r 3 , RA 2

[0229] RA Sig2A and RA Sig2B can be transmitted together or form a jointly signed RA. The TRR checks the validity and confirms all RA Sigs (=proofs) by returning the following response RB to the TE: Status = 200 , Sig 2 A , sig pKey TRR , 200 , Sig 2 A , Sig 2 B

[0230] If the verification of an RA in the sequence RA F fails (e.g. status "400"), the following algorithm is executed: Step 1: Find the chronologically oldest RA in the sequence RA F that is verifiable with the RA sig_T of the RB. The sequence RA F can be iterated in two directions, either from the oldest RA to the newest RA or from the newest RA to the oldest RA. Step 2: If the RA sig_T of the RB is verifiable with an RA in the sequence RA F, the signature of verifier 2 is verified with the public part PKey TRR of the key pair of verifier 2. If the signature of verifier 2 is not verifiable, the protocol has been violated. A man-in-the-middle attack is assumed, and the registration requests RA are not deleted from the token store of the TE. Step 3: If the signature of verifier 2 is verifiable, no RAs (proofs) are deleted.Optionally, failed RAs can be marked or the RBs can be stored in the TE's token store to make it easier to identify the failed RA if requested later.

[0231] This algorithm will now be explained using an example. Four modifications (SPLIT, MERGE, MERGE, SPLIT) are performed on a token T: Modification 1 (SPLIT, see also Fig. 6 ): The token value va of the token T a is divided by v = 100 into vb = 30 and into vc = 70. Modification 2 (MERGE, see also Fig. 7 ): The token value vb = 70 is combined with a token value vd = 50 of another token T d to form a new token value ve = 120. Modification 3 (MERGE, see also Fig. 7 ): The token value ve = 120 is combined with a token value vf = 40 of another token T f to form a new token value vg = 160. Modification 4 (SPLIT, see also Fig. 6): The token value vg = 160 is divided into vh = 100 and vi = 60.

[0232] The corresponding RA for the four modifications are: RA 1 = SPLIT , 100 , 8 , 30 , 9 , 70 , 10 RA 2 = MERGE , 70 , 10 , 50 , 6 , 120 , 11 RA 3 = MERGE , 120 , 11 , 40 , 5 , 160 , 13 RA 4 = SPLIT , 160 , 13 , 60 , 17 , 100 , 3

[0233] The TE calculates (see also Figures 6 and 7 ) six RA sig_T : RA Sig 1 = sig r 1 , RA 1 RA Sig 2 A = sig r 2 , RA 2 RA Sig 2 B = sig r 3 , RA 2 RA Sig 3 A = sig r 4 , RA 3 RA Sig 3 B = sig r 4 , RA 3 RA Sig 4 = sig r 6 , RA 4

[0234] RA Sig2A and RA Sig2B, as well as RA Sig3A and RA Sig3B, can be transmitted together or form a jointly signed RA. The TRR checks the validity and determines that RA3 is invalid and sends the following response RB back to the TE: Status = 400 , Sig 3 A , sig pKey TRR , 400 , Sig 3 A , Sig 3 B

[0235] It is not obvious to the TE that if the TRR sends an RB with status code 400, the token(s) T associated with this RB is / are forged. It may happen that all RAs within the TE are valid and contain genuine / valid tokens T, but the TRR still responds with an RB with status (error code) "400" to a registration request for the sequence RA F . The status (error code) "400" initially leads to an abort of the registration of the sequence RA F . In this case, the sequence RA F may already have been partially processed, and the storage unit 1 may have already been partially updated using parts of the sequence RA F .

[0236] This interruption or partial processing (processing) can occur due to network or transmission errors. For example, data transmission problems occur during the registration of the sequence RA F of registration requests RA. In such cases, the TRR responds with an error status code (e.g., "400") in the RB, which does not necessarily mean that the relevant tokens T of the TE are counterfeit.

[0237] According to the invention, a data protection and data integrity mechanism now provides for detecting any type of manipulation of the sequence RA F during transmission to the TRR. Before sending the sequence RA F , the TE calculates a secure checksum (e.g., hash value) for the sequence RA F (preferably without the signatures) and securely stores the hash / checksum result in the TE's token memory. This hash / checksum result is confidential and is not transmitted outside the TE. If the TRR's verification unit 2 wishes to register the sequence RA F , the TRR's verification unit 2 also calculates a secure hash / checksum for the sequence RA F . Later, the TRR's verification unit 2 will only include this hash / checksum result in the RB in the event of error scenarios (e.g., error status code "400").In case of an error, this additional hash / checksum in the RB helps to analyze whether the error occurred due to transmission manipulation / errors or due to a forged token T. The verification unit 2 of the TRR can optionally also include this hash / checksum result in the RB (e.g., in the signature of the RB) in case of success scenarios (e.g., success status code "200").

[0238] The hash / checksum can be part of the signature of Verification Unit 2. When the TE now verifies the signature of Verification Unit 2, the TE must retrieve the stored hash / checksum from its token memory. If the TE can establish this association, it means that the sequence RA F has not been tampered with (e.g., by an intermediary entity such as a terminal device, RAE, or a man-in-the-middle entity).

[0239] The process (sending the sequence RA F ) will then simply be repeated; the corresponding RAs with signatures will still be present in the TE. The partially processed sequence RA F can be obtained from an archiving unit 5 of the TRR.

[0240] This abort or partial processing (processing) can also or alternatively be due to incorrect behavior of a TE. For example, a malicious TE intentionally changed either the order of the RAs or the syntax of the RAs, resulting in the TRR being unable to verify the RA (fraud attempt). For example, invalid RAs were received in the sequence RA F due to incorrect behavior of the TE, data transmission errors, or other reasons.

[0241] If the TE receives an RB with error status code 400, it first identifies the failed RA, see above. Using the associated hash / check result, the TE can also attempt to verify the signature of Verifier 2.

[0242] If signature verification fails, either the RA F data was tampered with during transmission, or the response did not come from Verification Unit 2, but a third party impersonated Verification Unit 2 but failed to generate a valid signature. The TE then ignores the RA without making any changes to the TE's token memory.

[0243] This termination or partial processing (execution) can also or alternatively occur due to a non-assignable TR. For example, there was never an assignable token T (fraud attempt), or the assignable token T has already been modified (split, merge, switch) and a token reference TR exists in the TRR for this modification, or the assignable token T has already been spent (illegal multiple spend attempt), or the assignable token T has been deleted (token value v has been redeemed).

[0244] Such an analysis requires a proper examination using the archiving unit 5 (and, if applicable, the audit unit 3 and / or the re-registration unit 4).

[0245] In such a case, the TRR moves the entire outstanding RA F to the archiving unit 5. This application can also be installed on an ATM terminal or a web server. It specializes in analyzing and correcting accounting errors and creating a blacklist of counterfeit tokens T (based on the token references TR) currently circulating in the offline world. The goal is to reset the TE and the token storage (including the RA F sequence) and load a replacement token T onto the TE.

[0246] The TE or the RAE or the terminal sends the (entire) sequence RA F to the archiving unit 5 together with the RB of the verification unit 2 of the TRR. The RB can serve as confirmation that the registration of the sequence RA F was aborted.

[0247] The TRR's archiving unit 5 checks each RA in the sequence RA F both syntactically and semantically with the help of the TRR's verification unit 2. For this purpose, the archiving unit 5 has read / write access to the TRR's storage unit. The TRs within an RA are checked individually.

[0248] Those TRs that are unknown to the verification unit 2 of the TRR are stored in an active part of the archiving unit 5. The verification unit 2 of the TRR also has access to this active part of the archiving unit 5.

[0249] Archiving Unit 5 can request transaction log records from the TE corresponding to the failed RAs and the RAs or TRs listed in Archiving Unit 5. This information from the TE can be used to identify and track malicious TEs.

[0250] The archiving unit 5 can have replacement tokens created with the entire token value (including the token values ​​from the archiving unit 5) or only from the verified RA and valid TR according to the storage unit 1, for example by the re-registration unit 4.

[0251] The TE’s token storage is emptied and recharged with this replacement token.

[0252] The value neutrality of the registration requests RA is checked in verification unit 2. For each registration request from a subscriber unit TE, it checks whether the sum of the input token values ​​equals the sum of the output token values. Verification unit 3 checks the total value of the stored token values ​​in storage unit 1, for example, before or after processing a sequence RA F and / or at selected times (periodically or quasi-randomly). Verification unit 3 compares the currently stored total token value with a reference value. The reference value is adjusted when the token issuer TH deletes or initially registers tokens via its interface, the re-registration unit 4. LIST OF REFERENCE SYMBOLS

[0253] CO Command (type) PKey TH public part of the token issuer key pair pKey TH private part of the token issuer key pair PKey TRR public part of the verifier key pair pKey TRR private part of the verifier key pair R public part of the token-specific key pair r private part of the token-specific key pair RA F sequence of registration requests RA L last registration request in the sequence of RA F RA registration request RA sig_T registration request signed with private part of the token-specific key pair RA sig_TH registration request signed with private part of the token issuer key pair RAE registration request unit RB registration response, registration confirmation T token TE subscriber unit TE B subscriber unit bank TE layer direct transaction layer TRR layer register layer TH token issuer TR token reference TRR token reference register 1 database,Storage unit 2 Verification unit 3 Testing unit 4 Re-registration unit 5 Archiving unit TS Transaction system TW Token value ah Indices for various tokens and token references Σ Total token value of the transaction system,

Claims

1. Method for registering tokens (T) of an electronic transaction system (TS) that comprises secure elements as transaction units (TE), wherein each token (T) of the transaction system (TS) has at least one token value (v) and a private portion (r) of a token-specific key pair as token elements, having the method steps of: - receiving registration requests (RA) in a token reference register (TRR) of the transaction system (TS), wherein the registration requests (RA) each have at least two token references (TR), at least one token reference (TR) of a first registration request (RA) of the registration requests (RA) and one token reference (TR) of a second registration request (RA) of the registration requests (RA) being identical; - verifying, by way of a verification unit (2) of the token reference register (TRR), whether a token reference (TR) of a registration request can be uniquely assigned to a token (T) of the transaction system (TS), wherein the token reference (TR) is checked for whether it is or was stored in the token reference register (TRR); - storing at least one token reference (TR) other than the checked token reference in the storage unit (1) of the token reference register (TRR) in order to register the token (T) uniquely assigned to this token reference (TR) in the transaction system (TS) if the verification step determines that a token (T) of the transaction system (TS) can be assigned to the checked token reference (TR); characterized in that the step of receiving receives the registration requests (RA) in the token reference register (TRR) as a sequence (RAF) of registration requests (RA), and the steps of verifying and storing process the registration requests (RA) in the token reference register (TRR) as a sequence (RAF) of registration requests (RA).

2. Method according to Claim 1, wherein each token reference (TR) except the other token reference (TR) from the sequence (RAF) of registration requests (RA) was or is uniquely assigned to a token (T) in the transaction system (TS) and wherein in particular the tokens (T) were transferred directly between subscriber units (TE) of the transaction system (TS) in a direct transaction layer (TE layer) of the transaction system (TS), and / or were modified by a subscriber unit (TE), without these tokens (T) having been registered in the transaction system (TS).

3. Method according to Claim 1 or 2, wherein the step of receiving receives the registration requests (RA) as a sequence (RAF) of registration requests (RA) of one of the secure elements (TE); and / or at least the first and second registration requests (RA) in the sequence contain a previously unregistered token that is present in the subscriber unit, in particular the secure element.

4. Method according to one of Claims 1 to 3, wherein the entire sequence (RAF) of registration requests (RA) is received in the token reference register (TRR) before the verification step is performed; and / or the step of verifying is performed for at least one token reference (TR) from each registration request (RA); and / or the step of storing is performed for the other token reference, in particular in each case, if the other token reference is not yet stored; and / or at least three registration requests (RA) in the sequence (RAF) comprise a token reference (RA) that is also a token reference (TR) of another registration request (RA) in the sequence (RAF).

5. Method according to one of the preceding claims, wherein the entire sequence (RAF) of registration requests (RA) is transmitted from a subscriber unit (TE) of the transaction system (TS) to a registration request unit of the transaction system (TS) before the verification step is performed and wherein the token reference register (TRR) sequentially receives from the registration request unit, and verifies, each registration request (RA) from the sequence of registration requests (RA) before the next registration request (RA) from the sequence (RAF) of registration requests (RA) is received and verified.

6. Method according to one of the preceding claims, wherein the sequence (RAF) of registration requests (RA) is stored in an archiving unit (5) of the token reference register (TRR); and / or wherein each registration request (RA) from the sequence (RAF) of registration requests (RA) is stored in an archiving unit (5) of the token reference register (TRR), preferably in a first part of the archiving unit (5), when the verification step determines that the checked token reference (TR) of one of the registration requests (RA) in the sequence (RAF) of registration requests (RA) cannot be uniquely assigned to a token (T) of the transaction system (TS), wherein a sequence (RAF) of registration requests (RA) with token references (TR) is preferably stored in a second part of the archiving unit (5) if all token references (TR) of the sequence (RAF) of registration requests (RA) can each be uniquely assigned to a token (T) of the transaction system (TS).

7. Method according to one of the preceding claims, wherein the token references (TR) of the sequence of registration requests are verified chronologically backwards; and / or wherein each token reference (TR) has at least the token value (v) of the token (T) and a public portion (R) of the token-specific key pair as token reference elements, wherein the public portion (R) of the token-specific key pair was obtained by applying a cryptographic one-way function to the private portion (r) of the token-specific key pair of the token (T); wherein the registration request (RA) is preferably signed with the private portion (r) of the token-specific key pair in order to be able to verify an assignment of the token reference (TR) to the token (T).

8. Method according to one of Claims 1 to 7, wherein each token reference (TR) was obtained by masking the assigned token (T) by applying a homomorphic one-way function (f(C)) to the token (T).

9. Method according to one of the preceding claims, having the further method steps of: - creating, by way of the verification unit (2) of the token reference register (TRR), a registration response, wherein the registration response indicates a result of the verification step; - transmitting the registration response to a subscriber unit (TE) or registration request unit of the transaction system (TS) that sends the registration request (RA) from the sequence (RAF) of registration requests (RA), wherein the subscriber unit (TE) preferably has the token (T) of the at least one token reference (TR) of the sequence (RAF) of registration requests (RA).

10. Method according to one of the preceding claims, wherein - the sequence (RAF) of registration requests (RA) is provided by a subscriber unit (TE), and / or - wherein each registration request (RA) in the sequence (RAF) has at least one token reference (TR) as an output token reference and at least one input token reference, and / or - wherein the registration requests (RA) in the sequence (RAF) are linked to each other, in particular a respective output token reference of a registration request (RA) in the sequence forms an input token reference of the next registration request (RA) in the sequence.

11. Token reference register (TRR) for a transaction system (TS), configured to perform the method steps according to one of the preceding claims, wherein the token reference register (TRR) preferably comprises: - at least one storage unit (1) for storing token references (TR) in order to register tokens (T) in the transaction system (TS); - at least one verification unit (2) for verifying whether a token reference (TR) of a received registration request (RA) is stored in the token reference register (TRR); - an archiving unit (5) for storing sequences of registration requests (RA); and - a re-registration unit (4) for registering tokens (T) re-generated by a token issuer (TH) or tokens (T) erased by a token issuer (TH).

12. Token reference register (TRR) according to Claim 11, wherein the storage unit is configured such that: - a subscriber unit (TE) or a registration request unit (RAE) has only write access - in particular by means of registration requests - to the storage unit (1); and / or - the archiving unit (5) and / or the verification unit (2) have read and write access to the storage unit (1); and / or wherein the token reference register (TRR) is configured to receive a multiplicity of registration requests, which are verified in parallel in a plurality of verification units to ascertain whether the at least one token reference (TR) contained in the respective received registration request (RA) is uniquely assigned to a token (T) of the transaction system (TS), wherein all registration requests in a sequence of registration requests are sequentially verified one after the other in the same verification unit in each case.

13. Secure element as a subscriber unit (TE) for use in a transaction system (TS) according to Claim 16, having: - an interface configured to: o transfer tokens (T) to another subscriber unit (TE); o transfer, to a token reference register (TRR) or a registration request unit of the transaction system (TS), a registration request (RA) comprising at least one first and a second token reference (TR); - an access means for accessing a token memory or token memories, wherein at least one token (T) of the secure element is stored in the token memory; and - a computing unit configured to: o apply a cryptographic one-way function to a private portion (r) of a token-specific key pair of a token (T) of the token memory in order to obtain a token reference (TR); and ∘ modify tokens (T).

14. Secure element as a subscriber unit according to Claim 13, wherein a sequence (RAF) of registration requests (RA) is stored in the token memory; and / or wherein the subscriber unit is configured to transmit registration requests (RA) to the token reference register (TRR) as a sequence (RAF) of registration requests (RA); and / or wherein the subscriber unit is configured to obtain only one registration confirmation for the sequence (RAF) of registration requests (RA) from the token reference register (TRR).

15. Secure element as a subscriber unit according to Claim 13 or 14, wherein only one token is stored in the token memory; and / or wherein to transfer a token to another subscriber unit the token (Ta) is split, wherein a registration request (RA) is generated for this purpose, wherein the registration request (RA) preferably has a token reference (TRa) of the token (Ta) to be split and a token reference (TRb, TRc) of each of the split tokens (Tb, Tc); and / or wherein when a token is received from another subscriber unit, the received token (Te) is connected to the token in the token memory, wherein a registration request (RA) is generated for this purpose, wherein the registration request (RA) preferably has a token reference (TRf) of the connected token (Tf) and a token reference (TRd, TRe) of each of the tokens (Td, Te) to be connected.

16. Transaction system (TS) comprising: - a register layer (TRR layer) having a token reference register (TRR) according to Claims 11 to 12 for registering token references (TR); and - a direct transaction layer (TE layer) having a multiplicity of subscriber units (TE) configured to directly exchange tokens (T) with each other; wherein the register layer preferably comprises a registration request unit, wherein the entire sequence of registration requests (RA) is transmitted from a subscriber unit (TE) of the transaction system (TS) to the registration request unit of the transaction system (TS) before the verification step is performed, and wherein the token reference register (TRR) receives the registration request (RA) from the sequence of registration requests (RA) from the registration request unit.