Android Keystore and Hardware-Backed Key Storage Explained

When an Android app says it protects your encryption keys on your device, that statement does not tell you the whole story. The keys might be protected by the operating system, isolated inside a trusted execution environment, or stored in stronger dedicated security hardware. Understanding the difference helps explain why some cryptographic keys are difficult to extract, why rooted devices can still present security risks, and why certain banking and authentication apps check a device's security state.

Android provides a framework called the Android Keystore system that allows apps to generate and use cryptographic keys without directly handling their raw key material. Depending on the device and the key's configuration, those keys may receive software-level protection or hardware-backed protection.

These arrangements are not equivalent. They offer different security guarantees, and neither should be treated as a complete solution to every threat. This guide explains how they work, how developers can inspect a key's security level, and what the results mean in practice.

In this post

1. What Android Keystore actually does
2. Software-backed keys
3. Hardware-backed keys, TEE and StrongBox
4. Comparing the security levels
5. How developers can check a key's security level
6. Key attestation and verified boot
7. What rooting or unlocking the bootloader changes
8. How applications use Keystore
9. Limitations and common misconceptions
10. What Android users should know

1. What Android Keystore actually does

The Android Keystore system allows an application to create or import cryptographic keys and use them for permitted operations. Depending on the key configuration, those operations may include signing data, verifying signatures, encrypting information, or decrypting ciphertext.

The important distinction is that an application does not normally receive the raw key material when it uses a Keystore-managed key. Instead, it requests an operation through Android's cryptographic APIs, and the underlying Keystore implementation performs the operation or delegates it to secure hardware.

For example, an application might generate a private key to sign a transaction. The app supplies the transaction data to a signing operation, and Android returns the digital signature. The private key itself does not need to be exposed to the application process.

This arrangement reduces the risk of accidental key exposure and can make extracting the key substantially harder. It also allows Android to enforce restrictions such as permitted cryptographic algorithms, key purposes and, where supported and configured, user-authentication requirements.

Important distinction: Android Keystore is a system interface and key-management framework, not a guarantee that every key is stored in dedicated security hardware. The protection depends on the security level of the individual key and the device's implementation.

For the official technical overview, see the Android Keystore system documentation.

2. Software-backed keys and their limitations

A software-backed key is protected by software rather than being guaranteed to reside inside a trusted hardware security environment. Android's Keystore APIs can still manage the key and restrict how an application uses it, but the key's protection ultimately depends more heavily on the operating system and its security controls.

This does not mean that a software-backed key is automatically stored as an ordinary, unencrypted file. The implementation may use protected storage and other operating-system safeguards. The important point is that software-level protection is not the same as isolating the key inside a hardware security boundary.

Consider an application that stores sensitive information using encryption. If the encryption key is software-backed, an attacker who compromises the operating system may have a better opportunity to access the key or interfere with the process that uses it. The exact outcome depends on the Android version, the implementation, the key configuration and the attacker's privileges.

When software-backed protection can be appropriate

• Applications with moderate security requirements and limited exposure to sophisticated attacks.
• Devices that do not support the required hardware-backed algorithms or key configurations.
• Non-critical cryptographic operations where compatibility is more important than the strongest available isolation.

Software-backed protection is not useless. It can provide meaningful security against ordinary applications and less privileged attackers. However, developers should not assume it provides the same resistance to operating-system compromise as a key held inside secure hardware.

3. Hardware-backed keys: TEE, secure elements and StrongBox

Hardware-backed Keystore keys are designed to keep their key material inside a security environment that is isolated from the normal Android operating system. When the required hardware and algorithm support are available, cryptographic operations can be performed within that environment without exposing the raw key to the application or normal operating-system memory.

Android commonly distinguishes two hardware security levels: a Trusted Execution Environment (TEE) and StrongBox. They are related concepts, but they are not interchangeable.

Trusted Execution Environment (TEE)

A TEE is an isolated execution environment, often implemented using processor security features such as ARM TrustZone. It separates certain sensitive operations from the normal operating system. A hardware-backed Keystore implementation can use the TEE to protect keys and enforce supported cryptographic restrictions.

