PaperlayerView exact revision on arXiv

Source-linked AI summary

CURE: A Security Architecture with CUstomizable and Resilient Enclaves

Raad Bahmani, Ferdinand Brasser, Ghada Dessouky, Patrick Jauernig, Matthias Klimmek, Ahmad-Reza Sadeghi, Emmanuel Stapf

arXiv:2010.15866v1cs.CR

TL;DR

Existing TEEs often offer only one enclave type, cannot flexibly support services requiring peripherals or multiple cores, and provide inadequate cache side-channel protection. CURE introduces multiple customizable enclave types and exclusive resource assignment using minimal hardware changes, with a RISC-V prototype showing moderate performance overhead.

  • Problem

    Existing TEE architectures use one-size-fits-all enclaves and provide inadequate or impractical support for diverse services and cache side-channel protection.

  • Method

    CURE provides sub-space, user-space, and self-sustained enclaves with exclusive assignment of peripherals, CPU cores, and cache resources.

  • Results

    CURE’s RISC-V prototype indicates minimal hardware overhead and a moderate overall performance overhead.

  • Takeaways & Limitations

    CURE enables strongly isolated enclaves adapted to the functionality and security requirements of sensitive services.

  • Takeaways & Limitations

    CURE excludes hardware flaws and physical attacks, and does not protect against software-exploitable vulnerabilities inside enclave code.

Abstract

from arXiv · show

Security architectures providing Trusted Execution Environments (TEEs) have been an appealing research subject for a wide range of computer systems, from low-end embedded devices to powerful cloud servers. The goal of these architectures is to protect sensitive services in isolated execution contexts, called enclaves. Unfortunately, existing TEE solutions suffer from significant design shortcomings. First, they follow a one-size-fits-all approach offering only a single enclave type, however, different services need flexible enclaves that can adjust to their demands. Second, they cannot efficiently support emerging applications (e.g., Machine Learning as a Service), which require secure channels to peripherals (e.g., accelerators), or the computational power of multiple cores. Third, their protection against cache side-channel attacks is either an afterthought or impractical, i.e., no fine-grained mapping between cache resources and individual enclaves is provided. In this work, we propose CURE, the first security architecture, which tackles these design challenges by providing different types of enclaves: (i) sub-space enclaves provide vertical isolation at all execution privilege levels, (ii) user-space enclaves provide isolated execution to unprivileged applications, and (iii) self-contained enclaves allow isolated execution environments that span multiple privilege levels. Moreover, CURE enables the exclusive assignment of system resources, e.g., peripherals, CPU cores, or cache resources to single enclaves. CURE requires minimal hardware changes while significantly improving the state of the art of hardware-assisted security architectures. We implemented CURE on a RISC-V-based SoC and thoroughly evaluated our prototype in terms of hardware and performance overhead. CURE imposes a geometric mean performance overhead of 15.33% on standard benchmarks.

1 Introduction

Existing TEE architectures provide limited, one-size-fits-all enclaves that poorly match diverse services and offer inadequate practical protection against cache side channels. CURE addresses these gaps with multiple enclave types, exclusive resource assignment, and minimal hardware changes.

  • Existing limitations: Existing TEEs typically provide one enclave type, forcing applications to adapt to fixed features and limitations.SGX, for example, restricts enclave system calls and may require frameworks to deploy unmodified applications.
  • Existing limitations: Modern services impose varied requirements, including secure connections to sensors, accelerators, and other peripherals.The requirements arise across applications such as payment, biometric authentication, speech processing, and MLaaS.
  • Existing limitations: Existing TEE defenses against cache and controlled side-channel attacks are incomplete or impractical.Examples include excluding cache attacks from the threat model or heavily influencing the operating system.
  • CURE: CURE provides sub-space, user-space, and self-sustained enclaves that can span privilege levels and multiple CPU cores.These enclave types let boundaries match individual functionality and security requirements.
  • CURE: CURE exclusively binds peripherals to enclaves and provides fine-grained cache resource allocation for side-channel protection.The design supports peripherals with and without DMA support.
  • Contributions: CURE combines architecture-agnostic protection with minimal, non-invasive hardware modifications and a RISC-V prototype evaluated for hardware and performance overhead.The evaluation uses micro- and macrobenchmarks on an FPGA and cycle-accurate simulator setup.

