Attest-key-triple validation needed for ae construction?

[deeglaze]

If we're dropping the need for RVPs to specify the attester authority, we ought to mention in Phase 1 that Evidence can only be transformed an ECT about environment E only if the evidence was signed by a key bound to E with an attest-key-triple, no? It probably works differently for SPDM since the measurement is over an authenticated channel rather than signed, but unfortunately that detail is missing from the TCG document https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Concise-Evidence-Binding-for-SPDM-Version-1.0-Revision-54_pub.pdf

[nedmsmith]

we ought to mention in Phase 1 that Evidence can only be transformed an ECT about environment E only if the evidence was signed by a key bound to E with an attest-key-triple, no?

This might be too constraining since it is reasonable for an Attester to disclose the existence of a key without it being used. For example, an HSM could have several keys that are protected by the HSM but doesn't use all of them when producing Evidence.
The RIM author can decide when it is appropriate to supply attest key triples. That decision likely make sense for attestation keys that are used to sign evidence, but if a key isn't used, the spec should not compel them to supply an attest key triple (nor should it compel them to use it even if a key is used). The spec expects the verifier will verify keys that are used in the generation of evidence already, so it's the cases when a key isn't used to sign a Verifier input / Evidence, but may be used some other time, that attest key triple and identity key triple comes into play.

[nedmsmith]

It probably works differently for SPDM since the measurement is over an authenticated channel rather than signed

SPDM defines something called a "transcript" which is something like a signed block that can be taken out of the channel context to be used to verify the integrity of offline measurements. They could be forwarded to a proxy to verify etc. This seems a bit like an IETF "token" but the spec isn't written that way.

[nedmsmith]

but unfortunately, that detail is missing from the TCG document

The TCG binding spec anticipates that a transcript can be used.
The spec doesn't preclude use of a token or a detached signature (e.g., EAT) as the spdm-toc-map is extensible.

[deeglaze]

Do we have any plan for normative language about attest-key-triple and how its use is meant to bind an evidence-signing key to an environment?

[nedmsmith]

Do we have any plan for normative language about attest-key-triple and how its use is meant to bind an evidence-signing key to an environment?

By "bind" do you mean some form of proof-of-possession?

[deeglaze]

No I mean more of a binding contract in the Verifier to not accept evidence from keys not associated with the environment the reference values are for. I want to make sure that if I’m not specifying authorized-by for my reference values, then the environment must be tied to the manufacturer RoT somehow

[nedmsmith]

The trust dependency triple is trying to model that. We've parked that discussion a while ago so we could do the refactoring and get more prose behind core features. Maybe it's time to revisit trust dependency triple. One of the open topics was whether or not the domain abstraction was compelling. There was a proposal to squash it into an environment. (e.g,. $domain-type-choice /= environment-map or stateful-environment-map). That would allow the RVP to explicitly say which environments / keys depend on which other environments/keys (without needing an abstraction layer). If modeling DICE layering, the bottom dependency would be a RoT key and so forth. The verifier would use the trust dependency triples to check the actual DICE layers' signing sequences (aka DICE cert path) If the actual path differed from the intended path, the verifier would raise a red flag of some sort (i.e., not add corroborating RVs).

[deeglaze]

I'm afraid I don't follow that explanation. The RVP cannot say which exact keys the whole fleet that will run its signed firmware will have. We just know that the keys' certs should be issued by AMD's intermediate CA.

[deeglaze]

Attest-key-triple can be encoded by AMD's KDS signing a VCEK certificate with extensions that identify the environment it's bound to.

SEV-SNP Evidence can be interpreted as coming from a certain environment.
If there is a valid attest-key-triple for that environment and it verifies the evidence, then the evidence can be added as authorized by the attest-key. Yes?

[deeglaze]

There is no ACS / Appraisal context representation of attest-key-triple. I think we need to concretize the internal representation and its meaning.

[nedmsmith]

Reflecting rough consensus from the 2024-10-23 corim design team discussion:

• attest-key-triple should be processed as an endorsement.
• the combination of environment-map and a key ($crypto-key-type-choice) tuple (EKT) makes up the condition to be searched in the ACS. This means Evidence or Reference triples should have previously placed an EKT in the ACS.
• If key verification is successful, then a new ACS entry is added that contains the EKT values as an ECT where the ECT authority includes both the original endorser and the verifier.
• The verifier relies on the root of the certificate path that is provided in $crypto-key-type-choice as the trust anchor. (Note: if a key digest / key-id form of crypto-key-type-choice is used, the verifier will have to do "best effort" attempts to find a verifiable credential. Or we restrict the set of crypto-key-type-choice values to some subset). I'm leaning toward best effort rather than the spec having restrictions.

Other considerations:

• The attest-key-triple doesn't have a way to include authority as part of the condition. This could be a useful addition as it would allow an endorser to specify which RVP (or DICE layer key) it expects would have supplied the original (existential) measurement.
• A backwards compatible way to add authorized-by as a matching condition might be:

attest-key-triple-record = [
  environment-map
  key-list: [ + $crypto-key-type-choice ]
  ? authorized-by
]

If there is a second key-list entry that has different authority, this can be modeled by using a second attest-key-triple-record.

Note: to be consistent with measurement-map use of authorized-by we might want:

attest-key-triple-record = [
  environment-map
  key-list: [ + $crypto-key-type-choice ]
  ? [ + authorized-by ]
]

The semantics are that there could be multiple entities asserting the EKT, meaning multiple signers of the evidence / reference triples. In practice, this seems unlikely, but it isn't much overhead if added.

• The structure of the ACS addition (assuming key verification succeeds) would be an ECT where the environment is the EKT.environment-map and the ECT.element-id is omitted (anonymous), the ECT.element-claims.measurement-map.measurement-values-map is the EKT.measurement-map.measurement-values-map containing the key-list.