**Table 1.** Synthesized requirements for secure IoT devices.


#### *Electronics* **2021**, *10*, 1814


#### *Electronics* **2021**, *10*, 1814



#### *Electronics* **2021**, *10*, 1814

#### **4. Review of Existing Solutions**

In this section, we analyze some of the current popular trusted computing solutions used for IoT devices against the recommendations presented in Section 3. The solutions chosen are either already mature and currently in use for IoT devices or are emerging concepts that might bring new quality to the topic. The selection of technologies for IoT security includes examples that are more hardware-based (e.g., GEON SoC Platform) and more software-focused, such as Intel Software Guard Extensions (SGX). We chose the most popular solutions available on the market, such as Arm's TrustZone or Intel SGX, the most promising open source ones, such as Keystone and OpenTitan and other representative, usually hardware-based, solutions. In the last group, we targeted solutions that can be integrated into a designed SoC in the form of a standalone IP–Rambus RT, similar but more complex solutions, such as Geon SoC Security Platform, and finally, a solution offered as an integrated circuit (NXP EdgeLock SE050). A short description is provided for each one before the analysis of the IoT security in the context of Table 1. We present our findings for each solution in Table 2. The descriptions are formed from the perspective of a designer who wants to understand the requirements for a secure IoT device. We assumed that the analysis is based only on publicly accessible information, no lab testing nor feasible attacks on devices based on the solutions were performed, and that little to no implementation experience for each of the discussed solutions is required.

#### *4.1. Arm TrustZone*

TrustZone is a security extension offered by Arm for application processors (Cortex-A family) and microcontrollers (Cortex-M family), which has become popular recently. There is a growing interest in the subject across academia, and a number of commercial products utilize TrustZone's capabilities, for example, Samsung Knox. Arm's solution is based on a Trusted Execution Environment (TEE) concept and enables the system to fulfill Platform Security Requirements [39]—a set of guidelines defined by Arm. This document provides similar guidelines to those gathered in Section 3, with a strong focus on hardware and firmware security. There are some differences between architecturespecific implementations of TrustZone, but the main idea remains the same—on Cortex-A processors, the secure monitor, a privileged software, implements mechanisms for secure context switching between worlds; on Cortex-M processors, there is no secure monitor and hence the change between the secure and non-secure world is handled by a set of core logic mechanisms. Enabling TrustZone for microcontrollers has allowed for more widespread usage in resource-constrained devices, which has an impact on IoT devices. Pinto and Santos [40] provided a detailed explanation of TrustZone's operation with a distinction between Cortex-A and Cortex-M implementation. The general concept of TrustZone's operation on software and firmware levels is presented in Figure 1.

**Figure 1.** Concept of a TrustZone supported execution environment on software and firmware levels, based on [41]. The division between non-secure and secure worlds, as well as their construction with accentuated levels of operation, are presented. The SCR\_EL3.NS is a register bit used to switch between the trusted and not trusted environments. The Secure Monitor, a special processor mode controlling the transition between secure and non-secure states, is presented as a common base for the environments.

TrustZone provides two virtual processors supported by hardware-based access control, resulting in division into secure and non-secure environments. Both execution environments are completely separated in the hardware, thanks to memory isolation and a special processor mode dedicated to monitoring (*secure monitor*). A few additional modules, such as the TrustZone Address Space Controller (TZASC), the TrustZone Memory Adapter (TZMA) and internal interface modifications, are introduced for separation and memory partitioning in TrustZone for Cortex-A. Noticeably, Arm states that the use of TZASC and TZMA is optional in the system. The final decision is left to the designer. Peripherals are flagged as *secure* or *normal*, while the APB-AXI bridge hardware is responsible for access control and rejecting AXI transactions with insufficient permissions. There is no separated trusted path since secure and non-secure transactions are multiplexed on the system bus using the same hardware. Significantly, in TrustZone there are no explicit considerations for Hardware Root of Trust implementation. However, the implementation of Root of Trust has been proposed in the literature by Zhao et al. [42], and a commercial solution, discussed later in this subsection, has also been made available. Some security features are provided by separate hardware modules. For example, remote attestation is achieved by an incorporated hardware component, such as a Trusted Platform Module, responsible for measuring the kernel's integrity and creating unique cryptographic keys. While there is no information on random number generation in TrustZone documents, Arm offers a separate security IP called the True Random Number Generator, advertised as TrustZone compatible. Similarly, secure storage can be implemented by simply denying access to a device from a non-secure world.

