Design Methodology and Metrics for Robust and Highly Qualified Security Modules in Trusted Environments

Abstract

Cyberattacks and cybercriminal activities constitute one of the biggest threats in the modern digital era, and the frequency, efficiency, and severity of attacks have grown over the years. Designers and producers of digital systems try to counteract such issues by exploiting increasingly robust and advanced security mechanisms to provide secure execution environments aimed at preventing cyberattacks or, in the worst case, at containing intrusions by isolation. One of the most significative examples comes from General Purpose Processor (GPP) manufacturers such as Intel, AMD, and ARM, which in the last years adopted the integration of dedicated resources to provide Trusted Execution Environments (TEEs) or secure zones. TEEs are built layer by layer on top of an implicitly trusted component, the Root-of-Trust (RoT). Since each security chain is only as strong as its weakest link, each element involved in the construction of a TEE starting from the RoT must be bulletproof as much as possible. In this work, we revise and propose a design methodology to implement in both hardware (HW) and software (SW) highly featured and robust security blocks by highlighting the key points that designers should take care of, and the key metrics that should be used to evaluate the security level of the developed modules. We also include an analysis of the state of the art concerning RoT-based TEEs, and we illustrate a case study that documents the implementation of a cryptographic coprocessor for the secure subsystem of the Rhea GPP from the European Processor Initiative (EPI) project, according to the presented methodology. This work can be used by HW/SW security module designers as a cutting-edge guideline.

1. Introduction

In the modern age, due to the pervasive adoption of technology in even more contexts and aspects of human life, digital systems are becoming more complex and sophisticated day by day, aiming at ensuring more advanced and efficient services. On the one side, this trend is bringing unprecedented benefits; on the other hand, the increasing amount of processed and exchanged data, interconnections, and infrastructures is extending the attack surfaces for cyberattacks. Indeed, hand in hand with the evolution of technology, in the last decades the attacks aimed at violating the security of data have become more elaborate, more frequent, and their consequences more severe [1,2,3]. The main approach to counteract this phenomenon relies on equipping digital systems with dedicated and adequate security mechanisms to prevent attacks by reducing the vulnerabilities and to contain them or limit their effects with tempest reactions. In this sense, the state of the art promoted by the main General Purpose Processor (GPP) manufacturers lies in the creation of Trusted Execution Environments (TEEs). A TEE is a secure and isolated area within a processor or microcontroller that provides a high level of security for running specific applications and processing sensitive data. TEEs are designed to protect against various forms of attacks, including software-based attacks, hardware attacks, and even attacks from the operating system or other running applications. Indeed, they provide a safe and isolated environment where code and data can be executed and processed securely. TEEs are often built on top of a Root-of-Trust, i.e., a foundational component or process that is inherently trusted to perform critical security functions [4,5,6]. This can include tasks like hardware-based secure boot, key management, and attestation. TEEs typically leverage the hardware-based security features provided by the RoT to establish and maintain their security. For example, some TEEs, like ARM TrustZone or Intel Software Guard Extensions (SGX), rely on a hardware-based RoT to establish a secure boot process and to ensure the integrity and confidentiality of the TEE’s operation. The construction of a TEE starting from an RoT consists of several steps. It involves several elements, each of which must be carefully designed to not introduce security vulnerabilities that might compromise the overall security of the TEE. This is because TEEs built on top of RoT are essentially security chains that are only as strong as their weakest link. Indeed, several examples of security flaws in TEEs of GPP producers can be found in the literature. For instance, in the case of the ARM TrustZone, cache SCAs have been exploited in [7,8,9,10], EMA attacks in [11,12], and fault attacks in [13].

In this work, we present a comprehensive design methodology and the security design metrics for the elements (both hardware and software) that are involved in RoT-based TEEs. The application focus is on embedded security: we aim to provide the hardware–software infrastructure that can be used by system developers to enforce the security of their embedded systems. We aim to exploit the lesson learned from the EPI project (see [14,15,16,17,18,19,20,21,22,23] as references to the implementations of the specific HW accelerators) to make available to the security community the methodology and strategy to design such an advanced system. The presented methodology builds on the experience acquired during the design of a cryptographic coprocessor to assist the secure boot process in the Rhea GPP, which represents the first family of processors born from the European Processor Initiative (EPI). Our goal is to extract the lessons learned from the design activity and develop a generic methodology that can be proposed to the security community. The EPI project is a collaborative effort between various stakeholders, including research institutions, universities, and industry partners, to drive innovation in processor technologies, and it is aimed at developing and promoting European-designed and European-manufactured High-Performance Computing (HPC) processors and accelerators. It represents a strategic effort that seeks to reduce Europe’s reliance on non-European technologies in the field of supercomputing and data processing by ensuring that Europe has access to cutting-edge processor technologies including state-of-the-art security mechanisms.

The remainder of this work is organized as follows: Section 2 provides the main definitions, principles, and outline of Roots-of-Trust and Trusted Environments, by highlighting the mechanisms that involve each other. Section 3 gives a review of the state of the art concerning RoT-based TEEs from the main GPP manufacturers such as Intel, AMD, and ARM. Section 4 presents the proposed methodology and the most qualifying security metrics that should be carefully addressed when designing any of the elements involved in the construction of a Trusted Environment on top a Root-of-Trust. In Section 5, we present a case study concerning the development of a cryptographic coprocessor that has been included in the Security Subsystem of Rhea GPP, according to the proposed methodology and metrics. Finally, Section 6 summarizes the conclusions of this work.

