[0001] This invention relates to secure electronic communications, and more particularly to a transferrable value or rights token.

Background

[0002] Tokens can be used to represent the value of an asset or a right to a service. Such value or rights may relate to a representation of any physical or digital asset including for example digital currencies, stocks, shares, coupons, bonds, options, vouchers, deeds etc.

[0003] Referring to Fig 1, there is shown a transferable value or rights token system in accordance with Applicants patent publication GB 1417413.0, the entire content of which is hereby incorporated herein by reference. The illustrated system comprises a user access device 1 which includes a user interface 4 and an authentication component 5 which connects to a communication media 3 to obtain access to a pocket controller device 2. This pocket controller device 2 includes a memory configured to store at least two pockets 9 which store the current balance of the value or rights tokens held by a respective user. The users gain access to their pockets through the controller 6 after successful authentication by the authentication component 5. The controller 6 connects to the certification engine 8 to create one or more digital signatures or cryptographic check values that are used to protect the token. The issued tokens are stored in the Token store 7. These tokens can be stored and moved in any suitable form including for example by the use of bar codes.

[0004] The pocket controller device 2 provides at least two core functions to the users, the ability to create tokens and the ability to load tokens. Once a token is created it doesn't need to contain any reference to the source pocket from which the token was created or the pocket into which the token will eventually be loaded. In this sense the token is anonymous because it contains no reference to the users of the system.

[0005] The system of Applicants patent publication GB 1417413.0 is based on the concept of creating anonymous tokens of a user-defined value that can be readily transferred between users in a way that more closely relates to the handling of cash, but in an on-line mode.

Although the handling of tokens is assumed to be through on-line communications media it is possible to define an embodiment where only the receiver of the token needs to be on-line.

[0006] Users of the Token system may enrol in order to be assigned a pocket and receive credentials to enable their access to be authenticated. User access authentication may be the traditional user name and password or a 2-Factor authentication method using something the user owns such as a smart card and something the user knows such as a password. In some cases, the system may use the Transport Layer Security (TLS) protocol where the user is issued with a client certificate to store in devices such as mobile phones and tablets or PCs. The users may arbitrarily enhance this security by requiring further access credentials to use the client certificate such as a user PIN or password.

[0007] When a user wishes to transfer a value token to another party, the user connects to the authentication module of the pocket controller device. Based on the credentials provided by the user authentication process, the controller identifies which pocket belongs to the user making the authentication request.

[0008] Following successful authentication, the user may then request the creation of a value token. The controller will then decrement the user's pocket and create a corresponding value token. This value token may be protected by a cryptographic check sum, although a digital signature would be an alternative security technique.

[0009] In normal operation the controller would actually create two cryptographic checksums using two separate security domains. This provides a more secure approach particularly where access to the token controller takes place over the public internet. The two security domains may be located and managed by different legal entities such that, in practice, collusion to make an attack is extremely difficult to achieve and hence highly unlikely.

[0010] For the purposes of this disclosure, the term "security domain" shall be understood to refer to run-time environment in which messages may be secured by means cryptographic keys, checksums and/or digital signatures generated using of a set of one or more certificates and/or root keys that are typically provided by a trusted authority. A security domain may comprise a respective Certification Authority (CA) for keys issued within that security domain, and respective cryptographic features (including algorithms), either of which may be the same or different from those of other security domains. The term "separate security domains" refers to run-time environments in which messages may be secured on the basis of respective different sets of certificates and/or root keys, and possibly respective different CAs. In some cases, the certificates and/or root keys defining two or more separate security domains may be provided by respective different trusted authorities, but this is not essential. Typically, messages secured under one security domain cannot be validated by a process using a different security domain. Applicants' patent publication GB 1417413.0 teaches

embodiments in which each token is secured by cryptographic check sums generated using two separate security domains. This means that in order to attack the token, it would be necessary for a hacker to obtain both sets of certificates and/or root keys.

