How to identify the FIDO2 devices consistently

[EvgeneOskin]

Hi,

At Termius, we implemented FIDO2 support using libfido2 for SSH connections and faced a UX problem.
The Termius desktop app allows users to select devices via UI and show all attached FIDO2 devices so the user can select specific devices, e.g., one Yubikey out of several. So far, the Termius desktop app shows the vendor and product names from libfido2.

On the screenshot, I have Yubikey 5Ci, Yubikey 5 NFC, SoloKey, and OnlyKey connected. I cannot tell which FIDO2 device is Yubikey 5Ci or Yubikey 5 NFC both are YubiKey OTP+FIDO+CCID.

We've looked at Yubkey Manager and found that each Yubikey has a serial number. So we could use it but want to use a vendor-agnostic API, e.g., implemented by libfido2.

My questions so far are:

• What would be the recommended approach for showing all FIDO2 devices in the app?
• Is there a way to get serial numbers for FIDO2 devices using libfido2? If there is no at the moment, can such APIs be added to libfido2?

Cheers,
Eugene

[nuno0529]

https://w3c.github.io/webauthn/#sctn-privacy-attacks
IMHO, I don't think use serial numbers is a good approach if you are targeting FIDO2 devices.
And I will suggest to use AAGUID of getInfo's response for different models by using FIDO's MDS3 services or maintain a key-value map of them likes
https://support.yubico.com/hc/en-us/articles/360016648959-YubiKey-Hardware-FIDO2-AAGUIDs
https://github.com/opotonniee/fido-mds-explorer (just a quick link website, not formal website of FIDO MDS3)

[EvgeneOskin]

Got it. Thanks, @martelletto!

[ntwerdochlib]

So what would be suggested method for identifying a specific fido2 device if say two or more identical devices are installed? I am trying to emulate what Windows Hello does, where in this scenario it is able to detect that the correct device is installed. I am sure this based on the serial number, as I believe it gets added to the device node.

[LDVG]

@ntwerdochlib: Could you share more details about what you are trying to accomplish? In my testing with Windows Hello, I am prompted to touch the authenticator I would like to use if multiple ones are present.

[ntwerdochlib]

@LDVG: Had my head so deep in this on Friday... my comment seemed full of detail; to me...

Assumptions:

1. Multiple FIDO2 devices are installed
2. At least two of them are the exact same hardware
3. The two identical FIDO2 devices have a PIN set

Under Windows Hello, if you start an assertion request with more then one key inserted, you will be prompted to select the device to use. One device is then selected. Windows Hello will then prompt you for the PIN. Before pressing Ok on the PIN dialog, remove the selected device, then press Ok

At this point, Windows Hello will prompt you to reinsert your device. This is where it gets pretty interesting, as Windows Hello seems to be able to determine when you have inserted the expected device. I think I even tested reinserting the other identical device and it is able to detect that it is not the expected device.

Windows is storing some "value" in the instance id which I thought might be the serial number, but that value seems to also change.

My logic for handling this under Linux/Mac is currently waiting for a device with same vendor/product id to be reinserted. This will lead to a failure if an identical device is inserted that does not have an expected RPID and Credential ID.

A Wireshark USB capture does show that a vendor specific 0x7f command is being sent to the device, but I don't think this is Yubico proprietary serial number request command. I have about 8 FIDO2 keys for testing with, but all of them are Yubico since that is what we are advertising as currently supported devices.

[LDVG]

Thank you for the added context!

When I try this, it seems to me that Windows is only relying on the interface path which seemingly depends on the port I plug the authenticator into? On my system (FYI, a virtual machine), I tried the following:

1. Insert three identical devices; each with a unique PIN.
2. Attempt to get an assertion.
3. Get prompted to select a device; select authenticator #3.
4. Get prompted for PIN; do not press OK.
5. Remove authenticator #2 and #3 from the system.
6. Press OK on PIN prompt; get prompted to reinsert device.
7. Insert authenticator #3 into #2's old slot; insert #2 into #3's slot.
8. Assertion fails with "Incorrect PIN".

If I were to implement my own logic, I'd probably just try to send the request and then retry the whole ceremony on failure (e.g. device is no longer reachable), either automatically if you have found a reliable way to detect this situation, or manually upon user request.