4.4.2 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 availability of trusted, known-good backup copies of critical data. These backup copies may be stored on the device itself or by some other host device. Because these backups may also be vulnerable to attack, these guidelines specify that devices also provide a means to restore to known-good factory defaults.

1) Mechanisms to recover critical data shall resist attacks which corrupt the active critical data or the Primary Firmware Image, or subvert their protection mechanisms. 2) The device should provide a method to backup a known good copy (or copies) of the active critical data to another location or locations. The protections on those locations shall be at least as good as that for the active critical data. The protections should be better than those for the active critical data. a) A symbiont device that cannot backup its own critical data should make its critical data available to its host device. In this case, the host device shall backup the symbiont’s data. b) If a symbiont provides its critical data to a host device so the host device may backup the data, then the symbiont should be able to consume the recovered critical data. 3) The device may determine that its critical data is “known good” by using that data as part of a successful reboot. 4) The device shall backup the critical data either automatically or when instructed by the user or when instructed to do so by another trusted device. 5) The RTRec or CTRec shall be capable of recovering critical data to factory defaults. 6) The RTRec or CTRec should be capable of recovering to last known good critical data. 7) A device shall not use policies stored as critical data by that device to recover its own critical data. However, a symbiont may rely on policies which are provided by a host device. 8) If multiple back-ups are available, the RTRec or CTRec may allow a choice of which back up to use. 9) If detection of corruption of critical data is automatic, the RTRec or CTRec may gain approval from a host device or the user before replacing the current critical data. 10) In the absence of the RTD or CTD triggering recovery actions, the platform administrator should be able to initiate recovery of critical data. Devices should provide a method for Platform Administrators to force recovery. Devices which receive authorized requests to force recovery may then instruct other devices with which there are established trust relationships to force recovery, either directly or through chains of trusted devices. While it is outside the scope of this document to define what constitutes an appropriate state for a platform to recover to (other than a state of integrity), examples include any of the following:

• Recover to a last known good state
• Reset to factory defaults
• Update to the newest firmware image
• Perform a partial ‘repair’ operation
• Recover to an enterprise-defined ‘starting point’
• Any combination of the above

Note that recovery processes may require multiple stages before normal operation is restored. For example, devices may initially restore factory-default configuration data prior to recovering last-known-good configuration data.

When considering how to determine which of the above states of integrity to recover a device to, using a policy-based approach necessitates the use of critical data in order to store/maintain those policies. However, if that critical data becomes corrupted, then the recovery process may either not be able to happen or it may happen incorrectly. As such, vendors should carefully consider the algorithm used to recover. As an example, a straightforward mechanism might be the use of a simple Most Recently Used (MRU) algorithm, e.g., the algorithm might first try to recover to the last known good state; if that data is not valid, then it might next try recovering to a prior saved state; if that is not available, then it might try recovering from a remote enterprise storage location; if that is not available, then it might try resetting to factory defaults. Using an algorithmic approach in this manner eliminates the need to rely on critical data being in a state of integrity during the recovery operation. Appendix A—Acronyms

Selected acronyms and abbreviations used in this paper are defined below.

BIOS Basic Input/Output System

CoT Chain of Trust

CPLD Complex Programmable Logic Device

CTD Chain of Trust for Detection

CTRec Chain of Trust for Recovery

CTU Chain of Trust for Update

FPGA Field-Programmable Gate Array

ROM Read Only Memory

RoT Root of Trust

RTD Root of Trust for Detection

RTRec Root of Trust for Recovery

RTU Root of Trust for Update

UEFI Unified Extensible Firmware Interface Appendix B—Glossary

Active Critical Data The copy of critical data that is used to initialize or configure a device. Note: active critical data does not include back-ups of critical data.

Add-in Card A generic term used to refer to any device which can be inserted or removed from a platform through a connection bus, such as PCI. Add-in cards are typically inserted within a platform’s physical enclosure, rather than residing physically external to a platform. An add-in card will have its own devices and associated firmware, and may have its own Expansion ROM Firmware.

