Android Keystore API Overview

• Android Keystore API is the Android interface that securely generates, manages, and uses cryptographic keys in hardware isolated from regular OS memory.
• It differentiates between TEE-backed and Secure Element (StrongBox) modes, balancing performance with enhanced isolation for sensitive operations.
• Its evolution since 2011 and enforced safe defaults help mitigate risks from OS compromises while acknowledging fallback to vulnerable software-backed storage.

Android Keystore API is Android’s public interface to trusted hardware for application cryptography and the principal mechanism by which app developers can keep cryptographic keys out of ordinary app and operating-system memory. Its core security property, as characterized in a large-scale 2025 measurement study, is that keys are generated, stored, and used inside hardware separate from the normal Android execution environment, so key material never appears in host memory during use. The API is not a single implementation: in common usage it usually denotes a TEE-backed keystore, while the more isolated secure-element-backed mode is exposed as StrongBox Keymaster [2507.07927].

1. Definition and historical evolution

Android exposed the Keystore system to developers in 2011. TEE support became available in Android 4.3 / API 18 in 2013; symmetric keys were added only in Android 6.0 / API 23; hardware key attestation appeared in Android 7.0 / API 24; and StrongBox, the secure-element path, became available to external developers in Android 9.0 / API 28 [2507.07927].

This chronology matters because the API’s semantics have expanded from a relatively narrow interface into a policy-rich hardware-backed key-management surface. The addition of symmetric keys in Android 6.0 made the API relevant to ordinary data-at-rest and session-protection workflows, while attestation in Android 7.0 made it possible to bind application trust decisions to hardware-backed evidence. StrongBox in Android 9.0 further differentiated the API into at least two hardware tiers: a TEE-backed mode on the main processor and a more isolated secure-element-backed mode.

The historical evolution also explains why older Android cryptography patterns remain prevalent. The 2025 ecosystem study treats software-backed Java cryptography as the historical default on Android if no provider is specified, even on devices that support hardware-backed keys. That legacy matters because much of the practical value of Android Keystore derives not from generic cryptographic functionality alone, but from explicit selection of a backend that preserves key non-exportability under operating-system compromise [2507.07927].

2. Backend taxonomy and threat model

The contemporary Android key-storage landscape is usefully divided into software-backed storage, TEE-backed storage, and secure-element-backed storage. The distinctions are architectural rather than merely API-level.

Backend	Mechanism	Security properties and caveats
Software-backed	java.security.*, javax.crypto.*, Java KeyStore, Cipher, providers such as Bouncy Castle or AndroidOpenSSL / Conscrypt	Historical default if no provider is specified; keys are decrypted into RAM while in use
TEE-backed	TrustZone-style secure execution environment, Android’s Trusty OS, Android Keystore aliases	Strong resistance to kernel compromise and memory extraction; still exposed to more advanced side-channel and architectural attacks
Secure element / StrongBox	StrongBox Keymaster on a physically separate processor with its own CPU, memory, storage, tamper-resistant packaging, and TRNG	Stronger isolation from both the main OS and main processor; optional in practice and subject to availability checks

In the software-backed model, classic Java crypto and keystore APIs remain available through providers such as Bouncy Castle or AndroidOpenSSL / Conscrypt. The large-scale Android analysis treats this model as vulnerable to memory extraction and cold-boot-style attacks because keys are decrypted into RAM while in use, so an adversary with operating-system compromise can recover them. The same study also notes poor security ergonomics in older software APIs, including weak defaults such as ECB mode [2507.07927].

The TEE-backed model centers on TrustZone-style secure execution environments and Android’s Trusty OS. Requests traverse the Android Keystore using string aliases; long-term keys are stored in the secure world and cryptographic operations are performed internally. In this model, even if the normal Android world is rooted, key material should not be exportable from the TEE or exposed in process memory. The guarantee is therefore targeted at attackers who compromise the Android OS, including root-capable malware or a malicious app with elevated privileges, as well as physical attacks that can extract software-resident keys from RAM. The literature is explicit, however, that TEE security is not absolute: TEEs remain exposed to more advanced side-channel and architectural attacks, and prior attacks on SGX and TrustZone are cited as evidence that logical isolation is not equivalent to complete physical robustness [2507.07927].

