WO2024027869A1 - Élément sécurisé, procédé d'enregistrement de jetons et registre de référence de jeton - Google Patents

Élément sécurisé, procédé d'enregistrement de jetons et registre de référence de jeton Download PDF

Info

Publication number
WO2024027869A1
WO2024027869A1 PCT/DE2023/100487 DE2023100487W WO2024027869A1 WO 2024027869 A1 WO2024027869 A1 WO 2024027869A1 DE 2023100487 W DE2023100487 W DE 2023100487W WO 2024027869 A1 WO2024027869 A1 WO 2024027869A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
validity
trr
transaction
token reference
Prior art date
Application number
PCT/DE2023/100487
Other languages
German (de)
English (en)
Inventor
Klaus ALFERT
Lars HUPEL
Matthias Fasching
Peter Zeller
Original Assignee
Giesecke+Devrient Advance52 Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke+Devrient Advance52 Gmbh filed Critical Giesecke+Devrient Advance52 Gmbh
Publication of WO2024027869A1 publication Critical patent/WO2024027869A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3676—Balancing accounts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending

Definitions

  • the invention relates to a method for registering tokens, in particular a secure element as a transaction unit, to a secure element and to a token reference register in which token references are stored that are clearly assigned to a token, as well as to the transaction system as a whole.
  • systems or portable data carriers are known as secure elements for transferring monetary amounts in the form of electronic data sets, in which payment with duplicates of the data set is prevented and a high degree of security against manipulation is provided is.
  • Complex structures and complex encryption and signing processes are required for the transactions.
  • the security of transactions and the associated transaction data includes protecting the confidentiality of the data exchanged; as well as protecting the integrity of the data exchanged; as well as protecting the availability of the exchanged data.
  • token-based systems As solutions for secure transaction systems, a distinction is often made between token-based systems and account-based systems.
  • account-based systems In addition to conventional account-based systems, such as credit or credit accounts, more novel account-based systems based on blockchain topologies have recently been discussed.
  • the account-managing unit has access to the data record that represents the monetary amount.
  • the newer account-based systems provide a high level of integrity protection, they also publish a lot of information, for example when records exist in a freely readable data structure and change hands there.
  • a token register It is also already known to expand a token-based transaction system to include a token register.
  • the secure element sends a registration request for its token to the register.
  • the registry verifies the registration request and, for example, only stores a token reference for the token, so it does not know the token itself.
  • WO 2020/212337 Al describes a transaction system in which even modifications of tokens - for example by splitting the token, are possible offline, i.e. directly between the secure elements of the transaction system and without any further control instance.
  • the tokens can be transferred immediately without having to register a modification in a token register of the transaction system.
  • the registration of the modification in the token register can take place independently of the actual transaction, the transfer of the token.
  • the secure elements are known to be resource-limited, particularly limited in terms of storage space, processing speed, transmission time and/or speed.
  • the invention is based on the object of providing a new method that is more suitable for a secure element as a transaction unit, and is therefore particularly resource-saving.
  • the processes in the transaction system such as the direct transfer of tokens between the transaction units and the registration of tokens in the register, as well as the associated advantages and possible uses should preferably be retained.
  • several modification details of a transaction unit should be processed in a resource-saving manner.
  • a secure element of an electronic transaction system has a token storage for tokens of the transaction system and is set up to exchange tokens directly with another transaction unit of the transaction system.
  • a token reference is uniquely assigned to each token in the transaction system. Token references (and thus the assigned tokens) can be registered in a token reference register of the transaction system.
  • the secure element is further set up to generate at least one output token and its output token reference based on at least one input token.
  • the secure element provides at least one modification indication for the token reference register, which includes at least one input token reference, a command and at least one output token reference. Now the secure element provides the at least one modification information as a validity request and receives a confirmation of validity for at least one output token reference of the validity request to be checked for validity.
  • Sending the modification information in a validity request enables, as explained in more detail below, a variety of initially seemingly small advances, which can ultimately be helpful for the secure element and even for the token reference register. Since the token reference register can process the validity request with (only optional) modification information faster on average than a conventional registration request, the connection or transmission time is reduced and thus the effort in the secure element to manage the connection, in particular to maintain it (timeouts. . .) or restore.
  • the validity request can preferably include the at least one output token reference to be checked and at least one output token reference not to be checked. This means that not all output token references need to be checked for validity.
  • the validity request can include the modification information and additionally a verification information that specifies the at least one (or more) output token reference(s) to be checked.
  • the test information can, for example, contain the output token reference(s), contain one (or the) reference(s) to the output token references or also encoded by one (or more) set flag(s) for the output token reference(s). be.
  • Flags are typically bits that are either set or unset. For example, for each output token reference of the validity request or the modification statement, a flag would be provided that could either be set or not set.
  • the checking information relates to output token references of at least two different modification details of the validity request.
  • the secure element could be set up to provide modification information either as a validity request or as a registration request.
  • the secure element could use the following as a selection criterion for sending as a validity request:
  • - use a time criterion, in particular with the help of a timestamp, for example a transaction and/or modification or the last communication with the token reference register, and/or - an origin criterion, for example if the modification information was received, in particular from another transaction unit.
  • a timestamp for example a transaction and/or modification or the last communication with the token reference register
  • an origin criterion for example if the modification information was received, in particular from another transaction unit.
  • the secure element can always send one (or more) modification information as a validity request.
  • the confirmation of validity includes a separate cryptographic confirmation, such as a checksum or signature, for each output token reference to be checked. It can also be advantageous if the confirmation of validity includes a common cryptographic confirmation, such as a checksum or signature, for all output token references to be checked (or only for these).
  • the cryptographic confirmation(s) for the output token reference(s) to be checked are preferably stored in the secure element and/or transmitted to another transaction unit together with the associated token(s).
  • the validity request can include several modification details, in particular a stack and/or at least one sequence of modification details.
  • Modification statements that are independent of one another (in their token references) are referred to here as a stack.
  • the modification information of a batch can be processed in the token reference register in any order.
  • Modification statements that depend on one another (in their token references), on the other hand, are referred to as a sequence (or sequence).
  • At least one output token reference of one modification information is also the input token reference of another modification information.
  • the sequence preferably comprises several output token references, which are also the input token reference of a subsequent modification statement in the sequence.
  • the modification information of a sequence cannot be processed in any order in the token reference register.
  • the token reference register will execute the modification information of the sequence(s) in particular in the order in which they are present in the validity request or which is specified in the validity request.
  • the modification statement(s) of the validity request is (are) only to be carried out optionally.
  • the token reference register can send a confirmation of validity even in the event of one (or more) incorrect modification details. Whether the token reference register checks and, if necessary, executes the modification information and/or which of the modification information has been checked and executed is independent of the confirmation of validity for the at least one (or more) output token reference(s) to be checked. .
  • the validity request can be a request for a token reference register that stores only the valid token references in a storage unit for token references to check whether the output token reference (s) to be checked is (are) already stored in the storage unit.
  • the secure element regularly comprises a processor, in particular for carrying out the steps as a transaction unit, and/or an interface, in particular to a local terminal, via which the validity request for the token reference register (TRR) is provided.
  • a transaction unit can be a participant unit or is sometimes referred to as such below.
  • the or each token will comprise, as data elements, in particular a token value and a secret token element, which is in particular a secret key of a key pair.
  • Token references can include, as data elements, a token value, in particular the token value of the token, and a public token element, in particular the public key of the token's key pair.
  • a modification is in particular a splitting and/connecting or switching of tokens.
  • the command for the modification specification is, for example, “split”, “connect” or “switch”.
  • One (or more) input tokens with one (total) token value can be split into several output tokens with a different token value (but the same total value).
  • Two or more input tokens with a total value can be combined to form an output token with the total value.
  • An input token with a token value can be switched to an output token with the same token value.
  • the transaction unit for example the security element, can generate one (or more) output tokens, in particular including the token value and secret token element, as well as the assigned output token reference for the modification information.
  • the transaction unit for example the security element, stores your tokens and optionally one or more modification details.
  • the modification information is stored together with or at least linked to the initial token.
  • the security element can preferably delete the modification information(s) stored in the security element and contained in the validity request in response to receipt of the validity confirmation.
  • Tokens can be directly exchanged with other transaction units. For tokens that have not yet been registered, the token must be transferred together with the modification information(s). Tokens that have already been registered can be transferred without the modification information.
  • the present invention provides a method for checking the validity of a token of a secure electronic transaction system.
  • a token reference is uniquely assigned to each token in the transaction system.
  • a token reference register of the transaction system includes a verification unit and a storage unit in which the token references of valid tokens are stored. The following steps are carried out in the token reference register:
  • the validity request includes a check information that specifies the at least one output token reference to be checked and/or the modification information that is only optionally to be processed.
  • the checking (and optionally the receiving and sending) is preferably carried out by the verification unit of the token reference register. Receiving and sending can be done through an interface unit of the token reference register.
  • the verification unit preferably processes modification information, i.e. optionally also the modification information(s) of the validity request, with one or more of the sub-steps:
  • the confirmation of validity is sent - in particular without further processing of the modification information - if the output token reference(s) to be checked of the validity request are already stored in the storage unit. Otherwise, the modification information(s) will be processed.
  • the confirmation of validity can be sent alternatively or additionally after the processing of the (one or more) modification details that can only be processed optionally has been omitted completely or in partial steps, i.e. none of the partial steps have been carried out or not all partial steps have been carried out.
  • the validity request preferably includes at least one, more preferably several, output token reference(s) that cannot be checked for validity.
  • Validation confirmation may include a separate cryptographic confirmation, such as signature or checksum, for each output token reference to be verified.
  • the output token reference to be checked for validity does not have to be explicitly displayed in the check details of the validity request. It can be one of the initial token references included in the modification statement. However, the token reference(s) to be checked is/are preferably received from the token reference register in the checking information, as an independent data element of the validity request.
  • the check information can be formed by one (or more) reference(s) to the output token reference(s) to be checked (for example position or number of the output token reference in the validity request) or contain the output token reference(s).
  • the validity request may include multiple modification statements, each modification statement including one or more input token references, one or more output token references and a command.
  • the modification information is preferably a stack of modification information and/or a sequence of modification information. Stacks consist of independent modification statements. Sequences consist of at least partially interdependent modification information.
  • the token to be checked can be transferred directly between two transaction units of the transaction system in the direct transaction layer of the transaction system (but does not have to have been transferred yet).
  • the token to be checked has preferably been modified in a transaction unit without the token being registered in the transaction system.
  • the confirmation of validity is preferably also sent if some of the several modification details cannot be carried out (the assignment of the token references to tokens of the transaction system is therefore partially not possible), in particular if these modification(s) are only made in the direct transaction layer without registering the modification(s). in the token reference register. It is therefore not a prerequisite for the validity check that all modification information in a validity query can be traced or carried out by the verification unit. Only the assignment of at least one token reference to be checked must be verifiable. Verification thus takes place independently of registration of one or more modifications from the modification information in the token reference register.
  • the verification unit of the token reference register can send memory queries and/or memory instructions to the storage unit of the token reference register. For example, it can query whether a token reference is stored in the storage unit and/or instruct a token reference to be saved or deleted.
  • the verification unit sends to the storage unit a common memory query for output token references of different modification information and/or for output token references and input token references of at least one modification information.
  • the token reference register can send a partial validity confirmation.
  • the partial validity confirmation preferably concerns the valid output token references of the output token references of the stack to be checked for validity.
  • the verification unit can only temporarily store at least one (or) output token reference(s) of at least one modification information internally (i.e. not store it in the storage unit).
  • the buffered output token reference(s) is discarded if it is the input token reference of a further modification information or otherwise stored in the storage unit.
  • At least one (or more) output token reference(s) of a modification statement is only stored in the storage unit after checking one, several or all further modification statements of the sequence.
  • the token reference register can carry out the method with a transaction unit or the secure element already described.
  • the token reference register can further include further verification units and/or an archive unit which stores no longer valid token references and/or validity requests and/or registration requests that have already been carried out.
  • a token reference register for a transaction system is set up to carry out one of the aforementioned methods, in particular with a transaction unit TE of the transaction system or with one of the aforementioned secure elements.
  • the token reference register includes the storage unit for storing the valid token references in the transaction system; an interface set up to receive a validity request and the at least one verification unit.
  • a transaction system includes a register layer with the token reference register; and a direct transaction layer with a variety of transaction units, including a secure element.
  • the validity requests in the transaction system can be distributed to different verification units of a token reference register and these can therefore be processed in parallel by different verification units of the token reference register. This means that a large number of validity requests can be divided internally in the token reference register between different verification units (“load balancing”).
  • the confirmation of validity and/or the valid output token reference(s) to be checked is preferably signed with a private part of a key pair of the token reference register, preferably the verification unit (possibly one of a plurality of verification units).
  • This signature is verified by the transaction entity upon receipt of the confirmation of validity with the public part of the key pair of the token reference register.
  • This increases security because validity confirmations generated by unauthorized third parties - for example as part of man-in-the-middle attacks - are recognized by a transaction unit due to a missing or invalid signature. Such confirmations of validity can then be ignored by the transaction entity.
  • a token is a data record of a transaction system that can be directly exchanged between transaction units. With knowledge of the token, the receiving transaction entity is in possession of the token value that the token represents. When you swap, the token changes therefore automatically the owner.
  • a token - a record that is transferable independently of a transaction topology, such as blockchain topologies - can be transferred directly between transaction entities without any intervening entities.
  • the token is an electronic coin data record or payment token for exchanging monetary amounts between transaction units.
  • a payment token is also colloquially referred to as a “digital coin” or “electronic coin” and represents cash in electronic form.
  • Each token in the transaction system is a data record comprising at least two token elements.
  • a first token element of each token of the transaction system is a token value, for example an asset, an asset, an asset and/or a monetary amount.
  • a second token element of each token of the transaction system is a private part of a token-specific key pair.
  • This private part is a secret in the transaction system and is not published and may not be used multiple times. The generation of the private part must not be predictable.
  • This private part can be a random number. The random number is preferably the result of a true random generator.
  • the token is formed from the token value (first token element) and the private part. This formation is preferably the chaining (concatenation) of these two token elements. Any other type of linking of these two token elements is not excluded according to the invention and includes, for example, appending one after the other, inserting them into a TLV data structure and/or logical linking.
  • Each token in the transaction system is assigned a token reference.
  • This assignment is one-to-one, which means that exactly one token reference is assigned to a token and exactly one token is assigned to each token reference.
  • the token reference is a public data record that is stored in a storage unit of the token reference register of the transaction system in a verifiable manner for each transaction unit. Both the token and the token reference are unique. Due to the unique assignment, there is a 1-to-1 relationship between the token and the token reference.
  • Each token reference in the transaction system is a data record comprising at least two token reference elements.
  • a first token reference element at each token reference is the token value of the token uniquely assigned to the token reference.
  • the token value of the token is therefore identical to the token value of the assigned token reference.
  • the token value of the token reference is a copy of the token value of the associated token.
  • a second token element of each token reference of the transaction system is a public part of the token-specific key pair.
  • This public part of the token reference together with the private part of the token, forms the token-specific key pair.
  • the public part is obtained by applying a cryptographic function to the private part.
  • This cryptographic function is a one-way function.
  • This cryptographic function is therefore a mathematical function that is “easy” to calculate in terms of complexity theory, but “difficult” to practically impossible to reverse.
  • the term one-way function also refers to a function for which there is currently no known reversal that can be practically carried out in a reasonable amount of time and with reasonable effort.
  • a one-way function is used that operates on a group in which the discrete logarithm problem is difficult to solve, such as B.
  • a cryptographic process analogous to elliptic curve encryption, ECC for short from a private key of a corresponding cryptography process.
  • the reverse function i.e. the creation of a token (or part of the electronic coin data set) from a token reference, is very time-consuming.
  • the (mere) knowledge or possession of a token reference does not authorize the use/transfer/issue of the token value (token reference element). This represents a significant difference between the token reference and the token and is a core of the present invention.
  • the public part of the token-specific key pair is obtained as the second token reference element.
  • the token reference is formed from the token value (first token reference element) and the public part. This formation is preferably the concatenation of these two token reference elements. Any other type of linking of these two token reference elements is not excluded according to the invention and includes, for example, adding them one after the other, introducing them into a TLV data structure and/or logically linking them.
  • a token reference can preferably be generated by an electronic wallet of a transaction unit. To do this, the transaction unit must have knowledge of the token and its token elements. Generating the token reference can be done by an electronic wallet of a transaction entity that wants to send the token. Alternatively, the token reference can be generated by an electronic wallet of a transaction entity that has received the token.
  • a token reference is not comparable to the use of addresses of transaction units in a blockchain-based transaction system, since no addresses of the transaction units are used in the token reference register according to the invention in order to prevent the tokens from being traceable.
  • the token reference register is a unit of the transaction register that stores the token references, thereby registering the tokens as valid tokens.
  • This register can be a central database or storage unit.
  • This register can be a decentralized ledger.
  • the token reference register can separately maintain a history of the token references and/or the registration requests and/or the validity requests in an archive unit.
  • a token reference is only stored once in the token reference register. Since a token reference of a token only exists once in the transaction system, the verify step can determine whether attempts have been made to issue a token multiple times.
  • the token is stored in a token store that the transaction unit can access exclusively.
  • This token memory can have a large number of tokens, for example the large number of tokens can be stored in a data memory of the transaction unit.
  • the data storage can be internal, external or virtual.
  • “connecting” can take place automatically when a token is received, so that preferably only one (or a certain number of) tokens are stored in the transaction unit.
  • the transaction unit can be, for example, a mobile device, such as a smartphone, a tablet computer, a computer, a server or a machine.
  • the transaction unit can be a smart card that is inserted into a terminal device ready for operation.
  • the transaction unit is preferably a secure element.
  • the data storage is, for example, a wallet storage of an electronic wallet.
  • the electronic wallet is, for example, a software application that is stored executable on a transaction unit.
  • the electronic wallet (wallet) can enable the transaction entity to participate in the transaction system.
  • the electronic wallet can generate a validity request to check the validity of a token.
  • the electronic wallet can make modifications (switching, connecting, splitting) to a token and generate any necessary validity requests and send them to the token reference register.
  • the electronic wallet can transfer tokens to another wallet (in a different transaction unit).
  • a transaction in the transaction system is preferably atomic.
  • a token reference register is provided for a transaction system which is set up to carry out the method steps according to the method described above.
  • the token reference register can be set up to receive a plurality of validity requests, which are verified in parallel in a plurality of verification units as to whether the at least one token reference contained in the validity request received in each case is valid.
  • a transaction system which has a register layer with a token reference register of the previous type for registering token references and checking tokens using token references and a direct transaction layer with a large number of transaction units, set up for the direct exchange of tokens with one another.
  • a two-layer transaction system consisting of a direct transaction layer for directly exchanging tokens and a register layer. No transactions are logged in the register layer Only token references are saved and modifications to tokens are saved via appropriately adapted token references for the purpose of verifying the validity of tokens. This ensures the anonymity of the participants in the transaction system.
  • the storage unit of the token reference register preferably only stores token references of tokens valid in the transaction system. As soon as a token is modified and a corresponding (modified) token reference is to be registered, the (old) token references become invalid and (only) the modified token references are stored in the storage unit.
  • old (i.e. invalid) token references are deleted from the storage unit and archived in a (token reference) archive.
  • the token reference archive can be part of the archiving unit, but it can also be provided as a separate unit in the token reference register or in the transaction system.
  • the token reference archive can also be completely replaced by the archiving unit if all registration requests are completely stored there.
  • the time-dependent deletion of registration requests can also apply to the deletion of old token references.
  • a transaction unit preferably a secure element, in a secure electronic transaction system with: an interface that is set up to: transfer tokens to another transaction unit; Creating and sending, to a token reference register, a validity request for checking a token according to one of the preceding embodiments; an access means for a token memory or token memory, wherein at least one token of the transaction unit with modification information is stored in the token memory; and a computing unit configured to: apply a one-way cryptographic function to a private part of a token-specific key pair of a token of the token storage to obtain a token reference; and modifying tokens.
  • the transaction unit has access means to a token memory and/or the transaction unit has a token memory, with at least one token of the transaction unit containing the sequence of registration requests being stored in the token memory.
  • the transaction unit has a computing unit that is set up to apply a cryptographic one-way function to a private part of a token-specific key pair of a token of the token storage to obtain a token reference; and for modifying tokens.
  • Modifying tokens includes, in particular, splitting Tokens, connecting tokens and/or switching tokens in the manner described above.
  • the transaction unit can be set up in such a way that only one token is stored in its token memory. This token is split (SPLIT) for direct transactions to produce a correct token value according to the transaction to be made. If tokens are received in the transaction unit, the received token is immediately combined with the token in the token store (MERGE).
  • SPLIT split
  • MERGE token store
  • this token of the token storage can be split (SPLIT), with a registration request being generated for this purpose.
  • the registration request preferably has a token reference of the token to be divided and a token reference of the divided tokens.
  • the registration request preferably has a token reference of the connected token and a respective token reference of the tokens to be connected.
  • a transaction unit can be a secure element that has secured access to tokens in a token store.
  • the secure element is, for example, installed in a terminal device ready for operation.
  • the secure element and/or the terminal device have a special computer program product (electronic purse, wallet), in particular in the form of a secured runtime environment within an operating system of a terminal device, English Trusted Execution Environments, TEE, stored on a data storage device, for example a mobile terminal device, a machine, preferably ATM.
  • the secure element is designed, for example, as special hardware, in particular in the form of a secured hardware platform module, Trusted Platform Module, TPM, or as an embedded security module, eUICC, eSIM.
  • the secure element provides a trusted environment.
  • the communication between two transaction units for exchanging tokens can take place wirelessly or by wire, or, for example, optically, preferably via QR code or barcode, and can be designed as a secure channel.
  • the exchange of tokens is, for example, additionally secured for transport by cryptographic keys, for example a session key negotiated for a token exchange or based on a key pair specific to the transaction unit.
  • FIG. 1 shows an exemplary embodiment of a transaction system according to the prior art
  • Fig. 2a shows a registration request according to the prior art
  • Fig. 2b shows a registration procedure for a registration request according to Fig. 2a according to the prior art
  • Fig. 3a shows a first exemplary embodiment of a validity query according to the invention
  • FIG. 3b shows a first exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 3a according to the invention
  • 3c shows a second exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 3a according to the invention
  • Fig. 4a shows a second embodiment of a validity query according to the invention
  • FIG. 4b shows a first exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 4a according to the invention
  • FIG. 4c shows a second exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 4a according to the invention
  • Fig. 5a shows a third embodiment of a validity query according to the invention
  • 5b shows a first exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 5a according to the invention
  • 5c shows a second exemplary embodiment of a method for checking the validity of a token based on a validity request according to FIG. 5a according to the invention
  • Fig. 6 shows a further exemplary embodiment of a transaction system with a token reference register according to the invention
  • Fig. 1 shows an exemplary embodiment of a transaction system TS according to the prior art.
  • the transaction system TS includes a register layer TRR layer in which a token reference register TRR is arranged.
  • the TS also includes a direct transaction layer TE layer, in which a large number of transaction units (or subscriber units) TE can be provided; two transaction units TE1, TE2 are shown as representatives.
  • the transaction units TE1, TE2 are preferably secure elements.
  • the transaction units TE of the transaction system TS are set up to exchange tokens T directly with one another.
  • the tokens are payment tokens, also referred to as digital coins.
  • Each token T is generated by a token issuer TH (not shown in Fig. 1).
  • Each token T can be modified, i.e. divided, connected or switched, by each transaction unit TE and can be generated and also deleted by the token issuer TH.
  • a token issuer TH is, for example, a central bank.
  • a token T is uniquely represented in the transaction system TS by a token value v and a random number r as token elements.
  • the token value v can be specified in a range of values from 1 to 2 31 -1.
  • the random number r can be a number in the range from 0 to 2 256 -1, i.e. the order of an elliptic curve, for example secp256rl.
  • the random number r is a private part of a token-specific key pair.
  • the random number r is unique and secret in the transaction system TS and may not be published or reused. The generation of the random number r must not be predictable.
  • the token value v is a 32-bit token element of type integer.
  • the random number r is a 32-byte token element of type integer.
  • One Transaction unit TE has exclusive access to this token storage or includes this token storage in a data storage of the transaction unit TE.
  • a token reference TR can be stored in the token reference register TRR.
  • the token reference TR includes the token value v of the assigned token T and a public part R of the token-specific key pair.
  • the token value v of a token T is therefore known in the token reference register TRR.
  • the public part R of the token-specific key pair is generated by applying a cryptographic function to the private part r of the token-specific key pair. This function is difficult to reverse and thus gives the TS transaction system the necessary security.
  • R r * G, where G can be, for example, a global parameter of the transaction system TS, for example a generator point of an elliptic curve, here the secp256rl curve.
  • the token reference TR is then formed by the token value v of the token and the public part R of the key pair.
  • the token reference TR is therefore the concatenation of token value v and public part R.
  • a token reference TR can be sent to the token reference register TRR together with a modification information (see overview in Figures 6a and 6b) as a registration request RA regarding the token T.
  • the modified token T is registered with its token reference in the token reference register TRR.
  • the transaction unit TE1 generates a new token TA, the token reference TRA of which is to be stored in the token reference register TRR instead of the token reference TRß of the old token TE with the same token value v.
  • the registration request can be sent by the transaction unit TE1 and/or - after transmission of the token TA together with its modification information to the transaction unit TE2 - by the transaction unit TE2.
  • a known token reference register TRR is initially shown in FIG.
  • the token reference register TRR manages in particular the storage location for the token references TR, which can optionally also store the previous registration requests RA, shown here as database 1 as an example of a storage unit in the token reference register TRR.
  • the token reference TR for the token T of the transaction unit TE1 is entered in the database 1 as a representative.
  • This database 1 can consist of a combination of many databases (see also FIG. 6) that are networked with each other.
  • the token reference register TRR includes at least one verification unit 2.
  • the verification unit 2 of the token reference register TRR verifies registration requests RA. Syntactic correctness or the correct specification of a command in the registration request RA can be verified.
  • the history from old (past) registration requests RA can also be checked.
  • the separation of this verification unit 2 from the database 1 distributes the storage and checking tasks and increases the speed in the token reference register TRR.
  • token reference register TRR receives registration requests RA from transaction units TE 11 and, if necessary, sends a registration confirmation RB to the transaction unit 18.
  • FIG. 2a An example of a registration request RA according to the prior art is shown in FIG. 2a.
  • the registration request of FIG. 2a includes two input token references TRE, an output token reference TRA and a modification command KO.
  • the registration request RA can be signed with the private part r of the token-specific key pair (not shown). Signing makes it possible to verify whether the sender of the token reference TRE was in possession of the input token TE, which further increases security in the transaction system TS.
  • step 11 the RA is received in the TRR.
  • step 12 it is checked whether an input token reference TREH of the RA is stored in the TRR. If step 12 is no, it is checked in step 16 whether the registration request RA has already been executed and is stored in the storage unit 1 as part of the history of the registration requests. In the YES case, the registration is confirmed (again) 18. In the No case of step 16, the RA is not confirmed according to step 19 (error message).
  • step 12 If step 12 is yes, step 13 is executed. In step 13 it is checked whether an input token reference TREU from RA is stored in the TRR.
  • step 14 is executed.
  • the command is checked for errors.
  • the RA is not confirmed according to step 19 (error message).
  • the TRAII of RA and the RA are stored in the TRR in step 15. The transaction unit is confirmed that registration has taken place in step 18.
  • the token reference register TRR is preferably not readable for the transaction units TE1, TE2. It is of little practical relevance but theoretically known that a transaction unit can query the status of a token, i.e. can query the status with which a token reference TR is stored in the token reference register TRR. However, such a status query is not a validity query in the present sense, as it will now be described in more detail.
  • a transaction unit TE1, TE2 can send one or more existing modification information MA, each of which links one (or more) output tokens to one (or more) input tokens via a command, to the token reference register as a validity request.
  • the reduction in the burden on limited resources that can be achieved is particularly helpful for security elements as a transaction unit.
  • the transaction unit TE1, TE2 sends the modification information(s) in a validity request for at least one token reference and receives a confirmation of validity from the token reference register TRR for the at least one requested token reference.
  • the validation request includes multiple output token references.
  • the token reference register TRR can provide a signature for each requested token reference in the validation confirmation.
  • the token reference register TRR shown in FIG. 1 is now also set up to verify validity requests GA.
  • the verification unit 2 of the TRR is provided.
  • the verification unit 2 of the token reference register TRR then verifies registration requests RA and/or validity requests GA.
  • a history of old (past) validity requests GA regarding a token T can also be verified. However, the history is not required for processing GA validity requests.
  • the storage unit 1 of the TRR can therefore advantageously only contain the valid token references TR.
  • a history of previously valid token references TR and/or modification information that has already been carried out can be stored in a separate unit, a Archive unit. In the following, it will be briefly stated in short that it is checked whether a token reference is stored in the TRR, but it is checked in each case whether the token reference is stored as a valid token reference or, assuming that the storage unit 1 only contains the valid token references, whether it is stored in the storage unit 1.
  • Fig. 3a shows a first exemplary embodiment of a validity request GA according to the invention.
  • the GA of FIG. 3a includes a (single) modification information MA.
  • This MA includes input token references TREH, TREU and output token references TRAII TRAU and a modification command KO.
  • the number of output token references TRA and the number of input token references TR ⁇ in the modification request MA is not restrictive, it can be more (indicated by the dots) or even fewer. Examples of the number of input and output token references TR per specific modification command KO will be given later.
  • the modification information MA can optionally include one or more signatures 32.
  • the modification information MA includes a signature of the modification information.
  • a signature 32 is preferably created with the private part r of an input token reference; in particular, a signature 32 with the associated private part TEU, TEI2 can be present for each input token reference TREU, TREU of the modification request MA.
  • the validity query GA can optionally include a check information 33.
  • the check specification specifies the one or more output token reference(s) to be checked for validity. In the example shown, the validity of the output token reference TRAU ZU must be checked. For a validity request GA without explicit verification information 33, for example, all output token references can be checked for validity.
  • the MA of the GA includes at least one output token reference TRAU to be checked for validity and preferably one (or more) output token reference(s) TRAU not to be checked for validity.
  • step 101 the TRR receives the GA and optionally checks the MA of the GA in further steps 103-105.
  • step 102 the TRR checks whether the MA's TRAU is stored as a valid token reference in the TRR (in particular in its storage unit 1).
  • TRAu is the output token reference contained in GA audit statement 33. If step 102 is yes, a validity confirmation GB is sent to the TE in step 108 in response to the GA.
  • the MA of the GA will not be examined further. There is already an output token reference of the MA in the TRR. The TRR must have already executed the MA in the past.
  • At least one signature of the TRR is created, in particular a signature of the TRR for the valid output token reference(s) TRAU.
  • the validity confirmation GB may contain or be formed by the signature of the TRR for the valid output token reference(s).
  • the TRR checks (verifies) the MA 103, 104 and, if necessary, executes them 105.
  • the TRR checks whether each input token reference TREU and TREI2 of the MA is stored in the TRR. If the input token references TREH and TREU of the MA are stored in the TRR (yes case), the TRR checks the MA for error 104.
  • the syntax of the MA is checked, in particular the command KO (e.g.: unknown KO type or KO- Type of TH) and/or the number of input and output token references (e.g.: no or too few output token references/input token references).
  • step 109 If the verification 103, 104 of the MA is not successful, an invalidity confirmation UGB is sent for the GA 109. In contrast to treating the MA as a registration request, the history is no longer used to check whether the MA has already been carried out. Both in the no case of step 103 and in the case of an error in the MA (yes case of step 104), the UGB is sent in step 109.
  • step 105 the TRR deletes the input token reference(s) TREU and TREU and stores the output token reference(s) TRAU and TRAU of the MA in the TRR, or in the storage unit 1 of the TRR.
  • Step 106 is again optionally carried out before step 108, so in the present example only TRAU is signed and the signature for TRAU is provided in the GB for the GA of the TRR of the transaction unit TE.
  • 3c shows a second exemplary embodiment of a method sequence for checking the validity of a token T based on a validity request GA according to FIG. 3a according to the invention.
  • step 101 the TRR receives the GA and now first checks 104 the MA of the GA for errors (particularly in syntax, value neutrality and/or signatures).
  • step 103 if MA itself is error-free, the TRR checks whether the input token reference(s) TREH and TREU of the MA are stored in the TRR. If the input token references TREU and TREU are stored in the TRR (yes case), the MA of the GA is executed 105.
  • step 102 is executed.
  • the MA is faulty (yes case of step 104) or the input token reference(s) of the MA are not stored in the TRR (no case of step 103)
  • step 102 is executed.
  • the MA cannot be verified, it is checked in step 102 whether the (optionally specified) output token reference TRAU or the (optionally specified) output token references is stored in the storage unit 1 of the TRR.
  • step 102 a validity confirmation GB is sent to the TE in step 108 in response to the GA.
  • the (specified) output token reference (s) is (are) already stored in the TRR, in particular in its storage unit 1.
  • the TRR has already carried out the MA with this TRA in the past.
  • a signature of the TRR for the (specified) output token reference(s), here TRA12, is created beforehand 106.
  • the TRR sends 109 an invalidity confirmation UGB for the (specified(s)) MA output token reference(s).
  • step 103 the TRR executes the MA's modification command KO in step 105 and then sends the validity confirmation 108.
  • the MA's input token references are deleted in step 105 and the MA's output token references are saved.
  • the method according to FIG. 3 c is first used to check whether the MA is faulty and/or the TRE is not stored in the TRR. Otherwise, i.e. even though the MA of the GA cannot be executed, it is checked whether the (specified) TRA of the GA are already saved.
  • the method according to Figure 3c also reduces the effort involved in checking the validity.
  • Fig. 4a shows a second exemplary embodiment of a validity request GA according to the invention.
  • This GA includes two or more modification requests MA (MAi, MA2, . . . MA X ).
  • Each MA includes (one or) more input token references TREH, TREU and (one or) more output token references TRAII TRAU and a modification command KO.
  • the number of output token references TRA and the number of input token references TRE in the modification request MA is not restrictive, it may be more or less. Examples of the typical number of input and output token references TR per specific command KO are listed later.
  • Optional MA signatures are not shown separately here.
  • the GA’s MAs are verified individually. It is preferred that the youngest MA, Max, be verified first.
  • the modification requests MA of the GA can be present as a batch or as a sequence of modification requests MA.
  • the MAs will essentially indicate consecutive modifications to tokens in time. At least one output token reference of one MA of the sequence will be input token reference of another MA of the sequence. Preferably, two or more consecutive MAs, for example MAx.i and MA Accordingly, the modification requests MA of the GA are in the order MAi. . . MA MA X is the most recent MA and represents the last modification to a token.
  • Fig. 4a shows a stack of MA in the GA as an example.
  • the input and output token references TR of the modification requests MA in the GA are essentially independent of each other (neither TRAII nor TRAU correspond to TRE21 or TREU, for example).
  • TRAII nor TRAU correspond to TRE21 or TREU, for example.
  • an output token reference of one MA of the stack is an input token reference of another MA of the stack.
  • the validity query 40 shown includes one or more output token references TRAij (jth output token reference of the ith modification information) to be checked for validity.
  • the specified output token reference(s) TRAij may include one, several or no output token references of the last modification indication (MA X ) of the GA, even in the case of a sequence.
  • the verification indication may include two or more output token references TRAij of the GA from different MAs, such as TRA21 and TRAXI.
  • the test information cannot include two or more output token references TRAIJ of the GA, preferably from different MAs, such as TRAII, TRA22 and/or. TRAX2.
  • FIG. 4b shows a first exemplary embodiment of a method for checking the validity of at least one token T based on a validity request GA with several MA, for example according to FIG. 4a.
  • the sequence of the method in FIG. 4b essentially corresponds to the method according to FIG. 3b (identical steps 102, 103, 104, 105, 106) and in this regard reference is made to the statements in FIG. 3b.
  • a specified output token reference, TRAIJ or alternatively all output token references of the MA, TRAII and TRAII, of the MA are already stored (as a valid TR).
  • the modification request MAi is executed 105.
  • a UGB could be sent in step 109 as soon as the current MA of the GA is not executable (no case of step 103 or yes case of step 104), if all TR of the GA must be checked for validity.
  • loop 141, 142 including steps 102-106 (and 146), is executed for each MA, MAi. . . MA X , which passes through GA.
  • Output token references TRAIJ that have already been previously saved according to step 102 or saved in step 105 can be buffered in the loop as TRA of the GA - recognized as valid or already signed.
  • step 146 it is also cached that the specified TRAIJ of the MAi or the output token reference or references, TRAIJ, of the MAi are invalid. If all specified TRAIJ are valid or all output token references of the GA are valid, a validity confirmation GB for the GA, including optional signatures, is sent 108. Otherwise, an invalidation confirmation can be sent 109.
  • a partial validity confirmation TGB can be (created and) sent 148, unless all but at least one output token reference in question is valid (step 147)
  • the partial validity confirmation TGB preferably only includes the signatures of the TRR for the valid output token references of the GA or the valid output token references TRAij to be checked for validity.
  • the validity confirmation GB for the GA is sent to the TE or the invalidity confirmation UGB is sent for the GA (or optionally a partial validity confirmation for the GA is sent) .
  • FIG. 4c shows a further exemplary embodiment of a method for checking the validity of a token T based on a validity request GA with several MA, in particular according to FIG. 4a.
  • the sequence of the method in FIG. 4c essentially corresponds to the method according to FIG. 3c (identical steps or sequence of steps 104, 103, 102, 105, 106) and in this regard reference is made to the statements in FIG. 3c.
  • 4c also includes a loop 141, 142 with a termination criterion (all specified TRAIJs checked for validity or all MAs run through), which allows each MA of the GA to run through the step sequence 102-106, 146 until the termination criterion is reached.
  • a termination criterion all specified TRAIJs checked for validity or all MAs run through
  • the corresponding confirmation GB/UGB/TGB will be sent 108/109/149.
  • MA of the GA can remain unchecked and a validity confirmation GB can still be sent for the TRAIJ to be checked for validity.
  • Stacks of modification information MA are preferably checked using the method according to FIGS. 4b and 4c.
  • the modification information contains independent token references.
  • Fig. 5a shows a third exemplary embodiment of a validity request GA according to the invention.
  • the GA includes several modification details MAi, MA2, . . . MAX .
  • the GA modification information is dependent on each other.
  • the GA therefore includes a sequence of
  • MAi's output token reference is TRAII
  • the output token reference TRA22 of MA2 could be an input token reference of another MA of the GA, for example the MA3, MA4 or MA X .
  • the first input token reference of MA x is the output token reference TRA X -I 1 of MA x -i.
  • the GA's check information 53 contains the output token references TRA21 and TRA X 2.
  • the MA's optional signatures are again not shown in the figure.
  • 5b shows a first exemplary embodiment of a method for checking the validity of a token T based on a validity request GA with several, preferably interdependent, MAs - in particular according to FIG. 5a.
  • the GA is received 101 and in step 102 it is checked whether the token references TRAIJ to be checked for validity are stored as valid TRs in the TRR, in particular whether they are present in the storage unit 1 of the TRR, which only contains the valid TRs. If the specified output token references TRA21 and TRAX2 are already stored, the validity confirmation GB can be sent 108 - optionally after the signatures 106 have been created as a cryptographic confirmation of the TRR for the valid TR. In this case, none of the MA of the GA (for errors and/or or feasibility).
  • step 103 it is checked in step 103 whether the input token reference(s) TREH and TREI2 are stored in the storage unit 1 of the TRR, i.e. are valid. In the no case, an invalidity confirmation UGB is sent 109. Likewise in the (yes) case of step
  • step 104 since the method is aimed at a sequence whose token references depend on each other - the MA is not actually executed yet.
  • the output token references TRA of the MAi are not yet saved. Deleting the input token references TRE of the MAi in the loop would be conceivable, but preferably only takes place in step 155.
  • the verification unit 2 only temporarily stores the output token references TRA of the MAi to be saved (and the input token references TRE of the MAi to be deleted). Several of these cached output token references will be the input token reference of another MA of the GA (which would therefore have to be deleted again). Now they are simply removed from the verification unit's cache. An unnecessary writing access (or several unnecessary writing or deleting accesses) to the storage unit 1 can thus be avoided.
  • Step 155 Only in step 155 are the cached (and not deleted again) output token references written into the storage unit. Step 155 may also be referred to as selectively storing the overall output token references of the sequence.
  • the output token references TRA21 TRAXI TRA X 2 are saved and the input token references TREH TREI2 TRE21 are deleted. The validity confirmation for the output token references TRA2I,TRA X 2 can then be sent.
  • the modification specification MA n has already been carried out.
  • the processing of the sequence of modification information can therefore be started with the following modification information MA n +i.
  • the sequence of the MA can be evaluated in order to recognize secondary branches of the sequence and take them into account as such in the processing of the sequence.
  • 5c shows a further exemplary embodiment of a method for checking the validity of a token T based on a validity request GA with several MA, in particular according to FIG. 5a or a GA with a sequence of MA.
  • step 101 all modification information MAi to MA X of the GA are first checked for errors in step 164a. If the MA contains an error (no case in step 164b), it is checked whether the specified output token references TRAIJ of the GA are all already stored 102. Depending on the case, the UGB is sent accordingly 109 or - after optional signing 106 of the TRAIJ - the validity confirmation GB is sent 108.
  • step 164b all TRs of the GA are read 162 from the storage unit 1 (it is checked for all TRs whether they are already stored). If all specified output token references TRAij are present 102, the validity confirmation 108 is sent as before. If not (no case of step 162), in step 165 the overall output token references of the sequence are selectively saved and the input token references (if still saved) are deleted.
  • the procedure according to Fig. 5c also leads to optimized processing of the GA with a sequence (or a stack).
  • the checked (verified) token references TR are stored in the token reference register TRR, whereby the modification to the token T is registered in the transaction system TS.
  • the token reference TR is uniquely assigned to the token T and is used to register the token T in the transaction system TS.
  • the token reference TR is therefore the public representation of the token T from the direct transaction layer TE layer.
  • the sole knowledge or possession of the token reference TR does not allow the transfer of the token T and does not mean that the TE is in possession of the token T.
  • the token reference TR is used to prevent multiple issuance attempts. It is checked whether token values v were generated in an inadmissible manner. Therefore, the token reference TR and, if necessary, the history of the token T and corresponding modifications by registration requests RA sent by transaction units TE are stored in the token reference register TRR.
  • the tokens T are stored, for example, in token stores or electronic purses, so-called wallets, of a TE.
  • a wallet is, for example, a software application within a transaction unit TE (in particular a secure element) or a terminal device in which the TE is installed ready for operation.
  • a wallet can be set up as an application on a smartphone, a smart card or a payment terminal.
  • the wallet is used to securely manage token T of the TE, to generate token references TR, to modify token T, to exchange token T and/or to initiate the checking of the validity of tokens.
  • Wallets are used to communicate with the token reference register TRR, to generate registration requests RA for modifications of the token T to the token reference register TRR, to carry out transactions from token T to a transaction unit TE and/or to generate validity requests GA.
  • the transaction system TS is set up to carry out a transaction offline, i.e. without a communication connection with the token reference register TRR. A corresponding registration of token T can therefore take place after a transfer of the token T to a transaction unit TE.
  • the token reference register TRR is a unit of the transaction system TS and is either a central register or a central database of the transaction system TS or a decentralized register or a decentralized database (DLT) of the transaction system TS.
  • a validity request GA is created by the transaction unit TE.
  • the validity request GA includes the token reference TR of the token T, the validity of which is to be checked.
  • the validity request GA also includes modification information about one or more modifications to the token T.
  • a token reference TR can be sent to the token reference register TRR together with a modification information as a validity request GA regarding the token T.
  • the validity request GA can be signed with the private part r of the token-specific key pair. Signing makes it possible to verify whether the sender of the token reference TR was in possession of the token T, which further increases security in the transaction system TS.
  • a validity request GA can be sent to the token reference register TRR to check whether the token T is valid.
  • This validity request GA is received in the token reference register TRR.
  • the transaction unit TE After checking the validity request GA by the token reference register TRR (or its verification unit2), the transaction unit TE is informed whether the token T is valid or not.
  • a validity request GA is preferably signed with the private part r.
  • the signature allows the syntactic authenticity of the command to be easily checked by the recipient (TRR or TE). This check is preferably carried out in the database 1 or the verification unit 2.
  • a validity query GA can, for example, be syntactically validated by checking the signature and/or the token reference TR.
  • the TE transaction units provide a secure hardware platform. With an available connection to the token reference register TRR, the token references TR are transmitted and the multiple issuance attempt can be detected in the token reference register TRR. If a token reference TR is not yet known in the token reference register TRR, it is added (saved).
  • An archiving unit can also be kept in the token reference register TRR (not shown in FIG. 1). Registration requests RA and/or validity requests and/or token references that are no longer valid are stored in this archiving unit.
  • commands KO for example “Switch”, “Split” or “Merge”.
  • Another type of command for checking the validity of an unmodified token T in the TRR was also known.
  • the following table shows example command encodings (0x01 to 0x05). The coding shown here and also the order of the data elements in the MA used in the figures is interchangeable or only an example.
  • Input token T and input token references TR are specified (“used”) for each command.
  • Output token T and output token references TR are specified (“generated”) for each command.
  • a modification statement (e.g. a registration request RA or a validity request GA) has the basic structure of the following three elements: command type, input token reference(s), output token reference(s).
  • Each command KO has a partially characteristic number (one or more) of input token reference(s) (“inputs”) and output token reference(s) (“outputs”).
  • a switch for example, preferably has exactly one input token reference and exactly one output token reference.
  • a split has exactly one (or more) input token reference and at least two (or more) output token references.
  • a connect has at least two (or more) input token references and exactly one (or more) output token reference(s).
  • FIG. 6 shows a further embodiment of a token reference register TRR of a transaction system TS. It is indicated here that several storage units 1 can be kept in the token reference register TRR in order to save one
  • FIG. 6 shows a further embodiment of a token reference register TRR of a transaction system TS. It is indicated here that several storage units 1 can be kept in the token reference register TRR in order to accelerate the storage of a large number of token references TR. It is also indicated here that several verification units 2 can be kept in the token reference register TRR in order to accelerate verification of validity requests GA and/or registration requests RA.
  • a transaction unit from a bank TEB is shown, which can serve as an interface between the transaction system TS and a bookkeeping system (lending, account management). It can enable transaction units TE to transfer tokens T of the transaction system TS into another transaction system TS. This transfer is possible bidirectionally.
  • the token issuer, TH is solely responsible for generating token T and also deleting token T in the TS.
  • FIG. 6 also shows a registration request unit RAE, which can receive a validity request GA (and/or RA) from a transaction unit TE1 and forwards the GA (and/or RA) to the TRR.
  • RAE Registration request unit
  • the TRR also contains an archive unit 5 in which RA and/or GA that have already been executed and/or token references that are no longer valid are stored, in particular as a linked graph.
  • Transaction units TE can send their RA and/or GA to the TRR via a first interface 3 of the TRR. However, only the token issuer TH is allowed to send commands to the TRR via the second interface 4 of the TRR.
  • token T it can be advantageous if only one (or a few) token T is used per transaction unit TE (here as a secure element, e.g. smart card or TEE).
  • TE connects a received token T with the token T stored in the token storage (MERGE).
  • MERGE token storage
  • SPLIT token memory
  • Each of these modifications is also referred to as a “proof” (see above for FIG. 1) or is stored as, preferably signed, modification information MA with the token T. This creates the sequence of modification information MAp or. in the TE1 for the token T. MAi, MA2, ... MA
  • a validity query GA is now provided to check a token for validity.
  • the terminal device receives the GA and/or the MA or MAF.
  • a registration request unit RAE can also be provided as a switching entity between the TE and the TRR, see Fig. 6.
  • the RAE then receives the GA and/or the MA or MAF from the TE or the terminal.
  • a GA is sent to the TRR.
  • the terminal (not shown in Figure 6) or the RAE attempts to transmit the GA to the TRR.
  • GA and/or the MA or MAF are neither evaluated nor interpreted by the end device nor by the RAE.
  • the order of the modification information in a GA of a sequence MAF is not changed by the terminal or the RAE.
  • a validity confirmation GB (or a registration confirmation RB) of the TRR is then transmitted from the terminal and/or the RAE to the TE.
  • Each GA and/or the MA or MAF can be signed with the private part r (the random number r) of the relevant token-specific key pair. Therefore, the modification information MA, which is stored in the TE (in the token memory), is sometimes also referred to as a proof.
  • the verification unit 2 of the TRR checks the validity, in particular using a method according to FIGS. 3b to 5c.
  • a GB is sent back to the secure element or the TE (possibly via the RAE or the end device).
  • TE2 also carries out:
  • Validity check of token F Only token F should be checked for validity.
  • a GA is generated and the token reference of the token F (as a checking specification) together with the modification information MA consisting of the three modifications (proofs) “Split”, “Switch” and “Merge” are sent from the TE2 to the TRR as a GA.
  • the output token reference TRB of the first MA of the GAs is not to be checked or is not checked for validity by the TRR.
  • the first two modification details of the GA are only carried out optionally, for example if TE1 (or another TE) has not yet sent an RA or GA with these two MA to the TRR.
  • the GB can of the TRR can optionally be returned in the form of a status message that also encodes additional information, for example:
  • the cryptographic confirmations, in particular signatures, of the TRR can be attached to such a status message.
  • the GB can or the valid TR can be signed with a private key pKey RR of a key pair of the verification unit 2.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un élément sécurisé en tant qu'unité de transaction d'un système de transaction ayant un registre de référence de jeton, une procédure dans le registre de référence de jeton, et le registre de référence de jeton. L'élément sécurisé comprend un magasin de jetons pour des jetons du système de transaction et est conçu comme une unité de transaction pour échanger des jetons du système de transaction directement avec une autre unité de transaction du système de transaction. À chaque jeton (T) du système de transaction (TS) est attribuée de manière univoque une référence de jeton (TR) qui peut être enregistrée dans un registre de référence de jeton (TRR) du système de transaction (TS). L'élément sécurisé est conçu pour, à partir d'au moins un jeton d'entrée, produire au moins un jeton de sortie et une référence de jeton de sortie (TRA) de celui-ci. L'élément sécurisé fournit un détail de modification, avec une référence de jeton d'entrée (TRE), une commande (KO) et une référence de jeton de sortie (TRA), pour le registre de référence de jeton (TRR). Dans le cas présent, l'élément sécurisé fournit ledit détail de modification (MA) en tant que demande de validité (GA). Il est également conçu pour recevoir une confirmation de validité (GB) pour au moins une référence de jeton de sortie, dont la validité doit être vérifiée, de la demande de validité (GA).
