Understanding the PCI-CPoC white-box requirement

Understanding the PCI white-box cryptography requirement for CPoC

Posted On

By Juris Olekss


PCI recently released a standard for mobile contactless payment applications that puts the spotlight on white-box cryptography. This unique technology enables secure payment processing in off-the-shelf devices without the dependency on specialized hardware. Its implications include lower software development complexity and costs, faster time to market, and wider device platform reach.

With the growing demand for “tap and go” payments, the Payment Card Industry Security Standards Council recently published a new standard for applications that use the near-field communication (NFC) interface in commercial off-the-shelf (COTS) phones and tablets to accept contactless payments. Called PCI Contactless Payments on COTS (CPoC): Security and Test Requirements (the “CPoC Standard”), it lays out a set of security principles and requirements to govern developers and vendors of CPoC solutions and for the labs that evaluate them.

While the CPoC Standard includes multiple components, the requirements in section 2.2, which deal with white-box cryptography (WBC), have created the most uncertainty and questions among companies developing applications that accept contactless payments. Although white-box cryptography is not a new technology, the CPoC Standard raises it to new levels of significance and scrutiny. This article clarifies the concept, and addresses potential questions relating to its use in the CPoC Standard.

What is white-box cryptography?

Protection of cryptographic operations traditionally has been provided by special-purpose tamper-resistant hardware components, such as hardware security modules (HSM), trusted platform modules (TPM), Secure Enclaves (SE), and trusted execution environments (TEE). The security of these components relies on the fact that it is very difficult and expensive for attackers to reverse engineer a hardware module and observe or manipulate its internal data. Generally speaking, hardware security systems like the Android Keystore, or the iOS Keychain can be considered black-box models because their internal workings are essentially hidden to the observer. Although these types of internal hardware systems are becoming more common in COTS devices, support for them is not universal. Moreover, their design or features frequently do not allow secure implementation for a CPoC application.

This is where the concept of white-box cryptography comes into play. As opposed to the previously described black-box model, the white-box model assumes that the internal workings of an algorithm are visible and modifiable. When applied to cryptography, this means that a software-only implementation of cryptographic algorithms must be sufficiently secure such that the secret cryptographic keys are encrypted and hidden at all times (even at runtime). The CPoC Standard defines white-box cryptography as “a method used to obfuscate a (mostly symmetric) cryptographic algorithm and key with the goal of making determination of the key value computationally complex.”

Secure Key Box is whiteCryption’s solution in this space, with options to use AES, RSA, ECC, and other ciphers securely.

PCI white-box security requirements

White-box cryptography provides developers cryptographic security in open and untrusted execution environments, where secure hardware components are not available or acceptable. Under the new standard, PCI essentially mandates white-box cryptography to become an integral part of contactless payment systems on COTS. How so? Since availability of hardware-based security modules is not uniform across the many different types of devices globally, white-box cryptography is required as a substitute for device-dependent cryptography where the underlying hardware support is lacking (a situation called “hybrid implementation” in the CPoC Standard). 

A software-only implementation reliant solely on white-box cryptography is also now an acceptable option for attaining a PCI Letter of Approval.

Digging into the specifications

Compared to hardware-based cryptography, white-box cryptography offers developers and vendors obvious advantages in terms of speed to market, ease of deployment and upgrade, portability, and cross-platform support. But it brings the inherent disadvantage of being more prone to attacks, since it is easier to manipulate code or device memory than to hack a hardware chip’s circuits and electrical signals. Given this, how could PCI choose it as an acceptable CPoC security protocol? By defining eight essential security requirements that applications implementing white-box cryptography must meet:

  1. Cryptographic methods protected primarily by software-based methods must be protected against analysis and abuse.

The CPoC Standard details specific expectations regarding secure key generation, how the software-based protection should be implemented, and what attacks it must be ready to withstand. This demands a deep knowledge of software obfuscation and data protection techniques from the engineering team.

  1. The robustness of the software-based protection mechanisms must be evaluated, at least annually, against current attack scenarios and vectors.

This requires the ongoing involvement of security labs, researchers, and payment domain security experts in the development process who must regularly produce analysis documentation of potential threats, difficulty thereof, mitigation techniques, and so on.

  1. The cryptographic material used in software-based protection mechanisms, such as white-box keys, entropy seeds and nonces, must be changed periodically to prevent cryptographic key compromise.

This point has probably generated the most controversy, because it requires the application developer to change the white-box implementation and cryptographic keys at least once a month. While the actual implemented algorithms may not need to change, the way they are encoded in tables or otherwise has to change regularly to minimize the risk of breach. The simplest way to achieve this is to release a new and slightly modified version of the application every month.

  1. Retired cryptographic material used in software-based protection mechanisms must be securely deleted no later than six months after initial deployment of CPoC application versions using those keys.