Authenticated Update An update which uses an authenticated update mechanism.

Authenticated Update Mechanism An update mechanism which ensures that an update firmware image has been digitally signed and that the digital signature can be verified using one of the keys in the key store of the Root of Trust for Update (RTU) before updating the firmware image.

Authorized Update An update which uses an authorized update mechanism.

Authorized Update Mechanism An update mechanism that checks for approval before installation of an update. Approval could consist of checking possession of a credential, confirmation by a physically present person or similar means.

Boot Firmware Generic term to describe any firmware on a platform executed to boot (start-up, initialize) a device. This may include, but is not limited to, initialization of device memory, initialization of device registers, initialization of connectivity interfaces, health checks of the device, etc. The general purpose of boot firmware is to prepare a device or platform for normal operational use.

Chain of Trust (CoT) A Chain of Trust (CoT) is a sequence of cooperative elements which are anchored in a Root of Trust (RoT) that extend the trust boundary of the current element by conveying the same trust properties to the next element when it passes it control. The result is both elements are equally able to fulfill the trusted function as though they were a single trusted element. This process can be continued, further extending the chain of trust. Once control is passed to code which is not, or cannot be, verified then the Chain of Trust has ended. This is also referred to as passing control to a non-cooperative element.

Code Instructions directly executed by a processor or like device (FPGA, CPLD, etc.). Also included are instructions that are interpreted by a program. Source code is the human-readable instructions that are translated into code and then executed. Corruption Corruption is a loss of integrity of firmware code, or an error or unexpected value in critical data, which could be the result of any one of a number of different causes, including but not limited to, malicious activity (e.g. an attacker), poorly written code (e.g. buffer overflows, algorithmic error), accidental events (e.g. inadvertent user action), failure to install a security patch, unauthorized changes, or hardware-induced (e.g. signal integrity, alpha particles, power failures).

Critical Data Critical data is mutable data which persists across power cycles and must be in a valid state that has been authorized by the Platform Administrator in order for the recovery and/or booting of the platform to securely and correctly proceed.

Critical Platform Firmware The collection of all Platform Firmware that either (a) performs the functions of protection, detection, recovery and update of any Platform Firmware, (b) maintains the security of Critical Data or (c) implements interfaces for Critical Data that are non-bypassable.

Device A generic term used to refer to any computing or storage element or collection of computing or storage elements on a platform. Examples of devices include a central processing unit (CPU), applications processing unit (APU), embedded controller (EC), baseboard management controller (BMC), Trusted Platform Module (TPM), graphics processing unit (GPU), network interface controller (NIC), hard disk drive (HDD), solid state drive (SSD), Read Only Memory (ROM), flash ROM, etc.

Device Firmware The collection of non-host processor firmware and Expansion ROM firmware that is only used by a specific device. This firmware is typically provided by the device manufacturer.

Expansion ROM Firmware Peripheral Component Interconnect (PCI) term for firmware executed on a host processor which is used by an add-in device during the boot process. This includes Option ROM Firmware, UEFI applications, and UEFI drivers. Expansion ROM Firmware may be bundled as part of the Host Processor Boot Firmware, or may be separate (e.g., from an add-in card). In this document, we will use the term Expansion ROM Firmware when referring to either Option ROM Firmware or UEFI Drivers and Applications generically.

Firmware Generic term to describe any code stored in a chip that either resides at the reset vector (or equivalent) of the corresponding processor or which is provided as extensions to other firmware (such as Expansion ROM Firmware). General purpose operating systems that are stored in chips are generally not considered firmware in the scope of this document.

Host Device A device that assists a symbiont device to establish the roots and chains of trust required to meet the protection, detection, and/or recovery guidelines in this document. The allocation of functionality between the host and symbiont devices is implementation dependent. The Host Device must, itself, meet the guidelines for its own firmware on its own. Note that this should not be confused with a Host Processor. A Host Processor may serve as a Host Device, but a Host Device is not necessarily a Host Processor.