The secure element, exposed on Android as StrongBox Keymaster, is treated as the strongest Android key-storage backend. Unlike a TEE, it is a physically separate processor with its own CPU, memory, storage, tamper-resistant packaging, and TRNG. The 2025 study attributes to this model all TEE benefits plus stronger isolation from both the main OS and the main processor, improving resistance to cold-boot memory attacks, shared-resource attacks, and certain side channels. Pixel devices are used as examples: Titan M in Pixel 3, Titan M2 from Pixel 6 onward, with Google Tensor interfacing with Titan M2; integrated secure elements can also qualify for StrongBox if they meet the hardware requirements [2507.07927].

Two caveats define the Android Keystore threat model in practice. First, Android Keystore is “best effort”: if suitable hardware is unavailable, the API may fall back to software unless the app checks and enforces hardware availability itself. Second, even hardware-backed keys can still be used on-device by an attacker with root access; the hardware prevents key export, but not necessarily unauthorized invocation of the key on that same device [2507.07927].

3. API surface, key-policy semantics, and security defaults

The dominant initialization primitive in observed Android Keystore usage is android.security.keystore.KeyGenParameterSpec.Builder(String keystoreAlias, int purposes), observed 278,567 times in the 2025 scan. The most common follow-on builder methods were setEncryptionPaddings(String[]) with 235,719 calls, setBlockModes(String[]) with 224,169, setKeySize(int) with 166,379, setUserAuthenticationRequired(boolean) with 48,150, setDigests(String[]) with 48,095, and setRandomizedEncryptionRequired(boolean) with 30,245. StrongBox selection appears through setIsStrongBoxBacked(boolean) with 24,656 total calls. Authentication-related configuration includes setUserAuthenticationValidityDurationSeconds(int) with 23,946 calls, setUserAuthenticationParameters(int,int) with 8,974, setInvalidatedByBiometricEnrollment(boolean) with 6,629, setUnlockedDeviceRequired(boolean) with 383, setUserAuthenticationValidWhileOnBody(boolean) with 93, setUserConfirmationRequired(boolean) with 47, and setUserPresenceRequired(boolean) with 38. Attestation is requested through setAttestationChallenge(byte[]), observed 2,724 times [2507.07927].

The surrounding API surface also includes android.security.keystore.KeyProtection, androidx.security.crypto.MasterKey, the broader androidx.security.crypto package, and Java cryptography entry points such as java.security.KeyStore, java.security.KeyPairGenerator, javax.crypto.KeyGenerator, and javax.crypto.Cipher, where the provider may be specified as AndroidKeyStore or AndroidKeyStoreBCWorkaround. The latter was included in the measurement because of an Android bug dating back to 2015 [2507.07927].

A central design feature of Android Keystore is that it enforces safer configurations than software Java crypto. The 2025 analysis argues that it disallows insecure combinations such as ECB for symmetric encryption and RSA encryption without suitable padding, and that it defaults to randomized encryption with IND-CPA-like guarantees. That default is not absolute, however. Of the 30,245 references to setRandomizedEncryptionRequired(boolean), 77.94% set it to false; relative to all hardware-backed keys, the study estimates that approximately 8.45% of Android Keystore-backed keys disable IND-CPA. Manual inspection identified public libraries that did this, including AWS’s internal key-value store (com.amazonaws.internal.keyvaluestore), Apptentive, and React Native Sensitive Info; some disabled the setting due to custom IVs or claimed API inconsistency on Android 23–28 [2507.07927].

Observed purpose and algorithm choices reveal the API’s practical use cases. Of the 278,056 key initializations where purpose values were recovered, 92.31% were designated for encryption/decryption only and 5.60% for signing or MAC verification. Among 232,283 key-generation calls requesting the Android Keystore provider through Java crypto APIs, 63.51% requested AES, 34.48% RSA key pairs, and 0.9% EC key pairs; appendix counts reported 147,529 AES, 80,096 RSA, 2,233 EC, 2,321 HMAC-SHA256, and 100 HMAC-SHA512. By contrast, among 20,042 calls requesting the software-backed AndroidOpenSSL provider, 99.74% generated RSA and only 51 generated AES, which the study interprets as evidence that developers may avoid hardware-backed storage for asymmetric operations because of performance. For StrongBox specifically, where key size and StrongBox settings could be paired for 98 keys, 97 of 98 were AES-256 and only one was RSA-2048 [2507.07927].

