[RFC] FIELD_ENTROPY - add support for non-FUSE-based support

[jameszhang-nvidia]

Scope

This RFC describes the rationale and implementation proposal for transitioning FIELD_ENTROPY from a FUSE-only approach to a model where FIELD_ENTROPY can be either FUSE-based or non-FUSE-based, according to the integrator's choice. FIELD_ENTROPY may be tied to device ownership and passed in from external sources. The RFC will also address the problem statement, change proposal, and threat analysis, explaining why we believe this approach does not degrade security but instead enhances usability.

This is mostly a ROM change so filing this under caliptra-sw.

---

Rationale

This RFC proposes changes to the FIELD_ENTROPY mechanism that is currently implemented in Caliptra Core 1.x, 2.0, and 2.1 for future Caliptra Core releases. Specifically, it addresses a fundamental incompatibility between FUSE-based FIELD_ENTROPY and silicon products that follow a circular economy model — where devices are expected to be returned, refurbished, and redeployed multiple times throughout their operational lifetime. With only 2 (or 4) FIELD_ENTROPY FUSE slots in current implementations, FUSE-based FIELD_ENTROPY is not sustainable for products that undergo repeated RMA, ownership transfer, and refurbishment cycles. This RFC recommends adding non-FUSE-based FIELD_ENTROPY capability.

Problem Statement

Current Caliptra implementations provide only 2 (or 4) FIELD_ENTROPY FUSE slots. FIELD_ENTROPY is used to derive locally significant device identity LDevID and to hedge against attackers who may have obtained the Unique Device Secret UDS before the device reaches the owner's facility. However, FUSE-based FIELD_ENTROPY is fundamentally incompatible with silicon products that follow a circular economy model:

1. Finite slots vs. near unlimited lifecycle events — With only 2–4 FIELD_ENTROPY FUSE slots available, each RMA or ownership transfer permanently consumes a non-renewable resource. For silicon products designed to be returned, refurbished, and redeployed, FIELD_ENTROPY slot exhaustion is inevitable. A product with 2 slots is fully depleted after just two lifecycle events; even 4 slots merely delays the problem.

2. High-value multi-component modules — Some silicon products are increasingly shipped as multi-component modules (e.g., CPUs paired with multiple GPUs on a single board). An RMA of such a module replaces far more silicon than a single socket, making each consumed FIELD_ENTROPY slot disproportionately expensive relative to the overall module cost.

3. Customer acceptance risk — Cloud Service Providers and enterprise customers may not accept refurbished boards that have depleted or nearly depleted FIELD_ENTROPY slots, creating a practical barrier to product serviceability and undermining circular economy goals.

Change Proposal

We need to consider implementation that uses Caliptra Subsystem (MCU + Core) and implementation that only uses Calipotra Core when it comes to this change. The key would be about how to pass per device unique FIELD_ENTROPY from an off silicon location (Flash or DOT) to Caliptra Core for Caliptra Core to be able to conduct LDevID Derivation in ROM. This should be done without mandating per device unique firmware (Caliptra Core Firmware/Manifest) to ease adaptation and real world deployment possibilities.

The proposed changes for Caliptra Core are as follows:

• ROM

  • The change shall be additive, so the original FUSE based FIELD_ENTROPY should still be an option if vendor choose to support that.
    • The selection for choosing between FUSE-based or non-FUSE-based should be an integration gasket choice and decided at time of integration.
  • Add new command GET_LDEVID in ROM that would be the flexible mechanism for either MCU or vendor ROT to provide Caliptra Core a non FUSE based FIELD_ENTROPY
  • Revise the ROM flow so that LDevID is generated just in time before RI_DOWNLOAD_FIRMWARE.
    • If FUSE based FIELD_ENTROPY is not used and no GET_LDEVID command is received, assume 0 as FIELD_ENTROPY
  • As an additional security measure, FIELD_ENTROPY should be treated as a seed value and obfuscated using RTL-derived.

• HW

  • Support an additional integration gasket mechanism where the integrator will select between FUSE-based or non-FUSE-based FIELD_ENTROPY usage.

With Caliptra Core supporting flexibile implementation choice to obtain FIELD_ENTROPY from a command. The caller, be it Caliptra MCU or another silicon vendor ROT, has many options on how this can be supported.

