On Sun, Nov 2, 2014 at 12:42 PM, Jiri Kosina [off-list ref] wrote:

On Sun, 2 Nov 2014, Andy Lutomirski wrote:

quoted

I want to get U2F (universal second factor, sometimes called "security
key" or even "gnubby") working on Linux.  U2F tokens are HID devices
that speak a custom protocol.  The intent is that user code will speak
to then using something like HIDAPI.

The trick is that, for HIDAPI to work, something needs to recognize
these devices and get udev to set appropriate device permissions.

Just to make sure we are on the same page -- this is really only about
setting proper device node permissions and nothing else, right?

Yes.

quoted

My question is: how should this be done?  The official way to
enumerate U2F devices is to look for a HID usage page 0xf1d0
containing usage 0x1.

Options include:

 - A builtin udev helper that reads the sysfs report_descriptor for
hid or hidraw devices and sets attributes accordingly (either
ID_SECURITY_TOKEN or something more general).

Hmmm ... please keep in mind that report_descriptor is actually in
debugfs, so it's a bit questionable whether you can rely on it being
present on well-defined location on all systems.

Huh?  I have /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0013/report_descriptor
on my system.

You can get it from different other places though, such as libusb (but
then you are limited only to USB HID devices ... which might be enough
in your particular case).

I have no idea whether there will ever be a bluetooth U2F device.

quoted

- A udev helper that does this and doesn't live in the systemd tree.
I don't love this option -- I'd prefer for this to be as plug-and-play
as possible.

Agreed.

quoted

- HID core code in the kernel to add
HID_USAGES=f1d00001:lots:of:other:things to the uevent (or udev code
to do the same).  This might end up producing a rather long string or
some devices.

We have been thinking about this quite a lot in the past, and decided to
postpone this until there is a very good reason for it to happen.

I'm not sure that U2F counts as a very good reason.

quoted

 - An actual kernel driver for U2F devices using the hid group
mechanism for enumeration.  This seems overcomplicated.

Hmmm ... why do you think so? I believe it actually should be really
super-trivial.

The HID group part is trivial, but what interface would the driver
expose?  I don't think that a udev rule for hidraw matching the
modalias makes any sense, and, if it were a real driver, what
interface would it expose?  Most cross-platform userspace code for U2F
is likely to use HIDAPI.

Admittedly, a U2F driver in the kernel would be slightly nicer from a
multiplexing standpoint than hidraw.

--Andy