SECURE ELEMENT, METHOD FOR REGISTERING TOKENS, AND TOKEN REFERENCE REGISTER

Abstract

A secure element relates to a transaction unit and to a method for registering tokens of an electronic transaction system, which includes the secure element acting as a transaction unit and a token reference register. Each token of the transaction system has at least one token value and one private part of a token-individual key pair acting as token elements.

Claims

1.-23. (canceled)

24. A method for registering tokens of an electronic transaction system comprising secure elements as transaction units, each token of the transaction system having at least one token value and one private part of a token-individual key pair acting as token elements, comprising the method steps: receiving registration requests in a token reference register of the transaction system, the registration requests each having at least two token references, with at least one token reference of a first registration request of the registration requests and one token reference of a second registration request of the registration requests being identical; verifying, using a verification unit of the token reference register, whether a token reference of a registration request can be uniquely assigned to a token of the transaction system, the token reference being checked to see whether it is or was stored in the token reference register; storing at least one token reference other than the checked token reference in the memory unit of the token reference register for registering the token uniquely assigned to this token reference in the transaction system if it is established in the verification step that a token of the transaction system can be assigned to the checked token reference; wherein in the receiving step, the registration requests are received in the token reference register as a sequence of registration requests, and in the verification and storage steps, the registration requests are processed in the token reference register as a sequence of registration requests.

25. The method according to claim 24, wherein each token reference other than the other token reference from the sequence of registration requests was or is uniquely assigned to a token in the transaction system, and wherein in particular the tokens in a direct transaction layer of the transaction system were transmitted directly between subscriber units of the transaction system and/or were modified by a subscriber unit without these tokens being registered in the transaction system.

26. The method according to claim 24, wherein in the receiving step, the registration requests are received as a sequence of registration requests of one of the secure elements; and/or at least the first and second registration requests of the sequence contain a previously unregistered token present in the subscriber unit, in particular the secure element.

27. The method according to claim 24, wherein the entire sequence of registration requests is received in the token reference register before the verification step is executed; and/or the verification step is executed for at least one token reference from each registration request; and/or the storage step is executed for the other token reference, in particular in each case, if the other token reference is not yet stored; and/or at least three registration requests of the sequence comprise a token reference, which is also the token reference of another registration request of the sequence.

28. The method according to claim 24, wherein the entire sequence of registration requests is sent from a subscriber unit of the transaction system to a registration request unit of the transaction system before the verification step is executed, and wherein the token reference register sequentially receives and verifies each registration request from the sequence of registration requests from the registration request unit, before the next registration request from the sequence of registration requests is received and verified.

29. The method according to claim 24, wherein the sequence of registration requests is stored in an archiving unit of the token reference register.

30. The method according to claim 24, wherein each registration request from the sequence of registration requests is stored in an archiving unit of the token reference register, in a first part of the archiving unit, if it is established in the verification step that the checked token reference of one of the registration requests of the sequence of registration requests cannot be uniquely assigned to any token of the transaction system.

31. The method according to claim 30, wherein a sequence of registration requests with token references is stored in a second part of the archiving unit if all token references of the sequence of registration requests can each be uniquely assigned to a token of the transaction system.

32. The method according to claim 24, wherein the token references of the sequence of registration requests are verified chronologically backwards.

33. The method according to claim 24, wherein each token reference comprises at least the token value of the token and a public part of the token-individual key pair as token reference elements, wherein the public part of the token-individual key pair was obtained by applying a cryptographic one-way function to the private part of the token-individual key pair of the token.

34. The method according to claim 33, wherein the registration request is signed with the private part of the token-individual key pair in order to be able to verify an assignment of the token reference to the token.

35. The method according to claim 24, wherein each token reference has been obtained by masking the associated token by applying a homomorphic one-way function to the token.

36. The method according to claim 24, further comprising the method steps of: generating, from the verification unit of the token reference register, a registration response, wherein the registration response indicates a result of the verification step; sending the registration response to a subscriber unit or registration request unit of the transaction system sending the registration request from the sequence of registration requests, the subscriber unit having the token of the at least one token reference of the sequence of registration requests.

37. The method according to claim 24, wherein the sequence of registration requests is provided by a subscriber unit, and/or wherein each registration request of the sequence comprises at least one token reference as an output token reference and at least one input token reference, and/or wherein the registration requests of the sequence are linked to each other, in particular, in each case, an output token reference of a registration request of the sequence forming an input token reference of the next registration request of the sequence.

38. A token reference register for a transaction system, configured for performing the method steps according to claim 24.

39. The token reference register according to claim 38, comprising: at least one memory unit for storing token reference for registering tokens in the transaction system; at least one verification unit for verifying whether a token reference of a received registration request is stored in the token reference register; an archiving unit for storing sequences of registration requests; and a new registration unit for registering tokens newly generated by a token issuer or tokens deleted by a token issuer.

