Hardware-Aided Trusted Computing
TEEP (Trusted Execution Environment Provisioning) Implementation on RISC-V
Introduction of TEEP and implementation on RISC-V
IETF is discussing Trusted Execution Environment Provisioning (TEEP) protocol to manage remote installation/update/deletion of a TA (Trusted Application) in TEE (Trusted Execution Environment) which provides hardware isolated environment in the CPU. TEEP is designed to be general among different CPU architectures. We have implementation of TEEP on the new RISC-V cpu. Our implementation is designed to be portable to another TEE architecture. The requirement for portability is discussed at the event.
IETF is discussing Trusted Execution Environment Provisioning (TEEP) protocol to manage remote installation/update/deletion of a TA (Trusted Application) in TEE (Trusted Execution Environment) which provides hardware isolated environment in the CPU. TEEP is designed to be general among different CPU architectures, but primary implementations are proceeding on Intel SGX and ARM TrustZone. Therefore, we have implemented of TEEP on Keystone which is a TEE project on RISC-V led by UC Berkeley.
TEEP consists of 3 major software components; “TEEP Broker” on the normal OS, “TEEP Agent” in the TEE, and “Trusted Application Manager (TAM)” on a remote server. These components manage certificates for authenticating TEE and TAM, and code signing of TA. All of the certificates are based on PKI key management. The challenges of having TEEP functionality on RISC-V is how to minimize the complexity of required features of TEEP inside TEE while keeping the portability of existing TA. The TEE is not meant to have full scale of POSIX API development environment which are convenient for developer but not ideal for minimizing security who would like to focus on code size.
Some of the features we have added to Keystone runtime are HTTP/HTTPS and Concise Binary Object Representation (CBOR) parser.
Our initial implementation of TEEP was implemented on Arm TrustZone with OP-TEE and then moved to Keystone on RISC-V. The presentation will also include instruction of basic concept and design of TEEP.
Additional information
| Type | devroom |
|---|
More sessions
| 2/6/21 |
A brief introduction to the room and to the sessions.
|
| 2/6/21 |
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.
|
| 2/6/21 |
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 or ...
|
| 2/6/21 |
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. This talk will discuss the design, implementation, features, lessons learned, and the current status of the project. The ...
|
| 2/6/21 |
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 script, ...
|
| 2/6/21 |
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.
|
| 2/6/21 |
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 ...
|
