fido2: user verification switch "-v" causes fido2-cred to return FIDO_ERR_UNSUPPORTED_OPTION when device has no biometric function

[GaelC92]

default compilation results in the output below, with reported error 'FIDO_ERR_UNSUPPORTED_OPTION'

$ gocryptfs -init -d -fido2="IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice" foo.gocryptfs
OpenSSL disabled, using Go GCM
FIDO2 Register: interact with your device ...
callFidoCommand: executing "/usr/local/bin/fido2-cred" with args [fido2-cred -M -h -v IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice]
fido2-cred: fido_dev_make_cred: FIDO_ERR_UNSUPPORTED_OPTION
fido2-cred failed with exit status 1

calling the reported command line shows that the space in the device string is the troublemaker [Edit : wrong assumption. -v was the root cause]
$ fido2-cred -M -h -v IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice
fido2-cred: unknown type OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice

I added the patch below to the brew formula in order to have the space escaped :

inreplace "./internal/fido2/fido2.go",
          " device)",
          ' fmt.Sprintf("%s",strings.ReplaceAll(device," ","\\\\\\\\ ")))'

results after the patch : the space is now escaped, and the reported error changed to 'FIDO_ERR_INTERNAL'

$ gocryptfs -init -d -fido2="IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice" foo.gocryptfs
OpenSSL disabled, using Go GCM
FIDO2 Register: interact with your device ...
callFidoCommand: executing "/usr/local/bin/fido2-cred" with args [fido2-cred -M -h -v IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey\ OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice]
fido2-cred: fido_dev_open IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey\ OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice: FIDO_ERR_INTERNAL
fido2-cred failed with exit status 1

invoking fido2-creds with the latest reported command line does not report any error. I'm still investigating to find what goes wrong.

[rfjakob]

Hi, gocryptfs actually runs

fido2-cred -M -h -v "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice"

can you check what you get when you run this in the shell?

I have updated the debug output to show that in 015cd06 .

[GaelC92]

Hi, here is the debug output (this is the head code) :

gocryptfs -init -d -fido2="IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice" foo.gocryptfs
OpenSSL disabled, using Go GCM
FIDO2 Register: interact with your device ...
callFidoCommand: executing "/usr/local/bin/fido2-cred" with args ["fido2-cred" "-M" "-h" "-v" "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice"]
fido2-cred: fido_dev_make_cred: FIDO_ERR_UNSUPPORTED_OPTION
fido2-cred failed with exit status 1

gocryptfs --version
gocryptfs [unknown]; go-fuse v2.1.1-0.20210508151621-62c5aa1919a7; 2021-06-05 go1.16.4 darwin/amd64

[GaelC92]

When run in the shell, the command fido2-cred -M -h -v "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice" there is no reported error, although the call would need input and output files, so it just stays there waiting.

I wonder if the following thread systemd/systemd#17784 is not related to the problem, since I use a yubikey 5 NFC, and the -v switch is requested

I checked that the fido2 lib works properly by following the example of the fido2-cred man page :
$ echo credential challenge | openssl sha256 -binary | base64 > cred_param
$ echo relying party >> cred_param
$ echo user name >> cred_param
$ dd if=/dev/urandom bs=1 count=32 | base64 >> cred_param
$ fido2-cred -M -i cred_param "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS05@14200000/YubiKey OTP+FIDO+CCID@14200000/IOUSBHostInterface@1/AppleUserUSBHostHIDDevice" | fido2-cred -V -o cred

[GaelC92]

Ok, I confirm that removing the "-v" switch is enough to make it work.

for those that may be insterested in working around this, I added the following block to the brew formula :

inreplace "./internal/fido2/fido2.go",
          ' "-v",',
          ''

[rfjakob]

From man fido2-cred:

     -v      If making a credential, request user verification.  If verifying a credential, check
             whether the user verification bit was signed by the authenticator.

This looks kinda important :)

Why doesn't your fido2-cred have this option? Maybe an older version? I have fido2-tools-1.6.0-2.fc34.x86_64 here.

[GaelC92]

my libfido2 is 1.7.0.

On my Yubikey 5, removing the -v switch from the command line does NOT bypass the need to touch the yubikey in order to decrypt.

However, I can't tell if -v is required for biometric devices, since I have none.

Below, I quote some excerpts from the link I mentioned above, which explain the reason for the error. Basically it's because user verification (-v switch) is related to biometry functions, which are not necessarily present :

"The unsupported option in this case is likely UV, which is set to false in https://github.com/systemd/systemd/blob/master/src/home/homectl-fido2.c#L253. YubiKeys do not support UV, only PIN. Older YubiKeys ignore the UV parameter. Newer YubiKeys return FIDO_ERR_UNSUPPORTED_OPTION if UV is set to anything other than FIDO_OPT_OMIT, since that is the normative behaviour defined in the CTAP2 spec."

(...)

"clientPin and uv are separate options in CTAP2 (second table). clientPin is defined as "the device is capable of accepting a PIN from the client". uv is defined as "the device is capable of verifying the user within itself. For example, devices with UI, biometrics fall into this category". Both achieve the same thing: when creating a credential, the UV bit is set in the signed data returned by the authenticator.

The spec defines the steps an authenticator is expected to follow when creating a credential. Step 3 reads:

If the options parameter is present, process all the options. If the option is known but not supported, terminate this procedure and return CTAP2_ERR_UNSUPPORTED_OPTION. If the option is known but not valid for this command, terminate this procedure and return CTAP2_ERR_INVALID_OPTION. Ignore any options that are not understood. Note that because this specification defines normative behaviors for them, all authenticators MUST understand the "rk", "up", and "uv" options.
which is why newer YubiKeys return FIDO_ERR_UNSUPPORTED_OPTION if uv is set to either true (explicitly enabled) or false (explicitly disabled)."

[EDIT] : re-reading this, it appears that specifying -v might be needed when calling libfido2 with a biometry-providing authentication device, but should not be used otherwise. If that is the case, then the use of "user verification" (in the strict meaning explained above) should probably become a cli option of gocryptfs.

[EDIT 2] : a call to "fido2-token -I " (uppercase i) could also be used to check device capabilities and construct the args list accordingly before calling fido2-cred"

[rfjakob]

@prusnak what do you think, can we drop the "-v" flag to fido2-cred ?

[prusnak]

I think this is a bug in Yubikey and or libfido2 interaction with Yubikey. I'd keep -v because we want to verify user's presence.