2. Definitions, Principles, and Outline of Roots-of-Trust and Trusted Environments

A Root-of-Trust (RoT), sometimes referred to as Trust Anchor, is a fundamental component in computer and information security. It is an element, typically implemented in hardware or firmware, that is considered implicitly trusted and forms the basis for establishing and verifying the authenticity and integrity of various system components, software, and data. The primary purpose of an RoT is to provide the secure foundations for building and maintaining trust within a computing environment. For instance, it is used for the following:

• Secure Boot and Initialization. The RoT ensures that a computer system starts up securely. It verifies the integrity of the bootloader and firmware during the boot process, ensuring no malicious code has been injected into these critical components. This helps prevent firmware-level attacks and rootkits from compromising the system.
• Code and Data Authentication. The RoT mechanisms can be used to authenticate and verify the integrity of software applications and data. This ensures that only trusted and authorized code and data are executed or accessed on a system.
• Cryptographic Operations. The RoT often includes cryptographic capabilities and can generate and manage cryptographic keys. This is crucial for secure communication, data encryption, and authentication between different system components and devices.
• Secure Storage. Some RoT implementations provide secure storage for sensitive data, such as cryptographic keys or biometric templates, ensuring that this data cannot be easily tampered with or stolen.
• Remote Attestation. The RoT can be used for remote attestation, allowing a system to prove its trustworthiness to remote entities. This is particularly important in scenarios like cloud computing, where a remote server needs assurance that a client device is secure before granting access.
• Hardware-Based Security. Many RoT implementations are designed to be tamper-resistant and are stored in secure hardware modules, making it difficult for attackers to compromise their integrity.
• Trust in Supply Chain. The RoT can establish trust in the supply chain by ensuring that hardware components and software are genuine and have not been tampered with during manufacturing, distribution, or deployment.
• Protecting Against Insider Threats. The RoT can also help protect against insider threats by limiting access to sensitive information and functions based on authentication and authorization policies.

The RoT is the key element for building Trusted Execution Environments, typically through secure boot routines. In this sense, a TEE can be seen as a layered structure in which each layer is enabled (and configured) upon verification of the previous layer. The resulting environment constitutes a secure zone where code and data can be executed and processed securely. Each layer provides specialized security mechanisms that rely on the ones of the lower layer and support the higher layer. In case of an attack on any of the elements of a layer, the corresponding layer can attempt to counter the attack with its security mechanisms, and, in case of failure, that layer can be isolated by leveraging the lower layer. The highest layer of the security chain is the one connected with the main operating system, other parts of the processor, and eventually external systems, which are insecure. In some cases, not only can the highest layer be interfaced with insecure elements or zones, but also lower layers can, for instance, to provide advanced specialized services. In the former case, the TEE can be modeled as a Chain-of-Trust (CoT), i.e., the organization of the layers is purely sequential; in the latter case, the TEE can be modeled as a Tree-of-Trust (ToT), i.e., some layers concur with each other. A representation of the two different topologies is given in Figure 1.

The separation between the secure zone and the non-secure zone can be physical or logical. In the first case, only the secure software can access the hardware security-critical components, and the insecure software can exchange data with the secure software to request security services. The most significant example relies on the usage of two distinct processing units. One of the processing units (e.g., a MicroController Unit, MCU) is dedicated to all and only the security-related functions and processes, and is eventually assisted by additional hardware accelerators or specialized circuits; for this reason, such a microcontroller is called a Secure MCU, and it is provided with its own RAM that is called Secure RAM (SRAM). The other processing unit (e.g., the main processor) is in charge of executing the operating system and general-purpose applications. The main processor can make a request for security services to the Secure MCU through dedicated interconnections (e.g., a mailbox system). In the second case, both secure and non-secure software share the same hardware resources, but only the secure software has access to the resources dedicated to the security functions. An example can be a unique processor that executes both security-related software and non-security-related applications, hence exploiting the same RAM for both of them. Furthermore, some memory spaces are dedicated only to security-related data and instructions, and their access is forbidden to non-secure applications. Section 3 reports an overview of the state-of-the-art RoT-based Trusted Environments.

3. State of the Art of RoT-Based Trusted Environments

Several implementations of hardware security solutions are released by the main GPP vendors like ARM, Intel, and AMD targeting different uses such as isolated execution and TEE, acceleration of security functions, random number generation, and memory protection.

