Server-ServerAuthenticatorAttestationResponse-Resp-9 P-3

[aseigler]

By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.

If you have privacy concerns, please email [email protected]

What protocol and version of the protocol are you testing?

FIDO2

What is your implementation class?

Server

What is the version of the tool are you using?

v0.10.109

What is the OS and the version are you running?

Windows 10

Issue description

P-3 Send a valid ServerAuthenticatorAttestationResponse with "tpm" attestation pubArea.nameAlg is not matching algorithm used for generate attested.name, and check that server succeeds

Spec (https://www.w3.org/TR/webauthn/#tpm-attestation) states:

"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."

Test appears contrary to spec, in spirit allowing valid Name for pubArea as computed using algorithm in the attestation statement instead of nameAlg field of pubArea as specified.

[yackermann]

Sorry for the delay. I was traveling.

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.

So the name is concatenation of nameAlg[2byte] and hash structure[n-bytes].

The confusion comes from the fact TPMS_CERTIFY_INFO contains name field that contains name of the TPMT_PUBLIC. But in the same time TPMT_PUBLIC contain nameAlg field that contains algorithm identifier for calculating authPolicy. There two both use nameAlg, but they can be different.

For example:
TPMT_PUBLIC.nameAlg = SHA-1;
TPMT_PUBLIC.authPolicy = hashTPMT_PUBLIC.nameAlg

nameAlg = SHA-256
TPMS_CERTIFY_INFO.name = nameAlg || hashnameAlg

Does this makes more sense @aseigler ?

[aseigler]

So the nameAlg that is IN pubArea, is not the nameAlg field OF pubArea, that nameAlg is for the policy. Rather, the nameAlg in the TPMS_CERTIFY_INFO is OF pubArea and is therefore the one used to verify. That is extremely confusing wording, but it works.

[yackermann]

Yes. Welcome to the world of TPM. Complicated wording is official moto of this standard -_-

On Sat, 29 Sep 2018 at 10:06, Alex Seigler ***@***.***> wrote: So the nameAlg that is IN pubArea, is not the nameAlg field OF pubArea, that nameAlg is for the policy. Rather, the nameAlg in the TPMS_CERTIFY_INFO is OF pubArea and is therefore the one used to verify. That is extremely confusing wording, but it works. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#396 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABj3FBDb-x-RHPbd8J69l5n45amBUwVeks5uftXBgaJpZM4WtIAx> .

-- [image: Ackermann Yuriy] <https://jeman.de/> *Ackermann Yuriy* Developer *e:* [email protected] *g:* @herrjemand <https://github.com/herrjemand> *w:* https://jeman.de/

[aseigler]

Still makes more sense than CSS.

[yackermann]

[madwizard-thomas]

I ran into this too, it makes sense to use the prefixed algorithm identifier from certify_info.name rather than the one in pubArea.nameAlg, but I still fail to see how the wording in the W3 specs can be interpreted to do that:

... whose name field contains a valid Name for pubArea, as computed using the algorithm in the nameAlg field of pubArea

Doesn't this explicitly say to use pubArea.nameAlg to compute the name? If the sentence ended after "whose name field contains a valid Name for pubArea" it would make more sense.

Also your own article on TPM verification seems to use pubArea.nameAlg as well:

9. Hash pubArea to create pubAreaHash using the pubArea.nameAlg
10. Concatenate pubArea.nameAlg and pubAreaHash to create attestedName.
11. Check that certInfo.attested.name is equals to attestedName.

If certInfo.attested.name contains it own algorithm there can be multiple valid names using different algorithms and a comparison like this would not suffice.

Also earlier the article's description of TPMT_PUBLIC seems to indicate the algorithms must be the same:

name alg — an algorithm that was used to generate name field in certInfo. Must much algorithm in name [sic, 'match' was intended I presume?]

[grzuy]

Hi @herrjemand,

Sorry I am still trying to understand how Name computation works and how it can be possible for the hash algorithms to be different in both structures, based on TPM 2.0 spec.

Sorry for the delay. I was traveling.

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.

So the name is concatenation of nameAlg[2byte] and hash structure[n-bytes].

The confusion comes from the fact TPMS_CERTIFY_INFO contains name field that contains name of the TPMT_PUBLIC. But in the same time TPMT_PUBLIC contain nameAlg field that contains algorithm identifier for calculating authPolicy.

Section 12.2.4 TPMT_PUBLIC in TPM-Rev-2.0-Part-2-Structures mentions that TPMT_PUBLIC.nameAlg is both used for authPolicy (as you mentioned above) and for computing the Name of the object.

There two both use nameAlg, but they can be different.

Is there any passage in the TPM 2.0 spec that explicitly mentions, or you think it can be inferred, that there's a possibility that TPMT_PUBLIC.nameAlg and TPMS_CERTIFY_INFO.name.name.hashAlg can be different?

Honestly asking because I couldn't, and I might be missing something in the sea of TPM docs :-)

Passages from the TPM docs that make me think that the TPMS_CERTIFY_INFO.name.name.hashAlg has to be the same as in TPMT_PUBLIC.nameAlg, because one is computed from the other, are:

1. Table 3 — Equations for Computing Entity Names in TPM-Rev-2.0-Part-1-Architecture where it states that for Objects the hash structure of the Name is computed "using the nameAlg parameter in the object associated with handle", were handle is referring to the public area (TPMT_PUBLIC), i.e. TPMT_PUBLIC.nameAlg from what I understand.

2. Section 16 Names in TPM-Rev-2.0-Part-1-Architecture stating:

"The Name of an entity is its unique identifier. The handle associated with an object may change due to context management (TPM2_ContextSave() / TPM2_ContextLoad()), but the Name of an object remains constant".

Assuming that TPMS_CERTIFY_INFO.name.name.hashAlg can be different from TPMT_PUBLIC.nameAlg, that would mean there could be two valid and different names for the same object, which contradicts the statement from the TPM spec above, in my opinion.

My deduction here being, TPMS_CERTIFY_INFO.name.name.hashAlg has to have the same hash algorithm as TPMT_PUBLIC.nameAlg in order for the Name of a public area to be unique.

This is a similar argument to what @madwizard-thomas stated in #396 (comment).

For example:
TPMT_PUBLIC.nameAlg = SHA-1;
TPMT_PUBLIC.authPolicy = hashTPMT_PUBLIC.nameAlg

nameAlg = SHA-256
TPMS_CERTIFY_INFO.name = nameAlg || hashnameAlg

Does this makes more sense @aseigler ?

Sorry for the long comment, and thanks in advance!