WO2010007334A1

WO2010007334A1 - Secure delivery of electronic tokens

Info

Publication number: WO2010007334A1
Application number: PCT/GB2008/050582
Authority: WO
Inventors: Martin Strauch; Martin Kelly
Original assignee: Digital Locksmiths Ltd.
Priority date: 2008-07-17
Filing date: 2008-07-17
Publication date: 2010-01-21
Also published as: WO2010007178A1

Abstract

This invention provides a mechanism for the secure, remote delivery of electronic tokens to a Customer's Token Container without the need for delivery-time access to security modules or other cryptographic processes. By separating the generation of secure tokens from the means of delivery and storage, the invention provides a general solution to the delivery of tokens to a Customer's Token Container. This mechanism provides flexibility without compromising security. The architecture and mechanisms that constitute this invention are not restricted to the delivery of a specific type of token or a specific scheme, nor do they depend on the transmission media employed in distributing them.

Description

SECURE DELIVERY OF ELECTRONIC TOKENS

Technical Field

[1] The invention relates to the remote download of electronic tokens to a Customer's

Token Container.

[2] Within the UK there exists a nationally approved standard for smart card based interoperable ticketing (ITSO). The provisions of the ITSO Specification make it difficult to securely deliver tickets to Customer Media that are not in close proximity to the mandatory security module.

[3] This invention describes a mechanism for delivering tokens securely without the need for delivery-time access to security modules and maintains compatibility with existing system components.

[4] In solving this problem the invention provides a general solution to similar problems of token delivery to a user's smart card, or similar Token Container. This mechanism provides flexibility without compromising security.

[5] The applicability is not restricted to ITSO schemes. Similar system architectures as those specified by ITSO are found in many unrelated schemes; for example loyalty cards. It is also expected that as NFC technology matures similar problems will benefit from methods of this invention. Background Art

[6] Delivery of ITSO tickets over the internet is not new. Public demonstration of this technology occurred at the MovingOn conference in 2003 on Cornwall County Council's stand. WO2005111953 ' IMPROVED TICKETING SCHEME' 2005, describes the same. This solution requires access to remotely hosted SAMs via a network and secure real-time communications between the IPE Retailer and the Customer. These implementations depended on an ISAM- Array at the server side and intelligent terminal software at the client side, used to access the Customer Media. The invention described herein does not require any of these features and is secure from hacking at the client terminal. The latter could be considered as a insurmountable problem with these prior art proposals, precluding adoption of those solutions in many scenarios.

[7] Delivery of ITSO tickets via a 'back door' is addressed in WO2006/010913

'REMOTE SMARCARD APPLICATION' 2006 whereby a Customer Media's data may be updated and the internal security cross references simultaneously maintained. These topics were also widely discussed within ITSO's Integrator's forum with similar proposals for GSM SMS delivery to cards or NFC enabled phones: in May 2003. In these scenarios, Customer Media update and Customer Media usage is via two distinct channels. This invention uses such methods but makes no claim as to inventive steps regarding the method whereby products are added to the Customer Media .

[8] The EMV card personalization specification (EMV Card Personalization Specification, v 1.1, EMVCo, LLC), uses a mechanism for enabling personalization data to be pre-calculated and delivered to cards without need of a real-time cryptographic secure session. In this scenario assumptions can be made regarding the card's choice of seed data for the secure session thereby enabling the data generator to predict the card's responses and to generate encrypted inbound data so as to match the card's expectations; in effect generating a script that may be played to a card at a later date without further reference to the data generator. This invention does not require a secure session and achieves similar results without the need to add predictability to the card's session key generation. Disclosure of Invention Technical Problem

[9] Currently the process of loading a product onto an ITSO card involves a POST (1) that contains an ISAM (2). The ISAM contains many keys, installed at the discretion of the Product Owners and the Scheme Operator, which enable it to both manage IPEs (create and modify) and to register those IPEs with the Customer Media (3) via a directory that is universally verifiable.

[10] Coordination of this process is managed within the POST which must contain an