This requirement goes hand-in-hand with the previous one. Primarily, this means that when a new set of keys is established every month, the old set of keys must be permanently deleted as soon as possible.

  1. The cryptographic material used in software-based protection mechanisms must not be used directly for account data or attestation data encryption.

Each key used in white-box cryptography must be used for one purpose only, and they must not be used directly for the encryption of account data or for directly securing any other communications that are part of the overall solution security, such as attestation data. No sharing of keys allowed.

  1. Cryptographic keys that are protected primarily with software-based methods must be unique per CPoC application version and instance of the OS store.

To achieve this goal, each version of the application for each OS store type (such as the App Store and Google Play) and geographical region must be unique. This involves creating and deploying an appropriate key provisioning system allowing effective and secure generation and distribution of keys for each unique global market.

  1. Cryptographic algorithms and keys used in software-based protection mechanisms must meet the security requirements of acceptable cryptography.

It is important that only industry-recognized standard cryptographic algorithms, key lengths, and other implementation methodologies be the basis for any security services used in the solution. The criteria for acceptable cryptography are described in section 1.3 of the CPoC Standard.

  1. Cryptographic keys used in software-based protection mechanisms must meet the established key management requirements.

Cryptographic keys must be managed securely using recognized industry practices throughout their cryptographic lifecycle, including generation, distribution, storage, replacement, revocation, deletion, and accountability. The criteria for established key management requirements are described in section 1.4 of the CPoC Standard.

What to look for in a white-box cryptography solution

As a developer or vendor of contactless or mPOS based payment systems on COTS, the number and stringency of the security requirements expected by the CPoC Standard can quickly become overwhelming. For most, in-house development of a white-box cryptography module is virtually impossible, especially those aiming to get to market as swiftly as possible. This is where third-party developers specializing in white-box cryptography and software tamper resistance come in.

While several companies offer such solutions, CPoC solution providers must set their bar high. The maturity, reputation, range of offered services, ciphers available, supported platforms, and integration methodologies of such companies’ products all should be reviewed carefully. With the right provider, you can ensure application security, flexibility, and compliance with PCI standards, while saving time and costs over in-house research and development.

whiteCryption Secure Key Box

An increasing number of key players in the banking, finance, and payments industry are choosing whiteCryption Secure Key Box™ (SKB) to implement their selected cryptographic security posture.

whiteCryption Secure Key Box (SKB) is a library providing a secure white-box implementation of industry-recognized standard cryptographic algorithms. It is part of the whiteCryption application shielding suite from Intertrust.

The SKB white-box implementation ensures that your keys always stay encrypted and protected, even when in use. This fundamental feature prevents hackers from extracting keys from your applications using either static or dynamic methods. SKB is supported on most operating systems, including Android, iOS, Windows, MacOS, and Linux, and popular programming languages, including C, C++, Objective-C, Android Java, Kotlin, and JavaScript. 

SKB addresses PCI CPoC white-box requirements

whiteCryption SKB helps you comply with all the requirements laid out in the CPoC Standard section 2.2. It is designed and built from the ground up with robust protection against analysis, tampering, and reverse engineering. It undergoes regular penetration testing by third-party experts and our own team of researchers constantly monitor and analyze its implementation in the context of existing and emerging attack vectors. SKB’s incorporation of strong cryptographic diversification ensures keys are never reused or otherwise used in a manner inconsistent with PCI requirements. It also makes it easy to update the cryptographic implementation monthly as required by the standard.

Expertise in PCI CPoC compliance

whiteCryption researchers and developers have been working over a decade to perfect the algorithms and techniques underlying SKB and protecting it from attacks. The security of whiteCryption products has been tested by security labs such as Riscure, and audited and certified by NIST. whiteCryption technology protects some of the largest names in the finance, health, entertainment, and automotive industries across the globe, and is used by a number of players in mPOS, tap to phone, and payment processing services on COTS, such as Felix Payments (Gentek Global). Our team has worked hand-in-hand with these companies throughout their PCI testing and documentation process.

To find out more about how Intertrust and whiteCryption deliver world-class protection for your software-based cryptography implementation, read this white paper or reach out to us today.

Juris Olekss

About Juris Olekss

A seasoned security professional, Juris has spent more than 17 years in the IT and security industries, with the majority dedicated to software security. Juris currently serves as a Senior Technical Writer for Intertrust’s whiteCryption application shielding solutions.