This blog was originally posted on June 3, 2015 and was last updated on August 8, 2018
White box cryptography is just one example in a very broad field, so it is first important to understand the basics of cryptography itself.
What is cryptography?
Explained in basic terms, cryptography attempts to hide sensitive information from malicious users, whilst successfully communicating the message to the intended recipient.
Cryptography is most often associated with scrambling plaintext into ciphertext (a process called encryption), then back again (known as decryption).
Understanding white box cryptography
White box cryptography is an essential technology when it comes to minimizing security risks for open devices, such as smartphones. Devices have to be secured to avoid being analyzed or rooted.
On open devices, the cryptographic keys used for making a payment are observable and modifiable, rendering them vulnerable to attack. White box cryptography prevents the exposure of confidential information such as these keys. To do so, keys are obfuscated by not only storing them in the form of data and code, but also random data and the composition of the code itself.
This process makes it very hard to determine the original key, even though the cryptographic algorithms are openly observable and modifiable. It should be noted, however, that there is not a standard specification for white box cryptography, so implementations may vary.
Securing cloud-based payments
White box cryptography can be used to add an additional security layer to host card emulation (HCE)-based mobile payments, mitigating the risk caused by the absence of hardware security. It does this by hiding sensitive data within the mobile application.
Though white box cryptography resists reverse engineering threats to the cryptographic keys, anti-reverse engineering deterrents are also required to ensure the code surrounding the white box cryptography primitives remains intact. This could be done through native machine-code obfuscation, mangling Java Native Interface names and Java byte-code obfuscation. In addition, anti-tamper mechanisms may be applied, such as integrity checking and self-healing. In some cases, these techniques are deployed to detect reverse-engineering tools.
Whilst this would make mobile payments more secure, as each application’s code must be unique this can make implementations more complex and costly. Players should therefore consider a modular, layered approach that is tailored to their own requirements and strikes the right balance between security and convenience.