Proposing a new TCBMapping design with one hash endorsement

[haitaohuang]

Policy v2 measures the entire signed policy blob (which contains the TCB mapping) into RTMR2. This creates a circular dependency:  svnMappings  can't include RTMR2 because RTMR2 depends on the mapping's content. Today's workaround keys  svnMappings  on a register subset  [MRTD, RTMR0, RTMR1] , which (1) forces the source MigTD to accept full init TDINFO from the untrusted VMM per request, and (2) prevents the attestation service from matching  init/cur_servtd_info_hash  against the mapping.

Propose: measure RTMR2 as a single canonical-bytes extend of  policyData  with  servtdCollateral.servtdTcbMapping  redacted. The redaction is the only escape hatch; every other field stays bound by construction. The mapping can then key on the full composite  tdinfo_hash  (=  SHA384(TDINFO) ), populated after measurement — no cycle.

Benefits: MigTD resolves SVN locally (no VMM TDINFO), and the attestation service does a direct  tdinfo_hash → SVN  lookup with no out-of-band endorsements.  servtdIdentity  is retained for  tcbDate / tcbStatus  compatibility and measured for free. Future considerations: dropping policy signing and an RTMR1 signer anchor for key rotation.

See design doc at https://github.com/haitaohuang/MigTD/blob/tcbmap_proposal/doc/tcb_mapping_design_proposal.md

[jyao1]

@haitaohuang , very good analysis!

In brief, the proposal is:

MR	Before	After
MRTD	TD-Shim + MigTDCore	TD-Shim + MigTDCore (unchanged)
RTMR0	SEPARATOR	SEPARATOR (unchanged)
RTMR1	Policy issuer cert chain	TCBMapping issuer cert chain
RTMR2	Policy Data	Policy Data without TCBMapping
RTMR3	N/A	N/A (unchanged)

I agree that this solution (Using TDINFOHASH in the TCBMapping) can resolve the problem.

Some questions:

1. There is no authority for the policy, since policy issuer cert chain is not included in any RTMR. Then I do not see how signed policy is helping here. Do you still want signed policy, or do you want to propose for unsigned policy?

To me, I do not think it is justified that "Policy is still signed to keep current file format not changed". Policy signing seems useless in the new solution. I would rather remove the policy signing directly.

2. It seems that this solution changed the measurement style.

• the original style is "authority" (policy issuer cert) + "authorized data" (policy data).
• the proposed style is "authority" (TCBMapping issuer cert) + "unauthorized data" (policy data without TCBMapping). But "authorized data" (TCBMapping) is NOT measured.

It requires the MigTD to validate the integrity of TCBMapping with TCBMapping issuer cert - that should be OK.
But it cannot resist rollback attack, because there is no way to know if the TCBMapping is tampered or not. Please double confirm if this limitation is acceptable or not, from MSFT side.
And I am not sure if we need some TCBMapping revocation mechanism for the old invalid TCBMapping. Anyway, please think through the limitation.

[jyao1]

For NRX, "The issuer signatures on servtdTcbMapping and servtdIdentity still remain"

If it is NRX, there will be no servtdTcbMapping and servtdIdentity. They are out of scope.

[haitaohuang]

For NRX, "The issuer signatures on servtdTcbMapping and servtdIdentity still remain"

If it is NRX, there will be no servtdTcbMapping and servtdIdentity. They are out of scope.

I thought the policy owner would still need issue those but the servtd_ext.init/curr_info_hash redefined for policy. Would not?

Also created PR so it is easier to comment inline: #910

[haitaohuang]

@haitaohuang , very good analysis!

In brief, the proposal is:

MR Before After
MRTD TD-Shim + MigTDCore TD-Shim + MigTDCore (unchanged)
RTMR0 SEPARATOR SEPARATOR (unchanged)
RTMR1 Policy issuer cert chain TCBMapping issuer cert chain
RTMR2 Policy Data Policy Data without TCBMapping
RTMR3 N/A N/A (unchanged)
I agree that this solution (Using TDINFOHASH in the TCBMapping) can resolve the problem.

Some questions:

1. There is no authority for the policy, since policy issuer cert chain is not included in any RTMR. Then I do not see how signed policy is helping here. Do you still want signed policy, or do you want to propose for unsigned policy?

To me, I do not think it is justified that "Policy is still signed to keep current file format not changed". Policy signing seems useless in the new solution. I would rather remove the policy signing directly.

Thanks for quick review. We could remove policy signature. We were not sure:

1. whether this should replace or feature gated. I tend to think no future use for current design if we implement the new one. But would like to get feedback.
2. If we do feature gate, keeping it to minimize branching.
3. another minor benefit to keep it is for MigTD still self-validate the bytes loaded not corrupted at start up.

2. It seems that this solution changed the measurement style.

• the original style is "authority" (policy issuer cert) + "authorized data" (policy data).
• the proposed style is "authority" (TCBMapping issuer cert) + "unauthorized data" (policy data without TCBMapping). But "authorized data" (TCBMapping) is NOT measured.

It requires the MigTD to validate the integrity of TCBMapping with TCBMapping issuer cert - that should be OK. But it cannot resist rollback attack, because there is no way to know if the TCBMapping is tampered or not. Please double confirm if this limitation is acceptable or not, from MSFT side. And I am not sure if we need some TCBMapping revocation mechanism for the old invalid TCBMapping. Anyway, please think through the limitation.

I believe this is fine but will double check internally and let you know if any concerns