Host Processor A host processor is the primary processing unit in a platform, traditionally called a Central Processing Unit (CPU), now also sometimes referred to as an Application Processing Unit (APU), or a System on Chip (SoC). This is the processing unit on which the primary operating system (and/or hypervisor), as well as user applications run. This is the processor that is responsible for loading and executing the Host Processor Boot Firmware.

Host Processor Boot Firmware Generic term used to describe firmware loaded and executed by the Host Processor which provides basic boot capabilities for a platform. This class of firmware includes Legacy BIOS, System BIOS and UEFI, as well as other implementations. Where the distinction between Legacy BIOS and UEFI is not important, the term Host Processor Boot Firmware will be used. Where the distinction is important, it will be referenced accordingly. Expansion ROM firmware may also be considered as part of the Host Processor Boot Firmware. Expansion ROM Firmware may be embedded as part of the Host Processor Boot Firmware, or may be separate from the Host Processor Boot Firmware (e.g., loaded from an add-in card). Host Processor Boot Firmware includes firmware which may be available during runtime.

Immutable Unchangeable. In the context of this document, this refers only to the inability to make changes in the field through manufacturer intended mechanisms and/or defined interfaces. Note that a platform or device manufacturer may still be able to make changes through manufacturing or service tools directly connected to a locally (physically) present platform or device.

Legacy BIOS (Basic Input/Output System) One form of Host Processor Boot Firmware used on x86 platforms which uses a legacy x86 BIOS structure. This form of host processor boot firmware has been or is being replaced by UEFI.

Mutable Changeable. In the context of this document, this refers only to the ability to make changes in the field through manufacturer intended mechanisms and/or defined interfaces. Such mechanisms may require cryptographic mechanisms or unambiguous physical presence.

Non-critical Data Non-critical data is mutable data which persists across power cycles but is not critical to the booting, operating, or recovery of the device.

Non-Host Processor A non-host processor is a generic term used to describe any processing unit on a platform which is not a host processor (e.g. a microcontroller, co-processor, etc.).

Non-Host Processor Firmware Non-host processor firmware is a generic term used to describe firmware used by any processing unit on a platform which is not a host processor.

Option ROM Firmware Legacy term for boot firmware typically executed on a host processor which is used by a device during the boot process. Option ROM firmware may be included with the host processor boot firmware or may be carried separately by a device (such as an add-in card).

Peripheral (aka external device) A peripheral (also known as an external device) is a device which resides physically external to a platform and is connected to a platform, either wired or wirelessly. A peripheral is comprised of its own devices which may have their own firmware. While conceptually the principles and guidelines in this document could apply equally to peripherals, they are outside the scope of this document.

Platform A platform is comprised of one or more devices assembled and working together to deliver a specific computing function, but does not include any other software other than the firmware as part of the devices in the platform. Examples of platforms include a notebook, a desktop, a server, a network switch, a blade, etc.

Platform Administrator Privilege Privileges required to manage the firmware and critical data on platform devices. In particular, this privilege may be needed to authorize firmware updates, change firmware configuration settings, and firmware recovery operations.

Platform Administrator An entity with Platform Administrator Privileges.

Platform Firmware The collection of all device firmware on a platform. In this document, the term Platform Firmware may be used when making references to the collection of all firmware used by devices on a platform. Primary Firmware Image The executable code stored on the device. Different parts of the primary firmware image may be protected differently.

Read Only Memory (ROM) A memory device that once it has been initially set, cannot be overwritten through any mechanism, making that memory immutable (unchangeable).

Resilient The capability of a system with specific characteristics before, during and after a disruption to absorb the disruption, recover to an acceptable level of performance, and sustain that level for an acceptable period of time.

Root of Trust (RoT) An element that forms the basis of providing one or more security- specific functions, such as measurement, storage, reporting, recovery, verification, update, etc. A RoT is trusted to always behave in the expected manner because its misbehavior cannot be detected and because its proper functioning is essential to providing its security-specific functions.

