Your Hardware Security Is Working. That’s Not the Problem.

We hear a version of this objection regularly: “We’re already using Android StrongBox. We have ECDH key exchange. Our keys never leave the hardware. Why would we need white-box cryptography on top of that?” 

It’s a fair question. StrongBox, TEE-backed Keystore, and ECDH are genuinely strong technologies. Dismissing them would be intellectually dishonest–and unhelpful. So instead of dismissing them, let’s look at what they actually protect, and where the gaps are.

The Vault Analogy–and Why It’s Incomplete 

Hardware security is excellent at one thing: keeping keys safe inside a vault. StrongBox generates keys, stores them, and performs cryptographic operations without ever exposing the raw key material. That’s real protection and it matters. 

But here’s the question most security architects don’t ask: is the vault in the path for the operations that matter most? 

For Android apps making standard server connections–using HttpsURLConnection, OkHttp, or similar OS-managed APIs–the answer is largely no. Android’s TLS stack runs through BoringSSL and Conscrypt, two software libraries that handle ECDH key exchange entirely in software, without routing through StrongBox or TEE Keystore. TLS session keys exist as raw bytes in memory, regardless of what hardware your device has. 

This isn’t a flaw in Android’s design–it’s an architectural reality that most app security conversations skip over. Your vault is excellent. For TLS, the vault isn’t in the building. 

When the Binary Is the Attack Surface 

Set aside TLS for a moment. Consider an app that does use hardware-backed keys for its own cryptographic operations–properly provisioned, ECDH-derived, stored securely in StrongBox. That’s a strong setup. 

Now consider what an attacker actually does with your app. They don’t try to extract the key from StrongBox–that’s hard. They download your app, run a disassembler, and read your code. 

What they find is the handshake logic: the protocol your app uses to communicate with your server, the authentication flow, the API structure. With that understanding, they don’t need your key. They build a modified app that completes a legitimate-looking handshake from scratch. StrongBox on their device now holds a key your server trusts. 

The higher-value attack isn’t reading one user’s decrypted data. It’s understanding your protocol well enough to forge authenticated API requests–potentially at scale, potentially as arbitrary users. Hardware security has no answer for this because the attack never touches the hardware. 

This is the gap white-box cryptography and app hardening address: protecting the protocol logic itself, not just the key. 

The Fragmentation Problem (While It Lasts) 

Even setting aside the BoringSSL reality, hardware security has a coverage problem on Android. According to the DroidCCT study–a peer-reviewed analysis of Android device security–StrongBox is available on only 8.7% of premium-tier devices, 7.2% of medium-tier, and 0.2% of low-tier devices. Most of your users don’t have it. 

iOS is a different story: Secure Enclave is present on all current iOS devices and provides strong hardware-backed protection. The fragmentation argument applies primarily to Android. 

It’s worth acknowledging that this argument has a shelf life. Hardware availability will improve over time, and some security guidelines already recommend white-box cryptography as a temporary complement to TEE while hardware adoption catches up. The binary reverse engineering, attestation, and vendor-independence cases are durable; fragmentation is the compelling-today case. For some organizations–particularly those with regulatory or supply chain constraints–reducing dependency on any single hardware vendor’s security implementation is itself a design goal. 

What “App-Layer Attestation” Actually Means 

One more gap worth naming: your server completed a handshake, but it doesn’t know who it’s talking to. 

It can’t distinguish between your legitimate app running on a real device, a repackaged version of your app running on a rooted device, and a completely synthetic client that mimicked your handshake after reverse engineering your protocol. 

Google Play Integrity API helps. MEETS_STRONG_INTEGRITY with proper nonce and requestHash binding substantially reduces the bypass surface. But clean proxy device replay remains a residual risk regardless of integrity tier. 

White-box cryptography provides app-layer attestation: cryptographic proof that the request originated from an unmodified app executing protected protocol logic, independent of OS or hardware trust signals. It’s a second, orthogonal signal–not a replacement for Play Integrity, but the layer that addresses what Play Integrity cannot. 

The more sophisticated version of this–and where we believe the industry is headed–is continuous behavioral attestation: did this client trigger any tamper detections since its last request? A server that can modulate its response based on a client’s runtime security posture is meaningfully more resilient than one making a binary trusted/untrusted decision at session establishment. 

The Complete Picture 

Hardware security is the vault. White-box cryptography and app hardening are the armored transport–protecting everything that has to leave the vault and participate in the real world. 

For most Android TLS operations, the vault isn’t in the path. Where it is in the path, it doesn’t protect the protocol, the binary, or the attestation layer. These aren’t reasons to abandon hardware security–they’re reasons to treat it as one layer of a complete defense, not the final answer. 

These are four of the arguments we’ve stress-tested internally with our engineering, security, and customer success teams. There’s more to the story–including how this applies to specific platforms, compliance frameworks (Digital.ai Key & Data Protection holds FIPS 140-3 certificate #4910), and regulated industry requirements. 

If you’re evaluating app protection and want to walk through the full picture as it applies to your environment, we’d welcome the conversation. Request a demo today