-
Notifications
You must be signed in to change notification settings - Fork 14
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
Server-ServerAuthenticatorAttestationResponse-Resp-9 P-3 #396
Comments
Sorry for the delay. I was traveling.
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: nameAlg = SHA-256 Does this makes more sense @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. |
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/
|
Still makes more sense than CSS. |
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:
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:
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:
|
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.
Section
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 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
"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 My deduction here being, This is a similar argument to what @madwizard-thomas stated in #396 (comment).
Sorry for the long comment, and thanks in advance! |
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.
The text was updated successfully, but these errors were encountered: