WO2015162276A2

WO2015162276A2 - Secure token implementation

Info

Publication number: WO2015162276A2
Application number: PCT/EP2015/058981
Authority: WO
Inventors: Jaimie ABRIL DOVALO; Rebecca HIGLEY; Cristina VINTILA; Nikolai Strasding; Selin ÖZSOY; Sebastiaan Hoeksel
Original assignee: Vodafone IP Licensing Ltd
Current assignee: Vodafone IP Licensing Ltd
Priority date: 2014-04-24
Filing date: 2015-04-24
Publication date: 2015-10-29
Anticipated expiration: 2016-10-24
Also published as: WO2015162276A3

Abstract

To ensure security of token provision to a user device, token request by (or on behalf of) the user device, token generation at a token service provider and token provision from the token service provider each make use of data stored within a secure element, SE, of an SE module of the user device. Tokens are generated in dependence on the obtained data: storage and communications of the tokens are also secured using the obtained data. Advantageously, the data required to generate a token request is securely stored on a user device itself and not a server remote from the user device.

Description

SECURE TOKEN IMPLEMENTATION

Field of the Invention

The present disclosure relates to a method for improving the security of tokens used in transactions by user devices. More particularly, embodiments of the present disclosure improve the security of generation, provisioning and storage of tokens for use in token based transactions. According to embodiments, the use of tokens is dependent on data stored in the secure element of a user's device. Advantageously, security is improved over known techniques.

Background to the Invention

Chip card technology for payments is well established. Problems experienced by chip cards include the cards being vulnerable to fraud in e-commerce and card not present transactions. The required data for performing such transactions are the user's Primary Account Number, PAN, the expiry data and CVV, and all of this data is printed on the card. In addition, the cards are limited to having a single purpose.

There has therefore been a lot of interest in replacing payments by chip cards with user devices, such as mobile telephones, that are able to function as payment devices in addition to providing other services. Important for the effective implementation of payments by such user devices is ensuring the security of sensitive personal data during transactions. In particular, the transfer of the payment data from the user device to a merchant's point-of-sale terminal and then to the issuer host needs to be robust. A known technique for improving the security of personal data in a payment system is to use tokens. Tokens are surrogate values that are used instead of personal data, such as a user's PAN. Tokens may be used for implementing payment transactions as well as non-financial purposes, such as loyalty tracking. An advantage of using tokens is that the potential loss due to malicious activity is greatly reduced. For example, a token may be limited to use with a specific merchant, use in a specific country or use within a predetermined time period. Tokens may also be limited to just a single use. The potential loss resulting from the loss of a token with such use restrictions is less than that of fraudulent chip card payments that can be made in an almost unrestricted manner until the fraudulent activity has been detected and the functioning of the chip card stopped. Accordingly, even if a token is intercepted when it is transferred from a user device to a point-of sale terminal, the potential loss is greatly reduced. The provisioning and using of tokens is described in EMV Payment Tokenisation Specification, Technical Framework, Version 1 .0, March 2014, the entire contents of which are incorporated into the present document by reference. Tokens are generated by a token service provider, which is remote from a user device, and transmitted to the user device. The token service provider generates payment tokens for a particular user in response to receiving a token request. The token request comprises personal data of the user, such as the user's PAN and its expiry date. The token service provider performs an identification and verification, ID&V, check on the received personal data in the token request and then generates tokens in dependence on the provided data in the token request.

Known token systems are implemented by Host Card Emulation, HCE, solutions. In HCE solutions, the user device is capable of emulating a chip card with token data stored in the user device. The token system has a server that is remote from both the user device and the token service provider. In order to obtain tokens to make payments, the user first needs to register his card details, which contain personal data, such as PAN, expiry date, etc., with the remote server. The server stores the personal data and uses it to request tokens from the token service provider every time tokens are needed.

A number of problems are experienced by the above-described operation of a token system.

A user's personal data is stored by the remote server. The user therefore has less control over their personal data as the personal data has been provided to a third party and malicious activity may result in personal data being stolen from the third party's server.

In addition, obtaining data from a remote server in order to generate a token request is a slow process that can only be performed when the user device has network connectivity. This results in a poor user experience.

Malicious activity may also result in tokens being intercepted when the tokens are transmitted to the user device, or tokens that are stored in the user device being retrieved from the user device. The obtained tokens may then be fraudulently used in transactions. In order to limit the potential loss due to the lack of security, both the value of tokens, and the number of tokens that can be generated in response to a token request, are restricted. In addition, or alternatively, a validation through a PIN may be requested every time a token is used. These again result in a poor user experience.

Accordingly, known implementations of tokens by user devices experience a number of problems.

Summary of the Invention

According to a first aspect of the present disclosure, there is provided a method for providing a token for use in a transaction to a user device, the method comprising a server: obtaining identification data of a secure element, SE, module that comprises an SE of a user device; generating a token for use in a transaction; and transmitting the token to the user device; wherein the server is remote from the user device; and the token is generated in dependence on the identification data. Preferably, the generated token is for paying for a transaction and is for use in one or more systems and methods according to an EMV Payment Tokenisation Specification.

Preferably, the method further comprises retrieving the identification data from the SE of a user device; and transmitting the identification data to the server.

Preferably, the method further comprises receiving the token by the user device; and storing the received token in the SE.

Preferably, the method further comprises using the token in a transaction by transferring the token from the user device to a remote terminal.

Preferably, the token is transferred to the terminal by transmitting the token using at least one of near field communication, Bluetooth or WiFi. Preferably, the token is transferred to the terminal by: generating a computer readable code in dependence on the token; displaying, on a display of the user device, the computer readable code; and reading, by the terminal, the displayed computer readable code.

Preferably, said step of obtaining identification data is performed in response to a determination that a token is required. Preferably, the server generates the token further in dependence on a primary account number and/or expiry date.