[0011] The two cryptographic checksums enable the token transfer process to consist of three steps, the creation of a token by a "sending" party, and the load of a token by a receiving party, which has twosteps. In a first step, the receiving party is given the token and just one of the two cryptographic checksums. This enables the controller to check the authenticity of the Token and to mark its destination to be that of the receiving party's pocket. In the second step, the receiving party is given the second cryptographic checksum, which they can present to the controller in order to vest the value of the token in their pocket. This certificate verification technique allows the transaction process to take place in two steps but allows the receiving party to ensure that they have received an authentic token and that it cannot be spent by anybody else.

[0012] This type of operation is particularly useful when the two parties engaged in a transaction do not trust each other. On the other hand, in many cases the sender and receiver would trust each other. In such a case, perhaps for example when a parent is paying value to their children, it would not be necessary to split the load and verify function. Rather, the receiving party could be given both cryptographic check sums in a single operation, so that they can present both cryptographic check sums along with the token to the controller, again as a single operation.

[0013] The token transfer system also allows an additional function for users to check the validity of the value token by providing a validate operation. In this case the receiver of the token can send it to the controller to request a validity check. The controller would check that the token is authentic and has not previously been spent. In this case the receiver may not have all the information necessary to load the token, for example the sender may not have provided the second (i.e. the verification) cryptographic check sum. However the token can still marked as unspent and could be given to another user. The load command results in the token being marked as spent even though the value may not be vested with the receiver, who is still awaiting the verification cryptographic check sum.

[0014] It is an important to recognise that it is not necessary to include information in the Token that identifies either the sender or the receiver. Breaking the link between Tokens and users in this way means that the spending behaviour of users cannot be monitored and their activities can be truly anonymous. This may be important not only when the tokens are used for payments but also when they relate to rights, perhaps for example a vote.

[0015] How the users of the system handle the security of the tokens is arbitrarily their choice. The tokens are protected by their own integrity function and it is not possible for an attacker to modify the contents of the token without detection. However if some third party were to steal a complete token (that is, the token itself plus both of its cryptographic checksums) before it is loaded by the rightful owner then there is no inherent protection because they could load it into their own pocket. Thus there is a problem remaining to be solved, which may be described as how to ensure that only the rightful owner (or,

equivalently, the intended receiving party) of the token can successfully load the token to their pocket.

Summary

[0016] The above noted problem is solved by the combination of features defined in the appended independent claims. Further, optional features of the invention are defined in the appended dependent claims.

[0017] An aspect of the present invention is that it offers the users of the system an additional security feature such that loss or theft of the token is not a concern. It is always possible for a token to be duplicated, but a token can only be loaded once by the pocket controller. The pocket controller is provided with an additional feature which may be optionally applied by the users to enforce the use of a secret PIN necessary for loading the token into the pocket by the pocket controller. The use of this PIN allows the users to ensure that the token value can only be loaded to a pocket associated with the intended recipient.

[0018] When a user creates a token they may optionally provide a secret PIN of arbitrary length but typically 4 or 6 digits. In the event that no PIN is provided b the user, the pocket controller may allocate a default value defined by the system which might be a null value or perhaps a value of 4 zeros but other values including alphanumeric sequences are possible. In any event the user-defined or default PIN value is included in the cryptographic check sums that are used to protect the integrity of the token. It is not necessary or desirable to include the PIN within the token itself unless protected for confidentiality.

[0019] When a user passes the token to another person, the sender makes the recipient aware of the secret PIN value by some independent means, such as, for example, by means of a phone call or a text message or any other viable communications channel. When the receiver of the token loads the token into the pocket controller it will be necessary for them to also provide the secret PIN, which the pocket controller will include in the validation of the cryptographic check sums. In the event that no PIN is provided by the recipient, the pocket controller will assume the default value is to be used when checking the cryptographic check sums.

[0020] In some embodiments, the pocket controller will allow a predefined number of attempts typically 4 although other values are possible. Alternatively, it is possible to allow an undefined number of attempts at entering the PIN.

