WO2022040762A1 - Systèmes, procédés et appareil de paiements électroniques - Google Patents

Systèmes, procédés et appareil de paiements électroniques Download PDF

Info

Publication number
WO2022040762A1
WO2022040762A1 PCT/AU2021/051008 AU2021051008W WO2022040762A1 WO 2022040762 A1 WO2022040762 A1 WO 2022040762A1 AU 2021051008 W AU2021051008 W AU 2021051008W WO 2022040762 A1 WO2022040762 A1 WO 2022040762A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
data
library
payment
transaction
Prior art date
Application number
PCT/AU2021/051008
Other languages
English (en)
Inventor
Tom Graham
Original Assignee
POQ Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2020903108A external-priority patent/AU2020903108A0/en
Application filed by POQ Pty Ltd filed Critical POQ Pty Ltd
Priority to AU2021329996A priority Critical patent/AU2021329996A1/en
Publication of WO2022040762A1 publication Critical patent/WO2022040762A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present invention is directed to the field of electronic payments and systems, methods and apparatus therefor.
  • 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.
  • 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.
  • PDAs personal digital assistants
  • mobile computing devices as payment terminals.
  • 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.
  • 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.
  • ROS Rich Operating System
  • 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.
  • 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.
  • PIN Personal Identification Number
  • 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.
  • 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.
  • 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.
  • mobile computing devices such as mobile phones, hand-held computers, tablets, personal digital assistants (PDAs) and other mobile computing devices
  • 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:
  • EMV Europay, Mastercard, VISA
  • MIFARE MIFARE protocols
  • PINs Personal Identification Numbers
  • CVM Card-holder Verification Methods
  • 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.
  • 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.
  • 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;
  • SSL Secure Sockets Layer
  • API Application Programming Interface
  • 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.
  • 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 library incorporates payment functionality into a third-party application, such as a third-party POS application.
  • a third-party application such as a third-party POS application.
  • the POS application, the library and one or more of the kernels interact with a Rich Operating System (ROS) of the computing device.
  • ROS Rich Operating System
  • 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 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).
  • TEE Trusted Execution Environment
  • 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 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.
  • API Android Package
  • 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.
  • an independent attestation system such as Android SafetyNet
  • the back-end server or the mobile device disallows the mobile device from performing a transaction and deletes any sensitive user or key material.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • UID User ID
  • 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.
  • 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 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.
  • 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 POS.
  • TDEK Transaction Data Encryption Key
  • 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
  • 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;
  • 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
  • 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
  • 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;
  • 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;
  • FIG 7 is a table showing the different types of encryption keys and their usage that can be used for the key encryption keys
  • FIG 8 is a table showing the different types of sensitive data encryption keys and their usage that can be used for sensitive data
  • FIG 9 is a diagram illustrating steps involved in a method of authenticating a merchant
  • FIG 10 illustrates a key roll process
  • FIG 11 is a general flow diagram for processing a transaction according to some embodiments of the present invention.
  • FIG 12 illustrates encryption processes involved in the transaction process shown in FIG 11 according to some embodiments of the present invention
  • FIG 13 shows the mobile device displaying a PIN entry keypad in accordance with some embodiments of the present invention.
  • 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.
  • a system 100 for securely processing electronic transactions 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.
  • SSL Secure Sockets Layer
  • API Application Programming Interface
  • 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.
  • 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.
  • 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.
  • EMV Europay, Mastercard, Visa
  • MIFARE MIFARE protocols
  • an appropriate kernel such as an EMV kernel or other kernel
  • NFC or other communication protocol such as Bluetooth
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • kernels/protocols 130 such as a MIFARE kernel/protocol
  • FIG 3 illustrates the architecture of a point of sale (PCS) application 110 comprising a library 130 for securely processing electronic transactions.
  • the library 130 can be used to incorporate payment functionality into a third-party application, such as a third-party PCS application.
  • 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.
  • TEE Trusted Execution Environment
  • the app or the library 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.
  • 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:
  • API Android Package
  • Any attestation data provided by cryptographic hardware such as Keystore attestation certificates on Android.
  • Device sensor data such as data from sensors such as accelerometers, cameras, and/or any other sensors in or on the device 106.
  • ROS Rich Operating System
  • 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.
  • some or all of the aforementioned data is provided to the back-end server 102 regularly, such as with every message.
  • 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.
  • 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.
  • a common strategy for breaching a Rich Operating System 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.
  • one or more of the following root detection strategies can be used for detecting root access:
  • the aforementioned searches and checks are performed in low-level software, utilising C code or assembly wherever possible.
  • the application 110 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.
  • I PC Inter-process Communication
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • AES Advanced Encryption Standard
  • RSA Rivest-Shamir-Adleman
  • 3DES Triple Data Encryption Standard
  • 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).
  • CBC cipher block chaining
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • step 2 the application 110 uses the provided credentials to authenticate the merchant to the library 132.
  • 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.
  • 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.
  • the back-end server 102 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.
  • 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.
  • All key exchanges include attestation data from the mobile device 106 which is documented under Attestation.
  • 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.
  • Client Initialisation KEK Client Initialisation KEK
  • 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.
  • 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.
  • step 1 the merchant tenders an amount to the application 110 running on the mobile device 106.
  • step 2 the application 110 starts the transaction to the library 130, running on the mobile device.
  • 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.
  • TDEK Transaction Data Encryption Key
  • 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.
  • 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.
  • the library 130 encrypts the payment data relating to the financial account and communicates the encrypted data to the backend server 102.
  • 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.
  • 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.
  • the library 130 encrypts the PIN and communicates the encrypted PIN to the backend server 102.
  • 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.
  • the payment gateway submits the transaction message to the acquirer 104, such as a financial institution, for the merchant.
  • the acquirer 104 returns the transaction result, such as approved or declined, to the payment gateway.
  • the payment gateway returns the transaction result to the backend server 102.
  • the backend server 102 returns the transaction result to the library 130 on the mobile device 106.
  • the library 130 returns the transaction result to the application 110 running on the mobile device 106.
  • 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.
  • the merchant 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.
  • 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.
  • NFC Near Field Communication
  • 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.
  • CVM Cardholder Verification Method
  • 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.
  • 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 displays a keypad 142, as shown in FIG 13, to allow the customer to enter their PIN in a secure manner.
  • 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.
  • a secure format such as a PIN block format as per ISO 9564, such as format 1
  • 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.
  • PAN Primary Access Number
  • 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.
  • 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.
  • CVM Card-holder Verification Method
  • 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.
  • the backend server 102 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.
  • the mobile device 106 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.
  • 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.
  • 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.
  • a PIN may be needed as a form of Cardholder Verification Method (CVM).
  • CVM Cardholder Verification Method
  • the PIN must be securely entered into the mobile device 106 and securely provided to the back-end server 102.
  • 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.
  • PIN Block 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.
  • the library 130 or application 110 protects the PIN using one or more of the following techniques.
  • 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.
  • 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.
  • the data is encrypted for transmission preferably using an asymmetric key to minimise the possibility of an attacker getting access to the data.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • attack 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.
  • SAS System Accessibility Service
  • 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
  • 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.
  • the security operations, failures, and general transaction processing information is logged and sent to the back-end server for analysis.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the customer 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.
  • 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.
  • 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.
  • Another scenario applicable to the present invention is “in-app” purchases.
  • the customer i.e. the cardholder
  • the application causes the device to scan a QR code or other code that enables the customer to make a purchase via the application.
  • 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.
  • the customer’s own device is used to make and receive payment via the application.
  • 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.
  • KYC Know Your Customer
  • 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.
  • 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.
  • TEE Trusted Execution Environment

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

