[AS] Return generic report_data & init_data field in Attestation Claim

[Xynnn007]

Inspired by #216 (comment) we should also embed two more claims init_data and report_data to the Attestation-Claims of each verifier handler. This would do great help to the consumer of the attestation claims without needing to understand the TEE specific information.

cc @fitzthum @jialez0

[Xynnn007]

Tasklist

• Sample
• SGX
• TDX
• SNP
• Azure-vTPM-SNP
• CSV
• CCA

[fitzthum]

I am in favor of this, but I have two questions.

First, how are we going to accomodate Verifiers that don't support the init_data field. I think this it the case for the AZ SNP Verifier (maybe @mkulke has more details). I guess the verifier could have an empty claim? Then what happens when we try to compare this to the expected report data?

Second, is there any way in the source to make sure that developers don't forget to add the right claims to the map? I'm not really aware of a way to do this.

[Xynnn007]

Second, is there any way in the source to make sure that developers don't forget to add the right claims to the map? I'm not really aware of a way to do this.

This is surely a problem. Might be two ways.

1. Mandatory one enforced by compiler: A well defined structure as return type.
2. non-mandatory one: prompt developers by adding more comments above the definition of verifier.

Also would like to get viewpoints from @mkulke

[mkulke]

If we pass through init_data_hash and report_data to the verifiers evaluate() fn, can't we add those to the claim-set on the caller site after a successful verification?

regarding init-data on vTPM based attestation mechanisms (this will also apply to the az-tdx-vtpm TEE):

If we consider measured initialisation data to be a key property of cc_kbc then we there should be support for that in all verifiers, I think.

For SNP/TDX the measurement would be included as part of the signed report/quote in HOSTDATA/MRCONFIGID fields. vTPM based attesters would also need to provide a measurement as part of the evidence. It doesn't really matter how init-data would be injected/retrieved in the TEE, but it needs to be measured somehow into the vTPM (which is linked to a SNP/TDX attestation report/quote).

consequently, we need to establish trust in the component that performs the init-data measurement.

For example: If we assume init-data is provided via a CSP's user-data/IMDS facility (doesn't really matter, could be disk or a hardcoded file) then this component could be a script in userland, which itself is covered by measured boot. Extending the respective measurement with a hash of the provided init-data would yield expected_init_data_hash.

It's a lot more ceremony than providing an expected hash at guest-launch and having it embedded in a signed report, but I wouldn't know another way. In CAA there are many permutations of TEEs and Infrastructure, but I think this reasoning applies to all of those. (cc @stevenhorsman)

[fitzthum]

Maybe this is a good use of confidential-containers/guest-components#392 @bpradipt might also want to be aware of this potential approach.

@Xynnn007 is the idea to remove the report_data and init_data arguments from the evaluate method once all the verifiers return those values in the claims map?

[Xynnn007]

@Xynnn007 is the idea to remove the report_data and init_data arguments from the evaluate method once all the verifiers return those values in the claims map?

Yes. Leaving the comparation to the caller would be a better way once we have a common return value.