In the digital age, securing sensitive information like passwords, authentication tokens, and private user data is one of the most critical responsibilities of an application developer. Simply storing this data in a plain text file on a device’s storage is grossly insecure. To solve this problem, Android provides a robust, system-level facility called the Android Keystore System. This system allows applications to generate and store cryptographic keys in a secure, hardware-backed container, making it extremely difficult for malware or attackers to extract them, even on a rooted device.
The Problem: Insecure Key Storage
Cryptographic keys are the foundation of modern security. They are the secrets used to encrypt and decrypt data, sign messages, and authenticate users. If these keys are compromised, the entire security of an application collapses. Before the Keystore system, developers had to manage key storage themselves, which often led to insecure practices:
- Storing keys in Shared Preferences or local files: This is highly insecure. If the device is rooted, a malicious app with root privileges can simply read these files and steal the keys.
- Obfuscating keys in code: Hiding keys within the application’s source code is a form of “security through obscurity” that provides a false sense of security. An attacker can easily decompile the APK and extract the hardcoded keys.
- Relying on user-provided passphrases: While better, this relies on the strength of the user’s password and can be vulnerable to brute-force or dictionary attacks.
A proper solution required a way to store and use cryptographic keys without ever exposing the raw key material to the application or the main Android OS kernel itself.
Introducing the Android Keystore System: Hardware-Backed Security
The Android Keystore System is a service that provides a secure, specialized container for cryptographic keys. Its key feature is that it allows an application to generate, store, and use keys without the application’s process ever having direct access to the key material. All cryptographic operations (like encryption or signing) that use the key are performed *inside* the secure container.
The security of the Keystore is rooted in hardware. On most modern Android devices, the Keystore is backed by a Hardware-Backed Security Module. This can be:
- A Trusted Execution Environment (TEE): A secure, isolated area of the main application processor (SoC) that runs a separate, trusted OS. The main Android OS cannot directly access the memory or processes within the TEE.
- A Secure Element (SE): A separate, tamper-resistant chip on the device (like the Titan M chip in Google Pixel phones). This offers an even higher level of security, as it’s physically isolated from the main processor. This is conceptually similar to the iOS Secure Enclave.
By using this hardware, the Keystore ensures that even if the Android OS kernel is compromised, an attacker cannot extract the keys. The keys are generated, stored, and used entirely within the TEE or SE.
How the Android Keystore Works Internally
Using the Keystore involves interacting with the `KeyStore` provider API. The application doesn’t see the key, only a handle or alias to it.
1. Generating a New Key
An application requests that the Keystore generate a new key pair (a public and private key) or a secret key. When doing so, it specifies a set of constraints and properties for the key using `KeyGenParameterSpec`.
// Example of generating a new key pair for signing KeyGenParameterSpec spec = new KeyGenParameterSpec.Builder( "my_key_alias", KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY) .setDigests(KeyProperties.DIGEST_SHA256) .setUserAuthenticationRequired(true) // Require fingerprint/face unlock to use the key .setInvalidatedByBiometricEnrollment(true) .build(); KeyPairGenerator kpg = KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore"); kpg.initialize(spec); KeyPair kp = kpg.generateKeyPair(); // The key is generated and stored securely. In this example, the key is generated directly inside the hardware security module. The `kp` object returned to the app contains the public key, but the private key material never enters the app’s memory.
The `setUserAuthenticationRequired(true)` constraint is particularly powerful. It means this key can *only* be used after the user has successfully authenticated with their device credential (PIN, pattern, password) or biometrics.
2. Using a Key
When the app needs to perform a cryptographic operation, it loads the key from the Keystore using its alias and then performs the operation.
- The app requests to use the key with alias `”my_key_alias”`.
- The Android Keystore service receives the request.
- If the key has constraints (like requiring user authentication), the system will first prompt the user to authenticate (e.g., show the fingerprint dialog).
- If authentication is successful, the Keystore service instructs the TEE/SE to perform the requested operation (e.g., sign a piece of data with the private key).
- The TEE/SE performs the signing operation internally.
- The result (the digital signature) is returned to the Keystore service and then to the app.
Throughout this entire process, the private key never left the secure hardware. The app only ever handled the input data and the resulting signature.
Key Features and Constraints
The power of the Keystore comes from the rich set of constraints you can apply to keys at generation time.
| Constraint | Description | Use Case |
|---|---|---|
| Authentication Requirement | `.setUserAuthenticationRequired(true)` | Ensures a key can only be used after the user unlocks their device, protecting data even if the phone is stolen while unlocked. |
| Authentication Timeout | `.setUserAuthenticationValidityDurationSeconds(30)` | Allows a key to be used multiple times for 30 seconds after a single successful authentication. Useful for a series of actions in a banking app. |
| Biometric Invalidation | `.setInvalidatedByBiometricEnrollment(true)` | Automatically deletes the key if a new fingerprint is added to the device, preventing an attacker from adding their own fingerprint to access your app’s data. |
| Hardware Security | `.setIsStrongBoxBacked(true)` (on supported devices) | Forces the key to be created and stored in a dedicated Secure Element for the highest level of security. |
The official Android Developer documentation provides a comprehensive guide to these features.
Frequently Asked Questions
Is the Android Keystore the same as the Android Keyring?
No. The “Keyring” is a much older, now deprecated system for system-wide credential storage. The Android Keystore system is the modern, recommended, hardware-backed solution for application-specific keys.
What happens to the keys when I uninstall an app?
When an application is uninstalled, all the keys it created in the Android Keystore are permanently and irrevocably deleted. This is a key part of Android’s sandboxing and data protection model, ensuring that no orphaned sensitive data is left behind. This is a much stronger guarantee than just deleting files from storage, as the hardware itself purges the keys.
Can I export a key from the Keystore?
No. This is the entire point of the system. The fundamental security guarantee of a hardware-backed keystore is that the private key material is non-exportable. It is generated, stored, and used within the secure hardware and can never be extracted by software.
How can I check if a key is hardware-backed?
You can programmatically check the properties of a key after it has been generated. The `KeyInfo` class allows you to check a flag called `isInsideSecureHardware()`. For keys that must have the highest level of protection, you should always verify this flag returns true. On modern devices running recent Android versions, keys generated via the `AndroidKeyStore` provider are almost always hardware-backed.