PCT/DE2023/100487 2022-08-01 2023-06-28 Élément sécurisé, procédé d'enregistrement de jetons et registre de référence de jeton WO2024027869A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022002780.1A DE102022002780A1 (de) 2022-08-01 2022-08-01 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE102022002780.1 2022-08-01

Publications (1)

Publication Number Publication Date
WO2024027869A1 true WO2024027869A1 (fr) 2024-02-08

Family

ID=87429466

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2023/100487 WO2024027869A1 (fr) 2022-08-01 2023-06-28 Élément sécurisé, procédé d'enregistrement de jetons et registre de référence de jeton

Country Status (2)

Country Link
DE (1) DE102022002780A1 (fr)
WO (1) WO2024027869A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009034436A1 (de) 2009-07-23 2011-01-27 Giesecke & Devrient Gmbh Verfahren und System zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze
DE102009038645A1 (de) 2009-08-24 2011-03-24 Giesecke & Devrient Gmbh Verfahren und tragbarer Datenträger zum Übertragen eines geldwerten Betrages in Form eines elektronischen Datensatzes zwischen einer ersten nichtzentralen Instanz und einer zweiten nichtzentralen Instanz
CN108830586A (zh) * 2012-04-01 2018-11-16 深圳市可秉资产管理合伙企业（有限合伙） 使用移动装置结算支付的装置和方法
WO2020212337A1 (fr) 2019-04-15 2020-10-22 Giesecke+Devrient Gmbh Procédé pour le transfert direct de jeux de données électroniques de monnaie entre des terminaux ainsi que système de paiement
WO2022016886A1 (fr) * 2020-07-20 2022-01-27 华为技术有限公司 Procédé et appareil de vérification de transaction
DE102021004019A1 (de) * 2021-08-04 2023-02-09 Giesecke+Devrient Advance52 Gmbh Verfahren zum registrieren von token eines elektronischen transaktionssystems

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1212734B1 (fr) 1999-08-26 2006-07-19 MONEYCAT Ltd. Argent electronique, portefeuille electronique destine a celui-ci et systemes de paiement electroniques dans lesquels l'argent et le portefeuille electroniques sont utilises
DE102006017911B4 (de) 2006-04-18 2023-01-26 creditPass GmbH Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
EP3035270A1 (fr) 2014-12-15 2016-06-22 Giesecke & Devrient GmbH Generation de jetons hors ligne a base de cartes
US10423954B2 (en) 2015-01-26 2019-09-24 International Business Machines Corporation Resource account application management
DE102016106055A1 (de) 2016-04-03 2017-10-05 Achim Faßbender Alternative Zahlungsmittel und Zahlungsverfahren
DE102018009949A1 (de) 2018-12-18 2020-06-18 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Übertragungsverfahren zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen
US20220027896A1 (en) 2020-07-22 2022-01-27 ZUZLab, Inc. Method and system for defining, creating, managing, and transacting multiple classes of digital objects
DE102021004548A1 (de) 2021-09-08 2023-03-09 Giesecke+Devrient Advance52 Gmbh Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009034436A1 (de) 2009-07-23 2011-01-27 Giesecke & Devrient Gmbh Verfahren und System zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze
DE102009038645A1 (de) 2009-08-24 2011-03-24 Giesecke & Devrient Gmbh Verfahren und tragbarer Datenträger zum Übertragen eines geldwerten Betrages in Form eines elektronischen Datensatzes zwischen einer ersten nichtzentralen Instanz und einer zweiten nichtzentralen Instanz
CN108830586A (zh) * 2012-04-01 2018-11-16 深圳市可秉资产管理合伙企业（有限合伙） 使用移动装置结算支付的装置和方法
WO2020212337A1 (fr) 2019-04-15 2020-10-22 Giesecke+Devrient Gmbh Procédé pour le transfert direct de jeux de données électroniques de monnaie entre des terminaux ainsi que système de paiement
US20220215355A1 (en) * 2019-04-15 2022-07-07 Giesecke+Devrient Advance52 Gmbh Method for directly transmitting electronic coin data records between terminals and payment system
WO2022016886A1 (fr) * 2020-07-20 2022-01-27 华为技术有限公司 Procédé et appareil de vérification de transaction
US20230177505A1 (en) * 2020-07-20 2023-06-08 Huawei Technologies Co., Ltd. Transaction Verification Method and Apparatus
DE102021004019A1 (de) * 2021-08-04 2023-02-09 Giesecke+Devrient Advance52 Gmbh Verfahren zum registrieren von token eines elektronischen transaktionssystems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Load balancing (computing) - Wikipedia, the free encyclopedia", 28 September 2012 (2012-09-28), XP055305779, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Load_balancing_(computing)&oldid=515073473> [retrieved on 20160927] *