ARM proposes the so-called TrustZone [24,25], which is a system-wide technology integrating security features into the ARM processors, bus fabric, and peripherals. Instead of protecting assets in a dedicated hardware block, the TrustZone architecture adds security functionalities to any part of the System-on-Chip (SoC). The TrustZone strategy is based on the partitioning of all the SoC resources (both hardware and software) in two worlds: the Secure world for the Security Subsystem and the Normal world for everything else. At the hardware level, the division of the world is implemented through different hardware features: the bus fabric can ensure that no Secure world resources can be accessed by the Normal world components. This is accomplished through the Advanced eXtensible Interface (AXI) bus, which contains a dedicated bit to determine secure and non-secure read/write operations; hardware extensions are included into the processor in order to enable it to execute code from both the Normal world and the Secure world in a time-sliced fashion. This feature removes the need for a dedicated processor for the security part, so the single processor runs the secure software when its state is secure, and the normal software when it is in the non-secure state; introduction of a hardware classification of the memory-mapped devices as secure or non-secure through the TrustZone Address Space Controller (TZASC) and memory division into secure and non-secure through the TrustZone Memory Adapter (TZMA); and distinction between secure and non-secure prioritized processes interrupts through the interrupt controller. Each world manages the resources for applications belonging to its world’s space. The two different software stacks (i.e., secure software and non-secure software) are executed one at a time on the same processor. The context switching between Secure and Normal world is handled by monitor mode, which is the highest privilege level of the Secure world and can access both worlds’ system’s resources. ARM TrustZone is integrated inside Cortex-A [26], as well as in Cortex-M [27] with some differences related mainly to privilege levels of the processor.

The Intel Software Guard eXtensions (SGX) is an isolation technology included in almost all the 6th generation of Intel processors, which virtually creates a secure zone for secure code. This technology, unlike the ARM TrustZone, does not divide the execution process into two worlds (i.e., Secure and Normal world) but creates a secure computing space within the untrusted application: the Enclave. The Enclave is a protected container the applications can instantiate, which ensures confidentiality and integrity by using memory access checks and by encrypting data and code that goes outside the CPU. At the hardware level, the architectures supporting SGX are equipped with a set of security-related instructions and dedicated hardware components like the Enclave Page Cache (EPC) to support the multitasking of different Enclaves and the Enclave Page Cache Map (EPCM) to track page space of each Enclave. As discussed in [28], a user application can instantiate an Enclave using a trusted process. Such a process communicates with the EPC to assign an enclave page to the application, and the page information is checked by the EPCM. The target process is executed thanks to the Enclave and after its completion, the Enclave is destroyed and the page space released. Further information about the Intel SGX technology can be found in [29,30,31,32,33].

AMD proposes the Platform Security Processor (PSP) [34], which is a standalone coprocessor embedded inside the main AMD CPU. It is responsible for creating, monitoring, and maintaining the security environment, including managing the boot process, initializing security-related mechanisms, monitoring the system for any suspicious activity, and implementing an appropriate response. The PSP consists of an ARM microcontroller, cryptographic coprocessors, local memory, local registers, and interfaces to interact with the system memory, IOs, and configuration registers. The primary function of the PSP is to protect the main AMD core and to provide the hardware RoT; the PSP is in charge of the boot sequence using its own ROM and SRAM using the Unified Extensible Firmware Interface (UEFI) Secure Boot process. The communication mechanism between the PSP and the main CPU is implemented by interrupts: the PSP processor can generate interrupts to the CPU using PCI-compliant messages and the main CPU can raise interrupts to the PSP as well. This is accomplished via a PSP–CPU mailbox mechanism.

The CryptoManager Root-of-Trust (CMRT) [35,36] is a family of hardware-based RoT IPs developed by Rambus. It includes a 32-bit RISC-V processor, a ROM unit, and hardware resources dedicated to accelerating the security algorithms and managing the security assets. It also features private buses and interfaces for the integration of One-Time Programmable (OTP) memories and SRAMs within the Trusted Environment. It was developed to assist general-purpose processing units for Internet-of-Things (IoT), automotive, connectivity, and sensor applications.

Another commercial solution for hardware RoT is the Synopsys tRoot Hardware Security Module (HSM) [37]. The tRoot HSMs are designed to be integrated into SoCs, and the architecture can be customized depending on the application. The tRoot includes a CPU with secure instructions and data controllers for external storage, hardware key management and protection, hardware accelerators for cryptographic functions, and different interfaces (e.g., UART, GPIO, etc). The main goal of the tRoot is to provide a TEE to protect sensitive information and processing and implement security-critical functions such as secure boot, storage, debugging, anti-tampering, and key management.

For what concerns academic solutions, the work in [38], named Bastion architecture, is a hardware–software architecture for protecting security software modules in an untrusted software stack. At the hardware level, Bastion features dedicated instructions and registers inside the CPU, dedicated registers external to the CPU for storing hash values and keys, and dedicated engines for encryption, hash functions, and random number generation. The strategy in the Bastion architecture is to provide direct hardware protection of the hypervisor before employing it to protect the operating system and application modules. A similar solution has been proposed in [39], where the authors present an architecture named HyperWall to provide hypervisor-secure virtualization through hardware support. Also in this case, the solution of [39] proposes a hardware extension applied to a standard processor rather than dedicated and isolated hardware for security. The hardware extension includes new instructions, dedicated registers for the virtualization and key materials, and crypto-engines for random number generation, encryption, and hash functions. Other academic solutions can be found in [40,41,42].

The review of the state-of-the-art commercial solutions for TEEs is summarized in

Table 1. Comparison of state-of-the-art TEEs.

	Rambus CMRT	ARM TrustZone	Intel SGX	AMD PSP	Synopsis tRooT
