Dismantling Android Keystore: Reversing Safe Storage & Key Attestation

Introduction

Android Keystore provides a robust container for cryptographic keys, making it significantly harder for malicious apps to extract secret credentials. When backed by hardware, such as a Trusted Execution Environment (TEE) or StrongBox secure element, private key material is designed to remain outside normal application memory. However, the communication interface between the normal world (Rich Execution Environment or REE), keystore2, the KeyMint HAL, the TEE, and StrongBox-backed implementations is still an important audit surface.

This article details a comprehensive exploration of Keymaster/KeyMint architectures, tracing binder transactions, and reverse-engineering proprietary OEM security modules to inspect key generation, storage, and attestation. The 2026 update is especially important because Android Key Attestation is moving through a root certificate rotation, and Remote Key Provisioning is now part of the mainstream attestation story rather than a future-looking side feature.

1. Keymaster and KeyMint Architecture Overview

Android's secure storage has transitioned from standard software libraries to hardware-enforced isolation. In current Android versions, the terms matter:

• Keystore is the Android framework-facing service and API surface.
• KeyMint is the modern HAL used by the platform to talk to hardware-backed cryptographic implementations.
• Keymaster is the older HAL lineage that still matters when auditing legacy devices.
• StrongBox KeyMint is a KeyMint implementation backed by a dedicated secure element or integrated secure enclave, not just the main application processor's TEE.

Below is the simplified stack mapping the execution environments:

1. Rich Execution Environment (REE): Under the Linux kernel, standard system applications and system services run here. The keystore2 daemon mediates access to cryptographic services.
2. Hardware Abstraction Layer (HAL): The bridge interface. Using AIDL (Android Interface Definition Language), Keystore interacts with KeyMint (android.hardware.security.keymint).
3. Secure Execution Environment (TEE) or StrongBox: Vendor TEE implementations, such as Qualcomm's secure execution environment or Trustonic Kinibi, run trusted applications in ARM TrustZone-backed secure-world contexts. StrongBox implementations provide stronger physical isolation but support a smaller algorithm set and may be slower.

1+-----------------------------------+2|     Android App / System UI       |3+-----------------------------------+4                  | (AIDL binder)5                  v6+-----------------------------------+7|      keystore2 System Daemon       |8+-----------------------------------+9                  | (HAL interface)10                  v11+-----------------------------------+12|       KeyMint/Keymaster HAL       |13+-----------------------------------+14                  | (Secure monitor call - SMC)15                  v16+-----------------------------------+17|   TEE (Secure World / TrustZone)   |18+-----------------------------------+

2. Reverse-Engineering the HAL Binder Interface

In Android 12+, keystore2 manages isolated namespaces. To trace how binder transactions pass parameters like key size, padding, and digests to the underlying HAL:

1. Binder Interception: By utilizing bpftrace and tracing transaction functions on the binder driver, we logged transactions targeting android.hardware.security.keymint.IKeyMintDevice.
2. Decompiling Proprietary HAL Modules:

We inspected the vendor-specific HAL library (e.g. android.hardware.security.keymint-service.qti.so). Loading it into Ghidra revealed wrappers mapping standard AIDL definitions into custom proprietary structures:

1   // Approximate signature identified during reversing2   int qti_keymint_generate_key(3       struct qti_keymint_device* dev,4       struct key_parameter* params,5       size_t param_count,6       struct key_creation_result* result7   ) {8       // Marshalling AIDL key parameters into secure world buffers9       uint8_t* secure_buffer = marshall_params(params, param_count);10       int status = smc_call(SMC_GENERATE_KEY, secure_buffer);11       unmarshall_result(secure_buffer, result);12       return status;13   }

3. Breaking Down Key Attestation in 2026

Attestation verifies that a key generated in Keystore is indeed backed by an expected security level such as TEE or StrongBox. During key generation, the secure implementation signs a detailed data structure containing:

• Verified Boot state (Locked/Unlocked, verified signature chain).
• Security Level of the key and attestation path (TEE, StrongBox, Software, or framework-enforced fields).
• Key parameters (Authorization list details like validity period, user authentication bound status).
• Patch and boot binding that helps prevent a device from rolling back to vulnerable firmware or OS states and still using keys created under newer states.

Verification Pipeline

To audit the attestation statement manually, one must extract the certificate chain from the attestation response and verify each link up to a trusted Android Key Attestation root. This changed in 2026: Google introduced a new ECDSA P-384 Android Key Attestation root. Apps and backends that rely on Android Key Attestation needed to add the new root by March 31, 2026; RKP-enabled devices began receiving certificates rooted in the new certificate in February 2026 and were expected to exclusively use the new root by April 10, 2026. Older factory-provisioned devices can still chain to the older root.

1# Shell snippet validating attestation cert fields2openssl x509 -in attestation_leaf.pem -text -noout | grep -A 10 "1.3.6.1.4.1.11129.2.1.17"

The OID 1.3.6.1.4.1.11129.2.1.17 represents Android's custom attestation extension containing ASN.1-encoded security parameters. Inspecting this extension helps analysts verify boot state, patch level, key origin, security level, and user-authentication constraints, but it does not by itself guarantee that the entire application channel is free from framework hooks or runtime tampering.

In app code, do not infer hardware backing from the alias or provider name. For Android 10 and later, inspect KeyInfo.getSecurityLevel() and require TRUSTED_ENVIRONMENT or STRONGBOX where the threat model demands hardware-backed keys. For Android 9 and lower, KeyInfo.isInsideSecurityHardware() remains the older compatibility check.

4. Key Takeaways and Architectural Vulnerabilities

Through auditing different Android devices and backend validation patterns, several recurring risk areas emerge:

• Root Rotation Blind Spots: Backends that pinned only the old Android Key Attestation root can reject valid 2026 RKP-backed attestations; backends that blindly trust any new chain without policy review can weaken their trust model.
• Stale Attestation Decisions: Backends that cache or replay old attestation verdicts can trust device states that are no longer current.
• Fallback Ambiguity: Applications that do not check the reported security level can accidentally treat software-backed keys as hardware-backed keys.
• StrongBox Misuse: StrongBox is valuable for high-risk physical-tampering scenarios, but it is slower and supports fewer algorithms and concurrent operations. Treat it as a threat-model-driven choice, not a default performance-free upgrade.
• Secure-World Memory Bugs: Memory corruption in TEE components can weaken isolation assumptions even when the Android framework integration looks correct.

Implementing a defensive posture requires continuous validation of bootloader states, strict verification of attestation certificate chains directly on remote backend servers, and the avoidance of blind trust in client-side secure storage containers.

References

• Android Keystore system: https://developer.android.com/privacy-and-security/keystore
• Verify hardware-backed key pairs with key attestation: https://developer.android.com/privacy-and-security/security-key-attestation
• AOSP Hardware-backed Keystore: https://source.android.com/docs/security/features/keystore
• AOSP Key and ID attestation: https://source.android.com/docs/security/features/keystore/attestation
• AOSP Keystore features: https://source.android.com/docs/security/features/keystore/features