How to Inspect Hardware Secure Elements and OMAPI Readers on Android Using ADB dumpsys secure_element

In modern mobile architectures, securing sensitive cryptographic keys, contactless payment credentials (such as Google Pay), transit cards, and digital car keys requires dedicated tamper-resistant hardware. While Android leverages Trusted Execution Environments (TEE) for general Keystore operations, high-assurance security applets execute inside physical Secure Elements (SE). These include embedded Secure Elements (eSE), integrated Secure Elements (iSE), or smart card microchips embedded directly within SIM/UICC cards. In the Android framework, the Open Mobile API (OMAPI) and the underlying SecureElementService manage secure communications between client applications and physical secure element readers. Using the Android Debug Bridge (ADB) to execute dumpsys secure_element, mobile security engineers, payment application developers, and QA teams can inspect active SE reader terminals, audit hardware HAL bindings, examine package access control rules, and verify channel lifecycles.

Architecture of the Android Secure Element Subsystem

The Android Secure Element framework operates within com.android.server.secure_element.SecureElementService and coordinates communication over standard ISO 7816 smart card interfaces:

• SE Readers (Terminals): Physical and logical interfaces recognized by the system. Common readers include eSE1 (the primary embedded chip on the motherboard) and SIM1/SIM2 (the cellular smart card microchips).
• Hardware Abstraction Layer (ISecureElement HAL): The low-level vendor driver (such as [email protected]) providing direct serial bus access (e.g. SPI or I2C) to the secure element hardware.
• Access Control Enforcer (ARA-M / ARA-D): Evaluates Access Rule Applications stored within the Secure Element. Before an Android application is permitted to open a logical channel to an on-chip applet, the system queries the secure element to verify that the calling APK’s SHA-256 signing certificate matches authorized access rules.
• Logical and Basic Channels: Channels allocated to client applications for transmitting Application Protocol Data Units (APDUs). Channel 0 is reserved as the Basic Channel, while Channels 1 through 19 manage concurrent isolated sessions.

Extracting Secure Element Diagnostics via ADB

To inspect the status of on-device Secure Elements and OMAPI readers, execute dumpsys secure_element from an active ADB terminal:

# Capture the complete SecureElementService diagnostic dump
adb shell dumpsys secure_element

# Filter for terminal reader names and connected HAL instances
adb shell dumpsys secure_element | grep -E "Reader|Terminal|Connected|Channel"

If the device has hardware secure element support, the dump details each recognized terminal reader and its underlying hardware binding.

Auditing Connected Readers and Hardware Terminals

Within the diagnostic dump, locate the section detailing registered terminal readers. Reviewing these fields confirms whether the operating system successfully initialised the physical controllers:

# View detailed reader configurations in dumpsys
adb shell dumpsys secure_element | grep -A 8 "Reader:"

Examine the following key parameters:

• Reader Name (e.g., eSE1 or SIM1): Confirms the hardware identity. Devices with dual SIM trays expose separate terminals for each slot (SIM1 and SIM2).
• mIsConnected: A boolean indicating whether the framework established a healthy binder connection to the vendor Secure Element HAL daemon. If false, verify hardware bus initialisation in dmesg or inspect SELinux denials.
• mChannels: Lists all currently allocated logical channels, their client package UIDs, and assigned session tokens.
• ATR (Answer To Reset): The raw hexadecimal ATR string returned by the smart card chip during power-on initialization, confirming ISO 7816 protocol compliance and baud rate negotiation.

Evaluating Access Control Rules and Security Permissions

Unlike standard Android permissions granted via AndroidManifest.xml, communicating with Secure Element applets requires cryptographic authorization stored within the chip itself:

• Access Rule Application Master (ARA-M): An applet located on the Secure Element with standard AID (A0000001514441434D00). When an app invokes SEService.getReaders() and attempts to open an applet, SecureElementService queries the ARA-M applet for matching certificate hashes.
• Certificate Hash Verification: If the APK’s release key hash is present in the ARA-M access rule table, the channel opens. If the rule is absent or if the APK is signed with an unauthorized debug key, the framework throws a SecurityException: Access Control Enforcer: Access Denied.

Inspect active access control cache entries in the diagnostic dump to verify whether rules have been parsed successfully from the hardware.

Troubleshooting Secure Element Communication Failures

When payment or secure digital key applications fail to communicate with on-chip applets, evaluate common hardware and framework bottlenecks:

• Exhausted Logical Channels: Secure Elements support a finite number of concurrent logical channels (typically 4 to 20). If background applications leak channels without calling Channel.close(), subsequent requests fail with IOException: No free channel available. Audit active channel counts in the dump.
• NFC / SE Bus Contention: On many mobile platforms, the Near Field Communication (NFC) controller and the embedded Secure Element share an I2C/SPI physical bus. Intense contactless polling can temporarily lock the bus.
• Vendor HAL Crashes: If the vendor daemon (e.g., android.hardware.secure_element-service) crashes, mIsConnected reports false. Restart the service or inspect system crashes via adb logcat -s SecureElementService.