Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cryptographic validation of Evidence with attest-key-triple #318

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Cryptographic validation of Evidence with attest-key-triple #318

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 20 additions & 8 deletions draft-ietf-rats-corim.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1824,14 +1824,6 @@ If Evidence is cryptographically signed, its validation is applied before transf
If Evidence is not cryptographically signed, the security context of the conveyance protocol that collected it is used to cryptographically validate Evidence.

The way cryptographic signature validation works depends on the specific Evidence collection method used.
For example, in DICE, a proof of liveness is carried out on the final key in the certificate chain (a.k.a., the alias certificate).
If this is successful, a suitable certification path is looked up in the Appraisal Context, based on linking information obtained from the DeviceID certificate.
See Section 9.2.1 of {{DICE.Layer}}.
If a trusted root certificate is found, the usual X.509 certificate validation is performed.

As a second example, in PSA {{-psa-token}} the verification public key is looked up in the appraisal context using the `ueid` claim found in the PSA claims-set.
If found, COSE Sign1 verification is performed accordingly.

Regardless of the specific integrity protection method used, the Evidence's integrity MUST be validated successfully.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Regardless of the specific integrity protection method used, the Evidence's integrity MUST be validated successfully.
Nevertheless, Evidence integrity MUST be validated successfully.


> If a CoRIM profile is supplied, it MUST describe:
Expand All @@ -1840,6 +1832,26 @@ Regardless of the specific integrity protection method used, the Evidence's inte
> * How key material is associated with the Attesting Environment
> * How the Attesting Environment is identified in Evidence

##### Example: DICE
In DICE, a proof of liveness is carried out on the final key in the certificate chain (a.k.a., the alias certificate).
If this is successful, a suitable certification path is looked up in the Appraisal Context, based on linking information obtained from the DeviceID certificate.
See Section 9.2.1 of {{DICE.Layer}}.
If a trusted root certificate is found, the usual X.509 certificate validation is performed.

##### Example: ARM PSA Token
In PSA {{-psa-token}} the verification public key is looked up in the appraisal context using the `ueid` claim found in the PSA claims-set.
If found, COSE Sign1 verification is performed accordingly.

##### Example: `attest-key-triple`

A more general method of verifying evidence purely with CoRIM constructs is by verifying the signature with a trusted attestation key associated with the Evidence's Target Environment.
The Verifier MAY use environment-identifying elements of unverified Evidence to determine the Target Environment.
The Verifier MAY establish trust in an attestation key by constructing a certificate path to an accepted trust anchor whose constraints apply to the Target Environment.
For example, the Verifier has accepted a CoTS tag {{-ta-store}} with an environment that matches the `attest-key-triple`'s `environment-map` and a listed purpose is `"eat"`.
The Verifier MAY associate an attestation key with the Target Environment if a valid `attest-key-triple`'s `environment-map` successfully compares with the Evidence's Target Environment.
Comment on lines +1847 to +1851
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this topic is still relatively fresh, I understand the reluctance to add strong statements. However, these MAYs totally lack bite. I think a better way to phrase this is to state clear requirements under a set of well-defined circumstances. For example:

If attest-key-triples are used during phase 1 for evidence verification, then:

  • The verifier MUST ...
  • The verifier SHOULD ...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, if I use this method in the SEV-SNP CoRIM profile, then I can add that normative language for the profile, but this is still an example, and that profile doesn't actually use CoRIMs in this way.

For that profile I will still be making suggestions that Verifiers include a CoTS tag binding the SEV-SNP attestation class-id for the AMD-published keys as an implicit input, and then treating VCEK certificates from KDS as "virtual" attest-key-triples, since they don't issue CoRIMs.

When I describe translating an ATTESTATION_REPORT to claim structure that lines up with reference values in the CoRIM profile, I still describe the whole verification scheme.

It all just feels more like a mental exercise than an actual use of the CoRIM representation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to have similar requirements for PSA/CCA. Maybe we could sit down and see if we can extract a core set of requirements that are profile-independent.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The verifier will accept Evidence assertions so long as the channel to the Attester is authenticated (but not attested). Attest-key triple is not second guessing this assumption.

Phase 3 (corroboration of ref values) may be a better phase to process attest-key triples since the enforcement of a key measurement that fails key verification would reasonably result in that measurement NOT being corroborated.

It might make sense to require the RIM author to include RV triples that do binary compare operations as a pre-requisite to applying attest-key processing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RV triples that do binary compare operations of what? I'm not following.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am in favor of spinning off a hacking call to summarize set of profile independent core requirements. Any appetite?

Comment on lines +1845 to +1851
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These lines pertain to the handling of attest-key-triple-record and its transformation and processing logic. Possibly, it makes sense to move this text to issue #330?
It doesn't make sense to describe it as an example since it is / will be described in another part of the spec.

Comment on lines +1844 to +1851
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
##### Example: `attest-key-triple`
A more general method of verifying evidence purely with CoRIM constructs is by verifying the signature with a trusted attestation key associated with the Evidence's Target Environment.
The Verifier MAY use environment-identifying elements of unverified Evidence to determine the Target Environment.
The Verifier MAY establish trust in an attestation key by constructing a certificate path to an accepted trust anchor whose constraints apply to the Target Environment.
For example, the Verifier has accepted a CoTS tag {{-ta-store}} with an environment that matches the `attest-key-triple`'s `environment-map` and a listed purpose is `"eat"`.
The Verifier MAY associate an attestation key with the Target Environment if a valid `attest-key-triple`'s `environment-map` successfully compares with the Evidence's Target Environment.

If the `$crypto-key-type-choice` is an identifier type (e.g., `tagged-thumbprint-type`) and the Verifier cannot retrieve the associated public key material, then the key identifier MUST be discarded.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If the `$crypto-key-type-choice` is an identifier type (e.g., `tagged-thumbprint-type`) and the Verifier cannot retrieve the associated public key material, then the key identifier MUST be discarded.

This logic shouldn't apply when crypto-key-type-choice is used as a measurement-values-map value. If the value is corroborated by RVs then that should be good enough.

If the context is a key verification triple like attest-key-triple, then it makes sense to consider this text as part of the processing steps. But this is one of many possible failure conditions. Maybe there isn't a need to callout this condition explicitly?

The Verifier MAY use the Evidence's Target Environment to fetch input to verify and admit a relevant `attest-key-triple`.

Comment on lines +1852 to +1854
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These lines are included with the previous comment related to attest-key-triple-record.

### Input Transformation {#sec-phase1-trans}

Input Conceptual Messages, whether Endorsements, Reference Values, Evidence, or Policies, are transformed to an internal representation that is based on ECTs ({{sec-ir-cm}}).
Expand Down