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
> > > <[email protected]> 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.