40. The token reference register according to claim 38, wherein the memory unit is configured such that: a subscriber unit or a registration request unit only has write accessin particular by means of registration requeststo the memory unit; and/or the archiving unit and/or the verification unit has read and write access to the memory unit.

41. The token reference register according to claim 38, configured for receiving a plurality of registration requests, which are verified in parallel in a majority of verification units as to whether the at least one token reference contained in the respectively received registration request is uniquely assigned to a token of the transaction system, with all registration requests of a sequence of registration requests being verified sequentially one after the other in the same verification unit in each case.

42. A secure element as a subscriber unit in a transaction system having: an interface, configured for: transmitting token to another subscriber unit; transmitting, to a token reference register or a registration request unit of the transaction system, a registration request comprising at least a first and a second token reference; an access means to a token memory or token memories, wherein at least one token of the secure element is stored in the token memory; and a computing unit, configured for: applying a cryptographic one-way function to a private part of a token-individual key pair of a token of the token memory for obtaining a token reference; and modifying token.

43. The secure element as a subscriber unit according to claim 42, wherein a sequence of registration requests is stored in the token memory; and/or wherein the subscriber unit is configured to send registration requests as a sequence of registration requests to the token reference register; and/or wherein the subscriber unit is configured to receive only a registration confirmation for the sequence of registration requests from the token reference register .

44. The secure element as a subscriber unit according to claim 42, wherein only one token is stored in the token memory; and/or wherein, for transferring a token to another subscriber unit, the token is split, wherein a registration request is generated for this purpose, the registration request having a token reference of the token to be split and, in each case, a token reference of the split tokens; and/or wherein, when a token is received from another subscriber unit, the received token is merged to the token in the token memory, wherein a registration request is generated for this purpose, the registration request having a token reference for the merged token and, in each case, a token reference of the tokens to be merged.

45. A transaction system comprising: a register layer having a token reference register for registering token references; and a direct transaction layer having a plurality of subscriber units, in particular comprising secure elements according to claim 42, which are configured for the direct exchange of tokens with one another.

46. The transaction system according to claim 45, wherein the register layer comprises a registration request unit, wherein the entire sequence of registration requests is sent from a subscriber unit of the transaction system to the registration request unit of the transaction system before the verification step is executed, and wherein the token reference register receives the registration request from the sequence of registration requests from the registration request unit.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0142] The invention and further embodiments and advantages of the invention will be explained in more detail below with reference to figures, wherein the figures merely describe exemplary embodiments of the invention. Identical components in the figures are provided with the same reference numbers. The figures are not to be considered true to scale; individual elements of the figures may be illustrated excessively large or excessively simplified.

[0143] FIG. 1 shows an exemplary embodiment of a transaction system according to the invention;

[0144] FIG. 2 shows an exemplary embodiment of a token reference register according to the invention;

[0145] FIG. 3a shows an overview of commands for tokens according to the invention;

[0146] FIG. 3b shows an overview of signed registration requests according to the invention for the commands according to the invention;

[0147] FIG. 4 shows an exemplary embodiment of a flowchart of a method according to the invention for generating and registering a token and an overview of the command details in dependence on the transaction layer;

[0148] FIG. 5 shows an exemplary embodiment of a flowchart of a method according to the invention for deleting a token and registration;

[0149] FIG. 6 shows an exemplary embodiment of a flowchart of a method according to the invention for splitting and registering a token, and an overview of the command details in dependence on the transaction layer;

[0150] FIG. 7 shows an exemplary embodiment of a flowchart of a method according to the invention for merging and registering a token, and an overview of the command details in dependence on the transaction layer;

[0151] FIG. 8 shows an exemplary embodiment of a flowchart of a method according to the invention for switching and registering a token, and an overview of the command details in dependence on the transaction layer; and

[0152] FIG. 9 shows a further exemplary embodiment of a token reference register according to the invention.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

[0153] FIG. 1 shows an exemplary embodiment of a transaction system TS according to the invention. The transaction system TS comprises a register layer, TRR layer, in which a token reference register TRR is arranged. The TS also comprises a direct transaction layer TE layer in which a plurality of subscriber units TE can be provided, representatively with two subscriber units TE1, TE2.

[0154] The subscriber units TE of the transaction system TS are configured to exchange tokens T directly amongst one another. In the case of FIG. 1, the tokens are payment tokens, which are also referred to as digital coins. Each token T is generated by a token issuer TH (not shown in FIG. 1; see FIG. 2). Each token T can be modified by each subscriber unit TE, i.e. split, merged or switched (see FIGS. 6 to 8) and can be generated by the token issuer TH (see FIG. 4) and also deleted (see FIG. 5). A token issuer TH is, for example, a central bank.

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

