Support Bluetooth about authenticator-rs

[rstoica]

Hi @jcjones!

Thank you for your work on the authenticator and enabling CTAP support within Mozilla.

Maybe this issue is stale, but I am posting here to offer some feedback on it and also get your opinion / input.

One way to support Bluetooth "out-of-the-box" is via HID over Bluetooth Profile support. Given the current implementation this requires the dynamic management of the HID_RPT_SIZE, which to the best of my knowledge is actually not pinned to 64 bytes anyway by the CTAP HID spec. 64 is just the best one can do. Handling HID_RPT_SIZE dynamically would require to parse the descriptor FIDO_INPUT, FIDO_OUTPUT and compute it from there for each HID device. This is needed to account for the varying MTU capabilities of Bluetooth L2CAP allowing interoperability between devices and hosts.

One other issue is the fact that libc read/write (on linux at least) may return 0 bytes on read/write operations for HID over Bluetooth devices depending on the profile implementation, which is inline with the documentation of since the file descriptors (/dev/hidraw*) belong in fact to character device type and not regular files. So this may be trickier to handle nicely since the strong checks now in the code will not be asserted.

What do you think about this approach given your superior understanding of the code base ?

I would offer to help implementing this but I am by no means a Rust user :(. I just got to this point by debugging why a custom made HID Bluetooth FIDO2/U2F authenticator tested with Chrome, Edge on multi-platforms (Mac, Linux, Windows) would not work on Mozilla in Linux.

Cheers,
Andrei

[fmeum]

@rstoica Great to see somebody else interested in this.

One way to support Bluetooth "out-of-the-box" is via HID over Bluetooth Profile support.

I don't know what @jcjones had in mind when this issue was created, but I think that it was meant to be about adding support for Bluetooth CTAP transport, not Bluetooth HID transport. That said, Bluetooth HID transport is certainly much easier to add.

Given the current implementation this requires the dynamic management of the HID_RPT_SIZE, which to the best of my knowledge is actually not pinned to 64 bytes anyway by the CTAP HID spec. 64 is just the best one can do. Handling HID_RPT_SIZE dynamically would require to parse the descriptor FIDO_INPUT, FIDO_OUTPUT and compute it from there for each HID device. This is needed to account for the varying MTU capabilities of Bluetooth L2CAP allowing interoperability between devices and hosts.

I have a PR that does most of what's needed for that (#112), but could certainly be improved. I have not received any comments on it yet, but would gladly work them in.

One other issue is the fact that libc read/write (on linux at least) may return 0 bytes on read/write operations for HID over Bluetooth devices depending on the profile implementation, which is inline with the documentation of since the file descriptors (/dev/hidraw*) belong in fact to character device type and not regular files. So this may be trickier to handle nicely since the strong checks now in the code will not be asserted.

Do you happen to know which profiles would still return 0? I tried to get this changed in the kernel so that hidraw would behave uniformly between USB and Bluetooth transport, but I'm not very knowledgeable about the kernel and drivers.

I would offer to help implementing this but I am by no means a Rust user :(. I just got to this point by debugging why a custom made HID Bluetooth FIDO2/U2F authenticator tested with Chrome, Edge on multi-platforms (Mac, Linux, Windows) would not work on Mozilla in Linux.

Just in case you want to give it a try: Chrome OS should also support Bluetooth HID authenticators starting with the current Beta 84.0.4147.51 / 13099.41.0.

[rstoica]

@rstoica Great to see somebody else interested in this.

One way to support Bluetooth "out-of-the-box" is via HID over Bluetooth Profile support.

I don't know what @jcjones had in mind when this issue was created, but I think that it was meant to be about adding support for Bluetooth CTAP transport, not Bluetooth HID transport. That said, Bluetooth HID transport is certainly much easier to add.

True, figured that out, Bluetooth HIDP is just one way to go about and closest delta in terms of Bluetooth support with current code base.

Given the current implementation this requires the dynamic management of the HID_RPT_SIZE, which to the best of my knowledge is actually not pinned to 64 bytes anyway by the CTAP HID spec. 64 is just the best one can do. Handling HID_RPT_SIZE dynamically would require to parse the descriptor FIDO_INPUT, FIDO_OUTPUT and compute it from there for each HID device. This is needed to account for the varying MTU capabilities of Bluetooth L2CAP allowing interoperability between devices and hosts.

I have a PR that does most of what's needed for that (#112), but could certainly be improved. I have not received any comments on it yet, but would gladly work them in.

Cool, that is what I had also in mind regarding the dynamic management of the HID frame length. But as I mentioned, I am afraid this may be not sufficient to support Bluetooth as one has to handle the read/write returns of this transport layer within the authenticator logic.

One other issue is the fact that libc read/write (on linux at least) may return 0 bytes on read/write operations for HID over Bluetooth devices depending on the profile implementation, which is inline with the documentation of since the file descriptors (/dev/hidraw*) belong in fact to character device type and not regular files. So this may be trickier to handle nicely since the strong checks now in the code will not be asserted.

Do you happen to know which profiles would still return 0? I tried to get this changed in the kernel so that hidraw would behave uniformly between USB and Bluetooth transport, but I'm not very knowledgeable about the kernel and drivers.

Here is the arch of the HID transport in Linux. In terms of the Bluetooth, from a very brief look it seems that only HIDP is supported within the kernel as a transport layer for the HID. The alternative HOGP is within BlueZ, but I did not see any link to the HID core. The HIDP is I/O is handled by L2CAP layer via sockets, and is implemented based on wait queues and interrupts (as it should) to handle the Bluetooth connections and wireless access. Here is the HIDP write inner part if you have any interest to look into it.

I would offer to help implementing this but I am by no means a Rust user :(. I just got to this point by debugging why a custom made HID Bluetooth FIDO2/U2F authenticator tested with Chrome, Edge on multi-platforms (Mac, Linux, Windows) would not work on Mozilla in Linux.

Just in case you want to give it a try: Chrome OS should also support Bluetooth HID authenticators starting with the current Beta 84.0.4147.51 / 13099.41.0.

Nice to hear that. Will give it a look.