Preferably, the identification data comprises an integrated circuit card identifier.

Preferably, the user device is a mobile telephone or a mobile computing device.

Preferably, the SE module is a smart card of the user device. Preferably, the SE module is a subscriber identification module, SIM, of the user device,

According to a second aspect of the present disclosure, there is provided a server for providing a token for use in a transaction to a user device, wherein the server is configured to perform the method of a server as set out in the first aspect.

According to a third aspect of the present disclosure, there is provided a user device for using a token in a transaction, wherein the user device is configured to perform the method of a user device as set out in the first aspect. According to a fourth aspect of the present disclosure, there is provided a system comprising the server of the second aspect and the user device of the third aspect.

According to a fifth aspect of the present disclosure, there is provided a method for authenticating a token request, the method comprising a server: receiving a token request from a user device, wherein the token request comprises identification data of an SE module comprised by the user device and data for use in generating one or more tokens for use by the user device; and authenticating the token request in dependence on the received identification data.

Preferably, the one or more tokens for use by the user device are tokens for paying for a transaction and for use in one or more systems and methods according to an EMV Payment Tokenisation Specification.

Preferably, the data for use in generating one or more tokens comprises a primary account number and/or expiry date. According to a sixth aspect of the present disclosure, there is provided a server for authenticating a token request, wherein the server is configured to perform the method of a server as set out in the fifth aspect. According to a seventh aspect of the present disclosure, there is provided a method for generating a token for use in a transaction by a user device, the method comprising a token generator: obtaining data stored within a secure element, SE, of an SE module of a user device; and generating a token in dependence on the obtained data.

Preferably, the generated token is for paying for a transaction and is for use in one or more systems and methods according to an EMV Payment Tokenisation Specification. Preferably, all of the processes performed by the token generator to generate a token are performed within the SE of the user device.

Preferably, the processes performed by the token generator to generate a token are partially performed within the SE of the user device.

Preferably, said process of generating a token is performed by a server remote from the user device; the method further comprising: transmitting, by the user device, the obtained data to the server; and transmitting, by the server, the token to the user device. Preferably, the method further comprises storing the token in the SE.

Preferably, the method further comprises using the token in a transaction by transferring the token from the user device to a remote terminal. Preferably, the token is transferred to the terminal by transmitting the token using at least one of near field communication, Bluetooth or WiFi.

Preferably, the token is transferred to the terminal by: generating a computer readable code in dependence on the token; displaying, on a display of the user device, the computer readable code; and reading, by the terminal, the displayed computer readable code.

Preferably, said step of obtaining data is performed in response to a determination that a token is required. Preferably, the obtained data comprises one or more of identification data of the SE module, a primary account number and an expiry date of a primary account number. Preferably, the identification data is an integrated circuit card identifier.

Preferably, the user device is a mobile telephone or a mobile computing device. Preferably, the SE module is a smart card of the user device.

Preferably, the SE module is a subscriber identification module, SIM, of the user device.

According to an eighth aspect of the present disclosure, there is provided a user device for generating a token for use in a transaction, wherein the user device is configured to perform the method of a user device as set out in the seventh aspect.

According to a ninth aspect of the present disclosure, there is provided a server for providing a token for use in a transaction to a user device, wherein the server is configured to perform the method of a server as set out in the seventh aspect.

According to a tenth aspect of the present disclosure, there is provided a system comprising the server of the ninth aspect and the user device of the eighth aspect. According to an eleventh aspect of the present disclosure, there is provided a method for generating a cryptogram for use with a token for performing a transaction by a user device, the method comprising a user device: obtaining data stored within a secure element, SE, of an SE module of the user device; and generating a cryptogram in dependence on the obtained data. Preferably, the generated cryptogram is for use as a token cryptogram for providing a transaction-unique value and is for use in one or more systems and methods according to an EMV Payment Tokenisation Specification.

Preferably, all of the processes performed to generate the cryptogram are performed within the SE of the user device.

Preferably, the processes performed to generate the cryptogram are partially performed within the SE of the user device. Preferably, the generated cryptogram is unique. Preferably, the generated cryptogram is generated further in dependence on a token obtained by the user device.

Preferably, the method further comprises storing the generated cryptogram in the SE.

According to a twelfth aspect of the present disclosure, there is provided a method of generating transaction data by a user device, the method comprising the user device: obtaining a token for use in a transaction; generating a cryptogram according to the method of the eleventh aspect; and generating transaction data that comprises the cryptogram and the token.

Preferably, the token is generated by the user device.

Preferably, the token is generated at a server that is remote from the user device; and the method further comprises transmitting, by the server, the token to the user device.

Preferably, the method further comprises storing the token in the SE.

Preferably, the method further comprises transferring the transaction data from the user device to a remote terminal in order to use the token in a transaction.

Preferably, the transaction data is transferred to the terminal by transmitting the transaction data using at least one of near field communications, Bluetooth or WiFi.

Preferably, the transaction data is transferred by: generating a computer readable code in dependence on the transaction data; displaying, on a display of the user device, the computer readable code; and reading, by the terminal, the displayed computer readable code.

Preferably, the obtained token and cryptogram are generated in dependence on the same data. Preferably, the method further comprises authenticating, by the terminal, the token for use in a transaction in dependence on a determination that the token and cryptogram were both generated in dependence on the same data.

Preferably, said obtained data stored within a SE comprises one or more of a private key of the SE module, an application transaction counter, identification data of the SE module, a primary account number and an expiry date of a primary account number. Preferably, the identification data is an integrated circuit card identifier.

Preferably, the user device is a mobile telephone or a mobile computing device.

According to a thirteenth aspect, there is provided a user device for generating a cryptogram for use with a token for performing a transaction, wherein the user device is configured to perform the method of a user device as set out in the eleventh and/or twelfth aspects.

According to a fourteenth aspect, there is provided a server for providing a token for use in a transaction to a user device, wherein the server is configured to perform the method of a server as set out in the eleventh and/or twelfth aspects.

According to a fifteenth aspect, there is provided a system comprising the server of the fourteenth aspect and the user device of the thirteenth aspect. According to a sixteenth aspect of the present disclosure, there is provided a method for transferring a token into a secure element, SE, of a user device, the user device having a secure communications channel that is configured to transmit data, that has been encrypted with one or more keys, between a data source remote from the user device and the SE of the user device, the method comprising: obtaining a token by an application on the user device, wherein the obtained token is outside of both the SE and the secure communications channel; encrypting the token using the same one or more keys configured to encrypt data transmitted from the remote data source in the secure communications channel; and using the secure communications channel to transfer the encrypted token to the SE. Preferably, the method further comprises the SE: receiving the encrypted token; and decrypting the encrypted token using one or more keys.

Preferably, the one or more keys are keys issued by a network operator of the communications with the user device and/or a payment service provider.

Preferably, the one or more keys are provisioned to the SE and/or said application at the time of their manufacture. Preferably, the secure communications channel is provided by Trusted Service Manager, TSM.

Preferably, the token is for paying for a transaction and is for use in one or more systems and methods according to an EMV Payment Tokenisation Specification.

Preferably, the token comprises one or more of identification data of the SE, a primary account number and an expiry date of a primary account number. Preferably, the token comprises identification data and the identification data is an integrated circuit card identifier.

Preferably, the obtained token has been generated by the user device. Preferably, the user device is a mobile telephone or a mobile computing device.

Preferably, the SE is a smart card of the user device or a subscriber identification module, SIM, of the user device. According to a seventeenth aspect of the present disclosure, there is provided a user device comprising a secure element, SE, and one or more applications executable by the user device, wherein the one or more applications are configured to transfer a token into the SE according to the method of the first aspect. According to a eighteenth aspect of the present disclosure, there is provided a method for transferring a token into a secure element, SE, of a user device, the method comprising: obtaining a token by an application on the user device, wherein the obtained token is outside of the SE of the user device; encrypting the token using one or more keys, wherein the one or more keys are issued by a network operator of the communications with the user device; transmitting the encrypted token to the SE; and decrypting the token by the SE.

Preferably, the token is transmitted to the SE via one or more other applications outside of the SE. Preferably, the one or more keys are provisioned to the SE and/or the application that encrypts the token at the time of their manufacture. Preferably, the token is for paying for a transaction and is for use in one or more systems and methods according to an EMV Payment Tokenisation Specification.

Preferably, the token comprises one or more of identification data of the SE, a primary account number and an expiry date of a primary account number.

Preferably, the token comprises identification data and the identification data is an integrated circuit card identifier. Preferably, the obtained token has been generated by the user device.

Preferably, the user device is a mobile telephone or a mobile computing device.

Preferably, the SE is a smart card of the user device or a subscriber identification module, SIM, of the user device.

According to a nineteenth aspect of the present disclosure, there is provided a user device comprising a secure element, SE, and one or more applications executable by the user device, wherein the one or more applications are configured to transfer a token into the SE according to the method of the eighteenth aspect.

According to a twentieth aspect of the present disclosure, there is provided a method for obtaining a token for use in a transaction, the method comprising: determining that a token is required for use in a transaction; obtaining an encrypted token; obtaining, from a secure element, SE, of a user device, one or more keys for decrypting the encrypted token; and using the one or more keys to decrypt the token so that the decrypted token is usable in a transaction.

Preferably, the method further comprises: obtaining a token; obtaining one or more keys for encrypting the token; and using the one or more keys to encrypt the token so that the token is not usable in a transaction.

Preferably, the encrypted token is stored on the user device but outside of the SE of the user device. Preferably, the one or more keys are keys issued by a network operator of the communications with the user device and/or a payment service provider. Preferably, the token is for paying for a transaction and is for use in one or more systems and methods according to an EMV Payment Tokenisation Specification.

Preferably, the user device is a mobile telephone or a mobile computing device.

According to a twenty first aspect of the present disclosure, there is provided a user device for using a token in a transaction, wherein the user device is configured to perform the method as set out in the twentieth aspect.

Various respective aspects and features of the present disclosure are defined in the appended claims.

It is an aim of certain embodiments of the present disclosure to solve, mitigate or obviate, at least partly, at least one of the problems and/or disadvantages associated with the prior art. Certain embodiments aim to provide at least one of the advantages described below.

Brief Description of the Drawings

Embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a system according to an embodiment of the present disclosure; Figure 2 shows a process according a first embodiment of the present disclosure;

Figure 3 shows another process according a first embodiment of the present disclosure; Figure 4 shows a process according a second embodiment of the present disclosure;

Figure 5 shows a process according a third embodiment of the present disclosure;

Figure 6 shows communication paths according to a fourth embodiment of the present disclosure;

Figure 7 shows a process according a first implementation of the fourth embodiment of the present disclosure;

Figure 8 shows a process according a second implementation of the fourth embodiment of the present disclosure; and

Figure 9 shows a process according a fifth embodiment of the present disclosure. Detailed Description

Embodiments of the present disclosure solve at least some of the above-described problems and improve the security of the implementation of tokens on user devices.

According to embodiments, the use of tokens is dependent on data stored in the Secure Element, SE, of a user device. The stored data may be the personal data of a user.

In a first embodiment, tokens are generated in dependence on identification data of the SE module that supports the SE. Advantageously, the tokens are dependent on identification data related to the user device that they were intended for use by. Security is improved by generating tokens that can be easily prevented from being used by any other user device.

In a second embodiment, personal data for generating a token request is stored in the SE. Advantageously, there is no need for a remote server to store this personal data and either to generate a token request itself or to provide it to the user device in order for the user device to generate a token request.

In a third embodiment, data in the SE is used to generate a cryptogram. Advantageously, the cryptogram improves the security of transactions performed by the user device. In a fourth embodiment, the SE stores one or more tokens and a token is not retrieved from the SE until it is required for use during a transaction. Advantageously, this prevents malicious activity from stealing tokens from the user device. In a fifth embodiment, the user device stores encrypted tokens. The SE is required to decrypt the tokens. Advantageously, even if malicious activity does result in tokens being retrieved from the user device, the encrypted tokens are unusable.

Embodiments are described in more detail below.

Figure 1 shows a system according to an embodiment. The system comprises a user device 101 , a network 105, an issuer system 107, an acquirer system 106, a token service provider 104 and a merchant's point-of-sale, POS, terminal 103. The user device 101 may be, for example, a mobile device such as a mobile telephone or computing tablet or any type of computing device for making token based payments. The user device 101 comprises a communications interface for communicating with the network 105. The same, or an additional, communications interface may also be used for communicating with the POS terminal 103.

The network 105 shown in Figure 1 may comprise a plurality of networks. For example, the network may comprise a wireless communications network for communications with the mobile device 101 as well as a payment network for communications with the issuer system 107, acquirer system 106, token service provider 104 and the POS terminal 103.

The issuer system 107 is provided by the bank of the user of the user device and controls the transfer of money from the user's account during a financial transaction.

The acquirer system 106 is the bank of the merchant that the user is making a payment to and controls the transfer of money into the merchant's account during a financial transaction.

The token service provider 104 is a server system for generating tokens in response to receiving a token request triggered by a user device. After the token service provider 104 has generated one or more tokens, the tokens are transmitted to the user device 101 .

In certain embodiments, the system (i.e. the user device, the network etc.) automatically determines that a token request should be generated due to the number of available tokens at the user device being at or below a predetermined threshold level. Additionally or alternatively, other criteria may be applied to determine whether a token request should be generated: for instance, the location of the user device, whether a suitable network connection is available, the time of day, whether the user device has requested a maximum number of tokens within a predetermined time-period, etc.

The POS terminal 103 is any type of merchant's point-of-sale terminal that is capable of accepting a token-based payment. Suitable communications links for transferring token-based payments from the user device 101 to the POS terminal 103 include near field communication, NFC, Bluetooth and WiFi. In addition, or alternatively, a user device may transfer a token- based payment to the POS terminal 103 by the user device generating a computer readable code, such as a QR code, in dependence on the token-based payment. To transfer the token- based payment, the user device 101 displays the computer readable code and the code is read by a computer readable code reader of the POS terminal 103. The POS terminal 103 may also be capable of transmitting data to the user device 101. This may be used by the POS terminal 103 to provide the user device 101 with acknowledgements of accepted token-based payments.

The operation of, and communication between, such a user device 101 , issuer system 107, acquirer system 106, token service provider 104 and merchant's POS terminal 103 in order to implement a payment is well known in the art and the skilled person would be aware of a number of ways in which these techniques can be implemented.

The user device 101 comprises a Secure Element, SE 102. An SE is a tamper resistant component which provides a secure and confidential operating environment in the user device 101. The SE 102 may run multiple applications for a variety of purposes. The SE 102 may be all or part of an SE module. Suitable form factors for the SE 102 include an universal integrated circuit card (UICC), eUICC, an embedded SE, a smartSD, a smart microSD, and others known in the art. Implementations and operations of an SE are described in VISA MOBILE, Proximity Payment Testing & Compliance Requirements for MicroSD and Mobile Accessories, Version 3.1 , February 2014, the entire contents of which are incorporated herein by reference.

Communications with an SE are described in GlobalPlatform Device Technology, Secure Element Access Control, Version 1.0.20, March 2014, the entire contents of which are incorporated herein by reference. SEs, and communication with SEs over an NFC interface in order to pay for a transaction, is described in 'Mobile/NFC Security Fundamentals', Secure Elements 101 , Smart Card Alliance Webinar, March 28, 2013,

http://www.smartcardalliance.org/resources/webinars/Secure_Elements_101_FINAL3_032813. pdf viewed on 14 April 2014, the entire contents of which are incorporated herein by reference.

According to embodiments, the SE 102 may store personal data, such as a PAN and its expiry date, identification data of the SE module that supports the SE 102, such as an integrated circuit card identifier, ICCID, and other data for use in token based transactions. The SE 102 may also store tokens that have either been generated by the SE itself or generated elsewhere and provided to the SE.

Preferably, the system implements an electronic/digital wallet facility that provides payment tokens to user devices in response to valid requests. In certain embodiments, the user device 101 executes a wallet client application that communicates with the electronic/digital wallet facility and thus allows the user device 101 to function as an electronic/digital wallet. The wallet client application provides a payment token whenever needed by the user to pay for a transaction. In logical terms, the wallet electronic/digital wallet facility includes a wallet frontend for communicating with the SE 102 of the user device 101 and a wallet backend for communicating with other applications on the user device 101 , a remote token service provider 104 and/or to a remote point-of-sale terminal 103. In certain embodiments, the wallet frontend is implemented as software executing in the user device 101 (for example, the front end may be a function of the wallet client application or a standalone application) and the wallet backend is implemented as software executing in a server (not shown) within the network 105, and remote from the user device 101 ; the backend server being in communicative connection both to the user device 101 and the token service provider 104. The number of tokens available from the user's wallet is monitored and, if the number of tokens has decreased to a predetermined threshold amount, a request for one or more tokens is automatically generated.

The monitoring of the number of tokens in the wallet may be performed by the wallet backend, wallet frontend, or SE module on the user device. In a first embodiment, the tokens are generated by a token service provider remote from the user device. The user device generates and sends a token request to the token service provider. In a preferred implementation, the wallet frontend automatically determines that a token request should be generated due to the number of available tokens being at or below a predetermined threshold level. The wallet frontend generates and sends a message to the SE module that is a request for the SE module to sign a token request. The token request is a request for one or more tokens and comprises token request data, i.e. the data required by a remote token service provider to generate one or more tokens, such as a PAN and its expiry date. The above- described determination that a token request should be generated, and sending a message to the SE module, may alternatively be performed by the wallet backend.

