Trust Begins at Home

The first step in securing a system is to ensure that it starts from reset in an expected state and that its firmware is intact and has not been tampered with. A Root of Trust can be started by a variety of methods, including simply loading its protected memory region and signaling it that it has firmware available. Alternatively, it can be loaded using a hardware state machine from external Flash memory, run directly out of SPI memory, or many other methods. When it starts, the Root of Trust derives its internal keys from supplied device identity inputs and executes self-tests and code validation for itself. If these tests pass, it can move on to validate code for other subsystems in the chip using a secure bootstrap process.

Secure bootstrap systems use cryptographic signatures on the firmware to determine its authenticity. While predominantly firmware, secure bootstrap systems can take advantage of hardware features such as cryptographic accelerators to achieve higher security and faster boot times. Flexibility for secure boot schemes is maximized by using public key signing algorithms with a chain of trust traceable to the firmware provider. This can allow the code signing authority to be replaced by revoking and reissuing the signing keys if it is ever compromised. The essential feature that security hinges on is that the root public key is protected by the secure bootstrap system, and is unalterable. Protecting the public key in hardware ensures that the root of trust identity can be established and is unforgeable.

DesignWare tRoot Secure Hardware Root of Trust

tRoot is Synopsys’ highly-secure hardware root of trust that is designed to easily integrate into SoC ASICs and provide a scalable platform to offer diverse security functions and applications. It provides robust hardware protection while being highly configurable, flexible and maintaining a high level of performance. tRoot is used to provide security functions in a trusted execution environment as a companion to a host processor that runs most system applications. To minimize the number of attack vectors, tRoot uses a simple interface with a limited set of interactions with the host processor (Figure 1). At the same time, it provides a fully programmable platform that can offer a variety of services throughout the device’s lifecycle.

tRoot protects IoT devices using unique code protection mechanisms that provide run-time tamper detection and response, and code privacy protection without the added cost of more dedicated secure memory. This unique feature reduces system complexity and cost by allowing tRoot’s firmware to reside in any non-secure memory space. Commonly, tRoot programs reside in shared system DDR memory. Due to the confidentiality and integrity provisions of the secure instruction controller, this memory is effectively private to tRoot and impervious to attempts to modify it originating in other subsystems in the chip or from the outside.

tRoot offers a 32 bit CPU with tightly coupled SRAM that runs inside of the tRoot secure perimeter, as well as a secure instruction controller that provides tRoot with code and data confidentiality, integrity and both boot-time and run-time tamper detection for programs running in-system DDR memory. Its optional secure data controller provides encrypted, authenticated read/write data storage in the system’s DDR memory. A key management module provides hardware key derivation from keys stored in non-volatile memory (NVM) in the SoC, along with secure key ports to derive and load keys to other security subsystems on the chip. A device identity interface loads unique and other keys stored in NVM to the key management module.

The tRoot Secure Hardware Root of Trust receives input via an entropy interface from an on-chip true random number generator (TRNG) and also offers additional interface ports to communicate with the host processor and other on-chip subsystems, including inputs from tamper detection sensors.

Hardware-Enforced Secure Boot with tRoot

The tRoot boot sequence can be comprised of one or several boot loader stages. Compromising any one of these stages can compromise parts of a system, or in the worst-case, the entire system. The tRoot secure boot application protects one or more of the critical boot loader stages from attacks that modify the code loaded for the primary processor(s). This application can be configured to act as a primary boot loader or as a later stage boot loader, or both. 

tRoot as a Primary Boot Loader

As a primary boot loader, for example, the system can be configured to run automatically from reset. In this case, the secure boot loader can authenticate the system’s main host boot code prior to starting the main host processor. On successful completion, tRoot passes control to the host processor to continue (Figure 2).

1. At power up, the hardware boot module copies the tRoot firmware image from Flash to system memory (NAND Flash use case), or reads it directly (SPI Flash use case).
2. The hardware boot module moves the host CPU firmware to the system memory at a predetermined location for tRoot to access.
3. The hardware boot module de-asserts the tRoot reset which automatically starts reading the tRoot firmware and runs the secure boot application.
4. The secure boot application verifies the signature of the host CPU firmware and returns success or failure. On authentication failure, tRoot can hold the host processor in reset, or take other action as deemed suitable by the system designer.

tRoot as a Secondary Boot Loader

Alternatively, the host CPU can initiate the tRoot secure boot application to authenticate later stage host code in a multi-stage boot system (Figure 3). With this setup, a primary boot stage from trusted code (e.g., ROM) running on the host CPU has already occurred and secure boot application is protecting the integrity of the later boot stage(s). This is beneficial for IoT systems that do field updates on the host code that is verified by the secure boot application. 

1. At power up, the host CPU boots from ROM and initializes base peripherals/resources used by the boot loader
2. The host CPU moves the next stage host CPU firmware to system memory
3. The host CPU copies tRoot firmware from Flash to system memory
4. The host CPU initiates the tRoot boot process
5. tRoot runs its Secure Boot application and verifies the signature of the next host CPU boot stage(s)

A significant advantage of the tRoot secure boot application is that it can replace the protection typically provided by using system boot code in a SoC’s mask-based read-only memory (ROM) device. tRoot offers high-grade cryptographic security for run-time code protection of software residing in RAM and stored in Flash memory. This has cost and maintainability advantages for system developers without sacrificing security. Reducing or eliminating ROM reduces the overall engineering cost and risk when developing an IoT system on a chip.

IoT Security with tRoot

Secure boot is one application for the tRoot Hardware Root of Trust. It can significantly reduce the ability of adversaries to modify system code within IoT devices, while leaving designers with the ability to release future code updates for fielded systems. Minimizing or eliminating ROM from the system reduces the risk of latent defects and vulnerabilities in IoT systems.