Life on the Line: Breaking into a Medical Device by Exploiting TEE/HSM

Life on the Line: Breaking into a Medical Device by Exploiting TEE/HSM

Speakers: Tamil Mathi, Senior Product Security Engineer, Bectific Dickinson Advanced Patient Monitoring

Conference: Biohacking Village

YouTube: https://www.youtube.com/watch?v=Tl48Lg3ReIo

Overview

In this critical presentation from Biohacking Village, Tamil Mathi, a Senior Product Security Engineer at Bectific Dickinson Advanced Patient Monitoring, delves into the often-overlooked vulnerabilities within medical devices leveraging Trusted Execution Environments (TEE) and Hardware Security Modules (HSM). The talk specifically focuses on exploitation techniques targeting implementations of the PKCS#11 standard within an OP-TEE (Open Portable Trusted Execution Environment) architecture. Mathi highlights that despite the robust security primitives offered by TEEs, common misconfigurations and design flaws can render these devices susceptible to attacks, with potentially life-threatening consequences for patients.

The discussion underscores the severe implications of compromised medical devices, ranging from incorrect treatment and delayed care to direct patient harm or even death, citing real-world examples like vulnerable pacemakers. Mathi's expertise, honed through a blend of secure-by-design principles and offensive security practices like red teaming and bug bounty hunting, provides a unique perspective on identifying and mitigating these high-stakes risks. The presentation serves as a stark reminder that security must be an integral, upfront consideration in the development of medical technology, not an afterthought, especially given the rising number of connected medical devices with known vulnerabilities.

This article will dissect Mathi's findings, exploring the architectural components, the specific vulnerabilities uncovered, the demonstration of their exploitation, and crucial defensive strategies. It aims to provide a comprehensive understanding of how to better secure these vital, life-sustaining technologies against sophisticated cyber threats.

Background

▶ Watch: Introduction and talk agenda (0:00)

The security of medical devices is a matter of paramount importance, directly impacting patient safety and trust in healthcare systems. Citing CISA data, Mathi reveals that over 60% of connected medical devices in hospitals harbor known vulnerabilities, a staggering figure that highlights a systemic problem. Unlike typical IT compromises that might lead to data loss, a breach in a medical device can directly manipulate patient data, alter treatment parameters, or even disable critical functions, leading to severe physical harm or death. The 2017 pacemaker vulnerability, requiring invasive surgery for firmware updates, serves as a grim example of the unique challenges in patching implantable devices.

Medical devices are classified based on their invasiveness (non-invasive, minimally invasive, invasive), which directly correlates with their risk profile and the stringency of required security controls, as mandated by regulatory bodies like the FDA in the US and MDR in the EU. A critical oversight, Mathi argues, is often in platform and hardware security. These devices are deployed in "uncontrolled or hostile environments" where physical access is possible. Without robust hardware security measures—such as Trusted Platform Modules (TPM) or Trusted Execution Environments (TEE)—an attacker with physical access could tamper with external interfaces, modify boot parameters to gain root privileges, and bypass all software-level security controls.

Trusted Execution Environments (TEEs) are hardware-backed security mechanisms, often built directly into the CPU, providing a secure area within the main processor. ARM's TrustZone is a well-known implementation, splitting the processor into a Secure World and a Non-Secure World. Code in the Non-Secure World cannot directly access the Secure World; interactions must occur via standardized GlobalPlatform APIs. TEEs offer a cost-effective alternative to physical HSMs for securing cryptographic keys, performing cryptographic operations, and protecting sensitive data like Protected Health Information (PHI) or AI/ML models. While TEE specifications don't explicitly define storage, manufacturers often attach secure storage mediums to the TEE's secure side.

To leverage TEE hardware, a Trusted OS (TOS) is required. These are tiny operating systems with small codebases, intentionally designed to minimize attack surface. Examples include Google's OP-TEE (Open Portable Trusted Execution Environment) used in Android, Qualcomm's QSEE, and Apple's Secure Enclave OS. OP-TEE runs alongside a Rich Execution Environment (REE), typically Linux. Custom Trusted Applications (TAs) run within OP-TEE, isolated from each other and the REE. Communication between applications in the REE and TAs in the TEE is facilitated by GlobalPlatform APIs, which provide a standardized, vendor-agnostic interface for secure interactions, abstracting hardware specifics. These APIs are categorized into Client APIs (used by REE applications) and Core APIs (used by TAs to access secure hardware resources for operations like key generation or random number generation).

