GB2525423A - Secure Token implementation - Google Patents

Secure Token implementation Download PDF

Info

Publication number
GB2525423A
GB2525423A GB1407255.7A GB201407255A GB2525423A GB 2525423 A GB2525423 A GB 2525423A GB 201407255 A GB201407255 A GB 201407255A GB 2525423 A GB2525423 A GB 2525423A
Authority
GB
United Kingdom
Prior art keywords
token
user device
data
tokens
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB1407255.7A
Other versions
GB201407255D0 (en
Inventor
Jaime Antonio Abril Dovalo
Rebecca Claire Higley
Cristina Elena Vintila
Nikolai Strasding
Selin à Zsoy
Sebastiaan Adrianus Alphonsus Petrus Hoeksel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vodafone IP Licensing Ltd
Original Assignee
Vodafone IP Licensing Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vodafone IP Licensing Ltd filed Critical Vodafone IP Licensing Ltd
Priority to GB1407255.7A priority Critical patent/GB2525423A/en
Publication of GB201407255D0 publication Critical patent/GB201407255D0/en
Priority to PCT/EP2015/058981 priority patent/WO2015162276A2/en
Publication of GB2525423A publication Critical patent/GB2525423A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/71—Hardware identity

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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 smartphone 403; and generating a token in dependence on the obtained data 405. Advantageously, the personal data, such as Primary Account Number (PAN) and its expiry date, required to generate a token request is securely stored on the user device itself and not a server remote from the user device. In this way, security of personal data is improved as said data never leaves the SE during the token generation process.

Description

SECURE TOKEN IMPLEMENTATION
Field of the Invention
The present invention relates to a meLhod for improving the security of transactions by user devices. More particularly, embodiments of the invention improve the security of 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 chp cards include the cards being vulnerabie to fraud in ecommerce 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 pointof-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 wrth a specrfic merchant, use in a specific country or use within a predetermined time period. Tokens may also he limited to just a singie 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, that 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 users 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 users 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.
Mahcious activity may also resuft 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 oss 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 invention, 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 a second aspect of the invention, 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 first aspect.
According to a third aspect of the invention, 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 fourth aspect of the invenflon, there is provided a system comprising the server of the third aspect and the user device of the second aspect.
Brief Description of the Drawings
Embodiments of the inventon will now be described, by way of example only, wTh reference to the accompanying drawings, in which: Figure 1 shows a system according to an embodiment of the invention: Figure 2 shows a process according a first embodiment of the invention: Figure 3 shows another process according a first embodiment of the invention; Figure 4 shows a process according a second embodiment of the invention: Figure 5 shows a process according a third embodiment of the invention: Figure 6 shows communcation paths according to a fourth embodiment of the invention; Figure 7 shows a process according a first imp'ementation of the fourth embodiment of the invention; Figure 8 shows a process according a second implementation of the fourth embodiment of the invention; and Figure 9 shows a process according a fifth embodiment of the invention.
Detailed Description
Embodiments of the invention solve at east some of the above-described problems and improve the security 01 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 rehieved 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 descilbed in more detail below.
Figure 1 shows a system according to an embodiment. The system comprises a user device, a network, an issuer system, an acquirer system, a token service provider and a merchant's point-of-sale terminal.
The user device 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 comprises a communications interface for communicating with the network. The same, or an additional, communications interface may also be used for communicating with the terminal.
The network 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 as well as a payment network for communications with the issuer system, acquirer system, token service provider and the terminal.
The issuer system is provided by the bank of the user of the user device and controls the transfer of money from the users account during a financial transaction.
The acquirer system is the bank of the merchant that the user is making a payment to and controls the transfer of money into the merthant's account during a financial transaction.
The token service provider is a server system for generating tokens in response to receiving a token request triggered by a user device. After the token service provider has generated one or more tokens, the tokens are transmitted to the user device.
The terminal is any type of merchant's point-of-sale terminal that is capable of accepting a token-based payment. Suitable communications links for transfening token-based payments from the user device to the terminal include near field communication, NFC, Bluetooth and WFi. In addition, or alternatively, a user device may transfer a token-based payment to the terminal 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 displays the computer readable code and the code is read by a computer readable code reader of the terminal. The terminal may also be capable of transmitting data to the user device. This may be used by the terminal to provide the user device with acknowledgements of accepted token-based payments.
The operation, and communication between, such a user device, issuer system, acquirer system, token service provider and merchants terminal 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 comprises a Secure Element, SE. An SE is a tamper resistant component which provides a secure and confidential operating environment in the user device. The SE may run multiple appUcations for a variety of purposes. The SE may be all or part of an SE module. Suitable from factors include an universal integrated circuit card (UICC), eUICC, an embedded SE, a smartSo, a smart microSD, and others known in the art.
implementations and operations of an SE are described in VISA MOBILE, Proximity Payment Testing & Comphance Requirements for MicroSD and Mobile Accessories, Version 3.1, February 2014, the entire contents of which are incorporated herein by reference.
Communications with a SE are described in GiohalPiatform 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 SEa over an NFC interface in order to pay for a transaction, is described in Mobile/NFC Security Fundamentals', Secure Elements 101, Smart Card Affiance Webinar. March 28, 2013, http://www.smartcardahiance.org/resources/webinars/Secure Elements 1 OIFINAL3O 3281 3.pdi viewed on 14 April 2014, the entire contents ci which are incorporated herein by reference.
According to embodiments, the SE may store personal data, such as a PAN and its expiry date, identification data of the SE module that supports the SE, such as an integrated circuit card identifier, ICCID, and other data for use in token based transactions. The SE may also store tokens that have either been generated by the SE itself or generated elsewhere and provided to the SE.
Preferably, the user device functions as an electronic/digital wallet that provides a payment token whenever needed by the user to pay for a transaction. The wallet has a frontend for communicating with the SE of the user device and a backend for communicating with other applications on the user device, a remote token service provider and/or interface to a remote point-of-sale terminal. The number of tokens available from the 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 by the wallet backend, wallet frontend (which can be a wallet client application), 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.
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.
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 ri 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 its expiry date. The personal data is stored in the SE only after an lD&V operation on the personal data has been performed and the result has been positive. A preferred implementation of Lhe D&V operation is for Lhe personal data to be provided to the wallet frontend. The wallet frontend detemilnes 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 verificaton techniques in the art, and transmits, via the wallet backend, an lD&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 lD&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 D&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 deschbed in the above-cited EMV Payment Tokenisation Specification.
Token requests are generated in dependence on the personal data stored in the SE and, optionafly, 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 waflet apphcations 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 tor the first embodiment.
Optionafly, 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 requestS In another implementation applications on the user device itself operates as the token service provider 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 sLored in the SE.
Advantageously, secuhty 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, appncaUons only on the SE operate as the token service provider, without any 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 aH 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 Ihe SE used to generate the cryptogram is secret to the SE and can be used to perform identification and authorisaUon operations on the cryptogram. Preferably, the data is a private key of the SE module. The 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 that the cryptogram is generated in dependence upon includes personal data of the user, such as a PAN and its 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, that are issued by mobile network operators. 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 deschbed in the White Paper: The Role of the Trusted Service Manager in Mobile Commerce, December 2013, http:/Iwww.gsma.comIdigitalcornmerce/wp-contentluploadsf2Ol 3/1 2/GSMA-TSM-Wnite-Paper-FINAL-DEC-201 3.pdf, viewed on 11th AprH 2014, the entre contents of which are incorporated herein by reference.
The joint GSMA and European Payments Council pubhcation, EPC -GSMA: Mobe Contacfless Payments Service Management Roles: Requirements and Specftications: DocEPC 220-08, Ver 2.0, October 2010, describes the role of a TSM in managing secure card emLdat!on 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 rnplerrlentat!on, the wahet backend uses existing OTA and/or OTi (or other mechanisms in place that achieve the goal of communication to the SE) capabihties 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 waflet backend and the SE. This direct channel is an end-to-end secure channeL opened on top of the actual communication/transport chann& between the OTA/OTI (or other mechanisms in place that achieve the goal of communication to the SE) platlorm and the SE. The waHet 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 existEng mobe 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 waflet backend and the SE. The keys are preferably specific to the mobie network operator.
The keys may be provisioned to the SE and/or the wallet backend at the time of their manufacture. The waUet backend uses the one or more keys to encrypt the token so thai the Loken is encrypted n 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 transnrntted to the SE.
Advantageously, this method of provisioning the tokens on the SE makes use of the easting 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 apphcaflon on a user device, wherein the user device has a secure communicaUons channe 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 eiernent. SE, of the user device and the obtained token is outside of both the SE and the secure communicatons 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 embodment.
In step 801 the process begins.
In step 803, a token is obtained by an apphcation on the user device, wherein the obtained token is outside of the secure &ement, 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 transnrntied by the token service provider are received by the waflet backend, the tokens are encrypted with a public key. 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 token is required for use in a transaction, an encrypted token is obtained and decrypted. 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 transfening 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 the 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.
In step 907, one or more keys for decrypting the encrypted token are obtained from a secure element, SE, of a user device.
In step 909, one or more keys are used to decrypt the token so that the decrypted token is usable in a transaction.
In step 911, 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 descilbed 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. 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 that the SE is provided by. 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.
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 that the token(s) are to be generated for. The token request may altematively 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).
Figure 1 shows a system according to an embodiment. Embodiments also include altemative 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 first implementation of the fourth embodiment are in no way restricted to use with just TSM channels 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 Dement Access Control document.
In the fourth embodiment, it is not necessary for the tokens to be received by the waflet 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 waflet 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.
AM of the described operations of embodiments may be automated and methods of embodiments 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 invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions; and alterations apparent to those skifled in the art can be made to the disclosed embodiments without departing from the sptit and scope of the invention as set forth in the appended clarns.

Claims (10)

  1. CLAIMS: 1. A method for generating a token for use in a transacflon 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.
  2. 2. The method according to claim 1, wherein the generated token is for paying for a transaction and is for use in one or more systems and methods according to anEMV Payment Tokenisation Specification.
  3. 3. The method according to claim I or 2, wherein all of the processes performed by the token generator to generate a token are performed within the SE of the user device.
  4. 4. The method according to claim 1 or 2, wherein the processes performed by the token generator to generate a token are partiaUy performed within the SE of the user device.
  5. 5. The method according to daim I or 2, wherein said process of generating a token is performed by a server remote from the user device; the method further comprisng: transmitting, by the user device, the obtained data to the server; and transmitting, by the server, the token to the user device.
  6. 6. The method according to any preceding claim, further comprising storing the token in the SE.
  7. 7. The method according to any preceding daim, further comprising using the token in a transaction by transferring the token from the user device to a remote terminaL
  8. 8. The method according to daim 7, wherein the token is transferred to the terminal by transmitting the token using at east one of near field communication, Bluetooth or WFi.
  9. 9. The method according to claim 7, wherein 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.
  10. 10. The method according to any preceding claim, wherein said step of obtaining data is performed in response to a determination that a token is required.11 The method according to any preceding claim, wherein the obtained data comprises one or more of identification data of the SE module, a primary account number arid an expiry date of a primary account number.12. The method according to claim 11, wherein the identification data is an integrated circuit card identifier.13. The method according to any preceding claim, wherein the user device is a mobile telephone or a mobile computing device.14. The method according to any preceding claim, wherein the SE module is a smart card of the user device.15. The method according to any preceding claim, wherein the SE module is a subscriber identification module, SIM. of the user device.16. 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 any preceding claim.17. 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 of claims ito 15.18. A system comprising the server of claim 17 and the user device of claim 16.