Also Published As

Publication number Publication date
DE102022002780A1 (de) 2024-02-01

Similar Documents

Publication Publication Date Title
DE69500751T2 (de) Verfahren zum Druckführen einer Transaktion zwischen einer Chipkarte und einem Datensystem
EP3956846A1 (fr) Procédé pour le transfert direct de jeux de données électroniques de monnaie entre des terminaux ainsi que système de paiement
WO2020212331A1 (fr) Dispositif pour le transfert direct d&#39;ensembles de données de pièces de monnaie électroniques vers un autre dispositif et système de paiement
DE102018122997A1 (de) Blockkettenentität, kettenexterne entität, zertifizierungsvorrichtung für blockkettenoperationen und verfahren zum durchführen einer kooperation zwischen einer blockkettenentität und einer kettenexternen entität
EP4111348A1 (fr) Procédé de transmission directe de jeux de données de pièces de monnaie électroniques entre terminaux, système de paiement, système de protection et unité de surveillance
WO2023011756A1 (fr) Élément sécurisé, procédé d&#39;enregistrement de jetons et registre de référence de jeton
EP4399632A1 (fr) Procédé et système de transaction pour transmettre des jetons dans un système de transaction électronique
EP3743844B1 (fr) Système d&#39;identité basé sur chaînes de blocs
WO2023011761A1 (fr) Élément de sécurité, procédé d&#39;enregistrement de jetons et registre de référence de jeton
DE102020120945A1 (de) Verfahren zum Kommunizieren, basierend auf einer Distributed-Ledger-Technologie, zwischen einer Vielzahl von Ladestationen für Elektrofahrzeuge
WO2024027869A1 (fr) Élément sécurisé, procédé d&#39;enregistrement de jetons et registre de référence de jeton
DE102018009951A1 (de) Verfahren zum direkten Austausch eines Münzdatensatzes zwischen Sicherheitselementen
DE102018009952A1 (de) Verfahren zum direkten Austausch eines Münzdatensatzes zwischen Sicherheitselementen
EP4111399B1 (fr) Procédé, terminal, entité de surveillance et système de paiement pour gérer des ensembles de données électroniques de pièces de monnaie
EP1817752A2 (fr) Procede pour personnaliser des cartes a puce
WO2022008321A1 (fr) Procédé, terminal et registre de pièces pour transmettre des jeux de données de pièces électroniques
DE102021106261A1 (de) Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikationsnetz, Verarbeitungseinrichtung, Kraftfahrzeug und Infrastruktureinrichtung
WO2024012624A1 (fr) Procédé de génération sécurisée d&#39;un jeton pouvant être émis, procédé de destruction sécurisée d&#39;un jeton et émetteur de jeton
DE102021002329A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102018202676A1 (de) Verfahren zum Authentifizieren eines Benutzers
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102021004023A1 (de) Verfahren zum direkten übertragen von token
WO2021170644A1 (fr) Procédé de transmission directe d&#39;ensembles de données de pièce de monnaie électronique entre terminaux, système de paiement, système de protection et entité de surveillance
DE102018206460A1 (de) Verfahren und Vorrichtung zum Betreiben eines digitalen Bezahlsystems
DE102009019050B4 (de) Verfahren und Datenträger zur Sicherung von Transaktionsdaten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23744660

Country of ref document: EP

Kind code of ref document: A1