The SE module receives the message comprising a token request from the wallet frontend. In response to receiving the message, the SE module obtains identification data stored in the SE and inserts the identification data into the token request. The token request is entirely hashed and is signed for the requested number of tokens with a private key of the SE module. The private key used to sign the token request is stored in the SE. Advantageously, a token request for transmission to a remote token service provider is generated with the token request comprising identification data of the SE module. The token service provider is able to verify the authenticity and integrity of the token request by determining that the request comprises the identification data of the SE module and checking the hash and signature.

Additionally or alternatively, the user device may verify to the SE that the user is the authorised user using any conventional authentication technique - such as requiring the input of a PIN or other password or passphrase, or the use of various biometric recognition techniques. In an alternative implementation, the token request sent to the token service provider does not comprise identification data of the SE module and the token service provider obtains the identification data by other means. For example, the identification data may be already known by the token service provider and stored therein. The token service provider may alternatively obtain the identification data by directly, or indirectly via the user device or other means, requesting the identification data from another server that is remote from both the token service provider and the user device. The token request received from the user device is still hashed and signed for the requested number of tokens with a private key of the SE module. The token service provider generates one or more tokens in dependence on the identification data and the token request sent from the user device. The token service provider transmits the one or more generated tokens to the wallet backend and/or frontend.

Advantageously, by generating the tokens in dependence on the identification data, the generated tokens may be easily made usable only by a specific user device and so there is no value in a malicious party attempting to intercept tokens for use by any other device. In addition, the user device does not have the computational burden of generating tokens and it is not necessary for the user device to be provided with any additional data required for generating tokens.

Once used in facilitating a transaction, consumed tokens may still be used in confirming the completion of the transaction.

Figure 2 is a flow chart of a process according to the first embodiment.

In step 201 , the process begins. In step 203, a server that is remote from a user device obtains identification data of a secure element, SE, module that comprises an SE of the user device.

In step 205, a token is generated for use in a transaction, wherein the token is generated in dependence on the identification data.

In step 207, the token is transmitted to the user device. In step 209, the process ends. Figure 3 is a flow chart of another process according to the first embodiment. In step 301 , the process begins.

In step 303, a token request is received from a user device, wherein the token request comprises identification data of a secure element, SE, module comprised by the user device and data for use in generating one or more tokens for use by the user device. In step 305, the token request is authenticated in dependence on the received identification data.

In step 307, the process ends.

In a second embodiment, the SE stores personal data for generating a token request.

A user enters their personal data to the user device. The personal data preferably includes the user's real PAN and a corresponding expiry date. The personal data is stored in the SE only after an ID&V operation on the personal data has been performed and the result has been positive. A preferred implementation of the ID&V operation is for the personal data to be provided to the wallet frontend. The wallet frontend determines that an ID&V operation is required and transmits, via the wallet backend, the personal data to the user's issuer system that is remote from the user device. The issuer system verifies the personal data, according to known verification techniques in the art, and transmits, via the wallet backend, an ID&V verification response back to the wallet frontend. The wallet frontend then transmits the ID&V verification response to the SE module that stores the ID&V verification response in the SE. The ID&V operations are preferably implemented by 3-D Secure techniques, as is known in the art.

Once the personal data is stored in the SE, it is not necessary for another ID&V operation to be performed on the data. The ID&V verification response is preferably used to generate a token assurance level that is applied to tokens that are generated in dependence on the verified personal data. Token assurance levels are described in the above-cited EMV Payment Tokenisation Specification.

Token requests are generated in dependence on the personal data stored in the SE and, optionally, ID&V verification response data also stored therein. A token request may be generated entirely by operations within the SE itself or the personal data may be retrieved from the SE and the token request generated by wallet applications on the user device, that operate outside of the SE. The token request is hashed and signed by a private key obtained from the SE module as described for the first embodiment. Optionally, the token request is also generated in dependence on identification data of the SE module and is a token request as described for the first embodiment. The generated token request is transmitted by the user device to a token service provider for generating a token. The token service provider that receives the token request may operate according to the first embodiment as described in the present document. Advantageously, token service providers are not required to perform ID&V checks on the personal data provided by token requests. It is also not necessary to store personal data on the server of a third party and to perform the slow and unreliable process of either requesting a remote server to generate a token request or for a user device to request personal data from a remote server whenever generating a token request.

In another implementation, one or more applications on the user device itself operate as token service providers and there is no token request sent from the user device. Any additional data required for generating tokens is transmitted to the user device. The user device uses wallet applications outside of the SE and, optionally, applications executed within the SE, to generate one or more tokens in dependence on the personal data and, optionally, SE module identification data that is stored in the SE.

Advantageously, security is improved by maintaining the personal data on the user device during token generation. The data involved in token generation is not transmitted at all over the network and remains on the user device. Preferably, the personal data is stored securely on, and never leaves, the SE during the token generation process.

In another implementation, only applications on the SE are permitted to operate as token service providers, with no applications outside of the SE being used to generate a token. Any additional data required for generating tokens is provided to the SE. Preferably, the generated tokens are stored in the SE and are never present outside of the SE until required for use during a transaction.

Advantageously, security is further improved by maintaining the personal data as well as all other data for generating a token in the SE of the user device during token generation.

Figure 4 is a flow chart of a process according to the second embodiment.

In step 401 , the process begins.

In step 403, data stored within a secure element, SE, of an SE module of a user device is obtained. In step 405, a token is generated in dependence on the obtained data. In step 407, the process ends.