GB1407255.7A 2014-04-24 2014-04-24 Secure Token implementation Withdrawn GB2525423A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
GB1407255.7A GB2525423A (en) 2014-04-24 2014-04-24 Secure Token implementation
PCT/EP2015/058981 WO2015162276A2 (en) 2014-04-24 2015-04-24 Secure token implementation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1407255.7A GB2525423A (en) 2014-04-24 2014-04-24 Secure Token implementation

Publications (2)

Publication Number Publication Date
GB201407255D0 GB201407255D0 (en) 2014-06-11
GB2525423A true GB2525423A (en) 2015-10-28

Family

ID=50971838

Family Applications (1)

Application Number Title Priority Date Filing Date
GB1407255.7A Withdrawn GB2525423A (en) 2014-04-24 2014-04-24 Secure Token implementation

Country Status (1)

Country Link
GB (1) GB2525423A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022198237A1 (en) * 2021-03-18 2022-09-22 Jpmorgan Chase Bank, N.A. System and method for payment device issuance, lifecycle management, and use

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022198237A1 (en) * 2021-03-18 2022-09-22 Jpmorgan Chase Bank, N.A. System and method for payment device issuance, lifecycle management, and use

Also Published As

Publication number Publication date
GB201407255D0 (en) 2014-06-11

Similar Documents

Publication Publication Date Title
CN112602300B (en) System and method for password authentication of contactless cards
CN107925572B (en) Secure binding of software applications to communication devices
EP3050247B1 (en) Method for securing over-the-air communication between a mobile application and a gateway
US10922675B2 (en) Remote transaction system, method and point of sale terminal
US10650371B2 (en) System and method for enabling a mobile communication device to operate as a financial presentation device
FI125071B (en) Payment system
EP2617219B1 (en) Secure near field communication of a non-secure memory element payload
JP6704919B2 (en) How to secure your payment token
US11132664B2 (en) Securing contactless payment performed by a mobile device
US20160117673A1 (en) System and method for secured transactions using mobile devices
US20130226812A1 (en) Cloud proxy secured mobile payments
US20170032362A1 (en) Streamlined enrollment of credit cards in mobile wallets
AU2014294613A1 (en) Provisioning payment credentials to a consumer
CN113168631A (en) System and method for password authentication of contactless cards
AU2015238048A1 (en) Remote transaction system, method and point of sale terminal
US20180240113A1 (en) Determining legitimate conditions at a computing device
WO2015117323A1 (en) Method and device for achieving remote payment
WO2015162276A2 (en) Secure token implementation
GB2525424A (en) Secure token implementation
KR20110103822A (en) Method and system of managing a mobile card
GB2525426A (en) Secure token implementation
GB2525423A (en) Secure Token implementation
US20150363766A1 (en) Transaction management
GB2525422A (en) Secure token implementation
GB2525425A (en) Secure token implementation

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)