ISAM (or have real time access to an ISAM). Vulnerability still remains in that the ISAM(2), CM(3) and Scheme Players (4) form a trusted relationship via the POST'S (1) Trusted Processing Logic (5). A compromised POST will break that trust. This problem is particularly acute for internet delivery mechanisms as discussed in the prior art section of this paper.

[11] In the scenario shown in Figure 1 the Retailer has possession of the POST (1). He uses it to deliver products to the Customer's CM and to account for his transactions back to the Scheme Players (4) via a network.

[12] Figure 2 shows the current utilization of this technology in an internet retail environment.

[13] In this scenario the Web Retailer (6) delivers products via the internet (7). The

Trusted Processing Logic (5) typically executes on the Customer's machine (or a publicly accessible machine e.g. at an internet cafe). The Web Retailer requires access to an ISAM to register the newly products within the Customer Media's memory (known as Directory signing in ITSO). The risk in this scenario is that a compromised Trusted Processing Logic may have access to ISAMs and use them for unspecified purposes. Alternatively it may record and store information relating to the Customer's CM that could be used to effect unauthorized modifications to the same card at a later date.

Technical Solution

[14] The invention provides end-to-end security, from the Delivery Agent to the Intelligent Customer Media. This is essential for the secure download of tokens in distributed environments where the client-side applications cannot be trusted. The disadvantages of both of the above scenarios are removed by this invention.

[15] Figure 3 shows the logical sequence of events and the following text describes their roles and responsibilities.

[16] In this architecture the Remote Retailer (8) interacts with the Customer via the point of sale (9). The point of sale may be a website, a telephone call or any other such buyer/seller interface. In situations where the Remote Retailer cannot access the Customer's media, it will be necessary for Customers and their media details to be pre- registered and held within the optional database (13). This is not considered to be a limitation as we expect such Remote Retailers to want to know their Customers, perhaps even issuing the Intelligent Customer Media (12) to them.

[17] When the Remote Retailer (8) receives a commitment to buy a product he may construct the appropriate IPE via traditional ITSO mechanisms utilizing his retail ISAM (2). He is responsible for reporting his activity to the Product Owners in exactly the same way a POST communicates with the Scheme Players (4).

[18] The next action he performs is the subject of this invention. The well formed product

IPE is not immediately delivered to the Customer Media as would be expected in traditional ITSO operations. Instead the IPE is passed to a Delivery Agent (11).

[19] The Delivery Agent (11) has a unique role with the Shell Owner (14). The Delivery

Agent encapsulates the IPE in a Data Telegram that is passed to the Customer Media via any of a number of mechanisms such as internet delivery, GSM-SMS or others. Unique properties of the Data Telegram prevent it from being re-used thus it is possible to send the Data Telegram repeatedly without fear of generating duplicate products on the Customer Media.

[20] The Intelligent Customer Media (12) is capable of accepting a Data Telegram and absorbing the IPE into it's portfolio of valid IPEs. The intelligence in the Customer Media is used to verify the Data Telegram, to ensure the uniqueness of the delivery and to update the relevant inventory of stored IPEs. The manner by which this may be achieved is described later in this document.

[21] By using this architecture the integrity of the IPEs and the ITSO scheme cannot be endangered by compromised Trusted Processing Logic (5). Thus remote retail of IPEs does not expose ITSO secrets whatever the nature of the delivery mechanism.

[22] By using this architecture an IPE may be simultaneously delivered to multiple locations at which the Customer is likely to present his Customer Media, without the risk of delivering the IPE to the Customer Media more than once.

[23] The mechanisms, described later, that enable the safe and secure delivery of IPEs also provide the facilities to securely and simply manage the Customer Media within a normal usage environment. This has the potential to significantly speed up and simplify the responsibilities of the POSTs. In particular, the storage and reconstruction of IPEs, the accurate management of the 'Directory', and the need to cater for 'tearing' or incomplete transactions are all simplified and properly secured.

[24] The process can be implemented without needing to enhance ITSO's existing ISAM architecture. In doing so it is also possible to upgrade existing ITSO deployments to remove the vulnerabilities inherent in the current architecture. However, as the process only requires that the IPE is correctly formed by the Remote Retailer, it also provides for the use of a Hardware Security Module, rather than an ISAM, which would enable greater security and faster processing of products (though this mechanism is not currently supported by ITSO).

