Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
ELECTRONIC PAYMENTS SYSTEMS, METHODS AND APPARATUS
Document Type and Number:
WIPO Patent Application WO/2022/040762
Kind Code:
A1
Abstract:
An application, such as a point of sale application, or a software library that can be embedded into an application, is stored in the memory of a computing device to enable the device to securely process electronic transactions. The device can perform one or more of i) merchant authentication to ensure the merchant is a valid merchant; ii) secure cryptographic operations to protect sensitive data; iii) secure collection of payment details, such as card-holders' card details via one or more payment protocols, using a kernel via a reader of the device; iv) secure collection of Personal Identification Numbers (PINs) or other Card-holder Verification Methods (CVM) via a secured interface; v) collection and/or verification of integrity and/or attestation information to validate the integrity of a device to ensure the device has not been compromised from a security perspective; vi) communication with a secure back-end server.

Inventors:
GRAHAM TOM (AU)
Application Number:
PCT/AU2021/051008
Publication Date:
March 03, 2022
Filing Date:
August 31, 2021
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
POQ PTY LTD (AU)
International Classes:
G06Q20/34; G06Q20/38; G07F7/08
Domestic Patent References:
WO2015183176A12015-12-03
Foreign References:
US20180225653A12018-08-09
US20200065805A12020-02-27
US20180068295A12018-03-08
Attorney, Agent or Firm:
SPRUSON & FERGUSON (AU)
Download PDF:
Claims:
CLAIMS An application, such as a point of sale (POS) application, or a software library that can be embedded into an application, such as a point of sale application, in a computing device, the application or library comprising computer executable instructions stored on a computer readable storage medium to perform one or more of the following on the computing device related to securely processing an electronic transaction: merchant authentication to ensure the merchant is valid and not, for example, a third-party masquerading as the merchant; customer authentication; secure cryptographic capabilities to protect sensitive data; secure collection of payment details, such as card-holders’ card details via one or more protocols, such as, but not limited to one or more Europay, Mastercard, VISA (EMV) and/or MIFARE protocols, using an EMV kernel or other kernel via a reader of the device; secure collection of Personal Identification Numbers (PINs) via a secured interface, or any other Card-holder Verification Methods (CVM); collection and/or verification of integrity and/or attestation information to validate the integrity of a device to ensure the device has not been compromised from a security perspective; and/or communication with a secure back-end server. A back-end server or system comprising computer executable instructions stored on a computer readable storage medium to perform one or more of the following related to securely processing an electronic transaction via a computing device: merchant authentication verification; customer authentication; integrity and/or attestation verification; device identification and/or tracking and/or management; secure cryptographic capabilities to transport sensitive data to an acquirer, and/or a payment scheme and/or a financial institution; store records of current and historical transactions; and/or Secure Sockets Layer (SSL) or similar security for communications on Application Programming Interface (API) endpoints. The application, or software library of claim 1 , or the back-end server or system of claim 2, wherein the computing device enables a merchant to sell items or services, keep track of a total sale amount and securely process an electronic transaction to accept payment for the sold items or services. The application, or software library of claim 1 , or the back-end server or system of claim 2, wherein the computing device is a consumer’s computing device, in particular a mobile phone, which enables the consumer to effect secure payments via their computing device. The application, or software library, of any preceding claim, wherein the one or more kernels enable the computing device to process payments according to one or more contactless transaction standards for known payment schemes, by using a Contactless Entry Point module for the discovery and selection of a contactless application that is supported by the reader of the device and a consumer’s payment device (e.g. payment card), and activation of the appropriate kernel for processing the contactless transaction in an international interchange environment. The application, or software library, of any preceding claim, wherein the library incorporates payment functionality into a third-party application, such as a third- party POS application. The application, or software library of claim 6, wherein the POS application, the library and one or more of the kernels interact with a Rich Operating System (ROS) of the computing device. The application, or software library of claim 7, wherein the ROS communicates with a hardware abstraction layer, which interacts with hardware of the computing device, such as one or more of a NFC interface and a touch screen. The application, or software library of claim 6 or 7, wherein the ROS includes a cryptography provider, which can be used for encryption functions used in the processing of the secure transactions, using a secure element or Trusted Execution Environment (TEE). The application, or software library of any preceding claim wherein the application constantly or periodically verifies the integrity of the computing device by collecting attestation and/or system data from the device and verifying the collected data on a back-end server. The application, or software library of claim 10, wherein the data collected includes, but is not limited to one or more of the following: information about the application binary, such as the Android Package (APK) details in the case of an Android application; the result of any root detection; checksums of the library and/or the application; a list of apps considered to be dangerous; whether the application has been built with debug symbols or debug enabled; any attestation data provided by cryptographic hardware, such as Keystore attestation certificates on Android; extensive device hardware and system information; device sensor data, such as data from sensors such as accelerometers, cameras, and/or any other sensors in or on the device; any attestation provided by the Rich Operating System (ROS) of the device, such as SafetyNet results in the case of Android; a current physical (GPS) location of the device; a unique identifier for the device that can preferably be tracked across re-installs of the application, such as the Android ID in the case of Android. The application, or software library of claim 11 , wherein: some or all of the data is provided to the back-end server regularly, such as with every message; and/or the data includes a nonce provided by the back-end server for cryptographic communication to ensure that the data cannot simply be repeated by a malicious user; and/or trust in the data is increased by including data from an independent attestation system, such as Android SafetyNet, which includes integrity checks from the operating system. The application, or software library of claim 11 or 12, wherein if the integrity of the device cannot be established, or if a device is deemed to be acting in a malicious or insecure manner, the back-end server, or the mobile device disallows the mobile device from performing a transaction and deletes any sensitive user or key material. The application, or software library of claim 11 or 12, wherein a mobile device that has been disallowed or blocked from performing transactions is also blocked from re-initialising or re-activation of payment capability, optionally through identifiers collected as part of attestation such as matching an ID of the device, such as an Android ID, identifying a common hardware and system information profile, determining that multiple integrity failures have come from a device location, and/or by matching the authentication credentials provided during initialisation. The application, or software library of any preceding claim, wherein validating the integrity of the device to ensure the device has not been compromised from a security perspective comprises performing one or more of the following root detection strategies for detecting root access: searching for root management apps; searching for potentially dangerous apps; searching for root cloaking apps; checking for test keys; checking for dangerous system properties; checking for BusyBox, or other software suites with one or more executable files that replace multiple commands, particularly ones designed for use with embedded operating systems; searching for the presence of root/super-user binaries; checking for read/write system access. The application, or software library of claim 15, further comprising mitigating risk associated with root-hiding comprising the application launching a new, separate process from the application using one of the following two methods; forking the current process via the operating system "fork ()" method; or by starting an Android Service in a new process under a new User ID (UID) by setting the “android:isolatedProcess” attribute in the services Android manifest. The application, or software library of any preceding claim, wherein merchant authentication comprises: the application using credentials provided by the merchant to authenticate the merchant to the library; transmitting the authentication credentials from the library to the back- end server, optionally with any collected attestation and system data; checking the validity of the credentials and that the attestation and system data prove the integrity of the computing device, optionally including security and/or fraud checks including, but not limited to whether the merchant is using a black-listed device, whether the merchant themselves are blacklisted, and/or whether the merchant is eligible for the payment capability; and generating a unique device identifier which is provided to the library and to the application at the computing device, which can be used as an identifier going forward. The application, or software library of claim 17, wherein validation and authentication of the credentials is performed by the back-end server or by an independent system, such as a Payment & Authentication Gateway. The application, or software library of any preceding claim, wherein the computing device and the back-end server utilise encryption of all messages card-holder data and card-holder PIN including initial Key Initialisation immediately after authentication to setup an initial set of daily session keys and regular subsequent key-rolls to minimise key lifetime and limit the impact of any single key being compromised. A method of securely processing an electronic transaction via a computing device comprising an application, such as a point of sale (POS) application, or a software library that can be embedded into an application, the computing device comprising computer executable instructions stored on a computer readable storage medium, the method comprising: the application running on the device receiving an amount for the transaction; the library sending meta data for the transaction to a backend server and receiving a Transaction Data Encryption Key (TDEK) from the backend server to protect the card data; receiving payment data relating to a financial account from a customer’s payment device in response to a prompt displayed by the computing device; the library encrypting the payment data relating to the financial account and communicating the encrypted data to the backend server; if a PIN is required to process the transaction: the library requesting and receiving from the backend server a Transaction PIN Encryption Key (TPEK) to protect the PIN; receiving a PIN via the computing device in response to a prompt for PIN entry displayed by the computing device caused by the library and/or the application; the library encrypting the PIN and communicating the encrypted PIN to the backend server; the backend server assembling a full transaction message or transaction request using the encrypted payment data and PIN, if required, and submitting the transaction message to a payment gateway; the payment gateway submitting the transaction message to an acquirer; the acquirer returning the transaction result to the library on the computing device via the payment gateway and the backend server; the library returning the transaction result to the application running on the computing device; and the library sending confirmation of the transaction result, or a request to reverse if an error condition has occurred, to the backend server.
Description:
TITLE