Authentication and attestation features are present but comparatively sparse. The study finds that 15.84% of keys require some user authentication before use, and 2.78% specifically require biometric authentication. Among keys that set a duration, 38.53% used 5 seconds, 4.45% used 1 hour, and 13.2% used 3 seconds or less. By default, authentication is required for every use; the duration APIs permit temporary reuse after one unlock. setUserConfirmationRequired(boolean) was nearly unused: 26 detected calls with arguments, only 2 enabling it. Attestation remained uncommon but nontrivial: 2,724 calls to setAttestationChallenge(byte[]) indicate roughly 0.98% of all keys generated an attestation certificate chain [2507.07927].

4. Ecosystem measurement, adoption, and library-mediated use

The largest available empirical characterization of Android Keystore API usage analyzed 490,119 Play Store apps with at least 10,000 installs that were available during scraping; 486,234 were successfully downloaded and decompiled. App metadata were scraped from October 2023 to March 2024, and Google Play Data Safety labels were used to identify apps self-reporting sensitive-data collection. Static analysis first decompiled APKs using Apktool and then grepped for android.security.keystore, reducing the set to 122,305 candidate apps. Deep analysis used Soot for inter-procedural call-graph construction, allocating 10 GB RAM per APK and imposing a 30-minute timeout; FlowDroid was avoided at this scale because callback-aware call-graph generation was too slow [2507.07927].

The static-analysis signatures were intentionally broad. The scan covered 64 API calls, including direct Android Keystore methods, wrapper APIs that eventually invoke the Keystore—explicitly including androidx.security.crypto.MasterKey and android.security.keystore.KeyProtection—and relevant Java cryptography APIs where a provider might be specified indirectly. For each matched call, the analysis extracted the full calling-method signature, package/class context, the object or register on which the call occurred, and argument values via backward program slicing. It also performed backward breadth-first traversal through the call graph, up to 1,000 nodes, to recover possible call paths and approximate reachability. Reachability was intentionally biased toward avoiding false negatives: a call was considered reachable if any backward path touched first-party code. Package reuse across APKs from different developers was then used to distinguish first-party from third-party usage, with particular focus on calls to android.security.keystore.KeyGenParameterSpec.Builder(String keystoreAlias, int purposes); obfuscated package names were excluded from this party analysis unless a package component had at least three characters [2507.07927].

The resulting adoption numbers are limited but stark. Out of 486,234 decompiled apps, 122,305 contained a Keystore reference, yielding only an upper bound of 25.15% of apps in the dataset using device trusted hardware at all. When restricted to the 159,241 apps that self-reported collecting sensitive data, 69,583 referenced the Android Keystore API, yielding 43.7% adoption and 56.3% non-adoption. The strongest hardware-backed option was far rarer. Among the 116,555 apps with analyzed Keystore references, 22,875 contained a reference to setIsStrongBoxBacked(boolean), equal to 19.62% of Keystore-using apps, 4.7% of the overall app dataset, and 5.03% of apps collecting sensitive data. Because the API takes a boolean, argument values were examined for 21,022 of 24,630 calls: 94.85% requested StrongBox while 5.15% explicitly disabled it. Extrapolating from those values, the authors estimated that 22,367 apps—4.6% of the full dataset—actually request StrongBox for at least one key [2507.07927].

The study also shows that apparent Keystore use frequently arises through dependencies rather than direct design choices by application developers. Of 199,156 key-initialization calls in non-obfuscated packages, 94.69% came from third-party libraries and only 5.31% from first-party code. For StrongBox, the skew was stronger still: of 17,400 StrongBox calls in non-obfuscated packages, 98.31% were in third-party libraries and only 294 calls, or 1.69%, were first-party. Dominant packages included com.google.android.gms.internal.firebase-auth-api, androidx.security.crypto, com.appsflyer, androidx.biometric, com.microsoft.appcenter.utils.crypto, com.google.crypto.tink.integration.android, com.oblador.keychain.cipherStorage, Microsoft identity packages, Salesforce, iProov, and Flutter secure storage libraries. The study accordingly notes that much of the measured Keystore use may be incidental through SDKs such as EncryptedSharedPreferences, EncryptedFile, biometrics wrappers, authentication libraries, or analytics and development tooling [2507.07927].