This isolation raises the difficulty of extracting keys through ordinary operating-system attacks. However, the strength of the protection still depends on the hardware, firmware, security implementation and the specific vulnerabilities involved.

StrongBox

StrongBox is a more specifically defined Android security level backed by dedicated secure hardware, such as an embedded secure element or an integrated secure enclave implementation that meets the relevant StrongBox requirements.

StrongBox implementations are designed to provide stronger isolation and tamper resistance than a typical TEE-backed implementation. They can also support key attestation. However, StrongBox generally supports a narrower set of algorithms and operations and may perform some operations more slowly.

Developers should therefore select StrongBox based on their threat model rather than assuming every application needs it. For many applications, a TEE-backed key provides an appropriate balance between protection, compatibility and performance.

Android explains these differences in its documentation on StrongBox KeyMint.

4. Software-backed vs hardware-backed keys

Property	Software-backed	TEE-backed	StrongBox-backed
Security boundary	Primarily software and OS controls	Isolated trusted environment	Dedicated secure hardware meeting StrongBox requirements
Raw key exposure	Depends on implementation and compromise level	Designed to keep supported keys inside secure hardware	Designed to keep supported keys inside secure hardware
Resistance to OS compromise	More limited	Improved protection against direct key extraction	Stronger isolation and tamper resistance
Attestation	Does not establish hardware-backed protection	Supported on compatible implementations	Supported
Algorithm support	Depends on Android's software implementation	Depends on the device's secure implementation	More restricted than general-purpose implementations
Availability	Depends on the Android implementation	Depends on device hardware and implementation	Optional; not available on every device

This comparison describes general properties, not a guarantee about every device. A device can support hardware-backed keys for one algorithm but not another. Developers should inspect the security level of the actual key they create rather than infer it from the phone model alone.

5. How developers can check a key's security level

Android developers can inspect the security level of a generated Keystore key using the KeyInfo API. On Android 12 (API level 31) and later, getSecurityLevel() provides a way to distinguish software enforcement, TEE protection and StrongBox protection.

The following Java example generates an AES key, retrieves its metadata, and reports the security level. It is intended for an Android application and should be run on a test device.

import android.os.Build;
import android.security.keystore.KeyGenParameterSpec;
import android.security.keystore.KeyInfo;
import android.security.keystore.KeyProperties;

import java.security.KeyStore;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;

public class KeystoreInspector {

    public static String inspectAesKey() throws Exception {
        String alias = "defmek_keystore_test";

        KeyGenerator generator = KeyGenerator.getInstance(
            KeyProperties.KEY_ALGORITHM_AES,
            "AndroidKeyStore"
        );

        KeyGenParameterSpec spec =
            new KeyGenParameterSpec.Builder(
                alias,
                KeyProperties.PURPOSE_ENCRYPT
                    | KeyProperties.PURPOSE_DECRYPT
            )
            .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
            .setEncryptionPaddings(
                KeyProperties.ENCRYPTION_PADDING_NONE
            )
            .setKeySize(256)
            .build();

        generator.init(spec);
        SecretKey key = generator.generateKey();

        SecretKeyFactory factory =
            SecretKeyFactory.getInstance(
                key.getAlgorithm(),
                "AndroidKeyStore"
            );

        KeyInfo info = factory.getKeySpec(
            key,
            KeyInfo.class
        );

        if (Build.VERSION.SDK_INT >= 31) {
            int level = info.getSecurityLevel();

            switch (level) {
                case KeyProperties.SECURITY_LEVEL_STRONGBOX:
                    return "StrongBox-backed";

                case KeyProperties.SECURITY_LEVEL_TRUSTED_ENVIRONMENT:
                    return "TEE-backed";

                case KeyProperties.SECURITY_LEVEL_SOFTWARE:
                    return "Software-backed";

                default:
                    return "Unknown security level: " + level;
            }
        }

        if (Build.VERSION.SDK_INT >= 23) {
            return info.isInsideSecureHardware()
                ? "Hardware-backed; exact level not reported here"
                : "Not reported as hardware-backed";
        }

        return "This example requires API level 23 or later";
    }
}

The example reports the security level of the key generated by the application. It does not establish the security level of every other key on the device, and it does not test whether the operating system is rooted or whether remote attestation will be accepted by a particular service.

