PaperlayerView exact revision on arXiv

Source-linked AI summary

MATEE: Efficiently Bridging the Semantic Gap in TrustZone via Arm Pointer Authentication

Shiqi Liu, Xiang Li, Jie Wang, Yongpeng Gao, Jiajin Hu

arXiv:2608.20583v1cs.CR

TL;DR

TrustZone’s semantic gap limits secure-world validation of normal-world requester identities and parameters, enabling malicious CAs to forge requests against other CAs’ sensitive data. MATEE uses Arm Pointer Authentication to bind resource IDs to CA identities and verifies them at access time. It defends against the recognized Type-II SGVs with a reported minimum performance overhead of 2.19%, while remaining bounded by storage and hardware-support limitations.

  • Problem

    TrustZone’s secure world has limited visibility into normal-world requester identities and parameters, allowing forged requests that compromise other CAs’ sensitive data.

  • Method

    MATEE uses Arm Pointer Authentication to sign resource IDs with CA identities during allocation and verify those signatures when resources are accessed.

  • Results

    MATEE’s evaluation validates protection against all six recognized Type-II SGV types and reports a minimum performance overhead of 2.19%.

  • Takeaways & Limitations

    Authenticated resource IDs provide process- and thread-level isolation while supporting legal sharing among threads of the same CA.

  • Takeaways & Limitations

    MATEE’s runtime storage protection does not preserve identity across TEE OS restarts, and full implementation requires Armv8.3-A PAC support.

Abstract

from arXiv · show

Trusted Execution Environments (TEEs) employ hardware-based isolation mechanisms to safeguard the confidentiality and integrity of sensitive code and data. One such prevalent implementation is Arm TrustZone, which partitions the system into the secure and normal (non-secure) worlds. However, this partitioning results in the secure world having very limited visibility into the operating information of the normal world, creating a semantic gap between these two worlds. Specifically, the secure world lacks an effective user identity authentication when receiving data requests from the normal world. Consequently, malicious Client Applications (CAs) in the normal world can deceive Trusted Applications (TAs) in the secure world by utilizing elaborate request parameters, compromising the sensitive data stored by other CAs. We systematically classify these Semantic Gap Vulnerabilities (SGVs) and propose a mate system for the TEE called MATEE to defend against SGVs. MATEE utilizes Arm Pointer Authentication (PA) to bind each request to the corresponding CA's identity and then verifies the identity when the CA accesses sensitive data, thereby preventing malicious request forgery. In particular, MATEE isolates sensitive data of different CAs without modifying existing CAs and TAs. Our evaluation demonstrates that MATEE successfully defends against SGVs with a minimal runtime overhead (2.19%).

1 INTRODUCTION

TrustZone’s secure world has limited visibility into normal-world requester identities and parameters, enabling semantic-gap attacks against sensitive TEE resources. MATEE binds resource access to CA identities with Arm Pointer Authentication and achieves broad protection with low overhead.

  • Problem: TrustZone’s asymmetric isolation leaves the secure world unable to reliably verify CA identities and request parameters.Malicious CAs can forge requests to access other CAs’ sensitive data, address spaces, or potentially the Rich OS.
  • Problem: SGVs are classified into Type-I pointer-based vulnerabilities and Type-II resource-ID-based vulnerabilities.The paper focuses MATEE on Type-II SGVs, whose resource IDs are not bound to CA identities and are often guessable or obtainable.
  • Approach: MATEE uses Arm Pointer Authentication to sign resource IDs with a CA identity during allocation and verify signatures during resource access.The capability-based design provides authenticated resource IDs without requiring the secure world to manage CA identities directly.
  • Approach: MATEE supports process- and thread-level resource isolation, legal sharing among threads, and compatibility with existing CAs and TAs.Its prototype adds 984 lines of code to the TCB.
  • Evaluation: MATEE’s security evaluation finds it immune to evaluated SGVs, while performance testing reports minimal overhead.The authors evaluate against HPE, BOOMERANG, and other SGVs using simulator, board, microbenchmark, and real-world application prototypes.

2 BACKGROUND

