Propose hybrid (LMS + ECDSA) signing for FMC and Runtime

[jhand2]

One goal of Caliptra is to provide a firmware signing scheme for defending against attacks from quantum computers. Currently, only stateful PQC signing algorithms are approved by NIST. Caliptra has chosen to use LMS for firmware signing. Caliptra also supports ECDSA P-384 signing schemes. We need to decide which of these verification schemes will be used in which cases.

Proposal

I propose that Caliptra should support multiple possible modes of signature verification.

Why

• Maintaining LMS signing infrastructure is new for most of the industry and is a bit non-trivial to get right (requires carefully managing state to avoid leaking key material).
• Leaking key material probably means a respin
• Adding an ECDSA signature is pretty trivial and mitigates the risk quite a bit. In a pre-PQC world, leaking the XMSS key isn't the end of the world since we have an ECDSA backstop. I think this would be prudent for v1 (and we can discuss simplifying in future versions once we're confident everything works well).

Key Manifest Changes

The key manifest may contain all of

• Up to 4 ECDSA manufacturer public keys
• Up to 4 LMS manufacturer public keys

Assuming P-384 ECDSA keys and SHA384 LMS keys, at most, this adds 192 bytes compared to only-ECDSA or only-LMS.

This manifest is:

• Hashed and stored in fuses
• Included in every firmware image header (and compared to the value in fuses)

Firmware image changes

A firmware image header may contain all of

• Manufacturer ECDSA signature
• Manufacturer LMS signature
• Owner ECDSA public key
• Owner ECDSA signature
• Owner LMS public key
• Owner LMS signature

In this case, LMS signatures are much larger than ECC signatures. The overhead of including both (instead of just LMS) is minimal.

Modes

Which signatures are enforced by ROM needs to be configurable because LMS signers may not be ready until after tape-out. A public key in can be included in the fused manifest, but LMS signatures may not be available to sign images until some later time.

Note: If a manufacturer ever wants to support hybrid signing, both the ECDSA and LMS public keys must be present in the fused manifest at tape-out.

I propose a single configuration fuse bit:

If fuse is 0, use Mode 1 If fuse is 1, use Mode 2

Notably, once Caliptra is fused to do LMS verification, it cannot be fused to stop doing LMS.

Mode 1: ECDSA-only

• ROM only enforces the manufacturer ECDSA signature
• FMC only enforces the Owner ECDSA signature

Mode 2: Hybrid signing

• ROM enforces both the manufacturer LMS signature and manufacturer ECDSA signature
• FMC enforces both the Owner LMS signature and Owner ECDSA signature

[Bryankel]

Maybe 2 fuse bits are required. I think you need a mode 3, LMS-only.

In a device where boot time is critical, you'll probably want 1 signature. It is not sufficient to choose ECDSA, as the vendor might want to CNSA 2.0 compliant.

I think at most 3 modes need to be supported. ECDSA, LMS, both.

Making the positive polarity the stronger strength to be more restrictive.

[jhand2]

I originally had 2 fuse bits, but we discussed in the call that folks were concerned about having complicated state transitions.

The feedback from the group was that cycles required for LMS verification would be significantly higher than ECDSA, so the difference in still doing ECDSA would be negligible. Eric recommended we get some timing numbers to be more sure about this.

But if we can settle on a configuration we're all happy with that supports 3 modes, I would also be cool with that. Here's the proposal I originally had:

Bit 0	Bit 1	Mode
0	0	Mode 1
1	0	Mode 2
1	1	Mode 3

This allows the following progressions:

• Mode 1 -> Mode 2: Switch from ECDSA to LMS
• Mode {1, 2} -> Mode 3: Hybrid signing

Notably, once Caliptra is fused to do LMS verification, it cannot be fused to stop doing LMS

Mode 1: ECDSA-only

• ROM only enforces the manufacturer ECDSA signature
• FMC only enforces the Owner ECDSA signature

Mode 2: LMS-only