How to interpret the result

• StrongBox-backed: Android reports that this key is protected by a StrongBox security implementation.
• TEE-backed: Android reports that the key is protected by a trusted execution environment.
• Software-backed: The key's security enforcement is reported as software-based.
• Unknown: The returned level does not justify a more specific conclusion. Do not automatically interpret an unknown value as software-backed.

Testing note: This sample uses a fixed alias for demonstration. A production application should manage aliases carefully, handle key-generation errors, consider existing keys, and define a proper lifecycle for key replacement and deletion. Do not put diagnostic key-generation code into a production security decision without testing the behavior on supported devices.

For the exact API behavior, consult the official KeyInfo reference and KeyProperties reference.

6. Key attestation and verified boot

Inspecting a key locally answers a limited question: what security level does Android report for this key? A remote server may need stronger evidence before it trusts a key presented by an application.

Android key attestation provides signed evidence about a key and certain properties of the environment in which it was generated. An application can request an attestation challenge from its server and include that challenge when generating an eligible key. The resulting certificate chain can contain an attestation record describing the key's security level and relevant device security properties.

The server must then validate the evidence. That includes checking certificate signatures and trust anchors, validating the challenge, checking revocation information where applicable, and interpreting the attestation fields according to the application's security policy.

What the attestation fields mean

Depending on the attestation version and device implementation, the certificate extension may include fields relating to the security level and the device's verified boot state.

• Security level: Indicates whether the relevant key or attestation mechanism is associated with software, a trusted execution environment, or StrongBox.
• Device locked: Reports whether the bootloader was locked as represented in the attested root-of-trust information.
• Verified boot state: Describes the reported state of the verified boot chain, such as verified, self-signed, unverified or failed.
• Patch information: Depending on the attestation version, relevant security patch levels may also be included.

These fields are not interchangeable. Hardware-backed key protection does not automatically establish that the operating system is in a state accepted by a particular service. A key may be hardware-backed while the attestation shows a boot state that fails the service's policy.

Read Google's guide to verifying hardware-backed key pairs and the Android Open Source Project attestation specification for implementation details.

Security principle: Attestation is evidence that must be verified, not a magic label. A server should not trust a client merely because the client claims that its key is hardware-backed.

7. What rooting or unlocking the bootloader changes

Rooting and bootloader unlocking affect different parts of Android's security model, and their consequences should not be treated as identical.

Unlocking the bootloader

An unlocked bootloader generally allows modified operating-system images to be installed. Android's verified boot mechanism uses a chain of trust to check the integrity and authenticity of software during startup. Unlocking the bootloader changes the device's boot security state and can allow software that would not be accepted under the original locked configuration.

This can affect key attestation because an attestation record may report an unlocked bootloader or an unverified boot state. A remote service that requires a locked device and a specific verified boot state may reject the device even when its cryptographic key is hardware-backed.

Root access

Root access gives software elevated privileges on the operating system. Depending on how root was obtained and what modifications were made, it may allow an attacker to inspect application processes, change system behavior, interfere with security checks, or access information that would normally be protected.

Hardware-backed keys can still resist direct extraction when the key material remains inside secure hardware. However, a compromised operating system may be able to request permitted cryptographic operations on the user's behalf. If an attacker can control an application at the moment it decrypts data, the attacker may also target the plaintext rather than extract the key.

Do not confuse key protection with device integrity. A hardware-backed key can remain non-extractable even when a device's boot state is unacceptable to a remote service. Conversely, a device that passes a particular integrity check is not guaranteed to be free from every vulnerability.

For more information, see the Android documentation on Verified Boot and device boot states.

8. How applications use Keystore in practice

Password managers

A password manager may use a Keystore key to protect another encryption key or to secure access to locally stored secrets. This can make direct extraction more difficult, especially when hardware-backed protection and user-authentication requirements are configured.

However, the Keystore does not automatically encrypt every password manager database. The application must design the complete encryption process, protect any intermediate secrets, and avoid exposing decrypted passwords unnecessarily. A compromised app session may expose information that is already decrypted and displayed to the user.

Banking and payment applications

A banking application may generate a private key in Android Keystore and use it to sign authentication challenges or transaction data. The bank's server can verify signatures using the corresponding public key.

