Complying with the latest PCI MPoS payment standard—CPoC

Posted On

By Paul Butterworth


The Payment Card Industry (PCI) Security Standards Council is the body that defines all the standards around card payment security. If you develop applications or build devices that interact with payment cards, PINs, or customer payment data, then you are probably familiar with the PCI council—it’s their standards that ensure the systems, card data, and PINs are kept secure. 

A short history of MPoS

Their latest standard, called Contactless Payments on COTS (CPoC™), enables a standard Android mobile device (also known as a COTS—a commercial off-the-shelf handset) to become a contactless payment acceptance terminal. It enables a standard mobile phone to take payments from contactless cards and other contactless payment methods such as Apple Pay. It’s the next evolution of Mobile Point of Sales (MPoS) systems, which have been changing fast since Twitter founder Jack Dorsey launched Square back in 2010. Square used a simple magnetic-stripe reader dongle that plugged into the headphone jack on mobile phones, enabling people to accept card payments from magnetic-stripe cards. Square was quickly followed by iZettle in Sweden and a raft of other innovative companies, who delivered a number of different card readers—some connected by cable, more recently Bluetooth, some with an integrated PIN pad enabling full chip-based card payments. The main issue with the readers containing PIN pads is the cost. The high bar for both physical and logical security required for PINs means that the devices need to achieve certification against the PCI PED standards. This increases the cost of the devices significantly. 

The next evolution, which started in 2018, was to remove the PIN pad from the reader, so it became a connected card reader only, and to move the PIN entry to the smartphone. This is called software-based PIN entry on COTS (SPoC). It’s still in its infancy, and these solutions are just rolling out. Security for these solutions relies on the fact that different encryption keys are used, held in different devices, to separately encrypt the PIN from the card data. The phone encrypts the PIN with one key and the card reader encrypts the card data with another. As long as these keys are stored securely and kept separate, and the pieces of data are encrypted with the different keys, then security is maintained. A PIN alone, without any card or customer data, is just a random four-digit number.

What is CPoC?

Back to the subject at hand—CPoC can be seen as an evolution of SPoC, removing the need for a separate card reader. However, removing the card reader also eliminates the ability to enter a PIN, as key separation is no longer possible. That means that CPoC, for now at least, can only be used for non-PIN-based transactions. So for transactions initiated from a card, they need to be below the contactless limit (£30 in the UK, up to €30 in Europe and $100 in the US). However, if payments come from a mobile wallet like Google Pay or Apple Pay, then transactions can be for any amount as the cardholder is required to perform cardholder verification through the biometric reader on the device. That authentication of the cardholder replaces the card PIN.

How to ensure it’s secure 

Given all this complexity, how do you maintain security in the mobile application? The standard addresses security in a number of ways—it mandates a combination of security mechanisms to be deployed into both the CPoC app running on the phone, as well as the back-end systems performing a number of risk management functions. In this article, I’ll only be referring to mobile device security requirements. 

Application shielding keeps you safe

The standards require that the CPoC application must have tamper resistance and reverse-engineering protection built in. It’s a given that applications in the field will get reverse-engineered, so developers need to ensure that it’s as difficult as possible and that, even if hacked, any output is incomprehensible. In addition, the device must be assumed to be untrusted, so the application needs to be developed in such a way that sensitive operations, data, and, most importantly, keys are protected. Some of the mechanisms suggested to provide this protection are through the use of code obfuscation, integrity checking, and white-box cryptography to protect the keys. 

There are a number of mechanisms available to provide obfuscation, all designed to reduce the efficiency of code decompilation tools and render the reverse-engineered code indecipherable. 

In this recent post I provide an overview of the obfuscation methods available.

Integrity protection to guard against code tampering, is also required. This can be delivered by using a tool that inserts many overlapping integrity checkers into the code as part of the build process. Each integrity checker validates that a section of the binary application hasn’t been tampered with, to stop people from removing the checkers, they overlap with each other in such a way that makes the process of removal very painstaking and cumbersome. The specifications mandate that if the application fails tamper checking, it must not accept account data. The Intertrust whiteCryption tools let the developer of the application choose the outcome of any detected threats. This is achieved through a feature that enables the calling of a specific function upon detection of a threat. This feature could be used to report the threat to a risk management platform, and for the application to be terminated cleanly before any card data is read.

Don’t forget to protect the keys

As well as obfuscating code and embedding integrity protection, it’s possibly even more important to protect the keys used in the application. The keys are what keeps the card and personal data secure. Get the keys, get the data. The specification mandates that if the keys are protected in software then they need to use technology such as white-box cryptography to ensure their safety. It’s also important that cryptographic material such as white-box keys, entropy seeds, and nonces, be changed periodically. This can be achieved with Intertrust’s market-leading whiteCryption Secure Key Box.

Proven contactless payment protection

If you are developing MPoS solutions, how can you be sure that you are choosing the best solution to both help achieve compliance and meet your development and business goals? When faced with this choice, payment system developers Gentek Global turned to Intertrust to secure their contactless payment solution without increasing dev time or complexity. 

Talk to one of our application security experts to learn more about our award-winning whiteCryption application shielding solutions, proven to help Gentek and multiple others protect their apps and achieve PCI compliance.


whitecryption CTA Banner

About Paul Butterworth

Paul Butterworth is an experienced payment and security professional, having spent almost 30 years in the card, payments and IT security industries. Paul is responsible for global product marketing for the Intertrust Secure Systems’ market leading application shielding and device identity solutions.

Related blog posts


How application protection helps HIPAA compliance

Read more


Top 2021 banking and fintech security regulations

Read more


Live optimized multi-DRM and anti-piracy services

Read more