WO2010007178A1

WO2010007178A1 - A token delivery system

Info

Publication number: WO2010007178A1
Application number: PCT/EP2009/059268
Authority: WO
Inventors: Martin Jones Strauch; Martin Sean Kelly
Original assignee: DIGITAL LOCKSMITHS Ltd
Current assignee: DIGITAL LOCKSMITHS Ltd
Priority date: 2008-07-17
Filing date: 2009-07-17
Publication date: 2010-01-21
Anticipated expiration: 2011-01-17
Also published as: WO2010007334A1

Abstract

In a known token distribution system the customer's computer must contain a program entrusted to provide security. Such a program can be interfered or manipulated with and the security information which the program contains can be extracted. Another problem is that the customer can only receive tokens via computers on which this program is installed. The problem is solved with a token distribution system comprising a token issuing system and a portable token container. The token issuing system transmits the token in the form of a data telegram which comprises the token, a unique identifier, a delivery number which is unique to each data telegram sent to the token container and a digital signature. The token container comprises means to verify from the unique identifier that the token is intended for that token container, from the delivery number that the token of that data telegram has not been saved onto the token container before, and from the digital signature that the data telegram has not be altered in any way since being sent from the token distribution system. If all of these checks are passed, the token is saved into the token container. By employing the invention it is possible for the token to be delivered by any transmission medium suitable for transmitting electronic data without the need to setup a secure network communication.

Description

[0001] A Token Delivery System

[0002] A known token distribution system is described in WO01/74031 in which a token is sent between two computers using secured networked communications. A problem with this arises that in order to provide security for the transmission for the token from the customer's computer into the token container the customer's computer must contain a program entrusted to provide that security. Such a program can be interfered or manipulated with and the security information which the program contains can be extracted. This extracted information can be used to fraudulently produce tokens. Another problem is that the customer can only receive tokens via computers on which this program is installed.

[0003] There are circumstances where it may be desired that the customer collects the token somewhere other than via the customer's computer or via a different transmission medium without using secured network communications. For example the customer might wish to request a train ticket by telephone and have it delivered to his smart card via Short Message Service (SMS). In another situation a customer requesting a token in the form of a travel pass may wish to be able to collect that pass at any one of many stations. Currently in some known distribution systems the customer has to report to specified station in order to collect the ticket.

[0004] It may also be desirable to send a ticket to a smart card which is not registered to the customer, e.g. where the ticket is bought as a gift for the use by another.

[0005] According to the invention there is provided a token distribution system comprising:

[0006] a) a token issuing system;

[0007] b) a portable token container comprising: a processor, and memory in which is recorded a unique identifier, a delivery number, cryptographic data and a program;

[0008] c) means by which a customer in possession of the portable token container can request the token from the token issuing system;

[0009] d) means in the token issuing system for identifying the unique identifier and delivery number of the customer's portable token container;

[0010] e) means in the token issuing system for responding to a request for a token by constructing a data telegram comprising: the token, the unique identifier, the delivery number and a signature, the signature being generated using cryptographic data being specific to the token container and held by the token issuing system

[0011] f) and means to send the data telegram to the portable token container and for changing the delivery number for the next data telegram to be generated for the token container;

[0012] the program in the portable token container being effective to

[0013] i) check the unique identifier in the telegram against that held in the memory; ii) check that the delivery number of a received data telegram does not match that of a previously received data telegram; iii) use the cryptographic data to verify the signature of the received data telegram; and iv) store the token in the memory.

[0014] By employing the invention it is possible for the token to be delivered by any transmission medium suitable for transmitting electronic data without the need to setup a secure network communication.

[0015] The system is suitable for transferring any electronic token that can be downloaded onto a token container. Possible tokens include, but are not restricted to: tickets, prescriptions, access control permissions, loyalty points and electronic cash.

[0016] The portable token container could take the form of a smart card, though the physical form is limitless in variation. It is important that the token container comprises means and/or has a physical construction to inhibit unauthorised access and amendment of data held on the card, in particular information associated with cryptographic functions. Communication with the token can be via a contact or contactless interface.

[0017] The means for retrieving the unique identifier and delivery number can be provided by the customer identifying himself in some way, e.g. by providing a username name or email address, whereupon the token issuing system looks up the identifier and delivery number from a database.

[0018] Alternatively the identifier and delivery number can be retrieved directly from the token container via a communication session with the token container. This option is not preferred, as unless the session is secured, there may be security risks if the unique identifier and delivery number and resultant data telegram were accessed by third parties.

[0019] The token is preferable encrypted using known encryption techniques.

[0020] The signature typically takes the form of cryptographically transformed data derived from the token, delivery number and unique identifier and appended to or otherwise associated with said token, delivery number and unique identifier.

[0021] The signature allows the program of the token container to verify the origin of the data telegram, and to verify that that token nor delivery number nor unique identifier have been altered since the data telegram was sent by the token issuing system.