Armv8-A TrustZone separates secure and non-secure software and uses shared memory for CA–TA communication. The background describes BOOMERANG and HPE attacks that exploit weak validation of pointers, sessions, global state, and storage identifiers, alongside Arm PA’s signing mechanism.

  • TrustZone Architecture: Armv8-A TrustZone divides software between secure and non-secure states across four exception levels.CAs and the Rich OS operate in the REE, while TAs and the TEE OS operate in the TEE; shared memory transfers data between CAs and TAs.
  • Semantic Gap Vulnerabilities: BOOMERANG attacks include PTRSAN bypass, type confusion, and shared-memory hijacking.These attacks exploit missing offset checks, pointer misclassification, or forged shared-memory identifiers.
  • Semantic Gap Vulnerabilities: HPE attacks exploit stateful TAs through forged session IDs, unrestricted global variables in single-instance TAs, and forged persistent-storage IDs.These paths can expose or corrupt sensitive data across sessions.
  • Semantic Gap Vulnerabilities: SGVs stem from insufficient semantic information for validating normal-world request parameters and requester identity.The paper distinguishes pointer manipulation from resource-ID attacks and reports additional TA-heap and opaque-handle variants.
  • Arm Pointer Authentication: Arm Pointer Authentication signs critical data using a pointer value, context, and key, then truncates the resulting signature into a PAC.PAC capacity depends on address-space configuration, reaching up to 31 bits for a 32-bit TEE virtual address when MTE is disabled.

3 OVERVIEW

MATEE targets Type-II Semantic Gap Vulnerabilities by binding TEE resource identifiers to CA identities with Arm Pointer Authentication. Its design emphasizes scalability, compatibility, security, and efficiency while trusting the secure-world software, Rich OS, and hardware.

  • MATEE extends its trust model to the Rich OS because the Rich OS supplies semantic information needed to mitigate attacks by normal-world CAs.
  • MATEE focuses on Type-II SGVs, including attacks involving shared resources, TA sessions, global variables, persistent storage, heap addresses, and opaque handles.
  • The paper excludes side-channel, denial-of-service, and physical attacks from its scope.
  • MATEE aims to defend existing and future SGVs without requiring CA or TA rewrites or major Rich OS and TEE OS architectural changes.
  • MATEE signs resource IDs in the Rich OS or TEE OS and authenticates them during access, using CA identity information appended by the TEE driver.
  • The implementation modifies fewer than a thousand lines of TCB code and targets minimal performance overhead through hardware-based authentication.

4 DESIGN

MATEE’s design manages CA identities, PAC authentication, exceptions, and trusted-thread assignment to preserve identity distinctions across normal- and secure-world interactions. PA contexts encode process or session identity according to the sharing mode.

  • MATEE comprises CA identity management, exception handling, PAC signing and authentication, and trusted thread management modules.
  • MATEE replaces potentially predictable PIDs with a 32-bit random_id synchronized with the CA process lifecycle.
  • PAC validation failures terminate the current CA in the Rich OS, while TEE OS failures set pac_fail, clear the session, and return an error.
  • TEE OS system calls use only random_id for SESSION_PUBLIC contexts and combine random_id with session ID for SESSION_PRIVATE contexts.
  • Trusted-thread scheduling matches invoking CA random_id values to preserve signing and verification key consistency across requests.
  • Internal interrupts allow direct resumption, whereas externally handled interrupts pause trusted threads until the normal-world service completes.

5 DEFEND AGAINST SGVS

MATEE applies PAC-based authentication and identity-aware handling to shared memory, sessions, TA variables, heap data, opaque handles, and persistent storage. These defenses address multiple SGV forms while preserving existing API calling conventions, with explicit scope boundaries.

  • MATEE signs and authenticates session IDs and shared memory IDs, embedding signatures in their high bits without additional storage.
  • The TEE driver signs shared memory IDs after allocation and registration, while memory references remain constrained to pre-registered or allocated shared memory.
  • TA session IDs are signed during creation and validated during invocation, cancellation, and session closure.
  • MATEE blocks single-instance TAs containing user-defined global variables and recommends heap variables for TA data sharing.
  • Cross-session sharing uses a signed global pointer accessed through SetInstanceData() and GetInstanceData() with SESSION_PUBLIC context.
  • New INVARIANT_VALUE_INPUT and INVARIANT_VALUE_OUTPUT parameter types use PA to protect heap variables transferred between the REE and TEE.
  • MATEE modifies 91 TEE Internal APIs to protect five opaque-handle categories while preserving original API calling conventions.
  • Opaque-handle handling authenticates direct APIs, passes PAC-bearing handles through wrappers, and authenticates before removal in mixed APIs.

