> For the complete documentation index, see [llms.txt](https://docs.talsec.app/appsec-articles/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talsec.app/appsec-articles/articles/white-box-cryptography-hiding-keys-in-plain-sight.md). # 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.

Standard vs White-box cryptography
Source: whiteboxcrypto.com

{% hint style="info" %} There are academic papers from the early 2000s which attempt to construct such implementations. However, there is no published white-box implementation of a standard cipher with a proof of security, and every published academic design has been broken. {% endhint %} 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. *** {% hint style="success" %} Handle App Security with a Single Solution! Check Out Talsec's Premium Offer & Plan Comparison!
#### Apps Security Threats Report 2025 #### Plans Comparison #### Premium Products: * [RASP+](https://docs.talsec.app/premium-products/product/rasp) - An advanced security SDK that actively shields your app from reverse engineering, tampering, rooting/jailbreaking, and runtime attacks like hooking or debugging. * [AppiCrypt](https://docs.talsec.app/premium-products/product/appicrypt) (Android & iOS) & [AppiCrypt for Web](https://docs.talsec.app/premium-products/product/appicryptweb) - 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](https://docs.talsec.app/premium-products/product/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](https://docs.talsec.app/premium-products/product/app-hardening#about-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](https://docs.talsec.app/premium-products/product/app-hardening#about-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. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.talsec.app/appsec-articles/articles/white-box-cryptography-hiding-keys-in-plain-sight.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.