How to Inspect Hardware-Backed Cryptographic Keys on Android Using ADB dumpsys keystore

Modern mobile security models rely on asymmetric and symmetric cryptography to protect user passwords, biometric credentials, corporate single sign-on (SSO) tokens, and hardware-attested authentication keys. On Android, application developers use the Android Keystore system to generate and store cryptographic keys. Rather than exposing private keys in application process memory where they could be dumped by malware or memory analysis tools, Android Keystore isolates private keys inside secure hardware.

Depending on the device architecture, keys are protected within a Trusted Execution Environment (TEE) or a dedicated discrete security chip such as StrongBox Keymaster (e.g. Google Titan M, Samsung Knox Vault). If an app experiences cryptographic exceptions, key attestation failures, or authentication authentication loops, security analysts and mobile developers use the Android Debug Bridge (ADB) to inspect active key descriptors and hardware security levels via dumpsys android.security.keystore.

Understanding the Android Keystore Architecture

The Android Keystore service (keystored / keystore2) acts as the intermediary between user-space applications and hardware security modules:

• Hardware Isolation: Private key material never enters host RAM. Cryptographic operations (signing, verification, encryption, decryption) occur entirely within the secure hardware processor.
• Security Levels:
  • SOFTWARE: Software-emulated fallback (insecure; non-hardware backed).
  • TRUSTED_ENVIRONMENT (TEE): Runs in a hardware-isolated secure world (such as ARM TrustZone) separate from the Android Linux kernel.
  • STRONGBOX: Physical discrete microcontroller with separate CPU, RAM, tamper-resistant packaging, and secure real-time clock.
• User Authentication Gates: Keys can be permanently tied to biometric authentication (Fingerprint, Face) or lock screen PIN/password entry, automatically locking when the screen turns off.

Connecting to ADB and Querying the Keystore Service

Connect your Android test device to the workstation with USB debugging enabled. Confirm device responsiveness:

adb devices

On modern Android operating systems (Android 12, 13, 14, and later), Android utilizes the rewritten keystore2 system daemon. Query the complete operational state of the Keystore service:

adb shell dumpsys android.security.keystore

If querying an older Android device (Android 11 or earlier), run the legacy service alias:

adb shell dumpsys keystore

Interpreting Active Key Descriptors and Aliases

The output presents details on active key entries, security levels, and associated application UIDs:

Keystore 2.0 service state:
  Database: /data/misc/keystore/persistent.sqlite
  Active keys:
    KeyDescriptor {
      domain: APP,
      nspace: 10142,
      alias: "CorporateSSOKey",
      blob: [key blob metadata]
    }
    SecurityLevel: TRUSTED_ENVIRONMENT
    Algorithm: RSA_2048
    Purposes: [SIGN, VERIFY]
    BlockModes: []
    Digests: [SHA_256]
    UserAuthentication: Required (Timeout: 300s)

Interpreting Critical Security Parameters

When auditing key properties or debugging authentication failures, evaluate the following fields:

Field Name	Observed Value	Security Meaning
domain	APP, SELINUX, or KEY_ID	Specifies whether the key belongs to an unprivileged app or a privileged system service
nspace	UID integer (e.g. 10142)	Linux User ID of the application package holding ownership of the key alias
SecurityLevel	TRUSTED_ENVIRONMENT or STRONGBOX	Confirms whether the key is hardware-backed in TEE or dedicated StrongBox silicon
Purposes	[ENCRYPT, DECRYPT] or [SIGN]	Hardware-enforced permissible cryptographic operations
UserAuthentication	Required or None	Indicates whether biometric authentication or screen unlock must precede key use

Verifying StrongBox Keymaster Silicon Support

To verify if the connected Android device features discrete StrongBox hardware security silicon (required for advanced enterprise key attestation and FIDO2 authenticators), query device features:

adb shell pm has-feature android.hardware.strongbox_keystore

If the command returns true, the device features dedicated physical security hardware capable of resisting physical probing and clock manipulation attacks.

Auditing App Key Generation Failures in Logcat

When an application fails to generate a key pair or encounters an InvalidKeyException during signing operations, capture real-time Keystore daemon logs:

adb logcat -s keystore2:* android.security.keystore:*

Common errors revealed in the logcat stream include:

• KM_ERROR_KEY_USER_NOT_AUTHENTICATED: The key requires biometric authentication, but the user has not recently authenticated or biometric authentication has timed out.
• KM_ERROR_KEY_PERMANENTLY_INVALIDATED: A biometric-bound key was invalidated because the user enrolled a new fingerprint or changed lock screen credentials.
• KM_ERROR_INCOMPATIBLE_ALGORITHM: The app requested an algorithm or padding mode unsupported by the device’s hardware security module.

Inspecting Key Attestation Certificates

Enterprise applications and banking clients frequently use Key Attestation to verify that a key was generated in real hardware rather than emulated software. Check whether attestation root certificates are loaded in the Keystore daemon:

adb shell dumpsys android.security.keystore | grep -i "attestation"

By regularly inspecting dumpsys android.security.keystore, mobile developers, security auditors, and penetration testers ensure that cryptographic keys are properly isolated within hardware, validating compliance with enterprise data protection standards.