Runtime Firmware Generic term to describe any firmware on a platform active/functional or available for use during runtime (after boot has completed).

Software Software is comprised of elements required to load the operating system, the operating system, and all user applications and user data subsequently handled by the operating system. Refer to Figure 1 for a graphical depiction.

Symbiont Device A symbiont device is a device that relies wholly or partially on another device (a host device) to establish the roots and chains of trust required to meet the protection, detection, and recovery guidelines in this document. The allocation of functionality between host device and symbiont device is implementation dependent. For example, the host device verifies updates and backs up critical data while the symbiont device is responsible for meeting all other guidelines. The symbiont property can be transitive: A device may be a symbiont device to a host device while the two may then serve as the host to another symbiont device and so on.

System A system is the entirety of a computing entity, including all elements in a platform (hardware, firmware) and software (operating system, user applications, user data). A system can be thought of both as a logical construct (e.g. a software stack) or physical construct (e.g. a notebook, a desktop, a server, a network switch, etc.). Refer to Figure 1 for a graphical depiction. UEFI (Unified Extensible Firmware Interface) One form of Host Processor Boot Firmware which uses a Unified Extensible Firmware Interface (UEFI) structure (as defined by the UEFI Forum).

UEFI Drivers Standalone binary executables which are loaded during the boot process to handle specific pieces of hardware.

Unambiguous Physical Presence Indicates authorization by a local person that cannot be impersonated by malware. Appendix C—References

[1] D. Cooper, W. Polk, A. Regenscheid, and M. Souppaya, BIOS Protection Guidelines, NIST Special Publication (SP) 800-147, National Institute of Standards and Technology, Gaithersburg, Maryland, April 2011, 26pp. https://doi.org/10.6028/NIST.SP.800-147

[2] A. Regenscheid., BIOS Protection Guidelines for Servers, NIST Special Publication (SP) 800-147B, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2014, 32pp. https://doi.org/10.6028/NIST.SP.800-147B

[3] Specifications, Unified Extensible Firmware Interface Forum [Web site], http://www.uefi.org/specifications [accessed 5/2/18]

[4] TPM Library Specification, Trusted Computing Group [Web site], https://trustedcomputinggroup.org/tpm-library-specification/ [accessed 5/2/18]

[5] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels , RFC 2119, Internet Engineering Task Force, March 1997, 2pp, https://doi.org/10.17487/RFC2119

[6] U.S. Department of Commerce. Secure Hash Standard , Federal Information Processing Standards (FIPS) Publication 180-4, August 2015, 36pp. https://doi.org/10.6028/NIST.FIPS.180-4

[7] U.S. Department of Commerce. Digital Signature Standard , Federal Information Processing Standards (FIPS) Publication 186-4, July 2013, 130pp. https://doi.org/10.6028/NIST.FIPS.186-4

[8] E. Barker, Recommendation for Key Management, Part 1: General, NIST Special Publication (SP) 800-57 Part 1 Revision 4, National Institute of Standards and Technology, Gaithersburg, Maryland, January 2016, 160pp. https://doi.org/10.6028/NIST.SP.800-57pt1r4

[9] E. Barker, Recommendation for Obtaining Assurances for Digital Signature Applications, NIST Special Publication (SP) 800-89, National Institute of Standards and Technology, Gaithersburg, Maryland, November 2006, 38pp. https://doi.org/10.6028/NIST.SP.800-89

[10] International Council for Systems Engineering, “Resilient Systems Working Group Charter,” November 2011.

[11] R. Ross, R. Graubart, D. Bodeau, and R. McQuaid, Systems Security Engineering: Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems , NIST Special Publication 800-160 Volume 2 (DRAFT), National Institute of Standards and Technology, Gaithersburg, Maryland, March 2018, 158pp. https://csrc.nist.gov/CSRC/media/Publications/sp/800-160/vol- 2/draft/documents/sp800-160-vol2-draft.pdf

`4.4.2` Recovery of Critical Data

Title

Control