ELECTRONIC PAYMENTS SYSTEMS, METHODS AND APPARATUS

FIELD OF THE INVENTION

[0001] The present invention is directed to the field of electronic payments and systems, methods and apparatus therefor. In particular, but not exclusively, the present invention is directed to mobile computing devices, such as mobile phones, hand-held computers, tablets, personal digital assistants (PDAs) and other mobile computing devices operating as mobile payment terminals to process electronic transactions.

BACKGROUND

[0002] Electronic payments are now ubiquitous and are preferred in many scenarios over cash or other forms of payment due to the speed of processing, traceability, security and convenience, such as obviating the need to carry cash, handle change or write a cheque.

[0003] The proliferation of mobile computing devices, and in particular mobile phones, and the advancement of mobile technology, such as processing capabilities and near field communication (NFC), have resulted in mobile phones commonly being used to make payments. Details relating to a payment apparatus, such as a debit card or a credit card, and the associated financial account, are stored on the mobile phone, usually in some tokenised form of the payment apparatus or a virtualised payment apparatus. The mobile phone is then presented to a payment terminal at the point of sale to effect payment, rather than presenting the payment apparatus.

[0004] The use of mobile computing devices as payment terminals is also well known. Such devices include conventional mobile payment terminals comprising features including a screen, a keypad, one or more of a magnetic stripe reader, a smart card reader and a contactless reader, various communications features and security features. The use of other mobile computing devices, such as mobile phones and tablets, as payment terminals is also known, i.e. the mobile phone or tablet is used to process the electronic transaction. Such functionality is appealing because of the ubiquitous nature of mobile phones, tablets and the like, i.e. merchants can use their mobile phones, tablets and the like as payment terminals thus avoiding the need to purchase dedicated payment terminals.

[0005] One problem that exists in using a mobile phone, tablet and the like as a payment terminal relates to the security of the mobile phone. Mobile phones typically include a Rich Operating System (ROS), such as Android, iOS or Windows, which is not typically able to be restricted or secured in the same way, or to the same extent, as conventional payment terminals. Typically, efforts to secure the ROS of the mobile phone tablet or the like in the same way, or to the same extent as conventional payment terminals requires the involvement of the manufacturer.

[0006] There is therefore a need for a system and/or a method and/or an apparatus and/or a computer readable storage medium comprising computer executable instructions to provide mobile computing devices, and in particular mobile phones, with a similar level of security to conventional payment terminals for the purpose of processing electronic transactions.

[0007] This level of security should allow for the protection of payment data of the individual making the payment, such as, but not limited to account data, account access data, such as Personal Identification Number (PIN), transaction details and any other data associated with the transaction, in such a manner to make it impractical for a third party to design a system that is either on the device or external to the device to capture this data in a cost effective manner and be able to use this data to ultimately defraud either the customer, the merchant, or the financial institution providing the payment facility.

[0008] The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

OBJECT OF THE INVENTION

[0009] A preferred object of the present invention is to provide a system and/or a method and/or an apparatus and/or a computer readable storage medium comprising computer executable instructions that enables mobile computing devices, such as mobile phones, hand-held computers, tablets, personal digital assistants (PDAs) and other mobile computing devices to operate as a mobile payment terminal to process electronic transactions that addresses, or at least ameliorates one or more of the aforementioned problems and/or provides a useful commercial alternative.

SUMMARY OF INVENTION

[0010] Generally, the present invention is directed to a system and/or a method and/or an apparatus and/or a computer readable storage medium comprising computer executable instructions that enables computing devices, and in particular mobile computing devices, such as mobile phones, hand-held computers, tablets, personal digital assistants (PDAs) and other mobile computing devices, to operate as a mobile payment terminal to process electronic transactions with a similar level of security to conventional payment terminals.

[0011] According to one aspect, but not necessarily the broadest aspect, the present invention resides in an application, such as a point of sale application, or a software library that can be embedded into an application, such as a point of sale application, in a computing device, the application or library comprising computer executable instructions stored on a computer readable storage medium to perform one or more of the following on the computing device related to securely processing an electronic transaction:

[0012] merchant authentication to ensure the merchant is valid and not, for example, a third- party masquerading as the merchant;

[0013] customer authentication;

[0014] secure cryptographic capabilities to protect sensitive data;

[0015] secure collection of payment details, such as card-holders’ card details, and/or Personal Identification Numbers (PINs) via one or more protocols, such as, but not limited to one or more Europay, Mastercard, VISA (EMV) and/or MIFARE protocols, using an EMV kernel or other kernel via a NFC reader in the device or any other form of reader in the device;

[0016] secure collection of Personal Identification Numbers (PINs) via an appropriately secured interface, or any other Card-holder Verification Methods (CVM) [0017] collection and /or verification of integrity and/or attestation information to validate the integrity of a device to ensure the device has not been compromised from a security perspective; and/or

[0018] communication with a secure back-end server. [0019] A point of sale application is an application that allows a merchant to sell items or services and keep track of the total sale amount and at the completion of the sale accept payment for the sold items or services.

[0020] However, it should be appreciated that the application or software library according to aspects of the present invention can be used on consumer devices to enable consumers to effect secure payments, for example, for online purchases, via the consumer’s computing device, in particular a mobile phone.

[0021] According to another aspect, but not necessarily the broadest aspect, the present invention also resides in a back-end server or system comprising computer executable instructions stored on a computer readable storage medium to perform one or more of the following related to securely processing an electronic transaction: [0022] merchant authentication verification;

[0023] customer authentication;

[0024] integrity and/or attestation verification;

[0025] device identification and/or tracking and/or management;

[0026] secure cryptographic capabilities to transport sensitive data to an acquirer, and/or a payment scheme and/or a financial institution;

[0027] store records of current and historical transactions; and/or

[0028] Secure Sockets Layer (SSL) or similar security for communications on Application Programming Interface (API) endpoints.

[0029] Suitably, the one or more kernels enable the computing device to process payments according to one or more contactless transaction standards for known payment schemes, by using a Contactless Entry Point module for the discovery and selection of a contactless application that is supported by the reader of the device and a consumer’s payment device (e.g. payment card), and activation of the appropriate kernel for processing the contactless transaction in an international interchange environment.

[0030] Suitably, the library incorporates payment functionality into a third-party application, such as a third-party POS application.

[0031] Suitably, the POS application, the library and one or more of the kernels interact with a Rich Operating System (ROS) of the computing device.

[0032] Suitably, the ROS communicates with a hardware abstraction layer, which interacts with hardware of the computing device, such as one or more of a NFC interface and a touch screen. [0033] Suitably, the ROS includes a cryptography provider, which can be used for encryption functions used in the processing of the secure transactions, using a secure element or Trusted Execution Environment (TEE).

