TRANSACTION AUTHORISATION

Abstract

There is discussed a method of authorising an electronic transaction in which a user device receives a shared secret and a shared secret identifier. Subsequently, on receipt of transaction data from a transaction terminal, the user device calculates a one-way hash of data comprising the shared secret to generate a hash value, generates authentication data comprising the hash value and the shared secret identifier, and transmits the authentication data to the transaction terminal.

Claims

1-15. (canceled)

16. A method of validating a transaction by a validation platform, the method comprising: provisioning a user device with a shared secret and a shared secret identifier; receiving authentication data for a transaction, the authentication data identifying a user of the user device and comprising a transaction hash value and a transaction shared secret identifier; verifying that the transaction shared secret identifier corresponds to a valid shared secret; calculating a verification hash value by calculating a one-way hash of data comprising the shared secret corresponding to the transaction shared secret identifier; and comparing the transaction hash value and the verification hash value to determine if the transaction is valid.

17. The method according to claim 16, wherein the validation platform provisions the user device with a plurality of shared secrets and a plurality of shared secret identifiers, each shared secret identifier corresponding to a respective shared secret.

18. The method according to claim 16, wherein following receipt of authentication data including a shared secret identifier, the validation platform invalidates the shared secret corresponding to the shared secret identifier for future transactions.

19. The method according to claim 16, wherein data used to calculate the verification hash value further comprises information relating to identification of the user.

20. The method according to claim 18, wherein the validation platform invalidates the shared secret by setting a status associated with the shared secret as being invalid.

21. The method according to claim 16, further comprising: transmitting a message to an issuer computer indicating a result of comparing the transaction hash value and the verification hash value.

22. The method according to claim 17, wherein the validation platform transmits the plurality of shared secrets and the plurality of shared secret identifiers to the user device via a first communication link, the first communication link communicating data using an Internet Protocol.

23. The method according to claim 16, wherein the transaction comprises a contactless payment transaction, and the user device is a mobile device comprising a contactless payment device.

24. The method according to claim 17, wherein the validation platform transmits the plurality of shared secrets and the plurality of shared secret identifiers via a first communication link, and wherein the user device transmits the authentication data via a second communication link different from the first communication link.

25. The method according to claim 24, wherein the second communication link is a wireless communication link.

26. A device comprising: a processor; and a memory storing executable instructions, which when executed by the processor, causes the device to perform operations including: provisioning a user device with a shared secret and a shared secret identifier; receiving authentication data for a transaction, the authentication data identifying a user of the user device and comprising a transaction hash value and a transaction shared secret identifier; verifying that the transaction shared secret identifier corresponds to a valid shared secret; calculating a verification hash value by calculating a one-way hash of data comprising the shared secret corresponding to the transaction shared secret identifier; and comparing the transaction hash value and the verification hash value to determine if the transaction is valid.

27. The device according to claim 26, wherein the processor causes the device to further perform: provisioning the user device with a plurality of shared secrets and a plurality of shared secret identifiers, each shared secret identifier corresponding to a respective shared secret.

28. The device according to claim 26, wherein following receipt of authentication data including a shared secret identifier, the device invalidates the shared secret corresponding to the shared secret identifier for future transactions.

29. The device according to claim 26, wherein data used to calculate the verification hash value further comprises information relating to identification of the user.

30. The device according to claim 28, wherein the device invalidates the shared secret by setting a status associated with the shared secret as being invalid.

31. The device according to claim 26, wherein the processor causes the device to further perform: transmitting a message to an issuer computer indicating a result of comparing the transaction hash value and the verification hash value.

32. The device according to claim 27, wherein the device transmits the plurality of shared secrets and the plurality of shared secret identifiers to the user device via a first communication link, the first communication link communicating data using an Internet Protocol.

33. The device according to claim 26, wherein the transaction comprises a contactless payment transaction, and the user device is a mobile device comprising a contactless payment device.

34. The device according to claim 27, wherein the device transmits the plurality of shared secrets and the plurality of shared secret identifiers via a first communication link, and wherein the user device transmits the authentication data via a second communication link different from the first communication link.

35. The device according to claim 34, wherein the second communication link is a wireless communication link.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] FIG. 1 shows a schematic diagram of a payment transaction system in which embodiments of the invention may be practised;

[0021] FIG. 2 schematically illustrates a payment device for use in an embodiment;

[0022] FIG. 3 schematically illustrates a validation platform for use in an embodiment; and

