 Hello all and thank you for joining this session. Here I will talk about how security of embedded devices is ensured when open source software meets with open source hardware. The security here is related to the sensitive data that are targets for malicious attacks. Those assets include proprietary software, private and user information, security critical parameters such as cryptographic and digital write management keys. It could be also fused values and any other device configuration parameters. An authorized access to these assets can lead to the exposure of confidential company iterate secrets for device manufacturers or content providers and compromise the privacy of unused users. When it comes to attacks, it can occur at different levels and originate from various sources. It could be at communication or connectivity level. Also, by exploiting the power and performance profiles known as side-channel attacks, it could be also from malicious or vulnerable software or firmware, which are subject to memory corruption attacks, but also from a buggy hardware block. If we take the CPU as an example, this includes exploiting specific architectural features of the CPU, such as the speculative execution, which is known for optimizing the CPU speed. Here I recall two specter and mail-down vulnerabilities. Each category of these attacks encompasses a rich body of literature with numerous documented instances. Now the security assurance of these devices is closely linked to the intricacy of the system's design. Actually, these devices are typically architected using a system-on-chip paradigm, which involves the composition of pre-designed hardware or software blocks referred to as intellectual property or IP. Finally, in terms of security, sensitive assets can be distributed among various IPs across the design. The semiconductor design and fabrication process involves numerous participants, such as IP providers, SoC design house, and foundries. As the industry becomes more globalized, complex supply chain pipeline is created, often involving a myriad of organizations across different geographical locations. Each element of this pipeline is susceptible to various security threats, including malicious design alterations, cloning, subversion, privacy, and much more. Even in situations where a component is designed without malicious intent, aggressive time-to-market demands and the need for a higher optimization may lead to unintentional errors and vulnerabilities. SoC manufacturers also operate in a fabulous model, let's say, and depend on external foundries, which may not entirely be trusted for fabrication services. And these weaknesses can be exploited by adversaries in the field. So to summarize, due to the rapid system lifecycle, which is often less than one year, let's say, for these devices from conception to production, securing the process becomes even more challenging. The security landscape is further complicated in SoC design as a result of the growing reliance on hardware IPs acquired from antracether party vendors. Again, the dependency can lead to significant security gaps, which may only be discovered on the device when it is in use or when it is in field. Okay, now let's move on to the countermeasures. The array of countermeasures for addressing these attacks is equally diverse, encompassing various aspects such as architecture, design, implementation, and validation-based protection. These countermeasures are essential in mitigating the risks just mentioned earlier. To effectively tackle this problem, we classified it into three distant groups, each requiring specific attention and mitigation strategies. First, the hardware security that pertains to security concerns that arise from issues within the fundamental hardware components. Second, the system or platform security, referring to the vulnerabilities that arise from functional or performance bugs within the system, which can be exploited by malicious third parties during execution. And finally, the IT security, which pertains to the susceptibilities that emerge from the interaction of a device, either with another device within a network or with remote servers and data centers. And in this presentation, the emphasis is put on the two first groups. And the IT security group is out of scope. Within this work, the focus lies on harnessing the potential of RISC-V architecture due to its advantages as an open instruction set architecture. In addition, there is plenty of open source hardware implementation available that are suitable for computing devices and SOCs. The modular and flexible design of RISC-V provides a higher degree of customization for building various components from architectural to micro architectural and from accelerators to controllers. Additionally, the openness and transparency of RISC-V, along with its comprehensive security mechanisms, ensure secure implementation of system from the underlying hardware core to the upper layer software stack. And the open nature of RISC-V allows for greater transparency and security by making the code and the design publicly available so anyone can conduct a thorough audit to identify potential vulnerabilities and ensure the system is secure. And this level of openness and accessibility encourage a wider community of developers and security experts to contribute to the improvement and hardening of the system. And this results in a more robust and secure device. Finally, the use of open source hardware and software also helps to build trust among users as they can have greater confidence in the security and the integrity of the system. Now the landscape of devices is rapidly evolving. Actually, these devices are becoming increasingly interconnected and offering a wider array of capabilities beyond their original core functionality. For example, vehicles now integrate assisted driving capabilities and telematic units that enable 5G connectivity while the infotainment systems allow for music streaming while on the road. Another example could be also smart home appliances that have gained voice assistance capabilities, transforming, therefore, our living spaces. However, the inclusion of these expanded features comes with a trade-off. Actually, it entails the development of extensive layers of code leading to a larger trusted computing base that becomes more subject to bugs and vulnerabilities. This in turn puts data at constant risk for being compromised or stolen. And to address this security challenge, focused approach is required. One approach could be involving or involves reducing the TCP by strictly keeping only the security-sensitive code and data within it and eliminating all the other software or the other code, including the feature-rich operating system or the rich OS, such as Linux or Android. So by limiting the code and data presented to TCP to only what is necessary for security purposes, the attack surface is significantly reduced, enhancing, therefore, the overall security posture of the device. So this guarantee is achieved by leveraging hardware support to enforce the physical isolation between the TCP and the rest of the code. This concept is typically known as Trusted Execution Environment, TE, and the TE could be perceived as a tamper-resistant enclave in which software runs on a separate scanner. There exist several ways to establish trusted computing, and depending on the trade-off between the level of security, performance, and cost, we may introduce inside of the platform or the device an external tamper-proof stakeholder designed to protect the system through the use of embedded cryptographic keys. Trusted platform modules, TPM, secure element, SE, and hardware security modules as an example of classes of this specialized cryptographic hardware. Despite the generally provide higher level of protections than the TE, the later delivers high performance, lower cost, and ease of development. And from security perspective, TE provides a higher level of security than a rich OS, and that is actually sufficient for most of the applications. So now let's move on to TE on risk five. A successful way of supporting TE in modern systems is to create separate environments already at the silicon level to pose the basis for the isolation concepts we just introduced. We identified, sorry, that risk five has the building blocks to support TE, and generally speaking for an application profile processor, we need at least three privileges levels, a memory management unit, and physical memory isolation, and that to isolate hardware threat and protect physical other space from memory masters. This would, for example, prevent a CPU core from accessing the memory of a cryptographic hardware accelerator. To be more specific now, the hardware must support at least user mode and a privileged mode. The privileged mode is used to manage the TE, and the user mode is intended for running trusted applications. The risk five specification define five privilege levels, I guess that's four. We have first the machine mode, which is mandatory and has low level access to the machine, making it the highest privileged mode. Then we have the supervisor mode, which supports virtual memory. Then the hypervisor for virtualization support. I'm not sure if this has been removed from the specifications or not. I need to double check. Then we have the user mode, which is the privileged lowest level, and finally, I guess the debug mode available only to the manufacturer. I need to double check about this also. Anyway, the risk five implementation may provide the following combination. We may have a heart with only the M mode, and that's for simple embedded systems. We could have MU for secure embedded systems and MSU for systems, which are running in OS such as Linux or Android. Then the main tool to make TE or risk five is the physical memory protection, which is part of the privileged specifications for isolating memory regions of the execution environment. PMP is controlled by a set of control and state registers to enforce physical memory access to the S mode and U mode and can only be configured by the M mode. The number of PMP varies from hardware implementation to another. For example, the chemo VRT machine has 16 entries, I guess, and each PMP entry is defined by one or more PMP CSRs, depending on the configuration mode. The isolation is done by checking the permissions read write execute at each memory access. In addition to the separation between the rich execution environments and the trusted execution environments running in S mode, the user space and the kernel space for each environment is also required. Each memory space may have the user or U permission. Supervisor mode sets the U flag so that the user cannot access the memory space. And in all cases, the kernel space memory does not have a U flag set. While the machine mode operates exclusively on physical addresses, supervisor and user mode access memory via virtual addresses. As PMP operates on physical addresses, the configuration of virtual addresses can be delegated to the S mode without compromising the security. Then the software running in M mode may use few PMP entries to guard its own memory. In addition to the enclave memory regions, I mean the RE and the TE. Then another functionality is the IOPMP, which stands for input output physical memory protection, which is used to enforce the isolation of the device's memory map at space to control the access issued from the busmasters. We use IOPMP, for example, to enforce the access of a cryptographic engine to a portion of memory accessible only by the TE. So by looking at the RISC-5 software ecosystem, there is a lot of solutions to manage enclaves. And domains. But now we are getting to the heart of the matter, which is the lack of secure OS or trusted OS for RISC-5. And that is our contribution. And that is the main topic also of this presentation. Among the many solutions, an excellent open-source solution has gradually entered the community's field of vision is OPTI, Open Portable Trusted Execution Environment. As of now, OPTI has been one of the core security projects. And after we learned the major OPTI scheme, we decided to port it to RISC-5. This choice is justified by the fact that OPTI follows the global platform specification. It is resilient against software and hardware attacks. It supports various cryptographic and digital signature algorithms. It provides a complete software development kit. And that is convenient for creating and compiling trusted applications and client applications, in addition to the ease of use and the complete documentation. As you may know, porting of an operating system to a target architecture is a time-consuming process, as it involves a deep understanding of the OS internals and a change to significant and complex OS components. Like the memory management involving writing a NEMI Mew driver, cache management, for the process management that involves writing the drop handlers, context switching, system calls, synchronizers, the scheduler, etc. For the IO that involves writing the console drivers, etc. Also, OPTI has been initially written for ARM. It provides an abstraction layer to port the OS to a new ARM-based platform, but not to a new architecture. And here I would like to express my gratitude to the guys from Linaroo for their good support and help on abstracting many components to ease the port to the RISC-5 architecture. When it comes to the architecture, the ecosystem consists in several execution environments, or let's call it domains from now, depending on the number of PMP entries. We consider mainly two execution domains, a non-secure domain and a secure or trusted domain. The non-secure domain runs feature-rich OS such as Linux and its client application. The client application component interface to access the trusted application primitives from non-secure domain. The trusted domain runs OPTI OS and its trusted applications. Then OpenSBI running in M-mode handles the security-related tasks, including domain management and resource assignments. OPTI OS runs in S-mode, trusted applications run in U-mode, and OPTI has said to follow the global platform API specifications both on the client side, complying with the T-client API, and inside the T-compliant with the T-internal core API. OPTI OS then uses the virtual addressing mechanism MMU to isolate the TAs. In the initial work, we tend to run OPTI OS and Linux OS in the same heart and perform context switching between them through a security monitor. But then we have abandoned the idea, due to many reasons, related to security, like increasing the privilege level each time we context switch between the two OSes, performance drop to the context switch on itself, the difficulty to assert interrupts if they are secure or not secure, and who should handle them, and many other reasons. In this work, we follow an asymmetric multi-processing scheme, IMP. We perceive a CPU core as a resource, and we assign it to a specific domain, meaning OPTI OS and Linux have their own CPU cores each. That's motivated also by the fact that SOC designs often include multiple CPU cores that could be homogeneous, or eatery juniors, or multi-core architectures. A CPU core may be different architecture, meaning it could be optimal for specific use cases, like cryptographic hardware accelerator. The CPU cores could have independent software contexts, meaning each with its own operating system, memory regions, and hardware resources. Let's take some examples. So I will not enumerate all of them. For example, the Kimu RISC-5 virtual machine has up to 8 generic RISC-5 cores with optional extensions. We could, for example, assign two to the OPTI OS and the remaining ones to the Linux. The Core-5 SOC may contain four CVA-6 application cores and one or more embedded cores. Now, assume that we have an SOC with four cores. We assign two cores to the secure domain, such will be owned by OPTI OS, and two of the remaining cores to the Linux OS, that will be owned by Linux. So in that case, a cross-domain communication mechanism is needed, such as the Linux OS can request operations from the OPTI OS. So the problem here is more a platform implementation issue rather than fundamental limitation of the RISC-5 architecture. So there is many solutions that can help solving this issue. In our case, so to perform under domain communications, we rely on our PMG in top of Virtiu. Actually, a Kimu RISC-5 generic virtual platform supports up to 8 Virtiu MMIO transport devices. And for the physical layer, we are using the NXP's proprietary mailbox implementation. With enter cores and interrupts, this would let OPTI to know that there is a request coming from Linux to be handled. And this allow also OPTI to perform remote procedure calls in the Linux site. With regards to the boot architecture, the global platform DE system architecture depicts three simplified secure boot sequences of a DE. We have trusted OS early boot, then ROM-based trusted OS and the trusted OS on-demand boot. So in this work, we opt for trusted OS early boot scheme. We use Uboot as a bootloader. We create a fit image containing OpenSBI, OPTI and Uboot proper. On system reset, the boot ROM code launches Uboot SPL in M mode. SPL loads OpenSBI, OPTI and Uboot proper to memory. Then it launches OpenSBI in M mode. OpenSBI then launches OPTI in S mode in top of the cores assigned to the trusted domain. Then OpenSBI launches Uboot proper in top of the remaining cores, which loads the Linux kernel and the DTB and gives control to the kernel to boot. So this boot architecture allows easily performing secure boot flow process in which every stage is allowed to be executed only if its signature verification passes. Now moving to the development and experimental setup, the development until now is done for Kimu risk-fibred machine as target platform with four LV64 general purpose cores. We use a risk-5 GNU compiler toolchain version 7.5.0. For the demo, I will show it is based on the upstream OPTI version 3.21.0. OpenSBI version 1.2, Linux kernel 5.19, sorry, build root 2022.11, release candidate 2, and the Kimu version 7.2. We also run the port in top of core 5 SoC with four CVA6 cores. And finally to verify the correct port of OPTI OS and its related APIs, we invoke Xtest, which is a suite of regression tests provided by OPTI. And as we can see from the recording Xtest passes, which is a good news. Now to conclude with the current status, OPTI OS port is almost done. We are at 90% of work complete. We need to upstream Linux OPTI driver, which adds support for RPMG as a conduit method, work on the documentation and the continuous integration, and then anyone can add support for his platform. I think that's all what I wanted to show you today. Thank you again for joining and feel free to contact me for any additional information. And that's all. Thank you. Bye.