Selon l'invention, une application, telle qu'une application de point de vente, ou une bibliothèque de logiciels qui peut être incorporée dans une application, est sauvegardée dans la mémoire d'un dispositif informatique pour permettre au dispositif de traiter des transactions électroniques en toute sécurité. Le dispositif peut effectuer une ou plusieurs actions parmi i) l'authentification du marchand pour assurer que le marchand est un marchand valide; ii) des opérations cryptographiques sécurisées pour protéger des données sensibles; iii) la collecte sécurisée de références de paiement, comme des références de carte de titulaire de carte par le biais d'un ou plusieurs protocoles de paiement, en utilisant un noyau par le biais d'un lecteur du dispositif; iv) la collecte sécurisée de numéros d'identification personnelle (PIN) ou d'autres procédés de vérification de titulaire de carte (CVM) par le biais d'une interface sécurisée; v) la collecte et/ou la vérification de l'intégrité et/ou d'informations d'attestation pour valider l'intégrité d'un dispositif pour assurer que le dispositif n'a pas été compromis d'un point de vue de sécurité; vi) la communication avec un serveur dorsal sécurisé.
PCT/AU2021/051008 2020-08-31 2021-08-31 Systèmes, procédés et appareil de paiements électroniques WO2022040762A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2021329996A AU2021329996A1 (en) 2020-08-31 2021-08-31 Electronic payments systems, methods and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2020903108 2020-08-31
AU2020903108A AU2020903108A0 (en) 2020-08-31 Electronic payments systems, method and apparatus