[0156] The random number r is a private part of a token-individual key pair. The random number r is unique and secret in the transaction system TS and cannot be published or re-used. The creation of the random number r may be unpredictable.

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

[0158] A token can be stored as a TLV-encoded data set in a token memory and then has a unique tag and length information, for example in the following format.

TABLE-US-00001 Day Token Random Name (hex) Length value v number r TLV-encoded token 42 1 byte 4 bytes 32 bytes

[0159] An example of a TLV-encoded token in hexadecimal form is shown below:

42 24 00 00 40 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1 F

[0160] and is interpreted as follows:
42 is the tag for identifying the TLV-encoded token T;
24 specifies the length, i.e. in this case that it is a 36-byte data set;
00 0040 00 is the token value (integer) v=16384 and is accordingly 163.84;
00 01 02 03 04 05 06 07 08 09 . . . 1D 1E 1F is the random number r as an integer.

[0161] A token reference TR can be stored in the token reference register TRR for each token T. The token reference TR comprises the token value v of the assigned token T and a public part R of the token-individual 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 disclosed by the token reference register TRR.

[0162] The public part R of the token-individual key pair is created by applying a cryptographic function to the private part r of the token-individual key pair. This function is difficult to reverse and thus gives the transaction system TS the available security. R=r*G, where G can, for example, be a global parameter of the transaction system TS, for example a generator point of an elliptical curve, here the secp256r1 curve.

[0163] 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 chaining of token value v and public part R.

[0164] This token reference TR can be sent as a registration request RA, optionally together with a command (see overview in FIGS. 3a and 3b) with respect to the token T to the token reference register TRR.

[0165] In addition, the registration request RA can be signed with the private part r of the token-individual key pair. The signing makes it possible to verify whether the transmitter of the token reference TR was in possession of the token T, whereby the security in the transaction system TS is further increased.

[0166] In the subscriber unit, the signed registration request RAsig is stored as a so-called PROOF, for example in the following format:

TABLE-US-00002 Type Day (hex) Length Data PROOF 4A N bytes

[0167] An example of a PROOF (=RA.sub.sig) in hexadecimal form is shown below:

4A 81 8 F 03 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1 F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2 F 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 4 F 50 51 52 53 54 55 56 30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1 F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2 F 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 4 F 50 51 52 53 54 55 56
and is interpreted as follows (see also FIG. 8 regarding the structure of a switch registration request):
4A is the tag for identification of the TLV-proof RA.sub.sig_Th,
81 8F gives the length;

[0168] 03 indicates that this is a switch (=SWITCH) registration request;

[0169] 11 12 13 14 is the token value v.sub.g;

[0170] 15 16 17 18 19 1A 1B 1C 1D 1E 1F 2021 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 is the public part R.sub.g;

36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 is the public part R.sub.h;
30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 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 is the signature as X690 sequence.

[0171] This registration request RA can be sent to the token reference register TRR. This registration request RA is received in the token reference register TRR. After checking the registration request RA by the token reference register TRR, the token reference TR is stored in the token reference register TRR, whereby the token T is registered in the transaction system TS.

[0172] The token reference TR is uniquely assigned to the token T and is used to register the token T in the transaction system TS. The token reference TR is accordingly the public representation of the token T from the direct transaction layer TE layer. The sole knowledge or only the possession of the token reference TR does not allow the token T to be transmitted and is not equivalent to the TE being in possession of the token T. The token reference TR serves to prevent multiple output attempts and checks whether token values v have been generated inadmissibly. For this reason, the token reference TR and, if applicable, the history via the tokens T and the corresponding registration requests RA from subscriber units TE are stored in the token reference register TRR.

[0173] The tokens T are stored, for example, in token memories or electronic purses, so-called wallets, of a TE. These wallets are, for example, software applications within the subscriber units TE or a terminal in which the TE is introduced ready for operation. A wallet can be configured as an application on a smart phone, a smart card, or a payment terminal. The wallet serves to securely manage tokens T of the TE, to create token references TR, to modify tokens T and/or to exchange tokens T. Wallets serve 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 of tokens T relative to a subscriber unit TE.

[0174] For a transaction with a subscriber unit TE, it is not necessary for there to be a communication link to the token reference register TRR of the transaction system TS. The transaction system TS is configured to carry out a transaction off-line, i.e. without a communication link to the token reference register TRR. A corresponding registration of tokens T can therefore be temporally downstream of a transmission of the token T to a subscriber unit TE.

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

[0176] Transmitting a token reference TR from an electronic wallet takes place, for example, as (an) APDU command(s) to a terminal device (smartphone) as subscriber unit TE. An APDU is a combined command/data block of a connection protocol between the secure element and the terminal. The structure of the APDU is defined by the ISO 7816-4 standard. The terminal device extracts APDU command(s) and transmits the data in API calls to the token reference register TRR, where HTTP codes are implemented.

