NIST platform security: roots of trust, firmware and secure enclaves SP 800-193
All1 Introduction2 Platform Architecture3 Principles and Key Concepts4 Firmware Security Guidelines for Platform Devices
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Introduction | ||
| 1.1 in 1 |
Purpose | Modern computing and information technology systems are built upon a variety of hardware components that provide the fundamental capabilities required by the system to operate. Many of these hardware components have firmware and configurati | |
| 1.2 in 1 |
Audience | The intended audience for this document includes system and platform device vendors of computer systems, including manufacturers of clients, servers and networking devices. The technical guidelines assume readers have expertise in the platf | |
| 1.3 in 1 |
Applicability and Scope | The goal of this document is to provide principles and guidelines that can support platform resiliency primarily against remote attacks. These principles and guidelines directly apply to the individual devices that make up a platform (see S | |
| 1.4 in 1 |
Document Structure | The remainder of this document is organized into the following major sections: • Section 2 provides informative material describing platform components and architectures. • Section 3 describes the security principles that form the basis for | |
| 2 | Platform Architecture | Ensuring a platform’s firmware code and critical data are always in a state of integrity is critical to ensure that a computing system can be operated free from malware. Modern client and server computing systems can be considered to be sep | |
| 2.1 in 2 |
Platform Devices | As noted above, the platform is a collection of devices that provide the functional capabilities and services needed by the operating system and applications. While resiliency of the platform as a whole is the ultimate objective, it is impo | |
| 2.2 in 2 |
Code and Data in Platform Devices | The devices described above will typically contain some set of firmware and data on nonvolatile storage, either resident on the device itself or on a shared storage device (e.g., the SPI flash). This section describes firmware code and data | |
| 2.2.1 in 2.2 |
Code | Firmware code is the set of instructions used by any device’s processing unit to perform the operations required by the device. Historically, firmware in platform devices has rarely been modified in the field, although system or component v | |
| 2.2.2 in 2.2 |
Data | Data are pieces of information that Platform Firmware code uses to carry out its operation, as instructed by the code. Data can be further categorized as critical and non-critical. Critical data includes configuration settings and policies | |
| 2.2.2.1 in 2.2.2 |
Critical Data | Critical data may be used for various purposes, including: • Configuration settings: Data which tells the code how to configure operational aspects of the device Example: Enabling a peripheral that is disallowed by enterprise security polic | |
| 2.2.2.2 in 2.2.2 |
Non-Critical Data | Non-critical data may be used for various purposes, including: • Informational / UI: Data which is merely informational or used as part of a user interface (UI) for the end user Example: An asset tag name of “Property of NIST” is displayed | |
| 3 | Principles and Key Concepts | This section provides a brief description of the driving principles for platform resiliency which provide the foundation for the guidelines in this document. It also discusses major architectural concepts and considerations used throughout | |
| 3.1 in 3 |
Principles Supporting Platform Resiliency | The security guidelines in this document are based on the following three principles: • Protection: Mechanisms for ensuring that Platform Firmware code and critical data remain in a state of integrity and are protected from corruption, suc | |
| 3.2 in 3 |
Resiliency Properties | The technical guidelines in this document are written in terms of guidelines for individual platform devices in order to make them broadly applicable to a variety of devices, platforms and systems. Despite the narrow focus on devices, the i | |
| 3.3 in 3 |
Roots of Trust and Chains of Trust | 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, recove | |
| 3.4 in 3 |
Device Relationships | Due to lack of capability or functionality, some platform devices may not have their own root(s) of trust to perform an update, detection, or recovery. We refer to devices needing assistance as symbiont devices and those lending assistance | |
| 3.5 in 3 |
Firmware Update Mechanisms | A central tenet to the firmware protection guidelines is ensuring that only authentic and authorized firmware update images may be applied to platform devices. An update image is authentic if the source (e.g., the device, system manufacture | |
| 3.5.1 in 3.5 |
Authenticated Update Mechanism | An authenticated update mechanism employs digital signatures to ensure the authenticity of the firmware update image. An update of the firmware image using an authenticated update mechanism relies on a Root of Trust for Update (RTU) that co | |
| 3.5.2 in 3.5 |
Authorized Update Mechanism | A system and its supporting management software and firmware may provide several authorized mechanisms for legitimately updating a firmware image. These include: 1) User-Initiated Updates : Vendors typically supply end users with utilities | |
| 3.5.3 in 3.5 |
Secure Local Update | While this document recommends firmware updates be done through an authenticated update mechanism as described in Section 3.5.1 , some devices may also support a secure local update mechanism. These mechanisms instead authorize firmware upd | |
| 3.6 in 3 |
Other Considerations for Platform Resiliency | This document does not address certain other considerations that a purchaser, user, or IT administrator may take into account pertaining to platform cyber resiliency. A non-exhaustive list and discussion of these other considerations follow | |
| 3.6.1 in 3.6 |
Management | Vendors should carefully consider their target customers when designing resilient platforms to ensure proper management and control of policies and configuration settings can be administered in the way which best serve customer needs. Manag | |
| 3.6.2 in 3.6 |
Authorization Mechanisms | Some recovery and administrative actions can make significant changes to either the Platform Firmware or software. For example, firmware settings may control the boot order, and a software recovery agent may restore a backup erasing recentl | |
| 3.6.3 in 3.6 |
Network-Assisted vs. Local Recovery | In most cases, the ability to recover locally from corruption will be the most expedient, provide the highest level of customer satisfaction, and may be necessary if there is no network connectivity. But it is recognized that this is not al | |
| 3.6.4 in 3.6 |
Automated vs. Manual Recovery | Recovery can proceed in one of three ways: | |
| 3.6.5 in 3.6 |
Event Logging | Logging firmware and recovery-related events can often be useful for multiple purposes, including but not limited to: • Forensic analysis which allows for a Platform Administrator of a system to capture information which might have led to | |
| 4 | Firmware Security Guidelines for Platform Devices | This section details the technical security guidelines for devices in a platform for each of the three elements of resiliency: protection, detection, and recovery. Devices may implement the requirements in one or more of these sections base | |
| 4.1 in 4 |
Roots of Trust | 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 componen | |
| 4.1.1 in 4.1 |
Roots of Trust (RoT) and Chains of Trust (CoT) | 1) The security mechanisms shall be founded in Roots of Trust (RoT). 2) If Chains of Trust (CoT) are used, a RoT shall serve as the anchor for the CoT. 3) All RoTs and CoTs shall either be immutable or protected using mechanisms which ensur | |
| 4.1.2 in 4.1 |
Root of Trust for Update (RTU) and Chain of Trust for Update (CTU) | 1) Each platform device with mutable firmware shall rely on either a Root of Trust for Update (RTU), or a Chain of Trust for Update (CTU) which is anchored by an RTU, to authenticate firmware updates. 2) If the RTU or CTU is mutable, then t | |
| 4.1.3 in 4.1 |
Root of Trust for Detection (RTD) and Chain of Trust for Detection (CTD) | 1) Each platform device which implements a detection capability shall rely on either a Root of Trust for Detection (RTD), or a Chain of Trust for Detection (CTD) which is anchored by an RTD, for its detection. 2) The RTD or CTD shall includ | |
| 4.1.4 in 4.1 |
Root of Trust for Recovery (RTRec) and Chain of Trust for Recovery (CTRec) | 1) Each platform device which implements a recovery capability shall rely on either a Root of Trust for Recovery (RTRec), or a Chain of Trust for Recovery (CTRec) which is anchored by an RTRec, for its recovery. 2) The RTRec or the CTRec sh | |
| 4.2 in 4 |
Protection | While previous efforts have addressed protection of BIOS (e.g., NIST SP 800-147 [1] , NIST SP 800-147B [2] ), there remains other security-critical firmware in the platform that has not been addressed. This includes firmware resident in man | |
| 4.2.1 in 4.2 |
Protection and Update of Mutable Code | This section specifies guidelines for firmware protection based on the principles of authenticated firmware updates, integrity protection, and non-bypassability of security mechanisms. Authenticated update mechanisms use digital signatures | |
| 4.2.1.1 in 4.2.1 |
Authenticated Update Mechanism | One or more authenticated update mechanisms anchored in the RTU shall be the exclusive means for updating device firmware, absent unambiguous physical presence through a secure local update, as defined in Section 3.5.3 . Authenticated updat | |
| 4.2.1.2 in 4.2.1 |
Integrity Protection | To prevent unintended or malicious modification of the firmware, nonvolatile storage regions containing device firmware need to be protected from such modifications outside of an authorized update mechanism. 1) The flash regions that conta | |
| 4.2.1.3 in 4.2.1 |
Non-Bypassability | The principle of non-bypassability is that it should not be possible for an attacker to modify device firmware outside of the authenticated update mechanism or, if supported, a secure local update. Any intended or unintended mechanisms capa | |
| 4.2.2 in 4.2 |
Protection of Immutable Code | Code could be stored in field non-upgradable memory, such as Read Only Memory (ROM). While the protections for this type of storage are strong, the trade-off is the inability to update the code to fix bugs and patch vulnerabilities. Manufac | |
| 4.2.3 in 4.2 |
Runtime Protection of Critical Platform Firmware | To satisfy the principle of non-bypassability described in Section 4.2.1.3 , it is important that software or bus-mastering hardware under the control of software not be capable of interfering with the intended function of Critical Platform | |
| 4.2.4 in 4.2 |
Protection of Critical Data | Unauthorized changes to critical data stored and used by devices could also seriously impact the security posture of a device. Such changes could modify or disable important security-relevant functions provided by the platform, or prevent t | |
| 4.3 in 4 |
Detection | The detection guidelines in this section describe mechanisms which can detect unauthorized changes to device firmware and critical data before it is executed or consumed by the device. When unauthorized changes are detected, a device could | |
| 4.3.1 in 4.3 |
Detection of Corrupted Code | Execution of unauthorized or corrupted firmware on a device could damage the device, inject malware in the system, or otherwise impact the security functions and capacities of a device or encompassing system. The following guidelines descri | |
| 4.3.2 in 4.3 |
Detection of Corrupted Critical Data | This section describes mechanisms to detect invalid or corrupted critical data in platform devices. As noted above, invalid critical data could render a device inoperable or disable certain critical security functionality. Verifying critica | |
| 4.4 in 4 |
Recovery | This section describes mechanisms for restoring platform firmware and critical data to a valid and authorized state in the event that any such firmware or critical data are detected to have been corrupted, or when an administrator initiates | |
| 4.4.1 in 4.4 |
Recovery of Mutable Code | The firmware recovery guidelines in this section specify mechanisms to recover firmware to a locally-stored backup or to a recovery image downloaded from another source. In either case, these guidelines specify using an Authenticated Update | |
| 4.4.2 in 4.4 |
Recovery of Critical Data | This section describes mechanisms to recover critical data in platform devices in the event that the device or administrator has reason to believe it has been corrupted. Because critical data can be user-configurable, recovery requires the |
47 of 47.