Mutable Attestation or Measurement Reporting Data

Incomplete Base
Structure: Simple
Description

This vulnerability occurs when the hardware registers storing boot integrity measurements can be altered by an attacker, allowing them to forge verification data and hide a compromised boot process.

Extended Description

In secure boot implementations, a System-on-Chip (SoC) typically verifies and measures each piece of code it loads during startup. This measurement is created by calculating a cryptographic hash of the code and combining it with previous measurements, building a verifiable chain of trust. The final hash value, stored in dedicated hardware registers, should provide an unforgeable record of everything that executed. However, if these measurement registers are not properly protected, they become the weak link in the chain. When an adversary can directly modify these register contents, they can replace the legitimate measurement with a fake value that matches their malicious code. This allows them to spoof attestation reports and verification checks, making a compromised device appear trustworthy. The core issue is that the hardware provides mutable storage for what should be immutable evidence, breaking the fundamental security guarantee of measured boot.

Common Consequences 1
Scope: Confidentiality

Impact: Read MemoryRead Application Data

Potential Mitigations 1
Phase: Architecture and Design
Measurement data should be stored in registers that are read-only or otherwise have access controls that prevent modification by an untrusted agent.
Demonstrative Examples 1
The SoC extends the hash and stores the results in registers. Without protection, an adversary can write their chosen hash values to these registers. Thus, the attacker controls the reported results.
To prevent the above scenario, the registers should have one or more of the following properties: - Should be Read-Only with respect to an adversary - Cannot be extended or modifiable either directly or indirectly (using a trusted agent as proxy) by an adversary - Should have appropriate access controls or protections
References 2
BIOS Chronomancy: Fixing the Core Root of Trust for Measurement
John Butterworth, Cory Kallenberg, and Xeno Kovah
31-07-2013
ID: REF-1131
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Not Technology-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Related Attack Patterns
Related Weaknesses
Notes
MaintenanceThis entry is still in development and will continue to see updates and content improvements.