Table of Contents
Fetching ...

On Securing the Software Development Lifecycle in IoT RISC-V Trusted Execution Environments

Annika Wilde, Samira Briongos, Claudio Soriente, Ghassan Karame

Abstract

RISC-V-based Trusted Execution Environments (TEEs) are gaining traction in the automotive and IoT sectors as a foundation for protecting sensitive computations. However, the supporting infrastructure around these TEEs remains immature. In particular, mechanisms for secure enclave updates and migrations - essential for complete enclave lifecycle management - are largely absent from the evolving RISC-V ecosystem. In this paper, we address this limitation by introducing a novel toolkit that enables RISC-V TEEs to support critical aspects of the software development lifecycle. Our toolkit provides broad compatibility with existing and emerging RISC-V TEE implementations (e.g., Keystone and CURE), which are particularly promising for integration in the automotive industry. It extends the Security Monitor (SM) - the trusted firmware layer of RISC-V TEEs - with three modular extensions that enable secure enclave update, secure migration, state continuity, and trusted time. Our implementation demonstrates that the toolkit requires only minimal interface adaptation to accommodate TEE-specific naming conventions. Our evaluation results confirm that our proposal introduces negligible performance overhead: our state continuity solution incurs less than 1.5% overhead, and enclave downtime remains as low as 0.8% for realistic applications with a 1 KB state, which conforms with the requirements of most IoT and automotive applications.

On Securing the Software Development Lifecycle in IoT RISC-V Trusted Execution Environments

Abstract

RISC-V-based Trusted Execution Environments (TEEs) are gaining traction in the automotive and IoT sectors as a foundation for protecting sensitive computations. However, the supporting infrastructure around these TEEs remains immature. In particular, mechanisms for secure enclave updates and migrations - essential for complete enclave lifecycle management - are largely absent from the evolving RISC-V ecosystem. In this paper, we address this limitation by introducing a novel toolkit that enables RISC-V TEEs to support critical aspects of the software development lifecycle. Our toolkit provides broad compatibility with existing and emerging RISC-V TEE implementations (e.g., Keystone and CURE), which are particularly promising for integration in the automotive industry. It extends the Security Monitor (SM) - the trusted firmware layer of RISC-V TEEs - with three modular extensions that enable secure enclave update, secure migration, state continuity, and trusted time. Our implementation demonstrates that the toolkit requires only minimal interface adaptation to accommodate TEE-specific naming conventions. Our evaluation results confirm that our proposal introduces negligible performance overhead: our state continuity solution incurs less than 1.5% overhead, and enclave downtime remains as low as 0.8% for realistic applications with a 1 KB state, which conforms with the requirements of most IoT and automotive applications.
Paper Structure (21 sections, 11 figures, 3 tables)

This paper contains 21 sections, 11 figures, 3 tables.

Figures (11)

  • Figure 1: Overview of the system components of various RISC-V-based TEE architectures. The symbols mark the architecture in which each component is present. Components that are not common to all architectures are dashed.
  • Figure 2: System model capturing the interaction of Keyfort with the ecosystem. The Keyfort modules -are integrated into the SM binary during build -. Enclave applications then include the Keyfort library -. Untrusted system components are dashed.
  • Figure 3: Overview of enclave-local time operation. The SM tracks $t_E$ and $t_E^{entry}$ during context switches (App$\rightarrow$Enclave 1 and Enclave 1$\rightarrow$OS). Grey areas indicate Enclave 1’s active runtime at time $t$ when it queries its local time.
  • Figure 4: Overview of the state continuity module. Cross marks indicate enclave initializations or state imports aborted due to mismatches with the SM (shown in gray), while check marks denote successful operations.
  • Figure 5: Migration Protocol
  • ...and 6 more figures