WO2015162276A2 - Mise en œuvre d'un jeton sécurisé - Google Patents

Mise en œuvre d'un jeton sécurisé Download PDF

Info

Publication number
WO2015162276A2
WO2015162276A2 PCT/EP2015/058981 EP2015058981W WO2015162276A2 WO 2015162276 A2 WO2015162276 A2 WO 2015162276A2 EP 2015058981 W EP2015058981 W EP 2015058981W WO 2015162276 A2 WO2015162276 A2 WO 2015162276A2
Authority
WO
WIPO (PCT)
Prior art keywords
token
user device
data
transaction
keys
Prior art date
Application number
PCT/EP2015/058981
Other languages
English (en)
Other versions
WO2015162276A3 (fr
Inventor
Jaimie ABRIL DOVALO
Rebecca HIGLEY
Cristina VINTILA
Nikolai Strasding
Selin ÖZSOY
Sebastiaan Hoeksel
Original Assignee
Vodafone Ip Licensing Limited
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
Priority claimed from GB1407258.1A external-priority patent/GB2525426A/en
Priority claimed from GB1407255.7A external-priority patent/GB2525423A/en
Priority claimed from GB1407254.0A external-priority patent/GB2525422A/en
Priority claimed from GB1407256.5A external-priority patent/GB2525424A/en
Priority claimed from GB1407257.3A external-priority patent/GB2525425A/en
Application filed by Vodafone Ip Licensing Limited filed Critical Vodafone Ip Licensing Limited
Publication of WO2015162276A2 publication Critical patent/WO2015162276A2/fr
Publication of WO2015162276A3 publication Critical patent/WO2015162276A3/fr

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/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • HCE Host Card Emulation
  • 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.
  • the user 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 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.
  • 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.
  • a method for providing a token for use in a transaction to a user device 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.
  • 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.
  • the method further comprises retrieving the identification data from the SE of a user device; and transmitting the identification data to the server.
  • the method further comprises receiving the token by the user device; and storing the received token in the SE.
  • the method further comprises using the token in a transaction by transferring the token from the user device to a remote terminal.
  • the token is transferred to the terminal by transmitting the token using at least one of near field communication, Bluetooth or WiFi.
  • 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.
  • said step of obtaining identification data is performed in response to a determination that a token is required.
  • the server generates the token further in dependence on a primary account number and/or expiry date.
  • the identification data comprises an integrated circuit card identifier.
  • the user device is a mobile telephone or a mobile computing device.
  • the SE module is a smart card of the user device.
  • the SE module is a subscriber identification module, SIM, of the user device,
  • 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.
  • 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.
  • a system comprising the server of the second aspect and the user device of the third aspect.
  • a method for authenticating a token request 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.
  • 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.
  • the data for use in generating one or more tokens comprises a primary account number and/or expiry date.
  • 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.
  • a method for generating a token for use in a transaction by a user device 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.
  • 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.
  • all of the processes performed by the token generator to generate a token are performed within the SE of the user device.
  • the processes performed by the token generator to generate a token are partially performed within the SE of the user device.
  • 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.
  • the method further comprises storing the token in the SE.
  • the method further comprises using the token in a transaction by transferring the token from the user device to a remote terminal.
  • the token is transferred to the terminal by transmitting the token using at least one of near field communication, Bluetooth or WiFi.
  • 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.
  • said step of obtaining data is performed in response to a determination that a token is required.
  • 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.
  • the identification data is an integrated circuit card identifier.
  • the user device is a mobile telephone or a mobile computing device.
  • the SE module is a smart card of the user device.
  • the SE module is a subscriber identification module, SIM, of the user device.
  • 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.
  • 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.
  • a system comprising the server of the ninth aspect and the user device of the eighth aspect.
  • a method for generating a cryptogram for use with a token for performing a transaction by a user device 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.
  • 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.
  • all of the processes performed to generate the cryptogram are performed within the SE of the user device.
  • the processes performed to generate the cryptogram are partially performed within the SE of the user device.
  • the generated cryptogram is unique.
  • the generated cryptogram is generated further in dependence on a token obtained by the user device.
  • the method further comprises storing the generated cryptogram in the SE.
  • a method of generating transaction data by a user device 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.
  • the token is generated by the user device.
  • 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.
  • the method further comprises storing the token in the SE.
  • 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.
  • the transaction data is transferred to the terminal by transmitting the transaction data using at least one of near field communications, Bluetooth or WiFi.
  • 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.
  • the obtained token and cryptogram are generated in dependence on the same data.
  • 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.
  • 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.
  • the identification data is an integrated circuit card identifier.
  • the SE module is a smart card of the user device.
  • the SE module is a subscriber identification module, SIM, of the user device,
  • the user device is a mobile telephone or a mobile computing device.
  • 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.
  • 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.
  • a system comprising the server of the fourteenth aspect and the user device of the thirteenth aspect.
  • 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.
  • the method further comprises the SE: receiving the encrypted token; and decrypting the encrypted token using one or more keys.
  • 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.
  • the one or more keys are provisioned to the SE and/or said application at the time of their manufacture.
  • the secure communications channel is provided by Trusted Service Manager, TSM.
  • 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.
  • 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.
  • the token comprises identification data and the identification data is an integrated circuit card identifier.
  • the obtained token has been generated by the user device.
  • the user device is a mobile telephone or a mobile computing device.
  • the SE is a smart card of the user device or a subscriber identification module, SIM, of the user device.
  • 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.
  • a method for transferring a token into a secure element, SE, of a user device 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.
  • the token is transmitted to the SE via one or more other applications outside of the SE.
  • the one or more keys are provisioned to the SE and/or the application that encrypts the token at the time of their manufacture.
  • 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.
  • 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.
  • the token comprises identification data and the identification data is an integrated circuit card identifier.
  • the obtained token has been generated by the user device.
  • the user device is a mobile telephone or a mobile computing device.
  • the SE is a smart card of the user device or a subscriber identification module, SIM, of the user device.
  • SIM subscriber identification module
  • 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.
  • a method for obtaining a token for use in a transaction 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.
  • 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.
  • the encrypted token is stored on the user device but outside of the SE of the user device.
  • 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.
  • 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.
  • 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.
  • the token comprises identification data and the identification data is an integrated circuit card identifier.
  • the obtained token has been generated by the user device.
  • the user device is a mobile telephone or a mobile computing device.
  • the SE is a smart card of the user device or a subscriber identification module, SIM, of the user device.
  • SIM subscriber identification module
  • 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.
  • 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.
  • 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.
  • 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.
  • tokens are generated in dependence on identification data of the SE module that supports the SE.
  • 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.
  • personal data for generating a token request is stored in the SE.
  • 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.
  • data in the SE is used to generate a cryptogram.
  • the cryptogram improves the security of transactions performed by the user device.
  • 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.
  • this prevents malicious activity from stealing tokens from the user device.
  • the user device stores encrypted tokens. The SE is required to decrypt the tokens.
  • the encrypted tokens are unusable.
  • FIG. 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.
  • 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 .
  • 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.
  • 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.
  • 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 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.
  • SEs 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,
  • 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.
  • the system implements an electronic/digital wallet facility that provides payment tokens to user devices in response to valid requests.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 201 the process begins.
  • 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.
  • a token is generated for use in a transaction, wherein the token is generated in dependence on the identification data.
  • step 207 the token is transmitted to the user device.
  • 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.
  • 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.
  • the token request is authenticated in dependence on the received identification data.
  • step 307 the process ends.
  • the SE stores personal data for generating a token request.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the personal data is stored securely on, and never leaves, the SE during the token generation process.
  • 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.
  • the generated tokens are stored in the SE and are never present outside of the SE until required for use during a transaction.
  • 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.
  • step 401 the process begins.
  • step 403 data stored within a secure element, SE, of an SE module of a user device is obtained.
  • step 405 a token is generated in dependence on the obtained data.
  • step 407 the process ends.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • step 501 the process begins.
  • step 503 data stored within a secure element, SE, of an SE module of the user device is obtained.
  • step 505 a cryptogram is generated in dependence on the obtained data.
  • step 507 the process ends.
  • 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.
  • the wallet backend uses a secure channel to transport the tokens to the SE.
  • TSM Trusted Service Manager
  • 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
  • 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.
  • 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.
  • this method of provisioning the tokens on the SE makes use of the existing TSM infrastructures in a simplified manner.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 701 the process begins.
  • 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.
  • 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.
  • step 707 the secure communications channel is used to transfer the encrypted token to the SE.
  • step 709 the process ends.
  • Figure 8 is a flow chart of a process according to the second implementation of the fourth embodiment.
  • step 801 the process begins.
  • 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.
  • 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.
  • step 807 the encrypted token is transmitted to the SE.
  • step 809 the token is decrypted by the SE.
  • step 811 the process ends.
  • tokens are stored on the user device but outside of the SE.
  • 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.
  • the user device 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.
  • step 901 the process begins.
  • step 903 it is determined that a token is required for use in a transaction.
  • step 905 an encrypted token is obtained (e.g. from the wallet backend or from storage in the user device).
  • 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.
  • 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.
  • step 91 1 the process ends.
  • 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.
  • identification data of a SE module is referred to.
  • This identification data may be identification data of only the SE within the SE module.
  • 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.)
  • 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.
  • 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).
  • 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.
  • the tokens 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.
  • 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.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Pour garantir la sécurité de la fourniture d'un jeton à un dispositif utilisateur, la demande de jeton émise par le dispositif utilisateur (ou pour le compte de celui-ci), la génération du jeton chez un fournisseur de services de jeton et la fourniture du jeton par le fournisseur de services de jeton utilisent chacun des données enregistrées dans un élément sécurisé (SE) d'un module SE du dispositif utilisateur. Des jetons sont générés en fonction des données obtenues; l'enregistrement et les communications des jetons sont également sécurisés au moyen des données obtenues. De manière avantageuse, les données requises pour générer une demande de jeton sont enregistrées de manière sécurisée sur un dispositif utilisateur et non sur un serveur distant du dispositif utilisateur.