[25] The architecture and mechanisms that constitute this invention are not restricted to the ITSO environment, nor do they depend on the transmission medium employed in distributing tokens.

[26] Detailed Description of the Key Components

[27] The invention is achieved via the interaction of three components:

[28] 1. The Delivery Agent (11)

[29] 2. The Data Telegram

[30] 3. The Intelligent Customer Media (12).

[31] These are described collectively then individually below.

[32] Combined Requirements

[33] The Delivery Agent and the Intelligent Customer Media share a delivery master key set. Note separate keys may be used to encrypt and to sign the contents of the telegrams. Data Telegrams are encrypted/signed by the delivery keys that are derived from master keys.

[34] Delivery Agent

[35] A Delivery Agent exists for each Shell Owner who permits this remote download capability.

[36] On behalf of its associated Shell Owner the Delivery Agent maintains a Delivery

Number for each Data Telegrams generated for each individual Intelligent Customer Media. The Delivery Number is unique for each distinct Data Telegram: the simplest implementation of this feature would be a counter.

[37] This Delivery Number is used to diversify the delivery master key. The resulting delivery keys are used to cryptographically protect the Data Telegram that is to be delivered to the Intelligent Customer Media. [38] Data Telegram

[39] The Data Telegram contains three major components, i) Identification information: this will be clear text identifying the recipient Intelligent Customer Media and the Delivery Number, ii) The IPE payload: this is the product that is to be loaded into the Intelligent Customer Media. It is included verbatim, as generated by the Remote Retailer. It may be encrypted, iii) A cryptographic signature of all of the Data Telegram's contents. This is used to verify the integrity and authenticity of the Data Telegram, enabling the Intelligent Customer Media to accept or decline the delivery.

[40] The Data Telegram may be delivered verbatim to the customer media via a bespoke command. The terminal that delivers the Data Telegram does not need to perform any processing on the Data Telegram other than to receive it from the Delivery Agent and to deliver it to the Intelligent Customer Media. In particular it is not trusted to perform any processing on the Data Telegram: it is only required to forward the Data Telegram to the Intelligent Customer Media. If the contents of the Data Telegram are tampered with in any way (either by accident or maliciously), then this will be detected by the Intelligent Customer Media as it performs its verification procedures.

[41] The incorporation of the Delivery Number allows the Intelligent Customer Media to reject repeated attempts to download a token that has already been loaded and provides additional security for the encryption/signing of the Data Telegram.

[42] Data Telegrams may be constructed as multiple data packets to simplify delivery over some communication media.

[43] Intelligent Customer Media

[44] Two features of the Intelligent Customer Media are essential for its operation, i) It needs to share the card master keys known to the Delivery Agent. See below for a possible key hierarchy, ii) It needs to know the unique key used for sealing directories on this particular instance of Customer Media. ITSO specify the derivation of this key.

[45] A possible delivery key hierarchy is the following:

[46] 1. Scheme master keys = top secret

[47] 2. CM master keys are unique to each Intelligent Customer Media and may be derived from the Scheme master keys and the media's unique identifier - in ITSO terms this is the ITSO Shell Reference Number (ISRN).

[48] 3. Data Telegram delivery keys are unique per Data Telegram and are derived from the Customer Media master keys and the Delivery Number.

[49] The Intelligent Customer Media will also provide a command interface that permits a terminal to deliver a Data Telegram. This interface will accept a Data Telegram; verify that the Delivery Number is as expected; verify the signature and possibly decrypt an encrypted IPE payload. Assuming all of the checks pass successfully, the IPE will be added to the Intelligent Customer Media's inventory of valid IPEs.

[50] In order to announce the existence of the new IPE to ITSO POSTs the Intelligent

Customer Media must be capable of signing the directory information delivered to a POST during normal operation; hence the need for the media to know its own directory signing key. The signing process is performed using the ITSO Directory sealing key, which is held by the Intelligent Customer Media.

