Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation

Description

This vulnerability occurs when a hardware component saves its configuration state during a power-down operation but fails to protect or verify the integrity of that saved data before restoring it. As a result, an attacker can tamper with the stored settings, leading to a compromised state when the device powers back on.

Extended Description

To optimize boot time, hardware Intellectual Property (IP) often saves its current operational state—like security settings or privilege levels—to persistent storage (e.g., flash memory) before entering a low-power mode. However, if this saved state isn't cryptographically protected or validated, an attacker with access to the storage can alter it. This manipulation could disable security features, escalate privileges, or force the hardware into a damaging configuration. When the device restores from this tampered state after power-up, it blindly loads the corrupted configuration, activating the attacker's changes. This bypasses normal hardware security checks, potentially leading to persistent compromise, system damage, or a complete loss of security controls. The core issue is the lack of integrity checking (like using signatures or checksums) between the save and restore operations.

Common Consequences 1

Scope: ConfidentialityIntegrity

Impact: DoS: InstabilityDoS: Crash, Exit, or RestartDoS: Resource Consumption (Other)Gain Privileges or Assume IdentityBypass Protection MechanismAlter Execution LogicQuality DegradationUnexpected StateReduce MaintainabilityReduce PerformanceReduce Reliability

Potential Mitigations 3

Phase: Architecture and Design

Inside the IP, incorporate integrity checking on the configuration state via a cryptographic hash. The hash can be protected inside the IP such as by storing it in internal registers which never lose power. Before powering down, the IP performs a hash of the configuration and saves it in these persistent registers. Upon restore, the IP performs a hash of the saved configuration and compares it with the saved hash. If they do not match, then the IP should not trust the configuration.

Phase: Integration

Outside the IP, incorporate integrity checking of the configuration state via a trusted agent. Before powering down, the trusted agent performs a hash of the configuration and saves the hash in persistent storage. Upon restore, the IP requests the trusted agent validate its current configuration. If the configuration hash is invalid, then the IP should not trust the configuration.

Phase: Integration

Outside the IP, incorporate a protected environment that prevents undetected modification of the configuration state by untrusted agents. Before powering down, a trusted agent saves the IP's configuration state in this protected location that only it is privileged to. Upon restore, the trusted agent loads the saved state into the IP.

Demonstrative Examples 1

The following pseudo code demonstrates the power save/restore workflow which may lead to weakness through a lack of validation of the config state after restore.

Code Example:

Bad

void save_config_state() {

The following pseudo-code is the proper workflow for the integrity checking mitigation:

Code Example:

Good

void save_config_state() {

It must be noted that in the previous example of good pseudo code, the memory (where the hash of the config state is stored) must be trustworthy while the hardware is between the power save and restore states.