BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

3.3 Roots of Trust and Chains of Trust

NIST platform security: roots of trust, firmware and secure enclaves SP 800-193
All changes in this version
first version loaded 3 Principles and Key Concepts part of 3

Title

Roots of Trust and Chains of Trust

Control

The security mechanisms described in this document are founded in Roots of Trust (RoT). A Root of Trust is an element that forms the basis of providing one or more security-specific functions, such as measurement, storage, reporting, recovery, verification, and update. A RoT must be designed to always behave in the expected manner because its proper functioning is essential to providing its security-specific functions and because its misbehavior cannot be detected. A RoT is typically just the first element in a Chain of Trust (CoT) and can serve as an anchor in such a chain to deliver more complex functionality. The responsibilities and capabilities of a RoT may be implemented entirely within the RoT or may be performed by a delegate or agent spawned by its RoT via a chain of trust anchored in the RoT. For example, a RoT for recovery (RTRec), when triggered, will initiate a recovery process by launching another element that determines an appropriate recovery sequence and launches a chain of successive elements that perform the recovery actions. Figure 2 provides a high-level description of how trust chains are established from an initial RoT.

Generally, successive elements are cooperative in maintaining the chain of trust started by the RoT. Components in a chain of trust are privileged to perform security critical functions like performing device updates that are not available to less trusted software. RoTs and CoTs may have mechanisms to relinquish these privileges once the security function is complete, or if it is determined that the security function is not required. A CoT may also relinquish privileges before passing control to a non-cooperative element. Figure 2: Roots of Trust

Because RoTs are essential to providing critical security functions, they need to be secure by design. Major considerations for determining confidence in RoTs are an analysis of the attack surface of a RoT and an evaluation of the mitigations used to protect that attack surface. The responsibility of ensuring the trustworthiness of a RoT is on the vendor which provides the Root of Trust. Vendors typically protect RoTs by either making them immutable, or by ensuring that the integrity and authenticity of any changes to RoTs are verified prior to performing such updates. Often, RoTs run in isolated environments, at greater privilege level than anything which could modify it, and/or complete their function before anything can modify it to ensure that other devices cannot compromise their behavior during operation.

Section 4.1 of this document provides specific guidelines on the capabilities and properties of the RoT that support platform resiliency.

Platforms are often composed of numerous devices, often with isolation boundaries between devices and different manufacturers. A platform may need multiple independent RoTs and CoTs to provide comprehensive coverage for resiliency. For example, a hard disk controller may have a separate microcontroller and firmware than the host platform. Both the hard disk controller and the host platform may need their own independent chain of trust for recovery if their individual critical data become corrupted.