Add CSR signing key

[bharatpillilli]

Request for enhancement: a new key that can be used to sign the IDevID CSR by the Caliptra BootROM. This would be an ECDSA-P384 private key that is input as "straps" to Caliptra (same as de-obfuscation key) and inserted as an ECO before SoC tapeout. The public portion would be provisioned on a frontend to the Vendor's HSM appliance. The Vendor's frontend would authenticate the IDevID CSR with the public key prior to certifying the IDevID with the HSM's Certificate Authority. This mitigates man-in-the-middle attacks between the Caliptra ROM and the HSM.

Corresponding integrator requirements:

SoC backend flows shall generate CSR signing key with appropriate NIST compliance as dictated in the Caliptra ROT specification. SoC backend flows shall ECO the CSR signing key before tapeout. SoC backend flows should rotate CSR signing key for each project? SoC backend flows should not insert CSR signing key flops into the scan chain.

[bharatpillilli]

Copying from private github -> https://github.com/Project-Caliptra/rtl-caliptra/issues/9

· Is the RTL change due to a Spec change? (Yes/No): Yes

· Is the Spec change approved? (Yes/No): Yes

· Is the spec updated? (Yes/No): Yes

· Is the change needed in Caliptra 0p8 or 1p0 milestone? (only P1 items will be discussed here): Up for debate

· Does it have silicon area impact? (Yes/No): Yes

· Does it have timing impact? (Yes/No): No

· If the change impacts ROM/FMC/RT, did the FW reps approve the change already? (Yes/No): No

· Why should the change be intercepted in Gen 1?: Threat model weakness

· Can the change be handled outside of Caliptra?: No

· If there is a schedule impact to Caliptra 0p8 or 1p0 milestone, is it approved by voting leads? (Yes/No)

[bharatpillilli]

Key can go into a register that is uC only accessible when Caliptra is not in debug/scan mode. ROM will clear the register after usage if the value of the CSR key register is zero, then ROM does not sign the CSR (Not yet approved - may require some behind the scene discussions) - Bharat will do a quick FYI in this forum and close it.

Assumed RTL impact is < 2 days - no schedule impact because github repo modification already pushed the 1p0 schedule by 2 weeks.

[varuns-nvidia]

@JohnTraverAmd could you comment if you're ok with this change? Bharat wanted your feedback before proceeding.

[varuns-nvidia]

I chatted with @JohnTraverAmd . The change request is insufficient to solve the problem. We assume that an adversary has control of the Tester as the person-in-the-middle between the DUT and the Vendor PKI. The Tester can inject fuse values via JTAG. NOTE: it's not required that the fuses be burned: a Vendor may desire that the fuses not be burned until the entire provisioning flow is complete, else they would have to throw away the DUT if the provisioning round-trip failed.

If the Tester can continually reset and inject new UDS Seeds, then it can cause the Caliptra DUT to continually generate authentic IDevID CSRs.

• There is no Caliptra-defined means to ensure the authenticity of the UDS Seed used to generate IDevID CSR.
• There is no requirement for Vendor PKI to track the pre-provisioned UEID of the DUT to ensure that Caliptra DUT only generates one CSR.

Vendors could address these issues through their own methods. Since the asset at risk is the trustworthiness of the Vendor PKI, they are incentivized to do so. A future Caliptra could mitigate these issues through on-device generation of UDS Seed.

Suggesting then that we close this ticket as Will Not Fix. I can update the Arch spec accordingly to list out these threats that a Vendor should handle.

@bharatpillilli @Bryankel @bluegate010 @andreslagarcavilla for thoughts

[varuns-nvidia]

Did not receive feedback to keep this in Caliptra WG, so proceeding to "wont fix" for 1.0 and keep for next gen. @bharatpillilli do you have a label for post 1.0?

[bharatpillilli]

Added one saying "Future" :)

[bharatpillilli]

@varuns-nvidia - can u plz assign this to the new Nvidia owner?