[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP4381408A1 - Sicheres element, verfahren zum registrieren von token und tokenreferenzregister - Google Patents

Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Info

Publication number
EP4381408A1
EP4381408A1 EP22744114.4A EP22744114A EP4381408A1 EP 4381408 A1 EP4381408 A1 EP 4381408A1 EP 22744114 A EP22744114 A EP 22744114A EP 4381408 A1 EP4381408 A1 EP 4381408A1
Authority
EP
European Patent Office
Prior art keywords
token
registration request
transaction system
tokens
key pair
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP22744114.4A
Other languages
English (en)
French (fr)
Inventor
Raoul-Thomas HERBORG
Daniel Albert
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Advance52 GmbH
Original Assignee
Giesecke and 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 and Devrient Advance52 GmbH filed Critical Giesecke and Devrient Advance52 GmbH
Publication of EP4381408A1 publication Critical patent/EP4381408A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • 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
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G06Q20/4033—Local solvency checks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

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 that are uniquely assigned to a token are stored, and to the transaction system as a whole.
  • secure direct transmission between the transaction units can be achieved with the aid of secure elements such as chip cards, SIM modules, etc., as transaction units, with intentional multiple issuance of tokens, also known as double-spending, already being ruled out.
  • systems or portable data carriers are known as secure elements for transferring monetary amounts in the form of electronic data records, in which payment with duplicates of the data record is prevented and a high degree of Manipulation security is given.
  • Complex structures and complex encryption and signing processes are required here for the transactions. These have turned out to be of little use in practice.
  • the security of transactions and the associated transaction data includes protecting the confidentiality of the data exchanged; as well as protection of the integrity of the exchanged data; as well as protection of 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.
  • newer account-based systems based on blockchain topologies have recently been discussed. While they provide a high level of integrity protection, they also publish a lot of information, for example when records are in a human-readable data structure and change hands there.
  • the secure element sends a registration request for its token to the registry.
  • the registry verifies the registration request and preferably only stores a token reference for the token, so preferably does not know the token itself
  • the invention uses a method for registering tokens that are directly transferrable between subscriber units.
  • WO 2020/212337 A1 describes a transaction system in which even modifications to the token—for example by splitting the token offline, ie directly between the secure elements of the transaction system and without any further control authority—are possible in a secure manner. After receipt in a secure element or subscriber unit, the tokens can be transferred immediately without a modification having to be registered in a token register of the transaction system. As is known, however, the secure elements are limited in terms of resources, in particular with regard to storage space and/or processing speed.
  • the invention is based on the object of creating a secure element and a method for registering tokens in a transaction system in which a transmission of tokens is secure but nevertheless simple enough--especially for secure elements.
  • a direct transmission of a token is to be created between subscriber units.
  • This transaction should remain anonymous to third parties.
  • the token should be able to be used 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.
  • a received token should be secret from subscriber units not involved in the transaction.
  • Each subscriber unit of the transaction system should be able to check a received token, in particular multiple output attempts and attempts to transmit non-existent token values should be able to be recognized by a subscriber unit or generally in the transaction system.
  • the stated object is solved by the objects described in the independent patent claims. Further advantageous configurations are described in the respective dependent patent claims.
  • the object is achieved in particular by a method for registering tokens in an electronic transaction system, with each token in the transaction system having at least one token value and a private part of a token-specific key pair as token elements.
  • the method comprises the method steps: receiving, in a token reference register of the transaction system, a registration request having at least one token reference uniquely assigned to a token of the transaction system, the token reference having at least the token value of the token and a public part of the token-specific key pair as token reference elements, wherein the public part of the token-specific key pair was obtained by applying a cryptographic one-way function to the private part of the token-specific key pair of the token, verifying, by a verification unit of the token reference register, whether the at least one token reference of the received registration request is stored in the token reference register, and storing the at least one token reference in a storage unit of the token reference register for registering the token uniquely assigned to this token reference in the transaction system if in Ve rify step is determined that the at least one token reference of the received register request is not stored in the token reference register.
  • Receiving preferably takes place at an interface of the token reference register, preferably an interface of the verification unit of the token reference register.
  • a transaction system is a system in which at least two, preferably a large number, of subscriber units can exchange (transmit) tokens directly with one another.
  • the transaction system is, for example, a payment transaction system for exchanging monetary amounts in the form of payment tokens.
  • a token is a transaction system record that can be directly exchanged between subscriber units. Knowing the token, the receiving subscriber unit is in possession of the token value that the token represents. With the exchange, the token automatically changes hands.
  • the token is an electronic coin record or payment token for exchanging amounts of money between subscriber units. Colloquially, such a payment token is also referred to as a “digital coin” or “electronic coin” and represents cash in electronic form.
  • Each token in the transaction system is a 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 economic good and/or an amount of money.
  • 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 will not be published and may not be used more than once. 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 genuine random number generator.
  • 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 ruled out according to the invention and includes, for example, adding them one after the other, incorporating them into a TLV data structure and/or logically linking them.
  • a token reference is assigned to each token in the transaction system. This assignment is one-to-one, that is, 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 record that is stored in a memory unit of the token reference register of the transaction system for each subscriber unit to be verifiable.
  • Each token reference in the transaction system is a data record comprising at least two token reference elements.
  • a first token reference element of each token reference is the token value of the token uniquely associated with 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. Together with the private part of the token, this public part of the token reference 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 “easily” calculable in terms of complexity theory, but “difficult” to practically impossible to reverse.
  • a one-way function is also referred to as a function for which no reversal that can be carried out in practice within a reasonable time and with reasonable effort is known to date.
  • a one-way function is used that operates on a group where the discrete logarithm problem is difficult to solve, such as B.
  • a cryptographic method analogous to an elliptic curve encryption, ECC for short from a private key of a corresponding cryptographic method.
  • the reverse function ie the generation of a token (or part of the electronic coin data record) from a token reference, is very time-consuming.
  • the (mere) knowledge or possession of a token reference does not entitle to use/transfer/issue the token value (token reference element). This represents an essential 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 ruled out according to the invention and includes, for example, adding them one after the other, incorporating them into a TLV data structure and/or logically linking them.
  • the token reference can be generated by an electronic purse of a subscriber unit wishing to send the token.
  • the token reference can be generated by an electronic purse of a subscriber unit that has received the token.
  • a token reference is not comparable to the use of addresses of subscriber units in a blockchain-based transaction system, partly because no addresses of the subscriber units are used in the token reference register according to the invention in order to prevent the tokens from being traced.
  • the method for registering provides a receiving step to receive a token reference in a token reference register as part of a registration request.
  • the registration request is sent by a subscriber unit of the transaction system or a token issuer of the transaction system.
  • the token reference repository is a unit of the trade repository that stores the token references, whereby the associated tokens are registered.
  • This register can be a central database or storage unit.
  • This register can be a decentralized ledger, for example in a blockchain topology.
  • the token reference registry may maintain a history of token references and/or registration requests.
  • the received registration request is verified by a verification unit in the token reference register. In this case, it is verified whether the at least one token reference of the received registration request is already stored in the token reference register.
  • 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 verifying step determines whether an attempt was made to issue a token more than once.
  • the verification unit of the token reference register also determines whether the token reference in the registration request received can be assigned to a token. For this purpose, the token reference or a derivation of the token reference or a history of the token reference must be stored in the token reference register, which can be assigned to the token reference of the registration request received.
  • the verifying 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 that is uniquely assigned to the token reference actually exists (can exist); and/or whether a difference formation of token values in the registration request matches a command type specified in the registration request.
  • the verifying step determines whether a signature of the registration request is correct.
  • the verification step also determines whether a sum of token values of all token references within the registration request is zero. In this case, input token values and output token values of the registration request are summed up. For registration requests originating from Subscriber Units, a sum of all token values of the registration request must equal zero. If the sum is not zero, an additional token value was created in the transaction system or a token value was destroyed from the transaction system in an unauthorized manner. This makes it easier to detect an attempt at fraud with non-existent tokens or tokens generated without permission. So far, time-consuming proofs of area (zero-knowledge-proofs, ZKP) were necessary, which can be omitted with this method.
  • ZKP zero-knowledge-proofs
  • the received token reference is stored in a storage unit of the token reference register. With the storage, the token uniquely assigned to the received token reference is registered in the transaction system. Storage only takes place if it is determined in the verifying step that the at least one token reference of the received register request is not stored in the token reference register.
  • the basic principle of registering a token is accordingly that a received registration request is verified as to 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 not known, it is entered (stored) in the token reference register in order to be available for future verification and test steps in the transaction system.
  • the public key part of the token-specific key pair of the token reference is at the same time a database index of a database of the token reference register.
  • the database index is an index structure separate from the data structure in the token reference register, which speeds up the search and sorting for token references. It can be a collection of pointers (references) that define an ordering relation to one or more entries in the token reference register.
  • Using the public key part as an index makes verification much easier. It is no longer necessary to check duplicates, because the uniqueness of the index is already checked in the token reference register.
  • the registration request received is signed with the private part of the token-specific key pair in order to be able to check or verify an assignment of the token reference to the token. If the verification in 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 be aware of the token. This can be used to detect an attempt at fraud with non-existent tokens or tokens generated without permission.
  • the token reference register has one or more memory units for storing token references for registering the token in the transaction system.
  • This storage unit(s) can be managed as a central database of the transaction system. The use of multiple storage units enables registration requests to be processed in parallel and speeds up registration in the transaction system.
  • the token reference register has one or more verification units for verifying received registration requests.
  • This verification unit(s) compares, for example, a command type of the registration request received with the token values of the registration request received. If a command type expects that no token values should be added to the transaction system or subtracted from the transaction system, a check is made to see whether this is also adhered to with the token values of the token references received. If the verification fails, a case of fraud is detected and registration is prevented.
  • the token reference register has one (or more) checking units for checking the received registration request.
  • the checking unit checks the registration request, in particular for syntactical correctness of the registration request, admissibility of a command type of the registration request, sum of the token values in the registration request (must be zero) and/or signature of the registration request before it is verified by the verification unit. Only the contents of the registration request are checked by the checking unit. This check therefore does not require access to the storage unit (or takes place without access to the storage unit). The verification unit no longer has to carry out the test steps carried out by a test unit. The verification unit can thus be relieved.
  • the token reference register has a total sum checking unit for checking a total sum of token values of the token references of registered tokens.
  • the total sum is preferably checked independently of the receipt of a registration request. It is checked, for example, at regular intervals or at random or due to an event.
  • the total checking unit determines a current total and compares the current total to a total token value.
  • the total token value is not changed by registration requests from (normal) subscriber units.
  • the total token value can change due to registration requests from the token issuer.
  • the total token value is preferably changed upon request of a re-registration entity through which only the token issuer can register new tokens or de-register registered tokens.
  • a verification unit can request the total token value verification for a registration request. The validity of the token value can thus be checked to determine whether a new token value was generated in an unauthorized manner.
  • a registration request history could be used to handle registration requests sent twice without loading the storage unit of the token reference register.
  • the re-registration unit can be used to update a reference value relating to the total token value of the tokens located in the transaction system on the basis of the generated and/or deleted tokens in the token reference register (for example in a total token value checking unit). For example, if a new token is generated, its token value is added to the total token value. For example, if a token is deleted, its token value is subtracted from the total token value.
  • the token reference has at least one counter value as a further token reference element.
  • the count value can be another token element.
  • the count may represent the number of offline transactions of the token.
  • An offline transaction is a direct transaction between subscriber units in the transaction system for transferring tokens without the token being registered in the token reference register. The count increases (increments) with each offline transaction. Depending on the system, it can be provided that tokens must be automatically registered in the token reference register when a predefined threshold value for the counter value is exceeded.
  • the token reference has at least an identity of a subscriber unit or of an owner of the subscriber unit as a further token reference element.
  • the identity can be another token element. This identity is used, for example, in the checking step to validate or verify the token reference. This eliminates the anonymity in the transaction system and a case of fraud is uncovered more quickly.
  • the token reference has at least a pseudonym of a subscriber unit or of an owner of the subscriber unit as a further token reference element.
  • the pseudonym can be another token element. This pseudonym is used in the check step, for example, to validate or verify the token reference. This does not eliminate anonymity in the transaction system, and a case of fraud is nevertheless uncovered more quickly if a unit of the transaction system resolves the pseudonym.
  • each further token reference element can be added by a concatenation with the first and/or second token reference element.
  • the registration request relates to a modification - in particular division, connection or switching - of at least one previously registered token and preferably has at least the token reference of the at least one previously registered token and the at least one token reference of the token to be registered, which the modification of the previously registered token is on.
  • the registration request relates to a splitting of a token and the registration request preferably has a token reference for the token to be split and a token reference for each of the (at least two) split tokens.
  • the token references contained in the registration request can be linked together (concatenation).
  • the split token then becomes invalid and the (at least two) split tokens are registered in the token reference register to become verifiable in the transaction system.
  • the token value of the token to be split is split into at least a first token value and a second token value.
  • the split can be done symmetrically, so the split token values are equal.
  • the split can be asymmetrical, so the split token values are unequal.
  • the splitting provides: generation of a new private part of a token-specific key pair for a first split token; applying a cryptographic function to obtain a corresponding public portion of the token unique key pair for the first split token; generating a new private part of a token-individual key pair for a second split token; applying a cryptographic function to obtain a corresponding public portion of the token unique key pair for the second split token; dividing the token value into a first split token value and a second split token value, noting that the sum of the first split token value and the second split token value equals the equals the token value of the token to be split; generating a token reference for the first split token comprising the first token split value and the public part of the token-individual key pair of the first split token; generating a token reference for the second split token comprising the second token split value and the public portion of the token unique 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,
  • the registration request relates to switching a token
  • the registration request preferably has a token reference for the token to be switched.
  • Switching the token is another modification option.
  • the token references contained in the registration request can be linked together (concatenation). If a token is transmitted directly from one subscriber unit to another subscriber unit, for example if the monetary amount is to be transmitted as a token value as part of a payment transaction, the receiving subscriber unit can now have the token value re-registered to itself. This registers the switchover in the token reference register.
  • the transmitted token is preferably switched ("switched") from the first subscriber unit to the second subscriber unit. Switching can preferably take place automatically when a token is received in the second subscriber unit.
  • the following is provided when switching over: 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; Creation of 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.
  • the token value of the token to be switched corresponds to the token value of the switched token. Accordingly, when switching over, a token with the same token value but a new private part is registered in the token reference register.
  • the registration request relates to a connection of at least two tokens, and the registration request preferably has a token reference for the connected token and a token reference for each token to be connected.
  • the token references contained in the registration request can be linked together (concatenation).
  • the tokens to be linked become invalid and the linked token is registered in the token reference register in order to be verifiable in the transaction system.
  • the following is provided during the connection: generation of a new private part of a token-specific key pair; applying a cryptographic function to obtain a corresponding public portion of the token-unique key pair for the associated 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 linked token comprising the calculated token value and the public part of the token individual key pair for the linked token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token.
  • a registration request is sent by a token issuer, the registration request relating to creating a token or deleting a token.
  • a token issuer in contrast to a subscriber unit, is a privileged entity in the transaction system through which tokens can be created and deleted.
  • a subscriber unit cannot create or delete a token, it can only modify tokens (switch, split, connect).
  • the token is stored in a subscriber unit.
  • the subscriber unit can have a large number of tokens, for example the large number of tokens can be stored in a data memory of the subscriber unit.
  • the data store can be internal, external, or virtual.
  • a “connection” can take place automatically when a token is received, so that preferably only one (or a specific number of) tokens are stored in the subscriber unit.
  • the subscriber unit can be, for example, a mobile terminal such as a smartphone, a tablet computer, a computer, a server or a machine.
  • the subscriber unit can be a smart card that is operatively inserted into a terminal.
  • a secure element is set up as a participant unit of a transaction system
  • each token of the transaction system having at least one token value and a private part of a token-specific key pair as token elements
  • the registration request having at least the token reference uniquely assigned to the token of the transaction system.
  • the data memory is, for example, a wallet memory of an electronic purse (wallet).
  • the electronic purse is, for example, a software application that is stored in an executable manner on a subscriber unit.
  • the electronic purse (wallet) can enable the subscriber unit to participate in the transaction system.
  • the electronic purse can generate a registration request to register a token in a token reference register.
  • the electronic purse can make modifications (switching, connecting, splitting) to a token and generate any registration requests that may be necessary and send them to the token reference register.
  • the electronic purse can transfer tokens to another purse (in a different subscriber unit).
  • a transaction in the transaction system is preferably atomic.
  • the token reference register therefore has knowledge of token references from tokens in the transaction system and preferably also carries out the processing or modifications to the token (token history).
  • the transactions with the tokens are not registered in the token reference register and take place in a direct transaction layer of the transaction system directly between subscriber units of the transaction system.
  • 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 has: at least one memory unit for storing token references for registering tokens in the transaction system; a checking unit for checking received registration requests; at least one verification unit for verifying whether a token reference of a received registration request is stored in the token reference register; and/or a new registration unit for registering tokens newly generated by a token issuer or tokens deleted by a token issuer.
  • a transaction system comprising: a register layer having a token reference register of the foregoing type for registering token references; and a direct transaction layer having a plurality of subscriber units arranged to exchange tokens directly with one another.
  • a two-layer transaction system consisting of a direct transaction layer for the direct exchange of tokens and a register layer. No transactions are logged in the register layer, but 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 participants in the transaction system.
  • the token reference register provides information about the token references that are uniquely assigned to the tokens of the transaction system, for example to avoid multiple issuance of the same token or to verify the authenticity of the token.
  • the storage unit of the token reference register preferably only stores 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 memory unit.
  • the terminal can therefore transmit electronic coin data records to another terminal in the direct payment transaction layer without being connected to the monitoring authority, especially when the terminal is offline, so there is no communication link to the monitoring entity.
  • a subscriber unit can be a secure element that has secured access to tokens in a token memory.
  • the secure element is installed ready for operation in a terminal, for example.
  • the secure element and/or the terminal have a special computer program product (electronic purse, wallet), in particular in the form of a secure runtime environment within an operating system of a terminal, English Trusted Execution Environments, TEE, stored on a data memory, for example a mobile terminal, a machine, preferably ATM.
  • the secure element is designed, for example, as special hardware, in particular in the form of a secure hardware platform module, English Trusted Platform Module, TPM, or as an embedded security module, eUICC, eSIM.
  • the secure element provides a trusted environment.
  • the communication between the end device and the secure element as a subscriber unit can take place using an APDU.
  • the communication between the end device and the token reference register or issuer unit can take place using API calls.
  • the end device is only a protocol translator and does not change the registration requests.
  • the communication between two subscriber units for exchanging tokens can take place wirelessly or by wire, or e.g. also optically, preferably via QR code or barcode, and can be designed as a secure channel.
  • the exchange of tokens is additionally secured for transport, for example by means of cryptographic keys, for example a session key negotiated for a token exchange or on the basis of a pair of keys specific to the subscriber unit.
  • 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
  • 3a shows an overview of commands for tokens according to the invention
  • 3b shows an overview of signed registration requests according to the invention for the commands according to the invention
  • FIG. 4 shows an exemplary embodiment of a flow chart 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 exemplary embodiment of a flow chart of a method according to the invention for deleting a token and registering
  • FIG. 6 shows an exemplary embodiment of a flow chart 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 flow chart 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. 8 shows an exemplary embodiment of a flow chart 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;
  • FIG 9 shows another embodiment of a token reference register according to the invention.
  • Fig. 1 shows an embodiment of a transaction system TS according to the invention.
  • 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 multiplicity of subscriber units TE can be provided; two subscriber units TE1, TE2 are shown as representatives.
  • the subscriber 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 issued by a token issuer TH generated (not shown in Fig. 1, see Fig. 2).
  • Each token T can be split, connected or switched by each subscriber unit TE (see Figures 6 to 8) and can be generated by the token issuer TH (see Figure 4) and also deleted (see Figure 5).
  • 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 value range from 1 to 2 31 -1.
  • the random number r can be a number in the range from 0 to 2 256 -1, ie 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 must not be published or reused. The generation of the random number r must be unpredictable.
  • the token value v is a 32-bit token element of type integer.
  • the random number r is a 32-byte integer token element.
  • 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.
  • a token can be stored as a TLV-encoded data record in a token memory and then has a unique tag and length information, for example in the following format.
  • TLV encoded token in hexadecimal form is shown below:
  • a token reference TR can be stored for each token T 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 reference TR of the token T can be viewed at any time in the register TRR of the transaction system TS.
  • the token value v of a token T is thus revealed by 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.
  • 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 link or concatenation of the token value v and the public part R.
  • This token reference TR can be sent to the token reference register TRR as a registration request RA, possibly together with a command (see overview in FIGS. 3a and 3b) relating to the token T.
  • 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, which further increases security in the transaction system TS.
  • the signed registration request RAsig is stored in the subscriber unit TE as a so-called PROOF, for example in the following format:
  • 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.
  • the token reference TR is stored in the token reference register TRR, as a result of which the token T is registered in the transaction system TS.
  • This 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 accordingly the public representation of the token T from the direct transaction layer TE layer. Mere knowledge or possession of the token reference TR does not allow the token T to be transmitted and does not imply that the TE is in possession of the token T.
  • the token reference TR is used to prevent multiple output attempts and checks whether token values v were generated in an impermissible manner. Therefore, in the token reference register TRR, the Stored token reference TR and possibly the history of the token T and the corresponding registration requests RA from subscriber units TE.
  • the tokens T are stored, for example, in electronic purses, so-called 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 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 tokens T of the TE, to generate token references TR, to modify tokens T and/or to exchange tokens T.
  • Wallets are used to communicate with the token reference register TRR, to generate registration requests RA to the token reference register TRR and/or to carry out transactions from token T to a subscriber unit TE.
  • the transaction system TS is set up to carry out a transaction offline, ie without a communication link to the token reference register TRR. A corresponding registration of token T can therefore follow a transmission of the token T to a subscriber 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 token reference TR is transmitted from a secure element as a subscriber unit on which there is an electronic purse, for example as an APDU command(s) to a terminal device (smartphone) of the subscriber, which preferably includes the secure element.
  • An APDU is a combined command/data block of a connection protocol between the secure element and the end device.
  • the structure of the APDU is defined by the ISO-7816-4 standard.
  • the end device unpacks APDU command(s) and transfers the data in API calls to the token reference register TRR, where it is converted into HTTP codes.
  • 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 the database 1 as a representative.
  • This database 1 can consist of a combination of many databases (see also FIG. 9), which are networked with one another.
  • the public part R of the token reference TR is also a database index in the 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.
  • the token reference register TRR will include at least one verification unit 2 .
  • the verification unit 2 of the token reference register TRR verifies registration requests RA.
  • a syntactical correctness or also the correct specification of a command in the registration request RA can be verified.
  • a history of old (past) registration requests RA relating to a token T can also be verified.
  • the separation of this verification unit 2 from the database 1 distributes the tasks of filing and verification (or checking) and increases the speed in the token reference register TRR.
  • the token reference register TRR can include an optional checking unit 3, which checks the registration request RA, in particular before the verification unit 2 uses the contents of the database 1 to verify it.
  • the checking unit 3 checks the registration request itself, ie only its contents. For example, the syntactical correctness, sum of the token values in the registration request (results in zero), command type and/or a signature of the registration request are checked.
  • a total token value checking unit (5 in Fig. 9) can check whether the current total sum of the token values of token references of registered tokens in the token reference register TRR corresponds to the total token value.
  • the total token value of the registered tokens must not change as a result of the registration request from (normal) subscriber units TE1. If this were the case, then a new token value v would be created or an existing token value v destroyed. Only privileged entities, such as a publisher entity TH in the present case, are allowed to do this in the transaction system TS.
  • 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 first registered or token references TR to be deleted are de-registered.
  • a re-registration unit 4 in which newly generated token references TR of a token issuer TH are first registered or token references TR to be deleted are de-registered.
  • a registration request RA is preferably signed with the private part r.
  • the signature allows the recipient (TRR or TE) to easily check the syntactical authenticity of the command. This check is preferably carried out in the checking unit 3 or the verification unit 2.
  • a register request RA can be syntactically validated, for example, by checking the signature and/or the token reference TR.
  • FIG. 3a shows an overview of commands CO which can be carried out on a token T.
  • command codes are given as an example (0x01 to 0x05), which can then be part of a registration request RA.
  • 3b shows an overview of commands CO and their signed registration request syntax RA.
  • input tokens T and input token references TR are “consumed” for each command CO.
  • CO output token T output token references TR are “generated” for each command.
  • a command CO has the basic structure of the following three elements: command type, input token reference(s), output token reference(s).
  • Each command has a characteristic number of input token reference(s) ("inputs”) and output token reference(s) ("outputs”), which are explained and illustrated in more detail in FIGS.
  • Each registration request can be signed in order to be able to check that the sender of the token reference TR is also in possession of the associated token T.
  • An ECDSA scheme can be used as a signature.
  • the registration request RA is preferably signed with the private part r of the token T.
  • a further signature of a token issuer TH is required for signed registration requests of the command types CO “create” and “delete” in order to ensure that these commands have been generated by a privileged unit of the transaction system TS.
  • FIG. 4 shows an exemplary embodiment of a flow chart of a method according to the invention for creating a token T and registering it in the TRR.
  • the signed registration request RA Sig and the command structure are shown in tabular form both from the point of view of the TE layer and the TR layer.
  • a random number r is generated in a privileged unit, here the token issuer TH. Based on the random number r, a public part R is calculated as described above.
  • a token reference TR can thus be formed in the token issuer TH starting from the token value v and the public part R by concatenating v and R.
  • a registration request RA consisting of the command “CREATE” or the command code according to FIG. 3a and 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.
  • the token T is issued to the TE1.
  • the signed registration request RA Sig is issued to the TRR.
  • the signature of the registration request RA is checked in the token reference register TRR using the public key PKey of the issuer entity TH.
  • This public key PKeyTH is known throughout the transaction system or was made available to the token reference register TRR in advance. If the signature check is successful, then the token reference TR is entered in the token reference register TRR.
  • the total token value of the transaction system TS is increased by the token value v by the new registration unit 4 of the token reference register TRR, in particular in a total token value checking unit of the token reference register TRR.
  • FIG. 5 shows an exemplary embodiment of a flow chart of a method according to the invention for deleting a token T and registering the deleted T in the TRR.
  • the signed registration request RA Sig TH and RA Sig T required for this, as well as the command structure, are shown in tabular form both from the point of view of the TE layer and the TR layer.
  • the token T to be deleted is used as an 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.
  • the registration request RA consisting of the “DESTROY” command and the token reference TR to be deleted is signed once with the private key pKey of the token issuer TH.
  • 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.
  • Both signed registration requests are sent to the token reference register TRR.
  • the signature is checked in the token reference register TRR using the public key of the issuing authority TH. This public key is known throughout the transaction system or was made available to the token reference register TRR in advance.
  • the signature of the further registration request RA is checked with the public part of the token reference TR. If both signature checks are successful, then the token reference TR in the TRR is deleted or marked as deleted.
  • the total token value of the transaction system TS is reduced by the token value v by the new registration unit 4 of the token reference register TRR in a total token value checking unit of the token reference register TRR.
  • the token reference register TRR or the token issuer TH also cause the token T in the subscriber unit TEL to be deleted
  • FIG. 6 shows an exemplary embodiment of a flow chart of a method according to the invention for dividing a token T a and registering the divided token Tb T c in the token reference register TRR.
  • the signed registration request RAsig Ta required for this and the command structure are shown in tabular form both from the point of view of the TE layer and the TR layer.
  • a first random number r c and a second random number r c are generated by the TE1. Based on this, a public part Rb and Rc is then generated in each case.
  • the token T a to be divided is available as an input parameter in the TE layer.
  • the token value v a is divided into a first partial token value Vb and a second partial token value v c .
  • the sum of the token part value Vb and the token part value vc must result in the token value va . This ensures that no new token value v is created or a token value v is destroyed.
  • the token references TRb and TRC are then generated by the TE1.
  • the registration request RA then contains the command “SPLIT” or the one shown for it in FIG. 3a command code, the input token reference TR a and the output token references TRb and TR C .
  • This registration request RA is signed with the random number r a of the token T a .
  • the token value difference between the input token reference TRa and the output token references TRb and TRc is formed in the token reference register TRR in (the verification unit 2 or) the checking unit 3 and checked to see if this difference is zero. If the difference is not zero, then a token value v was generated or destroyed in an illegal manner.
  • the total token value of the transaction system TS could theoretically also be checked by the checking unit 3 of the token reference register TRR (by means of the total token value checking unit 5) before or after the registration of the token references TRb and TRC .
  • the total token value v in the total token value checking unit 5 must not have changed and must correspond to the value in the token reference register TRR before the registration request was processed.
  • the split token Tb (or Tc ) (which has meanwhile been transferred from TE1 to TE2) can now be checked for validity by the subscriber unit TE2 in the TRR.
  • FIG. 7 shows an exemplary embodiment of a flow chart of a method according to the invention for connecting a token Td with a token T e and registering the connected token Tf in the TRR.
  • the signed registration requests RA Sig rd and RA Sig Te required for this as well as the command structure are shown in tabular form both from the point of view of the TE layer and the TR layer.
  • a random number rf is generated in a TE1 of the TE layer. Based on this, a public part Rf is then generated. In addition, a sum is formed from the token values Vd and v e to form the token value Vf based on the input tokens Td and T e .
  • a registration request RA then contains the command “MERGE” or the command code listed in FIG. 3a, the two input token references TRd and TRe and the output token reference TRf.
  • This registration request RA is signed once with the random number rd of the token Td to create a first to receive a signed registration request RA Sig _Td.
  • This registration request is also signed with the random number r e of the token T e in order to obtain a second signed registration request RA Sig _Te.
  • Both signed registration requests RA Sig rd and RA Sig Te are sent from the subscriber unit TE1 to the token reference register TRR.
  • the signatures of the registration requests RA Sig _Td and RA Sig Te are checked there.
  • the connected token Tf (which has meanwhile been transmitted from TE1 to TE2) can now be checked for validity by the subscriber unit TE2 in the TRR.
  • FIG. 8 shows an exemplary embodiment of a flow chart of a method according to the invention for switching a token T g to a token Th and registering the switched token Th in the token reference register TRR.
  • the required signed registration requests RA Sig _r g and the command structure are shown in tabular form both from the point of view of the TE layer and the TR layer.
  • a random number rh is generated in a TE1.
  • a public part Rh is then generated based on this.
  • the token value Vh which is identical to the token value vg of the input token Tg , is formed.
  • 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 public part Rh formed (or the output token reference TRh).
  • This registration request RA is signed with the random number r g of the token T g .
  • the signed registration request RA Sig r g is sent from the subscriber unit TE1 to the token reference register TRR.
  • the signature is checked there.
  • FIG. 9 shows a further embodiment of a token reference register TRR of a transaction system TS.
  • FIG. 9 indicates that a plurality of memory units 1 can be kept available in the token reference register TRR in order to speed up the storage of a large number of token references TR. It is also indicated here that several verification Units 2 and/or test units 3 can be kept in the token reference register TRR in order to speed up verification of registration requests RA.
  • Registration requests from secure elements or other subscriber units are processed in one of the verification units 2 and optionally beforehand in one (the) optional checking unit(s) 3 .
  • Registration requests from the token issuer (TH) are optionally processed by the re-registration unit 4 before verification (and/or checking).
  • the optional total token value checking unit 5 checks - for example at a predetermined or randomly varying time interval (x,y), such as every x hours or y days, or at the request of the checking unit 3, whether the total sum of the token values of valid tokens in the token -Reference register TRR equals the total token value.
  • a subscriber unit TEB which functions as an interface between the transaction system TS and a book money system (lending, account management) and allows subscriber units TE, for example, to transfer tokens T of the transaction system TS to another transaction system.
  • This transition is bi-directional and can be done using the token issuer TH, which is solely responsible for regenerating token T and also for token T erasure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Bioethics (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung betrifft ein sicheres Element, ein Tokenreferenz-Register sowie ein Verfahren zum Registrieren von Token eines elektronischen Transaktionssystems, wobei jeder Token des Transaktion systems zumindest einen Tokenwert und einen privaten Teil eines tokenindividuellen Schlüsselpaars als Token-Elemente aufweist, mit den Verfahrensschritten: Empfangen, in einem Tokenreferenz-Register des Transaktionssystems, einer Registrieranfrage aufweisend zumindest eine einem Token des Transaktionssystems eindeutig zugeordnete Tokenreferenz, wobei die Tokenreferenz zumindest den Tokenwert des Tokens und einen öffentlichen Teil des tokenindividuellen Schlüsselpaars als Tokenreferenz-Elemente aufweist, wobei der öffentliche Teil des tokenindividuellen Schlüsselpaars durch Anwenden einer kryptografischen Einwegfunktion auf den privaten Teil des tokenindividuellen Schlüsselpaars des Tokens erhalten wurde, Verifizieren, durch eine Verifiziereinheit des Tokenreferenz- Registers, ob die zumindest eine Tokenreferenz der empfangenen Registrieranfrage in dem Tokenreferenz-Register gespeichert ist, und Speichern der zumindest einen Tokenreferenz in einer Speichereinheit des Tokenreferenz-Registers zum Registrieren des dieser Tokenreferenz eindeutig zugeordneten Tokens im Transaktionssystem, wenn im Verifizieren- Schritt festgestellt wird, dass die zumindest eine Tokenreferenz der empfangenen Registeranfrage nicht im Tokenreferenz-Register gespeichert ist.

Description

SICHERES ELEMENT, VERFAHREN ZUM REGISTRIEREN VON TOKEN UND TOKENREFERENZREGISTER
Die Erfindung bezieht sich auf ein Verfahren zum Registrieren von Token, insbesondere eines sicheren Elements als Transaktionseinheit, auf ein sicheres Element sowie auf ein Tokenreferenzregister, in dem Tokenreferenzen gespeichert werden, die eindeutig einem Token zugeordnet sind, sowie auf das Transaktionssystem insgesamt.
Mit Hilfe sicherer Elemente, wie Chipkarten, SIM-Module etc, als Transaktionseinheiten kann bekanntermaßen eine sichere direkte Übertragung zwischen den Transaktionseinheiten erreicht werden, wobei bewusste Mehrfachausgaben von Token, auch Double-Spending genannt, bereits ausgeschlossen sind.
Beispielsweise aus DE 10 2009 038 645 Al und der DE 10 2009 034 436 Al sind Systeme bzw. tragbare Datenträger als sichere Elemente zum Übertragen von geldwerten Beträgen in Form elektronischer Datensätze bekannt, bei denen ein Bezahlen mit Duplikaten des Datensatzes verhindert und ein hoher Grad an Manipulations Sicherheit gegeben ist. Hier sind komplexe Strukturen und aufwendige Verschlüsselungs- und Signiervorgänge für die Transaktionen erforderlich. Diese haben sich als wenig praxistauglich herausgestellt.
Zur Sicherheit von Transaktionen und den dazugehörigen Transaktionsdaten gehören sowohl Schutz der Vertraulichkeit der ausgetauschten Daten; als auch Schutz der Integrität der ausgetauschten Daten; als auch Schutz der Verfügbarkeit der ausgetauschten Daten.
Als Lösungsansätze für sichere Transaktionssysteme wird oft zwischen tokenbasierten Systemen und accountbasierten Systemen unterschieden. Neben herkömmlichen accountbasierten Systemen wurden zuletzt neuartigere accountbasierte Systeme basierend auf Blockchain-Topologien diskutiert. Sie stellen zwar einen hohen Schutz der Integrität bereit, veröffentlichen jedoch auch viele Informationen, beispielsweise wenn Datensätze in einer frei lesbaren Datenstruktur vorliegen und dort den Besitzer wechseln.
Es ist ebenfalls bereits bekannt, ein tokenbasiertes Transaktionssystem noch um ein Token- Register zu erweitern. Das sichere Element sendet eine Registrierungsanfrage für seinen Token an das Register. Das Register verifiziert die Registrierungsanfrage und speichert vorzugsweise nur eine Tokenreferenz für den Token, kennt also vorzugsweise nicht den Token selbst. Die Erfindung bedient sich eines Verfahrens zum Registrieren von direkt zwischen Teilnehmereinheiten übertragbaren Token.
WO 2020/212337 Al beschreibt ein Transaktionssystem, bei dem sogar Modifikationen am Token - beispielsweise durch Aufteilen des Tokens, offline, also direkt zwischen den sicheren Elementen des Transaktionssystems und ohne weitere Kontrollinstanz, gesichert möglich sind. Die Token können - nach dem Erhalt in einem sicheren Element bzw. einer Teilnehmereinheit - sofort weiter übertragen werden, ohne dass eine Registrierung einer Modifikation in einem Token-Register des Transaktionssystems erfolgen muss. Die sicheren Elemente sind bekanntermaßen jedoch ressourcenbeschränkt, insbesondere bezüglich Speicherplatz und/oder V erarbeitungsgeschwindigkeit begrenzt.
Der Erfindung liegt die Aufgabe zu Grunde, ein sicheres Element und ein Verfahren zum Registrieren von Token eines Transaktionssystems zu schaffen, in denen eine Übertragung von Token sicher aber dennoch einfach genug - gerade für sichere Elemente - ausgestaltet ist.
Dabei soll insbesondere eine direkte Übertragung eines Tokens, gegebenenfalls eines modifizierten Tokens, zwischen Teilnehmereinheiten geschaffen werden. Diese Transaktion soll für Dritte anonym bleiben. Der Token soll nach dem Erhalt in einer Teilnehmereinheit sofort weiterverwendet werden können, um eine Transaktion auch ohne Verbindung zu einer entfernten Einheit, beispielsweise einem zentralen Register oder einem dezentralen Ledger, zu ermöglichen. Ein empfangener Token soll einerseits geheim gegenüber nicht an der Transaktion beteiligten Teilnehmereinheiten sein. Jede Teilnehmereinheit des Transaktionssystems soll einen erhaltenen Token überprüfen können, insbesondere sollen Mehrfach-Ausgabe-Versuche und Versuche, nicht vorhandene Tokenwerte zu übertragen, von einer Teilnehmereinheit oder allgemein im Transaktionssystem erkannt werden können.
Die gestellte Aufgabe wird durch die in den unabhängigen Patentansprüchen beschriebenen Gegenstände gelöst. Weitere vorteilhafte Ausgestaltungen sind in den jeweils abhängigen Patentansprüchen beschrieben. Die Aufgabe wird insbesondere durch ein Verfahren zum Registrieren von Token eines elektronischen Transaktionssystems gelöst, wobei jeder Token des Transaktionssystems zumindest einen Tokenwert und einen privaten Teil eines tokenindividuellen Schlüsselpaars als Token-Elemente aufweist.
Das Verfahren umfasst die Verfahrensschritte: Empfangen, in einem Tokenreferenz-Register des Transaktionssystems, einer Registrieranfrage aufweisend zumindest eine einem Token des Transaktionssystems eindeutig zugeordneten Tokenreferenz, wobei die Tokenreferenz zumindest den Tokenwert des Tokens und einen öffentlichen Teil des tokenindividuellen Schlüsselpaars als Tokenreferenz-Elemente aufweist, wobei der öffentliche Teil des tokenindividuellen Schlüsselpaars durch Anwenden einer kryptografischen Einwegfunktion auf den privaten Teil des tokenindividuellen Schlüsselpaars des Tokens erhalten wurde, Verifizieren, durch eine Verifiziereinheit des Tokenreferenz-Registers, ob die zumindest eine Tokenreferenz der empfangenen Registrieranfrage in dem Tokenreferenz-Register gespeichert ist, und Speichern der zumindest einen Tokenreferenz in einer Speichereinheit des Tokenreferenz-Registers zum Registrieren des dieser Tokenreferenz eindeutig zugeordneten Tokens im Transaktionssystem, wenn im Verifizieren- Schritt festgestellt wird, dass die zumindest eine Tokenreferenz der empfangenen Registeranfrage nicht im Tokenreferenz- Register abgespeichert ist.
Das Empfangen erfolgt bevorzugt an einer Schnittstelle des Tokenreferenz-Registers, bevorzugt einer Schnittstelle der Verifiziereinheit des Tokenreferenz-Registers.
Ein Transaktions system ist ein System in dem zumindest zwei, bevorzugt eine Vielzahl von Teilnehmereinheiten Token direkt untereinander austauschen (übertragen) können. Das Transaktionssystem ist beispielsweise ein Bezahltransaktionssystem zum Austausch von geldwerten Beträgen in Form von Bezahl-Token.
Ein Token ist ein zwischen Teilnehmereinheiten direkt austauschbarer Datensatz eines Transaktionssystems. Mit Kenntnis des Tokens ist die empfangende Teilnehmereinheit im Besitz des Tokenwerts, den der Token repräsentiert. Mit dem Austauschen wechselt der Token demnach automatisch den Besitzer. Ein Token - ein Datensatz, der unabhängig von einem Account in einer Transaktionstopologie übertragbar ist - kann direkt zwischen den Teilnehmereinheiten übertragen werden, also insbesondere ohne dass eine andere Einheit des Transaktionssystems dazwischen geschaltet ist und/oder Zugriff auf den Token hat. In einer Ausgestaltung ist der Token ein elektronischer Münzdatensatz oder Bezahl-Token, um geldwerte Beträge zwischen Teilnehmereinheiten zu tauschen. Umgangssprachlich wird ein derartiger Bezahl-Token auch als „digitale Münze” oder „elektronische Münze”, englisch „digital/electronic coin“ bezeichnet und repräsentiert Bargeld in elektronischer Form.
Jeder Token im Transaktionssystem ist ein Datensatz umfassend zumindest zwei Tokenelemente.
Ein erstes Tokenelement jedes Tokens des Transaktionssystems ist ein Tokenwert, bspw. ein Vermögens wert, ein Vermögensgegenstand, ein Wirtschaftsgut und/oder ein geldwerter Betrag.
Ein zweites Tokenelement jedes Tokens des Transaktionssystems ist ein privater Teil eines tokenindividuellen Schlüsselpaars. Dieser private Teil ist ein Geheimnis im Transaktionssystem und wird nicht veröffentlicht und darf nicht mehrfach verwendet werden. Die Erzeugung des privaten Teils darf nicht vorhersagbar sein. Dieser private Teil kann eine Zufallszahl sein. Bevorzugt ist die Zufallszahl das Ergebnis eines echten Zufallsgenerators.
Aus dem Tokenwert (erstes Tokenelement) und dem privaten Teil wird der Token gebildet. Dieses Bilden ist bevorzugt das Verketten (Konkatenation) dieser beiden Tokenelemente. Jede andere Art der Verknüpfung dieser beiden Tokenelemente ist erfindungsgemäß nicht ausgeschlossen und umfasst beispielsweise das Hintereinander-Anfügen, das Einbringen in eine TLV-Datenstruktur und/oder das logische Verknüpfen.
Jeder, der im Besitz eines Tokens ist oder uneingeschränkten Zugriff auf den Token mit seinen Tokenelementen hat, kann diesen Token mit einer anderen Teilnehmereinheit austauschen. Der Besitz des Tokens mit seinen zumindest zwei Tokenelementen (Tokenwert und privater Teil des tokenindividuellen Schlüsselpaars) ist also gleichbedeutend mit dem Besitz des Wertes, den der Token repräsentiert.
Jedem Token im Transaktionssystem wird eine Tokenreferenz zugeordnet. Diese Zuordnung ist eineindeutig, das heißt, einem Token ist genau eine Tokenreferenz zugeordnet und jeder Tokenreferenz ist genau ein Token zugeordnet. Die Tokenreferenz ist ein öffentlicher Datensatz, der in einer Speichereinheit des Tokenreferenz-Registers des Transaktionssystems für jede Teilnehmereinheit überprüfbar abgespeichert ist.
Sowohl der Token als auch die Tokenreferenz sind einzigartig. Durch die eineindeutige Zuordnung herrscht eine 1-zu-l Beziehung zwischen dem Token und der Tokenreferenz. Jede Tokenreferenz im Transaktion system ist ein Datensatz umfassend zumindest zwei T okenreferenz-Elemente .
Ein erstes Tokenreferenz-Element jeder Tokenreferenz ist der Tokenwert des der Tokenreferenz eindeutig zugeordneten Tokens. Der Tokenwert des Tokens ist damit identisch zum Tokenwert der zugeordneten Tokenreferenz. Beispielsweise ist der Tokenwert der Tokenreferenz eine Kopie des Tokenwerts des zugeordneten Tokens.
Ein zweites Tokenelement jeder Tokenreferenz des Transaktionssystems ist ein öffentlicher Teil des tokenindividuellen Schlüsselpaars. Dieser öffentliche Teil der Tokenreferenz bildet zusammen mit dem privaten Teil des Tokens das tokenindividuelle Schlüsselpaar. Der öffentliche Teil wird durch Anwenden einer kryptografischen Funktion auf den privaten Teil erhalten.
Diese kryptografische Funktion ist eine Einwegfunktion. Diese kryptografische Funktion ist demnach eine mathematische Funktion, die komplexitätstheoretisch „leicht“ berechenbar, aber „schwer“ bis praktisch unmöglich umzukehren ist. Hierbei wird unter Einwegfunktion auch eine Funktion bezeichnet, zu der bislang keine in angemessener Zeit und mit vertretbarem Aufwand praktisch ausführbare Umkehrung bekannt ist. Vorzugsweise wird eine Einwegfunktion verwendet, die auf eine Gruppe operiert, in der das diskrete Logarithmusproblem schwer zu lösen ist, wie z. B. ein kryptographisches Verfahren analog einer elliptischer-Kurve-Verschlüsselung, kurz ECC, aus einem privaten Schlüssel eines entsprechenden Kryptographie- Verfahrens. Die umgekehrte Funktion, also die Erzeugung eines Tokens (oder des Teils des elektronischen Münzdatensatzes) aus einer Tokenreferenz ist dabei sehr zeitintensiv.
Die (bloße) Kenntnis oder der Besitz einer Tokenreferenz berechtigt nicht dazu, den Tokenwert (Tokenreferenz-Element) zu verwenden/ übertragen/auszugeben. Dies stellt einen wesentlichen Unterschied zwischen der Tokenreferenz und dem Token dar und ist ein Kern der hier vorliegenden Erfindung.
Nach dem Anwenden der kryptografischen Funktion auf den privaten Teil des tokenindividuellen Schlüsselpaars wird der öffentliche Teil des tokenindividuellen Schlüsselpaars als zweites Tokenreferenz-Element erhalten. Aus dem Tokenwert (erstes Tokenreferenz-Element) und dem öffentlichen Teil wird die Tokenreferenz gebildet. Dieses Bilden ist bevorzugt das Verketten (Konkatenation) dieser beiden Tokenreferenz-Elemente. Jede andere Art der Verknüpfung dieser beiden Tokenreferenz-Elemente ist erfindungsgemäß nicht ausgeschlossen und umfasst beispielsweise das Hintereinander- Anfügen, das Einbringen in eine TLV-Datenstruktur und/oder das logische Verknüpfen.
Eine Tokenreferenz kann bevorzugt durch eine elektronische Geldbörse (=Wallet) einer Teilnehmereinheit erzeugt werden. Dazu muss die Teilnehmereinheit Kenntnis von dem Token mit seinen Tokenelementen aufweisen. Das Erzeugen der Tokenreferenz kann durch eine elektronische Geldbörse einer Teilnehmereinheit erfolgen, die den Token senden möchte. Alternativ kann das Erzeugen der Tokenreferenz durch eine elektronische Geldbörse einer Teilnehmereinheit erfolgen, die den Token empfangen hat.
Die Verwendung einer Tokenreferenz ist nicht mit der Verwendung von Adressen von Teilnehmereinheiten in einem Blockchain-basierten Transaktionssystem vergleichbar, unter anderem da im erfindungsgemäßen Tokenreferenz-Register keine Adressen der Teilnehmereinheiten verwendet werden, um eine Verfolgbarkeit der Token zu verhindern.
Das Verfahren zum Registrieren sieht einen Empfangen-Schritt vor, um eine Tokenreferenz in einem Tokenreferenz-Register im Rahmen einer Registrieranfrage zu empfangen. Beispielsweise wird die Registrieranfrage von einer Teilnehmereinheit des Transaktionssystems oder eines Tokenherausgebers des Transaktionssystems gesendet.
Das Tokenreferenz-Register ist eine Einheit des Transaktionsregisters die die Tokenreferenzen ablegt, wodurch die dazugehörigen Token registriert sind. Dieses Register kann eine zentrale Datenbank oder Speichereinheit sein. Dieses Register kann ein dezentraler Ledger, beispielsweise in einer Blockchain-Topologie sein. Das Tokenreferenz-Register kann eine Historie zu den Tokenreferenzen und/oder den Registrieranfragen führen.
Die empfangene Registrieranfrage wird durch eine Verifiziereinheit im Tokenreferenz-Register verifiziert. Dabei wird verifiziert, ob die zumindest eine Tokenreferenz der empfangenen Registrieranfrage in dem Tokenreferenz-Register bereits gespeichert ist.
Im Tokenreferenzregister ist eine Tokenreferenz nur ein einziges Mal gespeichert. Da eine Tokenreferenz eines Tokens nur ein einziges Mal im Transaktions system vorhanden ist, kann durch den Verifizieren-Schritt festgestellt werden, ob versucht wurde, einen Token mehrfach auszugeben.
In einer Ausgestaltung wird im Verifizieren-Schritt durch die Verifiziereinheit des Tokenreferenz-Registers zudem festgestellt, ob die Tokenreferenz in der empfangenen Registrieranfrage einem Token zugeordnet werden kann. Dazu muss die Tokenreferenz oder eine Ableitung der Tokenreferenz oder eine Historie zu der Tokenreferenz in dem Tokenreferenz-Register abgespeichert sein, die zu der Tokenreferenz der empfangenen Registrieranfrage zugeordnet werden kann.
In einer Ausgestaltung wird im Verifizieren-Schritt festgestellt, ob die empfangene Registrieranfrage syntaktisch korrekt ist. Damit wird beispielsweise geprüft, ob die Registrieranfrage plausibel ist, ob in der Registrieranfrage ein Kommandotyp korrekt angegeben wurde, ob der Token, der der Tokenreferenz eindeutig zugeordnet ist, tatsächlich vorhanden ist (existieren kann); und/oder ob eine Differenzbildung von Tokenwerten in der Registrieranfrage zu einem in der Registrieranfrage angegebenen Kommandotyp passt.
In einer Ausgestaltung wird im Verifizieren-Schritt festgestellt, ob eine Signatur der Registrieranfrage korrekt ist.
In einer Ausgestaltung wird im Verifizieren-Schritt zudem festgestellt, ob eine Summe von Tokenwerten aller Tokenreferenzen innerhalb der Registrieranfrage null ist. Dabei werden Eingangs-Tokenwerte und Ausgangs-Tokenwerte der Registrieranfrage aufsummiert. Bei Registrieranfragen, die von Teilnehmereinheiten stammen, muss eine Summe aller Tokenwerte der Registrieranfrage null ergeben. Ergibt die Summe nicht null, so wurde in unerlaubter Weise zusätzlich ein Tokenwert im Transaktionssystem geschaffen oder ein Tokenwert aus dem Transaktionssystem vernichtet. Damit kann ein Betrugsversuch mit nicht-vorhandenen Token oder unerlaubt generierten Token leichter erkannt werden. Bislang waren aufwendige Bereichsnachweise (zero-knowledge-proofs, ZKP) notwendig, die durch dieses Verfahren entfallen können.
Die empfangene Tokenreferenz wird in einer Speichereinheit des Tokenreferenz-Registers gespeichert. Mit dem Speichern erfolgt ein Registrieren des der empfangenen Tokenreferenz eindeutig zugeordneten Tokens im Transaktionssystem. Das Speichern erfolgt nur wenn im Verifizieren-Schritt festgestellt wird, dass die zumindest eine Tokenreferenz der empfangenen Registeranfrage nicht im Tokenreferenz-Register gespeichert ist. Das Grundprinzip des Registrierens eines Tokens ist demnach, dass eine empfangene Registrieranfrage verifiziert wird daraufhin, ob die dem Token zugeordnete Tokenreferenz im Tokenreferenz-Register bereits bekannt ist. Ist die Tokenreferenz bereits bekannt, wird sie nicht nochmal abgespeichert. Ist die Tokenreferenz nicht bekannt, wird sie in das Tokenreferenz- Register eingetragen (gespeichert), um für zukünftige Verifizier- und Prüfschritte im Transaktionssystem verfügbar zu sein.
In einer Ausgestaltung ist der öffentliche Schlüsselteil des tokenindividuellen Schlüsselpaars der Tokenreferenz zugleich ein Datenbankenindex einer Datenbank des Tokenreferenz- Register. Dabei ist der Datenbankindex eine von der Datenstruktur getrennte Indexstruktur in dem Tokenreferenz-Register, die die Suche und das Sortieren nach Tokenreferenzen beschleunigt. Er kann eine Ansammlung von Zeigern (Verweisen) sein, die eine Ordnungsrelation auf eine oder mehrere Einträge im Tokenreferenz-Register definieren. Durch Verwendung des öffentlichen Schlüsselteils als Index wird das Verifizieren stark vereinfach. Damit ist keine Prüfung von Dubletten mehr nötig, weil in dem Tokenreferenz-Register die Eineindeutigkeit des Index bereits geprüft wird.
In einer Ausgestaltung ist die empfangene Registrieranfrage mit dem privaten Teil des tokenindividuellen Schlüsselpaars signiert, um eine Zuordnung von der Tokenreferenz zu dem Token prüfen bzw. verifizieren zu können. Ist das Verifizieren im Verifizieren- Schritt erfolgreich, also kann die Signatur verifiziert werden, dann muss der Sender der Registrieranfrage im Besitz des Tokens bzw. in Kenntnis des Tokens sein. Damit kann ein Betrugsversuch mit nicht-vorhandenen Token oder unerlaubt generierten Token erkannt werden.
In einer Ausgestaltung weist das Tokenreferenz-Register eine oder mehrere Speichereinheit zum Speichern von Tokenreferenzen zum Registrieren der Token im Transaktions system auf. Diese Speichereinheit(en) kann/können als eine zentrale Datenbank des Transaktionssystems geführt sein. Die Verwendung von mehreren Speichereinheiten ermöglicht eine parallele Bearbeitung von Registrieranfragen und beschleunigt das Registrieren im Transaktionssystem.
In einer Ausgestaltung weist das Tokenreferenz-Register eine oder mehrere Verifiziereinheiten zum Verifizieren von empfangenen Registrieranfragen auf. Die Verwendung von mehreren Verifiziereinheiten ermöglicht eine parallele Bearbeitung von Registrieranfragen und beschleunigt das Registrieren im Transaktionssystem. Diese Verifiziereinheit(en) vergleicht/en beispielsweise einen Kommandotyp der empfangenen Registrieranfrage mit den Tokenwerten der empfangenen Registrieranfrage. Wird von einem Kommandotyp erwartet, dass keine Tokenwerte zum Transaktionssystem addiert oder vom Transaktionssystem subtrahiert werden sollen, so wird geprüft, ob dies mit den Tokenwerten der empfangenen Tokenreferenzen auch eingehalten wird. Bei fehlgeschlagener Verifzierung wird ein Betrugsfall erkannt und ein Registrieren verhindert.
In einer Ausgestaltung weist das Tokenreferenz-Register eine (oder mehrere) Prüfeinheiten zum Prüfen der empfangenen Registrieranfrage auf. Die Prüfeinheit prüft die Registrieranfrage, insbesondere auf syntaktische Korrektheit der Registrieranfrage, Zulässigkeit eines Kommandotyps der Registrieranfrage, Summe der Tokenwerte in der Registrieranfrage (muss Null sein) und/oder Signatur der Registrieranfrage, bevor sie von der Verifzierungseinheit verifziert wird. Nur die Inhalte der Registrieranfrage werden durch die Prüfeinheit geprüft. Diese Prüfung benötigt also keinen Zugriff auf die Speichereinheit (bzw. erfolgt ohne Zugriff auf die Speichereinheit). Die von einer Prüfeinheit durchgeführten Prüfschritte muss die Verifiziereinheit nicht mehr durchführen. Die Verifziereinheit kann somit entlastet werden.
In einer Ausgestaltung weist das Tokenreferenz-Register eine Gesamtsummen-Prüfeinheit zum Prüfen einer Gesamtsumme von Tokenwerten der Tokenreferenzen registrierter Token auf. Bevorzugt unabhängig vom Empfang einer Registrieranfrage wird die Gesamtsumme geprüft. Sie wird beispielsweise in zeitlich regelmäßigen Abständen oder zeitlich zufällig oder ereignisbedingt geprüft. Die Gesamtsummen-Prüfeinheit bestimmt eine aktuelle Gesamtsumme und vergleicht die aktuelle Gesamtsumme mit einem Gesamt-Tokenwert. Der Gesamt- Tokenwert wird durch Registrieranfragen von (normalen) Teilnehmereinheiten nicht verändert. Der Gesamt-Tokenwert kann sich durch Registrieranfragen des Tokenherausgebers ändern. Der Gesamt-Tokenwert wird vorzugsweise auf Anforderung einer Neuregistrierungseinheit geändert, über welche nur der Tokenherausgeber neue Token registrieren kann oder registrierte Token deregistrieren kann. Eine Prüfeinheit kann für eine Registrieranfrage die Gesamt- Tokenwert-Prüfung anfordem. Damit kann die Gültigkeit des Tokenwerts daraufhin geprüft werden, ob ein neuer Tokenwert unerlaubter Weise generiert wurde. Mittels einer Prüfung des Gesamt-Tokenwerts durch Bilden der Gesamtsumme werden indirekt alle alten Registrieranfragen geprüft und können auch gezielt alte Registrieranfragen und deren Erfolg geprüft werden.
Eine Registrieranfragen-Historie könnte verwendet werden, um ohne Belastung der Speichereinheit des Tokenreferenz-Registers, doppelt gesendete Registrieranfragen zu bearbeiten. In einer Ausgestaltung weist das Tokenreferenz-Register eine Neuregistrierungseinheit auf, um Tokenreferenzen zu neu erzeugten Token (=neue Token) oder gelöschten Token (deaktivierte Token) eines Tokenherausgebers zu registrieren. Über diese Neuregistriereinheit des Tokenreferenz-Registers können diese neu erzeugte Token und diese gelöschte Token in das Tokenreferenz-Register eingetragen werden. Mit der Neuregistriereinheit kann ein Referenzwert betreffend den Gesamt-Tokenwert der im Transaktionssystem befindlichen Token auf Basis der erzeugten und/oder gelöschten Token im Tokenreferenz-Register (beispielsweise in einer Prüfeinheit des Gesamt-Tokenwerts) aktualisiert werden. Wird beispielsweise ein neuer Token generiert, so wird dessen Tokenwert zum Gesamt-Tokenwert addiert. Wird beispielsweise ein Token gelöscht, so wird dessen Tokenwert vom Gesamt- Tokenwert subtrahiert.
In einer Ausgestaltung weist die Tokenreferenz zumindest einen Zählwert als weiteres Tokenreferenz-Element auf. Der Zählwert kann ein weiteres Token-Element sein. Der Zählwert kann beispielsweise die Anzahl von Offline-Transaktionen des Tokens repräsentieren. Eine Offline-Transaktion ist dabei eine direkte Transaktion zwischen Teilnehmereinheiten im Transaktionssystem zum Übertragen von Token, ohne dass der Token im Tokenreferenz- Register registriert wird. Der Zählwert erhöht sich (inkrementiert sich) mit jeder Offline- Transaktion. Es kann systembedingt vorgesehen sein, dass Token bei Überschreiten eines vordefinierten Schwellwerts für den Zählwert automatisch im Tokenreferenz-Register registriert werden müssen.
In einer Ausgestaltung weist die Tokenreferenz zumindest eine Identität einer Teilnehmereinheit oder eines Besitzers der Teilnehmereinheit als weiteres Tokenreferenz- Element auf. Die Identität kann ein weiteres Token-Element sein. Diese Identität dient beispielsweise im Prüfen- Schritt dazu, die Tokenreferenz zu validieren oder zu verifizieren. Damit wird die Anonymität im Transaktionssystem aufgehoben und ein Betrugsfall schneller aufgedeckt.
In einer Ausgestaltung weist die Tokenreferenz zumindest ein Pseudonym einer Teilnehmereinheit oder eines Besitzers der Teilnehmereinheit als weiteres Tokenreferenz- Element auf. Das Pseudonym kann ein weiteres Token-Element sein. Dieses Pseudonym dient beispielsweise im Prüfen- Schritt dazu, die Tokenreferenz zu validieren oder zu verifizieren. Damit wird die Anonymität im Transaktions system nicht aufgehoben und ein Betrugsfall dennoch schneller aufgedeckt, wenn eine Einheit des Transaktionssystems das Pseudonym auflöst. Zum Erzeugen der Tokenreferenz kann jedes weitere Tokenreferenz-Element durch eine Verkettung (Konkatenation) mit dem ersten und/oder zweiten Tokenreferenz-Element hinzugefügt werden.
In einer Ausgestaltung betrifft die Registrieranfrage eine Modifikation - insbesondere Aufteilung, Verbindung oder Umschaltung - zumindest eines zuvor registrierten Tokens und weist bevorzugt zumindest die Tokenreferenz des zumindest einen zuvor registrierten Tokens sowie die zumindest eine Tokenreferenz des zu registrierenden Tokens, welcher die Modifikation des zuvor registrierten Tokens ist, auf.
In einer Ausgestaltung betrifft die Registrieranfrage eine Aufteilung eines Tokens und bevorzugt weist die Registrieranfrage eine Tokenreferenz des aufzuteilenden Tokens und jeweils eine Tokenreferenz der (zumindest zwei) aufgeteilten Token auf. Die in der Registrieranfrage enthaltenen Tokenreferenzen können durch Verkettung (Konkatenation) aneinandergefügt sein. Die Aufteilung (=Split) ist eine Modifikationsmöglichkeit an einem Token, mit der ein Tokenwert eines Tokens in zumindest zwei (kleinere) Tokenwerte aufgeteilt werden kann. Damit ist es möglich den Tokenwert zu verkleinern und auf eine Transaktionsforderung tokenwertgenauer zu reagieren. Damit wird der aufgeteilte Token ungültig und die (zumindest zwei) geteilten Token werden in dem Tokenreferenz-Register registriert, um im Transaktionssystem prüfbar zu werden.
Alternativ oder zusätzlich wird für das Aufteilen vorgesehen, dass der Tokenwert des aufzuteilenden Tokens in wenigstens einen ersten Tokenwert und in einen zweiten Tokenwert aufgeteilt wird. Die Aufteilung kann symmetrisch erfolgen, sodass die aufgeteilten Tokenwerte gleich groß sind. Die Aufteilung kann asymmetrisch erfolgen, sodass die aufgeteilten Tokenwerte ungleich groß sind.
Alternativ oder zusätzlich wird beim Aufteilen vorgesehen: Erzeugen eines neuen privaten Teils eines tokenindividuellen Schlüsselpaars für einen ersten aufgeteilten Token; Anwenden einer kryptografischen Funktion zum Erhalten eines entsprechenden öffentlichen Teils des tokenindividuellen Schlüsselpaars für den ersten aufgeteilten Token; Erzeugen eines neuen privaten Teils eines tokenindividuellen Schlüsselpaars für einen zweiten aufgeteilten Token; Anwenden einer kryptografischen Funktion zum Erhalten eines entsprechenden öffentlichen Teils des tokenindividuellen Schlüsselpaars für den zweiten aufgeteilten Token; Aufteilen des Tokenwerts in einen ersten Tokenteilwert und in einen zweiten Tokenteilwert, unter Beachtung, dass die Summe aus dem ersten Tokenteilwert und dem zweiten Tokenteilwert dem Tokenwert des aufzuteilenden Tokens entspricht; Erzeugen einer Tokenreferenz für den ersten aufgeteilten Token aufweisend den ersten Tokenteilwert und den öffentlichen Teil des tokenindividuellen Schlüsselpaars des ersten aufgeteilten Tokens; Erzeugen einer Tokenreferenz für den zweiten aufgeteilten Token aufweisend den zweiten Tokenteilwert und den öffentlichen Teil des tokenindividuellen Schlüsselpaars des zweiten aufgeteilten Tokens; und Erstellen der Registrieranfrage unter Verwendung der Tokenreferenz des aufzuteilenden Tokens, der Tokenreferenz für den ersten aufgeteilten Token und der Tokenreferenz für den zweiten aufgeteilten Token.
In einer Ausgestaltung betrifft die Registrieranfrage eine Umschaltung eines Tokens und bevorzugt weist die Registrieranfrage eine Tokenreferenz des umzuschaltenden Tokens auf. Die Umschaltung des Tokens ist eine weitere Modifikationsmöglichkeit. Die in der Registrieranfrage enthaltenen Tokenreferenzen können durch Verkettung (Konkatenation) aneinandergefügt sein. Wird ein Token von einer Teilnehmereinheit direkt an eine andere Teilnehmereinheit übertragen, beispielsweise wenn im Rahmen einer Bezahltransaktion der geldwerte Betrag als Tokenwert übertragen werden soll, so kann die empfangende Teilnehmereinheit nun den Tokenwert auf sich umregistrieren lassen. Damit wird im Tokenreferenz-Register die Umschaltung registriert.
Beim Übertragen eines Tokens zwischen zwei Teilnehmereinheiten, haben diese beiden Teilnehmereinheiten zugleich Kenntnis über den Token. Um zu verhindern, dass die sendende Teilnehmereinheit den Token auch noch bei einer anderen (dritten) Teilnehmereinheit ebenfalls verwendet (sogenanntes Mehrfachausgeben des Tokens), wird bevorzugt ein Umschalten („Switch“) des übertragenen Tokens von der ersten Teilnehmereinheit auf die zweite Teilnehmereinheit ausgeführt. Das Umschalten kann bevorzugt automatisch beim Empfangen eines Tokens in der zweiten Teilnehmereinheit erfolgen.
Alternativ oder zusätzlich wird beim Umschalten vorgesehen: Erzeugen eines neuen privaten Teils eines tokenindividuellen Schlüsselpaars; Anwenden einer kryptografischen Funktion zum Erhalten eines entsprechenden öffentlichen Teils des tokenindividuellen Schlüsselpaars; Erstellen der Registrieranfrage unter Verwendung der Tokenreferenz für den umzuschaltenden Token und den öffentlichen Teil des tokenindividuellen Schlüsselpaars für den umgeschalteten Token.
Der Tokenwert des umzu schaltenden Tokens entspricht dem Tokenwert des umgeschalteten Tokens. Beim Umschalten wird demnach ein Token mit gleichem Tokenwert aber neuem privaten Teil bei dem Tokenreferenz-Register registriert. In einer Ausgestaltung betrifft die Registrieranfrage ein Verbinden von zumindest zwei Token betrifft und bevorzugt weist die Registrieranfrage eine Tokenreferenz des verbundenen Tokens und jeweils eine Tokenreferenz der zu verbindenden Token auf. Die in der Registrieranfrage enthaltenen Tokenreferenzen können durch Verkettung (Konkatenation) aneinandergefügt sein. Die Verbindung (= Merge) ist eine Modifikationsmöglichkeit an einem Token, mit der zwei Tokenwerte miteinander verbunden also verknüpft werden. Damit ist es möglich zwei Tokenwerte zu einem Tokenwert zu verschmelzen, um auf eine Transaktionsforderung tokenwertgenau zu reagieren. Damit werden die zu verbindenden Token ungültig und der verbundene Token wird in dem Tokenreferenz-Register registriert, um im Transaktionssystem prüfbar zu werden.
Alternativ oder zusätzlich wird beim Verbinden vorgesehen: Erzeugen eines neuen privaten Teils eines tokenindividuellen Schlüsselpaars; Anwenden einer kryptografischen Funktion zum Erhalten eines entsprechenden öffentlichen Teils des tokenindividuellen Schlüsselpaars für den verbundenen Token; Berechnen des Tokenwerts für den verbundenen Token durch Bilden der Summe aus den jeweiligen Tokenwerten der zumindest zwei zu verbindenden Token; Erzeugen einer Tokenreferenz für den verbundenen Token aufweisend den berechneten Tokenwert und den öffentlichen Teil des tokenindividuellen Schlüsselpaars für den verbundenen Token; und Erstellen der Registrieranfrage unter Verwendung jeder Tokenreferenz der zu verbindenen Token und der Tokenreferenz für den verbundenen Token.
In einer Ausgestaltung wird eine Registrieranfrage von einem Tokenherausgeber versendet, wobei die Registrieranfrage ein Erstellen eines Tokens oder ein Löschen eines Tokens betrifft.
Ein Tokenherausgeber ist im Gegensatz zu einer Teilnehmereinheit eine privilegierte Instanz im Transaktionssystem, durch die Token erzeugt und gelöscht werden können. Eine Teilnehmereinheit kann keinen Token erzeugen oder löschen, sie kann Token nur modifizieren (Umschalten, Aufteilen, Verbinden).
Der Token ist in einer Teilnehmereinheit abgelegt. Die Teilnehmereinheit kann eine Vielzahl von Token aufweisen, beispielsweise kann in einem Datenspeicher der Teilnehmereinheit die Vielzahl von Token abgelegt sein. Der Datenspeicher kann beispielsweise intern, extern oder virtuell sein. In einer Ausgestaltung kann beim Empfangen eines Tokens automatisch ein „Verbinden“ stattfinden, sodass bevorzugt nur ein (oder eine bestimmte Anzahl an) Token in der Teilnehmereinheit abgelegt sind. Die Teilnehmereinheit kann beispielsweise ein mobiles Endgerät, wie z.B. ein Smartphone, ein Tablet-Computer, ein Computer, ein Server oder eine Maschine sein. Die Teilnehmereinheit kann eine Smartcard sein, die betriebsbereit in einem Endgerät eingebracht ist.
Ein sicheres Element ist als Teilnehmereinheit eines Transaktionssystems eingerichtet,
- zum direkten Austausch von Token mit einer weiteren Teilnehmereinheit, wobei jeder Token des Transaktions systems zumindest einen Tokenwert und einen privaten Teil eines tokenindividuellen Schlüsselpaars als Token-Elemente aufweist,
- zum Erstellen eines modifizierten Tokens aus einem vorhandenen, zu modifzierenden Token, wobei eine dem modifizierten Token des Transaktionssystems eindeutig zugeordnete Tokenreferenz zumindest den Tokenwert des Tokens und einen öffentlichen Teil des tokenindividuellen Schlüsselpaars als Tokenreferenz-Elemente aufweist, wobei der öffentliche Teil des tokenindividuellen Schlüsselpaars durch Anwenden einer kryptografischen Einwegfunktion auf den privaten Teil des tokenindividuellen Schlüsselpaars des Tokens erhalten wird, und
- zum Bereitstellen einer Registrieranfrage an ein Tokenreferenz-Register des Transaktionssystems, wobei die Registrieranfrage zumindest die dem Token des Transaktionssystems eindeutig zugeordnete Tokenreferenz aufweist.
Der Datenspeicher ist beispielsweise einen Geldbörsenspeicher einer elektronischen Geldbörse (Wallet). Die elektronische Geldbörse ist beispielsweise eine Softwareapplikation, die auf einer Teilnehmereinheit ausführbar abgespeichert ist. Die elektronische Geldbörse (Wallet) kann der Teilnehmereinheit die Teilnahme am Transaktionssystem ermöglichen. So kann die elektronische Geldbörse eine Registrieranfrage generieren, um einen Token in einem Tokenreferenz-Register zu registrieren. Zudem kann die elektronische Geldbörse Modifikationen (Umschalten, Verbinden, Aufteilen) an einem Token vornehmen und die dabei möglicherweise notwendigen Registrieranfragen generieren und an das Tokenreferenz-Register senden. Zudem kann die elektronische Geldbörse Token an eine andere Geldbörse (in einer anderen Teilnehmereinheit) übertragen.
Eine Transaktion im Transaktionssystem ist vorzugsweise atomar.
Das Tokenreferenz-Register hat demnach Kenntnis über Tokenreferenzen von Token des Transaktionssystems und führt bevorzugt auch die Verarbeitungen bzw. Modifikationen an den Token (Token-Historie). Die Transaktionen mit den Token wird in dem Tokenreferenz- Register nicht registriert und findet in einer Direkttransaktionsschicht des Transaktionssystems direkt zwischen Teilnehmereinheiten des Transaktionssystems statt. Erfindungsgemäß ist ein Tokenreferenz-Register für ein Transaktionssystem vorgesehen, das eingerichtet ist zum Durchführen der Verfahrens schritte gemäß dem zuvor beschriebenen Verfahren.
In einer Ausgestaltung weist das Tokenreferenz-Register auf: zumindest eine Speichereinheit zum Speichern von Tokenreferenzen zum Registrieren von Token im Transaktions system; eine Prüfeinheit zum Prüfen von empfangenen Registrieranfragen; zumindest eine Verifiziereinheit zum Verifzieren, ob eine Tokenreferenz einer empfangenen Registrieranfrage in dem Tokenreferenz-Register gespeichert ist; und/oder eine Neuregistriereinheit zum Registrieren von von einem Tokenherausgeber neu generierten Token oder von von einem Tokenherausgeber gelöschten Token.
Erfindungsgemäß ist ein Transaktionssystem vorgesehen, das aufweist: eine Registerschicht mit einem Tokenreferenz-Register der vorhergehenden Art zum Registrieren von Tokenreferenzen; und eine Direkttransaktionsschicht mit einer Vielzahl von Teilnehmereinheiten, eingerichtet zum direkten Austausch von Token untereinander.
Erfindungsgemäß ist also ein zweischichtiges Transaktionssystem aus einer Direkttransaktions schicht zum direkten Austauschen von Token und einer Registerschicht vorgesehen. In der Registerschicht werden keine Transaktionen protokolliert, sondern ausschließlich Tokenreferenzen abgespeichert und Modifikationen zu Token über entsprechend angepasste Tokenreferenzen zum Zweck der Verifizierung der Gültigkeit von Token abgespeichert. So wird die Anonymität der Teilnehmer des Transaktionssystems gewährleistet. Das Tokenreferenz-Register gibt auf Anfrage Auskunft über die Tokenreferenzen, die eindeutig zu den Token des Transaktionssystems zugeordnet sind, um beispielsweise eine Mehrfach- Ausgabe des gleichen Tokens zu vermeiden oder die Echtheit des Tokens zu verifizieren.
Die Speichereinheit des Tokenreferenz-Registers speichert bevorzugt nur Tokenreferenzen von im Transaktions system tatsächlich vorhandenen Token. Sobald ein Token modifiziert wird und eine entsprechende (modifizierte) Tokenreferenz registriert werden soll, werden die (alten) Tokenreferenzen ungültig und (nur) die modifizierten Tokenreferenzen werden in der Speichereinheit gespeichert.
Das Endgerät kann also in der Direktbezahltransaktionsschicht einem anderen Endgerät elektronische Münzdatensätze übertragen ohne Verbindung zur Überwachungsinstanz, insbesondere wenn das Endgerät offline ist, also keine Kommunikationsverbindung zu der Überwachungsinstanz vorhanden ist.
Eine Teilnehmereinheit kann vorliegend ein sicheres Element sein, das einen gesicherten Zugriff auf Token in einem Tokenspeicher hat. Das sichere Element ist beispielsweise betriebsbereit in einem Endgerät eingebracht. Das sichere Element und oder das Endgerät haben ein spezielles Computerprogrammprodukt (elektronische Geldbörse, Wallet), insbesondere in Form einer abgesicherten Laufzeitumgebung innerhalb eines Betriebssystems eines Endgeräts, englisch Trusted Execution Environments, TEE, gespeichert auf einem Datenspeicher, beispielsweise eines mobilen Endgeräts, einer Maschine, vorzugsweise Bankautomat. Alternativ ist das sichere Element beispielsweise als spezielle Hardware, insbesondere in Form eines gesicherten Hardware-Plattform-Moduls, englisch Trusted Platform Module, TPM oder als ein eingebettetes Sicherheitsmodul, eUICC, eSIM, ausgebildet. Das sichere Element stellt eine vertrauenswürdige Umgebung bereit.
Die Kommunikation zwischen Endgerät und sicherem Element als Teilnehmereinheit kann mittels APDU erfolgen. Die Kommunikation zwischen Endgerät und Tokenreferenz-Register oder Herausgebereinheit kann mittels API-Aufrufen erfolgen. Das Endgerät ist dabei nur ein Protokollübersetzer und verändert die Registrieranfragen nicht.
Die Kommunikation zwischen zwei Teilnehmereinheiten zum Austauschen von Token kann drahtlos oder drahtgebunden, oder z.B. auch auf optischem Weg, bevorzugt über QR-Code oder Barcode, erfolgen und kann als ein gesicherter Kanal ausgebildet sein. Der Austausch von Token ist beispielsweise durch kryptografische Schlüssel zusätzlich transportgesichert, beispielsweise einem für einen Token-Austausch ausgehandelten Sitzungsschlüssel oder auf Basis eines teilnehmereinheitenindividuellen Schlüsselpaars.
Nachfolgend wird anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.
Fig. 1 zeigt ein Ausführungsbeispiel eines Transaktions systems gemäß der Erfindung;
Fig. 2 zeigt ein Ausführungsbeispiel eines Tokenreferenz-Registers gemäß der Erfindung; Fig. 3a zeigt eine Übersicht über erfindungsgemäße Kommandos für Token;
Fig. 3b zeigt eine Übersicht über erfindungsgemäße signierte Registrieranfragen für die erfindungsgemäßen Kommandos;
Fig. 4 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Erstellen und Registrieren eines Tokens und eine Übersicht über die Kommandodetails in Abhängigkeit der Transaktionsschicht;
Fig. 5 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Löschen eines Tokens und Registrieren;
Fig. 6 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Aufteilen und Registrieren eines Tokens und eine Übersicht über die Kommandodetails in Abhängigkeit der Transaktionsschicht;
Fig. 7 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Verbinden und Registrieren eines Tokens und eine Übersicht über die Kommandodetails in Abhängigkeit der Transaktionsschicht;
Fig. 8 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Umschalten und Registrieren eines Tokens und eine Übersicht über die Kommandodetails in Abhängigkeit der Transaktionsschicht; und
Fig. 9 zeigt ein weiteres Ausführungsbeispiel eines Tokenreferenz-Registers gemäß der Erfindung.
Fig. 1 zeigt ein Ausführungsbeispiel eines Transaktions systems TS gemäß der Erfindung. Das Transaktionssystem TS umfasst eine Registerschicht TRR-Schicht, in der ein Tokenreferenz- Register TRR angeordnet ist. Das TS umfasst zudem eine Direkttransaktionsschicht TE- Schicht, in der eine Vielzahl von Teilnehmereinheiten TE vorgesehen sein können, stellvertretend sind zwei Teilnehmereinheiten TE1, TE2 gezeigt.
Die Teilnehmereinheiten TE des Transaktionssystem TS sind eingerichtet, Token T direkt untereinander au szutau sehen. Im Fall von Fig. 1 sind die Token Bezahl-Token, die auch als digitale Münze bezeichnet werden. Jeder Token T wird von einem Tokenherausgeber TH generiert (in Fig. 1 nicht gezeigt, siehe Fig. 2). Jeder Token T kann von jeder Teilnehmereinheit TE aufgeteilt, verbunden oder umgeschaltet werden (siehe Figuren 6 bis 8) und kann von dem Tokenherausgeber TH generiert (Siehe Fig. 4) und auch gelöscht werden (siehe Fig. 5). Ein Tokenherausgeber TH ist beispielsweise eine Zentralbank.
Ein Token T wird durch einen Tokenwert v und eine Zufallszahl r als Tokenelemente eindeutig im Transaktions system TS repräsentiert. Der Tokenwert v kann in einem Wertebereich von 1 bis 231-1 angegeben werden. Die Zufallszahl r kann eine Zahl im Bereich von 0 bis 2256 -1, also die Ordnung einer elliptischen Kurve, beispielsweise secp256rl, sein.
Die Zufallszahl r ist dabei ein privater Teil eines tokenindividuellen Schlüsselpaars. Die Zufallszahl r ist im Transaktionssystem TS einmalig und geheim und darf nicht veröffentlicht oder wiederverwendet werden. Die Erzeugung der Zufallszahl r darf nichtvorhersehbar sein.
Beispielsweise ist der Tokenwert v ein 32 Bit großes Tokenelement vom Typ integer. Beispielsweise ist die Zufallszahl r ein 32 Byte großes Tokenelement vom Typ integer. Eine Teilnehmereinheit TE hat exklusiven Zugriff auf diesen Tokenspeicher oder umfasst diesen Tokenspeicher in einem Datenspeicher der Teilnehmereinheit TE.
Ein Token kann als ein TLV kodierter Datensatz in einem Tokenspeicher abgelegt sein und weist dann einen eindeutigen Tag und eine Längeninformation auf, beispielsweise in folgendem Format auf.
Ein Beispiel eines TLV-codierten Token in hexadezimaler Form ist nachfolgend dargestellt:
42 24 00 00 40 00 00 01 02 03 04 05 06 07 08 09 0A OB 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C ID IE 1F und wird wie folgt interpretiert:
“42” ist der Tag zur Identifizierung des TLV-kodierten Tokens T;
“24” zeigt die Länge an, hier also, dass es sich um einen 36 Byte großen Datensatz handelt;
“0000 4000” ist der Tokenwert (integer) v = 16384 und beträgt demnach € 163,84; “0001 02 03 04 05 06 07 08 09 ... ID IE IF” ist die Zufallszahl r als integer.
Für jeden Token T kann im Tokenreferenz-Register TRR eine Tokenreferenz TR gespeichert werden. Die Tokenreferenz TR umfasst den Tokenwert v des zugeordneten Tokens T und einen öffentlichen Teil R des tokenindividuellen Schlüsselpaars. Die Tokenreferenz TR des Tokens T kann jederzeit im Register TRR des Transaktions systems TS eingesehen werden. Damit ist der Tokenwert v eines Tokens T durch das Tokenreferenz-Register TRR offengelegt.
Der öffentliche Teil R des tokenindividuellen Schlüsselpaars wird durch Anwenden einer kryptografischen Funktion auf den privaten Teil r des tokenindividuellen Schlüsselpaars erzeugt. Diese Funktion ist schwer umkehrbar und gibt dem Transaktionssystem TS so die gebotene Sicherheit. Es gilt R = r * G, wobei G beispielsweise ein globaler Parameter des Transaktionssystems TS, bspw. ein Generatorpunkt einer elliptischen Kurve, hier der secp256rl-Kurve, sein kann.
Die Tokenreferenz TR wird dann gebildet durch den Tokenwert v des Tokens und den öffentlichen Teil R des Schlüsselpaars. Die Tokenreferenz TR ist somit die Verknüpfung oder Verkettung von Tokenwert v und öffentlichem Teil R.
Diese Tokenreferenz TR kann als Registrieranfrage RA ggf. zusammen mit einem Kommando (siehe Übersicht in Figuren 3a und 3b) bezüglich des Tokens T an das Tokenreferenz-Register TRR gesendet werden.
Zusätzlich kann die Registrieranfrage RA mit dem privaten Teil r des tokenindividuellen Schlüsselpaars signiert werden. Das Signieren ermöglicht es, zu verifizieren, ob der Sender der Tokenreferenz TR im Besitz des Tokens T war, wodurch die Sicherheit im Transaktionssystem TS weiter erhöht ist.
In der Teilnehmereinheit TE wird die signierte Registrieranfrage RAsig als ein sogenannter PROOF abgelegt, beispielsweise in folgendem Format:
Ein Beispiel eines PROOF (=RASig) in hexadezimaler Form ist nachfolgend dargestellt: 4A 81 8F 03 11 12 13 14 15 16 17 18 19 1A IB 1C ID IE IF 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 IB 1C ID IE IF 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 und wird wie folgt interpretiert (siehe auch Fig. 8 zur Struktur einer Umschalte- Registrieranfrage) :
“4A” ist der Tag zur Identifizierung des TLV-Proof RASig_Th;
“81 8F” zeigt die Länge an;
“03” zeig an, dass es sich um eine Umschalte (=SWITCH) Registrieranfrage handelt;
“11 12 13 14” ist der Tokenwert vg;
“15 16 17 18 19 1A 1B IC ID IE 1F 2021 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35” ist der öffentliche Teil Rg;
“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” ist der öffentliche Teil Rh;
“30 46 11 12 13 14 15 16 17 18 19 1A 1B IC ID IE 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“ ist die Signatur als X690-Sequenz.
Diese Registrieranfrage RA kann an das Tokenreferenz-Register TRR gesendet werden. Im Tokenreferenz-Register TRR wird diese Registrieranfrage RA empfangen. Nach Prüfung der Registrieranfrage RA durch das Tokenreferenz-Register TRR wird die Tokenreferenz TR im Tokenreferenz-Register TRR abgelegt, wodurch der Token T im Transaktionssystem TS registriert ist.
Diese Tokenreferenz TR ist dem Token T eindeutig zugeordnet und dient zur Registrierung des Tokens T im Transaktionssystem TS. Die Tokenreferenz TR ist demnach die öffentliche Repräsentation des Tokens T aus der Direkttransaktionsschicht TE-Schicht. Das alleinige Wissen oder nur der Besitz der Tokenreferenz TR erlaubt es nicht, den Token T zu übertragen und ist nicht gleichbedeutend damit, dass die TE im Besitz des Tokens T ist. Die Tokenreferenz TR dient zur Verhinderung von Mehrfachausgabe-Versuchen und prüft, ob Tokenwerte v in unzulässiger Weise generiert wurden. Deshalb wird im Tokenreferenz-Register TRR die Tokenreferenz TR und ggf. die Historie über die Token T und die entsprechenden Registrieranfragen RA von Teilnehmereinheiten TE abgelegt.
Die Token T werden beispielsweise in elektronischen Geldbörsen, sogenannten Wallets, einer TE abgelegt. Diese Wallets sind beispielsweise Softwareapplikationen innerhalb der Teilnehmereinheiten TE oder eines Endgeräts, in dem die TE betriebsbereit eingebracht ist. Ein Wallet kann als Applikation auf einem Smartphone, einer Smartcard oder einem Bezahlterminal eingerichtet sein. Das Wallet dient dazu, Token T der TE sicher zu verwalten, Tokenreferenzen TR zu erzeugen, Token T zu modifizieren und/oder Token T auszutauschen. Wallets dienen dazu, mit dem Tokenreferenz-Register TRR zu kommunizieren, Registrieranfragen RA an das Tokenreferenz-Register TRR zu generieren und/oder Transaktion von Token T zu einer Teilnehmereinheit TE vorzunehmen.
Für eine Transaktion mit einer Teilnehmereinheit TE ist es nicht notwendig, dass eine Kommunikationsverbindung zu dem Tokenreferenz-Register TRR des Transaktions systems TS besteht. Das Transaktionssystem TS ist dazu eingerichtet, eine Transaktion offline, also ohne Kommunikationsverbindung mit dem Tokenreferenz-Register TRR, durchzuführen. Eine entsprechende Registrierung von Token T kann daher einer Übertragung des Token T zu einer Teilnehmereinheit TE zeitlich nachgelagert sein.
Das Tokenreferenz-Register TRR ist eine Einheit des Transaktionssystems TS und ist entweder ein zentrales Register oder eine zentrale Datenbank des Transaktionssystems TS oder ein dezentrales Register oder eine dezentrale Datenbank (DLT) des Transaktionssystems TS.
Das Übertragen einer Tokenreferenz TR von einem sicheren Element als Teilnehmereinheit, auf welchem eine elektronische Geldbörse vorliegt, erfolgt beispielsweise als APDU Kommando(s) zu einem Endgerät (Smartphone) des Teilnehmers, welche vorzugsweise das sichere Element umfasst. Ein APDU ist ein kombinierter Kommando-/Datenblock eines Verbindungsprotokolls zwischen dem sicheren Element und dem Endgerät. Die Struktur der APDU ist durch den Standard ISO-7816-4 definiert. Das Endgerät entpackt APDU Kommando(s) und überträgt die Daten in API-Aufrufen an das Tokenreferenz-Register TRR, wo sie in HTTP-Codes umgesetzt werden.
In Fig. 2 ist ein Ausführungsbeispiel eines Tokenreferenz-Register TRR der Erfindung dargestellt. Das Tokenreferenz-Register TRR verwaltet insbesondere den Speicherort für die Tokenreferenzen TR, hier als Datenbank 1 als Beispiel einer Speichereinheit im Tokenreferenz-Register TRR dargestellt. Stellvertretend ist in der Datenbank 1 das TR zum Token T der Teilnehmereinheit TE1 eingetragen. Diese Datenbank 1 kann aus einem Zusammenschluss vieler Datenbanken bestehen (siehe auch Fig. 9), die untereinander vernetzt sind. Zum einfachen Auffinden einer Tokenreferenz TR, ist der öffentliche Teil R der Tokenreferenz TR gleichzeitig ein Datenbankenindex in der Datenbank 1, denn sowohl ein Index einer Datenbank als auch ein öffentlicher Teil R einer Tokenreferenz TR müssen im Transaktionssystem TS eineindeutig sein.
Zudem wird das Tokenreferenz-Register TRR zumindest eine Verifiziereinheit 2 umfassen. Die Verifiziereinheit 2 des Tokenreferenz-Registers TRR verifiziert Registrieranfragen RA. Dabei kann eine syntaktische Korrektheit oder auch die korrekte Angabe eines Kommandos in der Registrieranfrage RA verifiziert werden. Auch eine Historie aus alten (vergangenen) Registrieranfragen RA bezüglich eines Tokens T kann dabei verifiziert werden. Die Trennung dieser Verifiziereinheit 2 von der Datenbank 1 verteilt die Aufgaben von Ablegen und Verifzieren (bzw. Prüfen) und erhöht die Geschwindigkeit im Tokenreferenz-Register TRR.
Zudem kann das Tokenreferenz-Register TRR eine optionale Prüfeinheit 3 umfassen, welche die Registrieranfrage RA prüft, insbesondere bevor die Verifiziereinheit 2 mit Hilfe der Inhalte der Datenbank 1 verifiziert. Die Prüfeinheit 3 prüft die Registrieranfrage selbst, also nur dessen Inhalte. Geprüft wird beispielsweise die syntaktische Korrektheit, Summe der Tokenwerte in der Registrieranfrage (ergibt Null), Kommandotyp und/oder eine Signatur der Registrieranfrage.
Sie könnte darüber hinaus optional eine Prüfung eines Gesamt-Tokenwert S im Transaktionssystem TS für die Registrieranfrage anfordem. Eine Gesamt-Tokenwert- Prüfeinheit (5 in Fig. 9) kann prüfen, ob die aktuelle Gesamtsumme der Tokenwerte von Tokenreferenzen registrierter Token im Tokenreferenz-Register TRR dem Gesamt-Token-Wert entspricht. Durch die Registrieranfrage von (normalen) Teilnehmereinheiten TE1 darf sich der Gesamt-Tokenwert der registrierten Token nicht ändern. Wäre dies der Fall, dann würde ein neuer Tokenwert v geschaffen oder ein existierender Tokenwert v vernichtet. Dies dürfen nur privilegierte Einheiten, wie vorliegend eine Herausgeberinstanz TH, im Transaktionssystem TS. Wenn ein derartiges Verändern der Gesamtsumme der Tokenwerte durch eine Tokenreferenz TR einer Teilnehmereinheit TE erkannt wird, dann kann von einem Betrugsoder Fehlerfall ausgegangen werden. Somit kann eine illegale Generierung von Tokenwerten v sehr leicht entdeckt und verhindert werden. Die Prüfung des Gesamt-Tokenwerts stellt ein weiteres Sicherheitskonzept im Transaktionssystem TS dar.
Zudem kann das Tokenreferenz-Register TRR eine Neuregistriereinheit 4 umfassen, in die neu generierte Tokenreferenzen TR eines Tokenherausgebers TH erst-registriert werden oder zu löschende Tokenreferenzen TR ent-registriert werden. Damit wird eine Funktionstrennung zwischen Tokenreferenzen TR von privilegierten Teilnehmern, wie einem Tokenherausgeber TH, von Tokenreferenzen TR von unprivilegierten Teilnehmern, wie den Teilnehmereinheiten TE, erreicht. Die Tokenwerte v von neu generierte Tokenreferenzen TR oder zu löschenden Tokenreferenzen TR haben direkten Einfluss auf eine Änderung des Gesamt-Tokenwerts, der in der Gesamt-Tokenwert-Prüfeinheit überwacht wird.
Eine Registrieranfrage RA ist bevorzugt mit dem privaten Teil r signiert. Durch die Signatur kann eine syntaktische Echtheit des Kommandos durch den Empfänger (TRR oder TE) einfach geprüft werden. Diese Prüfung erfolgt bevorzugt in der Prüfeinheit 3 oder der Verifziereinheit 2. Zudem kann eine Registeranfrage RA beispielsweise syntaktisch validiert werden durch Prüfen der Signatur und/oder der Tokenreferenz TR.
Auch wenn eine Signatur in einer Teilnehmereinheit TE geprüft werden kann, so wird damit nicht sichergestellt, dass keine Mehrfachausgabe des gleichen Tokens T versucht wurde. Daher ist das Registrieren im Tokenreferenz-Register TRR vorgesehen. Zudem wird durch die Teilnehmereinheiten TE eine sichere Hardwareplattform vorgehalten. Mit verfügbarer Verbindung zum Tokenreferenz-Register TRR werden die Tokenreferenzen TR übertragen und im Tokenreferenz-Register TRR kann der Mehrfachausgabe-Versuch entdeckt werden.
Wenn eine Tokenreferenz TR im Tokenreferenz-Register TRR noch nicht bekannt ist, wird sie hinzugefügt.
In Fig. 3a ist eine Übersicht von Kommandos CO gezeigt, die an einem Token T vorgenommen werden können. Die Kommandos CO können Modifikationen an einem vorhandenen Token T sein, beispielsweise „Umschalten (=S witch)“, „Aufteilen (=Split)“ oder „Verbinden (=Merge)“. Die Kommandos CO können auch das Erzeugen (=Create) eines Tokens T oder das Löschen (Destroy) vorhandenen Token T betreffen. In Fig. 3a sind beispielhaft Kommandocodierungen angegeben (0x01 bis 0x05), die sodann Teil einer Registrieranfrage RA sein können. In Fig. 3b ist eine Übersicht von Kommandos CO und deren signierte Registrieranfrage- Syntax RA gezeigt. Dabei werden pro Kommando CO Eingangs-Token T und Eingangs- Tokenreferenzen TR „verbraucht“. Dabei werden pro Kommando CO Ausgangs-Token T Ausgangs-Tokenreferenzen TR „generiert“.
Ein Kommando CO hat die grundlegende Struktur aus den folgenden drei Elementen: Kommandotyp, Eingangs-Tokenreferenz(en), Ausgangs-Tokenreferenz(en).
Jedes Kommando hat eine charakteristische Anzahl von Eingangs-Tokenreferenz(en) („Eingänge“) und Ausgangs-Tokenreferenz(en) („Ausgänge“), die in den Figuren 4 bis 8 näher erläutert und dargestellt sind.
Zu beachten ist, dass für die Kommandos CO „Aufteilen“, „Umschalten“ und „Verbinden“ die Differenz der Tokenwerte v aller beteiligten Token T bzw. Tokenreferenzen TR den Betrag „null“ ergeben muss. Mit anderen Worten, diese Kommandos CO „Aufteilen“, „Umschalten“ und „Verbinden“ erzeugen keine Tokenwerte v und vernichten keine Tokenwerte v. Dies kann am Kommandotyp CO selbst erkannt oder auch von der Prüfeinheit 3 des Tokenreferenz- Register TRR nachgeprüft werden und ist ein Prüfkriterium für eine Registeranfrage RA.
Zu beachten ist auch, dass nur für die Kommandos CO „Erzeugen“ und „Löschen“ eine Differenz der Tokenwerte v des beteiligten Tokens T bzw. Tokenreferenzen TR erlaubt ist, aber nur in Höhe des Tokenwerts v des Tokens T und nicht darüber hinaus.
Jede Registrieranfrage kann signiert werden, um prüfen zu können, dass der Sender der Tokenreferenz TR auch im Besitz des dazugehörigen Tokens T ist. Als Signatur kann ein ECDSA-Schema angewendet werden. Die Registrieranfrage RA wird bevorzugt mit dem privaten Teil r des Tokens T signiert.
Für signierte Registrieranfragen der Kommandotypen CO „Erzeugen“ und „Löschen“ wird eine weitere Signatur eines Tokenherausgebers TH verlangt, um sicherzustellen, dass diese Kommandos von einer privilegierten Einheit des Transaktionssystems TS generiert worden sind.
In Fig. 4 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Erstellen eines Tokens T und das Registrieren im TRR gezeigt. Zudem ist die signierte Registrieranfrage RASig und die Kommandostruktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt. Beim Erstellen gibt es keinen Eingangsparameter in der TE-Schicht. In einer privilegierten Einheit, hier dem Tokenherausgeber TH, wird eine Zufallszahl r generiert. Auf Basis von der Zufallszahl r wird ein öffentlicher Teil R errechnet, wie es oben beschrieben wurde. Somit kann im Tokenherausgeber TH eine Tokenreferenz TR ausgehend vom Tokenwert v und dem öffentlichen Teil R durch Konkatenation von v und R gebildet werden.
Eine Registrieranfrage RA bestehend aus dem Kommando „CREATE“ bzw. dem Kommandocode gemäß Fig. 3 a und der erzeugten Tokenreferenz TR wird im Tokenherausgeber TH signiert. Dazu wird der private Schlüssel pKey des Tokenherausgebers TH verwendet.
In der TE-Schicht wird der Token T an die TE1 ausgegeben. In der TRR-Schicht wird die signierte Registrierungsanfrage RASig an das TRR ausgegeben.
Im Tokenreferenz-Register TRR wird die Signatur der Registrieranfrage RA mit dem öffentlichen Schlüssel PKey der Herausgeberinstanz TH geprüft. Dieser öffentliche Schlüssel PKeyTH ist transaktionssystemweit bekannt oder wurde dem Tokenreferenz-Register TRR im Vorfeld zur Verfügung gestellt. Ist die Signaturprüfung erfolgreich, dann wird die Tokenreferenz TR in das Tokenreferenz-Register TRR eingetragen.
In einer Ausgestaltung wird durch die Neuregistriereinheit 4 des Tokenreferenz-Register TRR der Gesamt-Tokenwert des Transaktionssystems TS, insbesondere in einer Gesamt-Tokenwert- Prüfeinheit des Tokenreferenz-Register TRR, um den Tokenwert v erhöht.
In Fig. 5 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Löschen eines Tokens T und Registrieren des gelöschten T im TRR gezeigt. Zudem sind die dazu benötigten signierten Registrieranfrage RASig TH und RASig T sowie die Kommando Struktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
Beim Löschen wird als Eingangsparameter in der TE-Schicht der zu löschende Token T verwendet und in der TRR-Schicht die zu löschende Tokenreferenz TRR und zwei signierte Registrieranfrage RASig TH und RASig T verwendet. Die Registrieranfrage RA bestehend aus dem Kommando „DESTROY“ und der zu löschenden Tokenreferenz TR wird einmal mit dem privaten Schlüssel pKey des Tokenherausgebers TH signiert.
Eine weitere Registrieranfrage RA bestehend aus dem Kommando „DESTROY“ und der zu löschenden Tokenreferenz TR wird zudem mit dem privaten Teil r des Tokens T signiert.
Beide signierte Registrieranfragen werden an das Tokenreferenz-Register TRR versendet. Im Tokenreferenz-Register TRR wird die Signatur mit dem öffentlichen Schlüssel der Herausgeberinstanz TH geprüft. Dieser öffentliche Schlüssel ist transaktionssystemweit bekannt oder wurde dem Tokenreferenz-Register TRR im Vorfeld zur Verfügung gestellt. Zudem wird die Signatur der weiteren Registrieranfrage RA mit dem öffentlichen Teil der Tokenreferenz TR geprüft. Sind beide Signaturprüfungen erfolgreich, dann wird die Tokenreferenz TR in dem TRR gelöscht oder als gelöscht markiert.
In einer Ausgestaltung wird der Gesamt-Tokenwert des Transaktionssystems TS in einer Gesamt-Tokenwert-Prüfeinheit des Tokenreferenz-Register TRR um den Tokenwert v durch die Neuregistriereinheit 4 des Tokenreferenz-Register TRR verringert.
Das Tokenreferenz-Register TRR oder der Tokenherausgeber TH veranlassen zudem das Löschen des Tokens T in der Teilnehmereinheit TEL
In Fig. 6 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Aufteilen eines Tokens Ta und Registrieren der aufgeteilten Token Tb Tc im Tokenreferenz-Register TRR gezeigt. Zudem ist die dazu benötigte signierte Registrieranfrage RAsig Ta sowie die Kommando Struktur sowohl aus Sicht der TE-Schicht als auch der TR- Schicht tabellarisch dargestellt.
In der TE-Schicht wird durch die TE1 eine erste Zufallszahl , und eine zweite Zufallszahl rc erzeugt. Basierend darauf wird dann jeweils ein öffentlicher Teil Rb und Rc erzeugt. Als Eingangsparameter steht in der TE-Schicht der aufzuteilende Token Ta zur Verfügung. Es erfolgt in der TE-Schicht eine Aufteilung des Tokenwerts va in einen ersten Tokenteilwert Vb und einen zweiten Tokenteilwert vc. Die Summe aus Tokenteilwert Vb und Tokenteilwert vc muss den Tokenwert va ergeben. Damit wird sichergestellt, dass kein neuer Tokenwert v erzeugt wird oder ein Tokenwert v vernichtet wird.
Sodann werden von der TE1 die Tokenreferenzen TRb und TRC erzeugt. Die Registrieranfrage RA enthält sodann das Kommando „SPLIT“ bzw. den dafür in Fig. 3a gezeigten Kommandocode, die Eingangs-Tokenreferenz TRa und die Ausgangs-Tokenreferenzen TRb und TRC. Diese Registrieranfrage RA wird mit der Zufallszahl ra des Tokens Ta signiert. Die signierte Registrieranfrage RASig ra wird vom TE1 an das Tokenreferenz-Register TRR gesendet. Dort wird die Signatur geprüft und die Summe von Vb und vc gebildet und mit dem Tokenwert va verglichen. Wenn va = Vb + vc gilt und die Signaturprüfung erfolgreich ist, dann wird die Tokenreferenz TRa in dem Tokenreferenz-Register TRR gelöscht oder als gelöscht markiert und die Tokenreferenzen TRb und TRC in das Tokenreferenz-Register TRR eingetragen.
In einer Ausgestaltung wird im Tokenreferenz-Register TRR in (der Verifiziereinheit 2 oder) der Prüfeinheit 3 die Tokenwertedifferenz der Eingangs-Tokenreferenz TRa und der Ausgangs- Tokenreferenzen TRb und TRc gebildet und geprüft, diese Differenz null ist. Ist die Differenz nicht null, so wurde in unerlaubter Weise ein Tokenwert v generiert oder vernichtet.
Zudem könnte theoretisch auch der Gesamt-Tokenwert des Transaktionssystems TS von der Prüfeinheit 3 des Tokenreferenz-Register TRR (mittels der Gesamt-Tokenwert-Püfeinheit 5) vor oder nach der Registrierung der Tokenreferenzen TRb und TRC geprüft werden. Der Gesamt-Tokenwert v in der Gesamt-Tokenwert Prüfeinheit 5 darf sich nicht verändert haben und muss dem Wert vor der Verarbeitung der Registrieranfrage im Tokenreferenz-Register TRR entsprechen.
Der aufgeteilte Token Tb (oder Tc) (der zwischenzeitlich von TE1 an TE2 übertragen wurde) kann nun von der Teilnehmereinheit TE2 im TRR auf Gültigkeit geprüft werden.
In Fig. 7 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Verbinden eines Tokens Td mit einem Token Te und Registrieren des verbundenen Tokens Tf im TRR gezeigt. Zudem sind die dazu benötigten signierten Registrieranfragen RASig rd und RASig Te sowie die Kommando Struktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
Dabei wird in einer TE1 der TE-Schicht eine Zufallszahl rf erzeugt. Basierend darauf wird dann ein öffentlicher Teil Rf erzeugt. Zudem erfolgt das Bilden einer Summe aus den Tokenwerten Vd und ve zum Tokenwert Vf basierend auf den Eingangs-Token Td und Te.
Sodann wird die Ausgangs-Tokenreferenz TRf erzeugt. Eine Registrieranfrage RA enthält sodann das Kommando „MERGE“ bzw. den in Fig. 3a gelisteten Kommandocode, die zwei Eingangs-Tokenreferenzen TRd und TRe sowie die Ausgangs-Tokenreferenz TRf. Diese Registrieranfrage RA wird einmal mit der Zufallszahl rd des Tokens Td signiert, um eine erste signierte Registrieranfrage RASig_Td zu erhalten. Diese Registrieranfrage wird zudem mit der Zufallszahl re des Tokens Te signiert, um eine zweite signierte Registrieranfrage RASig_Te zu erhalten. Beide signierte Registrieranfragen RASig rd und RASig Te werden von der Teilnehmereinheit TE1 an das Tokenreferenz-Register TRR gesendet. Dort werden jeweils die Signaturen der Registrieranfragen RASig_Td und RASig Te geprüft.. Zudem wird die Summe von den Tokenwerten Vd und ve gebildet und mit dem Tokenwert Vf verglichen. Wenn Vf = Vd + ve gilt und beide Signaturprüfungen erfolgreich sind, dann werden TRd und TRe in dem Tokenreferenz-Register TRR gelöscht oder als gelöscht markiert und die Tokenreferenz TRf in das Tokenreferenz-Register TRR eingetragen. Der verbundene Token Tf (der zwischenzeitlich von TE1 an TE2 übertragen wurde) kann nun von der Teilnehmereinheit TE2 im TRR auf Gültigkeit geprüft werden.
In Fig. 8 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Umschalten eines Tokens Tg auf einen Token Th und Registrieren des umgeschalteten Tokens Th im Tokenreferenz-Register TRR gezeigt. Zudem ist die dazu benötigte signierte Registrieranfragen RASig_rg sowie die Kommandostruktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
Dabei wird in einer TE1 eine Zufallszahl rh erzeugt. Basierend darauf wird dann ein öffentlicher Teil Rh erzeugt. Zudem wird der zum Tokenwert vg des Eingangs-Token Tg identische Tokenwert Vh gebildet.
Sodann wird die Tokenreferenz TRh erzeugt. Eine Registrieranfrage RA enthält sodann das Kommando „SWITCH“ oder einen entsprechenden Kommandocode gemäß Fig. 3a, die Eingangs -Tokenreferenz TRg und den gebildeten öffentlichen Teil Rh (bzw. die Ausgangs- Tokenreferenz TRh). Diese Registrieranfrage RA wird mit der Zufallszahl rg des Tokens Tg signiert. Die signierte Registrieranfrage RASig rg wird von der Teilnehmereinheit TE1 an das Tokenreferenz-Register TRR gesendet. Dort wird die Signatur geprüft. Zudem wird der Tokenwert vg mit dem Tokenwert Vh verglichen. Wenn vg = Vh gilt und die Signaturprüfung erfolgreich ist, dann wird die Tokenreferenz TRg in dem Tokenreferenz-Register TRR gelöscht oder als gelöscht markiert und die Tokenreferenz TRh in das Tokenreferenz-Register TRR eingetragen.
In Fig. 9 ist eine weitere Ausgestaltung eines Tokenreferenz-Registers TRR eines Transaktionssystems TS gezeigt. In Fig. 9 ist angedeutet, dass mehrere Speichereinheiten 1 im Tokenreferenz-Register TRR vorgehalten sein können, um ein Abspeichern einer Vielzahl von Tokenreferenzen TR zu beschleunigen. Hierbei ist zudem angedeutet, dass mehrere Verifizier- Einheiten 2 und/oder Prüfeinheiten 3 im Tokenreferenz-Register TRR vorgehalten sein können, um eine Verifizierung von Registrieranfragen RA zu beschleunigen.
Registrieranfragen von sicheren Elementen oder anderen Teilnehmereinheiten werden in einer der Verifizier-Einheiten 2 und optional zuvor in einer (der) optionalen Prüfeinheit(en) 3 bearbeitet. Registrieranfragen des Tokenherausgebers (TH) werden optional vor dem Verifizieren (und/oder Prüfen) von der Neuregistriereinheit 4 bearbeitet.
Die optionale Gesamt-Tokenwert- Prüfeinheit 5 prüft - beispielsweise in einem vorgegebenen oder zufällig variierenden zeitlichen Abstand (x,y), wie alle x Stunden oder y Tage, oder auf Anfrage der Prüfeinheit 3, ob die Gesamtsumme der Tokenwerte von gültigen Token im Token-Referenz-Register TRR dem Gesamt-Token-Wert entspricht.
Zudem ist eine Teilnehmereinheit TEB dargestellt, die als Schnittstelle zwischen dem Transaktionssystem TS und einem Buchgeldsystem (Kreditvergabe, Kontenmanagement) funktioniert und es Teilnehmereinheiten TE beispielsweise ermöglicht, Token T des Transaktionssystems TS in ein anderes Transaktionssystem zu überführen. Diese Überführung ist bidirektional und kann unter Verwendung des Tokenherausgebers TH erfolgen, der für die Neugenerierung von Token T und auch das Löschen von Token T allein verantwortlich ist.
BEZUGSZEICHENLISTE
CO Kommando
PKey H öffentlicher Teil des Tokenherausgeber-Schlüsselpaars pKey H privater Teil des Tokenherausgeber-Schlüsselpaars
R öffentlicher Teil des tokenindividuellen Schlüsselpaars r privater Teil des tokenindividuellen Schlüsselpaars RA Registrierungsanfrage
RAsig T Registrierungsanfrage signiert mit privatem Teil des tokenindividuellen Schlüsselpaars
RAsig TH Registrierungsanfrage signiert mit privatem Teil des Tokenherausgeber- Schlüsselpaars
T Token
TE Teilnehmereinheit
TEB Teilnehmereinheit Bank
TE-Schicht Direkttransaktionsschicht
TRR-Schicht Registerschicht
TH Tokenherausgeber
TR Tokenreferenz
TRR Tokenreferenz-Register
1 Datenbank, Speichereinheit
2 Verifiziereinheit
3 Prüfeinheit
4 Neuregistriereinheit
5 Gesamtsummen-Prüfeinheit
TS Transaktionssystem
TW Tokenwert a-h Indizes für verschiedene Token und Tokenreferenzen
S Gesamt-Tokenwert des Transaktionssystems

Claims

Patentansprüche
1. Ein Verfahren zum Registrieren von Token (T) eines elektronischen Transaktions systems (TS), wobei jeder Token (T) des Transaktionssystems (TS) zumindest einen Tokenwert (v) und einen privaten Teil (r) eines tokenindividuellen Schlüsselpaars als Token-Elemente aufweist, mit den Verfahrensschritten:
- Empfangen, in einem Tokenreferenz-Register (TRR) des Transaktionssystems (TS), einer
Registrieranfrage (RA) aufweisend zumindest eine einem Token (T) des
Transaktionssystems (TS) eindeutig zugeordnete Tokenreferenz (TR), wobei die Tokenreferenz (TR) zumindest den Tokenwert (v) des Tokens (T) und einen öffentlichen Teil (R) des tokenindividuellen Schlüsselpaars als Tokenreferenz-Elemente aufweist, wobei der öffentliche Teil (R) des tokenindividuellen Schlüsselpaars durch Anwenden einer kryptografischen Einwegfunktion auf den privaten Teil (r) des tokenindividuellen Schlüsselpaars des Tokens (T) erhalten wurde,
- Verifizieren, durch eine Verifiziereinheit (2) des Tokenreferenz-Registers (TRR), ob die zumindest eine Tokenreferenz (TR) der empfangenen Registrieranfrage (RA) in dem Tokenreferenz-Register (TRR) gespeichert ist, und
- Speichern der zumindest einen Tokenreferenz (TR) in einer Speichereinheit (1) des Tokenreferenz-Registers (TRR) zum Registrieren des dieser Tokenreferenz (TR) eindeutig zugeordneten Tokens (T) im Transaktionssystem (TS), wenn im Verifizieren- Schritt festgestellt wird, dass die zumindest eine Tokenreferenz (TR) der empfangenen Registeranfrage (RA) nicht im Tokenreferenz-Register (TRR) gespeichert ist.
2. Das Verfahren nach Anspruch 1, wobei im Verifizieren- Schritt durch die Verifiziereinheit (2) des Tokenreferenz-Registers (2) zudem festgestellt wird:
- ob die Tokenreferenz in der empfangenen Registrieranfrage einem Token zugeordnet werden kann; und/oder
- ob die empfangene Registrieranfrage (RA) syntaktisch korrekt ist; und/oder;
- ob eine Summe von Tokenwerten (v) aller Tokenreferenzen (TR) innerhalb der Registrieranfrage (RA) null ist.
3. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei der öffentliche Schlüsselteil (R) des tokenindividuellen Schlüsselpaars der Tokenreferenz (TR) zugleich ein Datenbankindex im Tokenreferenz-Register (TRR) ist.
4. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei die empfangene Registrieranfrage (RA) mit dem privaten Teil (r) des tokenindividuellen Schlüsselpaars signiert ist, um eine Zuordnung von der Tokenreferenz (TR) zu dem Token (T) verifizieren zu können.
5. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei die Registrieranfrage (RA) von einer Teilnehmereinheit (TE), insbesondere einem sicheren
Element, empfangen wird; und/oder die Registrieranfrage (RA) eine Modifikation zumindest eines zuvor registrierten Tokens betrifft und bevorzugt zumindest die Tokenreferenz (TRg) des zumindest einen zuvor registrierten Tokens (Tg) sowie die zumindest eine Tokenreferenz (TRh) des zu registrierenden Tokens (Th), welcher die Modifikation des zuvor registrierten Tokens ist, aufweist.
6. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei das Tokenreferenz- Register (TRR) zudem aufweist: die oder mehrere Speichereinheiten (1) zum Abspeichern von Tokenreferenzen (TR) zum Registrieren der Token (T) im Transaktionssystem (TS); und/oder die oder mehrere Verifiziereinheiten (2) zum Verifizieren empfangener Registrieranfragen (RA); und/oder eine oder mehrere Prüfeinheiten (3) zum Prüfen der empfangenen Registrieranfrage (RA), insbesondere auf syntaktische Korrektheit und/oder Summe der Tokenwerte in der Registrieranfrage, vor dem Verifzieren; und/oder eine Prüfeinheit (5) zum Prüfen eines Gesamt-Tokenwerts aller Tokenwerte (v) registrierter Token des Transaktionssystems (TS); und/oder eine Neuregistriereinheit (4) zum Registrieren von neuen Token (T) oder von gelöschten Token (T) durch einen Tokenherausgeber (TH).
7. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tokenreferenz (TR) zumindest eines der weiteren Tokenreferenz-Elemente aufweist: einen Zählwert, eine Identität einer Teilnehmereinheit oder eines Besitzers der Teilnehmereinheit, und/oder ein Pseudonym einer Teilnehmereinheit oder eines Besitzers der Teilnehmereinheit.
8. Das Verfahren nach Anspruch 5 bis 7, wobei die Registrieranfrage (RA) eine Aufteilung eines Tokens (Ta) betrifft und bevorzugt weist die Registrieranfrage (RA) eine Tokenreferenz (TRa) des aufzuteilenden Tokens (Ta) und jeweils eine Tokenreferenz (TRb, TRC) der aufgeteilten, zu registrierenden Token (Tb, Tc) auf.
9. Das Verfahren nach Anspruch 8, wobei zum Aufteilen des Tokens (Ta) in einer Teilnehmereinheit (TE) die folgenden Verfahrensschritte durchgeführt werden:
Erzeugen eines neuen privaten Teils (m) eines tokenindividuellen Schlüsselpaars für einen ersten aufgeteilten Token (Tb),
Anwenden einer kryptografischen Funktion auf den neuen privaten Teil (m) zum Erhalten eines entsprechenden öffentlichen Teils (Rb) des tokenindividuellen Schlüsselpaars für den ersten aufgeteilten Token (Tb);
Erzeugen eines neuen privaten Teils (rc) eines tokenindividuellen Schlüsselpaars für einen zweiten aufgeteilten Token (Tc);
Anwenden einer kryptografischen Funktion auf den neuen privaten Teil (rc) zum Erhalten eines entsprechenden öffentlichen Teils (Rc) des tokenindividuellen Schlüsselpaars für den zweiten aufgeteilten Token (Tc);
Aufteilen des Tokenwerts (va) in einen ersten Tokenteilwert (vb) und in einen zweiten Tokenteilwert (vc), wobei die Summe aus dem ersten Tokenteilwert (vb) und dem zweiten Tokenteilwert (vc) dem Tokenwert (va) des aufzuteilenden Tokens (Ta) entspricht;
Erzeugen einer Tokenreferenz (TRb) für den ersten aufgeteilten Token (Tb) aufweisend den ersten Tokenteilwert (vb) und den öffentlichen Teil (Rb) des tokenindividuellen Schlüsselpaars des ersten aufgeteilten Tokens (Tb);
Erzeugen einer Tokenreferenz (TRC) für den zweiten aufgeteilten Token (Tc) aufweisend den zweiten Tokenteilwert (vc) und den öffentlichen Teil (Rc) des tokenindividuellen Schlüsselpaars des zweiten aufgeteilten Tokens (Tc); und
Erstellen der Registrieranfrage (RA) unter Verwendung der Tokenreferenz (TRa) des aufzuteilenden Tokens (Ta), der Tokenreferenz (TRb) für den ersten aufgeteilten Token (Tb) und der Tokenreferenz (TRC) für den zweiten aufgeteilten Token (Tc).
10. Das Verfahren nach Anspruch 5 bis 7, wobei die Registrieranfrage (RA) eine Umschaltung eines umzuschaltenden Tokens (Tg) auf einen umgeschalteten Token (Th) betrifft und bevorzugt weist die Registrieranfrage (RA) eine Tokenreferenz (TRg) des umzu schaltenden Tokens (Tg) sowie die Tokenreferenz (TRh) des umgeschalteten Tokens (Th) auf.
11. Das Verfahren nach Anspruch 10, wobei zum Umschalten des Tokens (Tg) in einer Teilnehmereinheit (TE) die folgenden Verfahrensschritte durchgeführt werden:
Erzeugen eines neuen privaten Teils (rh) eines tokenindividuellen Schlüsselpaars,
Anwenden einer kryptografischen Funktion auf den neuen privaten Teil (rh) zum Erhalten eines öffentlichen Teils (Rh) des tokenindividuellen Schlüsselpaars für den umgeschalteten Token (Th); Erstellen der Registrieranfrage (RA) unter Verwendung der Tokenreferenz (TRg) für den umzu schaltenden Token (Tg) und den öffentlichen Teil (Rh) des tokenindividuellen Schlüsselpaars für den umgeschalteten Token (Th).
12. Das Verfahren nach Anspruch 5 bis 7, wobei die Registrieranfrage (RA) ein Verbinden von zumindest zwei Token (Td, Te) betrifft und bevorzugt eine Tokenreferenz (TRf) des verbundenen Tokens (Tf) und jeweils eine Tokenreferenz (TRd, TRe) der zu verbindenden Token (Td, Te) aufweist.
13. Das Verfahren nach Anspruch 12, wobei zum Verbinden des Tokens (Tf) in einer Teilnehmereinheit (TE) die folgenden Verfahrensschritte durchgeführt werden:
Erzeugen eines neuen privaten Teils (rf) eines tokenindividuellen Schlüsselpaars,
Anwenden einer kryptografischen Funktion auf den neuen privaten Teil (rf) zum Erhalten eines entsprechenden öffentlichen Teils (Rf) des tokenindividuellen Schlüsselpaars für den verbundenen Token (Tf);
Berechnen des Tokenwerts (vf) für den verbundenen Token (Tf) durch Bilden der Summe aus den jeweiligen Tokenwerten (vd, ve) der zu verbindenden Token (Td, Te);
Erzeugen einer Tokenreferenz (TRf) für den verbundenen Token (Tf) aufweisend den berechneten Tokenwert (vf) und den öffentlichen Teil (Rf) des tokenindividuellen Schlüsselpaars für den verbundenen Token (Tf); und
Erstellen der Registrieranfrage (RA) unter Verwendung jeder Tokenreferenz (TRd, TRe) der zu verbindenen Token (Td, Te) und der Tokenreferenz (TRf) für den verbundenen Token (Tf).
14. Das Verfahren nach einem der vorhergehenden Ansprüche 1 bis 4 oder 6, wobei die Registrieranfrage (RA) von einem Tokenherausgeber (TH) versendet wurde und wobei die Registrieranfrage (RA) ein Erstellen eines Tokens (T) oder ein Löschen eines Tokens (T) betrifft.
15. Ein Tokenreferenz-Register (TRR) für ein Transaktionssystem (TS), eingerichtet zum Durchführen der Verfahrensschritte nach einem der vorhergehenden Ansprüche.
16. Das Tokenreferenz-Register (TRR) nach Anspruch 15, aufweisend: zumindest eine Speichereinheit (1) zum Speichern von Tokenreferenzen (TR) zum Registrieren von Token (T) im Transaktionssystem (TS); zumindest eine Verifiziereinheit (2) zum Verifizieren, ob eine Tokenreferenz (TR) einer empfangenen Registrieranfrage (RA) in dem Tokenreferenz-Register (TRR) gespeichert ist, eine Neuregistriereinheit (4) zum Registrieren von von einem Tokenherausgeber (TH) neu generierten Token (T) oder von von einem Tokenherausgeber (TH) gelöschten Token (T), optional eine Prüfeinheit (3) zum Prüfen der empfangenen Registrieranfrage (RA) vor dem Verifzieren durch die Verifiziereinheit (2), und optional eine Prüfeinheit (5) zum Prüfen einer Gesamtsumme der in der Speichereinheit (1) gespeicherten Tokenwerte (v) registrierter Token (T) des Transaktionssystems (TS).
17. Sicheres Element, welches als Teilnehmereinheit eines Transaktionssystems (TS) eingerichtet ist,
- zum direkten Austausch von Token (T) mit einer weiteren Teilnehmereinheit, wobei jeder Token (T) des Transaktionssystems (TS) zumindest einen Tokenwert (v) und einen privaten Teil (r) eines tokenindividuellen Schlüsselpaars als Token-Elemente aufweist,
- zum Erstellen eines modifizierten Tokens (T) aus einem vorhandenen, zu modifzierenden Token, wobei eine dem modifizierten Token (T) des Transaktionssystems (TS) eindeutig zugeordnete Tokenreferenz (TR) zumindest den Tokenwert (v) des Tokens (T) und einen öffentlichen Teil (R) des tokenindividuellen Schlüsselpaars als Tokenreferenz-Elemente aufweist, wobei der öffentliche Teil (R) des tokenindividuellen Schlüsselpaars durch Anwenden einer kryptografischen Einwegfunktion auf den privaten Teil (r) des tokenindividuellen Schlüsselpaars des Tokens (T) erhalten wird, und
- zum Bereitstellen einer Registrieranfrage (RA) an ein Tokenreferenz-Register (TRR) des Transaktionssystems (TS), wobei die Registrieranfrage (RA) zumindest die dem Token (T) des Transaktionssystems (TS) eindeutig zugeordnete Tokenreferenz (TR) aufweist.
18. Ein Transaktions system (TS) aufweisend: eine Registerschicht (TRR-Schicht) mit einem Tokenreferenz-Register (TRR) gemäß Ansprüchen 15 oder 16 zum Registrieren von Tokenreferenzen (TR); und eine Direkttransaktionsschicht (TE-Schicht) mit einer Vielzahl von Teilnehmereinheiten (TE), die mindestens teilweise als sichere Element gemäß Anspruch 17 ausgebildet sind, insbesondere eingerichtet zum direkten Austausch von Token (T) untereinander.
EP22744114.4A 2021-08-04 2022-07-12 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister Pending EP4381408A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021004020.1A DE102021004020A1 (de) 2021-08-04 2021-08-04 Verfahren zum registrieren von token eines elektronischen transaktionssystems
PCT/EP2022/025325 WO2023011756A1 (de) 2021-08-04 2022-07-12 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Publications (1)

Publication Number Publication Date
EP4381408A1 true EP4381408A1 (de) 2024-06-12

Family

ID=82611281

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22744114.4A Pending EP4381408A1 (de) 2021-08-04 2022-07-12 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Country Status (6)

Country Link
US (1) US20240275600A1 (de)
EP (1) EP4381408A1 (de)
CN (1) CN117916735A (de)
BR (1) BR112024002177A2 (de)
DE (1) DE102021004020A1 (de)
WO (1) WO2023011756A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4425405A1 (de) 2023-03-01 2024-09-04 Giesecke+Devrient advance52 GmbH Sicherer dienstanbieter, sichere geldbörse, verfahren zur ausgabe einer oder mehrerer sicherer geldbörsen
EP4432191A1 (de) 2023-03-14 2024-09-18 Giesecke+Devrient advance52 GmbH Sichere tokenausgebereinheit, sichere dienstanbietereinheit, elektronisches zahlungstransaktionssystem, verfahren zur bereitstellung neuer token, verfahren zum empfangen alter token

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7555460B1 (en) * 2000-06-05 2009-06-30 Diversinet Corp. Payment system and method using tokens
TWI340354B (en) 2006-12-14 2011-04-11 Inst Information Industry System, method, and computer readable medium for micropayment with varying denomination
DE602007012538D1 (de) 2007-07-27 2011-03-31 Ntt Docomo Inc Verfahren und Vorrichtung zur Durchführung delegierter Transaktionen
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
KR102305825B1 (ko) * 2014-10-31 2021-09-27 삼성에스디에스 주식회사 토큰을 이용한 결제 방법 및 그 장치
WO2016065390A1 (en) 2014-10-31 2016-05-06 In4Ma Pty Ltd Electronic money, method of producing electronic money and transaction method using electronic money
US11062303B2 (en) 2015-06-08 2021-07-13 Blockstream Corporation Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction
CN113542293B (zh) 2015-12-04 2023-11-07 维萨国际服务协会 用于令牌验证的方法及计算机
US20170293899A1 (en) 2016-04-12 2017-10-12 Digicash Pty Ltd. Digital value token processing systems and methods having improved security and scalability
US11037162B2 (en) * 2018-05-14 2021-06-15 Visa International Service Association System, method, and computer program product for determining an event in a distributed data system
DE102019002732A1 (de) 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem

Also Published As

Publication number Publication date
BR112024002177A2 (pt) 2024-04-30
CN117916735A (zh) 2024-04-19
DE102021004020A1 (de) 2023-02-09
WO2023011756A1 (de) 2023-02-09
US20240275600A1 (en) 2024-08-15

Similar Documents

Publication Publication Date Title
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
DE102019002732A1 (de) Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
EP3956845A1 (de) Gerät zum direkten übertragen von elektronischen münzdatensätzen an ein anderes gerät sowie bezahlsystem
EP4399632A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
EP4381408A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
WO2023011761A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
EP4179488A1 (de) Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem
WO2022233454A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102021004023A1 (de) Verfahren zum direkten übertragen von token
EP3254432A1 (de) Verfahren zur berechtigungsverwaltung in einer anordnung mit mehreren rechensystemen
WO2022008321A1 (de) Verfahren, endgerät sowie münzregister zum übertragen von elektronischen münzdatensätzen
EP4111399B1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
WO2024012624A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber
EP4111347B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
WO2024027869A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102022130483A1 (de) Verfahren zum beglaubigen eines hardware-wallets einer blockchain
EP4405879A1 (de) Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit
DE102021000570A1 (de) Verfahren zum bereitstellen eines nachweisdatensatzes; verfahren zum prüfen eines nachweisdatensatzes; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240304

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR