Yubico Forum

Dear team,

I am trying to use the Neo's challange-response capabilities over NFC. I did not find any relevant documentation on the website, but luckily there is the open source program yubitotp-android that you published, and from looking at the code, I realized that the protocol is ISO 7816-4 "CCID". In particular, the selectCommand used to verify that the token is nearby is which is "SELECT" defined by GlobalPlatform (whatever that means), with misterious fixed payload of 7 bytes and expecting no payload in the response apdu.

Apparently, the "challenge" and "program challenge" commands are using INS=1, and place the yubikey operation code (such as SLOT_CHAL_HMAC2) into P1. The length of the command apdu payload seem to match the amount of data that is sent (in the case of that program, 8 bytes). But then, discrepancy start. For instance, I don't see the Le field (response bytes expected) in the pdu.

My goal is to get the "full-size" challenge-response, with 63 bytes challenge and 20 bytes response. How can I achieve this? Is it enough to build an apdu of 68 bytes, and put 63 into the Lc byte? Should I add the Le byte (69th) at the end containg 20? or 22 to make room for SW1-SW2?

Of course it would be best if you could publish the doc describing the protocol.

Thanks,

Eugene

The Yubikey functionality is implemented as an applet with Application ID (AID) A0 00 00 05 27 20 01. This AID consists of Yubico's Registered application provider IDentifier (RID) A0 00 00 05 27 and the Proprietary application Identifier eXtension (PIX) for the Yubikey2 applet which is 20 01

So in order to select this applet, we use the Global Platform manager to send an application select command:

CLA = 00
INS = A4
P1 = 04
P2 = 00

The AID then follows as a parameter with 7 bytes, giving

Lc = 07
DATA = A0 00 00 05 27 20 01

Which yields the complete APDU = 00 A4 04 00 07 A0 00 00 05 27 20 01

Now, when the select is done, the Yubikey API is wide open for commands to be sent, just like we usually do using the personalization API over USB. Instead of cutting up the frame into 7-byte slices, it can be sent as an ISO7816-4 APDU.

CLA = 00
INS = 01 (INS_YK2_REQ)
P1 = Command byte from ykdef.h
P2 = 00
Lc = Number of bytes in request (omitted if zero bytes payload).

Le is optional and does not have to be sent.

So back to your example where we want to send a HMAC-SHA1. Let's assume the device is configured for HMAC-SHA1 in slot 1.

The command byte to be sent is SLOT_CHAL_HMAC1, which yields hexadecimal value 0x30 from ykdef.h
I used one of the samples provided by NIST, where the key is 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 and the challenge "Sample #2" or 53 61 6D 70 6C 65 20 23 32

This makes the payload 9 bytes long so we use that for Lc, which gives the complete command APDU (cAPDU)

00 01 30 00 09 53 61 6D 70 6C 65 20 23 32

The response APDU (rAPDU) then becomes

09 22 D3 40 5F AA 3D 19 4F 82 A4 58 30 73 7D 5C C6 C7 5D 24 90 00

... which seems just about right. Note the two last bytes, which make up the Status Word SW1 + SW2. 9000 is the ISO7816 notation for SW_NO_ERROR


For sure - we shall update our documentation to include this. Again - please note that the programming interface is fully compatible with the USB HID encoding we're using for the standard Yubikey and for the NEO.


With the best regards,

JakobE
Hardware- and firmware guy @ Yubico

Thanks, that's about as much as I want to know at this point.
(I managed to get what I need by guesswork, but it's certainly better to have authoritative information!)

Thanks a lot for the details. Has the documentation been updated yet ?