Implementing Secure Boot With A Root Of Trust

A boot sequence describes the initial set of operations performed by a device at the start of the boot process. During this stage, available resources reside in some form of local, nonvolatile storage that is readily accessible by the device. The entity initiating the startup sequence is known as a boot loader (or bootstrap loader).

The boot loader enables forward progression throughout the startup sequence until completion, at which point the device enters its normal operational state. The boot loader flow consists of multiple stages, with each executing progressively more complex portions of the startup sequence, incorporating platform specific driver code for example. If the boot process is not secured, an adversary can insinuate counterfeit code into the boot process allowing them to take control of the system and/or execute malicious code.

With a Root of Trust, the boot flow can be implemented in a secure means by digitally signing and verifying all stages of the boot loading sequence. This is done through a multi-stage secure boot sequence proceeding through the following steps:

1. Execute initial boot loader stage from local read-only non-volatile storage (ROM), perform power on self-test (POST) for boot devices utilized during the secure boot flow, and verify the digital signature for the next stage of the boot loader (in local write-once non-volatile storage).
2. Execute the subsequent boot loader stage from local write-once non-volatile storage.
3. Load the next boot loader stage from remote mass storage to local volatile storage—and verify the digital signature of the next stage boot loader in local volatile storage.
4. Execute the subsequent boot loader stage in local volatile storage.
5. Repeat steps three and four for subsequent boot loader stages until the entire secure boot flow is complete.

In the case of the secure boot sequence implemented in a Rambus Root of Trust, the first stage of the secure boot loader is stored in ROM and referred to as “fBoot” (first boot). This code validates and executes the next stage of the secure boot flow—and provides support for manufacturing and testing. The subsequent stage of the secure boot loader is “sBoot” (second boot) and is typically loaded into local, write-once non-volatile storage during an enrollment phase. This code typically handles any device-specific actions required to validate and enable execution for the next stage of the secure boot flow. Next up “tBoot,” which refers to the following stage of the secure boot loader, is typically stored in remote mass storage and enables the loading, verification, and execution of subsequent secure boot loader stages.

It goes without saying, any secure boot process needs to rely on fast but solid cryptographic concepts and robust implementation on top of a “trust anchor.” At a minimum, a set of so-called P-256 or P-521-based Elliptic Curve Digital Signature verification is required, that verifies against an on-chip private key. Additional protection can be provided by robust image decryption before loading and verifying. Note that preferably the Root of Trust handles securely booting both itself as well as securely booting the Host system in the SoC.

The multi-stage secure boot flow enabled in a Rambus Root of Trust is flexible and can accommodate boot loader sequences that vary in complexity. For example, sBoot isn’t necessary if a device or platform initialization (or configuration) isn’t required. Or sBoot and tBoot can be combined into one phase. Similarly, sBoot and tBoot aren’t needed if the entire secure boot loader can reside in local ROM storage. In addition, the secure boot flow mechanisms will need to be extended with secure firmware update capabilities, which is a story for another time.

To illustrate these concepts in practice, here are four methods of how a Root of Trust can secure a system’s boot sequence in descending order of robustness:

• Root of Trust secure boot followed by host system boot: The Root of Trust boots while the host system is held in reset. Upon completion, the host system is released from reset and the Root of Trust validates each signed boot stage for system execution. This boot sequence offers the most robust security, as each stage is digitally signed and verified before execution by either the Root of Trust or the system.
• Partial host system boot followed by Root of Trust secure boot (and remainder of system boot): The system executes a portion of the system boot flow, which typically covers POST and the configuration of relevant system resources. The system boot flow is held at this point while the Root of Trust executes its own secure boot. Following this step, system boot flow resumes, with the Root of Trust validating the remaining system boot loader stages until system boot is complete. To ensure a robust level of security, the number of system boot loader stages executed prior to Root of Trust secure boot and subsequent secure system boot is kept to a minimum.
• Partial system boot followed by partial Root of Trust secure boot (and remainder of secure boot & system boot in parallel): This results in a somewhat faster overall system boot flow with elements of the system and Root of Trust boot flows execute in parallel. The security of this configuration depends on the number of system boot stages executed prior to activation of the Root of Trust, as well as the type of checks that are performed prior to completion of the secure boot flow.
• System boot followed by Root of Trust secure boot: The system boots while the Root of Trust is held in reset. Following system booth, the Root of Trust is released from reset and executes its secure boot flow. The security of this configuration is the least robust, as the Root of Trust can only validate the current state of the device and any images present in the device.

With the growing number and severity of threats, system designers should carefully evaluate the threat model for their system. Based on this analysis, the method of secure boot employing a Root of Trust can be selected. Rambus has over thirty years of security experience and the broadest line of Root of Trust solutions available in the industry. We can help you select the right Root of Trust, whatever your application, and the secure boot method that best fits your security needs.

Additional Resources:

• Website: Rambus Root of Trust Solutions
• Blog: Hardware Root of Trust: Everything you need to know
• Webinar: Will the Real Root of Trust Please Stand Up?