Implementation Strategy	Discrete	Integrated	Integrated	Integrated	Discrete
Isolation approach	Physical	Logical	Logical	Physical	Physical
Platform(s)	SoC IP	Cortex CPUs	from 6th generation of Intel CPUs	Ryzen CPUs	SoC IP

.

4. Design Methodologies and Key Aspects for Security Modules in Secure Zones

According to how much was highlighted by the review of the state of the art (Section 3), each of the proposed Trusted Environments relies on different and multiple components such as microcontrollers, OTPs, and coprocessors. As each of these elements is involved in the construction and maintenance of the TEE, each of them must offer an adequate level of security and adequate characteristics to carry out such purposes. Any flaw or vulnerability in any of the elements involved in these processes can severely compromise the security of the whole TEE. From a security point of view, any system integrating or adopting a Trusted Environment can be modeled as illustrated in Figure 2, by separating the security-related functions resources (Secure zone, green box) and non-secure-related resources (Non-secure zone, red box). The block that connects the zones is the representation of all the mechanisms through which the two zones can interact. It must integrate robust security policies that define how the assets of the secure zone may be accessed. For instance, it must regulate the content and the transfer methods of data from one zone to the other one and vice versa.

According to the model in Figure 2, three key aspects must be addressed in the implementation of the secure zone to guarantee such an environment is trusted. The three aspects are:

• the Security Services and Functions;
• the Interface Security Policy;
• the Physical Implementation.

The first aspect concerns the definition of which security function, service, or mechanism is included (e.g., confidentiality, integrity, authentication), how it is implemented (e.g., symmetric-key cryptography, hash functions, public-key cryptography, or other solutions), and the level of security required. In particular, this last point regards the usage of cryptographic algorithms. Indeed, the National Institute of Standards and Technology (NIST), which is one of the most important organizations in the matter of cybersecurity and standardized most of the cryptographic algorithms used, defined different levels of security. The security level (or strength) is expressed in bits, and the minimum accepted level for long-term protection is 128 bits. The quantification of the security strengths offered by the most diffused cryptographic algorithm is reported by the NIST in [43]. In addition, the used cryptographic algorithm(s) must also be verified at the functional level, ensuring its compliance with the corresponding standard. For this purpose, the NIST releases test vectors for each of its standardized algorithms through the Cryptographic Algorithm Validation Program (CAVP).

The second aspect focuses on the mechanisms aimed at managing and regulating the access and the life cycle of the security-critical assets. Once the security service and the cryptographic functions are defined at the first point, it is possible to individuate the security-related material and sensitive data that will be processed such as the cryptographic keys. In this case, the interface security policy may integrate dedicated mechanisms for the establishment or installation, the secure storage, and the maintenance of keys. Seal/unseal mechanisms can be used to protect keys from unauthorized access (by supporting different privilege levels), to bind the key for a specific usage (e.g., a specific cryptographic operation), and/or to limit its usage (e.g., for one, tens, or hundreds of times). Also, data access must be regulated. In this sense, an interface security policy mechanism may rely on a dedicated Finite State Machine (FSM) that strictly handles the data processing phases and allows access only once the cryptographic operation is completed. Any access attempt before the conclusion of the cryptographic operation may be logged and reported as a warning or as an alert.

The third and last aspect, which is equally important, concerns the physical implementation. Indeed, also the physical implementation of a secure system or module can introduce vulnerabilities, even if the chosen security algorithm is robust and cannot be violated from a numerical or mathematical point of view. When the module executes the chosen algorithm, the physical level may emit sensitive information through physical quantities, such as time, power consumption, electromagnetic radiation, or sound. This constitutes an unintentional leakage of information through a secondary channel (or side channel), i.e., the physical one, and it can be exploited to perform an attack bypassing the interface security policy level. To give a more intuitive explanation, for example, it is enough to consider the physical processes involved in the usage of transistors implemented in CMOS technology. When these hardware elements treat digital information formed by 0s and 1s, they can be assimilated into a capacitor which is charged or discharged, according to the digit value. Therefore, by measuring the power consumption of transistors, it could be possible to recover the value of the processed data. Due to their nature, such attacks take the name Side-Channel Attacks (SCAs), and Figure 3 depicts their scheme of operation.

SCAs are widely documented in the literature and constitute one of the hottest topics in the cybersecurity field. An exhaustive and systematic review of SCAs can be found in [44,45,46], while [47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63] report several examples of the most diffused categories of attacks that exploit the physical implementation of a device, which are listed below:

