fido_cred_verify_self: FIDO_ERR_INVALID_ARGUMENT for windows hello

[michael-dev]

What version of libfido2 are you using?

OpenSSH 9.8p1 (for sure) / libfido2 1.15.0 (as far as i can tell)

What operating system are you running?

Windows 11

What application are you using in conjunction with libfido2?

openssh portable

How does the problem manifest itself?

I cannot create an windows hello backed SSH key
Windows Hello says "master key saved successfully", but ssh-keygen subsequently fails:

Is the problem reproducible?

Yes

What are the steps that lead to the problem?

 .\ssh-keygen -t  ecdsa-sk -vvvvv
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: find_helper: using "...\\Downloads\\OpenSSH-Win32\\OpenSSH-Win32\\ssh-sk-helper.exe" as helper
debug3: spawning "...\\Downloads\\OpenSSH-Win32\\OpenSSH-Win32\\ssh-sk-helper.exe" as subprocess
debug3: start_helper: started pid=18844
debug3: ssh_msg_send: type 5 len 50
debug3: ssh_msg_send: done
debug3: ssh_msg_recv entering
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", userid "(null)", flags 0x01, challenge len 0
debug1: sshsk_enroll: using random challenge
webauthn_load: api version 7
debug1: ssh_sk_enroll: using device windows://hello
cbor_decode_cred_authdata: buf=030A4B58, len=164
0000: e3 06 10 e8 a1 62 11 59 60 fe 1e c2 23 e6 52 9c
0016: 9f 4b 6e 80 20 0d cb 5e 5c 32 1c 8a f1 e2 b1 bf
0032: 45 00 00 00 00 08 98 70 58 ca dc 4b 81 b6 e1 30
0048: de 50 dc be 96 00 20 be fa 9b 88 6d 9c 1c 73 6b
0064: 53 4b 77 43 67 9e 8b b7 8a be 60 4d c3 03 73 da
0080: 12 99 04 51 5f bc fc a5 01 02 03 26 20 01 21 58
0096: 20 2b 7b 1f ee f5 9e 41 d3 eb 77 60 fa c3 ac 70
0112: b5 df 58 b5 44 80 fb 5e 18 6d 67 4f 6e 35 6e ca
0128: 68 22 58 20 f2 09 5e b8 b0 df 1b e3 28 c5 5c 52
0144: 15 06 41 83 fe dc 79 2f 91 8c ba 71 cb 1e 9e b1
0160: 0f 8c 89 96
decode_attcred: buf=030A4B7D, len=127
0000: 08 98 70 58 ca dc 4b 81 b6 e1 30 de 50 dc be 96
0016: 00 20 be fa 9b 88 6d 9c 1c 73 6b 53 4b 77 43 67
0032: 9e 8b b7 8a be 60 4d c3 03 73 da 12 99 04 51 5f
0048: bc fc a5 01 02 03 26 20 01 21 58 20 2b 7b 1f ee
0064: f5 9e 41 d3 eb 77 60 fa c3 ac 70 b5 df 58 b5 44
0080: 80 fb 5e 18 6d 67 4f 6e 35 6e ca 68 22 58 20 f2
0096: 09 5e b8 b0 df 1b e3 28 c5 5c 52 15 06 41 83 fe
0112: dc 79 2f 91 8c ba 71 cb 1e 9e b1 0f 8c 89 96
decode_attcred: attcred->id.len=32
debug1: ssh_sk_enroll: self-attested credential
fido_cred_verify_self: cdh=03070EF0, authdata=030B2298, x5c=00000000, sig=00000000, fmt=03061DA0 id=030A29A8, rp.id=ssh:
debug1: ssh_sk_enroll: fido_cred_verify_self: FIDO_ERR_INVALID_ARGUMENT
debug1: sshsk_enroll: provider "internal" failure -1
debug1: ssh-sk-helper: Enrollment failed: invalid format
debug1: main: reply len 8
debug3: ssh_msg_send: type 5 len 8
debug3: ssh_msg_send: done
debug1: client_converse: helper returned error -4
debug3: reap_helper: pid=18844
Key enrollment failed: invalid format

The issue is the attstmt.sig==NULL in the object created.
From the output, this happens in https://github.com/openssh/openssh-portable/blob/V_9_8_P1/sk-usbhid.c#L966 calling https://github.com/Yubico/libfido2/blob/main/src/cred.c#L451
As the verify code hasn't really changed at all, it must be something different.

Does the problem happen with different authenticators?

I've cleared windows hello for my user and recreated it, but the problem persists.

Affects other users as well:

• SSH-KEYGEN returns ''invalid format" when generating ecdsa-sk key and storing it on another device PowerShell/Win32-OpenSSH#2279
• Cannot create ecdsa-sk key with Windows Hello in ssh-keygen PowerShell/Win32-OpenSSH#2040

fido2-token -L

run_manifest: found 0 hid devices
webauthn_load: api version 7
run_manifest: found 1 winhello device
windows://hello: vendor=0x045e, product=0x0001 (Microsoft Corporation Windows Hello)