[51] Extending the Behaviour of the Intelligent Customer Media

[52] The mechanisms described could provide a 'back door' delivery mechanism to media that present a 'front door' that is 100% compatible with ITSO's existing media definitions for Generic Micro-Processor, DesFire and Calypso.

[53] Alternatively the Intelligent Customer Media could exhibit an entirely new API that is optimized for ITSO operations and significantly simplifies and speeds up an ITSO transaction. Here we briefly outline such an interface.

[54]

[Table 1] [Table ]

[55] This interface facilitates vastly improved security without the need to use a secure messaging mechanism.

[56] Improved speed is to be expected as the communication overhead is reduced by the

Intelligent Customer Media taking responsibility for data storage and retrieval strategies. The requirement for the ISAM to be involved in secure messaging is also removed, further reducing the time required to complete a secure transaction.

[57] The proposed mechanism may be implemented in a JavaCard or a Multos card for flexibility and to permit co-existence with other card applications. It also has enough unique features and benefits to justify a bespoke mask implementation to reduce cost or optimize transaction processing speeds.

[58] Application to the Distribution of Generic Tokens

[59] The mechanism described here makes use of the ITSO architecture, but it is equally applicable to the secure distribution of any electronic token with an intrinsic value that requires protection, particularly for environments where the client-side terminal cannot be trusted.

[60] In a more generic scenario, the token is distributed in the cryptographically protected form of a Data Telegram to a secure Token Container. The content of the token and the type of transmission medium are not relevant to the secure mechanism described above for distributing the token to the container.

[61] Glossary [Table 2] [Table ]

Advantageous Effects

[62] The advantageous effects of the invention are the following:

[63] 1. It does not depend on a real-time interaction between the Remote Retailer/Delivery

Agent and the Customer's Token Container: the Data Telegram is sent to one or more locations (physical and/or virtual), where it is held until it can be downloaded to the

Customer's Token Container . [64] 2. It is not dependent on the transmission medium between the Delivery Agent and the Customer's Token Container: any medium suitable for transmitting the electronic Data Telegram can be used.

[65] 3. The security of the mechanism is encapsulated in the Data Telegram: the Data

Telegram cannot be modified, replayed or utilized by a Token Container for which it was not intended.

[66] 4. The mechanism is not dependent on the security of the client processes responsible for downloading the received Data Telegram to the Token Container: the security is a feature of the Data Telegram itself.

[67] 5. The mechanism is suitable for use with any electronic token that is downloaded onto a Customer's Token Container: possible tokens include, but are not restricted to, tickets, prescriptions, access control permissions, loyalty points and electronic cash. Description of Drawings

[68] Figure 1 illustrates the conventional ITSO transaction architecture, whereby the customer media is present at the retailer's POST. The transaction is protected by secure messaging facilitated by the ISAM located in the retailer's POST. The security is dependent on the immediate proximity of the ISAM and the trusted functionality of the POST

[69] Figure 2 illustrates a possible remote transaction architecture for ITSO, making use of the current architectures and mechanisms. The transaction is again secured by secure messaging with an ISAM, though in this case the ISAM is remote from the Customer's media. The secure messaging requires a real-time exchange of messages between the ISAM and the Customer's media. The security of this process is dependent on trusting the client-side functionality: the software implementing this functionality is hosted on the Customer's machine and is vulnerable to hacking.

[70] Figure 3 shows the architecture using the mechanism provided by the invention. The token is generated by the Retailer and is sent to the Delivery Agent for distribution to the Customer's media. The transmission medium is not relevant to the delivery of the secured token (the Data Telegram); indeed the Data Telegram may be sent to multiple locations where it might be accessed by the Customer's media. The Data Telegram can then be loaded into the Customer's media without requiring any communication with the Delivery Agent or the retailer. The security of the process is built into the cryptographic protection given to the Data Telegram by the Delivery Agent and verified/ authenticated by the Intelligent Customer Media. Best Mode

[71] It is a fundamental feature of the invention that it is applicable to any type of electronic token and any form of medium suitable for transmitting the Data Telegram.