[0034] In some embodiments, the application constantly or periodically verifies the integrity of the computing device by collecting attestation and/or system data from the device and verifying the collected data on a back-end server.

[0035] The data collected may include, but is not limited to one or more of the following: information about the application binary, such as the Android Package (APK) details in the case of an Android application; the result of any root detection; checksums of the library and/or the application; a list of apps considered to be dangerous; whether the application has been built with debug symbols or debug enabled; any attestation data provided by cryptographic hardware, such as Keystore attestation certificates on Android; extensive device hardware and system information; device sensor data, such as data from sensors such as accelerometers, cameras, and/or any other sensors in or on the device; any attestation provided by the Rich Operating System (ROS) of the device, such as SafetyNet results in the case of Android; a current physical (GPS) location of the device; a unique identifier for the device that can preferably be tracked across re-installs of the application, such as the Android ID in the case of Android.

[0036] Suitably, some or all of the data is provided to the back-end server regularly, such as with every message; and/or the data includes a nonce provided by the back- end server for cryptographic communication to ensure that the data cannot simply be repeated by a malicious user; and/or trust in the data is increased by including data from an independent attestation system, such as Android SafetyNet, which includes integrity checks from the operating system.

[0037] In preferred embodiments, if the integrity of the device cannot be established, or if a device is deemed to be acting in a malicious or insecure manner, the back-end server, or the mobile device disallows the mobile device from performing a transaction and deletes any sensitive user or key material.

[0038] Preferably, a mobile device that has been disallowed or blocked from performing transactions is also blocked from re-initialising or re-activation of payment capability, optionally through identifiers collected as part of attestation such as matching an ID of the device, such as an Android ID, identifying a common hardware and system information profile, determining that multiple integrity failures have come from a device location, and/or by matching the authentication credentials provided during initialisation.

[0039] In some embodiments, validating the integrity of the device to ensure the device has not been compromised from a security perspective comprises performing one or more of the following root detection strategies for detecting root access: searching for root management apps; searching for potentially dangerous apps; searching for root cloaking apps; checking for test keys; checking for dangerous system properties; checking for BusyBox, or other software suites with one or more executable files that replace multiple commands, particularly ones designed for use with embedded operating systems; searching for the presence of root/super-user binaries; checking for read/write system access.

[0040] Some embodiments of the invention further comprise mitigating risk associated with root-hiding comprising the application launching a new, separate process from the application using one of the following two methods; forking the current process via the operating system "fork ()" method; or by starting an Android Service in a new process under a new User ID (UID) by setting the “android:isolatedProcess” attribute in the services Android manifest.

[0041] Suitably, merchant authentication comprises: the application using credentials provided by the merchant to authenticate the merchant to the library; transmitting the authentication credentials from the library to the back-end server, optionally with any collected attestation and system data; checking the validity of the credentials and that the attestation and system data prove the integrity of the computing device, optionally including security and/or fraud checks including, but not limited to whether the merchant is using a black-listed device, whether the merchant themselves are blacklisted, and/or whether the merchant is eligible for the payment capability; and generating a unique device identifier which is provided to the library and to the application at the computing device, which can be used as an identifier going forward. [0042] Suitably, validation and authentication of the credentials is performed by the back-end server or by an independent system, such as a Payment & Authentication Gateway.

[0043] Preferably, the computing device and the back-end server utilise encryption of all messages card-holder data and card-holder PIN including initial Key Initialisation immediately after authentication to setup an initial set of daily session keys and regular subsequent key-rolls to minimise key lifetime and limit the impact of any single key being compromised.

[0044] According to a further aspect, but not necessarily the broadest aspect, the present invention resides in a method of securely processing an electronic transaction via a computing device comprising an application, such as a point of sale (POS) application, or a software library that can be embedded into an application, the computing device comprising computer executable instructions stored on a computer readable storage medium, the method comprising: the application running on the device receiving an amount for the transaction; the library sending meta data for the transaction to a backend server and receiving a Transaction Data Encryption Key (TDEK) from the backend server to protect the card data; receiving payment data relating to a financial account from a customer’s payment device in response to a prompt displayed by the computing device; the library encrypting the payment data relating to the financial account and communicating the encrypted data to the backend server; if a PIN is required to process the transaction: the library requesting and receiving from the backend server a Transaction PIN Encryption Key (TPEK) to protect the PIN; receiving a PIN via the computing device in response to a prompt for PIN entry displayed by the computing device caused by the library and/or the application; the library encrypting the PIN and communicating the encrypted PIN to the backend server; the backend server assembling a full transaction message or transaction request using the encrypted payment data and PIN, if required, and submitting the transaction message to a payment gateway; the payment gateway submitting the transaction message to an acquirer; the acquirer returning the transaction result to the library on the computing device via the payment gateway and the backend server; the library returning the transaction result to the application running on the computing device; and the library sending confirmation of the transaction result, or a request to reverse if an error condition has occurred, to the backend server. [0045] Further features and/or aspects of the present invention will become apparent from the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order that the invention may be readily understood and put into practical effect, reference will now be made to embodiments and aspects of the present invention with reference to the accompanying drawings, wherein like reference numbers refer to identical elements. The drawings are provided by way of example only, wherein:

[0047] FIG 1 illustrates a system, and in particular a backed-end server or system for securely processing electronic transactions according to embodiments of the present invention;

[0048] FIG 2 illustrates features of an application or library for the secure collection of payment details from a payment device according to embodiments of the present invention and features of a computing device in which the application or library operates;

[0049] FIG 3 illustrates the architecture of a point of sale application in relation to the rich operating system and hardware of the device comprising a library according to embodiments of the present invention;

[0050] FIG 4 illustrates a key initialisation process used to initialise a mobile device and exchange a first set of session keys according to an embodiment of the present invention;

[0051] FIG 5 is a table showing the different types of encryption keys and their usage that can be used in the key initialisation process shown in FIG 4;

[0052] FIG 6 is a table showing the different types of encryption keys and their usage that can be used to encrypt and sign messages to and from the server;

[0053] FIG 7 is a table showing the different types of encryption keys and their usage that can be used for the key encryption keys;

[0054] FIG 8 is a table showing the different types of sensitive data encryption keys and their usage that can be used for sensitive data;

[0055] FIG 9 is a diagram illustrating steps involved in a method of authenticating a merchant;

[0056] FIG 10 illustrates a key roll process; [0057] FIG 11 is a general flow diagram for processing a transaction according to some embodiments of the present invention;

[0058] FIG 12 illustrates encryption processes involved in the transaction process shown in FIG 11 according to some embodiments of the present invention; and [0059] FIG 13 shows the mobile device displaying a PIN entry keypad in accordance with some embodiments of the present invention.

[0060] Skilled addressees will appreciate that elements in the drawings are illustrated for simplicity and clarity, have not necessarily been drawn to scale and may be schematic in nature. For example, the relative dimensions of some elements in the drawings may be distorted to help improve understanding of embodiments of the present invention.

DETAILED DESCRIPTION

[0061] Embodiments of the present invention are directed to an application, such as a point of sale application, or a software library that can be embedded into an application, such as a point of sale application, that operates in and effects operations of a computing device, in particular a mobile computing device, such as a mobile phone, tablet or the like. The application or library comprises computer executable instructions stored on a computer readable storage medium in the computing device to cause the computing device to securely process electronic transactions. Embodiments of the present invention are also directed to an apparatus in the form of a computing device comprising such an application or library and to related systems and methods for securely processing electronic transactions.

