UPDATE: this turned out to be a problem with the ACR122 reader
I made Neo run its HMAC-SHA operation over Linux\s NFC libpcsclite framework with ACR122U reader.
But it only works as long as the APDU size is 54 bytes or less (48 bytes of data to sign). When I send a bigger APDU, I am getting a wrong "sequence number" in the key's response, Linux's ccid library takes it for a duplicate frame, tries to read again and timeouts. The contents of the response APDU looks legitimate, only the sequence number in the protocol header is bad.
These are my APDUs:
Code:
00000081 APDU: 00 01 38 00 30 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 01 02 03 04 05 06 07 08 09 0A 0
B 0C 0D 0E 0F 16 (works)
00000038 APDU: 00 01 38 00 31 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 01 02 03 04 05 06 07 08 09 0A 0
B 0C 0D 0E 0F 00 16 (fails)
This is what goes to/from the reader in the "good" case:
Code:
00000054 commands.c:1565:CmdXfrBlockTPDU_T0() T=0: 54 bytes
00000087 -> 000000 6F 36 00 00 00 00 0F 00 00 00 00 01 38 00 30 00 01 02 03 04 0
5 06 07 08 09 0A 0B 0C 0D 0E 0F 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 16
00059914 <- 000000 80 16 00 00 00 00 0F 00 81 00 77 3B F7 18 2E 17 CE 51 D0 AC 5
E B6 4D 33 6D 17 70 C9 1D 64 90 00
00000028 SW: 77 3B F7 18 2E 17 CE 51 D0 AC 5E B6 4D 33 6D 17 70 C9 1D 64 90 00
And this is the "bad" case:
Code:
00000027 commands.c:1565:CmdXfrBlockTPDU_T0() T=0: 55 bytes
00000041 -> 000000 6F 37 00 00 00 00 0D 00 00 00 00 01 38 00 31 00 01 02 03 04 0
5 06 07 08 09 0A 0B 0C 0D 0E 0F 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 16
00060854 <- 000000 80 16 00 00 00 00 0C 00 81 00 20 D1 A1 6E 94 E9 13 EB AF E5 9
C F5 F3 CB D8 31 A8 B3 DA 6F 90 00
00000043 ccid_usb.c:699:ReadUSB() Duplicate frame detected
Note that in the first case byte No 7 is '0F' in the sent and in the received data, while in the second case the value is '0D' in the sent data but '0C' in the received data. Libccid detects this as a "duplicate frame" (see
http://anonscm.debian.org/viewvc/pcscli ... iew=markup starting at line 783).
I am not sure if this is yubikey's fault, but it seems likely. Note that the same scenario works fine over USB, and over Android's NFC. Could it be because Android's NFC stack does not check the sequence numbers? Or the error is elsewhere, and I am barking at a wrong tree?
Thanks,
Eugene
UPDATE: I've build libccid with disabled duplicate frame check, and verified that the data returned in the APDU is correct.
UPDATE 2: when I plug the key into USB, and run the same operation using the pcsclite framework (i.e. access it via CCID over USB instead of CCID over NFC), sequence numbers
are correct. I don't know who is responsible for those, it might be the ACR122 reader's fault...
UPDATE 3: I observe the wrong sequence numbers problem with any other NFC device on the ACR reader. So it has nothing to do with yubikey. I will leave the topic for future reference.
Login
FAQ
Search
