Attestation with full attestation from authenticator that does not support full attestation

[gaxelac0]

Version

0.8.2

Description

Doing an enrollment with a Windows Hello Authenticator device with "direct" attestation throws this error that happens at attestation.go:187.

This happens because the MetatadataStatement for Windows Hello Authenticator (aaguid 08987058-cadc-4b81-b6e1-30de50dcbe96) doesn't have "basic_full" in the attestationTypes array.

"attestationTypes": [
"attca"
]

Is this a correct behavior?

Reproduction

Enroll a device with:
AttestationType "direct"
AuthenticatorType "platform"
Authenticator: "Windows Hello Authenticator"

Expectations

The device should be enrolled succesfully.

Documentation

No response

[james-d-elliott]

Which browser and OS (and their builds) are you using?

[gaxelac0]

I used Chrome latest (114.0.5735.198) on Windows 11.
But this is independant from the browser used, as the MetadataStatement truly doesn't have the expected attestationType ("basic_full").

[james-d-elliott]

What OS build? Also it's not entirely clear that a browser couldn't cause this strange behavior as some browsers do not have complete support for WebAuthn and forcibly use fido-u2f, however it's not exactly likely either and basically should not occur on Chrome (would still be interested if the behavior is the same on Edge but it's very likely the same). I'll try and replicate this and see what's going on after consulting the relevant specs.

To me it seems like a bug on the Windows end or with the MDS3 blob at first glance. If the attestation is direct theoretically the issuer should be the same as the subject, but maybe that's not the case. My other thought is potentially the attca which is associated with TPM-based authenticators always returns this kind of statement which seems to be supported by the fact both hardware Windows Hello types seem to list this type and so does the Android Authenticator (can't find the Apple TouchID one and it appears the only other ones are ).

The more I look at this the more unclear it becomes, I'll revisit this and see if the contributor who implemented MDS3 has some more information maybe.

This value indicates that the Relying Party wants to receive the attestation statement as generated by the authenticator.

[james-d-elliott]

@aseigler if you had some insight on this one it'd be a great help.

[aseigler]

Yes, I was going to try to take a look at this. Will report back with findings.

[gaxelac0]

Same error on

• Chrome Version 114.0.5735.199 (Official Build) (64-bit)
• Edge Version 114.0.1823.67 (Official build) (64-bit)
• Firefox 115.0 (64-bit)

So I infer it's independent from Browser type and build.

I tested on Windows 11 Enterprise
Version 10.0.22000 Build 22000

And I remember this happened to me on older Windows 10 version, so it is authenticator-related, not OS build related. As the AAGUID it's the same and didn't changed. (08987058-cadc-4b81-b6e1-30de50dcbe96)

Yes. It may be a problem on the BLOB, but may be a problem with the library as well... that's why I opened the issue to ask.

If you need me to test any additional scenario, no problem! Thanks.

[gaxelac0]

Tested on Firefox Version 115.0 (64 bit) with
Microsoft Windows 10 Enterprise
10.0.10942 Build 10942

Same error.

The aaguid is the same (08987058-cadc-4b81-b6e1-30de50dcbe96)

[gaxelac0]

Also tested these scenarios

Attestation: "indirect"
Authenticator Type: "platform"
Result: same error.

Attestation "direct"
Authenticator Type: "unspecified"
Result: same error.

Attestation "indirect"
Authenticator Type: "unspecified"
Result: same error.

Attestation "direct"
Authenticator Type: "platform"
RequireResidentKey: True
Result: same error.

[gaxelac0]

Tested this with old duo-labs/webauthn and it works.

Seems this logic in particular got migrated from attestation_packed.go to attestation.go causing this issue.
https://editor.mergely.com/XmpT3cDz

[james-d-elliott]

Yeah I'm fairly certain it's our issue, there is a chance it's an issue with the MDS3 blob as well; but I suspect that check is incomplete/incorrect. I had in mind interfacing that verification logic as well so maybe this is partially a whip crack to accomplishing that. We don't need further OS testing, the only situation this would theoretically not occur is when not using TPM backed Windows Hello.

Likely Commit: 697bc4c
Likely Code Section (already pointed out): https://github.com/go-webauthn/webauthn/blob/master/protocol/attestation.go#L177-L189

I suspect this check is not required and we can just revert it partially to provide a temporary fix, however I'd like to figure out if a similar check would be beneficial before merging.

[aseigler]

That aaguid as well as 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 Windows Hello VBS Hardware Authenticator both have attestationTypes = attca now. Everything else has basic_surrogate, basic_full, or both. Not sure if this changed recently or what (would have been the first of the month). Pondering.

[aseigler]

I think we simply need to treat attca the same as basic_full in this area. Essentially if (basic_full || attca). Will dig in a bit more and send up a PR.

[james-d-elliott]

If you find anything specific that may explain this it might be helpful to link the spec or related docs in the code, if you don't find anything that's fine too. I was thinking similar being the proper solution. Do we know if basic_surrogate as is with Windows Hello Software backed (from memory) also fits into this category?

[aseigler]

If you find anything specific that may explain this it might be helpful to link the spec or related docs in the code, if you don't find anything that's fine too. I was thinking similar being the proper solution. Do we know if basic_surrogate as is with Windows Hello Software backed (from memory) also fits into this category?

I don't think basic_surrogate falls into this category. Here's a couple of links describing the different types.

https://www.w3.org/TR/webauthn-2/#sctn-attestation-types
https://fidoalliance.org/specs/common-specs/fido-registry-v2.2-rd-20210525.html#authenticator-attestation-types
Third thing in: https://medium.com/webauthnworks/webauthn-fido2-whats-new-in-mds3-migrating-from-mds2-to-mds3-a271d82cb774

[james-d-elliott]

Yeah gotcha. That kind of makes sense to me too. One strange thing I noticed when looking at this was there were no obvious MDS3 entries for Apple unless I am missing something.

[aseigler]

Yeah gotcha. That kind of makes sense to me too. One strange thing I noticed when looking at this was there were no obvious MDS3 entries for Apple unless I am missing something.

You're not missing anything. Apple doesn't have any FIDO certified products, they do not provide attestation and they have no AAGUID. They do have an AAGUID for Apple AppAttest but that is a different animal and still not in MDS.