The sensitivity analysis relies on Google Play’s Data Safety labels. Apps were classified as “sensitive” if they self-reported collecting any of 12 of Google’s 14 high-level data categories, excluding “App info and performance” and “Device or other IDs.” Of the 342,872 apps with Data Safety information, 46.75% were classified as sensitive. The study also notes a structural limitation: Google’s notion of “collected” excludes data processed only locally on-device, so some apps handling sensitive local data may not appear sensitive in the labels. This implies that counts of sensitive apps that omit Keystore usage may be conservative [2507.07927].

Because the methodology is static, the resulting numbers are explicitly treated as an upper bound on secure-storage adoption rather than definitive proof that all sensitive keys are hardware-backed. Dead code cannot be fully excluded, static analysis cannot determine which runtime secrets are stored with which backend, and API presence alone cannot establish that the most sensitive application data are protected by the strongest available hardware [2507.07927].

5. Performance characteristics and backend selection

The first empirical performance study of trusted hardware in Android measured software-backed, TEE-backed, and StrongBox-backed operations on AWS Device Farm using a benchmark app built according to Android documentation. The benchmark covered symmetric key generation, asymmetric key generation, symmetric encryption with AES-GCM-256 / no padding, message signing using ECDSA with SHA-256, and small-payload asymmetric encryption for the common pattern of encrypting a tiny software AES key using a hardware RSA key. Reported figures are averages over 100 iterations, except for very large payload tests, where the count was reduced to 10 [2507.07927].

Key generation exposes the basic performance gradient between backends. On a Pixel 8, generating an AES-GCM-256 key took 0.002 s in software, 0.021 s in the TEE, and 0.071 s in StrongBox. RSA-2048 generation was much costlier: 0.21 s in software, 1.93 s in the TEE, and 9.22 s in StrongBox. The implication drawn in the study is direct: symmetric generation overhead is negligible across backends, whereas StrongBox can be costly for on-demand or frequent asymmetric key generation [2507.07927].

For symmetric encryption, TEE-backed Keystore remained within a practically viable range across Pixel devices from 2016 to 2023. Encrypting 1 MiB with AES-GCM-256 took around 0.78 s on the original Pixel and 0.41–0.42 s on Pixel 8. The software-backed provider was substantially faster, about 0.02 s for 1 MiB on Pixel 8, but the study argues that for payloads at or below 1 MiB the user-visible difference between software and TEE is usually negligible. StrongBox, by contrast, was dramatically slower: 1 MiB AES-GCM on Pixel 8 averaged 15.43 s, versus 0.42 s in the TEE and 0.02 s in software; Pixel 3 required 63.43 s for the same 1 MiB StrongBox operation. The study summarizes StrongBox as roughly 35–55 times slower than TEE for symmetric encryption depending on device, and explicitly states that this contradicts documentation describing StrongBox as only “a little slower” [2507.07927].

Payload-length experiments on Pixel 8 make the practical regime separation clear. For AES-GCM-256 encryption, TEE times increased from 0.03 \pm 0.01 s at 0.01 MiB to 13.10 \pm 1.44 s at 16 MiB; StrongBox increased from 0.21 \pm 0.01 s to 257.69 \pm 1.09 s over the same range. Runtime grew roughly linearly with message size. Using a threshold of under 3 seconds as “acceptable,” the study concluded that StrongBox is suitable only up to about 0.2 MiB, whereas the TEE remains acceptable up to around 2 MiB [2507.07927].

