Using libfido2 on Windows without Windows Hello

[apantina]

Hi folks!

I am trying to use your library for WebAuthn flows outside of browsers. Also I am limited to not using Windows Hello and would prefer to talk to the authenticator directly.

The flow is fairly simple - get a challenge from a relying party, call fido2-token to find a device and its handle, and then use that handle to call something like cat challenge_data.txt | fido2-assert -G <device> with the above device handle and challenge data. This flow works great on Mac & Linux by the way, so thanks for the support and work done on this library. :)

However on Windows I get no output if I try running fido2-token.
Debug info:

PS C:\Users\ardi> fido2-token.exe -L -d
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: HidD_GetPreparsedData
is_fido: unsupported report len

Interestingly enough, if I run the above command in an elevated PowerShell (admin rights) I am able to get a device handle. Also I can then use the same handle to call fido2-assert and generate an assertion successfully.
In an elevated shell:

PS C:\Users\ardi> fido2-token.exe -L -d
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: unsupported report len
is_fido: HidD_GetPreparsedData
is_fido: unsupported report len
\\?\hid#vid_1050&pid_0407&mi_01#7&21a877f4&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}: vendor=0x1050, product=0x0407 (Yubico YubiKey OTP+FIDO+CCID)

I am using the latest release (1.13.0) downloaded from https://developers.yubico.com/libfido2/Releases/ on Windows 10 Enterprise 22H2.
Am I doing something entirely wrong here? Thanks in advance.

[martelletto]

Hi @apantina,

The only way to interface with a FIDO device from an unprivileged context in recent versions of Windows 10 and in Windows 11 is through Windows Hello. This is a OS-level requirement.

It's a bit strange that you aren't seeing Windows Hello in the output of fido2-token -L. Did you explicitly disable USE_WINHELLO when building?

Thank you,

-p.

[apantina]

Hi @martelletto, thanks for the quick response!
Unfortunately Windows Hello is disabled on work machines by my employer for security reasons (mostly related to PINs). I used default build flags so USE_WINHELLO was turned on.

[martelletto]

That's quite interesting. Is there an alternative mechanism for unprivileged applications (e.g. Chrome) to communicate with FIDO keys? If so, we could look into supporting it in libfido2.

[apantina]

Browsers such as Chrome and Edge work fine with FIDO2 keys via WebAuthn even with Windows Hello disabled on their respective machines.
While I am not very familiar with the underlying mechanisms, this is what pops up when I use that authentication flow via Chrome.

I can confirm that this flow uses FIDO2 (although I'm not showing the entire page and I obfuscated some parts of the above screenshot :)).

Looking into Chromium code here, it seems like they use their WebAuthN header file and API, but I don't see any direct references to Windows Hello.

[martelletto]

Oh, I see. Thanks. That dialogue comes from Microsoft's webauthn.dll, which is usually (but mistakenly) referred to as Windows Hello. We support webauthn.dll in libfido2, so it's strange that fido2-token -L did not list it as an option. It also doesn't appear to have failed, given the absence of error messages in that path. It's unclear what happened. From the debug output, it looks as if libfido2 was built without USE_WINHELLO.

[apantina]

Thanks for the clarification! For the record, I used pre-built binaries from the Releases page so I assume they had the default USE_WINHELLO value (true). I can have a go at building them myself as well just in case.

[martelletto]

An additional data point: @LDVG had a look and confirmed that the latest release image for Windows (1.13.0) was built with USE_WINHELLO.

[apantina]

Going back to your previous comment:

We support webauthn.dll in libfido2, so it's strange that fido2-token -L did not list it as an option.

Not sure if I follow - what should have been listed here exactly? A device handle or just "windows://hello"? I believe that the winhello handle wasn't listed simply because it's disabled on the machine, regardless of the fact that the binary was built with USE_WINHELLO.

Should libfido2 be able to communicate via webauthn.dll with FIDO keys in an unprivileged context then? Or is that only possible for Windows Hello?
Thanks!

[LDVG]

Apologies for the extra troubles. As a workaround, assuming you're building with shared libraries turned on, can you run

Get-ChildItem -Path "..\..\regress" -Include *.dll -Recurse | Copy-Item

from your libfido2\build\x64\dynamic\tools\Release directory and then run the tools from there?

EDIT: Missed the -Include filter...
EDIT2: To top it off: I managed to mess up the bitmask in my draft PR. You will have to fetch the latest changes for this to work properly. Sorry!

[apantina]

No worries! Copying over the DLLs worked :) I fetched the latest changes and managed to verify an assertion successfully, thank you so much for all the help!
The assert file with a raw challenge (instead of the hash):

