Type: Primer

Category: Research — Keys & Secure Hardware

Series: Key containers on mobile devices, part 1 of 3

Reading time: ~8 min

Three security levels, one keystore API, and a certification requirement that stops short of the strongest one.

An application that generates a key through the Android Keystore receives a handle and a promise. The promise is that the private key material is protected by something better than the filesystem. What that something is varies by device, is not selected by the application, and is not evident from the handle.

This article establishes the vocabulary. The two that follow cover what a device can prove about the key, and how an SDK should choose among the options.

The hierarchy

Three security levels are defined: Software, TrustedEnvironment, and StrongBox.

Software means the key is protected by the operating system and nothing else. The key material is encrypted at rest, but the encryption and the enforcement of the key's usage constraints happen in code running on the main processor, under the main kernel. A compromise of the OS is a compromise of the key.

TrustedEnvironment — commonly called the TEE — means the key lives in an isolated partition of the same system-on-chip that runs the application processor. On ARM devices this is normally implemented with TrustZone: a "secure world" with its own small operating system, most often Trusty or a vendor's own. The application processor can request operations but cannot read the key. It shares silicon, memory controllers and power rails with the untrusted side.

StrongBox means the key lives in a physically separate tamper-resistant secure element with its own processor, its own secure storage, and its own true random number generator. AOSP's hardware guidance requires a StrongBox implementation to provide a discrete CPU, secure storage, a high-quality TRNG, tamper-resistant packaging and side-channel resistance.

The distinction between the second and third levels is the one that matters for threat modelling. A TEE resists a compromised OS. A discrete secure element additionally resists physical attack on the main SoC and the side channels that come with sharing it.

What certification actually requires

This is where expectations and reality diverge, and it is the most useful thing in this article.

The Android Compatibility Definition Document, section 9.11, sets what a device must implement to be certified. Reading it carefully:

• A hardware-backed keystore, backed by an isolated execution environment, is a MUST for devices launching with recent Android versions. Devices already launched on an earlier version are grandfathered, unless they declare the fingerprint feature, which requires it.
• The mandated algorithm set for that keystore is RSA, AES, ECDSA and HMAC, with the MD5, SHA-1 and SHA-2 hash families.
• Key attestation with a hardware-protected signing key is a MUST.
• StrongBox is STRONGLY RECOMMENDED, not required. The CDD notes that it will likely become a requirement in a future release. Where it is implemented, the device must provide dedicated secure hardware, and evaluation at EAL5 augmented with AVA_VAN.5 is strongly recommended rather than mandatory.

So a certified Android device is guaranteed to have a TEE-backed keystore and key attestation. It is not guaranteed to have a discrete secure element, and at the low end of the market it almost certainly does not.

The algorithm set is narrower still at the top level. Where StrongBox exists, the mandated subset is RSA-2048, AES-128 and AES-256, ECDSA and ECDH on P-256, HMAC-SHA-256, and Triple DES. StrongBox is not required to support any curve other than P-256, and does not support Curve25519. An application that requests Ed25519 in StrongBox is requesting something the specification does not promise.

(Facts in this section reflect the CDD as of September 2026; section 9.11 changes between releases and should be re-read against the version a deployment targets.)

The version ladder

The hardware abstraction layer was called Keymaster through Android 11 and renamed KeyMint in Android 12. The application-facing Java API — the AndroidKeyStore provider, KeyGenParameterSpec, KeyInfo — is stable across the rename.

Each HAL version corresponds to an attestation schema version, and the mapping is not linear:

HAL version	Android release	Attestation schema	Added
Keymaster 1	6.0 (API 23)	—	Symmetric keys; isInsideSecureHardware()
Keymaster 2	7.0 (API 24)	1	Key attestation; version binding
Keymaster 3	8.0 (API 26)	2	ID attestation
Keymaster 4	9 (API 28)	3	StrongBox; per-partition patch levels; secure key import
Keymaster 4.1	10 (API 29)	4	earlyBootOnly, unlockedDeviceReq, deviceUniqueAttestation
KeyMint 1.0	12 (API 31)	100	Rename; AIDL HAL; KeyInfo.getSecurityLevel()
KeyMint 2.0	13 (API 33)	200	Curve25519 for signing and key agreement
KeyMint 3.0	14 (API 34)	300	attestationIdSecondImei; RKP as updatable module
KeyMint 4.0	15 (API 35)	400	moduleHash groundwork
KeyMint 5.0	16 (API 36)	500	moduleHash; ML_DSA algorithm value and mlDsaVariant field in the attestation schema

Two notes on the last row, because it is easy to over-read.

The presence of ML_DSA as an algorithm value and mlDsaVariant as an attestation field means the interface accommodates post-quantum signatures. It does not mean devices generate them. Google's own account places the developer-facing ML-DSA API in Android 17, exposed through KeyPairGenerator for ML-DSA-65 and ML-DSA-87, implemented in the TEE — not in StrongBox, and not as a mandated capability. ML-DSA is absent from the HAL's list of primitives every implementation must provide, and absent from the CDD's mandated algorithm set.

A capability defined in an interface is not a capability available on a device. This distinction recurs throughout the subject and is worth holding onto.

There is also no clean public Java API to read the HAL version at runtime. The practical route is to generate a key with an attestation challenge and parse the version out of the resulting certificate.

Determining what you got

Four mechanisms, with their constraints:

KeyInfo.getSecurityLevel(), API 31 and above. Returns SECURITY_LEVEL_SOFTWARE, SECURITY_LEVEL_TRUSTED_ENVIRONMENT, SECURITY_LEVEL_STRONGBOX, or an unknown value. This is the preferred local check where available.

KeyInfo.isInsideSecureHardware(), available from API 23, deprecated at API 31. Returns a boolean and cannot distinguish TEE from StrongBox. Below API 31 it is the only option.

KeyGenParameterSpec.Builder.setIsStrongBoxBacked(true). Requests StrongBox explicitly. If StrongBox is unavailable for the requested algorithm or key size, key generation throws StrongBoxUnavailableException. This is the sound way to probe: attempt, catch, fall back.

PackageManager.FEATURE_STRONGBOX_KEYSTORE and FEATURE_HARDWARE_KEYSTORE. System features carrying integer version attributes that correspond to the HAL version implemented at that level. Querying with a version lets an SDK read the declared HAL version per level without generating a key.

Two hazards

Failure is loud in one direction and quiet in the other. An explicit StrongBox request fails with an exception, so there is no silent downgrade from StrongBox to TEE. But a plain key request on a device with no hardware-backed keystore can be satisfied in software, and only inspecting the resulting KeyInfo reveals it. An SDK that generates a key and never checks what it received has no idea what it is holding.

All four mechanisms run in the application's own process. They report what the platform tells them. On a device where the platform has been modified, they report whatever the modification chooses. They are appropriate for deciding what to attempt and for telling the user what protection is in effect. They are not evidence, and they cannot be the basis of an assurance claim made to anyone else.

What can serve as evidence is the subject of the next article.

Series: Key containers on mobile devices

• Part 2: The certificate has two lists.
• Part 3: Seven containers, ranked by what you can prove.

---

References

1. Android Open Source Project. Hardware-backed Keystore. https://source.android.com/docs/security/features/keystore
2. Android Open Source Project. Key and ID attestation. https://source.android.com/docs/security/features/keystore/attestation
3. Android Open Source Project. Compatibility Definition Document, §9.11 Keys and Credentials.
4. Android Developers. Android Keystore system. https://developer.android.com/privacy-and-security/keystore
5. Android Developers. KeyInfo and KeyGenParameterSpec.Builder API reference.
6. Google Online Security Blog (25 March 2026). Security for the Quantum Era: Implementing Post-Quantum Cryptography in Android.