More and more security companies are including “whitebox cryptography” in their product offerings. This is more than buzzword compliance; it’s a recognition that whitebox attacks are real, and that the implementation of a cryptographic algorithm is as important as the algorithm itself.
When you’re first confronted with the term “whitebox cryptography”, you may be tempted to parse it the same way you would “asymmetric cryptography”, or “quantum cryptography”. In the latter cases, the word before “cryptography” describes the solution – for example, quantum cryptography describes algorithms that use quantum techniques to do things like exchanging keys. But in the case of “whitebox”, it doesn’t describe the solution; it describes the problem. (Aside: as one of the authors of the paper that introduced the term “whitebox cryptography”, I have to take my share of the blame for the confusion that’s resulted. Sorry!)
“Whitebox” is meant to denote openness, accessibility, visibility. It refers to the way an attacker views software; as an open book ready to be explored, understood, bent to their will. Put simply, software is a white box. (This is not contrasting it with hardware, which is increasingly open to knowledgeable souls as well.) So an attacker going after a software implementation doesn’t have to content themselves with fuzzing inputs; they can set breakpoints, step through execution, watch memory regions, modify data at will, and more. These are whitebox attacks, leveraging the open nature of software. In terms of attacker advantage, it’s the difference between trying to open a combination lock by guessing 4-digit sequences, and trying to open a combination lock by watching the tumblers moving.
The only pre-requisite to this openness is access to the system on which the software is running. This could be direct access, if the attacker owns the device; it could be indirect access, if the attacker can somehow navigate their way through a network; or it could be remote access, if the attacker has a way of getting some malicious software onto the system, where it can take control. It’s safe to say that any running software implementation is at risk of a whitebox attack. As the person responsible for securing software, you can’t decide that whitebox attacks don’t matter; they’re a direct consequence of everything that makes software so attractive in the first place.
What does all this mean for cryptographic implementations in software? It means that following standards, choosing strong keys, obeying best practices, etc. just isn’t enough. Your keys are still going to fall to a whitebox attack unless you use an implementation that specifically mitigates against it. “Cryptographic implementations providing resistance against inevitable whitebox attacks” is quite the mouthful, but that’s how to read “whitebox cryptography”, and that’s why it’s so important.