lowRISC / lowRISC/opentitan

[RFC][ROM] Integrating FIPS 140-3 Known Answer Tests into OpenTitan Mask ROM

Open
#31,255 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

FIPS RFC:Proposal SW:ROM Type:Enhancement
Dominant language
SystemVerilog
Stars
3.6k
Forks
1.1k
Avg merge
2d 22h
Merged PRs (30d)
141

Description

Description

Summary

To achieve FIPS 140-3 validation, OpenTitan must execute cryptographic algorithm self-tests (CASTs / KATs) at startup. With the introduction of Post-Quantum Cryptography (ML-DSA, ML-KEM, SPHINCS+) and large classical keys (RSA-4096), raw test vectors require over 41 KB of storage. Storing these static vectors in Embedded Flash (eFlash) consumes scarce and expensive flash memory across multiple firmware slots.

We propose offloading static test vectors to the expanded 128 KB Mask ROM, organizing them into a dedicated, position-independent section while delegating test execution to higher boot stages (ROM_EXT / BL0). This change also prepares for potential ROM/ROM_EXT FIPS certification since this data is accessible from ROM, ROM_EXT and BL) stages.

📄 Full RFC Document: Google Doc: Integrating FIPS KATs in OpenTitan ROM

Feedback and review welcome

Key Highlights

  1. Passive ROM Storage with Delegated Execution:
    • ROM serves strictly as immutable data storage; execution is handled by otcrypto in BL0 (or ROM_EXT in future certified flows), avoiding driver bloat and low-clock execution in ROM.
  2. Dedicated .fips_kat Section & Fixed Pointer:
    • All vectors and a descriptor table reside in a contiguous .fips_kat section.
    • A 4-byte pointer slot at a fixed offset (_rom_chip_info_start - 4) allows runtime discovery without compile-time coupling.
    • Isolating the section enables fast FIPS 140-3 module integrity hashing (hashing only the ~12 KB KAT region instead of the entire 128 KB ROM).
  3. Storage Optimizations (~71% Size Reduction):
    • Single Vector Policy & Parameter Reuse: Base vectors shared across cipher modes with zero-length payload markers.
    • Deterministic Keygen & Output Hashing: Large RSA/ECC outputs replaced with 32-byte reference digests.
    • PQC In-RAM Loops:
      • ML-DSA-87: 5 NIST ACVP Table 1 seed-based test cases covering all rejection sampling branches ($z$, $r_0$, $h$) in 480 bytes.
      • ML-KEM-1024: Dynamic KeyGen-Encaps-Decaps loop in 128 bytes.
    • Result: Total footprint compressed from ~41.5 KB down to ~11.9 KB (~9.3% of the 128 KB Mask ROM).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the linked RFC, then trace how OpenTitan builds the 128 KB Mask ROM and exposes data to ROM_EXT and BL0. Identify the integration points for the position-independent .fips_kat section and its fixed pointer at _rom_chip_info_start - 4. Done means the design is accepted and the KAT storage, discovery, and handoff behavior are specified well enough for implementation and validation.

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.