[0177] FIG. 2 shows an exemplary embodiment of a token reference register TRR of the invention.

[0178] The token reference register TRR manages in particular the storage location for the token references TR, here as a database 1 as an example of a memory unit in the token reference register TRR. As a representative, the TR for the token T of the subscriber unit TE1 is entered in the database 1. This database 1 can consist of a combination of many databases (see also FIG. 9), which are networked with one another. For simple finding of a token reference TR, the public part R of the token reference TR is simultaneously a database index in the database 1, since both an index of a database and a public part R of a token reference TR must be unique in the transaction system TS.

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

[0180] In addition, the token reference register TRR may comprise a check unit 3 which checks whether (for example with the token value v of a received token reference TR) a total token value 2 is changed in the transaction system TS. The check unit 3 compares a total reference value with the actual sum of the token values stored in the database 1. If this is the case, a new token value v has been created or an existing token value v has been destroyed. Only privileged units, such as an issuer instance TH, may do this in the transaction system TS. If such a change in the total sum of the token values is detected by a token reference TR of a subscriber unit TE, then a case of fraud can be assumed. An illegal generation of token values v can thus be discovered and prevented very easily.

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

[0182] In addition, the token reference register TRR can comprise a new registration unit 4, into 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 functional separation between token references TR of privileged subscribers, such as a token issuer TH, and token references TR of unprivileged subscribers, such as the subscriber units TE, is thus achieved. The token values v of newly generated token references TR or token references TR to be deleted have a direct influence on a change in the total token value, which is monitored in the check unit 3. The total reference value is adjusted accordingly when the token issuer first registers or de-registers the TH token.

[0183] A registration request RA is preferably signed with the private part r. The signature allows the syntactic authenticity of the command to be easily checked by the recipient (TRR or TE). This check is preferably carried out in database 1 or verification unit 2. In addition, a registration request RA can, for example, be validated syntactically by checking the signature and/or the token reference TR.

[0184] Even when a signature can be checked in a subscriber unit TE, it is thereby not ensured that no multiple output of the same token T has been attempted. The registration in the token reference register TRR is therefore provided. In addition, a secure hardware platform is kept available by the subscriber units TE. With available connection to the token reference register TRR, the token references TR are transmitted and the multiple output attempt can be discovered in the token reference register TRR.

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

[0186] An archiving unit 5 may also be present in the token reference register TRR. Processed registration requests RA and/or processed sequences of registration requests RAF are stored in this archiving unit 5. Further details on the archiving unit are given in FIG. 9.

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

[0188] FIG. 3a shows an overview of commands CO that can be performed on a token T. These commands CO can be modifications to an existing token T, for example switch, split or merge. The commands CO can also relate to creating (=Create) a token T or deleting (Destroy) existing tokens T. In FIG. 3a, command codes are specified by way of example (0x01 to 0x05), which can then be part of a registration request RA.

[0189] FIG. 3b shows an overview of commands CO and their signed registration request syntax RA. In this case, input tokens T and input token references TR are consumed per command CO. In this case, output tokens T and output token references TR are created per command CO.

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

[0191] Each command CO has a characteristic number of input token reference(s) (inputs) and output token reference(s) (outputs), which are explained and shown in greater detail in FIGS. 4 to 8.

[0192] It should be noted that, for the commands CO split, switch and merge, the difference of the token values v of all participating tokens T or token references TR must give the value zero. In other words, these commands CO split, switch and merge do not create any token values v and do not destroy any token values v. This can be checked at the command type CO itself or also by the check unit 3 of the token reference register TRR and is a check criterion for a register request RA.

[0193] It is also to be noted that a difference of the token values v of the participating token T or token references TR is allowed only for the commands CO create and destroy, but only at the level of the token value v of the token T and not beyond.

[0194] Each registration request RA 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 applied as a signature. The registration request RA is preferably signed with the private part r of the token T.

[0195] For signed registration requests RA.sub.sig of the command types CO create and destroy, a further signature Sig.sub.TH of a token issuer TH is required in order to ensure that these commands have been generated by a privileged unit of the transaction system TS.

[0196] FIG. 4 shows an exemplary embodiment of a flowchart of a method according to the invention for generating a token T and registering it in the TRR. In addition, the signed registration request RA.sub.sig and the command structure is shown in tabular form both from the point of view of the TE layer and of the TR layer.

[0197] When generating, there is no input parameter in the TE layer. A random number r is generated in a privileged unit, here the token issuer TH. On the basis of the random number r, a public part R is calculated, as has been described above. IA token reference TR can thus be formed in the token issuer TH starting from the token value v and the public part R by concatenation of v and R.

[0198] A registration request RA consisting of the command CREATE or the command code according to FIG. 3a and the created token reference TR is signed in the token issuer TH. For this purpose, the private key pKey of the token issuer TH is used.