PCT/EP2015/058981 2014-04-24 2015-04-24 Mise en œuvre d'un jeton sécurisé WO2015162276A2 (fr)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
GB1407257.3 2014-04-24
GB1407258.1A GB2525426A (en) 2014-04-24 2014-04-24 Secure token implementation
GB1407255.7A GB2525423A (en) 2014-04-24 2014-04-24 Secure Token implementation
GB1407258.1 2014-04-24
GB1407255.7 2014-04-24
GB1407256.5 2014-04-24
GB1407254.0 2014-04-24
GB1407254.0A GB2525422A (en) 2014-04-24 2014-04-24 Secure token implementation
GB1407256.5A GB2525424A (en) 2014-04-24 2014-04-24 Secure token implementation
GB1407257.3A GB2525425A (en) 2014-04-24 2014-04-24 Secure token implementation

Publications (2)

Publication Number Publication Date
WO2015162276A2 true WO2015162276A2 (fr) 2015-10-29
WO2015162276A3 WO2015162276A3 (fr) 2016-03-24

Family

ID=53610851

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/058981 WO2015162276A2 (fr) 2014-04-24 2015-04-24 Mise en œuvre d'un jeton sécurisé

Country Status (1)

Country Link
WO (1) WO2015162276A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018143983A1 (fr) * 2017-02-01 2018-08-09 Equifax, Inc. Vérification d'une identité d'après des sources de données réparties multiples en utilisant une chaîne de blocs pour préserver l'identité
EP3467744A4 (fr) * 2016-06-01 2019-06-19 Alibaba Group Holding Limited Procédé, dispositif et système de paiement mobile
US11842328B2 (en) * 2019-10-24 2023-12-12 Mastercard International Incorporated Systems and methods for provisioning a token to a token storage device

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0804803D0 (en) * 2008-03-14 2008-04-16 British Telecomm Mobile payments
CN102971760B (zh) * 2010-06-29 2017-09-08 瑞典爱立信有限公司 用于建立通信的方法、服务器、商户设备以及计算机可读存储介质
US9043609B2 (en) * 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
US10664822B2 (en) * 2012-09-11 2020-05-26 First Data Corporation Systems and methods for facilitating bill payment functionality in mobile commerce
GB2506591A (en) * 2012-09-28 2014-04-09 Bell Identification Bv Method of providing secure services using a mobile device

