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.2 The Chain of Trust (CoT)

NIST platform security: roots of trust, firmware and secure enclaves IR 8320
All changes in this version
first version loaded 3 Platform Integrity Verification part of 3

Title

The Chain of Trust (CoT)

Control

The chain of trust (CoT) is a method for maintaining valid trust boundaries by applying a principle of transitive trust. Each firmware module in the system boot process is required to measure the next module before transitioning control. Once a firmware module measurement is made, it is recommended to immediately extend the measurement value to a root of trust for storage, such as an HSM register, for attestation at a later point in time [6] . The CoT can be extended further into the application domain, allowing for files, directories, devices, peripherals, etc. to be measured and attested.

Every CoT starts with an RoT module. It can be composed of different hardware and firmware components. For several platform integrity technologies, the RoT core firmware module is rooted in immutable read-only memory (ROM) code. However, not all technologies define their RoTs in this manner [6] . The RoT is typically separated into components that verify and measure. The core RoT for verification (CRTV) is responsible for verifying the first component before control is passed to it. The core RoT for measurement (CRTM) is the first component that is executed in the CoT and extends the first measurement to the TPM. The CRTM can be divided into a static portion (SCRTM) and dynamic portion (DCRTM). The SCRTM is composed of elements that measure firmware at system boot time, creating an unchanging set of measurements that will remain consistent across reboots except for volatile attributes like date and time. The DCRTM allows a CoT to be established without rebooting the system, permitting the RoT for measurement to be reestablished dynamically.

An RoT that is built with hardware protections will be more difficult to change, while an RoT that is built solely in firmware can be flashed and modified. An immutable hardware RoT possesses the risk of not being able to be patched. The goal should be to keep the RoT as small as possible. In the context of this publication, firmware is a specific class of computer software that provides the low-level control for a device’s specific hardware.

Various platform integrity technologies build their own CoTs. Please refer to the following technology examples in the appendices for more information:

• UEFI Secure Boot (SB)

• Intel Trusted Execution Technology (TXT)

• Intel Boot Guard

• Intel Platform Firmware Resilience (PFR)

• Intel Technology Example Summary

• AMD Platform Secure Boot (AMD PSB)

• Arm TrustZone Trusted Execution Environment (TEE) for Armv8-A

• Arm Secure Boot and the Chain of Trust (CoT)

• Cisco Platform Roots of Trust

• IBM Chain of Trust (CoT)