6 IMPLEMENTATION

MATEE is implemented in two prototypes: a security-focused functional prototype on Arm FVP and a performance prototype on Rock Pi 4B. The implementations integrate PA support while accounting for hardware differences.

  • The functional prototype is validated for security and compatibility on the Arm FVP simulator.The FVP supports Armv8.3-A PA, which MATEE requires for its hardware-based authentication design.
  • MATEE’s implementation includes a functional prototype on FVP and a performance prototype on Rock Pi 4B.The two prototypes separate security and compatibility validation from performance evaluation across different platform capabilities.
  • The performance prototype is evaluated on the Rock Pi 4B development board.Because the board lacks Armv8.3-A PA support, the prototype simulates PA instructions in software.

7 SECURITY EVALUATION

MATEE’s security evaluation examines its implementation footprint and defenses against Type-II SGVs. The analysis reports effective mitigation across the tested vulnerability classes and attack strategies.

  • 7.1 TCB: 984 lines of code modify the TCB without altering the architecture of Linux or OP-TEE OS.Changes add CA identity management, trusted thread management, PAC authentication, exception handling, and static analysis support.
  • 7.2 SGVs Mitigation Analysis: The evaluation uses attack scenarios involving shared memory, TA sessions, global variables, heap memory, persistent storage, and opaque handles.These scenarios model malicious CAs using victim resource identifiers or handles to access or alter sensitive data.
  • 7.2 SGVs Mitigation Analysis: MATEE provides effective defense against all six types of Type-II SGVs across evaluated CA isolation settings.The evaluation covers inter-process and inter-thread isolation across single- and multiple-TA-instance configurations.
  • 7.3 Security Analysis: PAC verification binds resource access to the CA identity and corresponding TA session ID, preventing direct exploitation of acquired resource IDs.The PA context supplies the identity information needed to reject resource-ID impersonation.
  • 7.3 Security Analysis: User-level PA signatures fail verification because user and privileged levels use distinct PAC keys.This addresses attempts to reuse signatures generated through PA instructions at the user level.
  • 7.3 Security Analysis: A 31-bit PAC and exception handling limit brute-force attacks to one incorrect guess before the malicious adversary is terminated.The secure-world PAC length makes brute-forcing costly and time-consuming, while failed verification triggers termination.
  • 7.3 Security Analysis: Unique PAC contexts for CA processes and TA sessions make replayed signed resource IDs ineffective.Distinct PAC keys are also used for adversary threads during Rich OS authentication.

8 PERFORMANCE EVALUATION

MATEE is evaluated against the original OP-TEE baseline through client-API measurements, microbenchmarks, and real-world applications. The reported overheads are generally modest, with variation across tests and configurations.

  • 8 PERFORMANCE EVALUATION: 2.19% average performance overhead is reported across MATEE’s performance evaluation.The evaluation covers TEE Client APIs, OP-TEE xtest microbenchmarks, and ported real-world applications, with each test repeated 100 times.
  • 8.1 Impact on the REE Side: 1.69% average overhead occurs for TEE Client APIs compared with the original OP-TEE baseline.All operations remain below 7% overhead; OpenSession() costs 864.153 µs and RequestCancellation() has the highest overhead at 6.23%.
  • 8.2 Microbenchmarks: MATEE passes all 137 xtest cases, including 31,072 subtests, with zero regression-test errors.The eight regression-test groups produce 1.36% total overhead, while the TEE Internal Arithmetical API has 6.07% higher overhead than baseline.
  • 8.2 Microbenchmarks: 1.39% average overhead is reported across ten xtest regression groups, including 0.19% for global-variable sharing and 2.81% for heap sharing.The heap-sharing result is reported as an additional regression test, alongside the native Set/GetInstanceData() comparison.
  • 8.2 Microbenchmarks: 4.19% total runtime overhead occurs across 28 xtest benchmark tests.The SHA tests show approximately 9% overhead and the AES tests around 5% compared with the baseline.
  • 8.3 Real-world Applications: AVB shows a 2.67% average runtime reduction, while Trusted Keys’ GetRandom API shows a 2.46% reduction.These results come from the real-world application evaluation; other configurations can instead incur overhead.
  • 8.3 Real-world Applications: 4.44% is the highest overhead when only the dropout, connection, and softmax layers run in the TEE, with 1.27% overall average overhead.This result concerns the DarkneTZ application configuration described in the evaluation.

