Multiple devices support

[ondrej-krc-jediny]

With libfido2 on Windows, I tried to implement multiple FIDO device support, meaning: When multiple FIDO keys are inserted into a computer, I want to flash all of them and depending which one the user touches, that device will be used for the authentication.
I created multiple threads for this, calling fido_dev_make_cred in each of them. When one thread returns from the call, others are cancelled and fido_dev_cancel is called there. But I learned in #637 that it does not work I cannot cancel the fido_dev_make_cred this way.
Is there any other way I can implement the described behavior?
Thanks in advance.

[LDVG]

Hi,

See fido_dev_get_touch_begin(3) and fido_dev_get_touch_status(3) and examples/select.c. Note that this does not work under the windows://hello backend.

Hope that helps!

[ondrej-krc-jediny]

Thank you, that's exactly what I was looking for.

[ondrej-krc-jediny]

Related question: I have a device that gets detected both as a HID device and a smartcard (I use libfido2 with PCSC support). The device is: SafeNet eToken Fusion USB C.
Output from manifest.exe:
C:\>manifest.exe
\\?\hid#vid_08e6&pid_34d2&mi_00#7&21656d21&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}: vendor=0x08e6, product=0x34d2 (SafeNet eToken Fusion)
pcsc://slot0: vendor=0x0000, product=0x0000 (PC/SC SafeNet eToken Fusion 0)
windows://hello: vendor=0x045e, product=0x0001 (Microsoft Corporation Windows Hello)
The first and second one are really the same device.
When I use the above approach and in different threads prompt the device using fido_dev_get_touch_begin + fido_dev_get_touch_status to select a device, it works until it hangs on fido_dev_get_cbor_info (this is called in single thread only after device selection is finished). Is this approach wrong? Should I detect in advance that it is the same device and treat it either as a smartcard or as a HID device? If so, how can this be done?
Thank you.

[LDVG]

Yes, that's what examples/select.c does. It makes all currently plugged in authenticators blink until one of them is touched, using a single thread. 🙂

(Sorry, I of course meant examples/select.c and not examples/manifest.c above!)

[ondrej-krc-jediny]

Thanks, I'll look into it. So you think that removing threads in the selection phase may resolve my subsequent problem with hanging fido_dev_get_cbor_info?

[LDVG]

Maybe? There's nothing in libfido2 that should cause fido_dev_get_cbor_info() to hang. 🙂

That said, devices that expose multiple interfaces at the same time are a bit of an unknown. This is part of the reason USE_PCSC is disabled by default.

Try running the example.

[ondrej-krc-jediny]

Well the documentation says fido_dev_get_cbor_info() may block :) I'm not sure for how long or under what circumstances.
I will try the example, thanks again.

[LDVG]

Yes, sorry, all fido_dev_*() may block for a period of time while waiting for the device to respond. Since authenticatorGetInfo does not require any tests of user presence, it should be fairly quick and should not hang for any longer period of time. You can provide a timeout if you so wish.

[ondrej-krc-jediny]

I tested the select example with interesting results, describing them here in case anybody would like to debug it further (now I'm talking only about libfido2 code, not my code).
I tested examples/select.c (where I filtered out Windows Hello) with two keys:

1. SafeNet eToken Fusion USB C (the one detected both as HID and PCSC)
2. YubiKey Bio - FIDO Edition (but any would serve as an additional device)

The behavior is demonstrated the best in the attached video.

fido.mp4

If I select device 2, nothing happens until I also touch device 1 (or wait 30 seconds).
The example gets stuck at fido_dev_get_touch_begin (it gets called 3 times - twice for device 1, once for device 2). Even if I set fido_dev_set_timeout before calling fido_dev_get_touch_begin, the behavior does not change.

[LDVG]

I'd again like to mention that -DUSE_PCSC=ON is only experimental and we do not recommend running with it enabled at this time. My best guess is that since your device is enumerating on two different interfaces, that there's some kind of implementation-specific internal lock preventing us to talk to it from concurrently. If this is the case, there's not much we can do in libfido2 itself. You'll have to reach out to the manufacturer for further information.

EDIT: Actually, the smart card interface is blocking by nature. We do not (and I don't know if your authenticator does either) support NFCCTAP_GETRESPONSE required for "asynchronous" communication. This is fine for contactless/NFC readers, but the behavior for for CCID is not clearly defined. We are waiting for the specification to clarify some of these things. This would be my new best guess. I'd suggest either turning PCSC off or filtering out PCSC devices that you do not know are NFC readers. Similarly, you may have to exclude the windows://hello pseudo-device, that will not work either.

Please provide debug output.

Does it work correctly if you build with -DUSE_PCSC=OFF?

[ondrej-krc-jediny]

Attaching debug log (while doing the same as in the video above): debugLog.txt. The place where it blocks is commented in the file.
Yes, it works correctly -DUSE_PCSC=OFF, then device 1 acts as a regular HID device and all works well.

I'd again like to mention that -DUSE_PCSC=ON is only experimental and we do not recommend running with it enabled at this time.

I understand that. If you feel there's nothing further to gain from investigating this at this stage, I'm happy to leave it here. Thanks again for all your help and insights.

[LDVG]

Thanks!

Yep, as expected, we're blocking on the request for a touch over PCSC. We are aware of the problem, especially as an ambiguity in the CTAP specification on how this is supposed to be handled for "contact-based" cards. The only asynchronous way to do this is through NFCCTAP_GETRESPONSE which is an optional feature that we cannot test support for before it's "too late". We hope that these parts of the specification will be clarified in future iterations and will investigate how to improve our API accordingly.

(I'd also like to add that, unfortunately, as you've also noticed, the PCSC API used internally does not easily provide a way for us to enforce a timeout. We're happy for suggestions, but there's quite a few obstacles here.)

Finally, thank you very much for the interesting discussions and ideas!