[0199] In the TE layer, the token T is output to the TE1. In the TRR layer, the signed registration request RA.sub.sig is output to the TRR.

[0200] In the token reference register TRR, the signature of the registration request RA is checked with the public key PKey of the issuing entity TH. This public key PKey.sub.TH is known across 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 into the token reference register TRR.

[0201] In one embodiment, the total token value of the transaction system TS in the check unit 3 of the token reference register TRR is increased by the token value v by the new registration unit 4 of the token reference register TRR.

[0202] FIG. 5 shows an exemplary embodiment of a flowchart of a method according to the invention for deleting a token T and registering the deleted T in the TRR. In addition, the signed registration requests RA.sub.sigTH and RA.sub.sig_T required for this purpose 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.

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

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

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

[0206] Both signed registration requests are sent to the token reference register TRR. In the token reference register TRR, the signature is checked with the public key of the issuing entity TH. This public key is known across a transaction system or was made available to the token reference register TRR in advance. In addition, 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 is deleted in the TRR or marked as deleted.

[0207] In one embodiment, the total token value of the transaction system TS in the check unit 3 of the token reference register TRR is reduced by the token value v by the new registration unit 4 of the token reference register TRR.

[0208] The token reference register TRR or the token issuer TH also causes the token T to be deleted in the subscriber unit TE1.

[0209] FIG. 6 shows an exemplary embodiment of a flowchart of a method according to the invention for splitting a token T.sub.a and registering the split tokens T.sub.b T.sub.c in the token reference register TRR. In addition, the signed registration requests RA.sub.sig_Ta required for this purpose and the command structure is shown in tabular form both from the point of view of the TE layer and the TR layer.

[0210] In the TE layer, a first random number r.sub.b and a second random number r.sub.c are created by the TE1. Based thereon, a public part R.sub.b and R.sub.c is then created in each case. The token T.sub.a to be split is available in the TE layer as input parameters. In the TE layer, the token value v.sub.a is split into a first token part value v.sub.b and a second token part value v.sub.c. The sum of token part value v.sub.b and token part value v.sub.c has to give the token value v.sub.a. This ensures that no new token value v is created or no token value v is destroyed.

[0211] The token references TR.sub.b and TR.sub.c are then created by the TE1. The registration request RA then contains the command SPLIT or the command code shown for it in FIG. 3a, the input token reference TR.sub.a and the output token references TR.sub.b and TR.sub.c. This registration request RA is signed with the random number r.sub.a of the token T.sub.a. The signed registration request RA.sub.sig_Ta is sent from the TEI to the token reference register TRR. There, the signature is checked and the sum of v.sub.b and V.sub.c is formed and compared with the token value v.sub.a. If v.sub.a=v.sub.b+v.sub.c and the signature check is successful, then the token reference TR.sub.a in the token reference register TRR will be deleted or marked as deleted, and the token references TR.sub.b and TR.sub.c are entered in the token reference register TRR.

[0212] In one embodiment, in the token reference register in the verification unit 2, the token value difference of the input token reference TR.sub.a and the output token references TR.sub.b and TR.sub.c is formed and checked to see whether this difference is zero. If the difference is not zero, a token value v will have been generated or destroyed inadmissibly. In addition, the total token value of the transaction system TS can also be checked in the check unit 3 of the token reference register TRR before or after the registration of the token references TR.sub.b and TR.sub.c. The total token value v in the check unit 3 must not have changed and must correspond to the value before processing of the registration request in the token reference register TRR.

[0213] The split token T.sub.b (or T.sub.c) (which was temporarily transmitted from TE1 to TE2) can now be checked for validity by the subscriber unit TE2 in the TRR.

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

[0215] FIG. 7 shows an exemplary embodiment of a flowchart of a method according to the invention for connecting a token T.sub.d to a token T.sub.e and registering the connected token T.sub.f in the TRR. In addition, the signed registration requests RA.sub.sig_Td and RA.sub.sig_Te required for this purpose 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.

[0216] Here, a random number rr is created in a TE1 of the TE layer. Based thereon, a public part R.sub.f is then created. In addition, a sum is formed from the token values v.sub.d and v.sub.e to the token value v.sub.f based on the input tokens T.sub.d and T.sub.e.