Non-Patent Citations (1)

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

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3467744A4 (fr) * 2016-06-01 2019-06-19 Alibaba Group Holding Limited Procédé, dispositif et système de paiement mobile
US11100474B2 (en) 2016-06-01 2021-08-24 Advanced New Technologies Co., Ltd. Mobile payment processing
US11100473B2 (en) 2016-06-01 2021-08-24 Advanced New Technologies Co., Ltd. Mobile payment processing
WO2018143983A1 (fr) * 2017-02-01 2018-08-09 Equifax, Inc. Vérification d'une identité d'après des sources de données réparties multiples en utilisant une chaîne de blocs pour préserver l'identité
US10637646B2 (en) 2017-02-01 2020-04-28 Equifax Inc. Verifying an identity based on multiple distributed data sources using a blockchain to safeguard the identity
US11290255B2 (en) 2017-02-01 2022-03-29 Equifax Inc. Verifying an identity based on multiple distributed data sources using a blockchain to safeguard the identity
US11784791B2 (en) 2017-02-01 2023-10-10 Equifax Inc. Verifying an identity based on multiple distributed data sources using a blockchain to safeguard the identity
US11842328B2 (en) * 2019-10-24 2023-12-12 Mastercard International Incorporated Systems and methods for provisioning a token to a token storage device

