*4.4. OpenTitan*

OpenTitan is undoubtedly one of the solutions to secure IoT devices that should attract designers' attention. This open source Hardware Root of Trust implementation [57] is endorsed by leading non-profit, academic or commercial organizations such as lowRISC, ETH Zürich or Google. The project is fully transparent, its sources are available online and can be inspected by the broader community, which should improve its security.

OpenTitan core is currently under development [58] and multiple features are still missing from the early stage top-level [59]. However, the intentions of its creators are well documented and in the complete form it should be a robust solution for various systems' security as an HWRoT module supporting the secure boot procedure and implementing miscellaneous cryptographic primitives.

OpenTitan acts as an immutable HWRoT with secure boot procedure support. It implements multiple cryptographic primitives (AES, RSA, Elliptic Curve CryptographyECC or keyed-Hash Message Authentication Code based on SHA-256 algorithm) that are used to verify the code of subsequent boot stages and authenticate the device during the ownership transfer process. OpenTitan provides FW to control these primitives, so they can be used for securing communication confidentiality and integrity, but it is a responsibility of higher software layers. OpenTitan implements several tamper protection and detection mechanisms as protection codes or scrambling memory regions that contain secrets. Core implements hardware Random Number Generators that are compliant with international standards (e.g., NIST [60,61]).

OpenTitan provides low-level software that is responsible for first stages of the secure boot process (Silicon Creator level—Figure 4). At the beginning, execution is restricted to the ROM region (which cannot be modified after silicon is manufactured) and then ROM\_ext part is loaded from flash (provided that integrity check has passed). At this point, execution is transferred to the entry point of the Silicon Owner code and from now on *it is the Owner who is responsible* for further boot stages security. It is also the end user's software duty to ensure isolation of the applications.

This solution offers the means to securely update its firmware—the integrity of the update block is verified prior to the reboot. The capability to update higher layers of software can be implemented using available cryptographic primitives; however, it is up to the end user.

**Figure 4.** Software stages of the OpenTitan secure boot procedure with respect to particular levels owners, based on [62]. Only low level software layers (ROM, ROM\_ext) are provided with the solution (Silicon Creator level), while the end user (Silicon Owner) is responsible for all higher phases of secure boot as well as the isolation of executed applications when the system is already up.

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

We attempted to analyze the final set of OpenTitan capabilities against requirements presented in Table 1. The OpenTitan documentation does not mention any means for logging of cybersecurity events, neither in hardware nor in software. Possibly, some mechanisms might be implemented by end user in higher layers of software.

As was already mentioned, OpenTitan offers a rich suite of cryptographic primitives. Algorithm agility may still be improved, especially if it comes to lightweight cryptography, but it might be that OpentTitan does not target resource-constrained devices. Robust key derivation mechanisms and managemen<sup>t</sup> schemes are available.

In summary, the fully operational OpenTitan core meets the assumptions of its designers—it is a solid foundation for maintaining the trust and integrity of the system, where it is instantiated. However, it still might not be enough to completely secure IoT devices in terms of recommendations from Table 1. It is not an out-of-the box solution

for all IoT device security aspects and the potential end user has to implement many missing features.

#### *4.5. NXP EdgeLock SE050*

NXP EdgeLock SE050 Plug and Trust Secure Element is presented as a "ready-to-use IoT secure element solution" by the manufacturer [63]. It is an auxiliary security device that connects to host. Optional connections to a sensor mode via another I2C interface and native contactless antenna, granting wireless access are also available (Figure 5). Interestingly, EdgeLock SE050 holds Common Criteria's EAL6+ certificate. It is advertised as suitable for smart cities, smart home, smart industry and smart supply chains. This solution combines a HWRoT with a Java Card OpenPlatform OS (JCOPOS), on which an IoT Applet runs. The Applet supports a wide range of secure functionalities, for example, random number generation, key management, hash operations, Platform Configuration Register (PCR) creation and managemen<sup>t</sup> [64], and is provided by the manufacturer. In hardware, many configurable cryptographic primitives are included, supporting a wide range of algorithms and operations to choose from: HMAC, CMAC, SHA-1, RSA, ECC, AES. Lightweight cryptography is also available. What distinguishes NXP SE050 from other discussed solutions is the fact that it is a separate integrated circuit in its own packaging. This implicates the need for a dedicated space on the circuit board. It is also the only analyzed technology that supports SmartCard.

**Figure 5.** NXP SE050 architecture scheme, based on [63]. The communication between SE050 and Host via I2C bus is presented. The additional interfaces for optional applications, i.e., the antenna and the extra I2C to communicate with Sensor Actuator, are marked. The software/firmware scheme is also present in the form of the IoT Applet, running on Java Card OpenPlatform Operating System (JCOPOS).

#### *Analysis for synthesized requirements for secure IoT devices*

Some capabilities required for a secure IoT device hardware are present, but unfortunately as a plug-and-play approach the SE050 can provide a false sense of security, if used inappropriately. No safety is ensured for the host OS, which could in reality be wrongly configured and utterly unsafe with other interface connections that bypass the secure element—each communication channel should be trustworthy to a degree required in a protected IoT device and each communication channel should have the possibility to be disabled if not needed as per Table 1. No approach to software and firmware updating and provisioning is presented. It is hard to assess the safety of the I2C communication channel and possible problems. Additionally, neither software trusted execution nor enclave creation is possible via the applet. It is uncertain whether the host can freely access and use the cryptographic functionalities (including the random number generator) or if they are only available for SE050 internal access. Remarkably, the data sheet states that only