• Support some type of MCTP VDM to store FIELD_ENTROPY on flash and can be retrieved at boot time.
• Support this as part of DOT protocol where FIELD_ENTROPY is one of the argument added to DOT alongside of CAK/LAK.
  • For volatile DOT, the management controller needs to track FIELD_ENTROPY to ensure consistancy
  • For mutable locking DOT, it can be tracked with DOT_BLOB

For Caliptra MCU I would suggest that we tie this with DOT because DOT handling in Caliptra MCU ROM happens prior to RI_DOWNLOAD_FIRMWARE and is already part of the boot flow.

Implementation Tradeoff

Field Entropy in Manifest instead of Command

There are locations in the Caliptra Manifest where it is feasible to insert the FIELD_ENTROPY. This would prevent the need for a new command GET_LDEVID in ROM. However this creates a situation where there needs to be some kind of support for per device unique firmware. To avoid the need to support logistic difficulty of per device unique firmware, we have choose to have a more flexible approach to use GET_LDEVID command and have Caliptra MCU and Silicon Vendor to have a choice on how FIELD_ENTROPY is obtained, which one option is to tie it into Device Ownership Transfer schemes.

Expand Field Entropy using KDF and FUSE instead of as additional input

There are alternative methods to increase the availability of FIELD_ENTROPY using fuses. For example, a Key Derivation Function (KDF) could be used to expand a set of FUSE bits, such that each FIELD_ENTROPY update only requires burning a single FUSE bit, significantly altering the derived FIELD_ENTROPY value when combined with an RTL key.

However, the primary objective of FIELD_ENTROPY is to inject fresh, device-specific entropy into the DICE chain, rather than to expand upon existing entropy tied to a vendor-owned RTL key.

Enabling flash-based injection of FIELD_ENTROPY preserves the property of introducing genuine new entropy for LDevID derivation.

Threat Analysis

The following table compares FUSE-based and flash-based FIELD_ENTROPY across known attack vectors:

Attack Path	FUSE Attack Profile	Flash Attack Profile	FUSE Mitigation	Flash Mitigation
Malicious manufacturing spoofing on FIELD_ENTROPY	Expert	Expert	FIELD_ENTROPY obfuscation with class RTL key	Sames as FUSE Mitigation
Physical invasive attack	Expert	Intermediate	Shield FUSE IP (integration dependent)	N/A
Boot path tampering while retrieving FIELD_ENTROPY values	Expert	Expert	FIELD_ENTROPY obfuscation with class RTL key	Sames as FUSE Mitigation
Deriving die-specific keys from known FIELD_ENTROPY	Expert	Expert	Confine unobfuscated FIELD_ENTROPY and derivations to key vault	Sames as FUSE Mitigation

Conclusion: Outside of physical invasive attacks (which require Expert-level capability for fuses and Intermediate for flash), the security profiles are not significantly different. The physical attack vector for flash can be further hardened by upgrading Caliptra's obfuscation to use a per-device unique key or PUF key (an integration-level change).

Implementation Timeline

Intercept the next Caliptra Core release (2.2).

Test Plan

The following test is focused on Caliptra Core functionalities.

• Ensure existing FIELD_ENTROPY usage using FUSE based input still works as expected.
• When non-FUSE-based input is selected, test the new GET_LDEVID Command would obtain input and have said input properly used in LDevID derivation. Use Known Answer Test for such derivation.

Maintenance

TBD

[bharatpillilli]

How is the underlying UDS/device identity solved when such a device is being refurbished? What if FE as a feature is dropped from devices that support refurbishing? Why do we need to make the FE a non-secret and change the security posture of the feature?

Also the statement that doesn't require any HW change isn't valid. Initial CDI derivations are all hardened in the RTL in terms of how the secrets, keys and derivations flow and the key vault rules implemented around it.

Why not just drop the FE feature for devices that need refurbishing support and be done with it than going through the hoops because we are not using any real underlying "secret" in this new support model.

[jameszhang-nvidia]

Hi Bharat,

The UDS / IDevID is not affected by this proposal at all. The proposal also allow a silicon vendor choice of selecting to integration with a FUSE-based FIELD_ENTROPY as it is currently defined or a more flexible FIELD_ENTROPY as input to Caliptra Core as defined by this RFC.

