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

[David Herrmann]

Hi

On Mon, Nov 3, 2014 at 8:19 PM, Andy Lutomirski <luto at amacapital.net> wrote:
> On Mon, Nov 3, 2014 at 11:03 AM, David Herrmann <dh.herrmann at gmail.com> wrote:
>> Hi
>>
>> On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski <luto at amacapital.net> 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.
>>
>> [snip]
>>
>>>  - An actual kernel driver for U2F devices using the hid group
>>> mechanism for enumeration.  This seems overcomplicated.
>>
>> Imho, this is the way to go. Create a proper char-dev for U2F, create
>> an API and make it work.
>>
>> We had this discussion earlier about vendor-extensions that should be
>> writable via hidraw from user-space. This turned out to be really
>> messy.. and was discussed for several weeks straight. hidraw just
>> wasn't designed as unprivileged user-space API. For instance, what
>> happens if a device provides U2F plus something else? Both will be on
>> the same hidraw device.
>> We could split hidraw per usage, but I don't see how that is superior
>> to a proper U2F API. And once one usage can affect a device as a whole
>> (like power-off), you're screwed.
>
> Agreed, mostly.  My only real concern is that this could be annoying
> for the userspace developers who will need to target Linux and HIDAPI
> separately.  Admittedly the Linux support will be trivial.

I see. I'll not stop you from using hidraw, I'd just not recommend it.
Especially for security stuff I dislike exposing the whole HID device
writable. But yeah, I guess you got my point.

> I can give the driver a try.  It'll actually be simpler than the spec
> makes it out, since a real kernel driver will have no need to
> arbitrate with itself.

I'll gladly review any custom HID drivers. Feel free to put me on CC
when sending to linux-input. There's also a lot of examples in
drivers/hid/ in case you need a head-start (especially if you need the
raw_event callback).

Thanks
David