Android Keystore: hardware-backed keys explained

The Android Keystore is the answer to a question that trips up a lot of apps: where do you put a cryptographic key so it cannot be stolen from your app? Not in a file, not in the code, not in shared preferences, all of those can be extracted. The Keystore stores keys in a container the app cannot read, and on most modern devices that container is hardware-backed, so the key never enters your app's memory and cannot be exported even by your own code. Here is what the Android Keystore is, what hardware backing means, and how to use it well.

Short answer

The Android Keystore is a system that stores cryptographic keys in a container designed so the key material cannot be extracted from the app, and on supported devices the keys are hardware-backed in a Trusted Execution Environment or, with StrongBox, a dedicated secure element. Per Android's Keystore documentation, your app does not read the key; it asks the Keystore to perform cryptographic operations with it, so the key never enters your app's process. You can bind a key to user authentication and to your app. Use it to protect data at rest and secrets, generate keys in the Keystore rather than importing or hardcoding them, and never try to export them.

What you should know

• The Keystore protects keys from extraction: the app cannot read the key material.
• Operations happen in the Keystore: you use the key without holding it.
• Keys can be hardware-backed: in a TEE, or a secure element with StrongBox.
• Keys can be bound to authentication: require biometrics or device credential.
• Generate in the Keystore: do not import or hardcode keys.

What is the Android Keystore?

It is a system service that holds cryptographic keys so they are not exposed to your app or to other apps. Instead of your code loading a key into memory to encrypt or sign, you generate or store the key in the Keystore and then ask the system to perform the operation with it, so the key material itself stays inside the Keystore and never enters your app's process. That is the core protection: even your own app cannot read the raw key, which means an attacker who compromises the app or reads its storage cannot extract it either. The Keystore can also tie a key to your app, so other apps cannot use it, and bind a key's use to user authentication. It is the Android counterpart to the iOS Keychain and Secure Enclave for key management.

What does hardware-backed mean, and what is StrongBox?

It means the key lives in secure hardware, not just protected software. The table contrasts the levels.

On most modern devices, Keystore keys are hardware-backed, held in a Trusted Execution Environment that is isolated from the main operating system, so the key is protected even if the OS is compromised. Devices with StrongBox provide an even stronger option, a dedicated secure element with tamper resistance. Hardware backing is what makes the key genuinely hard to extract; a software-backed Keystore still protects the key from ordinary access but without the hardware isolation. You can also use key attestation to verify that a key is hardware-backed.

How do you use the Keystore well?

Generate keys in it, keep them there, and bind sensitive ones to authentication. The right pattern is to generate a key directly in the Keystore so the raw material never exists outside it, rather than importing a key you generated elsewhere or, worse, hardcoding one. Use the key for the operation you need, encrypting a data key that protects files, signing, or releasing a secret, by asking the Keystore to perform the operation, and never attempt to export the key. For sensitive operations, bind the key to user authentication so it can only be used after a biometric or device-credential check, enforced by the hardware. Prefer hardware-backed keys, and StrongBox where available, for the strongest protection. The principle is that the key should be born in the Keystore, used through it, and never leave it.

What to watch out for

The first trap is hardcoding a key or storing it in a file or preferences instead of the Keystore, where it can be extracted; generate and keep keys in the Keystore. The second is importing a key generated outside the Keystore, which means the raw material existed where it could be captured; generate in place. The third is assuming all devices give the same protection, when backing ranges from software to StrongBox, so use attestation if you need to confirm hardware backing. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and assesses your key handling, including whether keys are hardcoded or stored insecurely rather than in the Keystore. Moving key management into the Keystore is the fix.

What to take away

• The Android Keystore stores cryptographic keys so the app cannot read or export them, performing operations with the key inside the system.
• On supported devices keys are hardware-backed in a Trusted Execution Environment, or in a dedicated secure element with StrongBox, which makes them genuinely hard to extract.
• Generate keys in the Keystore rather than importing or hardcoding them, bind sensitive keys to user authentication, and never try to export them.
• Use a pre-submission scan such as PTKD.com to confirm your keys are managed in the Keystore rather than hardcoded or stored insecurely.