[0023] FIG. 4 shows a process flow of an authentication process performed by a user device and a payment terminal according to an embodiment.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0024] FIG. 1 illustrates a transaction system 1 in which embodiments may be implemented. In particular, the transaction system of FIG. 1 is a payment transaction system in which a mobile device 100 can perform a contactless payment transaction with a contactless payment terminal 102 over a first communication link 104 using Near Field Communication (NFC). The NFC communication protocol is standardised in ISO/IEC 18092.

[0025] In the transaction system 1, the contactless payment terminal 102 is a Point of Sales (PoS) terminal located in a business premises, for example a shop, restaurant, cinema, station or other location, and is arranged to process payment transactions on behalf of the business or other entity associated with the PoS terminal.

[0026] The contactless payment terminal 102 is able to maintain or establish a data connection with an acquirer host 106 which typically takes the form of a server system of one or more computing devices for processing transactions associated with a financial institution, such as a bank, which manages one or more financial accounts of the entity associated with the POS. The communication between the contactless payment terminal 102 and the acquirer host is typically via a leased line.

[0027] An issuer host 108 is a server system of one or more computing devices arranged to process transactions associated with a financial institution, such as a bank, which manages one or more financial accounts of a user of the mobile device 100.

[0028] Each of the acquirer host 106 and the issuer host 108 is capable of communicating with a payment scheme network 110. The payment scheme network 110 is a server system of computing devices which may be associated with a financial services organisation, for example.

[0029] In the transaction system 1, the operating system of the mobile device 100 supports Host Card Emulation or the like that permits cloud-based payment transactions using a mobile application (not shown in FIG. 1) stored by the mobile device 100. The mobile application in the transaction system 1 is not stored in a secure element within the mobile device (such as an ISIM) card, and therefore sensitive account information such as the Primary Account Number (PAN) is stored in servers linked to the mobile application to provide security for the sensitive account information. The mobile application is able to communicate with a mobile application platform 112 using a second communication link 114 using the Internet Protocol when the mobile device 100 is online (i.e. when an Internet connection exists). The mobile application platform 112 is able to communicate with the issuer host 108.

[0030] As shown in FIG. 1, the mobile application platform 112 is also able to communicate with a validation platform 116. A communication link also exists between the validation platform 116 and the issuer host 108.

[0031] Although the mobile application platform 112 and the issuer host 108 are shown separately in FIG. 1, the mobile application platform 112 could be hosted by one or more servers of the issuer host 108. Similarly, although the validation platform 116 is shown separately from the issuer host 108, the validation platform 116 could be hosted by one or more servers of the issuer host 108.

[0032] As will be described in detail hereafter, the validation platform 116 provisions, via the mobile application platform 112, the mobile application within the mobile device 100 with an indexed list of shared secrets (which will hereinafter be referred to as a Relying Party Provisioned Challenges or RPPCs) in which each shared secret is associated with a corresponding shared secret identifier. An RPPC is known only within the validation platform 116 and within the mobile application of the mobile device 100. An RPPC is used when forming an application cryptogram for a transaction. After the transaction has been completed, the validation platform 116 marks the RPPC used for that transaction as no longer being valid.

[0033] FIG. 2 illustrates exemplary components of a user device according to embodiments of the present invention wherein the user device comprises a mobile telephony device.

[0034] User device 100 comprises conventional computational hardware including a processing portion 202, read only memory 204, random access memory 206, and other standard hardware such as an input/output controller, display controller etc. (not shown). User device 200 also comprises specific mobile telephony hardware including telephony antenna 208, and SIM card 210. The SIM card 210 constitutes a secure processing environment on the user device, also known as secure element 212, and incorporates additional security measures such as tamper resistance. The components described above are accessible to processing portion 202 via an internal communication structure, such as system bus 214. The operation and interaction of these components is well known in the art and therefore will not be covered in further detail here.

[0035] User device 100 also includes short range wireless communications hardware, including short range wireless antenna 216, which can be used to make contactless communication with the PoS terminal 102, and may be an NFC antenna.

[0036] Typically, where short range wireless antennas have hitherto been provided in known mobile telephony devices, they have been controlled by the SIM 210, via a dedicated communication channel 218, separate to system bus 214. The dedicated communication channel 218 may, for example, use the Single Wire Protocol for communication. According to embodiments of the present invention, the short range wireless antenna is accessible from an area outside of secure element 212, hereafter known as the standard application environment 220, for example via the system bus 214. This feature is presently available, for example, in the host card emulation functionality of the Android operating system.