• ROM only enforces the manufacturer LMS signature
• FMC only enforces the Owner LMS signature

Mode 3: Hybrid signing

• ROM enforces both the manufacturer LMS signature and manufacturer ECDSA signature
• FMC enforces both the Owner LMS signature and Owner ECDSA signature

[varuns-nvidia]

I think the next step here is to quantify the performance impact and then decide whether Mode 2 support is a requirement. @ericeilertson is gathering performance numbers.

[ericeilertson]

A simulation was run using a test vector from RFC8554. The parameters for this were run were SHA256, W=8, and H=5. This took 66,293,662 cycles. If we assume 450 Mhz, these parameters mean 147 milliseconds to verify.

The proposed hash algorithm for Caliptra is SHA256/192 which would reduce the amount of work by 25%. Using a w=4 would reduce the number of hashes by 8x.

If we assume those two scaling factors this would imply 6.2 million cycles to verify. At 450 Mhz, this would be 13.8 milliseconds.

This was a first run to get an order of magnitude for runtime. Vishal Soni and I have identified a few ways to improve the efficiency of the code generated. I hope to get these changes in and a run with the proposed parameters early next week.

[varuns-nvidia]

With regard to timing requirements, our assumptions are that the only Caliptra 1.0 integrating devices with hard firmware boot KPIs are PCIe/CXL endpoint devices. These devices face the following requirements:

• From power-good to PERST# deactivation (Fundamental Reset), the minimum time period defined by the Card Electro-Mechanical specification is 100 milliseconds (Tpvperl).
• From Fundamental Reset de-assertion, the minimum time period for the Upstream Port to enter the Link Training and Status State Machine (LTSSM) Detect state is 100 milliseconds for devices obeying Gen5 base specifications (see Relaxed Detect ECN) and supporting greater than 5.0GT/s link speeds, or 20 milliseconds for other devices.

What does this mean: Devices may require firmware to enter the Detect state. Because that firmware's measurements must be captured by Caliptra, Caliptra is in the critical path for PCIe link up from a Fundamental Reset. The relevant Caliptra critical path is boot from power-good reset, since the Caliptra warm reset boot flow does not authenticate firmware or derive keys.

A PCIe/CXL endpoint integrating Caliptra may choose to map Caliptra's power-good reset to either power-good detection or to PCIe Cold Reset (Fundamental Reset following the application of power). If mapping to power-good, then the device has 100+100 or 100+20 milliseconds to enter Detect state depending on its max link speed. If mapping to PCIe Cold Reset, then the Tpvperl window does not apply and so the critical path is reduced to 100 or 20 milliseconds.

The worst case integration then is 20 milliseconds to boot Caliptra and PCIe link training firmware, and the best case integration is 200+ milliseconds.

The Caliptra spec says the the following for scope and priorities:

The silicon iRoT scope includes all datacenter-focused server class SoC / ASIC (datacenter focused) devices (SSD - DC, NIC, CPU, GPU - DC):

Critical priority are devices with the ability to handle user plain text data
    Top priority are CPU SoCs
    Other examples include SmartNIC and accelerators
Over time scope includes further data center devices
    SSD, HDD, BMC, DIMM

For Caliptra 1.0, trying to solve for the worst case boot KPI while anticipating a quantum apocalypse is not the best use of our resources. Let's keep it simple (just Mode 1 + Mode 3) and strive to improve PQC authentication time in future Caliptra versions.

CC @bharatpillilli

[varuns-nvidia]

@jhand2 , my understanding is that ROM evaluates both Vendor and Owner signatures. Is that not the case?

[jhand2]

@varuns-nvidia I'm not sure. I don't currently see anything in the spec says who is responsible for verifying the owner signature, so we'll probably want to write that down either way (I'm not strongly opinionated about who verifies the owner signature).

[bluegate010]

The PoR is yes, ROM evaluates both sigs, as ROM mixes the owner pub key hash into the FMC alias key + cert.

[vsonims]

ROM will do Manufacturer + Owner verification of firmware header. That is the current POR.