Building Hardware Root of Trust
A Hardware Root of Trust (HRoT) is the foundation of system security, providing an immutable anchor from which all trust chains originate. Unlike software-only security, HRoT cannot be modified or bypassed through software attacks, making it essential for secure boot, key storage, and cryptographic operations in modern SoCs.
Hardware Root of Trust Functions
- Secure Boot: Verify firmware integrity before execution
- Key Storage: Protect cryptographic keys from extraction
- Attestation: Prove device identity and integrity
- Secure Storage: Encrypt sensitive data at rest
- Random Number Generation: Provide entropy for cryptography
- Tamper Detection: Respond to physical attacks
Root of Trust Architecture
Core Components
Hardware Root of Trust Block Diagram: ┌─────────────────────────────────────────────────────────┐ │ Host Interface (APB/AXI) │ ├─────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Crypto │ │ Key │ │ Secure │ │ │ │ Engine │ │ Storage │ │ Boot │ │ │ │ AES/SHA/PKI │ │ OTP/eFuse │ │ Manager │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ TRNG │ │ Tamper │ │ Lifecycle │ │ │ │ (Entropy) │ │ Detection │ │ Manager │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Secure Processing Core │ │ │ │ (Isolated execution environment) │ │ │ └─────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘
Immutable ROM
The first code executed must be immutable:
- Mask ROM or one-time programmable memory
- Cannot be modified post-fabrication
- Contains initial boot code and signature verification
- Minimal attack surface (small, verified code)
Key Storage Options
| Storage Type | Programmable | Security | Use Case |
|---|---|---|---|
| eFuse | One-time | High | Root keys, device ID |
| OTP (Anti-fuse) | One-time | Very High | Master secrets |
| PUF | Not stored | Very High | Device-unique keys |
| Secure SRAM | Volatile | Medium | Runtime keys |
| Battery-backed | Writable | Medium | Counters, state |
Secure Boot Chain
Boot Process
Secure Boot Chain:
┌──────────────────┐
│ HRoT ROM │ ← Immutable, hardware root
│ (Stage 0) │
└────────┬─────────┘
│ Verify signature
▼
┌──────────────────┐
│ Boot ROM │ ← First-stage bootloader
│ (Stage 1) │
└────────┬─────────┘
│ Verify signature
▼
┌──────────────────┐
│ Bootloader │ ← U-Boot, etc.
│ (Stage 2) │
└────────┬─────────┘
│ Verify signature
▼
┌──────────────────┐
│ OS Kernel │ ← Linux, RTOS
│ (Stage 3) │
└────────┬─────────┘
│ Verify signature
▼
┌──────────────────┐
│ Application │ ← User applications
│ (Stage 4) │
└──────────────────┘
Signature Verification
Each boot stage verifies the next:
- Hash Calculation: SHA-256/384/512 of firmware image
- Signature Check: RSA/ECDSA verification with public key
- Public Key Verification: Compare against OTP-stored hash
- Anti-Rollback: Check version counter in OTP
Implementation Example
Secure Boot Verification Logic
// Simplified secure boot state machine typedef enum { BOOT_RESET, BOOT_HASH_IMAGE, BOOT_VERIFY_SIG, BOOT_CHECK_VERSION, BOOT_SUCCESS, BOOT_FAIL } boot_state_t; always_ff @(posedge clk) begin case (state) BOOT_RESET: begin sha_start <= 1; state <= BOOT_HASH_IMAGE; end BOOT_HASH_IMAGE: begin if (sha_done) begin rsa_start <= 1; state <= BOOT_VERIFY_SIG; end end BOOT_VERIFY_SIG: begin if (rsa_done) begin if (rsa_valid) state <= BOOT_CHECK_VERSION; else state <= BOOT_FAIL; end end BOOT_CHECK_VERSION: begin if (image_version >= otp_version) state <= BOOT_SUCCESS; else state <= BOOT_FAIL; // Anti-rollback end endcase end
Device Lifecycle Management
Lifecycle States
Secure devices have defined lifecycle states:
- Manufacturing: Debug enabled, no secrets provisioned
- Provisioning: Key injection, personalization
- Deployed: Normal secure operation
- End of Life: Keys zeroized, device disabled
Device Lifecycle State Machine:
┌─────────────┐
│MANUFACTURING│ ← Debug enabled, test mode
└──────┬──────┘
│ Provision keys
▼
┌─────────────┐
│ PROVISIONED │ ← Keys loaded, not activated
└──────┬──────┘
│ Final configuration
▼
┌─────────────┐
│ DEPLOYED │ ← Normal secure operation
└──────┬──────┘
│ Security event / EOL
▼
┌─────────────┐
│ REVOKED │ ← Keys destroyed, disabled
└─────────────┘
Note: Transitions are one-way (irreversible)
Debug Authentication
Secure debug access requires authentication:
- Challenge-response with device-specific key
- Debug certificate signed by manufacturer
- Can be permanently disabled in deployed state
Tamper Detection and Response
Tamper Sources
- Voltage Glitching: Power supply manipulation
- Clock Glitching: Frequency manipulation
- Temperature: Extreme hot/cold attacks
- Light/Laser: Fault injection via photons
- Physical Probing: Direct signal access
Detection Mechanisms
- Voltage monitors (high/low)
- Frequency monitors
- Temperature sensors
- Light detectors
- Active mesh shields
- Memory integrity checks
Response Actions
- Zeroize sensitive keys immediately
- Reset to secure state
- Log tamper event (if possible)
- Permanent disable (fuse blow)
Industry Standards
TPM (Trusted Platform Module)
TCG specification for PC security:
- Cryptographic key generation and storage
- Platform Configuration Registers (PCRs)
- Remote attestation support
- Sealed storage (bound to platform state)
ARM TrustZone
Hardware isolation for secure execution:
- Secure and Non-secure worlds
- Memory and peripheral partitioning
- Secure monitor for world switching
DICE (Device Identifier Composition Engine)
TCG standard for IoT device identity:
- Unique Device Secret (UDS) in hardware
- Compound Device Identifier (CDI) derivation
- Layered key derivation per boot stage
Conclusion
A well-designed Hardware Root of Trust is essential for modern secure systems. By combining immutable boot code, secure key storage, cryptographic engines, and tamper detection, HRoT provides the foundation for secure boot, attestation, and data protection that cannot be compromised by software attacks.
Vcores provides customizable Hardware Root of Trust IP supporting secure boot, key management, lifecycle control, and tamper response. Our HRoT solutions are designed for Common Criteria and FIPS 140-3 certification requirements.