[0022] Advantageously the invention allows for the token encryption and signature generation to be performed without reliance on conversing with the portable token container.

[0023] Although the data telegram is ultimately sent to the token container, a benefit of the invention is that this can be done via many possible routes for example, the internet, email, SMS, or to point of sale terminals or a combination or plurality of these.

[0024] The customer can request the token via a website; by phone, cellular or otherwise or a point of sale terminal.

[0025] Functions 'd' 'e' and T of the invention can be performed by a delivery agent managed by a commercial organisation providing a service to one or more merchants issuing their own unique tokens. In such an arrangement the customer will request a token from the merchant, the merchant will generate a token and forward it with identification of the intended recipient to the delivery agent.

[0026] The invention will now be described by way of example with reference to the figures in which:

[0027] Figure 1 is a schematic of a token issuing system; [0028] Figure 2 is a diagram showing the functions performed by the telegram generator of Fig 1 ;

[0029] Figure 3 is a flow chart showing functions performed by a program held in the token container of Fig 1 ;

[0030] Figures 4A to 4F are schematic representations of a memory of the token container holding delivery numbers.

[0031] Referring to Fig 1 there is shown a token distribution system comprising a customer's PC 1 with associated card reader 1A containing a smart card 1 B. The smart card 1 B has a processor, and memory in which is recorded a unique identifier, a delivery number, cryptographic data and a program. All as is conventional in a smart card 1 B except for the delivery number.

[0032] There is an initial registration process in which the customer provides his details and in turn are provided a smart card 1 B and possibly a card reader 1A and software used to interface with the card reader and smart card 1 B. This registration process is made with a smart card issuer 5.

[0033] A customer requires a train ticket. Using his PC 1 he connects to the website of a selected merchant 2 purchases a ticket, provides his identification and chosen means of delivery e.g. email, short message service (SMS). Payment is taken using conventional techniques. Hereinafter the ticket will be referred to as a token. The merchant 2 has a token generator 2A which receives information from the customer's request such as the points of departure and arrival, date and time of travel and uses this information to generate a token that contains that information in a cryptographically protected form. The merchant 2 then transmits a data telegram request containing the token, associated customer identification and requested mode of delivery by a connection 3, which could be internet, to a delivery agent 4 that acts on behalf of the merchant 2 and others 2'.

[0034] The telegram request is received by a delivery processor 4A which responds by accessing a database 4B. The database 4B contains a record for each customer, the record having been generated in after the registration of the customer with smart card issuer 5. Each record contains information specific to the customer's token container 1 B, namely i) the unique identifier of the customer's token container, ii) a delivery number, iii) cryptographic information; and iv) information specific to the customer including but not restricted to addresses in particular mobile phone number, email address and postal address.

[0035] The customer's token is passed to the telegram generator 4C together with the unique identifier of the customer's token container 1 B, the delivery number and the cryptographic information from database 4B. As shown in Fig 2 (route A), the token is encrypted using the cryptographic information to form a partly encrypted block of data which is then signed also using the cryptographic information to produce the data telegram. The whole process can be performed automatically using any one of many off the shelf programmed hardware security modules commercially available. There are various different cryptographic algorithms suitable for data encryption and data signing including those using principles as described in Applied Cryptography by Bruce Schneier (1994) (ISBN 0-0471-59756-2) published by Widely & Sons. Once such method would be in which both the token issuing system and the smart card 1 B are able to independently generate shared secrets used to encrypt and decrypt the token and to generate and verify the signature. Alternatively, the encryption stage may be omitted (route B) and a signature applied to the unique identifier, delivery number and token in unencrypted form. Even without the encryption stage, protection is still given by the combination of the identifier, delivery number and signature.

[0036] The delivery processor 4A then increments the delivery number held in the database 4B and transmits the data telegram to the customer's token container 1 B using the delivery mode specified in the data telegram request, in the particular illustrated case, an email sent to the PC. The previously mentioned software on the PC 1 adapted to interface with the card reader 1A and token container 1 B is used to download the data telegram into the token container 1 B. Such software can be easily produced by conventional methods.

[0037] The software held by the token container 1 B performs the functions of Fig 3. Firstly the unique identifier is checked at 3A that it matches that held by the token container 1 B. If this check is successful a further check is performed at 3B that the delivery number in the telegram is not the same as that any one previously recorded these being having been recorded at 3C. If this check is successful then the signature in the received data telegram is verified at 3D using the cryptographic data held by the token container 1 B. If this not successful the data telegram is rejected. If successful the delivery number is added 3E to the list at 3C. The data telegram is decrypted at 3F and. stored at 3G. Obviously where the telegram has not been encrypted, the decrypting step 3F is not necessary.