[0217] The output token reference TRf is then created. A registration request RA then contains the command MERGE or the command code listed in FIG. 3a, which comprises two input token references TR.sub.d and TR.sub.e as well as the output token reference TR.sub.f. This registration request RA is signed once with the random number r.sub.d of the token T.sub.d in order to obtain a first signed registration request RA.sub.sig_Td. This registration request is also signed with the random number r.sub.e of the token T.sub.e in order to obtain a second signed registration request RA.sub.sig_Te. Both signed registration requests RA.sub.sig_Ta and RA.sub.sig_Te are sent by the subscriber unit TE1 to the token reference register TRR. The signatures of the registration requests RA.sub.sig_Td and RA.sub.sig_Te are each checked there. In addition, the sum of the token values v.sub.d and v.sub.e is formed and compared with the token value v.sub.f. If v.sub.f=v.sub.d+v.sub.e and both signature checks are successful, then TR.sub.d and TR.sub.e will be deleted in the token reference register TRR or marked as deleted, and the token reference TR.sub.f will be entered in the token reference register TRR. The connected token T.sub.b (which was temporarily transmitted from TE1 to TE2) can now be checked for validity by the subscriber unit TE2 in the TRR.

[0218] FIG. 8 shows an exemplary embodiment of a flowchart of a method according to the invention for switching a token T.sub.g to a token T.sub.h and registering the switched token T.sub.h in the shown token reference register TRR. In addition, the signed registration requests RA.sub.sig_Tg required for this purpose 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.

[0219] Here, random number r.sub.h is created in a TE1. Based thereon, a public part Rh is then created. In addition, the token value v.sub.h identical to the token value v.sub.g of the input token T.sub.g is formed.

[0220] The token reference TR.sub.h is then created. A registration request RA then contains the command SWITCH or a corresponding command code according to FIG. 3a, the input token reference TR.sub.g and the formed public part R.sub.h (or the output token reference TR.sub.h). This registration request RA is signed with the random number r.sub.g of the token T.sub.g. The signed registration request RA.sub.sig_Tg is sent by the subscriber unit TE1 to the token reference register TRR. The signature is checked there. In addition, the token value v.sub.g is compared with the token value v.sub.h. If v.sub.g=v.sub.h and the signature check is successful, then the token reference TR.sub.g in the token reference register TRR will be deleted or marked as deleted, and the token reference TR.sub.h entered in the token reference register TRR.

[0221] FIG. 9 is a further embodiment of a token reference register TRR of a transaction system TS. Optional units are shown with dashed lines.

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

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

[0224] In addition, FIG. 9 shows an optional registration request unit RAE, which receives a sequence of registration requests RA.sub.F from a subscriber unit TE1. The registration request unit RAE can, for example, forward the sequence RA.sub.F as a whole or one after the other in individual RA to the TRR. Only alternativelynot according to the present solutionan RAE could also only send the individual RA to the TRR, so that the TRR would have no knowledge of the existence of the sequence RA.sub.F.

[0225] It is advantageous if only one token T is used per subscriber unit TE (here as a secure element, e.g. smart card or TEE). However, the subscriber unit TE can also contain several tokens. This means that the TE connects (MERGES) a received token T with the token T stored in the token store. This also means that the TE separates (SPLITS) a token T to be sent from the token T stored in the token memory. These modifications to the token T can initially be carried out without a registration request RA and the token T can be passed on immediately after a modification. There may therefore be a sequence of modifications to the token T that are not known to the TRR. Typically, the sequence of RA registration requests consists of a combination of SPLIT and MERGE modifications. Each of these modifications is also saved as a proof (see FIG. 1 above) or signed registration request RAsig with the token T. This creates a sequence of RA.sub.F registration requests in the TE.

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

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

[0228] A terminal device (not shown in FIG. 9) can be provided between the TE and the TRR, into which the TE is inserted ready for operation. The terminal device can access the TE, for example by means of an electronic wallet. The terminal device switches the registration requests RA to the TRR. For this purpose, the terminal device receives the sequence RA.sub.F. Alternatively or additionally, a registration request unit RAE can also be provided between the TE and the TRR as a switching instance, see FIG. 9. The RAE then receives the sequence RA.sub.F from the TE or the terminal device.

[0229] According to FIG. 9, the RAE receives the sequence RA.sub.F and sends individual RA from the sequence RA.sub.F as part of the sequence to the TRR. The registration of the individual RA is carried out according to the same scheme as shown in FIGS. 1 to 8 and explicit reference is made to this. Alternatively or additionally, the TRR receives the entire sequence RA.sub.F at once before the verification is carried out, for example in an API request. The TRR then processes each RA of this RA.sub.F individually.

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

[0231] The verification unit 2 of the TR checks the validity of all individual RA in the sequence RA.sub.F (also referred to as payload) one after the other and translates the final result for all RA into a single RB. This RB has a registration status information, for example 200 if all RA in the sequence RA.sub.F have been successfully verified, and for example 400 if not all RA in the sequence RA.sub.F have been successfully verified. The RB is sent back to the TE (optionally via the RAE or the terminal device). The RB can be signed with a private key pKey.sub.TRR for a key pair of the verification unit 2. The RB can also comprise an RA.sub.sig, for example all RA of the sequence RA.sub.F or only the last RA of the sequence RA.sub.F.

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

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

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

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

