A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.

A System-on-Chip (SoC) implements secure boot by verifying or authenticating signed boot code. The signing of the code is achieved by an entity that the SoC trusts. Before executing the boot code, the SoC verifies that the code or the public key with which the code has been signed has not been tampered with. The other data upon which the SoC depends are system-hardware settings in fuses such as whether "Secure Boot is enabled". These data play a crucial role in establishing a Root of Trust (RoT) to execute secure-boot flows.

One of the many ways RoT is achieved is by storing the code and data in memory or fuses. This memory should be immutable, i.e., once the RoT is programmed/provisioned in memory, that memory should be locked and prevented from further programming or writes. If the memory contents (i.e., RoT) are mutable, then an adversary can modify the RoT to execute their choice of code, resulting in a compromised secure boot.

Note that, for components like ROM, secure patching/update features should be supported to allow authenticated and authorized updates in the field.

Modes Of Introduction

Architecture and Design
Implementation : Such issues could be introduced during policy definition, hardware architecture, design, manufacturing, and/or provisioning. They can be identified later during testing or system configuration phases.

Applicable Platforms

Language

Class: Not Language-Specific (Undetermined)

Operating Systems

Class: Not OS-Specific (Undetermined)

Architectures

Class: Not Architecture-Specific (Undetermined)

Technologies

Name: Security Hardware (Undetermined)
Class: Not Technology-Specific (Undetermined)

Common Consequences

Potential Mitigations

Phases : Architecture and Design
When architecting the system, the RoT should be designated for storage in a memory that does not allow further programming/writes.
Phases : Implementation
During implementation and test, the RoT memory location should be demonstrated to not allow further programming/writes.

Detection Methods

Automated Dynamic Analysis

Automated testing can verify that RoT components are immutable.
Effectiveness : High

Architecture or Design Review

Root of trust elements and memory should be part of architecture and design reviews.
Effectiveness : High

Vulnerability Mapping Notes

Rationale : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Related Attack Patterns

References

REF-1152

TCG Roots of Trust Specification
Trusted Computing Group.
https://trustedcomputinggroup.org/wp-content/uploads/TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf

REF-1153

Root of Trust Definitions and Requirements
GlobalPlatform Security Task Force.
https://globalplatform.org/wp-content/uploads/2018/06/GP_RoT_Definitions_and_Requirements_v1.0.1_PublicRelease_CC.pdf

REF-1348

bootrom.sv
https://github.com/HACK-EVENT/hackatdac19/blob/619e9fb0ef32ee1e01ad76b8732a156572c65700/bootrom/bootrom.sv#L263C19-L263C19

REF-1349

bootrom.sv
https://github.com/HACK-EVENT/hackatdac19/blob/ba6abf58586b2bf4401e9f4d46e3f084c664ff88/bootrom/bootrom.sv#L259C9-L259C9

Submission

Modifications