4 min read

Hidden Weaknesses in Secure Elements and Enclaves

Jan Lindquist : 10. January 2025

Mobile App Security MASC Secure Enclave
Hidden Weaknesses in Secure Elements and Enclaves

Secure elements (SE) on Android and secure enclaves on iOS have emerged as trusted hardware-backed solutions for storing and protecting sensitive information, such as cryptographic keys. They are often touted as tamper-resistant, isolated, and secure environments with the highest certifications (e.g., AVA_VAN.5 under Common Criteria). However, while the hardware is robust, the software layers above it introduce significant vulnerabilities. 

This blog post highlights the risks of relying solely on SEs or secure enclaves, including potential hooking attacks, emulation, and the implications of jailbroken/rooted devices. We also explore how software-level weaknesses can undermine hardware-backed security. 

What is a Secure Element (SE) and Secure Enclave? 

This section introduces essential terms and the flow of secure elements (SE) and secure enclaves, helping readers build a foundational understanding of their integration into Android and iOS ecosystems. This understanding is crucial for grasping the attack methods discussed in the next section. 

Secure Element (SE) on Android: 

The SE is a tamper-resistant hardware module designed to store cryptographic keys, payment credentials, and sensitive data. Protection uses hardware-based cryptographic operations 

Communication is performed via the OS and the following APIs: Keymaster, Keystore and OMAPI 

Secure Elements (SE) in Android can take different forms, each serving distinct purposes. Broadly, these include SEs embedded in the mobile device (used via APIs like Keymaster and Keystore) and SEs associated with applets or payment systems (managed through APIs like OMAPI). 

Android Secure Element Use Cases: Keystore, Keymaster, and OMAPI 

Secure Elements (SE) in Android provide distinct APIs for different layers of interaction, catering to specific use cases.

Hardware layer MASC 3 1

While Keystore API and Keymaster operate at different abstraction levels, both serve general-purpose cryptography needs and rely on hardware-backed keys. OMAPI, on the other hand, is specifically designed for direct SE communication and domain-specific interactions. 

 Secure Enclave on iOS: 

The Secure Enclave in iOS is a dedicated hardware-based coprocessor isolated from the main CPU and is used for Key generation, encryption, and biometric data storage. The private keys are generated inside the enclave (non-exportable). 

Communicates is performed via the OS and the following APIs: Keychain Services or CryptoKit APIs.

Diagram: How SE/Enclave Integrates with Software 

Hardware layer MASC 1 

 

Relation to Android and iOS: 

  • Programming for SE or Secure Enclave is typically done at the native libraries or upper API layers. Developers interact with higher-level abstractions such as Android Keystore or OMAPI on Android, and Keychain Services on iOS. 
  • The HAL interface (Hardware Abstraction Layer) is not directly accessible to developers. It serves as a bridge between the hardware and kernel, ensuring secure and standardized communication with the hardware layer. Accessing the HAL requires deep system privileges and is tightly integrated into the OS kernel. 

Software Risks: Hooking and Emulation 

This section explains how secure hardware-backed mechanisms, despite their strong protections, can still be compromised through emulation and hooking. It introduces the tools and methods attackers use to bypass SE and Secure Enclave protections, setting the stage for understanding real-world risks. 

Emulation involves creating a software-based replica of secure environments, such as Secure Elements or Secure Enclaves, to bypass hardware protections. Unlike physical SEs, emulated environments do not enforce tamper resistance, making them susceptible to interception and manipulation. 

 Android: Secure Element Vulnerabilities 

Hooking SE Communication: 

Tools like Frida and Xposed Framework enable attackers to intercept and manipulate communication between applications and the SE: 

 

Tool/Method 

Description 

Frida 

Hooks into Android Keystore APIs like Cipher or Signature to alter data. 

Xposed Framework 

Allows method interception, e.g., channel.transmit in OMAPI. 

Emulators/Rooting 

Software-based SEs are easier to intercept in emulated/rooted environments. 

 

Example Code (Frida Hooking): 

