A hardware Root of Trust can be defined by the four basic building blocks:
- The protective hardware provides a trusted execution environment (TEE) for the privilege software to run.
- At a minimum, it must perform one or more proven cryptographic functions like AES based.
- A form of tamper protection must be present and available for the entire runtime.
- A flexible, yet simple user interface that the host can interact with, through either the host CPU and/or a host controller toggling GPIOs.
To meet these criteria, a hardware Root of Trust will include a variety of components, starting with a security perimeter. The security perimeter defines what needs to be protected on the SoC. It can be implemented in various ways, including via a private bus that connects to the main bus through a gateway.
Next, a Root of Trust will have a secure CPU that runs secure software/firmware. The enablement for most of the security features supported in a hardware Root of Trust is defined by the software running on that CPU. The resources around the CPU will help facilitate the security and performance of these functions.
The third element of a Root of Trust is the runtime memory. When running software on the CPU, designers need to protect the runtime data required by the software, more explicitly, the STACK, HEAP and global data. This data will contain keys in plain-text and other sensitive information. It is critical to ensure tight security around this block.
Next comes tamper resistance, which is essential for a hardware Root of Trust. Code from the outside needs to be validated prior to running it on the secure CPU. This can be implemented in many ways, for example, using a dedicated ROM that can only be accessed by the hardware Root of Trust.
Although most cryptographic functions can be supported in software, cryptography typically uses fewer memory resources and runs faster with the use of hardware accelerators. With hardware cryptographic accelerators, you can maintain high performance while using a slower clock for the CPU, which saves power, uses less runtime memory, and therefore saves area in the SoC. This is critical for cost-sensitive applications that require a high level of performance for their security functions, such as automotive applications.
Hardware Roots of Trust require a True Random Number Generator (TRNG). This module will always produce a high level of entropy required for the various security functions. Secure, untampered access to this module is critical. Compromised access to a TRNG will result in security vulnerabilities for the many security functions.
For example, many protocols generate ephemeral information to secure the connection between the end points. The high entropy used to generate the ephemeral information reduces predictability, therefore safeguarding the information. By interfering with this process, you can increase the predictability, which in turn, increases the security vulnerability of the protocol.
Including a secure clock, or secure counter, is important for applications that require a reliable time measurement. Using a secure clock is only effective if the hardware Root of Trust has access to a clock source that cannot be tampered with. A common example of this type of clock is the secure real time clock (RTC), which is typically battery powered and runs at a relatively low clock rate. Applications can use this clock to manage any time-based rights policies, for example.
The last component of a hardware Root of Trust is secure storage. Secure access to persistent storage is essential for applications requiring a state knowledge. For example, an anti-rollback feature for devices can only truly be secure if the hardware Root of Trust has secure access to a non-volatile memory (NVM). It’s critical that the information cannot be tampered with, nor can the access to the information be tampered with.