Why is Caliptra FMC required?

[yh36]

In some DICE model, the TCI of FMC is combined with UDS to derive CDI of device certificate, i.e., BootROM-->FMC-->Runtime. In this boot model, it is reasonable that we have such extra FMC stage before transferring control to the main runtime FW. Since any code update on Runtime FW will not affect the device certificate. The rarely changed FMC stage can help stabilize the device certificate.
But in Caliptra DICE flow, it has IDevID and LDevID, which decouples TCI of FMC from IDevID generation. (Note: IDevID cert is the only one that needs to signed by MFG SUB CA.) So, the code change of FMC will not affect IDevID cert.
My point is that the original intention of FMC is to stabilize the device cert signed by MFG SUB CA. Since Caliptra's IDevID is not affected by Caliptra's FMC, why do we still need this extra FMC stage instead of transferring control to main Runtime FW directly?

[jhand2]

Good question. The primary reason is to allow machine owners to issue an owner certificate for FMC alias key. Because RT is hitelssly updatable but FMC is not, you can issue an FMC owner cert at cold boot and then guarantee it won't change until the next cold boot. You can also force it to rotate with an FMC update, whereas LDevID is bound to fuses, so it's not infinitely rotatable.

We have had a couple discussions for 2.0 about ways we could achieve this property without FMC, but we don't have anything concrete written down yet.

[yh36]

@jhand2 I have one follow-up question regarding the certificate model in Caliptra. In BootROM code, I see the private key of each layer is zeroized before moving to the next layer. For example, the idevid_layer_output is zeroized at line 69 after LocalDevIdLayer is derived. I know that the code is to reflect DICE layer requirements. Can we move line 69 to line 72 (or line 75)? Since all layer derivations are still within Caliptra BootROM, I assume that it is legal operation to keep the previous layer's private key until the control exits the BootROM.

[jhand2]

The reason it's done there is to ensure none of the early returns skip the zeroize step. Is there a particular reason you would want to move it?

[yh36]

I originally thought that what you did is to comply with DICE layer requirement. That is, the private key of current layer shall be cleared before going to the next layer, which is reasonable if each layer corresponds to a different running FW. Now, since all first three DICE layers are executed by the same BootROM code, I am wondering if it is legal to zeroize all three private keys together at the end. Will this still comply with the DICE layering spec?
Thanks!

[jhand2]

From a spec compliance perspective, yes I would still consider it valid. It's just implemented this way to reduce the edge cases we need to handle in code.