9 DISCUSSION

MATEE’s current protection is bounded by long-term storage, resource-sharing, hardware compatibility, and availability considerations. These boundaries identify deployment settings where additional mechanisms or design changes are needed.

  • Long-Term Storage Protection: Long-term storage protection ends when the TEE OS restarts, potentially allowing any CA with the storage ID to access the file.Persistent user identities, rather than CA process IDs, are needed in metadata for long-term protection.
  • Resource Sharing: Resource sharing is supported across TEE OS threads but not currently across threads in the Rich OS.Changing Rich OS PAC key management might enable dynamic synchronization between threads with shared resources.
  • Backward Compatibility: Full MATEE implementation requires PAC support and therefore excludes devices older than Armv8.3-A.Software-based pointer-integrity schemes may provide backward compatibility across Arm, Intel, and AMD platforms.
  • Availability: Immediate termination after failed signature verification mitigates brute-force attacks but may enable denial-of-service attacks by malicious CAs.A proposed mitigation is to cap verification attempts within a time window and delay or suspend requests after the threshold.

10 RELATED WORK

Related work addresses capability security, pointer authentication, TrustZone vulnerabilities, and TEE privilege reduction through varied hardware and isolation techniques. MATEE is distinguished by applying Arm PAC to TEE security rather than user-space or kernel-space protection.

  • Capabilities-Based Systems: Capability-based systems enforce fine-grained least-privilege security through hardware capability primitives, with CHERI combining conventional CPU performance and capability-system guarantees.The cited related work presents CHERI as a hybrid capability-system architecture.
  • PAC-Assisted Systems: PAC-assisted systems use pointer authentication across RISC-V and Arm platforms for security properties including control-flow integrity and memory safety.These systems include FPGA implementations and Arm-based protections for heap and stack safety.
  • PAC-Assisted Systems: MATEE is presented as the first scheme using PAC to enhance TEE security, unlike prior user-space and kernel-space protections.Prior work applies PAC to user-level or kernel control-flow integrity, kernel isolation, or memory safety.
  • TrustZone Vulnerabilities: TrustZone vulnerabilities span software components such as the TEE OS, TAs, and bootloaders, providing multiple potential exploit avenues.SGVs are characterized as confused deputy attacks that exploit TEE privileges against the REE side.
  • TEE Privilege Reduction Techniques: TEE privilege-reduction techniques create additional isolated regions or enclaves to reduce secure-world privileges or avoid expanding its trusted computing base.Examples include dividing the TEE OS into zones, confidential virtual machines, and normal-world enclaves.

11 CONCLUSION

MATEE targets Type-II Semantic Gap Vulnerabilities by authenticating resource IDs with Arm Pointer Authentication. The paper reports coverage of recognized Type-II SGVs and a minimum performance overhead of 2.19%.

  • Conclusion: MATEE mitigates Type-II SGVs by using authenticated resource IDs to isolate resources among CA processes and threads.The paper addresses BOOMERANG, HPE, TA heap compromises, and opaque handle compromises.
  • Conclusion: MATEE’s evaluation validates its capability to counter all six recognized types of Type-II SGVs.The evaluation includes microbenchmarks and real-world applications such as DarkneTZ.
  • Conclusion: 2.19% is MATEE’s minimum performance overhead in evaluations using microbenchmarks and real-world applications.The reported evaluations include applications such as DarkneTZ.
Loading 2608.20583v1…