[RFC][Caliptra 2.0] Proposed DICE design for Caliptra 2.0

[jhand2]

Note: This is a proposal. Please add comments for any proposed modifications.

Algorithms

Caliptra 2.0 will support the following signing algorithms

• ECDSA P-384
• ML-DSA-87

Configuration Registers

Caliptra 2.0 will support two modes for generating DICE certificates:

• ECDSA-P-384 & ML-DSA-87 Hybrid
• ECDSA-P-384 only

The DICE mode must be selected prior to ROM boot (prior to asserting FUSE_WR_DONE or BOOTFSM_GO if BootFSM_BrkPoint is high).

This register should be part of soc_ifc and be pregrammable by the SoC on every cold boot. The value cannot be changed on warm/update reset.

ECDSA-P-384 & ML-DSA-87 Hybrid

Caliptra will emit composite signatures as defined in draft-ietf-lamps-pq-composite-sigs. This document is approved by the IETF LAMPS workgroup and is expected to be published as an RFC.

• Public key encoding: subjectPublicKey BIT STRING = (ML-DSA pubkey || ECDSA pubkey)
• Signature encoding: signaureValue OCTET STRING = (ML-DSA signature || ECDSA signature)
• Algorithm Identifier: id-MLDSA87-ECDSA-P384-SHA512 (OID 2.16.840.1.114027.80.8.1.11)
  • Note: This OID is a placeholder in the spec. It will be replaced with the final RFC is published.

ECDSA P-384 only

This will produce the same DICE chain as Caliptra 1.0.

IDevID CSR Manufacturing Flow

Caliptra 2.0 will expose a new bit in the DBG_MANUF_SERVICE register: MFG_FLAG_GEN_IDEV_CSR_HYBRID. If this bit is set, Caliptra ROM will produce a composite IDevID CSR.

This may be set at the same time as MFG_FLAG_GEN_IDEV_CSR. If both are set, Caliptra ROM will output both CSRs to the mailbox.

The mailbox response will have the following format

Field	Type	Notes
CSR Count	u32	Number of CSRs returned
Hybrid CSR Offset	u32	Offset of the Hybrid CSR. If Hybrid CSR Size is 0, ignore
Hybrid CSR Size	u32	Size of the Hybrid CSR.
ECDSA CSR Offset	u32	Offset of the ECDSA CSR. If ECDSA CSR Size is 0, ignore
ECDSA CSR Size	u32	Size of the ECDSA CSR.
Data	u8[...]	CSRs to be returned

TODO: Instead of this we could also return PEM-encoding, or something else. Open to suggestion.

ML-DSA structures and algorithm identifiers

X.509 structures for ML-DSA signatures and keys will ultimately be described in draft-ietf-lamps-dilithium-certificates. Currently this document is a draft, and some things are not yet specified:

• Assign OIDs for ML-DSA algorithmIdentifiers: Marked as TODO in the document
  • Caliptra 2.0 ROM only uses ML-DSA in hybrid mode. The defined Composite OID will be used
• ML-DSA Signature Encodings: Not explicitly specified, but expected to align with FIPS 204
  • For the signatureValue field, Caliptra 2.0 ROM will encode signatures as an octet string containing the output of FIPS 204 sigEncode
• ML-DSA public key encodings: Specified in 4
  • Caliptra 2.0 ROM will implement these encodings

Caliptra 2.0 ROM will be updated when the final version of this RFC is released. This is expected well before first Caliptra 2.0 tapeout.

ML-DSA signing scheme: pre-hashing

The ML-DSA peripheral will require inputs to be pre-hashed. We will use SHA512 to pre-hash certificates before ML-DSA signing. See FIPS 204 section 7.1 for details. The IETF document for composite signatures explicitly requires pre-hashing.

In hybrid mode, SHA512 will be used for pre-hashing the certificate for both ECDSA and ML-DSA

In ECDSA-only mode, ECDSA signing will still use SHA384 for pre-hashing.

TODO: We could just always use SHA512 and change the ECDSA AlgorithmID to ecdsa-with-SHA512 with secp384r1.

Certificate Layers & Measurements

There are no changes from Caliptra 1.0 to certificate layers or the measurements that go into those layers. The layers will continue to be:

• IDevID (self-signed PKCS#10 CSR)
• LDevID (X.509)
• FMC Alias (X.509)
• RT Alias (X.509)
• DPE-produced Certificates (X.509)