Cryptographic operations are fundamental to Android's security, from disk encryption to secure network protocols and authentication tokens. The Android Keystore system provides a secure environment for generating, storing, and using cryptographic keys, ensuring they are protected against extraction, even if the Android OS itself is compromised.
The Android Keystore System
The keystore2 daemon is the userspace component that manages the Keystore API for applications. When an app requests a cryptographic operation (e.g., signing a payload with an RSA key), it does not perform the math itself, nor does it ever see the raw private key material.
Instead, the app uses the java.security.KeyStore API to request the operation. The framework routes this request to the keystore2 daemon, which then passes the data to the secure hardware for processing.
KeyMint HAL (Successor to Keymaster)
The actual cryptographic operations are performed by a Hardware Abstraction Layer (HAL). Historically, this was the Keymaster HAL. Starting in Android 12, it was replaced by the KeyMint HAL.
KeyMint defines the interface between the Android OS and the secure hardware. It supports symmetric (AES, HMAC) and asymmetric (RSA, EC) algorithms. The critical aspect of KeyMint is that the raw key material never leaves the HAL implementation.
Hardware-Backed Key Storage
To achieve robust security, the KeyMint implementation must run in a secure environment isolated from the main application processor and the Linux kernel. This is typically achieved using:
- Trusted Execution Environment (TEE): A secure operating system (like Trusty) running alongside Android on the same main processor but utilizing hardware isolation extensions (like ARM TrustZone).
- StrongBox (Secure Element): A completely separate, dedicated secure microcontroller (like a smartcard chip) integrated into the device motherboard. StrongBox provides the highest level of physical security against side-channel and hardware extraction attacks.
When a key is generated "in Keystore", it is actually generated inside the TEE or StrongBox. The secure hardware returns an encrypted "key blob" to the Android OS. The OS stores this blob on the /data partition, but it can only be decrypted and used by the secure hardware that created it.
Key Attestation
How can a remote server (like a banking backend) trust that a cryptographic signature was generated by secure hardware on an uncompromised Android device, rather than an emulator or a rooted phone? The answer is Key Attestation.
When an app generates a key pair, it can request an attestation certificate chain. The KeyMint implementation in the TEE/StrongBox generates this chain.
- The Root: The chain is rooted in a certificate securely provisioned by Google (or the device manufacturer) into the hardware during manufacturing.
- The Attestation Extension: The certificate contains a specific X.509 extension containing details about the key (e.g., it is hardware-backed, its purpose) and the device state (e.g., verified boot state, OS version).
The remote server can cryptographically verify this certificate chain to guarantee the provenance and security level of the key before trusting any operations performed with it.