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.4.1 Recovery of Mutable Code

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.4

Title

Recovery of Mutable Code

Control

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 Mechanism (Section 4.2.1.1 ) to verify the integrity and authenticity of the image prior to recovery.

1) Firmware recovery mechanisms shall resist attacks which corrupt the active critical data or the primary firmware image, or subverts their protection mechanisms. a) The RTRec, CTRec and authentic recovery firmware image should be protected independently of the running firmware. 2) The RTRec or CTRec shall be capable of obtaining an authentic device firmware image. a) If the authentic firmware image is stored locally in non-volatile memory, the image shall be protected from unauthorized modification. 3) Updates to a locally stored authentic firmware image shall be by way of an Authenticated Update Mechanism (Section 4.2.1.1 ) or a secure local update (Section 3.5.3 ). 4) Non-local recovery mechanisms shall use an Authenticated Update Mechanism (Section 4.2.1.1 ) to verify the integrity and authenticity of recovery images prior to restoring them. 5) If the authentic firmware image is stored remotely, the recovery policies shall be configurable with the location of this image. 6) If the device (a symbiont device ) relies upon another platform device (a host device ) to provide its RTRec or CTRec, then the host device’s RTRec or CTRec shall invoke the host/symbiont Authenticated Update Mechanism during recovery operations. 7) The device shall either implement its own recovery capability, or that device (a symbiont device ) and another platform device (a host device ) shall together implement the symbiont device’s recovery capability. 8) The recovery mechanism should be capable of logging and reporting events when recovery is performed. 9) The recovery mechanism should be capable of providing notifications of recovery events and actions. 10) The recovery mechanism may be capable of performing the recovery action without notification or intervention by the user or system administrator. 11) The recovery mechanism may request approval from the user or system administrator to perform a recovery action. 12) The platform administrator should be able to initiate recovery of mutable code. Devices should provide a method for Platform Administrators to force recovery. Devices may receive platform-level authorization to force recovery through a chain of one or more trusted devices, the first of which shall verify platform-level authorization prior to instructing downstream devices to recover. 13) The recovery process should protect against unauthorized recovery to an earlier firmware version that contains a security weakness. The overall recovery process should facilitate recovery to a recent firmware version. These may be implemented as a multi-stage recovery process.