NIST platform security: roots of trust, firmware and secure enclaves SP 800-147B
All1 Introduction2 Background3 BIOS Security Principles4 Security Guidelines by Update Mechanism5 The RTU ensures that the BIOS flash memory is locked prior to transferring control to code
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Introduction | ||
| 1.1 in 1 |
Purpose and Scope | This document provides guidelines for BIOS protections in server-class systems. It is the second in a series of publications on BIOS protections. The first document, SP800-147, BIOS Protection Guidelines , was released in April 2011 and pro | |
| 1.2 in 1 |
Audience | The intended audience for this document includes BIOS and platform vendors of server-class systems, and information system security professionals who are responsible for managing the servers’ security. The material may also be of use when d | |
| 1.3 in 1 |
Document Structure | The remainder of this document is organized into the following major sections: Section 2 presents an overview of the BIOS, describes server architectures and update mechanisms, identifies potential threats to BIOS in servers, and explain | |
| 2 | Background | This section provides background information on the system BIOS and types of server architectures. It identifies the primary methods used for updating the system BIOS, and it also discusses security issues and threats to the system BIOS. Fi | |
| 2.1 in 2 |
System BIOS | Exclusive of certain configuration and security code that may be embedded into a platform’s silicon components, e.g., processor, the system BIOS is the first software executed on the main central processing unit (CPU) when a computer is pow | |
| 2.2 in 2 |
Server Architectures | In this subsection, we differentiate servers into three classes: Basic Servers, Managed Servers, and Blade Servers. The distinctions made here have to do with the mechanisms employed to update the system BIOS. A Basic Server is architectura | |
| 2.3 in 2 |
System BIOS Update Mechanisms | The guidelines in this publication are intended to secure BIOS update mechanisms so that only authentic, authorized BIOS images are written to BIOS flash memory, a process sometimes referred to as “flashing” the image. While client systems | |
| 2.4 in 2 |
Threats to the System BIOS | A server is susceptible to the same forms of attack that threaten a client system. Execution of operating system-level malware on servers could precede a BIOS attack. Server BIOS updates that are executed without being authenticated as comi | |
| 2.5 in 2 |
Root of Trust for Update | A Root of Trust for Update (RTU) is an inherently trusted combination of hardware and firmware that performs a secure update of the BIOS and maintains the integrity of the BIOS. The RTU may comprise functionality for verifying digitally sig | |
| 3 | BIOS Security Principles | The security principles presented in NIST SP 800-147 for client systems—update authentication, flash region integrity, and non-bypassability—apply directly to server class machines. These security principles are intended to mitigate threats | |
| 3.1 in 3 |
BIOS Update Authentication | Authenticated BIOS update mechanisms shall be implemented in an RTU (see Section 2.5). These mechanisms employ digital signatures to ensure the authenticity and integrity of BIOS update images. The Verification Component of the RTU shall co | |
| 3.2 in 3 |
Secure Local Update | Servers may optionally include a secure local update mechanism that updates the system BIOS without using the authenticated update mechanism. Secure local update mechanisms shall authorize and authenticate the BIOS update image by requiring | |
| 3.3 in 3 |
Firmware Integrity Protection | To prevent the execution of inauthentic or malicious BIOS code, the integrity of the system BIOS shall be maintained between the verification of the system BIOS by the RTU and the execution of the system BIOS during the boot process. To pr | |
| 3.4 in 3 |
Non-Bypassability | The design of the system and accompanying system components and firmware shall ensure that there are no mechanisms to install and execute unauthenticated BIOS code, except through physical intervention and the secure local update mechanism. | |
| 4 | Security Guidelines by Update Mechanism | The following provides detailed recommendations for implementing the security guidelines in this document for three typical secure BIOS update mechanisms. A server may implement one or more of these mechanisms, and the method(s) implemented | |
| 4.1 in 4 |
Update Mechanism 1: Secure BIOS Update at Anytime | With this BIOS update mechanism, the secure update of the BIOS flash memory may occur during numerous operating states of the server. This includes being able to update the BIOS flash while the server operates, without requiring a reboot. W | |
| 5 | The RTU ensures that the BIOS flash memory is locked prior to transferring control to code | outside the RTU (e.g., Option ROMs), per the Firmware Integrity Protection requirements in Section 3.3. See Appendix B for an example of this update mechanism. 4.2 Update Mechanism 2: Secure BIOS Update at Reboot With this BIOS update mec | |
| 5.1 in 5 |
Service Processor as a Root of Trust | Service Processors in managed and blade servers might have the ability to directly update the BIOS flash memory, the BIOS execution memory, or their own flash or other storage media. In these cases, some or all of the Service Processor envi | |
| 5.2 in 5 |
Non-Bypassability of BIOS Protections by Service Processor | Some servers with Service Processors might not employ the Service Processor as an RTU for BIOS updates. To ensure the SP environment cannot bypass BIOS protections, Service Processors in these systems shall not have direct write access to t |
20 of 20.