PS C:\Users\ardi\libfido2\build\x64\dynamic\tools\Release> cat ..\..\..\..\..\..\assert.txt
a2xWalpBQUFBQUFEcThVeGpwZm5LNkhUX3VvS211TEZWWnB4Ti1PVEdOZmY1ZF84WGwtMkFSMmN5NWRWTTNoYTZtaWhveDVmSnJ2MkVSMVdWVnVSZEJHRVdUSVlxSjh0RTEzTg==
internalfb.com
SO3HEwBHH9vI7D7aEoKrAYNLJ99p9SMYHIeHL8EcrlXZem/mFPSjFSEVIsXTetNa+lvIkbXofgDScWjKvwAMSw==

Creating an assertion via fido2-assert.exe:

.\fido2-assert.exe -G -w -tpin=false -i ..\..\..\..\..\..\assert.txt windows://hello
7h/k54HhOa1NUdMfoe5J2xLmTFMtAEoAgD4JpsBv/hQ=
internalfb.com
WCX+8b41zaVs59RYeoohrljoqwHBidr6NkPD0RevZ1AHVgUAAARa
MEUCIBvje+5GAUzwZyYv9VaUD6UdafRfZlL0svRinqyiby7AAiEA814/DeSK63hrI2QEJyuEQYJv4lC0U7DWOfsv6CWdJ7M=

I have a followup question though - any idea why I get asked for my Yubikey pin? I explicitly set -tpin=false and I still get the prompt (screenshot below). I also checked the debug info and I see pin=false being output.

 .\fido2-assert.exe -G -w -d -tpin=false -i ..\..\..\..\..\..\assert.txt windows://hello
client data:
  6b 6c 56 6a 5a 41 41 41 41 41 41 44 71 38 55 78
  6a 70 66 6e 4b 36 48 54 5f 75 6f 4b 6d 75 4c 46
  56 5a 70 78 4e 2d 4f 54 47 4e 66 66 35 64 5f 38
  58 6c 2d 32 41 52 32 63 79 35 64 56 4d 33 68 61
  36 6d 69 68 6f 78 35 66 4a 72 76 32 45 52 31 57
  56 56 75 52 64 42 47 45 57 54 49 59 71 4a 38 74
  45 31 33 4e
relying party id: internalfb.com
credential id:
  48 ed c7 13 00 47 1f db c8 ec 3e da 12 82 ab 01
  83 4b 27 df 69 f5 23 18 1c 87 87 2f c1 1c ae 55
  d9 7a 6f e6 14 f4 a3 15 21 15 22 c5 d3 7a d3 5a
  fa 5b c8 91 b5 e8 7e 00 d2 71 68 ca bf 00 0c 4b
up=omit
uv=omit
pin=false
webauthn_load: api version 4
cbor_decode_assert_authdata: buf=000001BD9A647770, len=37
7h/k54HhOa1NUdMfoe5J2xLmTFMtAEoAgD4JpsBv/hQ=
internalfb.com
WCX+8b41zaVs59RYeoohrljoqwHBidr6NkPD0RevZ1AHVgUAAARe
MEYCIQDNpz8xG1gNJmhL4Ro0yK34WzlyI5lsoUztwAte8/HXSwIhAMwuYpYcmnRcgX7uw0gmRr+DGmb/TPS8TdiQZPndRwUW

The prompt:

After putting in my pin I get the user presence check, pressing the yubikey closes the prompt and fido2-assert gives me back the signed assertion.

[LDVG]

I have a followup question though - any idea why I get asked for my Yubikey pin? I explicitly set -tpin=false and I still get the prompt (screenshot below). I also checked the debug info and I see pin=false being output.

Since it's not possible for a client application to pass a PIN to the windows://hello backend (it has its own prompt), we consider it to only support "built-in" user verification methods in an attempt to map it to libfido2 concepts. Try using the -tuv=false option instead; that should discourage the backend from prompting you for a PIN.

[apantina]

Thanks for the clarification. Adding tuv=false removed the PIN prompt!

[LDVG]

Thank you for testing, I'll try to finish up that PR sometime soon.