2 System Assumptions

CURE targets modern high-performance multicore systems with caches, TLBs, branch predictors, a central system bus, peripherals, and multiple software privilege levels. The assumed platform also uses secure boot and firmware verification.

  • Platform: CURE targets high-performance multicore systems containing caches, a TLB, branch predictors, a shared cache, and a central system bus.The bus connects CPUs to main memory and various peripherals.
  • Privilege levels: The assumed software hierarchy separates user space at PL3 from kernel space at PL2 and may include hypervisor and firmware privilege levels.The MMU, configured by PL2 software, separates user and kernel virtual address spaces.
  • Boot assumptions: Secure boot verifies firmware through a chain of trust before firmware execution begins.Firmware state is stored encrypted, integrity-protected, and rollback-protected in non-volatile memory.

3 Adversary Model

CURE assumes a strong software-only adversary that can compromise system software and peripherals while leaving a small trusted software or microcode TCB intact. Hardware flaws, physical attacks, denial of service, and enclave-code vulnerabilities remain outside its protection scope.

  • Adversary capabilities: The adversary can compromise all software components except the small trusted computing base that configures hardware primitives and manages enclaves.This includes control over the operating system and other privileged software.
  • Adversary goal: The adversary’s goal is to leak secrets from the TCB or a victim enclave.The model allows malicious system software to exercise enclave-management interfaces.
  • Adversary capabilities: A compromised kernel or hypervisor can inject code, spawn malicious processes and enclaves, and access the TCB interface.The model also permits software compromise of peripherals to perform DMA attacks.
  • Scope boundaries: CURE excludes hardware flaws, physical access attacks, fault injection, physical side channels, malicious physical peripherals, and denial-of-service attacks.An OS-controlled adversary could shut down the complete system, making denial of service out of scope.
  • Scope boundaries: CURE does not protect against software-exploitable vulnerabilities inside enclave code, but prevents their exploitation from compromising the complete system.The model assumes the underlying hardware is correct and trusted.

4 Requirements Analysis

CURE is designed around security requirements for enclave protection, hardware-enforced isolation, a small trusted base, and side-channel resilience, together with functionality requirements for configurable boundaries, peripheral binding, minimal hardware changes, reasonable overhead, and dynamic per-enclave protections.

  • Security requirements: Enclave code and data must remain integrity-protected, confidential, and inaccessible to adversaries across software layers, other enclaves, and DMA.This requirement covers enclave protection while code is at rest and during execution.
  • Security requirements: Security enforcement must rely on hardware primitives configurable only by the software TCB, which must remain small and protected.The TCB should be small enough for formal verification.
  • Security requirements: CURE must mitigate cache, controlled side-channel, and transient-execution attacks.These mitigations are required as part of side-channel attack resilience.
  • Functionality requirements: Enclave trust boundaries must be freely configurable so enclaves can span different privilege levels.This requirement supports dynamic enclave composition.
  • Functionality requirements: Enclaves must support secure binding to selected peripherals, including hardware accelerators for sensitive machine-learning tasks.Peripheral communication must be explicitly supported.
  • Functionality requirements: The design must require minimal hardware changes, maintain reasonable setup and runtime overhead, and enable dynamic per-enclave cache protection.Cache protections must be applicable at runtime on a per-enclave basis.

5 Design of the CURE Architecture

CURE is a flexible TEE architecture that lets enclave boundaries be defined according to protected services’ requirements. It supports multiple enclave types rather than a single fixed enclave model.

  • CURE allows enclave boundaries to be freely defined for different protected services.

5.1 CURE Ecosystem

CURE’s ecosystem coordinates device vendors, users, service providers, and an app-store deployment model for protecting sensitive services. Services may split sensitive functionality into an enclave or integrate it entirely into one.

  • Sensitive services can be split between an enclave and a host app, or integrated entirely into an enclave.
  • Service providers specify enclave resource requirements, version numbers, and globally unique labels in configuration files.
  • Service providers sign enclave binaries and configuration files with asymmetric keys and attach certificates for device-side verification.
  • Device vendors provision each device with a unique asymmetric key pair and certificate for legitimacy claims in remote attestation.

