Android Keystore System

WHY IT EXISTS Apps regularly need cryptographic keys, for signing tokens, encrypting local data, or authenticating to a server, but any key sitting in regular app memory or in SharedPreferences is one root exploit or memory dump away from being stolen. The Android Keystore System exists to remove the key material from the app's reach entirely, so even a fully compromised OS cannot extract it.

THE MENTAL MODEL Think of it like a bank vault with a slot for documents instead of a door. You cannot walk in and take the key out, but you can slide data through the slot to be signed or encrypted with a key that stays inside, and get the result back. The app holds a reference to a key, never the key itself.

HOW IT WORKS An app generates a key using KeyGenParameterSpec, specifying purpose, sign, encrypt, or both, along with constraints like requiring user authentication or setting a validity period. That request goes through the standard KeyStore API with provider AndroidKeyStore, but instead of storing bytes on the filesystem, the system routes key generation into a Trusted Execution Environment, a CPU region isolated from the main OS, or into StrongBox, a separate secure element chip on devices that include one. All actual cryptographic operations, signing, encrypting, decrypting, execute inside that isolated hardware, and only the output crosses back into the app.

WHEN IT MATTERS It matters for anything security sensitive: storing an auth token encryption key, protecting biometric backed credentials, or signing requests to prove device identity. The footgun is assuming Keystore alone makes data safe: if a key is generated without setUserAuthenticationRequired, it is still hardware protected from extraction but usable by any code running as that app, so it defends against key theft, not against a malicious or compromised app using its own keys.

ONE CONCRETE EXAMPLE A banking app generates an AndroidKeyStore backed key pair the first time a user enables biometric login, marked to require a fingerprint for every use. On future logins, the app calls Signature.sign to sign a challenge from its server, the OS prompts for a fingerprint, and only after that succeeds does the secure hardware perform the signature, meaning the private key never exists anywhere the app process, or an attacker with root, could read it directly.