[72] The Delivery Agent must have access to cryptographic keys that are present on the customer's Token Container: these are used to secure the contents of the Data Telegram.

[73] The Token Container itself must have the ability to process the cryptographic functions required to verify the integrity and authenticity of the Data Telegram, and to prevent the replay of tokens: this functionality is required in addition to the Token Container's ability to securely store and manipulate tokens as required by the appropriate scheme.

[74] One example of the Best Mode would be the generation of the Data Telegram making use of the cryptographic functions provided by a Hardware Security Module; delivery of the Data Telegram via the internet to a customer's PC, which has a reader attached to it; the Data Telegram is downloaded onto a smart card via the reader.

[75] The interaction between the Remote Retailer, the Delivery Agent and the Customer

(and the Customer's Token Container) is illustrated in Figure 3.

[76] Note that in this example of the Best Mode, the transmission of the Data Telegram could be via SMS with the PC replaced by a mobile phone with access to a smart card. Mode for Invention

[77] The invention can be applied to the secure, remote download of ITSO ticketing products to Customers' media. In this more, the Retailer constructs the ticketing product in a conventional ITSO manner. The Delivery Agent makes use of a Hardware Security Module to cryptographically protect the Data Telegram, incorporating media specific information that restricts the download of the Data Telegram to a single load onto a particular Token Container. The Customer's media is an instance of the Intelligent Customer Media - a JavaCard applet hosted on a JavaCard smart card platform. Industrial Applicability

[78] The invention is applicable to the secure, remote download of electronic tokens to

Customers' Token Containers.

[79] It is particularly relevant to the delivery of tickets, providing a secure mechanism for the remote distribution of ITSO products that complements the local transaction mechanism defined in the current ITSO Specification. This application of the invention is illustrated in Figure 3. Sequence List Text

[80] Not applicable.

Claims

[1] A mechanism that secures the transmission of tokens across a distributed network from a Remote Retailer to a Customer's Token Container, this mechanism provides end-to-end security that is not dependent on a client-side application and does not require a real-time transaction between the Token Container and the system responsible for generating the token.

[2] The design of a Data Telegram that is delivered to the Token Container, which is generated so that the Token Container does not require interaction with the Remote Retailer or their systems.

[3] The mechanism is not dependent on the transmission mechanism; the end-to-end security is encapsulated in the Data Telegram by the Delivery Agent and is verified by the Token Container - the transmission of the Data Telegram need not be secured.

[4] The mechanism is suitable for transmission of Data Telegrams via the internet,

GSM SMS networks or via a dedicated network to dedicated terminals (for example ticketing terminals or gates ).

[5] While providing a generic solution, the mechanism could be made specific to any given transmission medium, tying in the implementation to features of the transmission medium.

[6] The mechanism allows the Data Telegram for a single token to be transmitted to a number of locations where it might be received by the Token Container; the Data Telegram provides protection against the repeated download of the token, and after being loaded for the first time, the Token Container will reject any replay of the Data Telegram.

[7] The mechanism is directly applicable to ITSO Schemes for the remote delivery of ITSO ticketing products (IPEs) without modifying the ISAM architecture; the invention provides a secure upgrade path for the implementation of remote transactions without requiring modification to the ITSO environment.

[8] A design for a Token Container (the Intelligent Customer Media) that provides the functionality required to secure remote transactions and also provides the functionality required to simplify and enhance the security, while reducing transaction times, of standard ITSO transactions performed in conjunction with an ITSO POST/ISAM.

[9] A scheme for securing the remote distribution of electronic tokens including, but not restricted to, tickets, prescriptions, access control permissions, loyalty points and electronic cash.

[10] A method for separating the logical functions of the creation and the delivery of tokens that have been customized for, and are specific to, identified Token Containers: generation is possible in the absence of the token carrier; delivery is performed in the absence of the token generator. [11] A method, scheme or system according to any preceding claim in which the

ISAM is replaced with one or more Hardware Security Modules that can be associated with a plurality of terminals for the generation and distribution of IPEs and the Data Telegrams used to secure the transmission of the IPEs.