Yubico
fido2-cred: -v causes FIDO_ERR_UNSUPPORTED_OPTION?
What version of libfido2 are you using? 1.16.0
What operating system are you running? Win10-22h2
What application are you using in conjunction with libfido2? fido2-cred
How does the problem manifest itself?
with the command line $input | fido2-cred -M -v -r -h -c 1 \\?\hid#vid_096e&pid_0858#6&2c581fce&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} it throws out fido_dev_make_cred: FIDO_ERR_UNSUPPORTED_OPTION
which is weird as according to the docs -v only should force it to ask for PIN and stuff
https://developers.yubico.com/libfido2/Manuals/fido2-cred.html#v
without using the flag, it just goes to ask for PIN anyway.
Is the problem reproducible? so far yes
What are the steps that lead to the problem? -v option in fido2-cred, all other options seem fine
Does the problem happen with different authenticators? not sure yet, some it seems to work with others not.
Please include the output of fido2-token -L.
fido2-token -L
$ fido2-token -L
\\?\hid#vid_096e&pid_0858#6&2c581fce&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}: vendor=0x096e, product=0x0858 (FT FIDO)
windows://hello: vendor=0x045e, product=0x0001 (Microsoft Corporation Windows Hello)
Please include the output of fido2-token -I.
fido2-token -I
$ fido2-token -I <device> proto: 0x02 major: 0x01 minor: 0x00 build: 0x01 caps: 0x07 (wink, cbor, msg) version strings: U2F_V2, FIDO_2_0, FIDO_2_1_PRE extension strings: credProtect, hmac-secret transport strings: usb algorithms: es256 (public-key) aaguid: 833b721aff5f4d00bb2ebdda3ec01e29 options: rk, up, noplat, clientPin, credentialMgmtPreview fwversion: 0x0 maxmsgsiz: 2048 maxcredcntlst: 10 maxcredlen: 96 maxcredblob: 0 maxlargeblob: 0 pin protocols: 1 pin retries: 8 pin change required: false uv retries: undefined
Please include the output of FIDO_DEBUG=1.
FIDO_DEBUG=1
fido_tx: dev=0000019C69D87BD0, cmd=0x06 fido_tx: buf=0000019C69D87BD0, len=8 0000: d3 aa df 11 ee 2d fc 34 fido_rx: dev=0000019C69D87BD0, cmd=0x06, ms=-1 rx_preamble: buf=0000000F871CF630, len=64 0000: ff ff ff ff 86 00 11 d3 aa df 11 ee 2d fc 34 00 0016: 00 00 0a 02 01 00 01 07 00 00 00 00 00 00 00 00 0032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 rx: payload_len=17 fido_rx: buf=0000019C69D87BD8, len=17 0000: d3 aa df 11 ee 2d fc 34 00 00 00 0a 02 01 00 01 0016: 07 fido_dev_get_cbor_info_tx: dev=0000019C69D87BD0 fido_tx: dev=0000019C69D87BD0, cmd=0x10 fido_tx: buf=0000000F871CF680, len=1 0000: 04 fido_dev_get_cbor_info_rx: dev=0000019C69D87BD0, ci=0000019C69D8E580, ms=-1 fido_rx: dev=0000019C69D87BD0, cmd=0x10, ms=-1 rx_preamble: buf=0000000F871CF5A0, len=64 0000: 00 00 00 0a 90 00 a9 00 aa 01 83 66 55 32 46 5f 0016: 56 32 68 46 49 44 4f 5f 32 5f 30 6c 46 49 44 4f 0032: 5f 32 5f 31 5f 50 52 45 02 82 6b 63 72 65 64 50 0048: 72 6f 74 65 63 74 6b 68 6d 61 63 2d 73 65 63 72 rx: payload_len=169 rx: buf=0000000F871CF5A0, len=64 0000: 00 00 00 0a 00 65 74 03 50 83 3b 72 1a ff 5f 4d 0016: 00 bb 2e bd da 3e c0 1e 29 04 a5 62 72 6b f5 62 0032: 75 70 f5 64 70 6c 61 74 f4 69 63 6c 69 65 6e 74 0048: 50 69 6e f5 75 63 72 65 64 65 6e 74 69 61 6c 4d rx: buf=0000000F871CF5A0, len=64 0000: 00 00 00 0a 01 67 6d 74 50 72 65 76 69 65 77 f5 0016: 05 19 08 00 06 81 01 07 0a 08 18 60 09 81 63 75 0032: 73 62 0a 81 a2 63 61 6c 67 26 64 74 79 70 65 6a 0048: 70 75 62 6c 69 63 2d 6b 65 79 00 00 00 00 00 00 fido_rx: buf=0000019C69D9C2E0, len=169 0000: 00 aa 01 83 66 55 32 46 5f 56 32 68 46 49 44 4f 0016: 5f 32 5f 30 6c 46 49 44 4f 5f 32 5f 31 5f 50 52 0032: 45 02 82 6b 63 72 65 64 50 72 6f 74 65 63 74 6b 0048: 68 6d 61 63 2d 73 65 63 72 65 74 03 50 83 3b 72 0064: 1a ff 5f 4d 00 bb 2e bd da 3e c0 1e 29 04 a5 62 0080: 72 6b f5 62 75 70 f5 64 70 6c 61 74 f4 69 63 6c 0096: 69 65 6e 74 50 69 6e f5 75 63 72 65 64 65 6e 74 0112: 69 61 6c 4d 67 6d 74 50 72 65 76 69 65 77 f5 05 0128: 19 08 00 06 81 01 07 0a 08 18 60 09 81 63 75 73 0144: 62 0a 81 a2 63 61 6c 67 26 64 74 79 70 65 6a 70 0160: 75 62 6c 69 63 2d 6b 65 79 fido_dev_open_rx: FIDO_MAXMSG=2048, maxmsgsiz=2048 fido_tx: dev=0000019C69D87BD0, cmd=0x10 fido_tx: buf=0000019C69D85AB0, len=219 0000: 01 a6 01 58 20 3c 6b 1d 2a 0f d1 a1 b6 42 eb 52 0016: 87 9f 3d f3 df 92 14 08 2a 97 25 3b 5b 50 8e cc 0032: 8d 3f 7b 1d 1c 02 a1 62 69 64 73 6c 6f 67 69 6e 0048: 2e 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d 03 a2 0064: 62 69 64 58 33 4f 46 3a 91 4b 92 8d 86 6c 92 49 0080: 9d 55 46 4b f6 81 bc 41 b6 6b 97 f6 f6 ab a9 85 0096: 75 ca 63 c3 92 5c 73 bd 98 ae 89 57 23 b9 f2 c4 0112: bf 1e 50 49 7d 36 36 9c 64 6e 61 6d 65 78 1e 74 0128: 74 65 73 74 65 72 40 33 62 67 62 34 79 2e 6f 6e 0144: 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d 04 81 a2 0160: 63 61 6c 67 26 64 74 79 70 65 6a 70 75 62 6c 69 0176: 63 2d 6b 65 79 06 a2 6b 63 72 65 64 50 72 6f 74 0192: 65 63 74 01 6b 68 6d 61 63 2d 73 65 63 72 65 74 0208: f5 07 a2 62 72 6b f5 62 75 76 f5 fido_rx: dev=0000019C69D87BD0, cmd=0x10, ms=-1 rx_preamble: buf=0000000F871CF680, len=64 0000: 00 00 00 0a 90 00 01 2b 00 00 00 00 00 00 00 00 0016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 rx: payload_len=1 fido_rx: buf=0000019C69D9DB00, len=1 0000: 2b cbor_parse_reply: blob[0]=0x2b fido_dev_make_cred_rx: parse_makecred_reply fido_dev_make_cred: FIDO_ERR_UNSUPPORTED_OPTION
Thanks for reaching out! The documentation is indeed slightly misleading in this case; fido2-cred -M -v can only request built-in user verification (in contrast to fido2-assert -G -v which prefers ClientPIN for historical reasons). We should probably add support for -t ^1 in fido2-cred also.
oh interesting, especially as some FIDO2 devices seem to just silently ignore the bio-uv flag, however that is supposed to handle under the hood I dont exactly know and just go and ask for client PIN, that is behavior allowed in CTAP2 or would that be something that the maker needs to fix?
oh interesting, especially as some FIDO2 devices seem to just silently ignore the bio-uv flag, however that is supposed to handle under the hood I dont exactly know and just go and ask for client PIN, that is behavior allowed in CTAP2 or would that be something that the maker needs to fix?
I believe the specification says that the authenticator must return CTAP2_ERR_INVALID_OPTION.
Our implementation asks for PIN when the authenticator returns CTAP2_ERR_PUAT_REQUIRED (aka CTAP2_ERR_PIN_REQUIRED back in CTAP 2.0). It used to be the case that a make credential operation always required some form of user verification (PIN or built-in) if one was configured, which is why the -v toggle only concerns itself with changing the preference from PIN to built-in UV. This has (conditionally) changed in later versions of the specification.
lol then BOTH are wrong XD unless invalid gets auto-checked and resolved by fido2-cred (which I dont assume), would need to try with more keys.
is there still a way to force clientPIN when using fido2-cred, also documentation should maybe be specific about whether user verification is meant as a generalized term (which includes clientpin) or specifially inbuilt UV (like fingerprints or on screen PIN entry on the authenticator itself).
is there still a way to force clientPIN when using fido2-cred, also documentation should maybe be specific about whether user verification is meant as a generalized term (which includes clientpin) or specifially inbuilt UV (like fingerprints or on screen PIN entry on the authenticator itself).
No, not as of today. Your authenticator should always require user verification because it has a PIN set and doesn't support makeCredUvNotReqd, though. You can check that some form of UV (incl. ClientPIN) was used by passing -v to fido2-cred -V still.
We'll try to improve both the tooling and documentation.
with that specific authenticator yes, the script has been primarily used with ones that do support that option. we dont run -V so far as the credential made is submitted to an API to just enroll FIDO keys in bulk without involving win hello (as that would be a pain) to users.
but as far as I read that only works on non-resident credentials so as -r is an option that is required anyway provided the thing has a PIN set it should let you through, I honestly havent tried making resident keys on FIDO keys without a PIN set using fido2-cred yet, as it seems kinda cursed.
but as far as I read that only works on non-resident credentials so as -r is an option that is required anyway provided the thing has a PIN set it should let you through, I honestly havent tried making resident keys on FIDO keys without a PIN set using fido2-cred yet, as it seems kinda cursed.
Yes, the authenticator must deny creating discoverable credentials without the user also having configured some form of user verification.