Some services also require key attestation or use other device-integrity checks. These are separate controls: signing proves possession of a particular private key, while attestation can provide evidence about how that key was created and aspects of the device's security state.

Encrypted messaging applications

A messaging app may use Keystore to protect a local encryption key or a key that protects other cryptographic material. This can reduce the risk of someone copying key material from device storage.

It does not, by itself, guarantee the security of the entire messaging system. Message security also depends on the protocol, key exchange, endpoint security, backup behavior and how the application handles messages after decryption.

Authenticator applications

Authenticator apps can store sensitive secrets and other account information that require protection. Keystore may help protect encryption keys used to secure those secrets, but it does not automatically mean that every time-based one-time password secret is stored inside hardware.

Developers need to distinguish between a secret stored directly in application data and an encryption key held by Keystore. That distinction determines which parts of the design benefit from hardware-backed protection.

9. What hardware-backed Keystore does not guarantee

Hardware-backed key protection is valuable, but it is not a substitute for a secure application design. Several limitations are important when evaluating claims about Android device security.

• It does not make every key non-extractable. Protection depends on how the key was created or imported, its security level and the supported hardware implementation.
• It does not stop every use of a key by compromised software. An attacker who controls the operating system or application may be able to request operations that the key is authorized to perform.
• It does not protect all plaintext automatically. Data may still be exposed when an application decrypts it, displays it or processes it in ordinary memory.
• It does not prove that an app is trustworthy. Key protection and application integrity are separate questions.
• It does not guarantee that every device supports StrongBox. Hardware capabilities and supported algorithms vary.
• It does not eliminate hardware or implementation vulnerabilities. Security depends on the quality of the implementation and the threat being considered.

These limitations do not make hardware-backed keys ineffective. They explain why robust applications combine key protection with secure coding, access controls, carefully designed authentication, appropriate server-side validation and secure data handling.

10. What Android users should know

Most Android users do not need to create or inspect Keystore keys themselves. Nevertheless, understanding the system helps when evaluating device security and applications that depend on it.

• Keep Android and security updates current. Updates can address vulnerabilities in the operating system, firmware and security components.
• Understand the consequences of unlocking the bootloader. It may change verified boot behavior, trigger a data wipe and cause some security-sensitive services to reject the device.
• Use reputable applications. Hardware-backed key storage cannot compensate for an application that mishandles passwords, exposes decrypted data or has a weak security design.
• Maintain appropriate backups. Hardware-backed keys are often bound to a particular device and are not simply portable to a new phone. Apps should provide a secure recovery or re-enrollment process.
• Do not assume that reinstalling an app restores its old keys. Uninstalling an app normally removes its app-specific Keystore entries, although exact behavior depends on the system and application lifecycle. Restoring app files alone may not restore the ability to use those keys.

For developers, the best approach is to identify the actual threat model, choose the appropriate key type and security level, enforce only the restrictions the application genuinely needs, and verify security claims through documented APIs and server-side validation.

Key takeaways

• Android Keystore lets applications use cryptographic keys without normally exposing their raw key material to the application.
• Software-backed keys rely more heavily on operating-system protections.
• TEE-backed keys use an isolated trusted execution environment.
• StrongBox provides a distinct hardware security level with stronger isolation and tamper-resistance requirements.
• Developers can inspect an individual key's reported security level using Android's KeyInfo APIs.
• Key attestation can provide signed evidence about a key and relevant device security properties.
• Rooting or unlocking the bootloader can weaken device integrity without necessarily making a hardware-backed key extractable.
• Hardware-backed storage does not prevent every attack against an application, its plaintext or its authorized key operations.

Further reading

• Android Developers: Android Keystore system
• Android Developers: KeyInfo API reference
• Android Developers: KeyProperties API reference
• Android Developers: Verify hardware-backed key pairs with key attestation
• Android Open Source Project: Key and ID attestation
• Android Open Source Project: Verified Boot

Understanding Android Keystore starts with a simple distinction: protecting a key, proving where a key is protected, and proving the integrity of the device are three different security goals. Hardware-backed keys can provide strong protection against direct extraction, but meaningful device security depends on how those keys are used and how the rest of the system is designed.