Session
FOSDEM Schedule 2021
Hardware-Aided Trusted Computing

Trusted RV: 64bit RISC-V TEE with Secure CoProcessor as Root of Trust

D.hardware.trusted
Kuniyasu Suzaki
<p>Trusted RV is a combination of 4 core 64bit RISC-V (AC: Application Core) and 1 core 32bit RISC-V Secure Coprocessor (SU: Secure Unit). The SU works as a "Root of Trust" and keeps critical information (e.g., Device Key, Certificate). The SU boots before the 64Bit RISC-V and controls it (i.e., secure boot, etc). The communication from the AC to the SU is limited for TEE (i.e., Keystone Encalve) only and keeps security. Trusted RV is implemented on an FPGA (Xilinx VC707) and a simulator.</p>

We have developed the Trusted RV which is a combination of 4 core 64bit RISC-V and 1 core 32bit RISC-V Secure Coprocessor. The secure coprocessor works as a "Root of Trust" and keeps critical information (e.g., Device Key, Certificate). The secure coprocessor offers machine mode only and runs Zephyr OS. The Zephyr OS includes crypto and certificate-verification libraries and manages the 64bit RISC-V. The secure coprocessor boots before the 64bit RISC-V and verifies it.

The secure coprocessor is tightened with RISC-V Keystone on the 64bit RISC-V to keep security. The 64bit RISC-V runs Keystone as TEE (Trusted Execution Environment), and Secure Monitor (SM) runs on machine mode under the Linux kernel. The secure communication between 64bit RISC-V and Secure Coprocessor is managed by SM only. The communication is passed to a Trusted Application (TA) in a Keystone Enclave only. The secure communication is implanted on the shared memory and mutual interrupts between 64bit RISC-V and Secure Coprocessor. This mechanism is also used for the remote attestation of Keystone which based on the key in the secure coprocessor. The Trusted RV is implemented on a simulator for software development, as well as FPGA (Xilinx VC707).

Additional information

Type devroom

More sessions

2/6/21
Hardware-Aided Trusted Computing
Jo Van Bulck
D.hardware.trusted
<p>A brief introduction to the room and to the sessions.</p>
2/6/21
Hardware-Aided Trusted Computing
Mike Bursell
D.hardware.trusted
<p>If you’re designing a project where security is uppermost, but you want to make it easy to use and compatible with multiple platforms (existing and future), what principles should you follow, and how do they translate into an architecture and actual code. We’ll present the 10 security design principles of the Enarx project, and discuss why they led us to where we are today: a Rust-based open source project with a WebAssembly run-time.</p>
2/6/21
Hardware-Aided Trusted Computing
Dominic Mulligan
D.hardware.trusted
<p>In this presentation we will introduce Veracruz, a project recently adopted by the Confidential Compute Consortium, exploring how efficient, collaborative computations between mutually distrusting parties can be developed using a mixture of hardware- and software strong isolation mechanisms. Veracruz uses Arm TrustZone, Intel SGX, AWS Nitro Enclaves, or the high-assurance seL4 microvisor, to provide a "neutral ground" within which a collaborative computation takes place, shielded from prying ...
2/6/21
Hardware-Aided Trusted Computing
Dmitrii Kuvaiskii
D.hardware.trusted
<p>Graphene is a lightweight library OS, designed to run a single Linux application in an isolated environment. Currently, Graphene runs on Linux and Intel SGX enclaves on Linux platforms. With Intel SGX support, Graphene can secure a critical application in a hardware-encrypted memory region and protect the application from a malicious system stack with minimal porting effort.</p> <p>This talk will discuss the design, implementation, features, lessons learned, and the current status of the ...
2/6/21
Hardware-Aided Trusted Computing
Christoph M. Wintersteiger
D.hardware.trusted
<p>Existing attestation schemes require pre-signed enclave images and provide few means of including runtime-dependent configuration data (like report data, enclave held data, configid). In multi-party settings in which the parties may not always fully trust each other, attestation of multiple pieces of code or data images via these means is cumbersome and inefficient. For example, consider the case of a secure cloud service running a JavaScript interpreter, which interprets a third-party ...
2/6/21
Hardware-Aided Trusted Computing
Jethro G. Beekman
D.hardware.trusted
<p>Enclave technologies such as SGX generally have a relatively high context-switching cost. This is particularly noticeable when doing (network) I/O. In this talk we'll present the first non-LibOS implementation of an asynchronous I/O model for SGX. This gives you a language-native async I/O programming experience in Rust, outperforming any other way to build SGX network services.</p>
2/6/21
Hardware-Aided Trusted Computing
D.hardware.trusted
<p>In this talk, we present an open-source framework to develop heterogeneous, distributed enclaved applications. The main feature of our framework is to provide a high level of abstraction over the platform-specific TEE layer and over the secure communication between different modules, leaving to a developer only the task to write the application’s logic. We provide a notion of event-driven programming to develop distributed enclave applications in Rust and C for heterogeneous TEEs, including ...