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.2 Detection of Corrupted Critical Data

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 Critical Data

Control

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 critical data is challenging, because data is often intended to be user-configurable. The guidelines in this section recommend either directly verifying critical data contents or implementing other mechanisms to look for symptoms of data corruption.

1) The RTD or CTD shall perform integrity checks on the critical data prior to use. Integrity checks may take the form, for example, of validating the data against known valid values or verifying the hash of the data storage. 2) Either as an alternative to integrity checks (for devices that cannot support such a capability) or in addition to those checks, the RTD or CTD may use watchdog timers to detect potential corruption of critical data. 3) If corruption of critical data is detected, the RTD or CTD shall be capable of starting a recovery process to restore the device’s critical data. 4) The detection mechanism should be capable of logging events when corruption is detected. 5) The RTD or CTD should be capable of creating notifications of corruption. 6) The RTD or CTD may be capable of forwarding notifications of corruption.