On Sat, Dec 13, 2014 at 7:41 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > 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. So this gives one more reason to have a proper kernel interface for not doing this ugly polling :) Out of curiosity, how did you managed to get the unplug/replugged working? Normally, a hid(raw) device is tighten to its physical presence, so when you remove the device, you should lose all the context... 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
