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. Cheers, Benjamin > --Andy > >> >> Cheers, >> Benjamin >> >>> >>> --Andy >>> >>> > >>> > Thanks, >>> > >>> > -- >>> > Jiri Kosina >>> > SUSE Labs >>> >>> >>> >>> -- >>> 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