[0236] If all RA in the sequence RA.sub.F are successfully verified (e.g. status 200), the following algorithm is triggered in the TE:

[0237] Step 1: Thread the chronologically last RA for the sequence RA.sub.F from the token memory;

[0238] Step 2: Check the signature RA.sub.sig_T from the RB with the public part R. If the signature RA.sub.sig_T cannot be checked, continue with step 6;

[0239] Step 3: If RA.sub.sig_T of the RB is verifiable, the signature of verification unit 2 is checked with the public part PKey.sub.TRR of the key pair for verification unit 2;

[0240] Step 4: If the signature of verification unit 2 is verifiable, delete all RA of the sequence RA.sub.F from the token memory of the TE. If the chronologically last RA can be successfully verified in verification unit 2, this means that all previous RA in the sequence RA.sub.F must also have been verified. This always occurs, for example, if the TE always (only) keeps available one token T and subtracts or adds further token values v from the token value v of token T with modifications (split/merge).

[0241] Step 5: If the signature of verification unit 2 cannot be verified, the protocol has been violated. A man-in-the-middle attack is assumed; the registration requests RA are not deleted from the token memory of the TE.

[0242] Step 6: If RA.sub.sig_T of the RB is not verifiable, the entire sequence is iteratively checked to find the RA for which RA.sub.sig_T from the RB is verifiable. The sequence RA.sub.F can be iterated in two directions, either from the oldest RA to the newest RA or from the newest RA to the oldest RA. If a matching RA is found in the sequence RA.sub.F, steps 3 to 5 are executed.

[0243] This algorithm is now explained using an example in which two modifications are made to a token T:

Modification 1 (SPLIT, see also FIG. 6): The token value v.sub.a of the token T.sub.a is divided from v=100 into v.sub.b=30 and into v.sub.c=70.
Modification 2 (MERGE, see also FIG. 7): The token value v.sub.b=70 is combined with a token value v.sub.d=50 of another token T.sub.d to form a new token value v.sub.e=120.

[0244] The corresponding RA for the two modifications are:

RA1=[SPLIT, 100, 8, 30, 9, 70, 10]

RA2=[MERGE, 70, 10, 50, 6, 120, 11]

[0245] The TE calculates (see also FIGS. 6 and 7) three RA.sub.sig_T:

RA.SUB.Sig1.=sig(r1, RA1)

RA.SUB.Sig2A.=sig(r2, RA2)

RA.SUB.Sig2B.=sig(r3, RA2)

[0246] RA.sub.Sig2A and RA.sub.Sig2B can be transmitted together or form a common signed RA. The TRR checks the validity and confirms all RA.sub.Sig (=proofs) by sending the following response RB back to the TE:

Status=200, Sig2A, sig(pKey.sub.TRR, [200, Sig2A, Sig2B])

[0247] If verification of an RA fails in the sequence RA.sub.F (e.g. status 400), the following algorithm is executed:

[0248] Step 1: Find the chronologically oldest RA in the sequence RA.sub.F that can be verified with the RA.sub.sig_T of the RB. The sequence RA.sub.F can be iterated in two directions, either from the oldest RA to the newest RA or from the newest RA to the oldest RA.

[0249] Step 2: If the RA.sub.sig_T of the RB can be verified with an RA of the sequence RA.sub.F, the signature of verification unit 2 is checked with the public part PKey.sub.TRR of the key pair of verification unit 2. If the signature of verification unit 2 cannot be verified, the protocol has been violated. A man-in-the-middle attack is assumed; the registration requests RA are not deleted from the token memory of the TE.

[0250] Step 3: If the signature of verification unit 2 is verifiable, no RA (proofs) are deleted. Optionally, failed RA can be marked or the RA can be kept in the token memory of the TE to make it easier to identify the failed RA if this is requested later.

[0251] This algorithm is now also explained using an example. Four modifications (SPLIT, MERGE, MERGE, SPLIT) will be carried out on a token T:

Modification 1 (SPLIT, see also FIG. 6): The token value v.sub.a of the token T.sub.a is divided from v=100 into v.sub.b=30 and into v.sub.c=70.
Modification 2 (MERGE, see also FIG. 7): The token value v.sub.b=70 is combined with a token value v.sub.d=50 of another token T.sub.d to form a new token value v.sub.e=120.
Modification 3 (MERGE, see also FIG. 7): The token value v.sub.e=120 is combined with a token value v.sub.f=40 of another token T.sub.f to form a new token value v.sub.g=160.
Modification 4 (SPLIT, see also FIG. 6): The token value v.sub.g=160 is divided into v.sub.h=100 and v.sub.i=60.

[0252] The corresponding RA for the four modifications are:

RA1=[SPLIT, 100, 8, 30, 9, 70, 10]