[0062] With reference to FIG 1 , a system 100 for securely processing electronic transactions according to embodiments of the present invention comprises a back-end server or system 102 in communication with an acquirer, payment scheme and/or financial institution 104. A computing device 106, in particular a mobile computing device, such as a mobile phone, tablet or the like communicates with the back-end server or system 102 via network 108. The computing device 106 comprises an application 110, such as a point of sale application, or an electronic library that can be embedded into an application, such as a point of sale application, for securely processing electronic transactions. The back-end server or system 102 comprises computer executable instructions stored on a computer readable storage medium 111 for performing merchant authentication verification, integrity and/or attestation verification, device identification and/or tracking and/or management, secure cryptographic capabilities to transport sensitive data to the acquirer, payment scheme or a financial institution 104, the storage of records of current and historical transactions and/or Secure Sockets Layer (SSL) or similar security for communications on Application Programming Interface (API) endpoints, as will be described herein. In some embodiments, such functionality can be implemented in the back-end server or system 102 in an authentication module 112, an integrity/attestation module 114, a cryptography module 116 and a transactional logging module 118, as shown in FIG 1. It will be appreciated that such functionality can be implemented in a back-end server or system in other ways with one or more other modules.

[0063] FIG 2 illustrates features of the application 110 or library for the secure collection of card-holders’ card details from an apparatus, such as a payment card, or a mobile device, such as a mobile phone or tablet or the like, storing payment details, according to embodiments of the present invention. FIG 2 also illustrates features of the computing device 106 in which the application or library operates.

[0064] The secure collection of payment details is performed via one or more protocols, such as, but not limited to one or more of Europay, Mastercard, Visa (EMV) protocols as defined by EMVCo, LLC and/or one or more MIFARE protocols using an appropriate kernel, such as an EMV kernel or other kernel, via NFC or other communication protocol, such as Bluetooth, via communication hardware 120 in the computing device 106, such as a NFC reader, or any other form of reader in the device 106 and a hardware abstraction layer 121 of the computing device 106. According to some embodiments, the application 110 or library provides one or more EMV kernels 122, 124, 126 according to the payment schemes to be processed by the computing device 106. For example, the application 110 or library can comprise a Paypass® kernel 122 for processing payments according to the EMV contactless transaction standards by MasterCard, a Paywave® kernel 124 for processing payments according to the EMV contactless transaction standards by Visa, one or more kernels 126 for processing payments according to EMV contactless transaction standards for other payment schemes, such as American Express, Discover, JCB etc. Such EMV contactless transactions use an EMV Contactless Entry Point module 128 for the discovery and selection of a contactless application that is supported by both the reader of the device 106 and the payment device (e.g. the payment card), and activation of the appropriate kernel for processing the contactless transaction in an international interchange environment. In this regard, reference can be made to, for example, EMV Contactless Specifications for Payment Systems, Entry Point Specification, as published by EMVCo, LLC, which defines the reader requirements necessary to support a multi-kernel architecture, and any related standards, such as the ISO/IEC 7816 and ISO/IEC 14443 series of standards. According to some embodiments, the application 110 or library provides one or more other kernels/protocols 130, such as a MIFARE kernel/protocol, for processing payments according to other kernels/protocols via the NFC hardware 120 and the hardware abstraction layer 121 of the computing device 106.

[0065] FIG 3 illustrates the architecture of a point of sale (PCS) application 110 comprising a library 130 for securely processing electronic transactions. According to some embodiments, the library 130 can be used to incorporate payment functionality into a third-party application, such as a third-party PCS application. The PCS application 110, library 130 and one or more EMV kernels, such as EMV kernels 122, 124, 126, 130, interact with the Rich Operating System (ROS) 132 of the computing device 106. The ROS 132 communicates with the hardware abstraction layer 121 , which interacts with the hardware of the computing device 106, such as NFC interface 134 and a touch screen 136. The ROS 132 includes a cryptography provider 138, which can be used for some encryption functions used in the processing of the secure transactions, using a secure element or Trusted Execution Environment (TEE) 140.

[0066] Installation of Application

[0067] In order to make use of the application 110 (or app), such as a point of sale application, or an electronic library 130 that can be embedded into an application, such as a point of sale application, the app or the library must first be installed on the mobile computing device 106. Installation is achieved by downloading the app or library using a secure store or distribution channel appropriate for the computing device being used. A secure store ensures that the app or library can be delivered in a secure and trusted manner. Common stores are Google Play for Android, Galaxy Store for Samsung devices, Amazon Appstore for Android, and App Store for iOS devices. However, other secure distribution channels may be appropriate for other devices. Most app stores also ensure that the mobile application is kept up to date by regularly checking for and installing updates when available. [0068] Attestation and Integrity

[0069] According to some embodiments, in order to ensure a secure environment for the collection of payment details, such as card-holders’ card details, PINs and any other information relating to financial accounts necessary for processing an electronic transaction, the application 110 constantly or periodically verifies the integrity of the computing device 106. Integrity is established by collecting attestation and system data from the device and verifying the collected data on a back-end server 102. According to preferred embodiments, the data collected includes, but is not limited to one or more of the following:

[0070] Information about the application binary, such as the Android Package (APK) details in the case of an Android application.

[0071] The result of any root detection.

[0072] Checksums of the library 130 and/or the application 110.

[0073] A list of apps considered to be dangerous.

[0074] Whether the application 110 has been built with debug symbols or debug enabled.

[0075] Any attestation data provided by cryptographic hardware, such as Keystore attestation certificates on Android.

[0076] Extensive device hardware and system information.

[0077] Device sensor data, such as data from sensors such as accelerometers, cameras, and/or any other sensors in or on the device 106.

[0078] Any attestation provided by the Rich Operating System (ROS) 132, such as SafetyNet results in the case of Android.

[0079] The current physical (GPS) location of the device 106.

[0080] A unique identifier for the device 106 that can preferably be tracked across reinstalls of the application 110, such as the Android ID in the case of Android.

[0081] In preferred embodiments, some or all of the aforementioned data is provided to the back-end server 102 regularly, such as with every message. In preferred embodiments, the data includes a nonce provided by the back-end server 102 for cryptographic communication to ensure that the data cannot simply be repeated by a malicious user. Trust in the provided data can be increased by including data from an independent attestation system, such as Android SafetyNet, which includes integrity checks from the operating system itself. If the integrity of a device cannot be established, or if a device is deemed to be acting in a malicious or insecure manner, then the back-end server 102, or the mobile device itself, disallows the mobile device 106 from performing a transaction and deletes any sensitive user or key material.

[0082] Mobile devices that have been disallowed or blocked from performing transactions are also blocked from re-initialising or re-activation of payment capability. This may be achieved through identifiers collected as part of attestation such as matching the device's Android ID, identifying a common hardware and system information profile, determining that multiple integrity failures have come from a device location, or by matching the authentication credentials provided during initialisation.

[0083] Root Detection

[0084] A common strategy for breaching a Rich Operating System (ROS) is for the user to obtain "root access" to the ROS 132, also referred to as "rooting" or "jail breaking". Root access involves escalating a user’s privileges to that of the "root" user, also known as admin user or super user. Root privileges provide the highest level of control over the ROS and effectively allow a user and applications running on the device to have full control over the device, including access to operating system files and memory.

[0085] According to some embodiments, one or more of the following root detection strategies can be used for detecting root access:

[0086] Searching for root management apps.

[0087] Searching for potentially dangerous apps.

[0088] Searching for root cloaking apps.

[0089] Checking for test keys.

[0090] Checking for dangerous system properties.

[0091] Checking for BusyBox, or other software suites with one or more executable files that replace multiple commands, particularly ones designed for use with embedded operating systems.

[0092] Searching for the presence of root/super-user binaries (like su).

[0093] Checking for read/write system access.

[0094] In preferred embodiments, the aforementioned searches and checks are performed in low-level software, utilising C code or assembly wherever possible.

[0095] When a mobile device has root capabilities, it is usually fairly easy to detect with one or more of the above strategies. However, applications exist that are designed to hide the root status from other applications by obfuscating or hiding the results of the above searches and checks. This is usually done when a user wants some applications to have root level privileges, and for other applications to have normal privileges. Many root hiding applications achieve this by allowing the user to choose which apps are targeted for root-hiding. This effectively allows a user to hide the root status from the application and bypass standard root detection. If the root status is hidden in this way, then a malicious user can potentially modify the data collected for attestation without the modification being detected.

