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

4.1 Roots of Trust

NIST platform security: roots of trust, firmware and secure enclaves SP 800-193
All changes in this version
first version loaded 4 Firmware Security Guidelines for Platform Devices part of 4

Title

Roots of Trust

Control

This section provides foundational guidelines on the Roots of Trust (RoT) and Chains of Trust (CoT) that support the subsequent guidelines for Protection, Detection, and Recovery. These guidelines are organized based on the logical component responsible for each of those security properties:

• The Root of Trust for Update (RTU) is responsible for authenticating firmware updates and critical data changes to support platform protection capabilities.
• The Root of Trust for Detection (RTD) is responsible for firmware and critical data corruption detection capabilities.
• The Root of Trust for Recovery (RTRec) is responsible for recovery of firmware and critical data when corruption is detected, or when instructed by an administrator.

Note that these are logical components which need not be distinct. In many cases, RoTs will be part of low-level platform firmware, and will share many components with one another. Furthermore, while each RoT is responsible for the functions necessary to support a given resiliency property, in most cases it will not implement all of those functions within the RoT itself. As described in Section 3.3 , most of those functions will be implemented in a CoT anchored in the RoT. The RoT is the inherently trusted component within that chain, and extends trust to other components in a secure manner.