The PKCS#11 standard (Cryptographic Token Interface Standard) acts as a universal abstraction layer for cryptographic devices, such as HSMs. It allows applications to perform cryptographic operations without needing to know the specifics of the underlying hardware. PKCS#11 uses an object-based approach, representing keys, certificates, and data as objects, promoting technology independence. Libraries are available across various programming languages, allowing applications to issue PKCS#11 commands, which are then translated by the device's firmware into hardware-specific instructions. In the context of this talk, the crucial architectural design choice is that PKCS#11 is implemented as a Trusted Application (TA) within OP-TEE, effectively creating a virtual, emulated HSM within the secure environment.

Key Findings

▶ Watch: Why medical device security is critical (2:00)

Mathi's research uncovered several critical weaknesses stemming from misconfigurations and insecure design patterns when implementing PKCS#11 as a trusted application within an OP-TEE architecture. These vulnerabilities can severely undermine the security promises of TEEs, leading to unauthorized access to sensitive data and cryptographic keys.

The primary area of concern revolves around weak or insecure PIN management for accessing PKCS#11 slots:

• Known, Easy, or Default Pins: Many implementations utilize easily guessable or default pins, which are often publicly known or simple to brute-force.
• Insecure Pin Storage: Applications often require access to these pins to interact with the PKCS#11 TA. If these pins are stored in plain text or in files on the Linux file system (REE) without proper Access Control List (ACL) hardening, any authenticated user or compromised application can retrieve them.
• Lack of Brute-Force Protection: Some TAs lack mechanisms to prevent or detect brute-force attacks against PINs, allowing attackers to systematically try combinations until successful.
• Hardcoded Pins: Pins hardcoded directly into the application's source code are easily discoverable through reverse engineering or if the source code is compromised.

Another significant finding is privilege sprawl. Over time, multiple applications might be added under the same user context, granting them access to PKCS#11 slots and objects they are not intended to interact with. This expands the attack surface significantly, as a compromise in one application could expose sensitive objects accessible by other applications under the same user.

Misconfigured Object Access Policies are equally dangerous. PKCS#11 objects (keys, data, certificates) have associated access control flags (e.g., CK_EXPORTABLE, CK_SENSITIVE, CK_ALWAYS_AUTHENTICATED) that define permissible operations. If these flags are not carefully and securely configured:

• An object marked CK_EXPORTABLE (especially a private key) can be easily extracted, even if it's considered sensitive. While some firmware might prevent private key export even with this flag, data objects are often extractable by default if this flag is not properly set.
• An object marked CK_MODIFIABLE can be altered, potentially corrupting data or cryptographic primitives.
• The default behavior of data objects being extractable by default if not explicitly secured underscores the need for granular control.

Finally, Mathi highlights severe misconfigurations of the Hardware Unique Key (HUK), which serves as the root of trust for the entire secure storage mechanism:

• All-Zero HUK: In some cases, the HUK is configured as all zeros, especially in devices that use default firmware settings for production. If an attacker can also extract the static string used in key derivation (e.g., from source code), they can easily derive all subsequent keys and decrypt all secure storage data.
• Hardcoded Static String: If the static string used in the HUK derivation process is hardcoded in the source code, it becomes another single point of failure.
• Key Leakage via APIs: Poorly designed TAs might expose APIs that allow for the extraction or leakage of the HUK or other derived keys, completely compromising the secure environment.
• Shared HUK Across Devices: Using the same HUK across an entire fleet of devices means that if one HUK is compromised, the security of all N devices is immediately undermined.

These findings collectively demonstrate that the mere presence of a TEE and PKCS#11 does not guarantee security. The implementation details, particularly around key and PIN management and object access control, are paramount.

Technical Deep Dive

▶ Watch: Device classification and hardware security importance (4:00)

The core of Mathi's technical deep dive lies in understanding how PKCS#11 is integrated into the OP-TEE architecture, specifically when implemented as a Trusted Application (TA). This integration creates a virtual HSM, abstracting the hardware-backed security of the TEE for cryptographic operations.

Architecture of PKCS#11 as a Trusted Application:

In this architecture, common Linux command-line utilities like pkcs11-tool or openssl (when configured with PKCS#11 support) initiate cryptographic operations. These utilities interact with a library, often libckteec, which is responsible for implementing the GlobalPlatform Client APIs.

1. Client-Side Initiation: An application in the Rich Execution Environment (REE) (e.g., Linux) makes a call using pkcs11-tool to perform an action (e.g., list objects, extract data).
2. GlobalPlatform API Translation: libckteec translates this PKCS#11 command into a corresponding GlobalPlatform API call.
3. Mode Switching: This call triggers a Secure Monitor Call (SMC) instruction, a CPU instruction that signals the processor to switch from the Non-Secure World to the Secure World.
4. OP-TEE Core: The SMC instruction directs the request to the OP-TEE core, which acts as a dispatcher.
5. Trusted Application Routing: The OP-TEE core routes the request to the specific PKCS#11 Trusted Application (TA) running within the Secure World.
6. PKCS#11 Command Unwrapping: Inside the PKCS#11 TA, the incoming GlobalPlatform API call is unwrapped and mapped to its corresponding internal PKCS#11 command.
7. Core API Calls: The TA then uses GlobalPlatform Core APIs to access secure hardware resources and perform the requested cryptographic operation (e.g., generate a key, access secure storage).
8. Secure Storage Interaction: For persistent objects, the TA interacts with the secure storage mechanism. Critically, any data leaving the Secure World for storage in the REE is encrypted and integrity-protected.

Secure Storage Implementation Strategies:

OP-TEE typically supports two main strategies for secure storage, both aiming to guarantee confidentiality and integrity for sensitive data:

1. Linux File System (REE): By default, OP-TEE can use the Linux file system (e.g., /data/tee directory) as its secure storage space. Each persistent object is assigned an internal identifier, visible as numbered files (e.g., 1, 2, 3) and a metadata database (df.tadb) in the /data/tee directory. While these files are physically present on the REE, their content is encrypted and integrity-protected by the TEE, rendering them garbage without the correct keys.
2. RPMB Partition of eMMC Device: A more robust, hardware-backed approach uses the Replay Protected Memory Block (RPMB) partition of an eMMC (embedded MultiMediaCard) device. RPMB offers a small, dedicated, and tamper-resistant storage area, ideal for keys or small sensitive data. However, its limited size makes it unsuitable for large amounts of data like PHI. An ideal implementation might combine both: RPMB for keys and critical small data, and the Linux file system for bulk encrypted data.

The Role of the TE Supplicant:

The TE Supplicant is a crucial component that acts as a bridge or "helper" in the Normal World (REE) for the Trusted Application. Since the OP-TEE is a tiny OS and lacks drivers for file systems or eMMC controllers, it cannot directly perform Input/Output (I/O) operations on storage.

• When a TA needs to write encrypted data to the Linux file system or an RPMB partition, it delegates this task to the TE Supplicant.
• The TA encrypts the data using keys only accessible within the TEE.
• Once encrypted, the data is passed to the TE Supplicant, which then writes the encrypted blob to the designated file system location or RPMB partition.
• This delegation ensures that sensitive operations (encryption/decryption) remain within the TEE, while the less secure I/O operations are handled by the REE in a controlled manner.

Hardware Unique Key (HUK) and Key Derivation:

The foundation of OP-TEE's secure storage is the Hardware Unique Key (HUK).

• Root of Trust: The HUK is a master key, typically a 128-bit symmetric key, stored in a One-Time Programmable (OTP) fuse or similar tamper-resistant hardware. It serves as the immutable root of trust and provides protection against offline attacks, as data encrypted with keys derived from the HUK can only be decrypted on that specific device.
• Key Derivation Hierarchy: The HUK is never used directly for bulk data encryption but is used to derive a hierarchy of other keys for security and isolation:

1. Secure Storage Key (SSK): Derived by applying an HMAC (Hash-based Message Authentication Code) on the HUK combined with a static string. The SSK is generated during OP-TEE boot and stored only in memory, never written to disk.
2. Trusted Application Storage Key (TASK): Each Trusted Application (TA) gets its own unique TASK, derived from the SSK. This provides isolation, meaning a compromise of one TA's storage key does not affect others. The TASK is used to encrypt and decrypt the File Encryption Key (FEK).
3. File Encryption Key (FEK): This is the key that ultimately encrypts and decrypts the actual block of sensitive data. The FEK itself is stored encrypted on the file system, protected by the TASK.

• Data Encryption: For actual data blocks, the system uses AES-GCM (Advanced Encryption Standard in Galois/Counter Mode). AES-GCM provides both confidentiality (encryption) and authenticated encryption with associated data (AEAD), which means it also ensures integrity protection. The flow involves decrypting the FEK with the TASK, then using the plaintext FEK to decrypt the data block using AES-GCM.

This multi-layered key derivation and secure storage mechanism is designed to be highly robust, but as Mathi demonstrates, it is only as strong as its weakest link – often, the initial provisioning and configuration of the HUK and the management of PKCS#11 access controls.

Demo / Proof of Concept

▶ Watch: Countermeasures: TPM and TEE explained (6:00)

Tamil Mathi demonstrated the practical implications of these vulnerabilities through a custom tool named open-opts1-security-audit-tool. This tool automates the exploitation scenarios described, showcasing how attackers can gain unauthorized access to sensitive data within medical devices leveraging misconfigured OP-TEE/PKCS#11 implementations.

The tool’s capabilities include:

1. Brute-Force Attack: It can perform brute-force attacks against known weak PINs or default pins used for PKCS#11 slot authentication. This is effective against TAs lacking brute-force protection mechanisms.
2. Object Enumeration: Once authentication to a slot is successful (either via known/default pins or successful brute-force), the tool can enumerate all objects stored within that PKCS#11 token, including private keys, certificates, and data objects.
3. Access Control Flag Assessment: The tool assesses the access control flags associated with each enumerated object (e.g., CK_EXPORTABLE, CK_MODIFIABLE). It highlights misconfigurations that permit unauthorized operations.
4. Sensitive Object Extraction: If flags are improperly configured (e.g., CK_EXPORTABLE for keys, or simply default extractability for data objects), the tool can extract these sensitive objects directly from the OP-TEE secure storage. Mathi showed an example using pkcs11-tool to query slot index 0 for data type and extract data based on a label to an output file, successfully demonstrating data exfiltration. Another example showed listing a private key object with the CK_EXTRACTABLE flag set, though Mathi noted some firmware might still prevent actual private key extraction even with this flag.
5. Log File Scanning: The tool also scans for sensitive log files (e.g., TEC.log) on the REE (Linux file system) where it has access. This aims to discover inadvertently leaked sensitive information, such as PINs or other details related to OP-TEE or the trusted application.

The demonstration visually confirmed that with tools like pkcs11-tool or openssl, an attacker who gains initial access to the Linux environment and can either guess/brute-force pins or retrieve them from insecure storage can easily interact with the virtual HSM. If the object access policies (flags) are not strictly enforced, extracting critical data objects or even private keys becomes trivial. The ability to list objects and observe their flags, combined with the ability to enter a known or brute-forced PIN, provides a clear pathway to compromise, bypassing the intended security of the TEE.

Defensive Implications

▶ Watch: Trusted firmware and secure world concept (8:00)

Securing medical devices leveraging TEE/PKCS#11 requires a multi-faceted approach, addressing both design flaws and operational misconfigurations. Mathi outlined several crucial defensive implications for manufacturers and healthcare providers:

1. Robust PIN Management:

• Avoid Default/Weak Pins: Never use default, easy-to-guess, or hardcoded PINs in production devices.
• Secure Pin Storage: If application-level pins are necessary, they must be stored with stringent ACL hardening on the Linux file system, ensuring only authorized processes can access them. Ideally, pins should be ephemeral or derived securely.
• Brute-Force Protection: The PKCS#11 Trusted Application must implement robust brute-force protection mechanisms, such as locking out slots after a few failed attempts or introducing delays.
• Identity-Based Authentication: Where possible, utilize identity-based authentication, mapping Linux user IDs to slots, providing finer-grained access control than shared user-level PINs.

1. Strict Object Access Control Flags:

• Least Privilege Principle: Implement object access policies following the principle of least privilege. Explicitly define what operations (e.g., read, write, export, modify) are allowed for each object.
• Review CK_EXPORTABLE and CK_MODIFIABLE: Ensure that sensitive keys (especially private keys) are never marked CK_EXPORTABLE. Data objects should also be protected against default extractability and modification if not intended.
• Always Authenticated: For critical operations, use flags like CK_ALWAYS_AUTHENTICATED to ensure every access requires re-authentication.

1. Secure Hardware Unique Key (HUK) Implementation:

• Physically Unclonable Functions (PUFs): Ideally, the HUK should be generated from within the device using Physically Unclonable Functions (PUFs) during manufacturing. This ensures the key is unique to each device, never leaves the System on Chip (SoC), and is never exposed externally.
• Secure Provisioning Process: If external key generation is unavoidable, the manufacturing environment must be tightly controlled with strong access controls, authentication, and secure serial communication for key injection. The provisioning workstation should remove all key traces (memory flush, no disk storage) and have robust auditing.
• Device Authentication: Implement a process to authenticate the device before provisioning the HUK to prevent malicious devices from obtaining keys.
• Key Revocation/Rotation: MPUs (Microprocessor Units) and device firmware should support HUK revocation and rotation capabilities, allowing compromised keys to be invalidated and replaced.
• Unique HUK per Device: Never use the same HUK across multiple devices; each device must have a unique HUK to prevent fleet-wide compromise.

1. Detection and Monitoring Strategies:

• Pseudo Trusted Applications (Pseudo TAs): While TEEs lack rich monitoring interfaces, Pseudo TAs can be developed. These TAs run with the same privileges as the OP-TEE core and can monitor the behavior of other TAs.
• Baseline and Policy Enforcement: Establish a baseline of typical operations for each TA (e.g., expected read/write operations on specific objects). The Pseudo TA can then track these function calls and report anomalies back to a full-blown monitoring system on the Linux side, potentially sending logs to a backend for analysis.
• TE Supplicant Monitoring: Monitor the TE Supplicant for unusual I/O operations or attempts to write encrypted data to unexpected locations.

1. Secure Software Development Lifecycle (SSDLC):

• Security by Design: Integrate security from the earliest design phases, rather than treating it as a checklist item.
• Threat Modeling: Conduct thorough threat modeling to identify potential attack surfaces and vulnerabilities in the TEE/PKCS#11 implementation.
• Code Review and Auditing: Regularly review and audit TA code and related libraries for security flaws, including API exposures and improper key handling.

Challenges in Medical Device Security: Mathi also acknowledged broader challenges:

• Legacy Devices: Many devices are decades old, lack computing power, or network connectivity, making real-time monitoring, detection, and remote patching almost impossible.
• Connectivity Limitations: Hospital restrictions or device limitations prevent internet connectivity, delaying incident response and patch deployment.
• Safety vs. Security Trade-offs: In medical devices, patient safety always takes precedence, which can sometimes complicate security implementations or delay patches if they introduce potential safety risks.
• Manual Updates: Lack of remote update capabilities often necessitates manual updates, leading to significant delays in applying security patches.

Addressing these defensive implications requires a holistic approach involving manufacturers, healthcare providers, and regulatory bodies, emphasizing proactive security integration and continuous vigilance.

Key Takeaways

• Medical device security is paramount and directly impacts patient safety. Over 60% of connected medical devices have known vulnerabilities, making them high-stakes targets with potential life-threatening consequences.
• Trusted Execution Environments (TEEs) like OP-TEE provide strong hardware-backed security primitives, but their effectiveness is entirely dependent on secure implementation. Misconfigurations can negate these benefits, creating critical vulnerabilities.
• Insecure PIN management for PKCS#11 access (e.g., default pins, hardcoded pins, insecure storage, lack of brute-force protection) is a common and critical weakness. This allows attackers to gain unauthorized access to secure slots and objects.
• Misconfigured object access control flags (e.g., CK_EXPORTABLE, CK_MODIFIABLE) enable sensitive data and key extraction or modification. Strict adherence to the principle of least privilege is essential for all PKCS#11 objects.
• The Hardware Unique Key (HUK) is the root of trust, and its misconfiguration (e.g., all-zero HUK, hardcoded derivation strings, API leakage, shared HUK across devices) can completely compromise the entire secure storage system. HUKs must be unique, securely provisioned, and protected by hardware-backed mechanisms like PUFs.
• Proactive security measures, including robust design, secure provisioning, continuous monitoring (e.g., via Pseudo TAs), and a comprehensive Secure Software Development Lifecycle (SSDLC), are essential to mitigate these risks. The unique challenges of legacy devices, connectivity, and safety-security trade-offs must also be carefully managed.

About the Speaker(s)

Tamil Mathi is a Senior Product Security Engineer at Bectific Dickinson Advanced Patient Monitoring. He holds a Master's degree in Cybersecurity from UNCC USA. Mathi's professional focus is on integrating secure-by-design principles into the development of high-stakes technologies, particularly medical devices, to ensure security is a fundamental element rather than an afterthought. His background includes experience as an "actamer" (a blend of attacker and defender), and he maintains his offensive security skills through red teaming, bug bounty hunting, and CVE research. This dual perspective allows him to effectively identify and address vulnerabilities in critical systems. He also contributes to the security community by writing blogs on topics like OP-TEE secure architecture.