The same pattern appears for signing. On Pixel 8, ECDSA with SHA-256 required 0.02 \pm 0.01 s in the TEE and 0.15 \pm 0.02 s in StrongBox for 0.01 MiB, but 1.76 \pm 0.05 s in the TEE and 35.91 \pm 0.09 s in StrongBox for 4 MiB. The TEE was about 20 times faster than StrongBox at 4 MiB. For tiny asymmetric encryption payloads, however, the trade-off changes: on Pixel 8 for 256-bit payloads, TEE RSA encryption averaged 0.0065 s and StrongBox 0.0125 s, which the study treats as evidence that StrongBox is practical for key wrapping or hybrid-encryption workflows where the hardware key encrypts only a small symmetric key [2507.07927].

Cross-device results reinforce both backend asymmetry and ecosystem fragmentation. TEE-backed AES-GCM encryption of 1 MiB clustered around 0.1 s on Samsung Galaxy A15, A35, S24, and Xiaomi 13, while Pixel 8 was slower at 0.41 s. Among devices with secure elements, StrongBox varied materially: Pixel 8 took 15.43 s for 1 MiB AES-GCM and Galaxy S24 took 26.39 s. Some newer Samsung and Xiaomi devices lacked StrongBox altogether and threw StrongBoxUnavailableException when it was requested [2507.07927].

The resulting operational guidance is narrowly scoped but concrete. For symmetric encryption, the evidence favors TEE-backed Android Keystore as a practical default for most ordinary app payload sizes: it offers materially stronger protection than software-backed storage against operating-system compromise and memory extraction, while adding little user-visible overhead until payloads become large. StrongBox is better reserved for small, high-value secrets, key wrapping, or infrequent operations where latency is acceptable, rather than for bulk symmetric encryption or frequent asymmetric key generation [2507.07927].

6. Adjacent key-management domains and research context

Android Keystore API manages per-app runtime cryptographic keys on a device; it is not the same thing as the developer-managed credentials used to sign APKs for publication and updates. A 2026 longitudinal study of Android app signing-key protection is therefore relevant chiefly by contrast. That study does not directly analyze Android Keystore API, KeyStore or KeyChain system services, or app-generated hardware-backed keys for in-app cryptography. Instead, it examines developers storing long-lived signing credentials in Java keystore files such as .jks and .keystore, together with passwords in repositories or build systems. Its central lesson is that APK signing keys should not be treated like ordinary app secrets or local files; the closest connection to Android Keystore is that high-value keys should be protected using stronger mechanisms such as hardware-backed storage, isolated signing services, multi-factor-controlled environments, or Play App Signing, rather than repository-resident Java keystores and plaintext Gradle secrets [2606.21487].

This distinction is important because the compromise semantics differ. Android Keystore is designed to prevent extraction of runtime keys under device compromise, while leaked release-signing keys allow attackers to produce forged APKs that Android accepts as legitimate updates from the original developer. The 2026 study accordingly underscores a broader point for Android security architecture: secure key protection is not exhausted by device-local cryptographic APIs, and long-lived supply-chain credentials impose different operational requirements from on-device application keys [2606.21487].

A separate 2025 OP-TEE wallet paper situates Android Keystore in another way: as a general-purpose secure-service model that can be specialized. That work does not use Android Keystore API for its main blockchain private keys. Instead, it proposes a custom wallet-specific path built on AOSP, TrustZone, OP-TEE, a Wallet Manager HAL or Binder interface, and chain-specific Trusted Applications housed in a multi-tenant TA store. Its relevance is architectural rather than API-specific. The proposal mirrors several keystore principles—hardware-backed non-exportability, secure boot, authenticated updates, and service-mediated key use—but replaces the standard Android flow with a domain-specific secure subsystem optimized for blockchain key generation, storage, import, and signing [2506.17988].

Taken together, these adjacent lines of work suggest a useful conceptual boundary. Android Keystore API is the standard Android mechanism for application-runtime key protection under an operating-system-compromise threat model; release-signing keys belong to release-engineering and distribution infrastructures rather than to ordinary app cryptography; and custom TrustZone services can reproduce keystore-like properties for specialized domains, but at the cost of standardization and ordinary app compatibility. Within that broader landscape, the strongest empirical conclusion remains the one from the 2025 Android app ecosystem scan: Android Keystore is underused relative to the sensitivity of data many apps report handling, TEE-backed Keystore is usually practical, and StrongBox offers stronger isolation but remains too slow for many direct cryptographic workloads [2507.07927].