the Pseudo Random Number Generator is available [63]. Tamper detection is mentioned, but there is no information on tamper resistance. Moreover, no information is provided about the execution privileges in the Java OS nor about what information could be gathered through the secure logging of modules inside the secure element. If only the secure element interfaces are used for off chip communication, then they should be safe. Even though a wide range of secure functionalities is presented in the data sheet, a variety of use cases is discussed on NXP's website, cryptographic hardware primitives, coherent with standards and certifications, are implemented—this cannot be considered as a plug-and-play secure IoT solution. In fact, software must be developed carefully to ensure a proper level of security whilst using the SE050. By and large, the solution seems more like an extensively functional HWRoT with communication between two operating systems rather than an IC offering complex security for IoT.

#### *4.6. Beyond Semiconductor GEON SoC Security Platform*

The GEON SoC Security Platform manufactured by Beyond Semiconductor is presented as a processor agnostic solution with essentials for hardware IP security. An IoT application is advertised, including Industrial [65]. The SoC contains a suite of security modules that work together to create a secure IoT device but can also be used independently. This includes a customizable Hardware Root of Trust including secure boot functionality (GEON Secure Boot) and even recovery to a vendor software state in the case of a security breach [66], firmware encryption module (GEON Firmware Encryption) for the integrity and confidentiality of software, a module that stores and generates secret keys (GEON Hardware Security Module (HSM)) and hardware cryptographic operations module, including random number generation. A wide range of cryptographic algorithms is supported, including lightweight. Code authentication and cryptography-supported measurement functionalities are available. Interestingly, GEON SoC Secure Platform offers GEON Secure JTAG that is claimed to offer a complete debug analysis without compromising security [67]. As presented in Figure 6, the communication channel for the SoC Security Platform is realized by AMBA interface (AHB/APB), which may impact the final design of the IoT design.

**Figure 6.** GEON SoC Security Platform hardware architecture, based on [65]. External interfaces and suggested connections to other components of System on Chip are presented.

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

Multiple cryptographic ciphers and hash functions are available for use. The debug access is described in some documents mentioned in Section 3 as possibly unsafe and it is advised to disable it after deployment. It should be stressed, though, that these guidelines do not consider a highly secured debug interface and that is the case in the GEON SoC. Agreeably, this functionality can be critical in some applications, and the level of security claimed by Beyond Semiconductors is very promising. Parts of the GEON SoC are described as "flexible" and "disposable" depending on the application, which can obviously be beneficial for system designers, but the lack of awareness can lead to the creation of an unsecured IoT. Additionally, some key secure functionalities could be missing if one of the modules is left behind. No information is provided about cybersecurity event logging and monitoring. In terms of secure updating, firmware downgrade protection is in place; the confidentiality and integrity of software and firmware are also protected. GEON SoC Platform Security does not introduce any interference with other interfaces existing in the system in which it is integrated, mainly no disabling or securing capabilities are present. The security threat of any interface in the IoT device is unaccounted for. It can be considered as a plug in to the main bus of SoC. This solution certainly offers a grea<sup>t</sup> variety of hardware-based security features, but the lack of guidance on software and firmware development can be concerning.

#### *4.7. Rambus RT Family*

Rambus has a wide range of security IPs in its portfolio. We decided to focus on the Root of Trust IP cores, especially those dedicated for IoT—RT-100 [68], RT-130 [69], RT-140 [70] and RT-260 [71]. It seems that the difference between the aforementioned modules is the supported cryptography and protocols. The rule of operation is the same. These products are advertised as complete Hardware Root of Trust engines, offering cryptographic accelerators (both symmetric and asymmetric, in RT-140 also lightweight), secure boot support, secure asset storage, secure firmware upgrade, device authentication and identity protection, as well as secure debug. RT-140 supports TLS protocols. Remarkably, the Rambus solution is architecture agnostic. It can be integrated in an SoC and is claimed to be compatible with most popular system buses (e.g., AMBA). In order to cooperate with the device, the CPU requires a dedicated API implementation. Figure 7 illustrates the architecture and the location in the system of the Rambus component. Unfortunately, apart from the manufacturer's materials, there is no literature openly available regarding the RT family. Therefore, our research relies solely on product briefs published on the Rambus website. The analyzed documents indicate that Rambus offers the RoT Secure Boot Toolkit, which may be either a firmware or a software extension to communicate with the instantiated hardware module. It interfaces with protected software stored in non-volatile memory and includes a signing tool and boot library.

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

Since this is purely a RoT solution, the development of secure software and firmware is left completely to the designer. One of the greatest advantages is the wide range of supported cryptography offered. However, there is very little information about securing memory and data transfers. In conclusion, the Rambus proposition is a foundation for building a secure IoT, not a complete solution.

**Figure 7.** Rambus RT hardware architecture, on RT-100 example, based on [68]. Corresponding software elements (e.g., RoT Secure Boot Toolkit), and the location of this component in a system on chip are presented.