RA2=[MERGE, 70, 10, 50, 6, 120, 11]

RA3=[MERGE, 120, 11, 40, 5, 160, 13]

RA4=[SPLIT, 160, 13, 60, 17, 100, 3]

[0253] The TE calculates (see also FIGS. 6 and 7) six RA.sub.sig_T:

Ra.SUB.Sig1.=sig(r1, RA1)

RA.SUB.Sig2A.=sig(r2, RA2)

RA.SUB.Sig2B.=sig(r3, RA2)

RA.SUB.Sig3A.=sig(r4, RA3)

RA.SUB.Sig3B.=sig(r4, RA3)

RA.SUB.Sig4.=sig(r6, RA4)

[0254] RA.sub.Sig2A and RA.sub.Sig2B as well as RA.sub.Sig3A and RA.sub.Sig3B can be transmitted together or form a common signed RA. The TRR checks the validity and determines that RA3 is invalid and sends the following response RB back to the TE:

Status=400, Sig3A, sig(pKey.sub.TRR, [400, Sig3A, Sig3B])

[0255] It is not obvious to the TE that if the TRR sends an RB with status code 400, the token(s) T associated with this RB is/are forged. It may happen that all RA within the TE are valid and contain real/valid token T, but the TRR still responds with an RB with status (error code) 400 to a registration request of the sequence RA.sub.F. The status (error code) 400 initially causes the registration of the sequence RA.sub.F to be aborted. The sequence RA.sub.F may already be partially processed and the memory unit 1 has already been partially updated using parts of the sequence RA.sub.F.

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

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

[0258] The hash/check value can be part of the signature of verification unit 2. If the TE now checks the signature of verification unit 2, the TE must retrieve the stored hash/checksum from its token memory. If the TE can establish this assignment, this means that the sequence RA.sub.F has not been manipulated (e.g. by a switching instance, such as a terminal device, RAE, or a man-in-the-middle instance).

[0259] The process (sending the sequence RA.sub.F) will then simply be repeated, the corresponding RA with signatures are still available in the TE. The only partially processed sequence RA.sub.F can be obtained from an archiving unit 5 of the TRR.

[0260] This abort or only partial processing (execution) can also or alternatively occur due to a malfunction of a TE. For example, a malicious TE has deliberately changed either the order of the RA or the syntax of the RA, as a result of which the TRR cannot verify the RA (fraud attempt). For example, an invalid RA was received in the sequence RA.sub.F due to malfunctioning of the TE or due to data transmission errors or for other reasons.

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

[0262] If the signature verification fails, then either the RA.sub.F data was manipulated during transmission or the response did not come from verification unit 2, but some third party posed as verification unit 2 but was unable to create a valid signature. The TE then ignores the RB without any changes in the token memory of the TE.

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

[0264] For such an analysis, a proper examination using the archiving unit 5 (and optionally the verification unit 3 and/or the new registration unit 4) is required.

[0265] In such a case, the TRR transfers the entire outstanding RA.sub.F to archiving unit 5. However, this application can also be installed in an ATM terminal or a web server. It specializes in analyzing and correcting billing errors and generating a blacklist of forged tokens T (based on the token references TR) currently circulating in the off-line world. The aim is to reset the TE and the token memory (including the sequence RAF) and load a replacement token T onto the TE.

[0266] The TE or the RAE or the terminal device sends the (entire) sequence RA.sub.F to the archiving unit 5 together with the RB of the verification unit 2 of the TRR. The RB can serve as confirmation that the registration of the sequence RA.sub.F has been canceled.

[0267] The archiving unit 5 of the TRR checks every RA of the sequence RA.sub.F both syntactically and semantically with the aid of the verifying unit 2 of the TRR. For this purpose, the archiving unit 5 has read/write access to the memory unit of the TRR. The TR within an RA are checked individually.

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

[0269] The archiving unit 5 may request transaction log records from the TE corresponding to the failed RA and the RA or TR listed in the archiving unit 5. This information from the TE can be used to identify and track malicious TE.

[0270] The archiving unit 5 can have replacement tokens generated with the entire token value (including the token values from the archiving unit 5) or only from the verified RA and valid TR according to the memory unit 1, for example by the new registration unit 4.

[0271] The token memory of the TE is emptied and loaded with this replacement token.

[0272] The value neutrality of the registration requests RA is checked in the verification unit 2. For each registration request of a subscriber unit TE, it checks whether the sum of the input token values is equal to the sum of the output token values. The test unit 3 checks the total value of the stored token values in the memory unit 1, for example before or after the processing of a sequence RA.sub.F and/or at selected times (periodically or quasi-randomly). The check unit 3 compares the currently stored total token value with a reference value. The reference value is adjusted when the token issuer TH deletes or initially registers tokens via its interface, the new registration unit 4.