• Cache attack [47,48,49]: This class of attacks is based on monitoring cache accesses in a shared physical system and, as the name suggests, it is mostly applied to software contexts. The protection strategies usually consist of replacing the LUTs with a series of equivalent logical operations, using alternative forms of LUTs, or creating an obvious memory access pattern (i.e., reading all LUT values in a fixed order and using only the one needed) [47,48].
• Timing attack [50,51,52,53]: This category of attacks concentrates on measuring the execution time of routines, targeting software implementations in which different instructions, branches, RAM cache hits, etc., cause time variation in the process. The protection mechanisms typically involve techniques for time equalization and reduction of unpredictable events (such as cache misses, etc.), or insertion of random delays [51,52,53].
• Power analysis [53,54,55,56,57,58,59,60,61,64,65]: This family of attacks is one of the most effective on both hardware and software implementations, and it exploits the power consumption of underlying physical circuits. Concerning the software case, if each opcode of the instruction set architecture can be associated with a different and specific power trace shape, then the series of operations performed by a routine is revealed; on the hardware side, data dependencies over different power traces can be analyzed to recover secret information. The most notorious attack classes of this group are Single Power Analysis (SPA), Differential Power Analysis (DPA), and Correlation Power Analysis (CPA). The first one consists of recovering data values by just observing the shape of a power trace; for instance, in a branched architecture where a certain value of processed information activates a certain branch rather than another one, isolating the branch-specific power profile within a power trace makes it possible to recover the sequence of 0s and 1s. DPA and CPA attacks instead are more sophisticated, and they employ statistical methods to disclose secret information. As can be intuited from what has been expressed so far, each of these attacks requires a certain knowledge of architecture, especially in the case of DPA and CPA, which typically make use of a power consumption model to make a guess of the value of processed data: the further the model from the real architecture, the weaker the guess. For power analysis attacks, the countermeasures usually are implemented by adopting two techniques, masking or hiding, or a mix of both. The former is aimed to reduce or eliminate the dependencies between data and power consumption; the latter instead is aimed to jam the Side-Channel with noise in order to reduce the signal-to-noise ratio of leaked information. Masking typically introduces significant overhead in terms of area and critical path, by requiring up to 5 times the amount of logic resources employed by the unprotected module, and lowering the maximum frequency of the circuit up to 2/3 times [53,56,59,61,65]. On the other hand, hiding usually is realized by coupling the unprotected module in parallel to a block dedicated to noise generation, thus the critical path of the circuit is not affected and the overhead of resources is limited. In that case, the most significant cost concerns are the power consumption, which can introduce an overhead of up to 5 times larger [54,55,57].
• Electromagnetic analysis [62]: This category of attacks relies on leaked electromagnetic radiation. It is usually assimilated to the class of power analysis attack, under the rough assumption that electromagnetic radiation is highly correlated (or proportional) to power consumption. Therefore, attacks and defense mechanisms are developed accordingly to the one of power analysis, using electromagnetic probes, instead of an instrument to measure the current.
• Differential fault analysis [63]: This type of attack has the purpose of discovering secrets by introducing faults while the system is running normally. The corresponding protection mechanisms typically involve architectural redundancy approaches and techniques for concurrent error detection.

Confirmations of the severity of SCAs can be found, for example, in [66]. It analyzes the resistance of ARM TrustZone with respect to Side-Channel leakages and reports several violations of security due to fault attacks [67,68,69], cache attacks, [7,8,9,10], and EMA [11,12,13].

According to the key aspects to be addressed for the development of a secure module, the security partitioning model illustrated in Figure 2 should be applied recursively to each layer and to each element of the chain involved in the construction of the TEE by dividing it into both trusted and non-trusted components. The results of this approach converge in the definition of a more accurate partitioning model that is represented in Figure 4. Such a model counts four abstraction layers that are, respectively from the top to the bottom, the protocol level, the software architecture level, the hardware micro-architecture level, and the circuit level. Each of these levels is characterized by the separation between security-related and non-security-related resources and a specific interface security policy between them. In addition, the interconnection between each level and the higher one is characterized by a specific class of SCA. Respectively, from the top to the bottom, they are interpreter-level attacks (such as fault attacks), timing analysis and cache attacks, and power analysis attacks (such as SPA, DPA, and CPA).

In conclusion, when designing a secure module to be integrated into a Trusted Environment (for its construction and maintenance), the three highlighted security aspects must be carefully addressed. According to the implementation methodology (only hardware, only software, or mixed hardware–software), the security module must be modeled according to the scheme presented in Figure 4, and the corresponding security mechanisms must be developed including the interface security policy and resistance measures against SCAs.

5. Case Study: Cryptographic Hardware Coprocessor for the Secure Subsystem of Rhea GPP

Similarly to the AMD PSP, the decision for the isolation strategy of the TEE inside the Rhea GPP was to isolate it from the main processing unit(s) at the physical level by implementing a Security Subsystem dedicated to all and only the security services. The outline of the Rhea GPP developed in the framework of the EPI project is illustrated in Figure 5, while Figure 6 focuses on the internal architecture of the Trusted Environment (i.e., the Security Subsystem).

Our research group was involved in the development of the cryptographic hardware coprocessor (the blue box in Figure 6) that has the purpose of assisting the secure boot routine for enabling the Security Subsystem and providing high-performance security mechanisms [20]. The implemented module was named Crypto-Tile and offers cutting-edge security services [14]. According to the presented design methodology in Section 5.1, Section 5.2 and Section 5.3, we described the features integrated within the developed security module, respectively, at the security service level, interface security policy level, and physical implementation level.

5.1. Security Services

In order to support both the secure boot routine and high-performance security functions at run-time, we embedded in the Crypto-Tile four independent and specialized cryptographic coprocessors, with each one for a different family of cryptographic operations. With reference to the architecture outline of the Crypto-Tile that is shown in Figure 7, our module embeds:

• A coprocessor for symmetric-key cryptography based on the Advanced Encryption Standard (AES) algorithm [17]. This coprocessor offers:

  –

  Confidentiality, through the AES modes operation Electronic CodeBook (ECB), Cipher Block Chaining (CBC), Cipher FeedBack (CFB), Output FeedBack (OFB), and CounTeR (CTR) [70];

  –

  Authenticated Integrity, through the AES mode of operation Cipher-based Message Authentication Code (CMAC) [71];

  –

  Authenticated Encryption, through the AES modes of operation Counter with CBC-MAC (CCM) [72] and Galois Counter Mode (GCM) [73,74];

  –

  Disk encryption, through the AES mode of operation XEX encryption mode with Tweak and ciphertext Stealing (XTS) [75].

  For each of the listed modes of operation, the AES coprocessor supports both 128-bit and 256-bit keys, respectively providing a corresponding security level of 128 and 256 bits [43].
• A coprocessor for public-key cryptography based on Elliptic Curve Cryptography (ECC) [16]. This coprocessor offers:

  –

  Acceleration of computationally intensive arithmetic operations over elliptic curves, such as Point Addition and Point Doubling;

  –

  Generation of private keys, key pairs (both private and public), and derivation of corresponding public keys starting from private keys;

  –

  Authentication and non-repudiation, through the Elliptic Curve Digital Signature Algorithm (ECDSA) [76].

  For each of the listed functions, the ECC coprocessor supports both 256-bit and 521-bit elliptic curves, in particular the NIST P-256 and the NIST P-521, that provide, respectively, a corresponding security strength of 128 and 256 bits [43].
• A coprocessor for hash functions based on the Secure Hash Algorithm (SHA) [18]. This coprocessor offers integrity through the algorithms SHA2 [77] and SHA-3 [78]. For both the SHA functions, the supported digest sizes are 224, 256, 384, and 512 bits, providing a corresponding security level of 128 (256-bit digest) and 256 (384-bit digest) bits [43].
• A coprocessor for Random Number Generation (RNG). This coprocessor offers:

  –

  Generation of high-entropy key-related material and seeds, through a True Random Number Generator (TRNG) [19];

  –

  Generation of key-related material, non-repeating values, and initialization vectors through a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) [79], which is seeded thanks to the TRNG.

The ECC and SHA cryptoprocessors support the secure boot routine to verify, respectively, the authenticity and the integrity of the first bootloader stage. Indeed, at the boot, the Secure Element in Figure 6 loads the software code from the OTP into the SRAM of the Master Secure MCU, enables the corresponding hardware acceleration unit (Crypto-Tile), and uses it to verify the integrity and the authenticity of the software code. Upon the success of this step, consequently, the Master Secure MCU performs similar operations by enabling the other Security Domains (triplets of Secure MCU, SRAM, and Crypto-Tile). After this process, the Secure Subsystem of Rhea GPP is fully enabled and can provide run-time security services that are accelerated in the hardware by the instances of the Crypto-Tile and all the embedded cryptoprocessors.

All the implemented algorithms have been tested and verified at the functional level with the corresponding suite of test vectors provided by the NIST through the CAVP.

The implemented cryptographic coprocessors were developed to find the best solution in terms of the trade-off between performance, resource consumption, and security strength. Indeed, according to [43] the minimum level of security for long-term protection is 128 bits, and it corresponds to the usage of 128-bit keys for the AES algorithms, 256-bit elliptic curves for ECC functions and schemes, and 256-bit digests for the SHA2 and SHA-3 functions. In addition, we also integrated security levels for supporting protection in terms of Post-Quantum Cryptography (PQC) to enhance the security level of the Crypto-Tile. According to [80,81], this requires the usage of 256-bit keys for the AES algorithms and 384-bit digests in the hash functions. Since the logic resources to implement the hash functions for the generation of 224-bit and 512-bit digests are the same as the ones required for the generation of 256-bit and 384-bit digests, respectively, we integrated the generation mechanisms for all the digest sizes in the hash cryptographic coprocessors, improving its flexibility and without increasing the cost in terms of logic resources.