[0037] Standard application environment 220 also comprises the payment application deployed on device 100. The payment application may be installed on the standard application environment at the time of manufacture of the device, or under the supervision of the issuing bank. Alternatively the payment application may be installed by the end user of the device. An end user may install the application by downloading the installation files to the user device, for example via the internet. Alternatively a user may install the application by downloading the installation files first to another device, such as a personal computer, and then sideloading the files onto to the user device, for example via a USB connection. Alternatively still, a user may obtain the installation files by accessing an application portal on the user device, such as the Apple® AppStore™, or the Android Market™, which facilitate an integrated download and installation of application files. The download of installation files facilitated by an application portal may be provided via an available internet connection, or over-the-air provisioning (OTAP).

[0038] FIG. 3 shows exemplary components of the validation platform 116. As shown, the validation platform 116 includes a network interface 302, a processor 304 and memory 306 interconnected by bus system 308. The memory 306 stores data including an RPPC database 310, and program code including a Master Control routine 312, a Provisioning sub-routine 314 and a Validation sub-routine 316.

[0039] The RPPC database 310 stores for each user device 100 a table of RPPC codes. Each RPPC code is associated with an index number, an expiry date and a status, which may be valid or invalid.

[0040] The Provisioning sub-routine 314 is initiated by the Master Control routine 312 to provide new RPPC codes to a user device 100. The execution of the Provisioning sub-routine 314 may be initiated in response to receipt of a request by the user device 100. The Provisioning sub-routine 314 forwards at least one new RPPC code to the user device 100, together with an index number for each RPPC code forwarded and the expiry date. The Provisioning sub-routine also stores each forwarded RPPC code and corresponding index number and expiry date in the table in the RPPC database 310 for that user device 100, and sets the status of each forwarded RPPC code to valid.

[0041] As will be discussed in more detail hereafter, the Validation sub-routine 316 is initiated by the Master Control routine 312 to validate an application cryptogram received from the issuer host 108. After the use of a valid RPPC in a transaction, the status of the RPPC in the table for the user device 100 is set to invalid in order to prevent reuse of the RPPC. In this way, possible “replay” attacks, in which bogus transaction data is prepared using an RPPC that has been already used for a previous transaction are prevented.

[0042] Before the transaction is completed, the payment terminal 102 must ensure that the presented user device 100 is both genuine, and authorised to complete the transaction. Authentication of payment devices and authorisation of transactions are handled according to transaction protocols, which ensure the interoperability of a range of payment devices and payment terminals.

[0043] The transaction system 1 of FIG. 1 uses the EMV (Europay®, Mastercard®, Visa®) transaction protocols, as defined for example in the EMV Contactless Specifications for Payment Systems, which are publicly available and published by EMVCo LLC. These protocols are referred to herein as simply “EMV”.

[0044] EMV provides methods that support dynamic signature generation, of which Dynamic Data Authentication (DDA) is the simplest. Additionally, EMV provides a method called Fast DDA (fDDA) which is optimised for contactless transactions, and a method called Combined Data Authentication (CDA), which combines DDA with the subsequent step of Application Cryptogram Generation (described below), in order to allow both operations to be completed in parallel.

[0045] EMV provides for transaction authorisation through the generation of application cryptograms. Depending on which options are used from the various EMV specifications, there are several mechanisms available for application cryptogram generation. Throughout the transaction processing, the success or failure of certain checks and actions, such as those described above in relation to offline data authentication, can be recorded in a Terminal Verification Results (TVR) data.

[0046] The TVR data is reviewed during Terminal Action Analysis, and on the basis of its contents, the terminal makes a preliminary decision about whether the transaction should be approved offline, authorised online, or declined. Approval offline comprises the terminal deciding that the transaction can take place without seeking express permission from the Issuing Bank. Online authorisation comprises sending details of the transaction to the Issuing Bank for authorisation before approving the transaction. In some circumstances, the terminal will decline the transaction offline, before seeking authorisation from the Issuing Bank.

[0047] The decision of the appropriate course of action for the terminal to take is made on the basis of Terminal Action Codes (TAC) and Issuer Action Codes (IAC). TACs are programmed into the terminal by the acquiring bank, and define the circumstances under which a transaction should be approved offline, authorised online, or declined. IACs are deployed into the payment application by the issuing bank, and also define a set of circumstances under which a transaction should be approved offline, authorised online, or declined. The terminal uses both the TACs and the IACs in order to make a preliminary decision on how to process the transaction.

[0048] FIG. 4 illustrates an exemplary Application Cryptogram Generation command flow diagram according to the EMV transaction protocols.

[0049] The flow begins at step 400 by comparing the contents of the TVR to the TACs stored at the payment terminal 102 and the IACs retrieved from the payment application on the user device 100. On the basis of the comparison, the payment terminal 100 makes a preliminary decision about whether the transaction should be approved offline, authorised online, or declined in step 402.

