Mobile payments have increased at a steady pace over the last decade: from 53 billion dollars in 2010 to 721 billion dollars in 2017[i].
The development of mobile payment solutions offered to the consumer fuelled this growth over the years, as well as the development and adoption of the Near Field Communication (NFC) technology. Since the launch of Apple Pay in 2014 [ii], several solutions were developed and are now available to consumers to pay using their smartphones NFC modules, from Google Pay and Samsung Pay on Android mobile phones on a global scale to other regional initiatives.
However, while payments made from a mobile device are becoming more common, payment solutions that merchants can use to receive payments are rarer.
Indeed, accepting payments with smartphones represents a technical challenge, especially in terms of security: smartphones are not all built with security in mind, and their versatility poses a higher risk, as more features and functionalities mean more possibilities for a vulnerability to appear and be exploited.
In December 2019, the PCI Security Standards Council released a new standard to secure contactless payments on commercial off-the-shelf devices called PCI Contactless Payments on COTS or PCI CPoC [iii].
This first version allows vendors to certify solutions intended to offer contactless and secure mobile payments software to merchants.
However, with this first version, only contactless transactions without PIN entry are allowed with PCI CPoC as of June 2020. While this seems to be a limiting factor in its adoption, this choice is due to security reasons.
In recent years, Strong Customer Authentication (SCA) has become common to reduce fraud, both in terms of regulation and technical solutions. EMVCo, for example, integrated SCA elements to its 3DS specifications to enhance the security level for online transactions where the customer cannot be authenticated.
In the EU, the PSD2 directive mandated SCA for certain operations, for example, when initiating an electronic transaction.
In this context, a customer must provide at least two of the following elements to authenticate:
—Something the customer must know (a PIN code)
—Something the customer possesses (credit card, mobile phones, …)
—Something the customer is (fingerprint, voice recognition, …)
Even if PSD2 applicability is limited to the European Union, the adoption of this directive represents a trend in the payment industry towards more security functions to reduce fraud.
It also explains why PIN entry is currently not permitted in PCI CPoC: using a smartphone device to accept payments is contrary to the customary usage of using approved PTS Point of Interaction solutions, which have been built with security in mind and integrates specific security features. The isolation of cardholder data such as the PIN and card chip information is necessary as an application, even with software protection mechanisms implemented, will not be as secure as a purpose-built physical device. [iv]
A PCI CPoC solution has schematically three components:
—A CPoC application:
This application is central in the solution and acts as an interface between the two other components: installed on the COTS device, it has the task of reading the card data thanks to the NFC kernel, encrypts it, and delivers it to back-end systems so that the transaction can be processed.
—A COTS device:
This is the mobile merchant device, a smartphone, or a tablet designed for mass-market distribution.
Their role is crucial in securing transactions. First, they will attest that the device is in a correct state and has not been tampered with. Then, they will monitor the transaction while taking place, discarding any attempts to tamper with the application, and finally, once the encrypted cardholder data has been received, process the transaction.
The PCI CPoC security model mandates the implementation of different security features for each component.
The CPoC application, due to its central role, represents an ideal target for potential attackers. Indeed, an attacker could have access to cardholder data by altering the CPoC application as it is an interface between the two other components.
In the 2.1 section ‘Tamper and Reverse-engineering Protection’ [v], solution vendors are to implement security measures to protect against tampering and reverse engineering.
Code obfuscation, a software protection mechanism which acts in scrambling the software logic and source code, is then required to protect against reverse engineering.
Environmental checks to detect if the device has been jailbroken, rooted, or executed in developer mode are also required.
The use of cryptography is also vital in the solution: tamper-resistant hardware mechanisms such as Secure Elements (SE) can be used for the generation and storage of cryptographic keys. However, SEs are available on a fraction of total smartphones, limiting the platforms on which the CPoC application could run. In this case, cryptography protected by software, such as white-box cryptography, can be used as a universal solution. The use of this software protection mechanism is covered in section 2.2 ‘Software-Protected Cryptography’[vi].
This feature can greatly help developers regarding key management, as the CPoC application should not store cryptographic keys or secrets in clear text (section 2.5.11)[vii].
The development and implementation of security features such as code obfuscation and environmental checks can be challenging for an organisation as they require a specific skill set. Moreover, the robustness of the CPoC application has to be tested during the evaluation process, industry-grade solutions are an excellent choice to shorten development time.
Quarkslab offers commercial-grade obfuscation, anti-tampering mechanisms, and white-box cryptography software, that can help you achieve excellent time-to-market for your application.
Quarks App Protect, our own application shielding software, can implement more than 25 obfuscation passes in your software, allowing you to focus on feature development. Environmental protections such as anti-root, anti-jailbreak, anti-debug, anti-hooking, and anti-dynamic analysis can also easily be added to your project thanks to security policies or annotations in your project’s code.
Quarks Keys Protect, our white-box cryptography library, is used to protect cryptographic keys in your application with reliable and proven algorithms, ensuring that keys are never stored in plaintext.
Quarks Digital Vault is a secure storage database that can be embedded within your mobile application to protect secrets and keys by using hardware cryptography, such as the cryptographic functions offered by the Trusted Execution Environment (TEE), or switch to using white-box cryptography when these platform features are not available.