Windows Hello and hmac-secret

[MiSimon]

Hello, i tried to create a credential on a FIDO2 token with the hmac-secret extension.
When i create the credential in admin mode using the token directly it works, if i want to create it on the same token using the windows://hello device the hmac-secret extension is not active for the credential. The credProtection extension is not affected by this behaviour, it is active when the token is used directly and also if the token is used via the windows://hello device.

I traced it down to the call to the winhello_make_cred function, the hmac-secret extension is set in ctx->opt->Extensions, but is not set in ctx->att->Extensions.

Am I missing some step that is required to use the extension with Windows Hello?

[martelletto]

Which version of webauthn.dll are you using? That can be observed by enabling FIDO_DEBUG and looking for api version:.

[MiSimon]

Do you mean this line: "webauthn_load: api version 4"?
I am using Windows 11 22H2.

[martelletto]

Yes, that's what I meant. Thank you for the information. We've reproduced the problem internally and are looking into it. From what we can observe, the authenticator data returned by Windows with only hmac-secret (no credProtect) does not have bit 0x80 set in its flags field, which indicates the absence of hmac-secret. It's unclear why this is happening. Are you able to use hmac-secret with the generated credential (if you ignore the attestation error)?

[MiSimon]

The hmac-extension can be used. The assertion can be verified with the hmac-extension enabled.

[martelletto]

Thank you. Could you share the Windows Event logs from when a credential is created? https://support.yubico.com/hc/en-us/articles/4404763857042-How-to-collect-FIDO-WebAuthn-logs has details on how to extract the logs from Event Viewer.

[MiSimon]

Webauthn.zip contains the eventlog. First i created the credential with the windows hello device and then with the token direct. Thank you for your help.

shell.txt
webauthn.zip

[martelletto]

A short update from our side: we have reproduced the issue with Chrome on Windows and https://webauthntest.identitystandards.io/login.html (i.e. https://github.com/microsoft/webauthntest). As far as we can tell, webauthn.dll appears to be ignoring the hmac-secret extension when enrolling a credential. If you have a chance, please try to reproduce the issue on https://webauthntest.identitystandards.io/login.html as well; that would be a useful data point. I will defer to my colleague @LDVG on next steps.

[MiSimon]

You are correct if i analyze the usb traffic to the token with wireshark, i can see the hmac.-secret extension is not set if webauth.dll is used.
It is missing if the credential is created via browser and also if created with libfido2 (not admin).

[LDVG]

Hi, @MiSimon.

It would appear that webauthn.dll mandates a request to create a discoverable/resident credential to also pass through the request for the hmac-secret extension. Does it work for you if you also set fido_cred_set_rk(cred, FIDO_OPT_TRUE)?

As an aside, note that the authenticator may support the hmac-secret extension when getting an assertion regardless of whether it was requested when the credential was created, as suggested by the CTAP2 specification.

[MiSimon]

Hi,

i can cofirm that the hmac-secret extension is used when rk ist true. This seems to be a Windows issue and not related to libfido2.

[LDVG]

Thank you for confirming! We additionally pushed a small set of added comments and slight improvements in #740.