According to a third embodiment, a cryptogram is generated in dependence on data stored in the SE. The cryptogram functions as a token cryptogram as described in the above-cited EMV Payment Tokenisation Specification. By generating the cryptogram in dependence on data stored in the SE, it is possible to determine from the cryptogram that a payment with a token is being performed by a token that has been stored in the same SE. The data in the SE used to generate the cryptogram is secret to the SE and can be used to perform identification and authorisation operations on the cryptogram (i.e. digital signature). Preferably, the secret data is a private key of the SE module. The secret data may also be an additional data value, such as an application transaction counter, ATC. The additional data value may be known to be only derived from the SE such that it can be shown that cryptogram was generated by that SE. Alternatively, or in addition, the data, upon which the generation of the cryptogram depends, includes personal data of the user, such as a PAN and a corresponding expiry date, identification data of the SE module, or any other data.

Advantageously, security is improved since the cryptogram is identifiable as being created by the SE of the user device. A token that uses the cryptogram can be determined to have been stored in the SE.

Figure 5 is a flow chart of a process according to the third embodiment.

In step 501 , the process begins. In step 503, data stored within a secure element, SE, of an SE module of the user device is obtained.

In step 505, a cryptogram is generated in dependence on the obtained data.

In step 507, the process ends. According to a fourth embodiment, tokens received by the wallet backend and/or frontend from a remote token service provider are securely transmitted to the SE and stored in the SE until required for use. In a first implementation, the wallet backend uses a secure channel to transport the tokens to the SE.

Trusted Service Manager, TSM, is a known technique for securely performing the provisioning and lifecycle management of service provider credentials e.g. payment, transport, etc. The TSM acts as a connection point between service providers, such as banks, transit operators and merchants, and SE modules. NFC payments by mobile devices using UICC or device SE can use the TSM model and how to implement the secure channel required for this would be known by the skilled person. The TSM is described in the White Paper: The Role of the Trusted Service Manager in

Mobile Commerce, December 2013, http://www.gsma.com/digitalcommerce/wp- content/uploads/2013/12/GSMA-TSM-White-Paper-FI NAL-DEC-2013.pdf, viewed on 11^th April 2014, the entire contents of which are incorporated herein by reference. The joint GSMA and European Payments Council publication, EPC - GSMA: Mobile Contactless Payments Service Management Roles: Requirements and Specifications: DocEPC 220-08, Ver 2.0, October 2010, describes the role of a TSM in managing secure card emulation services and is also incorporated in its entirety herein by reference. The above-cited document 'Mobile/NFC Security Fundamentals' describes how a TSM is used to enable payments over an NFC interface.

In a first implementation, the wallet backend uses existing "over-the-air", OTA, and/or "over-the- internet", OTI techniques (or other mechanisms in place that achieve the goal of communication to the SE) capabilities of the TSM to open a channel to the SE and to transmit the received tokens to the SE for storage therein. The channel is preferably direct between the wallet backend and the SE. This direct channel is an end-to-end secure channel, opened on top of the actual communication/transport channel between the OTA/OTI platform and the SE. In certain arrangements, alternative mechanisms to the OTA/OTI mechanisms may be used provided they achieve the goal of communication to the SE. The wallet backend is provisioned with, or obtains, any keys or other data required for transmitting the tokens via the TSM communication system. The keys may be the existing mobile network operator keys and/or those of a payment service provider and/or any other keys that are used to create a secure end-to-end communication channel between the wallet backend and the SE and depending upon the context may be symmetric keys or asymmetric keys belonging to respective asymmetric key pairs. The keys are preferably specific to the mobile network operator. The keys may be provisioned to the SE and/or the wallet backend at the time of their manufacture. The wallet backend uses the one or more keys to encrypt the token so that the token is encrypted in the same way as if it had been transmitted to the user device from a remote data source using the TSM OTA OTI capabilities, or any other TSM communication technique. The encrypted token is then provided to the communication channel and transmitted to the SE.

Advantageously, this method of provisioning the tokens on the SE makes use of the existing TSM infrastructures in a simplified manner.

According to a second implementation, the wallet backend is provisioned with one or more keys. The wallet backend encrypts received tokens using the one or more keys. The tokens are then transmitted to the SE via the wallet frontend. The keys are preferably issued by the mobile network operator that supports communication with the user device and private keys. The keys may be existing keys used for TSM communications. The keys may be provisioned to the SE and/or the wallet backend at the time of their manufacture. The wallet backend to wallet frontend communication is secure and the transmission of tokens to the wallet frontend is done securely. On top of that, by sharing a common secret key or, alternatively, by using an asymmetric key mechanism, the wallet backend and the SE ensure end-to-end security of the token transmission.

Advantageously, the transfer of the tokens to the SE is secure. Figure 6 shows the communication paths between the wallet backend and the SE in the above- described first and second implementations of the fourth embodiment.

In the first implementation, the tokens are preferably transmitted directly from the wallet backend to the SE via a secure channel (opened by the TSM or OTA directly from the wallet backend, if the wallet backend has OTA capabilities) and the tokens are preferably not transmitted via the wallet frontend or any other applications. In the second implementation, the encrypted tokens are transmitted from the wallet backend to the wallet frontend, and then from the wallet frontend to the SE.

Figure 7 is a flow chart of a process according to the first implementation of the fourth embodiment.

In step 701 , the process begins.

In step 703, a token is obtained by an application on a user device, wherein the user device has a secure communications channel that is configured to transmit data, that has been encrypted with one or more keys, between a data source remote from the user device and the secure element, SE, of the user device; and the obtained token is outside of both the SE and the secure communications channel. In step 705, the token is encrypted using the same one or more keys configured to encrypt data transmitted from the remote data source in the secure communications channel.

In step 707, the secure communications channel is used to transfer the encrypted token to the SE.

In step 709, the process ends.

Figure 8 is a flow chart of a process according to the second implementation of the fourth embodiment.

In step 801 , the process begins.