[0050] Depending on the result of the decision made at step 402, the terminal requests a specific type of Application Cryptogram to be generated by sending a GENERATE AC command to the user device 100. If the payment terminal 102 decides to decline the transaction offline, the GENERATE AC command requests Application Authentication Cryptogram (AAC) in step 404. If the payment terminal 102 decides to attempt to authorise the transaction online, the GENERATE AC command requests an Authorisation Request Cryptogram (ARQC) in step 406. If the payment terminal 102 decides to approve the transaction offline, the GENERATE AC command requests a Transaction Certificate (TC) in step 408.

[0051] In response to the GENERATE AC command issued by the payment terminal 102, the user device 100 may perform its own risk management in the form of “Card Action Analysis”. Card action analysis is perfoimed on the basis of parameters determined by the issuer and stored on the user device 100. The result of the Card Action Analysis can only elect an authorisation method the same as determined by the payment terminal 102 or stricter.

[0052] If the payment terminal 102 decides to reject the transaction offline by requesting an AAC as per step 404, the user device 100 must respond with an AAC in step 410. Any other response from the user device 100 will cause the transaction processing to fail.

[0053] If the payment terminal 102 decides to attempt to send the transaction online for authorisation by the issuing bank by requesting an ARQC as per step 406, as a result of the Card Action Analysis in step 412 the user device 100 may decide to respond with an ARQC in step 414 as requested, or elect to decline the transaction offline by responding with an AAC in step 410. A response from the user device 100 comprising a TC will cause the transaction processing to fail.

[0054] If the payment terminal 102 decides to allow the transaction offline by requesting a TC as per step 408, as a result of the Card Action Analysis in step 414 the user device may decide to respond with a TC in step 418 as requested, elect to send the transaction online for authorisation by the issuing bank by responding with an ARQC in step 416, or elect to decline the transaction by responding with an AAC in step 410.

[0055] If the user device 100 responds with an ARQC, the payment terminal 102 attempts to send this to the issuing bank for authorisation in step 420. If the result of the online authorisation procedure is to reject the transaction, the payment terminal 102 requests an AAC in step 422 by sending a second GENERATE AC command, and the AAC is returned by the user device in step 410. If the result of the online authorisation procedure is to authorise the transaction, the payment terminal 102 requests a TC in step 424 by sending a second GENERATE AC command, and the AAC is returned by the user device 100 in step 416.

[0056] Alternatively, if the online authorisation procedure cannot be completed, the terminal reverts to a default method as defined in the TAC/IAC, by sending a second GENERATE AC command which either requests an AAC as per step 422, which is returned by the user device 100 in step 410, or a TC in step 424, which is returned by the user device 100 in step 418.

[0057] Once the user device 100 has responded with either an AAC or a TC as per steps 410 or 418 respectively, the Application Cryptogram Generation command flow is completed.

[0058] In order to respond to a GENERATE AC command issued by the terminal, the user device 100 must produce an Application Cryptogram. An Application Cryptogram is produced on the basis of data sent to the user device 100 in the data field of the GENERATE AC command. The data to be used is specified in a Card Risk Management Data Object List (CDOL), which is stored in the user device 100. The user device 100 stores two CDOLs, one for use with the first GENERATE AC command issued in a given transaction, and the other to be used if a second GENERATE AC command is issued.

[0059] The Application Cryptogram is generated by applying a hash algorithm to a data set specified by a CDOL to generate a hash value. A hash algorithm is a one-way mathematical operation that is used to generate a fixed size result on the basis of a large or variably sized data input. The result depends on the entire data input, and it is computationally difficult to determine input data that would produce a given result. EMV recommends the use of the Secure Hash Algorithm (SHA-1) as standardised in ISO/IEC 10118-3.

[0060] In addition to the Application Cryptogram, in this embodiment the user device 100 also generates a supplementary hash value by applying a hash algorithm to a further data set including an RPPC, and optionally also the result of a user verification process (such as password or PIN entry, a biometric test or a technique such as FIDO) and possibly also verification data associated with the user verification process. The supplementary hash value is included together with the RPPC index corresponding to the RPPC used to generate the supplementary hash value in the ARQC data. The supplementary hash value is sufficiently small that the supplementary hash value and the RPPC index can be included in available space within the EIV message conveying the ARQC data.

