# Roots Of Trust (RoTs)

## Overview

RSL15 provides facilities to support two independent hardware Roots of Trust (RoTs).

A Root of Trust provides a secure mechanism to verify that code being executed on the device has been verified and authenticated.

- Verification involves checking that the firmware image being executed has not been corrupted. It uses a cryptographic signature to verify that the code is correct.
- Authentication involves checking that the firmware image has been provided by a trusted party, by ensuring that the key used to sign the image is actually owned by the firmware provider.
  - The authentication process uses asymmetric encryption where the public key is known to the device and the private key is used to sign the image.
  - In this way, the system can guarantee that the image has been signed by someone authorized to sign the firmware, and that the image has not been tampered with or corrupted.

In RSL15, the information required to enable this process is held in hardware and in the secure processing element.

- The ROM manages the boot process and ensures that an application has been signed and authenticated using assets stored in secure storage on the device.
- The ROM is immutable, hence the secure boot process can be trusted to verify the application firmware.
- The keys and other assets used to enable this process are held in NVM memory in a secure fashion, with anti-tamper detection to ensure consistency. This is achieved by the inability to overwrite ones with zeros in this area of NVM which behaves like OTP. Therefore, counting the zeros in the protected areas combined with accessing only through the secure IP block, provides anti-tamper protection.

Having the ROM manage the boot process, with immutable keys and assets ensures that the RoT is embedded in the hardware of the device. As indicated, RSL15 maintains two sets of RoT keys and assets allowing for two independent Roots of Trust. These can be enabled and used as required.

Since the specific parameters controlling the RoT are stored in NVM, these must be provisioned as part of the initial device setup. It is possible to use a single set of RoT parameters across a family of devices. Alternatively, unique parameters can be allocated to each individual device. The device manufacturer decides this based on their specific use cases.

## Root of Trust: The Mechanics

In its simplest terms, the Root of Trust consists of a known protocol to follow when authenticating information, combined with some token used for proving authenticity.

This protocol is implemented by the device’s ROM and the token is stored in NVM memory—which is configured such that corruptions can be detected. This provides a high level of security for the initial application, which can then perform further validations if required.

The system uses asymmetric cryptography for the tokens, storing a representation of an RSA public key on the device. Specifically, a 128-bit hash of the public key is stored in the NVM, together with metadata to ensure that corruptions can be detected.

This public key hash is then used to verify and authenticate certificates that accompany the firmware application. The use of certificates to introduce key information is common in security, and the processes employed in ROM follow standard techniques.

## Self-Signed Certificates

The device uses self-signed certificates based on an RSA key hash to authenticate and, if necessary, unencrypt assets. Such an asset could be a binary application for the device to execute, or a debug certificate provided to unlock debug functionality.

A self-signed certificate consists of four distinct parts:

- A header defining the type of the certificate, with any additional metadata the certificate provides to allow it to be understood
- A public key, used to verify the signature of the certificate
- A certificate data section containingthe information that the certificate is delivering
- A signature of the certificate, signed using a secure private key that corresponds to the public key above

By knowing the public key, it is possible to verify that the contents of the certificate have not been corrupted, and that the certificate is internally consistent.

Authenticity can be proven by verifying that the hash of the public key matches some known data. In the simplest form of a single certificate, the public key hash is compared against the hash stored in the RoT. (See the "Self-Signed Certificate Verification" figure.)

Figure: Self-Signed Certificate Verification

### Types of Certificate

There are four types of certificate used as part of the secure boot process, each one providing a different function:

- Key certificates are used to build certificate chains, by providing a payload consisting of the hash of the public key contained in the next certificate.
- Content certificates are used to identify the secure parts of an image to be executed by the Boot ROM. These are validated and, if necessary, decrypted.
- Debug enabler certificates are provided by the owner of the Root of Trust—this could be the device manufacturer or chip manufacturer—and are used to specify the precise debug features that can be enabled by a developer. These settings can be applied to a range of devices.
- Debug certificates are used by developers to enable the allowed debug features on a specific device.

## Certificate Chains

It is possible to chain certificates so that the first certificate provides information allowing subsequent certificates to be authenticated. This provides a flexible way of changing keys if one key becomes compromised.

In the ROM protocol, two or three certificates can be used in any authentication operation.

### Authenticating an Application to be Executed

When an application is loaded into the device for execution by the Boot ROM, the application must be packaged with at least two certificates: a key certificate and a content certificate (see the "Two-Certificate Authentication" figure). The certificate chain can also be extended by using two key certificates and a content certificate (see the "Three-Certificate Authentication" figure).

The ROM processes each certificate in order and the application is executed only if all verification and authentication steps are valid.

Figure: Two-Certificate Authentication

Figure: Three-Certificate Authentication

## Roots of Trust Summary

The establishment of a secure Root of Trust relies on the device having the public key associated with the first asymmetric key pair. As the public key itself is quite large, a truncated hash of the public key is stored on the device NVM; this is then used to authenticate the first key certificate in a chain of certificates.

Each certificate can be verified in isolation, as the public key forms part of the certificate contents; therefore, the information is available to check that the certificate is valid. Each key certificate allows the authentication of the next certificate in the chain, using the hashed public key. This ensures that the final application has been verified as original, and has been provided by an authenticated party.

IMPORTANT: The private keys must be kept strictly secure.