The synthesis results on a 7 nm standard-cell technology for the Crypto-Tile and the embedded cryptographic engines are illustrated in [14,16,17,18,19], in which we reported the area complexity expressed in Gate Equivalent (GE), the throughput, and the power consumption. In general, all the proposed engines outperform the existing solutions documented in the corresponding literature in terms of efficiency expressed as throughput per area and in terms of energy consumption. In particular, the AES engine, refs. [14,17], requires an area complexity of 56.01 kGE and supports a maximum frequency of 2.425 GHz, offering a throughput higher than 30 Gbps at the cost of 10.9 mW of dynamic power consumption. Concerning the engine for the public-key cryptographic functions, refs. [14,16], we opted for the ECC-based cryptography instead of the Rivest–Shadir–Adleman (RSA) cryptographic scheme, because it offers the same security level while requiring much lower resources [43]. Hence, the developed ECC engine occupies an area of 658.9 kGE, supports a maximum frequency of 1.525 GHz, and shows an average dynamic power consumption of 170 mW for signatures generation and 130 mW for signatures verification. It is interesting to signal that the ECC engine itself occupies about 50% of the area of the whole Crypto-Tile: this confirms that the choice of implementing public-key cryptographic functions based on the ECC algorithm was the best solution because the usage of the RSA-based counterpart would have required a much higher amount of resources, making the public-key coprocessor consume almost all the logic resource required to implement the Crypto-Tile. In addition, the ECC coprocessor has been designed with a specific interface to support higher-level ECC-based schemes such as the Elliptic-Curve Diffie–Hellman (ECDH) [82], the Elliptic-Curve Menezes–Qu–Vanstone (ECMQV) [82,83], and the Elliptic-Curve Integrated Encryption Scheme (ECIES) [83,84], which can be implemented in software. Thanks to the specialized mechanisms for the interface security policy (Section 5.2), the ECC coprocessor can accelerate in hardware the most computationally intensive parts of such schemes by assisting the dedicated secure software routines implementing them. Similarly, the SHA coprocessor, refs. [14,18], which occupies an area of 128.32 kGE, supports a maximum frequency of 3.725 GHz and shows average dynamic power consumption of 100 mW and 70 mW for the SHA2 and the SHA-3 functions, respectively, and is able to assist in hardware secure software routines dedicated to the HMAC scheme [85]. Finally, the RNG engine, refs. [14,19], requires an area complexity of 127.16 kGE and shows an average dynamic power consumption of 130 mW at the frequency of 4.325 GHz. This engine was characterized not only in terms of performance but it was also validated by using dedicated statistical test suites to evaluate the levels of entropy and randomness offered by the generated bitstreams [86]. All the tests were successful, satisfying the security requirements defined by the NIST and the Bundesamt für Sicherheit in der Informationstechnik (BSI) [19].

To evaluate the performance of the Crypto-Tile and its cryptographic engines, we also implemented a demoboard on a VCU128 board by Xilinx/AMD. The implemented system was aimed at emulating a Security Domain (Figure 6) by integrating the Crypto-Tile together with a 64-bit RISC-V processor CVA6 [87] as Secure MCU, a DDR controller to exploit the DDR4 memory onboard and implement the SRAM, and an AXI4 bus as system bus. The results showed that the Crypto-Tile is able to accelerate the security services and functions up to 400 times [14].

5.2. Interface Security Policy

According to the security functionalities included in the Crypto-Tile and described in Section 5.1, it is possible to individuate the main security-critical assets that require additional protection mechanisms when they are installed, used, and erased. We targeted the security-critical assets at three different levels:

• Global Crypto-Tile level: this level concerns the global configuration of the Crypto-Tile;
• Cryptographic Operation level: this level concerns data that are processed during the execution of the cryptographic operations;
• Key material level: this level concerns the keys, their installation in dedicated registers inside the Crypto-Tile, and their storage, access, and utilization statistics.

At the Global Crypto-Tile level, we integrated seal/unseal mechanisms that rely on a unique identifier that is configured during the secure boot process and the support of two authorization levels for access to the Crypto-Tile: a privileged level and an unprivileged level. For the cryptographic operation level, we integrated dedicated resources that strictly regulate the execution of each cryptographic operation and the access to the related data. For instance, Figure 8 shows the state diagram of the FSM that handles the cryptographic operations for the AES cryptoprocessor and manages access to the processed data. The auxiliary data such as initialization vectors can be provided in input only in the CONFIGURED state, while the input data to be encrypted can be written only in the RUNNING state, only once and only after the encryption of the previous data block is completed. In addition, the corresponding output data can be read only once and only in the RUNNING or ENDED state depending on the executed cryptographic operation. Similarly, the commands that can be provided to the AES cryptoprocessor strictly rely on the current state of the FSM.

Concerning the key material level, the Crypto-Tile embeds dedicated seal/unseal mechanisms similar to the ones used for the Global Crypto-Tile level. A dedicated FSM for each key regulates its usage similarly to how it is illustrated for the cryptographic operations in Figure 8. Counters and configuration registers limit the key utilization according to the target operation. For instance, the usage of cryptographic keys can be configured for specific AES operations such as the GCM one or only for encryption processes. In such a case, the usage of that key in other AES operations different from the GCM one or in decryption processes is not permitted.

In addition, each level presents logging and alerting resources to check unauthorized access and interrupt all the ongoing operations in case of misusage, as well as triggers for two distinct levels of panic mode. According to the severity of the panic mode, the key material can be preserved to allow for retrieving it after the termination of the panic mode, or it can be flushed to prevent an attacker from taking it over.

5.3. Physical Implementation

Regarding the physical implementation and according to the security partitioning model in Figure 4, the Crypto-Tile has an impact on both the circuit level and the hardware micro-architecture level. For this reason, we provided our module with countermeasures for both timing and power analysis attacks.