[0096] In order to mitigate this risk, further checks can be performed to minimize this possibility. One such solution on Android devices, in order to make targeting the application for root-hiding more difficult, is for the application to launch a new, separate process from the application using one of the following two methods.

[0097] 1 . By forking the current process via the operating system "fork ()" method; or [0098] 2. By starting an Android Service in a new process under a new User ID (UID) by setting the “android:isolatedProcess” attribute in the services Android manifest.

[0099] When launching the new process, the application 110 should generate a randomised process name in order to make detecting and tracking the new process more difficult. The second method notably uses a new, different UID compared to the main application, which can further increase the difficulty of the forked application being targeted or detected. The new process should implement the root detection strategies defined above and communicate the findings the root detection strategies to the main application using an appropriate Inter-process Communication (I PC) mechanism, such as TCP/IP. In preferred embodiments, the root detection strategies are run continuously. The main application uses the results provided by the new process to assist with determining root status. Additionally, if the new process stops working, or if the application 110 is unable to start the new process, this should be treated as a positive detection of root access.

[00100] Encryption

[00101] In preferred embodiments, the mobile device 106 and back-end server 102 communicate with each other over a secure channel, such as SSL 1.2 protected HTTPS. Additional encryption is preferably provided at the message level and for the payment details, such as card data and card-holder PIN using rolling, or changing keys, as described below. For initialisation of keys and for rolling keys, an asymmetric encryption scheme is preferably used. Common asymmetric encryption schemes include RSA and ECC. [00102] Public keys for encrypting data on the mobile device 106 and for verifying data received from the back-end server 102 are distributed with the mobile application 110, with the private keys residing on the back-end server 102. These keys can be used for the key initialisation process. During key initialisation and during every subsequent key-roll, new public and private key-pairs are generated on both the mobile device 106 and on the back-end server 102, and the public keys exchanged with the other end.

[00103] Symmetric keys are preferably used for transporting symmetric keys from the back-end server 102 to the mobile device 106, for protecting a card-holder’s card data, and for protecting a card-holders PIN.

[00104] Usually, asymmetric encryption schemes use a symmetric key to encrypt larger data payloads being sent, and then provide the symmetric key encrypted under the asymmetric public key alongside the payload. Symmetric keys used in this way are preferably uniquely generated per payload. This allows for such larger amounts of data to be encrypted without being limited by the size limits of the asymmetric scheme.

[00105] Encryption Keys Implementation

[00106] One such implementation for the encryption keys uses 128-bit Advanced Encryption Standard (AES) keys and 2048-bit Rivest-Shamir-Adleman (RSA) keys, with a 196-bit Triple Data Encryption Standard (3DES) key for PIN encryption. This implementation expects keys to roll or change daily. This example of implementation uses the following: a KEK - Key Encryption Key; a DEK - Data Encryption Key; and a SK - Signing Key, in relation to the following associated with the financial account: PAN - Primary Account Number; PIN - Personal Identification Number. All RSA keys are 2048 bit. Signature keys use Secure Hash Algorithm (SHA)-256 with a public key cryptography standard (PKCS) padding, such as PKCS1 probabilistic signature scheme (PSS) padding. Encryption keys use PKCS1 optimal asymmetric encryption padding (OAEP). All AES keys are 128 bit. AES keys use cipher block chaining (CBC). The 3DES PIN key is 196bit. 3DES keys also use CBC. It will be appreciated that this aspect of the present invention is not limited to this specific implementation, the specified key lengths or types of encryption and other forms and combinations of implementation, key lengths and encryption can be used providing best practices are followed regarding choice of encryption scheme and key-length.

[00107] Initialisation Keys [00108] The initialisation keys are used during the process of key initialisation as shown in FIG 4 and are used to initialise a mobile device 106 and exchange a first set of session keys. According to some embodiments, the first set of session keys includes the four communication RSA keys and two key encryption keys described herein. The table shown in FIG 5 shows examples of the key types and their usage. The public keys are pre-loaded in the app 110 and the private keys reside on the back-end server 102. The symmetric key is generated on the mobile device 106 (client device) at initialisation time.

[00109] Communication Keys

[00110] The communication keys are used to encrypt and sign, preferably, all messages to and from the back-end server 102. The table in FIG 6 shows examples of the key types and their usage. The daily keys in this section are all initialised or rolled (changed) periodically, such as daily, as part of the Key Initialisation process shown in FIG 4 or the Key Roll process shown in FIG 10. The server 102 and the mobile device 106 each generate an RSA key-pair for encrypting data and an RSA key-pair for signing data. The RSA keys are rolled daily as part of the standard keyroll process. For all RSA keys, the private key is stored locally (for decryption or signing) and the corresponding public key is sent to the other end (for encryption or verification). For the encryption of data, a per-message AES key is generated on the sending end. This key is used to encrypt the message payload, and then communicated to the receiving end under the relevant RSA key. According to some embodiments, all communications, unless otherwise specified, should be encrypted using this protocol.

[00111] Key Encryption Keys

[00112] The key encryption keys are in the form AES keys in some embodiments and are used to protect other AES keys. Reference is made to the table shown in FIG 7 for examples of the key types and their usage. These keys are rolled periodically, such as daily, as part of a standard key-roll process as described herein with reference to FIG 10. In some embodiments, the keys are all generated on the server, but the keys are stored on both ends and transported to the client device protected under the previous days rolling KEK, or under the Client Init KEK during key initialisation.

[00113] Sensitive Data Keys

[00114] The sensitive data keys are used for encrypting sensitive data from the client device to the server. Reference is made to the table shown in FIG 8 for examples of the sensitive data key types and their usage. In some embodiments, they are generated on an as-needed basis on the server for each transaction. The sensitive data keys are stored on both ends and transported to the mobile device 106 protected under the current Transaction KEK or PIN KEK.

[00115] Authentication

[00116] Before a merchant can make use of the application 110 to accept payments, the merchant must first be authenticated using valid credentials for the merchant that are stored on the back-end server 102. An example of an authentication process or method is described with reference to FIG 9. In step 1 the merchant logs into the application 110 by providing a username and password, an API token, or some other secret and uniquely identifying information. In step 2 the application 110 uses the provided credentials to authenticate the merchant to the library 132.

[00117] In step 3, the authentication credentials are transmitted from the library 132 to the back-end server 102, along with any collected attestation and system data. The back-end server 102 checks that the credentials are valid and that the attestation and system data prove the integrity of the mobile device 106. This may include security and/or fraud checks including, but not limited to whether the merchant is using a blacklisted device, whether the merchant themselves are black-listed, and/or whether the merchant is eligible for the payment capability. The back-end server 102 may validate and authenticate the credentials itself or the back-end server 102 may pass them through to an independent system to validate them, as shown at step 4 in FIG 9. In this example, the credentials are communicated to a Payment & Authentication Gateway. The Payment & Authentication Gateway validates the credential and returns the result to the back-end server 102 at step 5.

[00118] Once the merchant has been identified through validation of the credentials provided, the back-end server 102 generates a unique device identifier which is provided to the library 132 at step 6 and back to the application 110 at the merchant's mobile device 106 at step 7, which can be used as an identifier going forward. The authentication process is protected using the appropriate encryption scheme using the relevant initialisation keys to keep data secure during transmission.

[00119] Key Initialisation and Key Roll

[00120] To ensure the security of transactions, the mobile device 106 and back- end server 102 utilise appropriate encryption of all messages and of the card-holder data and card-holder PIN. An initial Key Initialisation should occur immediately after authentication to setup the initial set of daily session keys. Subsequent key-rolls should occur regularly, as often as daily to minimise key lifetime and limit the impact of any single key being compromised.

[00121] For the encryption model described in the Encryption section above, the following information would be true for all messages between the back-end server 102 and mobile device 106:

[00122] All key exchanges include attestation data from the mobile device 106 which is documented under Attestation.

[00123] Where an AES KEK is used it is assumed that the randomised initialisation vector (IV) is included in the message.

[00124] Where an RSA DEK is used for message encryption, it is assumed that an AES Payload DEK will be generated uniquely for this message and used to encrypt the entire payload. This AES Payload DEK will then be encrypted under the RSA DEK and it and the relevant AES IV will be communicated to the receiving end.

[00125] Where a message is signed, it is assumed that signing happens after encryption (if encrypted) and that signature verification happens before decryption (if encrypted).

[00126] For the encryption model described in the Encryption section above the following Key Initialisation and Key Roll would be appropriate.

[00127] Key Initialisation

[00128] With reference to FIG 4, the Key Initialisation process is very similar to the Key Roll, except that pre-loaded public keys are used for encrypting server-bound data and verifying client-bound data respectively and the initial request to the server 102 is not signed. This process also makes use of a client-generated Key Encryption Key (Client Initialisation KEK) since there is no existing Rolling KEK.

[00129] For initialisation the username and password may also be provided in the initial message as part of the authentication process. This Key Initialisation results in an exchange of the keys outlined in the sections Communication Keys and Key Encryption Keys detailed above.

[00130] Key Roll

[00131] With reference to FIG 10, the Key Roll process makes use of the previously exchanged keys. It is performed periodically, and in some embodiments, it is performed as often as daily, but shorter and longer periods can be implemented. The Key Roll results in an exchange of the keys outlined in Communication Keys and Key Encryption Keys detailed above.

[00132] Transactions

[00133] The general flow for processing a transaction according to some embodiments will now be described with reference to steps 1 to 14 in FIG 11 and to FIG 12.

[00134] At step 1 , the merchant tenders an amount to the application 110 running on the mobile device 106.

[00135] At step 2, the application 110 starts the transaction to the library 130, running on the mobile device.

[00136] At step 3, the library 130 sends meta data for the transaction to the backend server 102 and receives a key in the form of a Transaction Data Encryption Key (TDEK) from the backend server 102 to protect the card data.

[00137] At step 4, the library 130 causes the mobile device 106 to display a prompt for the presentation by the customer of a payment device, such as a card or another mobile device acting as a payment device. The customer presents their payment device to the mobile device 106 to provide the payment data relating to the financial account.

[00138] At step 5, the library 130 encrypts the payment data relating to the financial account and communicates the encrypted data to the backend server 102. [00139] If a PI N is required to process the transaction, for example, if the amount is equal to or above a threshold amount or due to another setting relating to the financial account, the library 130 requests and receives from the backend server 106 a key in the form of a Transaction PIN Encryption Key TPEK to protect the PIN.

[00140] At step 6, the library 130 causes the application 110 to display a prompt for PIN entry and the customer enters their PIN via the mobile device 106.

[00141] At step 7, the library 130 encrypts the PIN and communicates the encrypted PIN to the backend server 102.

[00142] If no PIN is required to process the transaction, the PIN entry steps are skipped.

[00143] At step 8, the backend server 102 assembles a full transaction message or transaction request using the encrypted payment data and PIN, if required, and submits the transaction message to the payment gateway. [00144] At step 9, the payment gateway submits the transaction message to the acquirer 104, such as a financial institution, for the merchant.

[00145] At step 10, the acquirer 104 returns the transaction result, such as approved or declined, to the payment gateway.

[00146] At step 11 , the payment gateway returns the transaction result to the backend server 102.

[00147] At step 12, the backend server 102 returns the transaction result to the library 130 on the mobile device 106.

[00148] At step 13, the library 130 returns the transaction result to the application 110 running on the mobile device 106.

[00149] At step 14, the library 130 sends confirmation of the transaction result, or a request to reverse if an error condition has occurred, to the backend server 102.

[00150] It should be appreciated that depending on the security strategies to protect the payment data and PIN, one or more of the above steps may differ.

[00151] During steps 3 and 5, keys from Sensitive Data Keys detailed herein are provisioned and securely transmitted back to the library 130, as shown in FIG 12. [00152] Further details of the transaction process will now be described.

[00153] Initialisation of Transaction

[00154] To perform a transaction the merchant must input the transaction details into the application 110. The mobile device 106 sends the transaction details to the back-end server 102. The transaction details can include the type of transaction, such as a purchase or refund, the amount of the transaction, a reference, such as a transaction identifier provided by the application, and a currency. The back-end server 102 creates a record for the transaction and generates an appropriate symmetric key to protect the customer’s payment details and transmits the symmetric key securely back to the mobile device 106.

[00155] Collection of the payment Details (e.g. Card-Holder Card Data)

[00156] The mobile device 106 displays a prompt for presentation of the payment device by the customer. Collection of the payment details can be achieved using Near Field Communication (NFC), or other known contactless protocol, or another known method, such as by reading the Integrated Circuit (IC) chip of a smartcard. A Europay Mastercard VISA (EMV) kernel 122, 124, 126 or other kernel 130 operates with the Rich Operating System 132 with bindings to the hardware interface layers of a presentation interface or graphical user interface (GUI). The EMV kernel 122, 124, 126 or other kernel 130 uses the presentation interface to communicate with the payment device (e.g. card) as per EMV standards defined by EMVCo, LLC, or other applicable standards. The EMV kernel 122, 124, 126 generates an EMV cryptogram which can then be encrypted using the symmetric key provided from the back-end server 102. The EMV kernel 122, 124, 126 contains sensitive data from the cardholder’s payment device and is kept secure. In preferred embodiments, as soon as the sensitive data is encrypted, the un-encrypted sensitive data and the encryption key are immediately deleted and removed from memory. The mobile device 106 then sends the encrypted payment data to the back-end server 102 along with any Cardholder Verification Method (CVM) indicators provided by the EMV kernel 122, 124, 126. The back-end server 102 stores the encrypted payment data in memory and inspects the CVM indicators. If the CVM indicators indicate the PIN must be requested then "Collection of Card-Holder PIN" must be performed, otherwise the back-end server 102 continues with "Processing of Transaction". It should be appreciated that other CVMs could be used, such as the provision of a signature or biometric data, such as a fingerprint, which can be captured by the screen, or other hardware component, of the computing device.

[00157] Collection of Card-Holder Verification

[00158] If the back-end server 102 determines that the PIN is required to complete the transaction, the back-end server generates an appropriate symmetric key to protect the PIN and transmits the symmetric key back to the mobile device 106. The mobile device then displays a keypad 142, as shown in FIG 13, to allow the customer to enter their PIN in a secure manner. According to some embodiments, the PIN data is formed into a secure format, such as a PIN block format as per ISO 9564, such as format 1 , and then immediately encrypted using the symmetric key provided from the back-end server 102. However, if other encryption protocols are used, other formats may be required, such as format 4, to ensure that the Primary Access Number (PAN), i.e. the card number, is kept separate from the PIN.

[00159] The mobile device 106 then sends the encrypted PIN block to the back- end server at step 7. The back-end server 102 matches the received encrypted PIN block with the encrypted card data previously received at step 5.

[00160] The mobile device may, in some implementations, indicate that an alternative Card-holder Verification Method (CVM) has been provided, such as a fingerprint or other biometric data, or the back-end server 102 may determine that a CVM other than a PIN, such as a signature, is required to be collected by the mobile device. If a CVM has been provided, the back-end server 102 may choose to process the transaction with that CVM. If a CVM other than a PIN is required, the mobile device would be required to collect that CVM, for example via the screen of the mobile device, or other hardware component, and transfer it to the back-end server 102 in an appropriate and secure manner.

[00161] Processing of Transaction

