[RFC][ROM_EXT] ROM_EXT Hierarchical Delegate Signing Scheme
- 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
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