Also Published As

Publication number Publication date
WO2015162276A3 (fr) 2016-03-24

Similar Documents

Publication Publication Date Title
US11240219B2 (en) Hybrid integration of software development kit with secure execution environment
CN112602300B (zh) 用于非接触式卡的密码认证的系统和方法
CN107925572B (zh) 软件应用程序到通信装置的安全绑定
US20220092589A1 (en) Systems and methods for cryptographic authentication of contactless cards
CN108027926B (zh) 基于服务的支付的认证系统和方法
EP3050247B1 (fr) Procédé de sécurisation de communication hertzienne entre une application mobile et une passerelle
RU2648944C2 (ru) Способы, устройства и системы для безопасного получения, передачи и аутентификации платежных данных
RU2663476C2 (ru) Защищенная обработка удаленных платежных транзакций, включающая в себя аутентификацию потребителей
CN107077670B (zh) 传输和处理交易消息的方法和装置、计算机可读存储介质
JP6704919B2 (ja) 支払いトークンのセキュリティを確保する方法
US11562354B2 (en) Terminal configuration server for the remote configuration of terminals
US20150199673A1 (en) Method and system for secure password entry
US20130226812A1 (en) Cloud proxy secured mobile payments
JP7483688B2 (ja) 非接触カードの暗号化認証のためのシステムおよび方法
US20230396441A1 (en) Systems and methods for cryptographic authentication of contactless cards
CN107256484B (zh) 移动支付转授权方法、及利用该方法实现的支付系统
US20150142669A1 (en) Virtual payment chipcard service
US20150142667A1 (en) Payment authorization system
EP3364352A1 (fr) Détermination des conditions légitimes au niveau d'un dispositif informatique
WO2015162276A2 (fr) Mise en œuvre d'un jeton sécurisé
GB2525424A (en) Secure token implementation
EP3095081A1 (fr) Procédé et système d'authentification
GB2525426A (en) Secure token implementation
EP3364329A1 (fr) Architecture de sécurité pour des applications de dispositif
GB2525422A (en) Secure token implementation

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15738277

Country of ref document: EP

Kind code of ref document: A2