[00162] The back-end server 102 performs any re-encryption and transformations, such as PIN block transformation, to prepare the encrypted payment data and encryption PIN block for transmission to the upstream acquirer, payment scheme, or financial institution. Once the back-end server 102 has re-encrypted and transformed the data, the backend server deletes the original symmetric encryption keys used to receive that data. This data may then pass through interim servers or need to be re-encrypted or transformed multiple times before eventually reaching the acquirer, payment scheme, or financial institution 104 endpoint. The endpoint uses the provided information to verify and either approve or decline the transaction and then sends the result back to the back-end server 102. The back-end server records the result of the transaction and forwards the result to the mobile device 106. Once the mobile device receives the transaction result, the result details are stored and presented to the user. At this point from the merchant and customer perspective the transaction is complete and may be either approved or declined as defined by the result from the back-end server 102.

[00163] Confirmation of Transaction

[00164] After the mobile device 106 has received the transaction result, the mobile device sends a confirmation message to the back-end server 102 to indicate that the mobile device has received the result. This message must eventually reach the back-end server 102 and in some circumstances the message may need to be queued using a message queue to ensure that it eventually reaches the back-end server. This process is known as "clearing". Once the back-end server 102 receives the confirmation message it can perform any final clean-up or logging of the transaction internally and forward it to other systems if necessary. At this point the transaction is final and the result can never be changed.

[00165] Reversal of Transaction [00166] If at any point before "Clearing of Transaction" an error occurs, there is an option for the mobile device 106 to reverse the transaction. An error may occur because of, for example, a network timeout, corruption of data, loss of power, a crash, or any other failure of the mobile device 106, back-end server 102 or communications. When reversing a transaction, the mobile device 106 must send a reversal message to the back-end server to indicate that it was unable to receive a valid result. This message must eventually reach the back-end server 102 and therefore may need to be queued using a message queue to ensure that it eventually reaches the back-end server. This process is known as "clearing".

[00167] Once the back-end server 102 receives the reversal message it must send an appropriate reversal message to the upstream acquirer, payment scheme, or financial institution 104. This reversal must reach the upstream acquirer, payment scheme, or financial institution and therefore may need to be queued using a message queue to ensure that it eventually reaches the acquirer, payment scheme, or financial institution 104. The back-end server 102 can also perform any final clean-up or logging of the transaction internally and forward it to other systems, if necessary, upon receipt of the reversal. At this point the transaction is final and the result can never be changed.

[00168] Cancellation of Transaction

[00169] If at any point before "Processing of T ransaction" the merchant chooses to cancel the transaction by performing an appropriate cancel action, such as a button press, in the application 110 on the mobile device 106, the app should send a cancel message to the back-end server 102 to request cancellation of the transaction. The back-end server must verify that the transaction is in a state in which a cancel action is possible, and that the transaction has not yet been transmitted to the upstream acquirer, payment scheme, or financial institution 104. If the transaction cannot be cancelled, then the cancel message is ignored and an appropriate failure to cancel message is sent to the mobile device 106. If the transaction can be cancelled then the transaction is marked as declined due to cancellation, and this transaction result is recorded and communicated to the mobile device 106. The back-end server 102 can also perform any final clean-up or logging of the transaction internally and forward it to other systems if necessary. At this point the transaction is final and the result can never be changed.

[00170] Protection of Payment Data (e.g. Card Data) [00171] When the payment data (e.g. card data) is received by the mobile application 106, the payment data is processed inside the EMV kernel 122, 124, 126 or other kernel 130 and immediately encrypted using the relevant symmetric encryption key. As soon as the data is encrypted, the relevant symmetric key is deleted from the mobile device 106 and the payment data is cleared from memory.

[00172] Protection of PIN

[00173] For higher value transactions, or in accordance with one or more other settings associated with the financial account, a PIN may be needed as a form of Cardholder Verification Method (CVM). The PIN must be securely entered into the mobile device 106 and securely provided to the back-end server 102. Usually the PIN is formatted into a "PIN Block" on the mobile device 106 before being provided to the payment gateway and then to the acquirer. On traditional payment terminals this process is made secure using secure hardware components to ensure that the PIN digits are kept secret during entry and transmission. Consumer devices, such as commercial off the shelf (COTS) mobile phones or tablets do not have the same level of secure hardware which means that a skilled attacker may be able to employ various methods in an effort to intercept or detect the PIN during entry or transmission. The library 130 or application 110 protects the PIN using one or more of the following techniques.

[00174] Streaming Keypresses to the Back-end Server

[00175] Once such method of attack may be to observe the memory of the mobile device 106 at the time of PIN entry such that the attacker can observe the full PIN. During PIN entry, the PIN is stored in full in memory before it can be encrypted and transported to the payment gateway and subsequently to the acquirer 104. One method to minimise the exposure of the PIN within memory on the mobile device 106 is to secure and then stream each touch-event directly to the back-end server 102. Once each touch-event arrives at the back-end server, the PI N and resulting PI N Block can be assembled on the back-end server 102 from the series of streamed touchevents. This ensures that the full PIN is never stored in memory and at most, only a single digit of the PIN is in memory at any point in time.

[00176] One technique is to directly stream touch-events that represent the exact button pressed. This buttons or keys displayed represent the digits 0 to 9, a backspace, optionally an OK (or done) and optionally a clear. [00177] Another technique is to stream the co-ordinates of each touch-event instead of the specific button pressed. In order to do this the back-end server 102 also needs to be provided within information about the co-ordinates of the PIN entry on the mobile device 106, such as the width, height, and offset. This approach provides slightly additional protection through obscuring the meaning of each touch-event. For streaming of the touch-event the data is encrypted for transmission preferably using an asymmetric key to minimise the possibility of an attacker getting access to the data. For example, each touch-event can be padded and encrypted using a 2048-bit RSA using RSAES-OAEP with a known public key for decryption at the back-end server 102. An example is described below.

[00178] Consider Key A is the public key for a 2048 bit RSA key-pair for which the private key is held by the back-end server 102. The transaction progresses to the PIN entry stage and the mobile device displays a PIN entry keypad as shown in FIG 13. In this example, the PIN entry keypad comprises keys representing the digits 0 to 9, backspace and OK. The card-holder taps '5' on the keypad. '5' is padded and encrypted using key A and is sent to the back-end server. The card-holder taps '6'. '6' is padded and encrypted using key A and sent to the back-end server 102. If the ‘6’ has been entered in error, the card-holder taps 'backspace' to delete the entry, 'backspace' is padded and encrypted using key A and is sent to the back-end server 102. The card-holder taps '4'. '4' is padded and encrypted using key A and sent to the back-end server. The card-holder taps '3' on the keypad. '3' is padded and encrypted using key A and sent to the back-end server 102. The card-holder taps '2'. '2' is padded and encrypted using key A and sent to the back-end server. The card-holder taps 'OK'. 'OK' is padded and encrypted using key A and sent to the back-end server 102. PIN entry is thus completed. The back-end server decrypts the touch-events and assembles the decrypted touch-events in order into a Key Block which can be used for further processing of the transaction.

[00179] Another technique is to scramble, jumble or shuffle the location of the keys displayed on the screen such that the keys representing the numbers are in a different location each time.

[00180] Securing the Insecure Screen

[00181] Due to the insecure nature of the Rich Operating System 132 and in particular the screen 136 of the mobile device 106, several types of attack exist that may allow an attacker to determine the entered PIN. One type of attack utilises Android accessibility capabilities to detect key presses. Android's accessibility framework allows certain applications to have full access to the screen and screen inputs. Another type of attack involves enabling Android developer tools, such as "show touches", to visually indicate inputs on the display. A further type of attack involves taking screenshots or screen recordings to determine when digits are entered. Screenshots or screen recordings could be used if an attacker can cause visual feedback to appear on the screen for each key-pressed or could be used to determine the exact time a key was pressed in order to observe memory. Another type of attack involves placing hidden or misleading overlays on top of the PIN collection user interface (III) to intercept and collect tap events. Yet another type of attack involves observing memory in use during PIN entry to observe the value of each keypress.

