search

google / u2f-ref-code

U2F reference implementations
BSD 3-Clause "New" or "Revised" License
585 stars 182 forks source link

u2f-chrome-extension HID GetVersion Request not sending Le bytes #111

Closed mirkop closed 8 years ago

mirkop commented 8 years ago

The U2F Chrome Extension is not including the Le bytes in the request per the latest updates to the Raw Messages specification.

This is the complete request captured from the U2F Chrome Extension's console output using Chrome's Developer tools.

0100BC54830007000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Here is the breakdown.

CID: 0100BC54 CMD: 83 LEN: 0007 PAYLOAD: 00 03 00 00 00 00 00

The LEN should be 0009 so as to include the Le bytes ensuring that bytes 8 & 9 are 0x00.

juanlang commented 8 years ago

Hi Mirko, this is actually the command formed in agreement with ISO 7816-4. Let's start with the command header and the data bytes at a high level:

CLA = 00 INS = 03 (VERSION) P1 = 00 P2 = 00

For the VERSION command, there are no data bytes. In ISO 7816-4 framing discussion, this means Nc (the number of data bytes to send) is 0.

ISO 7816-4 further states that when Nc = 0, i.e. there are no data bytes to send, then Lc is omitted.

What follows is Le. Let Ne be maximum length of the expected reply. For extended length encoding, which USB HID always uses, ISO 7816-4 encodes Ne as 00 MSB(Ne) LSB(Ne) when Lc is omitted.

Does that make sense?

FWIW, if you return INVALID_LEN to this APDU, the U2F Chrome extension will fall back to the FIDO U2F 1.0 framing of this command (which is not ISO 7816-4-compliant.)

mirkop commented 8 years ago

Hi Juan,

You are correct. I missed the part about "If there are no request data bytes, Lc is omitted."

It makes sense.

Thanks, Mirko