*4.3. Keystone*

Keystone [56] is an open-source framework designed for creating TEE environments based on unmodified RISC-V architecture. RISC-V Physical Memory Protection (PMP), arbitrarily securing the physical memory locations, and the programmable machine mode (M-Mode) are used to implement the memory protection scheme. The trusted Security Monitor (SM) program is proposed on M-Mode level and its main task is to manage the secure handling of hardware and context switching between enclaves (Figure 3). It should be executed entirely from on-chip memory. This component satisfies typical TEE requirements such as memory isolation and code/configuration attestation. Keystone does not propose direct resource management. This responsibility lays on the secure enclave application developer side. A runtime (RT) component is an enclave-specific platform for secure applications to be executed on, which also communicates with the SM and manages virtual memory chunks assigned to the enclave. The RT should have the functionality of system plugins, interfaces, *libc* implementations, paging and virtual memory management. It can be successfully reused between enclaves or modified as needed. Additionally, because the rich OS is not a part of a typical enclave, the Trusted Computing Base (TCB) is smaller.

From a hardware perspective, implementing Keystone does not require modifications to CPU cores or memory controllers. However, several requirements for the platform are listed in the publication [56]: trusted boot process support, unique authentication key dedicated for this process and a hardware source of randomness. According to the Keystone designers, the Root of Trust can be realized in hardware, but does not have to, which allows for a variety of implementations, for example tamper resistant software (zeroth-order bootloader) [56].

**Figure 3.** Overview of a Keystone system setup, based on [56]. The distinction between untrusted and trusted execution environments is presented, along with support for multiple secure enclaves and their runtimes. The privilege level for each RISC-V mode is marked. The security Monitor, operating on M-mode, being common for both execution environments, is the manager of context switching. Required trusted hardware is included.

With every CPU reset the Root of Trust executes these steps:


In the RISC-V architecture, only the machine mode has access to hardware resources such as interrupts, system memory, peripherals and devices. The S-mode (supervisor) is used for the OS kernel and the U-mode (user mode) allows execution of typical REE applications. The machine mode is used as a platform for the SM, because:


PMP restricts the physical access to memory locations for the S and U modes. Every record in the PMP table has a set of access flags for the programmed memory segment. Each PMP address register encodes a continuous address region and the configuration bits represent write/read/execute (rwx) permissions for the U/S modes. If a mode attempts to access an unassigned memory area, the access is rejected by the hardware. The PMP areas can be dynamically allocated during device operation. During SM image loading, the first PMP area is configured as the highest priority in order to protect its own resources, such as code/stack/data. By default, the OS has access to any memory location that is not part of an assigned PMP area of higher priority. When an application starts an enclave, the OS finds a continuous area of memory, which does not overlap with any other PMP configured area, and then switches the request to the SM that creates a new PMP record. During a context switch from an enclave to the OS or another enclave, the SM takes away all access permissions, but the enclave's address region is preserved. As a result, an enclave is securely isolated from other processes. Upon creation, the enclave's memory is measured and cryptographically signed. The OS uses an interface within the Linux kernel (/dev/Keystone) for enclave creation.

#### *Analysis for Synthesized Requirements for Secure IoT Devices*

The paper that introduces Keystone focuses more on the enclave code execution, while treating key management, software updates, device authentication and other problems such as orthogonal. A Root of Trust (either hardware or software) is stated as a necessity along with a trusted boot process, but it is in the hands of the application designer to make sure that secure IoT requirements are in place. Process and application privilege levels are inherent to the RISC-V implementation. Enclave security is supposed to include resistance to side-channel attacks, mapping attacks and syscall tampering attacks. Keystone's authors state that their solution is an improvement on SGX [56], and the measures they took to mitigating the risks that were exposed in Intel's solution seem to confirm that. However, Keystone, being based on a similar concept to SGX, can still demonstrate similar vulnerabilities that may ye<sup>t</sup> to be discovered.

Using concepts presented in Keystone, or even the entire solution, seems like a good starting point, but it is hardly enough in itself to state that a device is secure in the IoT field. It certainly offers some degree of flexibility. Keystone being an open-source solution can also be an advantage. However, as presented in Table 2, there are many important categories that are left completely at the system designer's discretion and it can result in unintentional exposures of the IoT device.