In step 803, a token is obtained by an application on the user device, wherein the obtained token is outside of the secure element, SE, of the user device.

In step 805, the token is encrypted using one or more keys, wherein the one or more keys are issued by a network operator of the communications with the user device.

In step 807, the encrypted token is transmitted to the SE.

In step 809, the token is decrypted by the SE. In step 811 , the process ends.

In a fifth embodiment, tokens are stored on the user device but outside of the SE. When one or more tokens transmitted by the token service provider are received by the wallet backend, the tokens are encrypted with a public key for the SE. The public key may be stored in the wallet backend or the SE. The private key for decrypting the encrypted tokens is only stored in the SE.

In response to determining that a token is required for use in a transaction, the user device obtains an encrypted token from the wallet backend and decrypts the token using the private key stored in the SE. Accordingly, a token is only decrypted just before it is required for use during a payment transaction.

Advantages include not needing to perform a process for transferring a token to the SE and not requiring a storage area on the SE for the token. The encryption and decryption process can be performed without requiring any network connectivity.

Figure 9 is a flow chart of a process according to a second implementation of the fifth embodiment.

In step 901 , the process begins.

In step 903, it is determined that a token is required for use in a transaction. In step 905, an encrypted token is obtained (e.g. from the wallet backend or from storage in the user device).

In step 907, one or more keys for decrypting the encrypted token are identified from amongst the data stored in a secure element, SE, of a user device.

In step 909, the one or more keys thus identified are used to decrypt the token so that the decrypted token is usable in a transaction.

In step 91 1 , the process ends.

In the above-described embodiments, one or more tokens and/or cryptograms are obtained by a user device for use in one or more transactions. The use of the token(s) in a transaction may be based on any known techniques, such as those described in the above-cited EMV Payment Tokenisation Specification.

Embodiments also include a number of modifications and variations that can be made to the embodiments as described above.

In the above-described embodiments, identification data of a SE module is referred to. This identification data may be identification data of only the SE within the SE module. Alternatively, the identification data may not be identification of either the SE or the SE module, but other data.

The SE module may be the physical hardware by which the SE is provided. Alternatively, the SE module may be just the SE itself. Embodiments have been generally described with reference to payment transactions. Embodiments also include applying the disclosed techniques for ensuring security of tokens that are not used for payments. Examples of such non-payment applications of tokens include, but are not limited to, the presentation of usage rights for a service or access to a part of a building or even country (as in electronic passports), the demonstration of a consumable right (such as the right to vote, participation in a medical trial, etc.)

In an embodiment, whether or not a token is stored in the SE is dependent on the use restrictions of the token. If the token is valid to use for a long period of time or is suitable for high value transactions, then the token is stored in the SE. Otherwise, it is determined to store the token outside of the SE, preferably encrypted in accordance with the fifth embodiment.

In the first embodiment, it is not necessary for the token request to be sent by the user device for which the token(s) are to be generated. The token request may alternatively be sent by another entity that is requesting the token(s) on behalf of the user device that is to be provided with the token(s). In certain embodiments, the requesting device may be a wearable device such as a smart watch or security pass which has a trusted communication channel to the device requiring the token(s) - i.e. a connected smartphone. Indeed the request may be transmitted to the token service provider from the requesting device via a communication module in the device requiring the token(s).

Figure 1 shows a system according to an embodiment. Embodiments also include alternative system architectures, such as system architectures for e-commerce and card not present transactions and it is not essential for a token to be directly transferred to a merchant's point-of- sale terminal as described above.

The techniques of the first implementation of the fourth embodiment are in no way restricted to use with just TSM channels and are applicable to any type of secure channels between an OTA interface and the SE. Suitable implementations of a secure channel are described in the above-cited Secure Element Access Control document.

In the fourth embodiment, it is not necessary for the tokens to be received by the wallet backend from a remote token service provider and the token may have been generated on the user device.

In the fifth embodiment, tokens are stored on the user device but outside of the SE. It is not necessary for the stored tokens to have been transmitted to the wallet backend by a token service provider and the stored tokens may have been generated on the user device or in the SE.

In the fifth embodiment, tokens are described as being stored on the user device but outside of the SE. It is not necessary for the tokens to be stored outside of the SE and the tokens may be stored in the SE for improved security.

All of the described operations of embodiments may be automated and methods of embodiments may be computer implemented. The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather, the method steps may be performed in any order that is practicable. Although the present disclosure has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.

Claims

CLAIMS:

1. A method for providing a token for use in a transaction to a user device, the method comprising a server:

obtaining identification data of a secure element, SE, module that comprises an SE of a user device;

generating a token for use in a transaction; and

transmitting the token to the user device;

wherein the server is remote from the user device; and

the token is generated in dependence on the identification data.

2. The method according to claim 1 , wherein said step of obtaining identification data is performed in response to a determination that a token is required.

3. The method according to any preceding claim, wherein the server generates the token further in dependence on a primary account number and/or expiry date.

4. The method according to any preceding claim, wherein the identification data comprises an integrated circuit card identifier.

5. The method according to any preceding claim, wherein the SE module is a smart card of the user device.

6. The method according to any preceding claim, wherein the SE module is a subscriber identification module, SIM, of the user device,

7. A server for providing a token for use in a transaction to a user device, wherein the server is configured to perform the method of a server as set out in any preceding claim.

8. A method for authenticating a token request, the method comprising a server:

receiving a token request from a user device, wherein the token request comprises identification data of an SE module comprised by the user device and data for use in generating one or more tokens for use by the user device; and

authenticating the token request in dependence on the received identification data.

9. The method according to claim 8, wherein the data for use in generating one or more tokens comprises a primary account number and/or expiry date.

10. A server for authenticating a token request, wherein the server is configured to perform the method of claim 8 or claim 9.

1 1. A method for generating a token for use in a transaction by a user device, the method comprising a token generator:

obtaining data stored within a secure element, SE, of an SE module of a user device; and

generating a token in dependence on the obtained data.

12. The method according to claim 11 , wherein all of the processes performed by the token generator to generate a token are performed within the SE of the user device.

13. The method according to claim 1 1 , wherein the processes performed by the token generator to generate a token are partially performed within the SE of the user device.

14. The method according to claim 1 1 , wherein said process of generating a token is performed by a server remote from the user device; the method further comprising: transmitting, by the user device, the obtained data to the server; and

transmitting, by the server, the token to the user device.

15. The method according to any one of claims 1 1 to 14, further comprising storing the token in the SE.

16. The method according to any one of claims 1 1 to 15, wherein said step of obtaining data is performed in response to a determination that a token is required.

17. The method according to any one of claims 1 1 to 16, wherein the obtained data comprises one or more of identification data of the SE module, a primary account number and an expiry date of a primary account number.

18. A user device for generating a token for use in a transaction, wherein the user device is configured to perform the method as set out in any one of claims 11 to 17.

19. A method for generating a cryptogram for use with a token for performing a transaction by a user device, the method comprising a user device: obtaining data stored within a secure element, SE, of an SE module of the user device; and

generating a cryptogram in dependence on the obtained data.

20. The method according to claim 19, wherein all of the processes performed to generate the cryptogram are performed within the SE of the user device.

21. The method according to claim 19, wherein the processes performed to generate the cryptogram are partially performed within the SE of the user device.

22. The method according to any one of claims 19, 20 or 21 , wherein the generated cryptogram is unique.

23. The method according to any one of claims 19 to 22, wherein the generated cryptogram is generated further in dependence on a token obtained by the user device.

24. The method according to any one of claims 19 to 23, further comprising storing the generated cryptogram in the SE.

25. A method of generating transaction data by a user device, the method comprising the user device:

obtaining a token for use in a transaction;

generating a cryptogram according to the method of any one of claims 19 to 24; and generating transaction data that comprises the cryptogram and the token.

26. The method according to claim 25, further comprising transferring the transaction data from the user device to a remote terminal in order to use the token in a transaction.

27. The method according to claim 26, further comprising authenticating, by the terminal, the token for use in a transaction in dependence on a determination that the token and cryptogram were both generated in dependence on the same data.

28. The method according to any one of claims 19 to 27, wherein said obtained data stored within a SE comprises one or more of a private key of the SE module, an application transaction counter, identification data of the SE module, a primary account number and an expiry date of a primary account number.

29. A user device for generating a cryptogram for use with a token for performing a transaction, wherein the user device is configured to perform the method as set out in any one of claims 19 to 28.

30. A method for transferring a token into a secure element, SE, of a user device, the user device having a secure communications channel that is configured to transmit data, that has been encrypted with one or more keys, between a data source remote from the user device and the SE of the user device, the method comprising:

obtaining a token for use by an application on the user device, wherein the obtained token is outside of both the SE and the secure communications channel;

encrypting the token using the same one or more keys configured to encrypt data transmitted from the remote data source in the secure communications channel; and using the secure communications channel to transfer the encrypted token to the SE.

31. The method according to claim 30, further comprising the SE:

receiving the encrypted token; and

decrypting the encrypted token using one or more keys.

32. The method according to claim 30 or claim 31 , wherein the one or more keys are keys issued by a network operator of the communications with the user device and/or a payment service provider.

33. The method according to any one of claims 30, 31 or 32, wherein the one or more keys are provisioned to the SE and/or said application at the time of their manufacture.

34. The method according to any one of claims 30 to 33, wherein the secure communications channel is provided by Trusted Service Manager, TSM.

35. The method according to any one of claims 30 to 34, wherein the token comprises one or more of identification data of the SE, a primary account number and an expiry date of a primary account number.

36. A user device comprising a secure element, SE, and one or more applications executable by the user device, wherein the one or more applications are configured to transfer a token into the SE according to the method of any one of claims 30 to 35.

37. A method for transferring a token into a secure element, SE, of a user device, the method comprising:

obtaining a token for use by an application on the user device, wherein the obtained token is outside of the SE of the user device;

encrypting the token using one or more keys, wherein the one or more keys are issued by a network operator of the communications with the user device;

transmitting the encrypted token to the SE; and

decrypting the token by the SE.

38. The method according to claim 37, wherein the token is transmitted to the SE via one or more other applications outside of the SE.

39. The method according to claim 37 or claim 38, wherein the one or more keys are provisioned to the SE and/or the application that encrypts the token at the time of their manufacture.

40. The method according to any of claims 37 to 39, wherein the token comprises one or more of identification data of the SE, a primary account number and an expiry date of a primary account number.

41. A user device comprising a secure element, SE, and one or more applications executable by the user device, wherein the one or more applications are configured to transfer a token into the SE according to the method of any of claims 37 to 40.

42. A method for obtaining a token for use in a transaction, the method comprising:

determining that a token is required for use in a transaction;

obtaining an encrypted token;

identifying, within data stored in a secure element, SE, of a user device, one or more keys for decrypting the encrypted token; and

using the one or more keys to decrypt the token so that the decrypted token is usable in a transaction.

43. The method according to claim 42, further comprising:

obtaining a token;

obtaining one or more keys for encrypting the token; and

using the one or more keys to encrypt the token so that the token is not usable in a transaction.

44. The method according to claim 42 or claim 43, wherein the encrypted token is stored on the user device but outside of the SE of the user device.

45. The method according to any one of claims 42, 43 or 44, wherein the one or more keys are keys issued by a network operator of the communications with the user device and/or a payment service provider.

46. The method according to any one of claims 42 to 45, wherein the token comprises one or more of identification data of the SE, a primary account number and an expiry date of a primary account number.

47. A user device for using a token in a transaction, wherein the user device is configured to perform the method as set out in any one of claims 42 to 46.