Potential Suggestion - Device paths are not persistent on MacOS.

[jdngray77]

Hi!

We're consuming this library in production through a custom C# wrapper and have come across a potentially solvable issue. Whilst we can work around it, i thought i would raise it as a potential improvement.

This is a question / suggestion surrounding how devices are identified on MacOS. I'll start with the problem we were seeing in production, what seems to be the root cause, and the suggestion.

With that said, I'm a high level (C#) developer with no effective experience with C, so I cannot really gauge the scope of this change, or it's impact on the rest of the library - if any - so this suggestion could be a nightmare to implement for all I know! For this reason i'm opening this as a Q&A discussion first to seek more insight, and see if this change is even possible.

---

The Scenario

Our cross-platform MacOS and Windows app is issuing FIDO Passkeys onto physical fido devices.

Whilst doing this, there is a scenario whereby the user is expected to unplug, then plug back in, the Yubikey device - i'll refer to this from now as 're-seating'.

The scenario is effectively the following:

• Have a Yubikey device with a PIN set already.
• PIN attempts remaining is high, i.e 9.
• Attempt to issue a new FIDO passkey to the device
• The user types thier PIN wrong a few times (i.e 3). The device still has attempts remaining, but becomes temporarily locked and must be re-seated before more attempts may be made.
• The application prompts the user to do so.

Windows

• On windows, the application is able to maintain communication with the device using the same Device Path despite temporarily losing connection.

MacOS

• On MacOS, the device path used for identifying the device is invalidated as soon as the device is unplugged.
• The user attempts to continue, and we receive -9 / InternalError from subsequent calls because the device path we were using now no longer exists.

To summarise, there is a difference in behaviour between MacOS and Windows to be found in the device paths. When a device is re-seated, the path on windows does not change, but on MacOS it does.

We can work around this on MacOS by detecting the platform we're running under and re-selecting / re-identifying the device after re-insertion, but this isn't fully ideal and carries a non-zero risk of accidentally selecting a different device from the one that originally selected whilst part-way through the issuance process, breaking our issuance pattern where the device should be selected up-front, which we would also need to account for, and could also end up being a source of confusion.

---

The root cause

The Yubikey device appears to be identified by get_path in hid_osx.c using it's corresponding entry into IOKit's IO Registry.

Example:

Our test harness reports the device as ioreg://4296533010

Converting this number to hex, we get 10017E412

We can peek the IO registry using ioreg -b -r -n "YubiKey OTP+FIDO+CCID" -t -i in bash.

...
 +-o IOUSBHostInterface@1  <class IORegistryEntry:IOService:IOUSBInterface:IOUSBHostInterface, id 0x10017e409, registered, matched, active, busy 0 (24 ms), retain 16>
                  | +-o AppleUserUSBHostHIDDevice  <class IORegistryEntry:IOService:IOHIDDevice:AppleUserHIDDevice, id 0x10017e412, registered, matched, active, busy 0 (10 ms), retain 17>
                  | | +-o IOHIDInterface  <class IORegistryEntry:IOService:IOHIDInterface, id 0x10017e41c, registered, matched, active, busy 0 (7 ms), retain 6>
...

And sure enough we can spot the corresponding hex ID in the registry under the entry for interface 1 on my device, which i assume is the fido interface.

The problem lies with how the library is using the ID of this registry entry, which does not persist when the device is re-seated.

It seems when the device is re-seated, IOKit removes the device from this registry, then create a new entry for it - giving it a new registry entry, and thus a new ID :

ioreg://4296533082

 | +-o AppleUserUSBHostHIDDevice  <class IORegistryEntry:IOService:IOHIDDevice:AppleUserHIDDevice, id 0x10017e45a, registered, matched, active, busy 0 (14 ms), retain 17>

A potential solution

If we take a peek at the rest of the information available to us in the registry, we can see that the device properties contains a locationID field:

...
     |   "UsbDeviceSignature" = <5010070471050000000301010300000b0000>
     |   "USB Product Name" = "YubiKey OTP+FIDO+CCID"
===> |   "locationID" = 51380224
     |   "bDeviceSubClass" = 0
     |   "bcdUSB" = 512
...

This ID tells us the identity of the location the device is connected to, in this case this is one of my in-built USB-C ports.

This ID is persistent, obviously providing that the user re-seats the device into the same USB port as they are expected to do.

So, my thought is this;

Could this locationID be used by the device path system in a fashion that would permit the device and it's fido interface to be located in a fashion which is persistent across connection sessions? Ideally this would provide feature parity between MacOS and Windows, with the ability to continue to use a device's path to continue to refer to the same device without the to requirement of the library's consumer to re-select / re-identify a device if running on MacOS.

[LDVG]

Hi,

I'm unfortunately no expert on MacOS API; I would assume an approach like this to be technically possible but it's been a non-goal for us (paths are not entirely stable on Linux either, for example). Our recommendation is to use fido_dev_info_manifest() to determine plugged in devices and to use fido_dev_get_touch_*() family of functions for the user to select the device they want to use, if there are more than one plugged in.

Hope this helps.