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

Hm. I'm certainly not an expert on the TPM specs, but my interpretation of the current state of the WebAuthn spec is:

- The issuer constructs the `pubArea` object first, and includes a `nameAlg` field in this structure.
- The issuer then constructs the `certInfo.attested` object, and sets its `name` field to the result of computing a `TPM2B_NAME` from `pubArea` by hashing it with the hash algorithm `pubArea.nameAlg`. The resulting `TPM2B_NAME` structure also includes a copy of that `nameAlg` value.
- So when the verifier is to validate the TPM attestation object, the WebAuthn spec instructs the verifier to re-compute the same `TPM2B_NAME` structure from `pubArea` and verify that the resulting byte sequence equals the byte sequence `certInfo.attested.name`. Note that equality here necessarily means that `pubArea.nameAlg` also equals the first two bytes of `certInfo.attested.name.name` [sic; the first two bytes of `certInfo.attested.name` are the length of `certInfo.attested.name.name`].

Thus, if my reading is correct that the verifier is supposed to check the recomputed `TPM2B_NAME` for binary equality with the embedded `TPM2B_NAME`, it seems to me that if the two hash IDs are different, then the attestation as a whole is invalid anyway.

I think there's support for this interpretation if you look at [Trusted Platform Module Library Part 3: Commands ยง18.2 TPM2_Certify](https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-3-Commands-01.38.pdf) (referenced in WebAuthn in the signing procedure of the TPM attestation format): the `TPM2_Certify` response structure only contains a `TPM2B_ATTEST` structure, that is `certInfo`; the `pubArea` object is not returned by the signing command. In that light - if you consider the `TPM2B_NAME` as a whole as an opaque value, not just the digest part of it - it makes more sense to me that the verifier should use the hash ID from `pubArea.nameAlg` and then verify that the recomputed `TPM2B_NAME` structure equals the one generated by the issuer.

If the above is correct, then @herrjemand's article is also correct in practice, because the algorithm presented there does also verify that the two hash IDs are equal. But if the FIDO conformance tool presents a test case with a TPM attestation with two different hash IDs and expects that to be accepted, then it seems to me like that test case is incorrect - it should instead expect the test case to be rejected.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1925#issuecomment-1650192706 using your GitHub account


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

Received on Tuesday, 25 July 2023 16:51:07 UTC