[systemd-devel] Supporting U2F over HID on Linux?

[Andy Lutomirski]

On Sun, Nov 2, 2014 at 12:42 PM, Jiri Kosina <jkosina at suse.cz> wrote:
> On Sun, 2 Nov 2014, Andy Lutomirski wrote:
>
>> 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.

>
>> 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.

>
>> - 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.
>
>> - 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.

>
>>  - 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