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.3.1 Detection of Corrupted 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.3

Title

Detection of Corrupted Code

Control

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 describe mechanisms to verify the integrity of firmware during the boot process using the Root of Trust for Detection (RTD), specified in Section 4.1.3 . While cryptographic integrity checks, either by the device itself or a host device, are preferred, some hardware device (e.g., FPGAs or CPLDs) may use other mechanisms to detect corruption in their code and programmable logic.

For these detection mechanisms to be effective, the design of the device needs to ensure that the RTD remains trustworthy in the event of a successful attack on the firmware itself.

1) A successful attack which corrupts the active critical data or the firmware image, or subverts their protection mechanisms, shall not in and of itself result in a successful attack on the RTD or the information necessary to detect corruption of the firmware image. 2) One or more of the following techniques shall be used by the RTD or CTD to validate firmware code: a) Integrity verification, using an approved digital signature algorithm or cryptographic hash, of device firmware code prior to execution of code outside the RTD. Note: Integrity verification could also be performed at runtime. These mechanisms may or may not be anchored in the RTD.

b) Symbiont devices may rely on a host device to perform detection. If the symbiont device boots independently from the host device, integrity verification of the symbiont’s device firmware shall be performed prior to execution of code outside the host CTD. In such cases, the following additional requirements apply: i) The symbiont’s firmware shall be protected according to the requirements in Section 4.2.1 . ii) The host device should be capable of immediately triggering a recovery of the symbiont’s firmware, followed by a restart of the device, in cases where corruption is detected. c) Certain hardware devices (e.g., FPGAs, CPLDs) may have field-upgradable logic rather than firmware code, often referred to as configuration bitstream. If these devices do not have the ability to support cryptographic verification or the ability to measure and report in conformance with a) or b), they shall use hardware-based mechanisms to detect device load failures. d) Other techniques (e.g., watchdog timers) may be used in combination with cryptographic integrity checks to detect other problems with the initialization process of platform devices. 3) If corruption is detected, the RTD or CTD should be capable of starting a recovery process to restore the device firmware code back to an authentic version. 4) The detection mechanism should be capable of creating notifications of corruption. 5) The detection mechanism should be capable of logging events when corruption is detected. 6) The detection mechanisms may be capable of using policies set by the Platform Administrator which define the actions taken by the RTD/CTD in the above guidelines.