[webauthn] TPM attestation verification steps inconsistent with FIDO conformance testing tool (#1925)

sbweeden has just created a new issue for https://github.com/w3c/webauthn:

== TPM attestation verification steps inconsistent with FIDO conformance testing tool ==
## Proposed Change

Note: This may end up resulting in a WebAuthn spec change (I think it should - read on), or in a close with feedback to the FIDO alliance about the validity of this test in the conformance testing tool, but the intent of opening this issue is to see a point of view and clarification from experts in the field of TPM attestation for FIDO.

There is a very confusing part of the TPM specifications related to which hash algorithm to use when computing the digest of the _pubArea_ for verification of the attested name of the _certInfo_ structure. Adding to this confusion is a completely different interpretation between the way WebAuthn is currently written, and the implementation of a TPM attestation test in the FIDO conformance test tool. 

Currently the WebAuthn TPM attestation verification steps [in section 8.3](https://w3c.github.io/webauthn/#sctn-tpm-attestation) include:

`Verify that attested contains a TPMS_CERTIFY_INFO structure as specified in [[TPMv2-Part2]](https://w3c.github.io/webauthn/#biblio-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]](https://w3c.github.io/webauthn/#biblio-tpmv2-part1) section 16.`

I draw attention to the words: **using the algorithm in the nameAlg field of pubArea**

Some sources, including [these instructions](https://medium.com/webauthnworks/verifying-fido-tpm2-0-attestation-fc7243847498) documented by @herrjemand indicate that the hash algorithm does *not* come from the _nameAlg_ field of _pubArea_, but instead comes from the TPM_ALG_ID portion of the attested name in the TPMS_CERTIFY_INFO structure. To me this makes complete sense - why wouldn't you co-locate the hash algorithm that was used alongside the hash digest?! Its not logical at all why the hash algorithm to use in the attested name within the TPMS_CERTIFY_INFO structure would come from the [nameAlg](url) in _pubArea_ (as currently written in WebAuthn).

In practice (i.e. in Windows TPM attestations observed in the field) these two hash algorithm identifiers are typically set to the same hash algorithm, which means regardless of which interpretation you use, verification of real-world TPM attestations works.

The FIDO conformance test tool however contains a specific test case where these algorithm identifiers are set to different values, to ensure that RPs use the algorithm identifier from the attested name in _certInfo_. If an RP strictly follows the process as currently defined in the WebAuthn specification, then that test case will fail. 

Adding to the confusion is the procedure specified in [[TPMv2-Part1]](https://w3c.github.io/webauthn/#biblio-tpmv2-part1) section 16, from which I draw two observations:
![image](https://github.com/w3c/webauthn/assets/8782685/2eb08aa5-ad1d-4b88-bc61-a86a7579b32c)

1. This seems fairly clear - use the hash algorithm in the name structure itself, which is consistent with the instructions from the aforementioned blog article and the FIDO conformance tool test.
2. This intimates that the nameAlg comes from the nameAlg parameter *in* the publicArea object. I actually think if the word `in` was changed to the word `of` here in the TPM spec, then things wouldn't be so ambiguous.
 
  
So which is correct? 

If using the _nameAlg_ from _pubArea_ is correct, then both the verification information from @herrjemand in his [blog article](https://medium.com/webauthnworks/verifying-fido-tpm2-0-attestation-fc7243847498) is wrong, as is the validity of that specific FIDO conformance test, as is the first observation from the screenshot of section 16 of the TPM spec. Further, its unclear what an RP should do if the _TPM_ALG_ID_ in the attested name is different from that in _pubArea_ because it would make the former redundant.

If using the algorithm identifier from the _TPM_ALG_ID_ in the attested name in _certInfo_ is correct, then the WebAuthn specification should be re-worded, for example:

`Verify that attested contains a TPMS_CERTIFY_INFO structure as specified in [[TPMv2-Part2]](https://w3c.github.io/webauthn/#biblio-tpmv2-part2) section 10.12.3, whose name field contains a valid Name for pubArea, as computed using the procedure specified in [[TPMv2-Part1]](https://w3c.github.io/webauthn/#biblio-tpmv2-part1) section 16. Note that the hash algorithm is included within the attested name in the TPMS_CERTIFY_INFO structure.`

Personally I believe it should be the latter, and am happy to pull together a PR with this change in it. It makes no sense to *not* use the hash algorithm identifier that is co-located in the attested name within the TPMS_CERTIFY_INFO structure.


Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1925 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 18 July 2023 23:11:18 UTC