-
Notifications
You must be signed in to change notification settings - Fork 180
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.
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
Added TPM verification clarifications #966
Added TPM verification clarifications #966
Conversation
cc @akshayku |
cc @apowers313 |
Ref #950 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for clarifying this stuff @herrjemand -- just a few rough edges to polish it seems.
- Note that the remaining fields in the "Standard Attestation Structure" [[TPMv2-Part1]] | ||
section 31.2, i.e., `qualifiedSigner`, `clockInfo` and `firmwareVersion` are ignored. | ||
These fields MAY be used as an input to risk engines. | ||
|
||
If |x5c| is present, this indicates that the attestation type is not [=ECDAA=]. In this case: | ||
- Verify the |sig| is a valid signature over |certInfo| using the attestation public key in |x5c| with the | ||
algorithm specified in |alg|. | ||
- Verify certificate chain in |x5c| against attestationRootCertificates in Metadata Statement specified by AAGUID in authData. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should have this match how we elsewhere mention the metadata service.
suggest:
- If the prior step was successful, obtain a list of acceptable
trust anchors (attestation root certificates) for the [=AttCA=]
attestation type and attestation statement format `tpm`, from
a trusted source or from policy. For example, the FIDO
Metadata Service [[FIDOMetadataService]] provides one
way to obtain such information, using the
<code>[=aaguid=]</code> in the
<code>[=attestedCredentialData=]</code> in |authenticatorData|.
- Verify certificate chain in |x5c| against the trust anchors
obtained in the prior step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scratch the above, see below.
@@ -3430,15 +3430,16 @@ engine. | |||
- Verify that `extraData` is set to the hash of |attToBeSigned| using the hash algorithm employed in "alg". | |||
- Verify that `attested` contains a `TPMS_CERTIFY_INFO` structure as specified in [[TPMv2-Part2]] section 10.12.3, | |||
whose `name` field contains a valid Name for |pubArea|, | |||
as computed using the algorithm in the `nameAlg` field of |pubArea| using the procedure specified in [[TPMv2-Part1]] | |||
section 16. | |||
as computed by concatinating algorithm identifier from the signauture algorithm(for RS256 it's sha256) specified in TPM_ALG_ID, with hash of the `pubArea` field as specified in [[TPMv2-Part1]] section 16. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking we do not want to get into this much detail since it is already spec'd in the TPM specs. Suggest doing only this:
as computed using the hash algorithm identified by the value of the
`nameAlg` field of |pubArea| and using the procedure specified in
section 16 of [[TPMv2-Part1]].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@equalsJeffH Navigating TPM specs is a hell. So I think we should be slightly more specific in this example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @equalsJeffH here. Duplicating instructions risks getting them wrong in subtle ways, and I think that risk outweighs the small possible convenience gain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the TPM specs are difficult to decipher -- i spent a ton of time yesterday trying to figure out how the nameAlg field works, and am not sure my interpretation is correct -- hence not wanting to bake errornous interp into webauthn, as @emlun notes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also agree - the TPM specs are difficult, so let's not add to confusion by potentially getting it different here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BradL-Msft Are other changes in this PR OK?
as computed using the algorithm in the `nameAlg` field of |pubArea| using the procedure specified in [[TPMv2-Part1]] | ||
section 16. | ||
as computed by concatinating algorithm identifier from the signauture algorithm(for RS256 it's sha256) specified in TPM_ALG_ID, with hash of the `pubArea` field as specified in [[TPMv2-Part1]] section 16. | ||
- Verify that `pubArea` contains TPMU_PUBLIC_ID that is set to newly generate public key as specified in [[TPMv2-Part2]] section 12.2.3.2. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
newly generate -> the newly generated
as specified in [[TPMv2-Part2]] section 12.2.3.2 -> as specified in sections 12.2.3.2 and 12.2.4 of [[TPMv2-Part2]].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing this up, but I agree with @equalsJeffH that it's probably best to not include all of it.
- Note that the remaining fields in the "Standard Attestation Structure" [[TPMv2-Part1]] | ||
section 31.2, i.e., `qualifiedSigner`, `clockInfo` and `firmwareVersion` are ignored. | ||
These fields MAY be used as an input to risk engines. | ||
|
||
If |x5c| is present, this indicates that the attestation type is not [=ECDAA=]. In this case: | ||
- Verify the |sig| is a valid signature over |certInfo| using the attestation public key in |x5c| with the | ||
algorithm specified in |alg|. | ||
- Verify certificate chain in |x5c| against attestationRootCertificates in Metadata Statement specified by AAGUID in authData. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd argue this is already covered by steps 15 and 16 in §7.1. Relying Party Operations: Registering a new credential, and doesn't need to be repeated here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps steps 15 and 16 in §7.1. Relying Party Operations: Registering a new credential can be appropriately referenced here -- we can add anchors to individual steps if we wish -- see step 13 in S 6.2.3.
@@ -3430,15 +3430,16 @@ engine. | |||
- Verify that `extraData` is set to the hash of |attToBeSigned| using the hash algorithm employed in "alg". | |||
- Verify that `attested` contains a `TPMS_CERTIFY_INFO` structure as specified in [[TPMv2-Part2]] section 10.12.3, | |||
whose `name` field contains a valid Name for |pubArea|, | |||
as computed using the algorithm in the `nameAlg` field of |pubArea| using the procedure specified in [[TPMv2-Part1]] | |||
section 16. | |||
as computed by concatinating algorithm identifier from the signauture algorithm(for RS256 it's sha256) specified in TPM_ALG_ID, with hash of the `pubArea` field as specified in [[TPMv2-Part1]] section 16. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @equalsJeffH here. Duplicating instructions risks getting them wrong in subtle ways, and I think that risk outweighs the small possible convenience gain.
as computed using the algorithm in the `nameAlg` field of |pubArea| using the procedure specified in [[TPMv2-Part1]] | ||
section 16. | ||
as computed by concatinating algorithm identifier from the signauture algorithm(for RS256 it's sha256) specified in TPM_ALG_ID, with hash of the `pubArea` field as specified in [[TPMv2-Part1]] section 16. | ||
- Verify that `pubArea` contains TPMU_PUBLIC_ID that is set to newly generate public key as specified in [[TPMv2-Part2]] section 12.2.3.2. | ||
- Note that the remaining fields in the "Standard Attestation Structure" [[TPMv2-Part1]] | ||
section 31.2, i.e., `qualifiedSigner`, `clockInfo` and `firmwareVersion` are ignored. | ||
These fields MAY be used as an input to risk engines. | ||
|
||
If |x5c| is present, this indicates that the attestation type is not [=ECDAA=]. In this case: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps this ought to be rewritten as:
If |x5c| is present, the attestation type is [=AttCA=].
..?
For anyone else that wants to play along from home, here is some help understanding TPM. I'll probably stick these in a blog post or something in the near future: |
After more talking internally, it looks like we don't want to duplicate things that are already in TPM specs. Which has a risk of going out of sync. If TPM specs are hard to read, that should be solved somewhere else. I would propose to close this. |
Ref #929
Preview | Diff