[0038] Instead of recording a list of all used delivery numbers at 3C there are many other ways in which it can be checked that the delivery of a received telegram does not match that of a previously received telegram. This is important to ensure that the customer cannot repeat the download so as to acquire duplicates of tokens when only authorised to receive one. In an alternative method a single delivery number could be held in the token holder and incremented/decremented on successful storage of a token at 3E in the same way and in synchronism with the incrementation used in the delivery agent database 4B. In a further alternative method the token container 1 B could contain a list of unused delivery numbers capable of being generated in the database 4B. This system would check that the delivery number of a received telegram matched that in the list.

[0039] In addition to checking that a received delivery number does not match a delivery number recorded as having been received, the system can identify a window of delivery numbers expected to be received in the near future and to reject telegrams having delivery numbers which do not fall within that window. In this way the system does not need to record every previously used delivery number, only the previously received delivery numbers within the aforementioned window, as the window can be shifted when a continuous block of received delivery numbers at the beginning of the window are recorded as having been received. This system also allows telegrams issued by the issuing system in a particular order to be downloaded onto the token container a different order. This arrangement is shown in Figures 4A - 4F. Fig 4A illustrates a portion of memory 3C of the token container 1 B used for storing the delivery number(s). In this example the memory 3C is sized to hold seven delivery numbers though this can be increased or decreased. Upon receipt by the token container of a telegram, the token container 1 B identifies the delivery number of the telegram and compares this with the delivery numbers held in memory 3C, as described above. In this example a telegram having delivery number Il is received, a check of the memory 3C indicates that no telegrams having this delivery number have been stored and so stores the token and marks that delivery number Il has been stored (Fig 4B). A second telegram having delivery number VII is received by the token container 1 B and the above process repeated (Fig 4C). Should any further telegrams having either the delivery numbers Il or VII be received, or any delivery outside the range I-VII, a check of memory 3C will result in the tokens contained within the later received telegrams being discarded. A third telegram having the delivery number I is received and again the above process repeated (Fig 4D). The system recognises that delivery number of at the beginning of the range (I and II) have been marked as received, shifts the range of delivery numbers held within the memory so as to begin with the next delivery number which has not been received, in this case III (Fig 4E).

[0040] In an alternative embodiment, the generated telegram can be returned to the merchant for distribution to the customer. In such a case the database 4B does not need to contain addresses. The customer can retrieve the telegram from the website.

[0041] The system may also include means in the token request to accept a specific address for delivery of the telegram rather than a requested mode of delivery. This would obviate the need for the customer record to hold specific addresses relating to the customer.

[0042] The system may be provided with means to send a token to a token container which is not owned by the customer. This would enable to the token to be purchased by a customer as a gift, or where one customer is buying multiple tokens for use by different people with their own token containers.

Claims

1. A token distribution system comprising: a) a token issuing system; b) a portable token container comprising: a processor, and memory in which is recorded a unique identifier, a delivery number, cryptographic data and a program; c) means by which a customer in possession of the portable token container can request the token from the token issuing system; d) means in the token issuing system for identifying the unique identifier and delivery number of the customer's portable token container; e) means in the token issuing system for responding to a request for a token by constructing a data telegram comprising: the token, the unique identifier, the delivery number and a signature, the signature being generated using cryptographic data being specific to the token container and held by the token issuing system and f) means to send the data telegram to the portable token container and for changing the delivery number for the next data telegram to be generated for the token container; the program in the portable token container being effective to i) check the unique identifier in the telegram against that held in the memory; ii) check that the delivery number of a received data telegram does not match that of a previously received data telegram; iii) use the cryptographic data to verify the signature of the received data telegram; and iv) store the token in the memory.

2. A token distribution system according to claim 1 wherein the token issuing system has a database which holds the unique identifier of the token container and the delivery number.

3. A token distribution system according to claims 1 or 2 comprising means in the token issuing system and in the portable token container for independently generating a shared secret.

4. A token distribution system according to any previous claim comprising means effective to encrypt any of the token, unique identifier or delivery number before the signature is generated

5. A token distribution system according to any previous claim wherein the functions of d), e) and f) of claim 1 are performed by a delivery agent capable of delivering tokens issued from multiple merchants.

6. A token distribution system according to any previous claim comprising means to increment or decrement the delivery number held by the issuing system upon sending a data telegram.

7. A token distribution system according to claim 6 wherein the program comprises means to increment or decrement the delivery number held in the token container on successful storage of a token, and in synchronism with the incrementation/decrementation of the delivery number held by the issuing system.

8. A token distribution system according to any claim 1-6 wherein the program is adapted to identify a window comprising a selected range of delivery numbers of telegrams expected to be received by the token container, and only stores telegrams having a delivery number which falls within that window.

9. A token distribution system according to Claim 8 wherein the program has means to identify that one or more consecutive delivery numbers at the beginning of the window are associated with telegrams which have been received by the token container and stored in the memory, and to reselect the range of delivery numbers of telegrams expected to be received by the token container.

10. A portable token container according to any previous claim.

11. A token issuing system according to any previous claim.