On 14/08/15(Fri) 10:17, Stuart Henderson wrote: > On 2015/08/14 11:00, Martin Pieuchot wrote: > > On 13/08/15(Thu) 20:35, Alexey Suslikov wrote: > > > On Tue, Aug 11, 2015 at 11:20 PM, Brandon Mercer > > > <yourcomputer...@gmail.com> wrote: > > > >> Another thing that bothers me. These keys are USB HIDs, right? Is it > > > >> safe > > > >> enough to let browser access USB bus (USB keyboard is HID and people > > > >> can type different things on it). > > > > What do you mean? You're already typing in your browser, right? AFAIK > > these devices act like standard keyboards. > > You're thinking of classic yubikey, which in normal use just emulates > a keyboard and just sends a sequence that looked like it was typed. > (Even for these, programming the device, and using it in other modes, > does require 2-way comms). > > The problem there is that the private key needs to be known by anyone > who allows your key to be used to authenticate. So it's great when you > want a centrally controlled location to gate authentication, but you > wouldn't want to hand this around to random websites. > > U2F is a different protocol, though still presenting as an HID. > It does challenge/response instead, so it needs 2-way comms in normal > use so the challenge can be sent to the key.. > > https://www.yubico.com/wp-content/uploads/2015/03/U2F.png
Thanks for the pointer. It seems they have a very simple client-side library which is nothing else than a HID driver in userland with some trendy JSON parsing: https://github.com/Yubico/libu2f-host So if you write a kernel driver for the important bits you can completely abstract the fact that this is a USB device. But the problem becomes then how to interface it with your application(s)? I don't know how Chrome uses this, but if that's the reason for a browser to be linked to the libusb, I feel this is completely wrong. But since a lot of people write USB drivers in userland I understand that applications are following this road.