Sensitive Information Uncleared Before Debug/Power State Transition

Stable Base
Structure: Simple
Description

This vulnerability occurs when a device changes its power mode or enters a debug state but fails to wipe sensitive data that should become inaccessible after the transition.

Extended Description

Devices cycle through various operational states—like active power, low-power, sleep, hibernate, or debug modes—as part of normal function. Each state has different security boundaries controlling what data is accessible. A security flaw arises when the system moves from a more permissive state (where sensitive data is present) to a more restricted one, but neglects to purge that data first. This leaves confidential information, such as encryption keys or user data, lingering in memory or registers where it shouldn't be reachable. For developers, this means sensitive data can leak across state boundaries if not explicitly cleared before a transition. Think of it as forgetting to shred confidential documents before locking them in a safe—the safe is secure, but the contents inside still pose a risk. To prevent this, you must implement explicit cleanup routines that wipe all sensitive information from temporary storage, caches, and buffers immediately before any power-state or debug-state change is finalized.

Common Consequences 1
Scope: ConfidentialityIntegrityAvailabilityAccess ControlAccountabilityAuthenticationAuthorizationNon-Repudiation

Impact: Read MemoryRead Application Data

Sensitive information may be used to unlock additional capabilities of the device and take advantage of hidden functionalities which could be used to compromise device security.

Detection Methods 1
Manual AnalysisHigh
Write a known pattern into each sensitive location. Enter the power/debug state in question. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the device needs to be fixed. Note that this test can likely be automated.
Potential Mitigations 1
Phase: Architecture and DesignImplementation
During state transitions, information not needed in the next state should be removed before the transition to the next state.
Demonstrative Examples 1

ID : DX-147

This example shows how an attacker can take advantage of an incorrect state transition.
Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in state B. The device reads the keys, performs operations using those keys, then transitions to state B, where those private keys should no longer be accessible.

Code Example:

Bad
Other

During the transition from A to B, the device does not scrub the memory.

After the transition to state B, even though the private keys are no longer accessible directly from the fuses in state B, they can be accessed indirectly by reading the memory that contains the private keys.

Code Example:

Good
Other

For transition from state A to state B, remove information which should not be available once the transition is complete.

Observed Examples 1
CVE-2020-12926Product software does not set a flag as per TPM specifications, thereby preventing a failed authorization attempt from being recorded after a loss of power.
References 1
Understanding the Security of ARM Debugging Features
Zhenyu Ning and Fengwei Zhang
2019 IEEE Symposium on Security and Privacy (SP)
22-05-2019
ID: REF-1220
Applicable Platforms
Languages:
VHDL : UndeterminedVerilog : UndeterminedHardware Description Language : Undetermined
Technologies:
Not Technology-Specific : Undetermined
Modes of Introduction
Architecture and Design
Functional Areas
  1. Power