5.2 Customizable and Resilient Enclaves

CURE manages customizable enclaves through a Security Monitor and supports enclave boundaries spanning user space, kernel space, multiple cores, or selected code within a privilege level.

  • Enclave types: CURE supports user-space, kernel-space, cross-privilege-level, and sub-space enclaves with different boundary choices.
  • Enclave management: The Security Monitor manages enclaves after secure boot and controls their setup, execution, and teardown.
  • Enclave management: Enclave state is encrypted and verified during restoration, while teardown removes enclave data from memory and caches.
  • Security mechanisms: CURE flushes core-exclusive cache resources at enclave transitions and supports dynamically configured cache isolation.
  • Kernel-space enclaves: CURE can assign peripherals exclusively to enclaves or share them with other enclaves and the operating system.
  • Sub-space enclaves: Sub-space enclaves isolate selected code within a privilege level, including the Security Monitor from other firmware code.

5.3 Hardware Security Primitives

CURE adds hardware security primitives to CPU register files, the system bus, and the shared cache. These primitives identify enclaves, control resource access, bind peripherals, and provide configurable cache isolation.

  • Security primitives: CURE’s security primitives augment each CPU core’s register file, the system bus, and the shared cache.
  • SP1: Core register files: The enclave ID register records which enclave a core executes and is configured by the Security Monitor during enclave transitions.
  • SP2: System bus: System-bus access control restricts parent-child transactions and supports exclusive enclave-to-peripheral bindings.
  • SP3: Shared cache: CURE mitigates core-exclusive cache attacks with flushing but leaves shared last-level-cache attacks as a concern.
  • SP3: Shared cache: On-demand way-based partitioning allocates cache ways exclusively to enclaves and applies access control using enclave identifiers.
  • SP3: Shared cache: CURE uses way-based partitioning because it requires the least extensive hardware modifications and provides infrastructure for more advanced cache designs.

6 Prototyping CURE on RISC-V

CURE is prototyped on a RISC-V Rocket Chip SoC with multiple enclave types, protected memory layouts, and hardware security primitives spanning cores, the system bus, peripherals, and caches. The prototype uses enclave identifiers and access-control mechanisms to isolate memory and resources.

  • RISC-V System-on-Chip platform: The prototype uses a RISC-V SoC generated with Rocket Chip and multiple in-order Rocket cores.The implementation targets an architecture-agnostic design while instantiating it on RISC-V.
  • Enclave types: CURE implements user-space, kernel-space, and sub-space enclaves, including a security monitor isolated from firmware at the machine level.The security monitor is implemented as a sub-space enclave to separate it from firmware sharing the same privilege level.
  • Enclave memory layout: Each enclave receives a continuous physical memory region containing code and data, page tables, enclave state, dynamic space, and shared memory.The shared-memory region supports communication with the OS and is assigned either to the enclave or to the OS.
  • Memory management: The prototype protects user-space enclave page tables by storing them in enclave memory and routes enclave exits through the security monitor.Custom trap handlers can observe interrupt behavior and detect suspicious interrupt-based side-channel activity.
  • System-bus and peripheral protection: CURE propagates a 4-bit enclave ID through TileLink transactions and applies bus, peripheral, DMA, and memory-range access controls.Access control runs in parallel with arbitration, enabling execution in a single clock cycle without additional latency.
  • Cache protection: Cache entries carry enclave ownership metadata, while strict cache-way partitioning limits the number of simultaneous enclaves using CP-STRICT.The prototype’s cache-way constraint is an implementation decision that could be addressed with more sophisticated cache designs.

7 Security Considerations

