White-Box Cryptography: Hiding Keys in Plain Sight
Every app at some point has to deal with storing and securing data. And every mobile app that encrypts some data has the same problem: the key has to exist somewhere. Saving or holding encryption key in its plain form is equivalent to hiding it under the doormat. It can be obfuscated, split into fragments, derived at runtime, but at the moment it is used in an algorithm, it needs to be readable in the memory. This puts the key at risk, especially on devices that are controlled by potentially malicious users.
When talking about cryptography, it is always automatically assumed that the key is somewhere the attacker cannot reach. In the land of reality, this is sometimes hard to achieve. White-box cryptography is the attempt to build implementations that survive even when this assumption does not could not be held.
Attack models
To see what white-box means, it helps to describe the attack models. The attack model defines what capabilities and information we assume an attacker has when trying to break a system. As we give the attacker progressively more capabilities/information we can roughly distinguish three models:
Black-box
The attacker sees inputs and outputs only. This is the textbook model that cryptographic algorithms and their security proofs assume. The attacker can query the cipher, observe ciphertexts, maybe choose plaintexts, but the execution itself is opaque.
Gray-box
Beyond what black-box model provides, the attacker can additionally observe side-effects of execution: power-consumption, electromagnetic emissions, timing, cache behavior.
White-box
The attacker controls everything. The binary, a debugger, full memory read/write, the ability to single-step instructions, tamper with intermediate values, and rerun computations as many times as they want with any inputs they like.
The last model is not being paranoid. It is an accurate description of a rooted Android phone, a jailbroken iPhone, an emulator with Frida attached, or a repackaged APK running under an instrumented runtime. If an app runs on a device you do not control, you are in a white-box model.
What is white-box cryptography?
The white-box cryptography aims to implement a standard cipher where the key is embedded in the implementation itself and cannot be extracted, even by an attacker with full access to the code and its execution. The goal is not to make the key hard to find, but instead to make the key not exist as a discrete value at any point during execution.
Since 2017, the CHES community (WhitBox contests) has run public competitions where designers submit white-box AES implementations and attackers try to break them. Across every edition, all submissions have been broken. The scoring metric is not "unbroken", but instead "how long" the design survived.
Be aware that white-box cryptography is not a substitute for a secure element. It is a strong speed bump that raises the cost of an attack from trivial to "requires a specialist". Which is still enormously useful, because most attacks are not run by specialists.
Why mobile security needs it anyway?
If hardware-backed keystores exist on both major platforms, why bother with white-box cryptography? Hardware Keystores have plenty of restrictions.
Limited support for ciphers
They cannot hold every kind of key. Hardware-backed keystores support only a predefined set of algorithms, key types, modes, and operations. An application cannot simply upload an arbitrary secret and ask the secure hardware to perform any cryptographic algorithm with it. If your protocol uses an unsupported primitive, or requires custom processing involving the key, the computation has to happen in the normal application environment.
Key provisioning issues
Keys that most need protecting are frequently exactly the ones that are not generated on-device: a content decryption key issued by a DRM, a payment credential provisioned by a token service provider, a shared secret used to authenticate the app to your backend. Hardware-backed keystores are designed primarily around keys that are generated inside secure hardware and never leave it.
Device support
The device support is fragmented.The actual security level depends on the device, OS version, and available secure hardware. Many devices do not have real hardware-backed keystores and instead contain only software-based implementations. An application therefore cannot always assume the same level of hardware protection on every device it supports.
Implementation inconsistency
Hardware key handling is present with portability issues. While one white-box implementation behaves identically across Android, iOS, and other platforms, hardware key handling does not.
Closing thought
White-box cryptography is one of the few areas of security that is openly imperfect and still worth deploying. It does not deliver the guarantee its name suggests. What it delivers is turning a key extraction from a five-minute task into a specialist project measured in weeks.
Handle App Security with a Single Solution! Check Out Talsec's Premium Offer & Plan Comparison!
Apps Security Threats Report 2025
https://www.talsec.app/talsec-global-threat-report-2025
Plans Comparison
https://www.talsec.app/plans-comparison
Premium Products:
RASP+ - An advanced security SDK that actively shields your app from reverse engineering, tampering, rooting/jailbreaking, and runtime attacks like hooking or debugging.
AppiCrypt (Android & iOS) & AppiCrypt for Web - A backend defense system that verifies the integrity of the calling app and device to block bots, scripts, and unauthorized clients from accessing your API.
Malware Detection - Scans the user's device for known malicious packages, suspicious "clones," and risky permissions to prevent fraud and data theft.
Dynamic TLS Pinning - Prevents Man-in-the-Middle (MitM) attacks by validating server certificates that can be updated remotely without needing to publish a new app version.
Secret Vault - A secure storage solution that encrypts and obfuscates sensitive data (like API keys or tokens) to prevent them from being extracted during reverse engineering.
Last updated
Was this helpful?