./fido2-token -I windows://hello
webauthn_load: api version 7
proto: 0x00
major: 0x00
minor: 0x00
build: 0x00
caps: 0x05 (wink, cbor, msg)
version strings: U2F_V2, FIDO_2_0, FIDO_2_1_PRE
extension strings: credProtect, hmac-secret
transport strings: nfc, usb
aaguid: 00000000000000000000000000000000
options: rk, up, uv, plat
fwversion: 0x0
maxmsgsiz: 0
maxcredcntlst: 0
maxcredlen: 0
maxcredblob: 0
maxlargeblob: 0
fido_tx: dev=000002A0C53F0C60, cmd=0x10
fido_tx: buf=000002A0C53F91D0, len=6
0000: 06 a2 01 01 02 01
fido_tx: invalid argument
fido_dev_get_retry_count_tx: fido_tx
pin retries: undefined
pin change required: false
fido_tx: dev=000002A0C53F0C60, cmd=0x10
fido_tx: buf=000002A0C53F9160, len=6
0000: 06 a2 01 01 02 07
fido_tx: invalid argument
fido_dev_get_retry_count_tx: fido_tx
uv retries: undefined
fido_tx: dev=000002A0C53F0C60, cmd=0x10
fido_tx: buf=000002A0C53F9150, len=6
0000: 40 a2 01 01 02 07
fido_tx: invalid argument
bio_tx: fido_tx
bio_get_info_wait: tx/rx

[LDVG]

Hi,

Am I understanding it correctly that you're trying to use a built-in authenticator (e.g. a TPM) in conjunction with the windows://hello backend?

From the looks of it, there's no (or an incomplete?) attestation statement returned from webauthn.dll despite us requesting "direct" attestation. Perhaps the authenticator does not support attestation and returns the "none" attestation format. If that is the case, there is little for us to verify.

Could you please show us the output of

$ ./fido2-cred -M -wdi cred_param windows://hello

where cred_param is a file with the following contents:

c29tZSBjbGllbnQgZGF0YQ==
localhost
user
dqRATYz4H4A1wzUAiytJ3hfUbejxX+ZAP1KT1u8MEzA=

It would help us gain more insight into the authenticator. Thanks!

[michael-dev]

Hi

Am I understanding it correctly that you're trying to use a built-in authenticator (e.g. a TPM) in conjunction with the windows://hello backend?

that is correct.

The output is as follows:

.\fido2-cred -M -wdi cred_param windows://hello
client data:
  73 6f 6d 65 20 63 6c 69 65 6e 74 20 64 61 74 61
relying party id: localhost
user name: user
user id:
  76 a4 40 4d 8c f8 1f 80 35 c3 35 00 8b 2b 49 de
  17 d4 6d e8 f1 5f e6 40 3f 52 93 d6 ef 0c 13 30
webauthn_load: api version 7
cbor_decode_cred_authdata: buf=00000186BEBD5E80, len=164
0000: 69 98 58 6a c1 be 5c 97 a5 2f 41 51 0a 35 b0 30
0016: fe 39 ff 3b 15 c6 a8 0b 46 89 45 74 a9 ab 84 36
0032: 45 00 00 00 00 08 98 70 58 ca dc 4b 81 b6 e1 30
0048: de 50 dc be 96 00 20 fa b8 63 fb d0 ed 61 9b a3
0064: f6 86 19 83 29 93 3e 57 b1 ca df 1c 40 22 a8 97
0080: 01 d1 95 23 a7 1f 66 a5 01 02 03 26 20 01 21 58
0096: 20 b8 57 f4 d6 9f 8e 03 cd a9 92 ae 7c b6 71 0d
0112: 0b 15 f1 1b ad 7c 90 d3 54 07 fb fc 8f ce 20 44
0128: c6 22 58 20 c3 b7 ad 82 eb af 42 17 f9 4d 07 d3
0144: b5 1b 82 68 b2 9d c0 22 09 52 85 66 8e ef c3 17
0160: df e0 2b e6
decode_attcred: buf=00000186BEBD5EA5, len=127
0000: 08 98 70 58 ca dc 4b 81 b6 e1 30 de 50 dc be 96
0016: 00 20 fa b8 63 fb d0 ed 61 9b a3 f6 86 19 83 29
0032: 93 3e 57 b1 ca df 1c 40 22 a8 97 01 d1 95 23 a7
0048: 1f 66 a5 01 02 03 26 20 01 21 58 20 b8 57 f4 d6
0064: 9f 8e 03 cd a9 92 ae 7c b6 71 0d 0b 15 f1 1b ad
0080: 7c 90 d3 54 07 fb fc 8f ce 20 44 c6 22 58 20 c3
0096: b7 ad 82 eb af 42 17 f9 4d 07 d3 b5 1b 82 68 b2
0112: 9d c0 22 09 52 85 66 8e ef c3 17 df e0 2b e6
decode_attcred: attcred->id.len=32
output error

Thanks!

[LDVG]

Oh, fido2-cred aborted earlier than I thought it would.

Do you have a build of our examples? If so, what happens if you run the cred example with the following parameters

$ $Env:FIDO_DEBUG = 1
$ .\cred windows://hello

[michael-dev]

I've got libfido2-1.15.0-win.zip only.

[LDVG]

OK!

In my virtual Windows 11 box, if I attempt to create a credential using a simulated TPM, I get the same behavior as you. If I run the cred.exe example binary, I can see the following output

$ $Env:FIDO_DEBUG = 1
$ .\cred windows://hello
<debug log omitted>
no attestation data, skipping credential verification

Which means that the authenticator replied with "fmt": "none" (or at least that is what webauthn.dll returned to us). There's no signature for libfido2 to verify in this case and it's up the the application, in this case OpenSSH, to decide whether that's acceptable.

I get the exact same behavior in e.g. Chrome when registering with "direct" attestation on https://demo.yubico.com/webauthn-developers -- no attestation statement is returned.

We might go ahead and add more debug statements to the windows://hello output to make this easier to diagnose in the future, but for now I'll be closing this as it's not a bug in libfido2. If you or anyone else reach another conclusion, feel free to reopen this issue.

Thanks for reporting!