lowRISC / lowRISC/opentitan

[RFC][ROM_EXT] ROM_EXT Hierarchical Delegate Signing Scheme

Open
#31,254 1 comment 0 reactions 0 assignees View on GitHub
RFC:Proposal Security: SW Guidance SW:ROM_EXT Type:Enhancement
Dominant language
SystemVerilog
Stars
3.6k
Forks
1.1k
Avg merge
2d 22h
Merged PRs (30d)
141

Description

### Summary & Motivation
Under the current OpenTitan secure boot architecture, verifying the BL0 boot stage requires signing firmware directly with the Silicon Owner Root Key stored in Flash Info. This single-key model forces Silicon Owners to expose their primary Root of Trust to daily automated CI/CD pipelines, high-churn engineering sprints, and third-party developers, making key rotation a high-stakes and operationally disruptive event.
This RFC proposes a hierarchical **Delegate Signing Scheme for ROM_EXT** that establishes a cryptographically verified chain of custody between the offline Silicon Owner Root Key and target BL0 images.
### Key Architectural Highlights
* **Unified Manifest TLV Extension**: Standardizes on a single, lightweight certificate structure (`manifest_ext_delegation_cert_t` / `DLGC`) featuring an immutable, cryptographically signed `cert_type` field (`kCertTypeIntermediate` vs. `kCertTypeLeaf`).
* **Flexible 0 / 1 / 2 Delegation Topologies**:
* **Direct Boot (0 delegates)**: Full backward compatibility for existing images with zero storage or latency overhead.
* **Single Delegation (1 delegate)**: Root Key signs a Leaf Key, isolating the master key from daily build systems.
* **Two-Tier Delegation (2 delegates)**: Bounded intermediate delegation (`Root -> Intermediate -> Leaf -> BL0`) allowing sub-teams or lab administrators to autonomously issue device-locked or sprint-scoped keys without accessing the offline Root Key.
* **Hardened Policy Containment**: Enforces a strict "stricter-only" containment check (`check_delegation_containment`) ensuring subordinate delegates cannot expand security version ceilings, execution slots, lifecycle states, device IDs, or operational flags beyond their parent.
* **Anti-Rollback Emergency Revocation**: Leverages existing monotonic OTP anti-rollback counters to revoke compromised delegate keys fleet-wide by incrementing the firmware version floor, completely avoiding OTP key fuse exhaustion.
* **SPHINCS+ Hybrid Post-Quantum Support**: Decouples PQC signatures into an optional extension (`manifest_ext_delegation_cert_spx_t` / `DLGS`), maintaining quantum resistance without imposing memory or latency penalties on ECDSA-only builds.
* **Deterministic & Bounded Resource Footprint**: Verification is strictly sequential to eliminate TOCTOU race conditions, adding only ~6 ms (1 delegate) to ~9 ms (2 delegates) on OTBN, ~2.0 KB of ROM_EXT code.
### Document
* **Full detailed RFC Document**: [Google Doc Link](https://docs.google.com/document/d/1HpPxQVoHLuBaDWzmYw50U1dvqOPa0tSNa9agZ5bNXiM)

Looking for feedback and reviews, Thanks

Contributor guide

Open the contributing guide

Research direction

Start with the linked Google Doc, then compare its proposed DLGC and DLGS structures and containment rules with the existing ROM_EXT secure-boot design. The issue requests feedback and reviews but names no implementation files, tests, or acceptance criteria, so no concrete completion target is specified.

Written by the indexing model from the issue text.

Assessment

Domain
cryptography, embedded-iot, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.