Publications (1)

Publication Number Publication Date
WO2022040762A1 true WO2022040762A1 (fr) 2022-03-03

Family

ID=80352197

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2021/051008 WO2022040762A1 (fr) 2020-08-31 2021-08-31 Systèmes, procédés et appareil de paiements électroniques

Country Status (2)

Country Link
AU (1) AU2021329996A1 (fr)
WO (1) WO2022040762A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015183176A1 (fr) * 2014-05-26 2015-12-03 Leong Tet Fei Edward Système de paiement électronique et procédé de paiement
US20180068295A1 (en) * 2015-10-15 2018-03-08 Hankooknfc, Inc. Mobile card payment system for performing card payment between mobile communication terminals and method therefor
US20180225653A1 (en) * 2017-02-03 2018-08-09 Worldpay Limited Terminal for conducting electronic transactions
US20200065805A1 (en) * 2016-12-28 2020-02-27 Capital One Services, Llc Smart card secure online checkout

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015183176A1 (fr) * 2014-05-26 2015-12-03 Leong Tet Fei Edward Système de paiement électronique et procédé de paiement
US20180068295A1 (en) * 2015-10-15 2018-03-08 Hankooknfc, Inc. Mobile card payment system for performing card payment between mobile communication terminals and method therefor
US20200065805A1 (en) * 2016-12-28 2020-02-27 Capital One Services, Llc Smart card secure online checkout
US20180225653A1 (en) * 2017-02-03 2018-08-09 Worldpay Limited Terminal for conducting electronic transactions

Also Published As

Publication number Publication date
AU2021329996A1 (en) 2023-05-18

Similar Documents

Publication Publication Date Title
US11240219B2 (en) Hybrid integration of software development kit with secure execution environment
CN112602300B (zh) 用于非接触式卡的密码认证的系统和方法
US10135614B2 (en) Integrated contactless MPOS implementation
CN107251595B (zh) 用户和移动装置的安全认证
US9904919B2 (en) Verification of portable consumer devices
US9372971B2 (en) Integration of verification tokens with portable computing devices
US9361619B2 (en) Secure and convenient mobile authentication techniques
DK2622585T5 (en) PIN verification for hubs and spokes
EP2733655A1 (fr) Procédé et dispositif de paiement électronique pour échanger de manière sécurisée des informations de paiement
US20090222383A1 (en) Secure Financial Reader Architecture
EP2098985A2 (fr) Architecture sûre pour lecteurs financiers
WO2016130764A1 (fr) Autorisation de transfert homologue de demandes numériques
JP6498192B2 (ja) オンライン取引の検証ステップを安全にするための方法
US8620824B2 (en) Pin protection for portable payment devices
EP3394778B1 (fr) Procédé et système pour améliorer la sécurité d'une transaction
US20190347661A1 (en) Coordinator managed payments
WO2016118087A1 (fr) Système et procédé de paiement en ligne sécurisé au moyen d'une carte à circuit intégré
CN112639854A (zh) 非接触式卡的密码认证的系统和方法
US20110022837A1 (en) Method and Apparatus For Performing Secure Transactions Via An Insecure Computing and Communications Medium
US20210383335A1 (en) Systems, methods, and computer program products providing an identity-storing browser
US20210390546A1 (en) Systems and Methods for Secure Transaction Processing
WO2022040762A1 (fr) Systèmes, procédés et appareil de paiements électroniques
CA3186376A1 (fr) Segmentation en unites de traitement de post-paiement dans un traitement de paiement de commercant

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21859430

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021329996

Country of ref document: AU

Date of ref document: 20210831

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 21859430

Country of ref document: EP

Kind code of ref document: A1