Cryptography Security Models

The black-box security model is when attackers view cryptographic tools as oracles that follow a particular API. It is mainly used by cryptographers to prove the security of cryptographic schemes, often by reducing the security of a cryptographic algorithm to the hardness of a hard problem, such as integer factoring, extracting discrete logarithms, or finding short vectors in lattices.

The grey-box security model is similar to the black-box model, but attackers can also take advantage of some information about how it's built and how it operates. This additional information can come from leakage of a physical dimension, such as power consumption, electromagnetic emissions, or time. Side-channel attacks typically fall into this model.

In the white box security model, attackers have complete control over the cryptographic setup and the environment in which it runs. This model captures the capabilities of a reverse engineer working on an executable.

White-Box Cryptography

So, what can be done to ensure a high level of cryptographic security in a white-box setting? What are the relevant security notions?

The first answers came from Chow and his team in 2002. They wrote a scientific paper proposing a white-box DES implementation, i.e. an implementation of the DES block cipher that embeds a secret key supposedly hard to extract. Since then, several other proposals have been published. All of them have been broken in one way or another.

Three security goals have been identified as of today:

• infeasibility of extracting the secret key;
• infeasibility of inverting the function;
• infeasibility of compressing the function.

Historically, the first security goal proposed by Chow et al. was to resist to key extraction. Conceptually, it consists in transforming a symmetric cipher whose implementation embeds a hard-coded key into a public-key cipher.

The classical approach uses input and output encodings that involves pre-computing a mix of encodings and decodings into table lookups. However, there are many ways to break these designs, such as using differential cryptanalysis, fault analysis, and leakage analysis.

Resisting to inversion is a slightly easier security goal: inverting a one-way function does not necessarily implies extracting its secret key. There are trivial illustrations of the gap between key extraction and inversion: a block cipher operated in CTR mode; AES-GCM; etc.

To resist to function compression, the adversary should not be able to build a “small” implementation out of a larger one running into a white-box setting. To do so, you can use huge tables that are necessary to implement the cipher. You can build those tables from operating a block cipher keyed with a secret as a PRNG. The security goal is to make “leaking” the white-box instance not very stealthy.

In practice, the industry sometimes has no choice but to implement white-box cryptography, typically in scenarios where no hardware secure elements are available, relying on ad hoc and secret designs (security by obscurity). Even if such technology is not very secure, it allows to slow down reverse engineers. However, white-box cryptography alone is not enough. In some situations, someone can still "carve" your code and run or emulate it without knowing how it works or extracting any embedded secret. Other software protection techniques, such as tamper-proofing and code obfuscation, are also needed.

In the next episode, I’ll cover computing on encrypted data. Stay tuned!

Thanks for reading Crumbs of Cybersecurity! Subscribe for free to receive new posts and support my work.