The Danger of Software-Based Keys
Imagine a banking app that generates a private key for transaction signing. If that key lives in the application memory space, an attacker with root access can extract it. Disk encryption and network security fail entirely if the underlying cryptographic keys are compromised. The system requires a mechanism to perform cryptographic math without exposing the raw key material to the main operating system.
Android solves this exposure problem through the Keystore system. The core userspace component is the keystore2 daemon. When your application requests a signature using an RSA key, it never performs the actual math or sees the private key. You use the standard java.security.KeyStore API to request the operation. This framework routes your request down to keystore2. The daemon acts as a trusted router and passes your payload across the hardware boundary for secure processing.
This physical separation guarantees that even a fully compromised Linux kernel cannot steal the private key.
Bridging the OS and Secure Hardware
Because Android runs on thousands of different hardware configurations, the system needs a standard way to communicate with secure components across all of them. This is the role of the KeyMint Hardware Abstraction Layer. KeyMint replaced the older Keymaster HAL starting in Android 12. The interface precisely defines the communication boundary between the Android OS and the secure hardware.
The actual cryptographic execution happens in a completely isolated environment. Hardware manufacturers typically provide a Trusted Execution Environment (TEE) like Trusty, which uses extensions like ARM TrustZone to isolate memory from the Linux kernel. For higher security, devices use StrongBox. StrongBox is a dedicated, physically separate secure microcontroller on the motherboard that resists physical extraction attacks.
This sequence diagram illustrates a standard signing operation. The visual clarifies exactly where the private key is decrypted and used. Watch how the payload travels down to the hardware, but the raw key never travels up to the OS.
Notice that keystore2 passes an opaque key blob to KeyMint. When a key is first generated, the secure hardware creates it internally and returns an encrypted blob to the OS. Android stores this blob on the data partition. The operating system cannot read it. Only the specific TEE or StrongBox chip that created the blob can decrypt and use the key inside it. This architectural choice means the OS only manages the encrypted storage and lifecycle of keys, leaving the actual cryptography to trusted hardware.
Proving Hardware Origin to Remote Servers
You now have a secure key locked inside a physical chip. But what if a remote banking server needs proof? An attacker could run a modified Android emulator, intercept the application traffic, and sign payloads with a software key. The remote server needs a way to verify the signature actually came from genuine hardware.
Android solves this remote trust problem with Key Attestation. When your application generates a new key pair, it can request an attestation certificate chain. The TEE or StrongBox generates this chain internally. Root certificates for this chain are securely provisioned by Google or the device manufacturer during factory assembly.
The leaf certificate contains a specific X.509 extension. This block holds cryptographic proof about the key and the device state. It records whether the key is hardware-backed, what its intended purpose is, and the current Verified Boot state of the OS. A remote server can evaluate this certificate chain. The backend verifies the factory root of trust and reads the X.509 extensions. That server can then guarantee the provenance of the key before trusting any financial transactions signed by it.
Tip: Do not write custom backend logic to parse Key Attestation certificates. Use the Google Play Integrity API or an established library to validate the certificate chain and device state.
We have traced how Android protects individual keys from extraction. By keeping the private key isolated in secure hardware and proving its origin with attestation, the system provides a secure foundation of trust. Next, we will examine how the system protects user data at rest through File-Based Encryption.