From a firmware and software perspective, a privileged instruction called the Secure Monitor Call (SMC) allows for entry to, exit from and general communication between secure and non-secure world applications. This mechanism involves a monitor software with higher privileges than the Rich Execution Environment Operating System (REE OS). Its responsibility is the reliable and protected context switching of the processor [40]. A Non-Secure (NS) bit stored in the Secure Configuration Register (SCR) represents the current context of the processor and the register's state is propagated throughout the entire SoC. Hence, it is possible to use peripheral devices that only allow secure access from the processor. In TrustZone there is no attestation of processes requesting execution in the secure world. In the event of an OS falling into the hands of an adversary, messages that require secure world resources can be crafted and possibly other information may be gleaned from apparently secured processes. A newer TrustZone technology for Cortex-M microcontrollers has some changes to allow for usage in more resource-constrained devices. The division between secure and non-secure worlds is based on memory map partition, and context switching happens due to code exceptions. To support this, a couple of new, dedicated instructions were added.

One could assume that TrustZone alone leaves quite some room for interpretation in terms of security functions implemented in hardware. That being said, Arm proposed the CryptoCell IP-family [43,44], which acts as HWRoT, offering cryptographic acceleration, true random number generator, trusted storage, secure boot support and authenticated debug support, to name a few. CryptoCell-300 is dedicated for Cortex-M implementations, while CryptoCell-700 is Cortex-A oriented [45]. Both families provide broad support for symmetric and asymmetric cryptography, as well as lightweight cryptography [46]. Code integrity and signing, authentication and key managemen<sup>t</sup> are also mentioned in the documents. Arm claims that this solution is meant for low power, low area designs [43,44]. It may seem that TrustZone, complemented by CryptoCell IP, is a powerful security solution, mostly implemented in hardware.

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

Some security flaws inherent to the REE-TEE communication channel have been found in previous years (Black Hat 2014, Black Hat 2015) [40] and have been used in attacks on real devices. Additionally, concerns with cache side-channel attacks arise. The lack of inherent memory encryption also raises questions. TrustZone in itself does not have any recommendations nor requirements for HWRoT implementation other than the need for the existence of a unique device key [40]. This is paramount for the security of an IoT device and cannot be left to wide interpretation. One could assume that Arm's recommendation is to use IP from the CryptoCell-family, though it is not always feasible. On the software execution front, the secure-world approach is not the same as an enclave and allows for a compromised TEE program to interfere with other programs within the TEE. Secure IoT required functionality, as presented in Section 3, is possible in TrustZone, but with much of the implementation left to the designers—secure deployment might be at risk. TrustZone documentation does not provide input on configuration, update or logging mechanisms. We assume it is at the designer's discretion. Finally, TrustZone is entwined with Arm's technology; it is not a universal solution and porting it to different platforms does not seem feasible. On one hand, this can be limiting for some implementations, as not all IoT devices use Arm's solutions. On the other hand, it would be surprising if one of the leaders in the processor market did not have a compatible security solution available.

We can conclude that TrustZone certainly offers an end-to-end security solution, but it requires a good understanding of the framework, some creativity in implementation and support from external IPs. It is worth repeating that this solution is dedicated for Arm infrastructure. The vast number of TrustZone supporting products speaks for itself. TrustZone fulfills most of the security recommendations, but it would not be possible without supplementary hardware, like CryptoCell or applications. TrustZone alone is not an off-the-shelf, ready-to-use solution.