Java.perform(function ()

{var Channel = Java.use('org.simalliance.openmobileapi.Channel');

Channel.transmit.implementation = function (apdu){

console.log('APDU Sent: ' + apdu);

var result = this.transmit(apdu); 

console.log('Response: ' + result); 

return result; 

}; 

}); 

 

 Why Emulators Should Be Avoided at All Costs: 

If you develop an app and it runs on an emulator, you cannot trust the environment. Emulators lack the hardware-backed protections inherent in physical Secure Elements, leading to vulnerabilities such as information disclosure and tampering. Running apps on emulators should be avoided at all costs to mitigate these risks. 

  • Emulator Detection: An app should not run on an emulator under any circumstances, as emulators lack the hardware protections of physical SEs. Running on emulators risks information disclosure and tampering. 
  • Interceptable: All communication on emulators can be intercepted, and any keys created with the assumption of hardware protection are vulnerable to tampering and information disclosure. 

iOS: Secure Enclave Risks 

While the Secure Enclave is hardware-isolated, vulnerabilities arise in: 

  • High-Level APIs (e.g. Keychain Services): 

    Intercept API calls via Frida or similar tools (on jailbroken devices). 
  • Jailbreaking:

    iOS security relies on system integrity. Jailbreaking disables code signing, exposing high-level API calls to hooking. 

Example Code (Frida Hooking on Keychain): 

Interceptor.attach(Module.findExportByName(null, "SecItemAdd"), { 

    onEnter: function (args) { 

        console.log("SecItemAdd Attributes: " + ObjC.Object(args[0])); 

    } 

}); 

 

 

The Root of the Problem: Trusting the OS 

Even with SE/Enclave hardware certified to AVA_VAN.5 (highest security rating), the OS above the hardware introduces weaknesses: 

  • Rooted Android Devices: Allow full control over the system, enabling hooking and tampering with cryptographic operations. 
  • Jailbroken iOS Devices: Bypass code signing and sandboxing, exposing APIs to hooking tools. 

Risks Introduced: 

  1. Information Disclosure: Hooking APIs to intercept sensitive data (e.g., APDU commands, encryption keys). 
  1. Data Tampering: Manipulating APDU responses or cryptographic functions. 
  1. Environment Emulation: Emulating SE environments to bypass hardware-backed protections.
     

 Mitigating the Risks 

The distinct APIs for Secure Elements—Keystore, Keymaster, and OMAPI—require targeted mitigations due to their different abstraction levels and roles. For instance, Keymaster operates closer to the hardware, and securing it requires addressing native-level vulnerabilities alongside general software hardening. 

While hardware-backed solutions provide strong security, developers and organizations must consider additional safeguards: 

  1. Integrity Checks: Implement runtime integrity verification to detect rooting or jailbreaking. 
  1. Multi-Factor Authentication: Combine SE/Enclave protection with user biometrics or secure authentication mechanisms. 
  1. Hardware Verification: Use attestation services to verify the device’s hardware state and ensure non-emulated environments. 

Example for Attestation: 

  • Use Android’s Play Integrity API (formerly SafetyNet Attestation) or iOS’s DeviceCheck API. 
  1. Limit Sensitive Data on SE APIs: Minimize reliance on software layers to interact with the hardware. 

Flow Diagram: Risks of Trusting Only the Hardware 

Hardware layer MASC 2 1

 

Conclusion 

Secure elements on Android and secure enclaves on iOS are invaluable tools for protecting sensitive keys and cryptographic operations. However, their security cannot be guaranteed in the presence of compromised software environments, such as rooted or jailbroken devices. By understanding the risks of  hooking, emulation, and OS vulnerabilities, developers can adopt additional protections to safeguard user data. 

Hardware-backed security is only part of the solution—a holistic approach that combines hardware integrity, software hardening, and runtime protections is essential. 

Cryptomathic’s Mobile Application Security Core (MASC) addresses these very challenges by providing end-to-end protection against hooking, emulation, and tampering. For example, we successfully protected the Belgium EUDI wallet, ensuring one of the most secure deployments in Europe. When it comes to safeguarding sensitive user data and trust, there should be no compromises. 

Contact Cryptomathic today to learn how MASC can help implement these critical security measures and mitigate the risks discussed. 

 

Key Takeaway: Trust the hardware, but verify the software.