logo

Missing Immutable Root of Trust in Hardware

Draft Base
Structure: Simple
Description

This vulnerability occurs when a hardware chip lacks a permanent, unchangeable root of trust. Without this immutable foundation, attackers can bypass secure boot protections and run unauthorized or malicious code during the system startup process.

Extended Description

Secure boot in a System-on-Chip (SoC) relies on verifying signed boot code using a trusted key. The chip must also check critical hardware settings, like a 'secure boot enabled' fuse. Together, this code and configuration data form the Root of Trust (RoT), which is the absolute starting point for all security. If an attacker can modify this RoT, they can compromise the entire boot chain. To prevent this, the RoT must be stored in immutable memory, such as locked fuses or one-time-programmable (OTP) memory, after initial provisioning. This ensures the foundational security data cannot be rewritten. It's important to distinguish this from components like ROM, which should support secure, authenticated update mechanisms for authorized patches in the field, while the core RoT itself remains permanently fixed.
Common Consequences 1
Scope: AuthenticationAuthorization

Impact: Gain Privileges or Assume IdentityExecute Unauthorized Code or CommandsModify Memory
Detection Methods 2
Automated Dynamic AnalysisHigh
Automated testing can verify that RoT components are immutable.
Architecture or Design ReviewHigh
Root of trust elements and memory should be part of architecture and design reviews.
Potential Mitigations 2
Phase: Architecture and Design
When architecting the system, the RoT should be designated for storage in a memory that does not allow further programming/writes.
Phase: Implementation
During implementation and test, the RoT memory location should be demonstrated to not allow further programming/writes.
Demonstrative Examples 2
The RoT is stored in memory. This memory can be modified by an adversary. For example, if an SoC implements "Secure Boot" by storing the boot code in an off-chip/on-chip flash, the contents of the flash can be modified by using a flash programmer. Similarly, if the boot code is stored in ROM (Read-Only Memory) but the public key or the hash of the public key (used to enable "Secure Boot") is stored in Flash or a memory that is susceptible to modifications or writes, the implementation is vulnerable.
In general, if the boot code, key materials and data that enable "Secure Boot" are all mutable, the implementation is vulnerable.
Good architecture defines RoT as immutable in hardware. One of the best ways to achieve immutability is to store boot code, public key or hash of the public key and other relevant data in Read-Only Memory (ROM) or One-Time Programmable (OTP) memory that prevents further programming or writes.
The example code below is a snippet from the bootrom of the HACK@DAC'19 buggy OpenPiton SoC [REF-1348]. The contents of the bootrom are critical in implementing the hardware root of trust.
It performs security-critical functions such as defining the system's device tree, validating the hardware cryptographic accelerators in the system, etc. Hence, write access to bootrom should be strictly limited to authorized users or removed completely so that bootrom is immutable. In this example (see the vulnerable code source), the boot instructions are stored in bootrom memory, mem. This memory can be read using the read address, addr_i, but write access should be restricted or removed.

Code Example:

Bad
Verilog
verilog

mem[addr_i[$clog2(RomSize)-1+3:3]] <= wdata_i;** end end end ...

verilog
The vulnerable code shows an insecure implementation of the bootrom where bootrom can be written directly by enabling write enable, we_i, and using write address, addr_i, and write data, wdata_i.
To mitigate this issue, remove the write access to bootrom memory. [REF-1349]

Code Example:

Good
Verilog
verilog

if (req_i) begin**

verilog
    
References 4
TCG Roots of Trust Specification
Trusted Computing Group
07-2018
https://trustedcomputinggroup.org/wp-content/uploads/TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf
ID: REF-1152
Root of Trust Definitions and Requirements
GlobalPlatform Security Task Force
03-2017
https://globalplatform.org/wp-content/uploads/2018/06/GP_RoT_Definitions_and_Requirements_v1.0.1_PublicRelease_CC.pdf
ID: REF-1153
bootrom.sv
2019
https://github.com/HACK-EVENT/hackatdac19/blob/619e9fb0ef32ee1e01ad76b8732a156572c65700/bootrom/bootrom.sv#L263C19-L263C19(2023-09-18)
ID: REF-1348
bootrom.sv
2019
https://github.com/HACK-EVENT/hackatdac19/blob/ba6abf58586b2bf4401e9f4d46e3f084c664ff88/bootrom/bootrom.sv#L259C9-L259C9(2023-09-18)
ID: REF-1349
 
  
    
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 Not Language-Specific : Undetermined 
 
 
Technologies:
 
 
 Security Hardware : UndeterminedNot Technology-Specific : Undetermined 
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Architecture and Design  
 
  Implementation  
 
 
 
  
Related Attack Patterns 
        
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Protection Mechanism Failure (CWE-693)