CURE uses a trusted security monitor and hardware security primitives to protect enclaves from privileged software, DMA devices, and several cache and controlled side-channel attacks. Its protection model still leaves user-space enclaves exposed to metadata leakage and malicious OS return values when using OS services.

  • Threat model: CURE assumes a strong software-only adversary while trusting a small software or microcode TCB that configures hardware primitives and manages enclaves.The OS and other software components may be compromised under this model.
  • Enclave protection: Hardware security primitives at the system bus and L2 cache enforce enclave protection and are configured by the security monitor.Machine-level trap handling is integrated with the security monitor through the mtvec register.
  • Enclave protection: CURE protects against privileged software and DMA adversaries through physical-address access control at the system bus.L1 data is flushed on context switches, while L2 data is protected through exclusive enclave cache-line assignment.
  • Side-channel attack resilience: Core-exclusive cache, BTB, and TLB side channels are mitigated by flushing on context switches, while shared-L2 attacks are addressed through strict way-based partitioning.Page-table attacks are addressed through protected page tables and hardware restrictions on forbidden page-table-walker accesses.
  • Residual risks: User-space enclaves retain risks from OS-service metadata leakage and malicious return values, requiring application-level countermeasures such as data-oblivious algorithms and result verification.These residual risks do not apply in the same way to kernel-space enclaves, whose resources are handled by the enclave runtime.

8 Evaluation

CURE was evaluated on implementation size, hardware area, microbenchmarks, macrobenchmarks, multi-core workloads, and cache partitioning. The prototype required small software and hardware changes, while performance overhead depended on enclave type, workload, and cache allocation.

  • Evaluation scope: The evaluation covered software and hardware modifications, microbenchmarks, macrobenchmarks, multi-core setups, and L2 cache partitioning.Experiments used FPGA-based setups and cycle-accurate simulators, with 10 runs per experiment.
  • System modifications: The Security Monitor contains around 3KLOC, and isolating it in a sub-space enclave cut the software TCB in half.The firmware contains 3286 LOCs, while management code represents 15.56% of the isolated software TCB.
  • System modifications: 105 LUTs per core extend TileLink through the system bus, while peripheral access control adds 248 LUTs per MMIO peripheral and 112 LUTs per DMA device.Each peripheral-control addition represents below 0.5% overhead relative to the dual-core baseline SoC.
  • System modifications: L2 cache way-based partitioning costs 516 LUTs and 214 registers, equal to 1.8% of L2 cache logic and 0.5% of the entire SoC.The evaluation used a 2048KB, 16-way set-associative shared L2 cache for the partitioning experiments.
  • Microbenchmarks: Binary verification accounts for 91.3% of user-space enclave setup time and 52.1% of kernel-space enclave setup time.Teardown zeroing accounts for 39.9% and 45.7% of overhead for user-space and kernel-space enclaves, respectively.
  • Macrobenchmarks: The geometric-mean macrobenchmark overhead is 19.70% for user-space enclaves and 15.33% for kernel-space enclaves relative to a normal user-space process.Kernel-space enclaves achieved almost the same performance as normal processes on the multi-core stress-ng benchmark; L2 partitioning overhead ranged from under 0.2% to over 9%, with a 3.09% geometric mean.

9 Related Work

Existing TEE architectures generally provide a single enclave type, with varying limitations in cache-side-channel resilience, controlled-side-channel protection, and peripheral binding. CURE is compared against these designs across enclave types, side-channel resilience, and exclusive enclave-to-peripheral assignment.

  • Existing TEE architectures mostly provide only one enclave type, resembling either CURE’s user-space or kernel-space enclaves.
  • SGX provides user-space enclaves but does not protect against cache or controlled side-channel attacks.
  • SGX extensions address side channels through ad-hoc techniques, costly data-oblivious algorithms, or uncommon hardware used in unintended ways.
  • Sanctum mitigates cache and controlled side channels, but page coloring affects the whole OS memory layout and cannot be efficiently changed at run time.
  • CURE dynamically assigns cache ways and provides mechanisms for interrupt-based side-channel mitigation, unlike Sanctum’s page-coloring approach.
  • Keystone partitions cache ways per CPU core, whereas CURE assigns cache ways to enclaves with freely configurable boundaries.

10 Conclusion

CURE provides strongly isolated enclaves that can be adapted to sensitive services’ functionality and security requirements. Its RISC-V instantiation uses hardware primitives across the system bus, shared cache, and CPU, with minimal hardware overhead and moderate overall performance overhead.

  • CURE offers sub-space, user-space, and self-sustained kernel-space enclaves that can execute privileged software.
  • CURE’s protection mechanisms use new hardware security primitives on the system bus, shared cache, and CPU.
  • The authors instantiate CURE on a RISC-V system and report minimal hardware overhead with moderate overall performance overhead.
Loading 2010.15866v1…