[0061] When the issuer host 108 receives the ARQC data, the supplementary hash value and the RPPC index are forwarded to the validation platform 116, which determines from the RPPC index the corresponding RPPC, checks that the corresponding RPPC is valid for that user device 100, and then calculates a validation hash value using the set of data used to generate the supplementary hash value in the ARQC data, and then compares the validation hash value with the supplementary hash value in the ARQC data. If the validation hash value matches the supplementary hash value, then the validation platform 116 sends a message to the issuer host 108 indicating that the user device 100 is authenticated. If the validation hash value does not match the supplementary hash value, then the validation platform 116 sends a message to the issuer host 108 indicating that the user device 116 is not authenticated. Whether or not the validation hash value matches the supplementary hash value in the ARQC data, the validation platform 116 then marks the RPPC value invalid for future transactions.

[0062] In use, typically, the contactless payment terminal 102 is configured to initiate a payment by a vendor. For example, the vendor may manually enter a transaction amount into the contactless payment terminal 102, or the value of goods and/or services due for payment may be determined by some other means, such as by a barcode reader reading barcodes provided on products for purchase, for example. In order to initiate a contactless payment transaction, it may be necessary to select a particular option on the contactless payment terminal 102, the contactless payment terminal 102 may be configured only to accept contactless payments or it may be configured to automatically enact a contactless payment transaction on detection of an appropriate contactless user device 100.

[0063] Once the contactless payment terminal 102 has been appropriately configured, the user (e.g. customer at a retail establishment) performs a user verification process on the user device 100 and then brings the contactless user device 100 into proximity with the contactless payment terminal 102. This results, for example, in the contactless payment terminal 102 sending a request to the contactless user device 100 to provide data for enacting the payment transaction. In response, the user device 100 retrieves sends the requested data to the contactless payment terminal 102. The provided data may include data identifying a payment account from which funds are to be drawn in the payment transaction, such as a PAN and an identifier of the issuer associated with the contactless payment device 100. Messages sent by the user device 100 may be in protected form. For example, it may comprise a cryptogram, for example an EMV compliant Authorisation ReQuest Cryptogram (ARQC).

[0064] On receipt of a message, the contactless payment terminal 102 determines, based on, for example, the presence of an ARQC that it is to obtain authorisation information from the issuer host 108. The contactless payment terminal 102 then sends an authorisation request message to acquirer host 106, the message including the information received from the contactless payment device 100. The message may also include a transaction identifier to identify the transaction, the identifier being included in the message by the contactless payment terminal 102. The message may also include other data added by the contactless payment terminal 102, such as a value of the transaction.

[0065] On receipt of the message, the acquirer host 106 forwards same to the payment scheme network 110. In the present embodiment, the payment scheme network 110 routes the message to the issuer host 108 (for example, based on an indicator of the issuer included in the message). The issuer host 108 receives the authorisation request message, cryptographically verifying same using the validation platform 116 where appropriate, and performs a determination process to determine whether to authorise the contactless payment transaction. The issuer host 108 then returns a result of the determination to the acquirer host 106, via the payment scheme network 110, in a message including an indicator as to whether or not the transaction is authorised. It may also include a transaction identifier the same as or corresponding to the transaction identifier provided by the contactless payment terminal 102 as described above.

[0066] The message sent by the issuer host 108 is routed to the contactless payment terminal 102 via the payment scheme network 110 and acquirer host 106. On receipt of the message, the payment terminal 102 identifies the result of the verification based on the content of the message, and may indicate same, for example on a display screen of the contactless payment terminal 102. If the contactless payment transaction is not authorised, the user may be presented with further options for completing the transaction.

[0067] Although the above systems and methods have been described in the context of contactless payment transactions, other types of payment transactions may be used. For example, the above payment authorisation methods may be used for payments in which a financial instrument such as a debit or credit card is brought into contact with a payment terminal, for example by swiping a magnetic strip on the card on a reader of the payment terminal or inserting a card including a chip into a reader on the payment terminal. Further, the systems and methods applied above can be used in transactions other than payment transactions. For example, the systems and methods described above can be used in an electronic access system in which a terminal device (analogous to a lock) authenticates a user device (analogous to a key) before providing access. Such an electronic access system may provide access to data. Alternatively, such an electronic access system may be used to open a door to a safe, or a room or the like.

[0068] As discussed previously, using a shared secret in the form of an RPPC as discussed above can prevent replay attacks. In addition, relay attacks can be largely defeated if the data set used to calculate the hash value in the ARQC included some transaction specific data.

[0069] The various memories described above may take the form of any suitable date store, including Random Access Memory (RAM) and/or Read Only Memory (ROM) data stores. The various processors may take the form of a semiconductor chip, such as a Central Processing Unit (CPU) for example.

[0070] It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims. The features of the claims may be combined in combinations other than those specified in the claims.