Enhance DPE TCBInfo to include Vendor/Model Information for RATS Compliance

[fdamato]

Enhance DPE TCBInfo to include Vendor/Model Information for RATS Compliance

Problem Statement

The current Caliptra DICE/DPE TCBInfo implementation lacks critical information required for proper environment disambiguation and RATS (Remote ATtestation procedureS) compliance:

1. Missing Vendor/Model Name - Critical for unique environment identification
2. Limited Type Field - The current 4-byte type value in TCBInfo is insufficient for uniquely identifying different environments, creating potential collisions between distinct SoC implementations
3. SVN Not Consumed - While SVN is already available through DPE DeriveContext and Stash APIs, it's not being included in TCBInfo generation

RATS Requirements Impact

According to the CoRIM (Concise Reference Integrity Manifest) specification, each environment must be universally unique. The current implementation fails to meet this requirement due to:

• Insufficient entropy in the type field for global uniqueness
• Lack of vendor-specific identification
• Missing model information that would distinguish between different SoC variants

Proposed Solution for Caliptra 2.x

API Enhancement

Extend the LoadFW API to accept additional parameters:

• Vendor Name (string identifier)
• Model Name (string identifier)

Implementation Approach

1. SoC Manager Integration: Retrieve vendor and model information from the SoC Manager during firmware loading
2. DCCM Storage: Store the vendor/model metadata in DCCM for persistence across the attestation lifecycle
3. SVN Integration: Consume SVN values already provided through DPE DeriveContext and Stash APIs
4. TCBInfo Generation: Include vendor/model/SVN information during TCBInfo generation for DPE measurements

[nquarton]

One possible solution we have discussed a bit in the WG calls is to defer DPE initialization in the RT FW and receive this info via a RT mailbox command.

This could just generically be a DPE_INIT command that can provide this info (and possibly more info in the future if needed). This would:

• Run initialize_dpe when the DPE_INIT command is called instead of happening during the RT FW cold reset flow
• Other RT FW commands to DPE functionality should return an error if DPE_INIT has not been called (should this include RT FW calls to stash measurement?)
• Calling DPE_INIT more than once should return an error

[zhalvorsen]

I'm worried that requiring this command might cause disruption in the fleet when firmware is updated. It is kind of a breaking change. Could we make it an opt-in option, but assuming if any other DPE command is received before the initialize_dpe command, it will use default values?

[nquarton]

That's a fair point I wasn't really considering the 2.0 to 2.1 update. I think that should work. That implicit DPE init would happen "silently" but if you later call DPE_INIT you would get an error that would raise the issue with your flow.

I think we still have to decide how to handle a RT stash measurement call though. I think ideally we could continue to buffer those until after a DPE init call (or other DPE call that forces a default init). That way, we don't have to push this DPE_INIT into a ROM if the user wants to use it and has the RT stash measurements calls.