[0021] There may be occasions when the PIN gets lost or forgotten. Similarly, the receiver of the token may exceed the number of allowed attempts at entering the PIN when loading the token into the pocket controller. In order to recover from this situation embodiments of the present invention may allow for the creator of the token to load it back into their own pocket. When the token is created the token database may store a reference code associated with the pocket from which the coin was created. The pocket controller may allow the user authorised to access the original pocket from which the token was created to load it back into their pocket. This authority would allow the token to be reloaded into the source pocket even if the number of PIN attempts (by either the sending or receiving users) has been exceeded. It is clear that in these circumstances the token database also needs to store the value of the chosen secret PIN in order to be able to check the cryptographic checksums that are used to protect the token.

[0022] As may be appreciated, the receiver of a value token protected by a PIN may load the token into their pocket and then create a new one protected by a PIN that only they know. This removes the capability of the token sender to spend the token (or reload it to their own pocket) after sending it to another person and also ensures that the receiver has taken the valueof the token.

Brief Description of Drawings

[0023] Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0024] Figure 1 is a diagram that shows the components involved in the transfer of value tokens where "TIBADO" represents the token and pocket controller device;

[0025] Figure 2 is a sequence diagram that shows the complete transfer of value token in accordance with an embodiment of the present invention; and

[0026] Figure 3 is a sequence diagram that shows a process for reloading a token value to a source pocket, in accordance with an embodiment of the present invention.

[0027] In the component diagram like components use the same identification number. In the case of the sequence diagrams each step in the sequence is numbered consecutively. The following reference numbers are used:

[0028] 1 - User access device

[0029] 2 - Pocket controller device

[0030] 3 - Communications media

[0031] 4 - User Interface [0032] 5 - Authentication module

[0033] 6 - Token controller

[0034] 7 - Token store

[0035] 8 - Certification engine

[0036] 9 - Pocket stores

Detailed Description

[0037] Embodiments of the present invention and their technical advantages may be better understood by referring to the figures. For the purposes of the following description, the present invention is described by way of a representative embodiment in which users of the system create, send, receive and load tokens into their respective pockets. This example assumes that the users are natural persons. However, it will be understood that the present invention is equally capable of operation where either or both of the "users" are automated or semi-automated processes such as bots, software agents or the like.

[0038] Referring again to Figure 1, the value token system of the present invention generally comprises a user's device 1 and a pocket controller device 2 connected for communication through a communication medium 3.

[0039] The user's device 1 may be provided as any suitable combination of hardware and software capable of supporting a user's interaction with the pocket server 2 and other users, and includes a user interface 4 and an authentication module 5 A. In some embodiments, the user's device 1 may be provided as any of a mobile phone, a tablet, a PC or even a special device developed for the purpose.

[0040] The pocket controller device 2 may similarly be provided as any suitable combination of hardware and software capable of supporting interaction with multiple user's devices, and includes an authentication module 5B, a controller 6, a certification engine 8, a token log 7 for storing information about each token generated by the system and a nonvolatile pocket memory 9 for storing a plurality of pockets. In some embodiments, the pocket controller device 2 may be provided as one or more computers (including a computer cluster, a network of computers or a virtual computer running in a cloud environment) connected to the communications media 3.

[0041] The communications media 3, may be provided as any suitable combination of communications media capable of supporting messaging between user's devices 1 and the pocket controller 2. In some embodiments, the communications media 3 may include the public Internet.

[0042] Each person who participates in the value token transfer scheme is allocated one or more pockets which store the balance of their value tokens. Each pocket can store the same or a different currency depending on how the pockets were initially configured and ascribed to the user.

[0043] Users interact with the pocket controller device 2 through their user interface 4 on their device 1 which is configured with the user's credentials in such a way that when connecting through the communications media 3 to the pocket and token controller device 6 the authentication module 5 A on the user's device 1 can establish a trusted session with the authentication module 5B on the token and pocket controller device 2.

[0044] By means of this authenticated connection to the token and pocket controller device 2 the users can securely create and load tokens for the transfer of value or rights. It is understood that each token comprises a block of data that may be stored and transmitted by any suitable means including bar code images for example.

