On Sat, Dec 13, 2014 at 4:39 PM, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxx> wrote: > On Sat, Dec 13, 2014 at 7:33 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Sat, Dec 13, 2014 at 4:06 PM, Benjamin Tissoires >> <benjamin.tissoires@xxxxxxxxx> wrote: >>> >>> On Dec 13, 2014 6:28 PM, "Andy Lutomirski" <luto@xxxxxxxxxxxxxx> wrote: >>>> >>>> On Sat, Dec 13, 2014 at 2:56 PM, Jiri Kosina <jkosina@xxxxxxx> wrote: >>>> > On Fri, 12 Dec 2014, Andy Lutomirski wrote: >>>> > >>>> >> It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard >>>> >> is amazingly vague), that means that the application sends a short >>>> >> (<64kB) binary request to the device (with a type, two "parameters", >>>> >> and a payload), and the device answers with exactly one reply packet >>>> >> that has two bytes of status and a payload. These requests and >>>> >> replies are fragmented into multiple HID reports. >>>> > >>>> > Sorry for taking one (or maybe even more) step back, but what makes this >>>> > thing even "HID device"? >>>> > >>>> > Yes, it interacts with human beings, but are the operations it's doing >>>> > covered by HID specification (at least in a "does it have HID >>>> > descriptor" >>>> > sense)? It's not really completely clear to me at this point. >>>> >>>> It has a HID descriptor, it's recognized by the HID stack, it >>>> understands SET_REPORT, and it generates async HID reports. Hidraw is >>>> willing to talk to it and, in fact, Chromium talks to it using hidraw >>>> (ugh). >>>> >>>> It's also supposed to be *enumerated* by reading the HID descriptor. >>>> There are multiple vendors of these things, and the USB descriptor >>>> doesn't seem to have anything in it to identify the device. >>>> >>>> I think that's the full extent to which it's a HID device. >>> >>> And the most important, these devices have a button on them :) >> >> Someone should have told the U2F committee that the device should send >> a HID report, then :-/ >> >> (Also, at least one implementation is missing the button. You "press >> the button" by unplugging and replugging the whole device.) >> > > Well, on the Yubico Fido U2F, there is a button, but it only works > when the client calls the right SET_REPORT. I guess it is to prevent > an attack when there is nobody physically behind the key. So > removing/replugging the device gives the same security: a physical > interaction is required. > > Not sending an input report is here to help such button-less devices. It requires that apps on devices with buttons (e.g. the Yubico device) poll to see when the button is pressed, though. --Andy > > Cheers, > Benjamin > > >> --Andy >> >>> >>> Cheers, >>> Benjamin >>> >>>> >>>> --Andy >>>> >>>> > >>>> > Thanks, >>>> > >>>> > -- >>>> > Jiri Kosina >>>> > SUSE Labs >>>> >>>> >>>> >>>> -- >>>> Andy Lutomirski >>>> AMA Capital Management, LLC >> >> >> >> -- >> Andy Lutomirski >> AMA Capital Management, LLC -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