[00182] In order to minimise the exposure of the PIN within memory on the mobile device, one or more of the following steps are taken to obfuscate the entry of the PIN and to otherwise make it difficult for an attacker to determine the digits that constitute the final PIN.

[00183] Protection against an attacker utilising Android accessibility services is achieved by checking if the System Accessibility Service (SAS) is enabled and blocking PIN entry if the SAS is enabled.

[00184] Protection against an attacker enabling tools to visually indicate inputs on the display is achieved by specifically checking the system settings for the status of "show_touches" and "pointerjocation" and disabling PIN entry if they are detected as enabled. These values should be continuously checked for the duration of the PIN entry process as well as on each touch input in order to detect the settings being enabled at any point during the PIN entry process. For example, to detect the "show_touches" status, the code Settings. System. getlnt(context

,getContentResolver(), "show_touches", 0); should be used.

[00185] Protection against screenshots and screen recording is achieved on Android by marking the display window using the LayoutParams. FLAG_SECU RE flag. In addition to this, any visual feedback, such as highlights, audible feedback, such as beeps, and sensory feedback, such as vibrations, should be disabled for all types of input for the duration of the PIN entry process.

[00186] Protection against an attack using hidden or misleading overlays on top of the PIN collection III to collect tap events is achieved on Android by a) detecting if the mobile application 110 is running in multi-window mode and aborting PIN entry if it is; and/or b) checking all touch-events to determine if the event has the FLAG_WINDOW_IS_OBSCURED flag set or the FLAG_WINDOW_IS_PARTIALLY_OBSCURED flag set and aborting PIN entry if either flag is set.

[00187] According to some embodiments, additional protections are included to make observation of memory difficult in order to limit an attacker’s ability to observe the values of each key press. These protections include one or more of the following: [00188] Using co-ordinates to derive the intended keypress rather than binding individual layout buttons to individual values. The co-ordinates for the PIN entry section of the Ul as well as all touch events are provided to the section of code responsible for deriving a value from each keypress.

[00189] Implementing the code to derive intended keypresses in Obfuscated-C rather than Java or Kotlin. The code to derive intended keypresses should take the overall co-ordinates of the PIN entry section of the Ul into account to determine what key the user intended to press. This code should run through several mutations of the data to further obfuscate the intention and logic of the code.

[00190] Triggering fake motion events using shell commands “shell input tap x y”, where x and y are randomised co-ordinates. These fake events should be triggered several times a second to make it difficult for an attacker to detect between real and fake keypresses. Fake keypresses should be generated and detected from the same Obfuscated-C code that derives the intended key press from the co-ordinates.

[00191] Logging

[00192] In order to maintain the state of security on mobile devices, in some embodiments, the security operations, failures, and general transaction processing information is logged and sent to the back-end server for analysis.

[00193] This data is preferably collected and sent to the back-end server 102 as soon as possible. Once the data has been successfully sent to the back-end server it is preferably removed from the mobile device 106 to minimise access to this data from a malicious user.

[00194] This logged data is preferably used by the back-end server 102 as an audit trail in order to detect anomalies and malicious actions and to assist with investigation of issues and unintended behaviour. The logs never contain any sensitive information such as Card Data or PIN information, but they can contain identification and attestation information relating to the mobile computing device processing the payment.

[00195] Device logs should be analysed on the back-end server automatically and/or manually for any anomalies. This data can be cross-referenced with attestation data or acted on by operational staff to block accounts or investigate certain merchants based on unusual log activity.

[00196] It should be appreciated that embodiments of the present invention can be used in scenarios in which the customer (i.e. the cardholder) installs an application downloaded to their computing device that provides in-store shopping or online shopping capabilities, such as an online store app, or a retail store app. In such scenarios, the in-store or online shopping app contains the application 110, or part thereof, or the electronic library, or part thereof providing the functionality described herein to enable the customer to use the NFC capability of their computing device to make contactless payments via their computing device.

[00197] In the case of in-store shopping, the customer can choose items in store and scan the barcode or other unique identifier for the product when they put the item in their shopping cart or basket. In the case of online shopping, the customer can choose items via the app to add them to a virtual cart or basket as is known for traditional e-commerce websites and apps.

[00198] When the customer is ready to check out, the customer makes the payment by tapping their own personal payment card on their own personal computing device, and optionally entering their PIN on their device, if necessary. This transaction would be processed as a full-EMV transaction (or other payment protocol) to the account of the merchant that is the owner of the retail store or e-commerce website.

[00199] Hence, in such scenarios, the customer is using their own computing device to order the goods (in the case of an online store), or record their selection of the physical goods (in the case of a physical retail store) and using their own computing device to pay a merchant for the goods by tapping their card and entering their PIN (if necessary) on their own computing device, rather than interacting with the merchant's computing device.

[00200] Another scenario applicable to the present invention is “in-app” purchases. For example, the customer (i.e. the cardholder) installs an application downloaded to their computing device. The application causes the device to scan a QR code or other code that enables the customer to make a purchase via the application. For example, the customer can download an application to hire a vehicle and make a purchase within the application, with the selection of any applicable options (e.g. upgrades, insurance etc.) and make payment via their device. Hence, the customer’s own device is used to make and receive payment via the application.

[00201] A further scenario applicable to the present invention is where the customer’s device scans a QR code or other code that directs the device to a website and purchases can be made via the website using the customer’s device. The application of the present invention installed on the customer’s device enables the customer to make payments via the website via their own device, for example, by tapping their own payment card on their own device, or by retrieving the payment card details from their own device if the payment apparatus is stored on the device in a tokenised form of or a virtualised form. The present invention can also enable the device to be used for identification and authentication purposes to satisfy “Know Your Customer (KYC) requirements. For example, the scanning capabilities of the device enable identification cards or documents, such as identification cards, medical cards, driver’s licenses and passports to be scanned for identification and authentication purposes.

[00202] It will be appreciated that whilst embodiments and aspects of the present invention have been described with reference to implementation in mobile computing devices 106, such as mobile phones, tablets, PDAs and the like, embodiments and aspects of the present invention can be implemented in other computing devices that are not, or are not usually mobile, such as stationary or temporarily fixed computing devices, for example, at any facility, establishment or location where it is desirable or necessary to be able to securely process an electronic transaction.

[00203] Whilst embodiments and aspects of the present invention have been described herein primarily with reference to implementation in the Android operating system, it will be appreciated that equivalent or corresponding commands, instructions and/or processes can be implemented for other operating systems, and in particular other Rich Operating Systems, such as, but not limited to iOS and Windows.

[00204] Hence, embodiments and aspects of the present invention address or at least ameliorate one or more of the aforementioned problems of the prior art by providing computing devices 106, and in particular mobile computing devices, such as mobile phones, tablets and the like with the capability to perform secure transactions. One advantage of the solutions of the present invention is that they can be run on any computing device with the appropriate payment device (e.g. card) reading ability and do not require the solutions or any underlying solution logic to be embedded into the computing device, such as in the secure element or Trusted Execution Environment (TEE) 140. Therefore, the solutions according to embodiments and aspects of the present invention can be implemented on such computing devices without requiring the involvement of the manufacturer.

[00205] In this specification, adjectives such as first and second, and the like may be used solely to distinguish one element or action from another element or action without necessarily requiring or implying any actual such relationship or order. Where the context permits, reference to an integer or a component or step (or the like) is not to be interpreted as being limited to only one of that integer, component, or step, but rather could be one or more of that integer, component, or step etc.

[00206] In this specification, the terms “comprises”, “comprising” or similar terms are intended to mean a non-exclusive inclusion, such that an apparatus that comprises a list of elements does not include those elements solely, but may well include other elements not listed.

[00207] Throughout the specification the aim has been to describe the invention without limiting the invention to any one embodiment or specific collection of features. Persons skilled in the relevant art may realize variations from the specific embodiments that will nonetheless fall within the scope of the invention.