[0045] When the user wants to create a Token they make an authenticated request to the pocket controller device 2. In accordance with the present invention, the request may include a Personal Identification Number (PIN) value that is either selected by the user, a default value or a null value. Alternatively, the pocket controller device 2 may query the user to input or otherwise select a PIN value, for example as part of the token creation process. The controller 6 accesses the pocket memory 9 and checks the appropriate pocket relating to the

authenticated request and as long as the balance would remain positive after the transaction it creates the value token and adds a corresponding entry in the token log 7 while debiting the balance in the involved pocket by the value of the token. [0046] The controller 6 also interacts with the certification engine 8 that creates the cryptographic check sums necessary to protect the token. The token is preferably protected by two cryptographic check sums created in different security domains. In some embodiments, each cryptographic check sum may be created by a respective different certification engine 8 (for simplicity of illustration, only one Certification Engine 8 is shown in the drawings). In some embodiments, each certification engine 8 may be operated by respective different legal entities. This arrangement improves the security of the system by making it very difficult for a single entity (e.g. a hacker) to be able to create tokens or load value into any pockets. It is anticipated that in many cases the pocket controller device 2 will comprise one or more servers in the cloud, and these servers may be managed by a third party. The use of the dual cryptographic check sum avoids the obvious collusion attacks. It is part of the invention that the token can be further protected by the inclusion of the PIN value which is incorporated into either or both of the cryptographic check sum values. This is to improve the security and to make it very difficult for a third party who gains a copy of the token to be able to create or load value into their own pockets because they won't have knowledge of the PIN.

[0047] Having created the protected token the controller 6 passes it back to the user by means of the secure channel between the token and pocket controller device 2 and the user's device 1.

[0048] The user may choose to store this token for an arbitrary period of time at which point they may pass the token to a potential receiver of the token (a payee) by any suitable communications means such as email or a messenger application for example. It should be clear that at this point the sending user (the payer) may be off-line from the pocket controller device 2 and might pass the token to the payee by some local communication path such as Bluetooth to the receiver.

[0049] Depending on the situation and the degree of trust between the participants of the transaction, the payer may choose to send only one of the two cryptographic check sums to the payee with the token.

[0050] With this information the payee can load the value of the token into their pocket by connecting to the pocket and token controller device 2 using an authenticated channel through the communications media 3, and then interacting with the controller 6 to execute the load operation. The payee must also provide the correct PIN value, either with the token or subsequently during the load operation.

Upon receipt of the token, PIN, and (one) check sum, the controller 6 can use the check sum and the PIN to confirm the validity of the token and will change the token's status in the token log 7 to mark it as being assigned to the payee's pocket, but will not actually vest the value of the token in the pocket. The token value is not available to the payee, and cannot be spent by the payee, until it has been vested in the pocket by the controller 6. Once the controller 6 has successfully confirmed the validity of the token, the payee now knows the token is valid and can complete the transaction with the payer by, for example, the supply of goods and/or services. When the necessary conditions have been met, the payer can then send the second verification cryptographic check sum to the payee by any suitable communications method including for example email.

Once the payee has received the second verification cryptographic check sum, the payee can now complete the load process by connecting to the pocket server 2 by means of the authenticated channel over the communications media 3, and supplying the second token to the controller 6.

[0051] The controller 6 can then check the validity of the second verification checksum and if it is valid, the controller 6 can update the balance of the payee's pocket and mark the token as spent in the token log 7.

[0052] The transaction flow described above can be understood in more detail by referring to the sequence diagram of Fig 2, in which the term "TIB ADO" is an expression in the drawings that represents the token and pocket controller device 2. In this respect, it will be appreciated that most of the operations attributed to the token and pocket controller device 2 require the cooperative operation of multiple components including, but not limited to, the authentication module 5B, controller 6, certification engine(s) 8 and memories 7 and 9.

