Questions related to Caliptra key management, trust measurement, power consumption and performance

[diswd]

Hi! I have some questions about Caliptra. Question:

1. the detail of the key management According to existing documents, the Key vault module cannot meet the requirements of key management because Key generation, key update, and key destruction were not mentioned. Therefore, I would like to ask how Caliptra implements key management?
2. trust measurement (1) Measurement sequence of SoC FW and Caliptra FW during system startup phase. (2) Active measurement description during system operation phase, such as dynamic measurement of key system components (such as kernel modules, drivers, etc.) (3) In the current version, can Caliptra directly obtain FW through QSPI ?
3. power consumption What is the power consumption reference index for Caliptra
4. performance Could you please provide a reference for Caliptra's overall throughput, the throughput of each algorithm, and the time required for secure startup?

[jhand2]

the Key vault module cannot meet the requirements of key management

Can you clarify what specific requirements you have?

[diswd]

the Key vault module cannot meet the requirements of key management

Can you clarify what specific requirements you have?

Hi! Thanks for your reply. I want to understand how Caliptra implements key generation, key update, and key destruction. I didn't find anything about these in Caliptra documents. Could you please tell me the specific description about Caliptra's key generation, key update, and key destruction? Thank you very much!

[jhand2]

It depends on what keys you're referring to.

In general, Caliptra stores all keys in the KeyVault peripheral: https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.kv_reg. This supports generation, locking, and clearing. You can find more details at https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.kv_reg

But how this is exposed to SoC callers depends on the key.

For DICE keys created by Caliptra:

• IDevID: Generated by ROM, used to sign LDevID Certificate, and then cleared.
• LDevID: Generated by ROM, used to sign FMC Alias Certificate, and then cleared.
• FMC Alias: Generated by ROM, used to sign Runtime Alias Certificate, and then locked by FMC. Unlocked on Caliptra reset. Can be cleared with the FIPS SHUTDOWN command.
• Runtime Alias: Generated by FMC, used to sign PCR quotes and DPE certificates by Runtime. Updated by FMC during impactless update. Can be cleared with the DISABLE_ATTESTATION or FIPS SHUTDOWN commands.

For DPE keys (keys created on behalf of the SoC) keys are generated, used, and cleared as part of a single command.

[diswd]

It depends on what keys you're referring to.

In general, Caliptra stores all keys in the KeyVault peripheral: https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.kv_reg. This supports generation, locking, and clearing. You can find more details at https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.kv_reg

But how this is exposed to SoC callers depends on the key.

For DICE keys created by Caliptra:

• IDevID: Generated by ROM, used to sign LDevID Certificate, and then cleared.
• LDevID: Generated by ROM, used to sign FMC Alias Certificate, and then cleared.
• FMC Alias: Generated by ROM, used to sign Runtime Alias Certificate, and then locked by FMC. Unlocked on Caliptra reset. Can be cleared with the FIPS SHUTDOWN command.
• Runtim Alias: Generated by FMC, used to sign PCR quotes and DPE certificates by Runtime. Updated by FMC during impactless update. Can be cleared with the DISABLE_ATTESTATION or FIPS SHUTDOWN commands.

For DPE keys (keys created on behalf of the SoC) keys are generated, used, and cleared as part of a single command.

Ok, thanks for your help!

[jhand2]

Oops I just linked the KeyVault register definition twice. I meant to link this for more details: https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md#key-vault

[bharatpillilli]

On performance numbers: HW spec carries information on the crypto performance characteristics. Please look at that.

On power: this is process specific.

[diswd]

On performance numbers: HW spec carries information on the crypto performance characteristics. Please look at that.

On power: this is process specific.

Ok, I got it. Thanks for your reply!