We integrated a clock randomization mechanism to counteract timing attacks [54,55]. In this way, the execution of each cryptographic operation is unpredictable and an attacker cannot gain information by observing it. For instance, the usage of 128-bit or 256-bit keys in the AES operations determines a different execution time, because the former requires 10 processing rounds, while the latter requires 14 processing rounds. With the clock randomization approach, an attacker is no longer able to distinguish between the key size from the execution time of an AES operation. In addition, such a mechanism aids also in lowering the success rate of power analysis because DPA and CPA require the time alignment of the power traces [88]. It is worth pointing out that the utilization and the configuration of the clock randomization mechanism are strictly regulated by specific authorization procedures at the interface security policy level because its usage has direct effects on the security strength of the cryptographic coprocessors, hence also it must considered as a security-critical asset.

Concerning power analysis attacks, we integrated also other dedicated protections to make them ineffective. For instance, the ECC operations are very vulnerable to SPA, i.e., by observing just one power trace, an attacker can retrieve the secret key without additional statistical computations such as in DPA and CPA [16]. Thanks to the methodology described in [88], we were able to analyze and evaluate the resistance of our ECC coprocessor against Single Power Analysis (SPA) without the necessity of the physical chip and using gate-level simulations, concluding that the dedicated countermeasures are able to guarantee the required protection and defeat successfully these kinds of attacks [16]. Indeed, by exploiting the same gate-level simulations on the netlist that we used to measure the power consumption of the Crypto-Tile (Section 5.1), we were able to gather and analyze the power consumption profile of the engines during the execution of the cryptographic operations. As an example, in Figure 9 we report the power consumption profile of the ECC engine before the integration of dedicated security mechanisms against power analysis attacks.

As illustrated in Figure 9, without equipping the cryptographic ECC engine with specialized countermeasures, it is possible to distinguish if the bit of the key processed by the engine is 0 or 1, because according to its values, the engine shows a different power profile. Hence, an attacker can retrieve the value of the secret private key with a single SPA attack, i.e., by analyzing only a single power trace. In Figure 10, it can be noted how the power profile of the ECC engine changed after the integration of the dedicated countermeasures; after the modifications, the power profile is invariant with respect to the value of the key bits.

5.4. Comparison with Existing TEEs

According to the results of the case study illustrated in Section 5.1, Section 5.2 and Section 5.3, we propose a brief comparison between the hardware-based security solutions analyzed so far and the proposed hardware coprocessor for the Rhea GPP. The isolation approach adopted in the Rhea chip is similar to the one proposed in the AMD PSP, Rambus CMRT family, and Synopsis tRoot products, that is the physical and complete isolation of the security functions in a dedicated zone of the chip that is separated from the main computational unit of the system. All the analyzed solutions include programmable units (e.g., microprocessors or microcontrollers), secure memories, and hardware accelerators for the most computationally intensive cryptographic algorithms. It is difficult to fully characterize the communication mechanism between the secure zone and the non-secure zone for each solution. The AMD PSP adopts a mailbox-based mechanism to exchange requests of security services from the main CPU (i.e., non-secure zone) to the secure zone, and a similar approach is adopted in the Rhea chip. Instead, this kind of information cannot be extracted for the Rambus CMRT family and the Synopsis tRoot. The solution proposed by ARM (i.e., the ARM TrustZone) and Intel (i.e., the Intel SGX) is opposite to the previous ones. The execution of the secure software is allotted to the main processing unit(s) together with the normal software, and the isolation between the Normal world (non-secure zone) and the Secure world (secure zone) relies on software assets aided by dedicated hardware extensions: for instance, such software assets take the name of Enclave in the Intel SGX. On the one hand, this latter solution lowers the cost in terms of physical resources; on the other hand, the former approach guarantees a stronger isolation between the two zones. Indeed, as an example, the work in [89] demonstrates that Hardware-assisted Isolated Execution Environments (HIEEs) like the ARM TrustZone and the Intel SGX are susceptible to Denial-of-Service (DoS) and spoofing attacks. By contrast, such attacks cannot be performed against the AMD PSP and the Security Subsystem of the Rhea GPP because the physical isolation between the secure zone and the non-secure zone makes them immune.

6. Conclusions

In this work, we explored the critical aspects of designing robust and highly qualified security modules for Trusted Environments. We discussed the need for security modules that can withstand sophisticated attacks and ensure the integrity, confidentiality, and authenticity of sensitive information. Our research focused on developing a comprehensive design methodology and a set of metrics that can guide the creation of such security modules. The proposed methodology places a strong emphasis on the identification of potential vulnerabilities at different and various levels and the application of security principles in every aspect of the design process. We showed that our approach results in modules that are fully equipped to withstand both known and emerging threats, according to the presented case study. Furthermore, we introduced a set of metrics to assess the security modules. These metrics provide a structured way to evaluate the robustness, efficiency, and effectiveness of the modules, ensuring that they meet the stringent requirements of Trusted Environments. Our study has also highlighted the strict connection between such metrics through the case study. Indeed, it shows how the security services provided by the developed security module and the implementation platform (hardware or software) concur to the definition of security-critical assets, whose access must be regulated by means of dedicated and specialized procedures and resources at the interface security policy level.

In conclusion, our research offers a valuable contribution to the field of TEE security. We have provided a systematic methodology and a set of metrics to guide the design and evaluation of security modules. By following these guidelines, developers and security professionals can create solutions that are more resilient and trustworthy. As Trusted Environments become increasingly vital in today’s interconnected world, the principles outlined in this paper are instrumental in achieving the highest level of security and reliability.