[0053] The process of Figure 2 begins at step S 1 , in which the payee makes a request of the payer for the transfer of a value token for, in this example, £5 [0054] At step S2, the payer establishes an authenticated connection to TIBADO using any suitable method, such as for example using TLS with a client certificate.

[0055] When the authenticated connection is established the payer makes a request (at step S3) to TIBADO to create a token with a value of £5 with a chosen PIN value. As noted above, this PIN value may be a value selected by the payer, a default value, or a null value. In a case in which the user-selected PIN is a default or null value, TIBADO may generate a new PIN value for the token.

[0056] Upon receipt of the request from the payer, TIBADO checks (at step S4) the balance of the payer's pocket and, if the requested withdrawal would leave a positive (or zero) balance in the payer's pocket decrements the pocket balance by £5, creates the value token and stores information about the token in the token log 7. The token information stored in the log 7 preferably includes at least the token ID and its value as well as the state of the token, (which at this time is "created") and the PIN. TIBADO then generates a at least one (and preferably two) cryptographic check sums. In embodiments in which only one cryptographic check sum is generated, the cryptographic check sum may form a Validation Certificate that is associated with the token. In embodiments in which two cryptographic check sum are generated, one of the cryptographic check sums may be embedded within (or attached to) the token, -while-the-other cryptographic cheek-sum-forms-a Validation Certificate associated- with the token. In some embodiments, the token information stored in the log 7 may also include one (or both) of the cryptographic check sums, but this is not essential. In all of these cases, at least one (and preferably both) of the cryptographic check sums includes the selected PIN.

[0057] In some embodiments, TIBADO will store a hash of the PIN in the token log 7, rather than the PIN itself. This allows subsequent verification of the PIN by TIBADO, but prevents a hacker from discovering the PIN by attacking the token log 7.

[0058] It is important to note that, while the PIN is included in at least one of the cryptographic check sums, it is not included in the data forming the token itself. This means that while the PIN is necessary for validation of the token (via the cryptographic check sums), there is no means by which the PIN can be discovered by analysis of the token. Consequently, an unauthorised party cannot validate the token (and so cannot load the token value into their own pocket) without also discovering the PIN.

[0059] In some embodiments, the process of generating the Token at step S4 is executed as an atomic database operation, in that it cannot be divided or interrupted during execution. This implies that the process is isolated from other processor function, which offers protection against some potential hacker attacks.

[0060] At step S5, TIBADO returns the token, its cryptographic check sums and, optionally, the PIN value to the payer across the authenticated channel. Sending the PIN to the payer may be appropriate in cases in which the token is created using a PIN selected by TIBADO, rather than the payer.

[0061] If desired, once the payer has received the token from TIBADO, the payer may (at step S6) end the Authenticated session with TIBADO.

[0062] At step S7, the payer sends the token to the payee. In embodiments in which the token is protected by two cryptographic check sums, only one of the cryptographic check sums may be sent to the payee at this time. In other embodiments in which the token is protected by only one cryptographic check sum, then the token may be sent to the payee without the cryptographic check sum. The PIN can be sent to the Payee by any agreed method such as text message, email, or the like. If desired, the PIN can be transmitted separately from the Token, for example at a different time or via a different mode of communication. In some embodiments, the payer and payee may previously agree upon a PIN value to be used for one or more subsequently-generated tokens. In this case, it is not necessary for the payer to send the PIN to the payee with the token.

[0063] At step S8, the payee establishes an authenticated connection to TIBADO, for example using TLS with a client certificate, and at step S9 requests the controller to load the token to the payee's pocket. The request will normally include the token and any check sum supplied by the payer. In some embodiments, the request may also include the ΡΓΝ.