#### *4.2. Intel Software Guard Extensions (SGX) and Security Essentials*

Intel SGX [47] is a set of CPU instructions that allow the creation of isolated software containers called enclaves in which code, data and stack of a program are isolated safely from other processes (even with higher privilege levels) through hardware-based access policy control and memory encryption. Unsurprisingly, this solution is meant for Intel architecture. Application code and the hardware it is running on can be attested by a remote entity [48] by verifying measurements of its code and data (named MRENCLAVE), calculated during enclave creation. This process provides increased confidence that the code is running in an enclave and is unmodified by a third party. It provides a mechanism to run a secure code in an unsecured OS, with support from trusted hardware. After successful attestation, an encrypted channel (based on public key schemes) between the remote party and the enclave can be established in order to exchange sensitive data. Data can be sealed using CPU instructions to generate a key (named MRSIGNER) which allows decryption only by the same enclave created in the future.

Additionally, in the Intel security ecosystem, a provisioning functionality is present, which allows trusted entities to update or add software whilst assuring integrity. It is presented in Figure 2. The provisioning process is described below:


From a hardware viewpoint, Processor Reserved Memory (PRM) is isolated by SGX and protected against all memory accesses from outside an enclave, including kernel, hypervisor and system managemen<sup>t</sup> mode, as well as DMA accesses requested by peripherals. Enclave's code and data are stored in Enclave Page Cache (EPC), providing pages of a 4KB size [49]. The untrusted OS is in charge of assigning EPC pages to enclaves, which creates a potential exposure. The processor is responsible for assuring that each enclave has only one EPC on hand; it is monitored in Enclave Page Cache Metadata (EPCM).

**Figure 2.** Intel SGX Software Lifecycle; steps are executed in the numerical order, sensitive data are remotely provisioned (3) into the enclave after mutual attestation (2) of the off-platform provider and created enclave (1), after the enclave is destroyed data are sealed in memory (4) in such a way that only an identical enclave can access them again. Software updates (5) are also possible via this scheme and a new seal is created (6) so that an old version of software cannot overwrite the new version. Based on [47].

SGX in itself is generally a TEE implementation, but other Intel modules and technologies allow for wider SoC security such as secure boot capabilities, TPM integration or random number generators [50]. It is advertised that the security extension assists with securing IoT edge device communication [51].

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

Intel SGX is a proprietary enterprise solution; therefore all security functionalities are tied in with Intel architecture. This means that other custom application accelerators, interfaces and system bus control are out of the scope for the solution. As such, all SoC security issues have to be solved by custom design decisions, increasing the risk of creating an unsecured device. Costan and Devadas [49] in 2016, one year after the Intel SGX debut, published an in-depth examination of this solution. They exposed a number of potential vulnerabilities to SGX and claimed that "our security analysis reveals that the limitations in SGX's guarantees mean that a security conscious software developer cannot in good conscience rely on SGX for secure remote computation" ([49], [p. 3]). In the five years that have passed since this article was published, a number of new side channel attacks have been discovered [52–55], and although Intel describes these attacks as very difficult to perform in a data center (i.e., physical access to the platform is required), this changes in an IoT context (device present in a public space) and remains alarming. Due to a security by obscurity situation, it is hard to assess the solutions for many requirements in Table 2 and thus no assurance on their completeness can be given, though an optimistic approach is taken. Interestingly, it is possible to change all device cryptographic keys by changing a single register called OwnerEpoch. This process allows for the fast sealing of the device and serves as additional protection of the enclave content. If the OwnerEpoch value is lost, the device is rendered inaccessible.

SGX and the Security Essentials provide multiple good trusted computing basics but is not a solution entirely catered for protection of IoT devices. This can be seen in the Cat. 6 and Cat. 8 sections of Table 2. However, the security level it provides and the critique around it, raises questions about whether it is a good choice at all.
