White-Box Cryptography in the mobile world


The use of White-Box Cryptography is gaining more and more popularity in the mobile world. The implementation of this technology poses some challenges for those that are researching the security of apps, both client side as server side.

From a pentester’s point of view you’d like to see both the plain text data that is exchanged between app and backend, but in a lot of cases also like to tamper with this data. This means that you’ll need to tap into the app (hook the app) or preferably break the White-Box Cryptography altogether.

In this blog series, I’ll dive into the application of White-Box Cryptography in the Mobile World. And also explain how one could break White-Box Cryptography implementations.

What is White-Box Cryptography?

The main concept of White-Box Cryptography is to embed both the static key (in the form of data but also in the form of code) and random data in a composition from which it is hard to derive the original key.

One of the main design principles in cryptography is the Kerckhoffs’ principle. This principle states that a cryptosystem should be secure even if everything about the system, except for the key, is public knowledge.

White-Box Cryptography aims to withstand similar public scrutiny. Not only does the attacker have full access to the implementation, the attacker also knows which algorithm is implemented, and what white-box protection techniques are applied. Its security relies on the confidentiality of the secret key and the random data.

The first white-box implementations were presented by Chow et al. in 2002 on the DES and the AES algorithms respectively. Their white-box techniques transform a cipher into a series of key-dependent lookup tables. The secret key is hard-coded into the lookup tables and converted into a representation where the operations on the secret key are combined with random data and code, in such a way that the random data cannot be distinguished from key information.

Problematic of traditional cryptography in mobile apps

Cryptography is increasingly deployed in applications that are executed on open devices, such as PCs, tablets or smartphones. In most implementations, there is a need to store and manage the encryption key on the device itself. This makes it very hard to protect the key. An attacker that manages to compromise the device can extract the key from it and get access to every secret managed by the application.

A clear example of this new paradigm can be seen in modern software solutions such as mobile contactless payment applications (digital wallets) or applications enforcing Digital Right Management (DRM) schemes such as Spotify or Netflix. Any of these applications need to protect critical data that is stored in a device that is potentially owned by an attacker.

The main tool to protect this sensitive data is cryptography, but what would happened if the attacker can reverse engineer the code of the application and extract the local encryption key?

Extracting the key from traditional cryptographic algorithm is possible due to the open nature of these systems. An attacker can have total visibility of the software implementation of the cryptosystem and full control over its execution platform. With this power over the platform, it would be relatively trivial to analyze the binary code of the application, and the corresponding memory pages during execution.

Taking advantage of this fact, an attacker can easily extract the encryption key when it is used by the algorithm. For example, in the following code fragment it can be seen that the secret key is declared as a String object. Furthermore, it is used later on by the encryption and decryption functions. By monitoring the execution flow, or by inspecting the memory of the application during execution, it will be possible to retrieve the secret key.

function main(args) {
    String secretKey = "DontRevealThisKey";
		#Eventually this key is managed by the application in plaintext during the encryption/decryption process
    String originalString = "SuperSecretText";
    String encryptedString = AES.encrypt(originalString, secretKey);
    String decryptedString = AES.decrypt(encryptedString, secretKey);

Application of White-Box Cryptography in mobile apps

White-Box Cryptography allows to perform cryptographic operations without revealing any portion of confidential information such as the cryptographic key. Without this, attackers could easily grab secret keys from the binary implementation, from memory, or intercept information that would lead to disclosure at execution time.

The usage of White-Box Cryptography together with other protection techniques such as obfuscation at different levels (e.g. function names or control flow obfuscation) has additional advantages. If an attacker wants to access to the secrets managed by the White-Box Cryptography, the first problem that will have to be faced is the identification and isolation of the White-Box Cryptography in the binary. Furthermore, in case that the White-Box Cryptography implementation is found, the next step would be to attack this new type of cryptography.

Is it possible to attack White-Box Cryptography?

As any other software solution, White-Box Cryptography is not a perfect solution and it is possible to attack it. Since the late 1990s, it was discovered that some types of attacks traditionally used for hardware cryptographic implementations can be migrated to software by applying the same approach. The most famous attacks are:

  • Differential Computational Analysis (DCA): It is the software derived version of the Differential Power Analysis (DPA) attack, which is used in hardware cryptography to attack smartcards, chips, etc. It was discovered that the statistical analysis of the data managed in memory or registers during obtained when executing a cryptographic primitive with different inputs might correlate to, and hence reveal information about the secret key material used by the algorithm.
  • Differential Fault Analysis (DFA): It comes from a hardware background, and it is based in the induction of faults during the execution of a cryptographic algorithms to reveal their internal states. The statistical analysis of an original trace (execution trace of a successful encryption of a given input) together with traces obtained using the same input and injecting faults during its execution can give as result the secret key of the software White-Box Cryptography implementation.

These attacks are quite interesting from a technical and mathematical point of view and will be elaborated in detail in a future post.

Securify's efforts on White-Box Cryptography

White-Box Cryptography is a great security feature that is already in use to protect encryption / decryption of sensitive data on open devices. At Securify we strongly believe that the usage of this type of cryptographic techniques will be eventually implemented in every mobile app handling cryptography, and we are already working on it to bring the best approach for efficient and quality testing of White-Box Cryptography.

What's next?

In the next blogpost we will give a detailed explanation about how the two most famous and effective attacks against White-Box Cryptography work, and what type of techniques are available to defend against them. Keep tuned to learn more about this fascinating technology and all the secrets that are hidden behind it.

Thanks for reading.

Vragen of feedback?