Alternatively, TIBADO may request he PIN from the payee following receipt of the token and check sum. [0064] Upon receipt of the payee' s request (and the PIN), TIB ADO (at step S 10) checks the token log 7 to determine whether or not the status of the received token is still "created" (that is, it has not already been "loaded" or "spent" to another destination pocket) and that the cryptographic check sum is valid which must include the PIN. As may be appreciated, the first of these checks prevents the problems of "double spending" or duplication of tokens. If either of these checks fails, TIB ADO may reject the load request, and send a corresponding failure message to the payee. Otherwise, TIBADO changes the state of the token in the token memory 7 to show the status as "loaded", and also updates the token information in the log 7 to indicate the payee's pocket as the intended destination. The controller 6 may also ensure the integrity of the pocket and token memories by the use of additional cryptographic checksums as necessary and appropriate.

[0065] In some embodiments, the process of loading the Token at step S10 is executed as an atomic database operation, in that it cannot be divided or interrupted during execution.

[0066] At step S 11 , TIBADO sends a reply to the payee confirming that the token is valid and loaded to the payee's pocket but the value is not yet vested. The confirmation message may also request the payee to provide the Validation Certificate. If desired, the payee may end the authenticated session with TIBADO following receipt of confirmation that the token is valid.

[0067] At step SI 2, the payee communicates with the payer to request the Validation Certificate for the token that will validate or certify the transaction so that the token value can be vested in the payee's pocket.

[0068] At step SI 3, typically based on some agreed terms between the payer and the payee (for example the payer receives goods from the payee), the payer sends the validation certificate to the payee. As noted above, the validation certificate may take the form of a cryptographic check sum generated by TIBADO for the token.

[0069] The payee may then establish a new authenticated connection with TIBADO and send (at step SI 4) the validation certificate to TIBADO. Upon receipt of the validation certificate, TIBADO uses the validation certificate (at step S 15) to check the previously received token, and, if the validation check is successful, TIBADO vests the token in the payee's pocket by marking the appropriate entry in the token log 7 as showing the token's new state of "spent", and updating the balance of the payee's pocket by the value of the token. If the validation check fails, TIB ADO may reject the load request, and send a corresponding failure message to the payee.

[0070] In some embodiments, the process of vesting the Token at step S 15 is executed as an atomic database operation, in that it cannot be divided or interrupted during execution.

[0071] At step SI 6, TIB ADO sends a confirmation message to the payee confirming the results of the processing at step SI 5. In the event that the processes was successful, the confirmation message indicates that the token value (in this case, £5) has been added to the payee's pocket. At step SI 7, the payee may send a confirmation "thank you" message to the payer indicating that the transaction has been successfully completed.

[0072] The token controller may allow the payee a predefined number of attempts to load the token to their pocket, or alternatively may permit an unlimited of attempts. If the number of attempts to load the token is limited, then the token controller 6 must keep a counter to record these events.

[0073] It is also possible to allow the original creator of the token to be able to reload the token back into their own pocket. This operation may be used to override a situation in which where the payee cannot successfully load their token into their pocket (for example, the maximum number of load attempts by the payee has been reached). For this purpose, the token controller 6 may keep a record of which pocket was used to create the token.

[0074] FIG. 3 illustrates an example process for reloading a token in an event in which the payee does not successfully load their token. Referring to FIG. 3, at step SI 8, the payee sends a message to the payer indicating that they were unable to load their token. Following receipt of the message, the payer may (at step SI 9), establish an authenticated connection to TIB ADO using any suitable method, such as for example using TLS with a client certificate.

[0075] When the authenticated connection is established the payer makes a request (at step S20) to TIBADO to reload the token. In some embodiments, the reload request includes at least the token, and (optionally) the validation certificate. In this case, the PIN is not required. Upon receipt of the request, TIBADO checks the status of the token. If the token status is either "created" or "loaded" (that is, the token status is not "spent"), and if the token checksum is valid, then TIBADO can use the token ID to check the token log 7 and identify the source pocket from which the token was created. TIBADO can then operate to reload the token into the source pocket. One method by which this can be done is by resetting the destination pocket of the token to the source pocket, then incrementing the destination pocket by the token value and resetting the token status to "spent". This operation has advantages in that it uses the normal process for vesting token value in a pocket. This ensures that reloaded tokens can be audited using the same auditing and verification algorithms used to ensure integrity of all records in the token log 7.