The argument is that FE in FUSE and FE as input can both be obfuscated by RTL key. The difference is a physical attack on the flash part (or other entity that is used for FE storage, such as potentially in silicon or in package NVM that's not FUSE) vs FUSE. So our understanding is that the attack surface is similar, while difficulty might change, overall concept of needing to break actual FE value that attacker has access to, and obtaining RTL de-obf key would be difficult for a single attacker.

Bottom line is that we do not feel there is a degredation in the usage of FE given that

• Choice of using FUSE-based is still there
• Having FE capability (obfuscated by RTL key) is better than not having it if device needs to support ownership-transfer and/or RMA/refurb type of scenarios

[bluegate010]

Some commentary. Tl;dr: if we keep field entropy as fuses, then it's very secure but not terribly useful. If we want to be able to mitigate supply-chain adversaries for parts that undergo circular supply-chain paths, we will need to make some compromises.

• The low number of fuses available in the existing implementation affords an approximately-single opportunity to program field entropy upon receipt of a part by a data center operator.

• Many parts these days have a supply-chain path that includes cycles. A classic example is a part that undergoes RMA and later returns to the data center.

  • A more involved example is an accelerator board consisting of multiple GPUs, where the whole board is RMA'd if any of the GPUs are found to be defective. When the board comes back, some of the GPUs may be new but others will not.
  • Another example is a CPU which, upon RMA, may be routed back to any number of customers, not just the customer that shipped it in. When a data center receives such a CPU, that CPU may have been used by other data center customers in the past.

• In order for the field entropy feature to have value, a data center operator must be willing to scrap a part if they are unable to program field entropy upon ingestion. If a data center operator is willing to deploy hardware where fuse-based field entropy was fully consumed prior to ingestion, then a supply-chain attacker can simply intercept a part, fully exhaust field entropy, then extract all fuse-based secrets from the device. Assuming the attacker has also obtained the deobfuscation class secret, they can then impersonate the device's attestations after it has been deployed.

• So: we need to be willing to scrap devices if we cannot program fresh field entropy each time we see the part enter the data center anew, else we gain no security value from operationalizing field entropy. And for parts that undergo circularity in their supply-chain paths, we cannot be sure that we can program fresh fuse-based field entropy each time we see the part.

• Therefore: to secure such parts against supply-chain adversaries, we need to explore alternatives. The status quo protects field entropy very well within fuses, but with the unfortunate consequence that, as a very limited resource, the entire value of the feature is dubious.

• If we need to be able to renew field entropy arbitrarily many times, then the trade-off is likely that we can no longer classify these as secrets in the same sense as UDS. The platform as a whole should still endeavor to keep them secret, but it wouldn't be solely Caliptra's responsibility or purview.

• If we were to go down this route, we would therefore need to recharacterize field entropy in the documentation, to avoid conveying a false sense of security. From Caliptra's perspective, we could perhaps refer to it as a "salt".

  • Note that we needn't drop the existing fuse-based field entropy: for those that would like to continue relying on field entropy being in fuses, they could do so. The flash-based salt could be an additional input into LDevID's derivation.

• On the topic of whether this "salt" needs to be provided during Caliptra ROM execution or if it can be provided later at runtime:

  • One important property: in the context of this feature, because supply-chain attackers are assumed to know UDS, the operator should rely on certs derived solely from UDS only during salt provisioning in a secure environment. After this point, the operator should not rely on those UDS-derived certs again (until re-ingestion).
  • Now, if the salt is provided at runtime, then the IDevID, LDevID, FMC alias, and RT alias keys use only UDS as their secret input, meaning they are known to the supply-chain attacker. And every time RT firmware changes in the field, the operator will need to use at least FMC alias in order to establish trust in the new RT alias key. This presents an opportunity for the supply-chain attacker, which knows FMC alias, to present a falsified RT alias key to the verifier.
  • This is why field entropy is mixed into LDevID: it does not change upon in-field updates, and so the operator never has to use an attacker-known key to establish trust following in-field updates.

[timothytrippel]

I agree, this seems like a reasonable approach to ensuring field entropy is still usable in the circular economies of the datacenter world today. I would like to see a proposal for how we can ensure the integrity and provenance of field entropy provisioned in non-volatile storage outside the SoC. I think piggy-backing on the DOT specification is an interesting idea/approach.