Center for R&D on Secure Computer Systems

Hardware (HW)

The requirements for protection models supported by UTA can be summarized in two points:

1. High flexibility, enabling the construction of any protection domain.
2. Resistance to side-channel attacks on data flowing between chips, including I/O devices and memory, provided at sufficiently low cost.

The TEE hardware must provide system software with TEE primitives (Figure 1) that satisfy these two requirements. These primitives can be divided into three components: (i) a memory protection mechanism forming the basis of the TEE, (ii) authenticated memory encryption to prevent eavesdropping and tampering on memory chips, and (iii) secure I/O channels that enable secure I/O with low overhead. The effectiveness of these technologies, each developed through dedicated research, will be demonstrated by implementing a multicore SoC hardware compliant with the RISC-V architecture. Verification will first be carried out in an FPGA environment, followed by the construction of a prototype chip–based environment.

System Software (OS)

Since the threat models required by TEE users vary, we aim to realize a Software-Defined TEE, where the functions provided by the TEE can be flexibly implemented in software. To this end, we will develop system software that enables flexible TEE configurations through hardware/software co-design with the TEE hardware. Specifically, we will achieve the following three objectives:

1. Provision of a hardware emulation environment
   Since availability of the UTA hardware will be later, we are extending the open-source emulator QEMU to emulate the UTA hardware under development in software. The extended QEMU will be released as open source, promoting software development on new TEE hardware.
2. Provision of a compatible environment with existing TEEs
   Using the UTA hardware, widely used practical TEE interfaces such as Intel SGX and Arm TrustZone will be realized as software modules. By releasing these modules as open source, we aim to attract existing TEE users.
3. Provision of innovative protection domain configurations
   We will introduce new protection domain configurations that address threat models not supported by existing TEEs due to hardware limitations. Especially, nested protection domains are difficult to implement in conventional TEEs. By including such models, we will demonstrate that configurations unsupported by current TEEs can be realized on UTA. Diverse protection domains will first be constructed in the QEMU environment, and some of them will be targeted for implementation on FPGA boards and prototype chip environments.

Theory (Th)

UTA aims to protect a user’s assets within application pro-grams against anticipated threats. Achieving such protection requires the system software to construct an appropriate protection model using the TEE primitives provided by the hardware. Consequently, to ensure that assets are safe-guarded as intended, every layer of UTA—the hardware, system software, and user application—must be correct.
We plan to achieve this goal through formal verification. However, verifying the entire architecture monolithically is infeasible due to its complexity. Furthermore, we cannot assume a fixed application program because it varies with each use case. To address these challenges, we seek to de-compose the overall verification task of UTA into verifica-tion problems of individual components. Specifically, we will investigate two forms of modular verification with security in mind:

1. Inter-layer verification
   The correctness of a higher layer depends on the correctness of the functionalities provided by the lower layer. For in-stance, the correctness of an application program depends on that of the system software, which in turn depends on that of the hardware. To enable layer-by-layer verification, we introduce a specification interface for each layer and verify that each layer satisfies its specification under the interface provided by the lower layer. This inter-layer modularity also reduces the verification cost of modifying application programs because we only re-verify the changed applica-tions and the verification of the other layers can remain unchanged. Because the interfaces of different layers are often described in different specification languages, we will study methods to bridge the gap between them.
2. Intra-layer verification
   Each layer may itself comprise multiple modules. For example, system software typically consists of many C source files. To scale verification, we also aim to pursue modular verification within individual layers. For system software, this requires modular verification of low-level programs that use complex features such as memory and resource management, interrupt handling, and concurrency. For hardware, it is worth exploring modular verification techniques applicable to hardware description languages such as Verilog.

Attestation (ATT)

IETF RFC 9334 (Remote ATtestation Procedures Architecture (RATS)) defines remote attestation as a process in which one peer (the "Attester") produces believable information about itself ("Evidence") to enable a remote peer (the "Relying Party") to decide whether to consider that Attester a trustworthy peer. This procedure is facilitated by an additional vital party (the "Verifier").
Remote attestation faces several technical challenges:

1. Suitability for use cases
   IETF RATS does not prescribe the specific contents of the evidence. This is because the evidence depends on the use case, such as VMs or microservices. Moreover, RATS does not specify performance requirements for the Verifier when handling large numbers of microservices.
2. Scalability and lightweight operation
   As TEEs become more widely adopted, the demand for remote attestation will grow, raising concerns about increased load on Verifiers. Since Verifiers hold sensitive information, their capacity cannot be simply expanded with proxies. Therefore, lightweight signature schemes suited to device capabilities, as well as clear definitions of the necessary verification items depending on use cases, are required.
3. Privacy protection
   As noted above, evidence is transmitted to the Verifier. However, such evidence may reveal device configurations or even allow identification of the user, raising privacy concerns. While DAA (Direct Anonymous Attestation) already provides an anonymization mechanism, it focuses mainly on device authenticity and does not thoroughly address other verification items, such as binary hashes or configuration information.

In this project, we will investigate the use cases and practices of remote attestation from the perspectives of suitability for purpose, scalability and lightweight operation, and privacy protection. Based on this investigation, we will develop guidelines, publish them, and work toward establishing them as standard guidelines.
Furthermore, drawing on the above study, we will develop remote attestation software for the proposed UTA, and evaluate its functionality and performance. The developed software will be released as open source, with careful consideration for secure management.

Middleware (MW)

Data involving privacy and other sensitive information that must be protected is now distributed across all types of platforms, including the cloud, PCs, IoT devices, and embedded systems. To achieve end-to-end data protection, it is essential to realize TEEs on these platforms. In cloud environments, Confidential Computing, which leverages TEEs, has been attracting significant attention. Confidential Computing is an execution model that protects both data and its processing by using hardware-based, attestable Trusted Execution Environments (TEEs). Ideally, Confidential Computing environments should be realized across all platforms.
To this end, we are developing the Portable Confidential Computing Environment (PCCE), an execution environment that enables easy use of Confidential Computing across diverse TEE hardware, including UTA.
As shown in Figure 2, PCCE adopts WebAssembly (Wasm) as its foundation. Wasm is a fast and secure binary virtual instruction set, for which multiple runtimes (Wasm virtual machines) are available across heterogeneous hardware platforms. By leveraging Wasm virtual machines, PCCE eliminates hardware and OS dependencies while also providing execution environment isolation through Wasm sandboxing.
PCCE provides mechanisms to mutually verify trust relationships (dotted arrows in Figure 2) among (i) the Wasm Virtual Machine deployed inside the TEE hardware, (ii) Wasm applications (Wasm binaries) running on the Wasm virtual machine, and (iii) applications (Local and Remote applications) that make use of them. Software developed on PCCE will run not only on the UTA but also on existing TEEs. In PCCE, we further define two Interface Definition Languages (IDLs), both implemented with the Clang compiler: one for constructing native execution libraries used by Wasm applications, and another for abstracting the different TEE application APIs that vary across TEE architectures.

Proof of Concept (PoC)

We propose Mobile Trunk, an encrypted file format that encapsulates both encrypted data and the Wasm code (as shown in Figure 3) required for its decryption and processing. The sender converts confidential data into a Mobile Trunk. The Mobile Trunk file itself is encrypted and can only be decrypted with a key stored either in the TEE runtime within the PCC or in secure storage on the conventional OS side. Moreover, the Wasm code for decrypting the encrypted data is restricted to run only in execution environments that satisfy the trust level specified by the creator (described later). Consequently, the Mobile Trunk can be safely delivered to recipients even through channels that are not inherently secure, such as e-mail.

The concept is demonstrated by presenting several use cases as follows. The first use case shown in Figure 3 is includes data expiration checking and authentication request processing. The code first verifies the trusted current time provided by TEE and the validity of the document’s expiration, and then send the authentication code via SMS for further processing. Figures 5 through 7 present examples in which the execution environment is verified prior to deciding whether to decrypt the data. In Figure 5, this Mobile Trunk allows execution only when it is running in a TEE environment within a Secure VM on the cloud. Figures 6 and 7 illustrate an example in which Mobile Trunk verifies whether the PC used for execution is workplace hardware and enforces execution control accordingly.