Open Mobile API: Accessing the UICC on Android Devices

This report gives an overview of secure element integration into Android devices. It focuses on the Open Mobile API as an open interface to access secure elements from Android applications. The overall architecture of the Open Mobile API is described and current Android devices are analyzed with regard to the availability of this API. Moreover, this report summarizes our efforts of reverse engineering the stock ROM of a Samsung Galaxy S3 in order to analyze the integration of the Open Mobile API and the interface that is used to perform APDU-based communication with the UICC (Universal Integrated Circuit Card). It further provides a detailed explanation on how to integrate this functionality into CyanogenMod (an after-market firmware for Android devices).

💡 Research Summary

The paper provides a comprehensive examination of how Android devices expose secure elements (SE), particularly the UICC, to applications through the Open Mobile API (OMAPI). It begins by outlining the three‑tier architecture of OMAPI: the application layer (Java‑based SmartcardService and Reader objects), the service layer (SEService, SEChannel implementations), and the hardware layer (native drivers and libraries that directly communicate with physical SEs such as UICC, embedded SE, or SIM‑based SE). The authors note that while the API itself is standardized, each OEM implements the lower layers differently, leading to a fragmented ecosystem.

To illustrate these differences, the authors performed a reverse‑engineering case study on a Samsung Galaxy S3 stock ROM. Using tools such as dex2jar, JADX, and IDA Pro, they extracted the system service SecSEService located in the package com.sec.android.service.se. This service implements the OMAPI Binder interface, receives requests from applications, and forwards them to a native library libseandroid.so. The native library, in turn, communicates with the radio interface layer (RIL) via the RIL_REQUEST_OEM_HOOK_RAW command. By constructing a SIM_IO structure that contains slot ID, channel ID, and APDU payload, the library sends raw commands to the modem, which forwards them to the UICC and returns the APDU response. The response is parsed back in the native code and delivered to the Java layer through SEChannel.

A critical security feature discovered is the use of an authentication token verified inside SecSEService. Only processes with the privileged SECURE_ELEMENT_PRIVILEGED permission and running under the system UID can open channels, preventing ordinary apps from directly accessing the SE. The authors also detail how multiple logical channels are supported by maintaining separate channel identifiers within the native library.

The second major contribution of the paper is a step‑by‑step guide for integrating this functionality into CyanogenMod, an aftermarket Android firmware. The integration consists of two main tasks. First, the standard org.simalliance.openmobileapi package is added to the system image, and an adapter class is written to bridge the standard SEService interface with Samsung’s proprietary SecSEService. This adapter reuses the existing Binder IPC mechanism while exposing the expected OMAPI methods. Second, a custom native library (libsecm.so) is created to replicate the behavior of libseandroid.so. The library is placed under device/<vendor>/<board>/se, compiled via an Android.mk entry, and linked against the device’s RIL implementation. Modifications to the init.rc file ensure that the service runs with the system UID, and the required permissions (android.permission.SECURE_ELEMENT_PRIVILEGED and android.permission.NFC) are declared in the framework’s manifest.

During integration, the authors encountered challenges related to APDU size limits (255 bytes) and proper handling of ISO 7816‑4 status words (SW1/SW2). They added logic in the SEChannel implementation to fragment oversized commands and to interpret status words correctly, ensuring robust communication with the UICC.

To validate the port, a test application was built that initializes SEService, enumerates the UICC’s file system, and reads an ISD‑P file containing authentication data. The test confirmed that APDU commands travel from the Java layer through the Binder service, into the native library, across the RIL, and finally to the UICC, with the expected responses returned to the application.

Overall, the paper demonstrates that despite the existence of a standardized API, OEM‑specific integrations require careful reverse engineering and adaptation. By dissecting Samsung’s implementation and providing a concrete migration path to an open‑source ROM, the authors show that secure element functionality can be preserved and even extended in custom Android builds. This work is valuable for developers seeking to leverage UICC‑based security features—such as mobile payments, secure authentication, or carrier‑controlled app provisioning—on devices where the stock firmware does not expose the Open Mobile API or where the OEM implementation is closed source.