## 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:  
1. the Security Services and Functions;
2. the Interface Security Policy;
3. the Physical Implementation. \begin{table}
\begin{tabular}{l l l l l l} \hline \hline  & **Rambus CMRT** & **ARM TrustZone** & **Intel SGX** & **AMD PSP** & **Synopsis tRootT** \\ \hline Implementation & Discrete & Integrated & Integrated & Integrated & Discrete \\ Strategy & Physical & Logical & Logical & Physical & Physical \\ \multirow{2}{*}{Platform(s)} & \multirow{2}{*}{SoC IP} & \multirow{2}{*}{Cortex CPUs} & from \#th generation & \multirow{2}{*}{Ryzen CPUs} & \multirow{2}{*}{SoC IP} \\  & & & of Intel CPUs & & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison of state-of-the-art TEEs. 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.