Introduction to Android’s Secure Element (SE)

The Secure Element (SE) is a tamper-resistant hardware component designed to securely store sensitive data and execute cryptographic operations in isolation from the main operating system. In the context of Android, SEs are critical for a multitude of security-sensitive applications, including mobile payments (NFC-based transactions), digital identity, secure authentication, and Digital Rights Management (DRM). Examples of SEs include embedded SEs (eSE), SIM/UICC cards, and even host-card emulation (HCE) which, while not a true hardware SE, leverages similar security principles for certain use cases.

Android provides a standardized API, Open Mobile API (OMAPI), for applications to interact with SEs. This abstraction allows developers to access the SE’s capabilities without needing to understand the underlying hardware specifics. However, for security researchers, penetration testers, or those seeking to understand low-level platform behavior, reverse engineering the Android Secure Element service internals is essential to uncover how the OS mediates access to these critical hardware components.

The Android Secure Element API (OMAPI)

The primary entry point for Android applications to interact with Secure Elements is through the android.se.omapi package. This package provides a set of classes that allow applications to discover available SEs, open sessions, and exchange APDUs (Application Protocol Data Units) with applets running on the SE.

Key Classes and Interfaces

• SEService: The central class for managing connections to Secure Elements. It allows applications to query for available SE readers and establish a connection to the SE service.
• Reader: Represents a physical or logical reader that can host one or more Secure Elements (e.g., an NFC controller connected to an eSE, or a SIM card slot). It provides methods to check if an SE is present and to open a session to it.
• Session: Represents an active connection to a Secure Element. A session is required before an application can open a communication channel to an applet.
• Channel: The actual communication path to a specific applet on the Secure Element. Applications send APDUs through this channel and receive responses.
• ISecureElementService, ISecureElementReader, etc.: These are Binder AIDL interfaces that define the communication contract between client applications (or the android.se.omapi wrapper) and the core Secure Element service running within the Android framework.

Deconstructing the SE Service – A Reverse Engineering Approach

Reverse engineering the Android SE service typically involves several stages, from identifying the service to analyzing its interaction with hardware abstraction layers (HALs).

Step 1: Identifying the Core SE Service

The first step is to locate the primary system service responsible for managing SE interactions. On most Android systems, this is handled by a service often named SecureElementService, part of the system server process. You can use dumpsys to list running services:

adb shell dumpsys activity services > services.txt

Search services.txt for