Type B NFC Chip in US Passport MRTD

I am trying to read a US Passport, issued 2010. It has an NFC chip in it using type B modulation. Most countries use Type A so I am just trying Type B now for the first time.

I am using an NXP PN532 NFC Controller. I am using the inCommunicateThru instruction rather than the inDataExchange since I need to manually control the timeouts and error handling to successfully talk to a type B chip on this model NFC controller. I had to implement parts of the ISO-14443-4 protocol myself, such as the PCB, CID and CRC bytes, however it seems to work. I am able to select the application and request a challenge nonce from the tag.

The issue is that a lot of extra data is returned on top of the SW1 SW2 bytes, even when no return data is expected. For example, in response to a select MRTD application command (INS = 0xA4), there are many bytes returned:

Sending Type 4B Frame (PCB = 0A, CID = 01, CRC = 8A 2E)

-> 0A 01 00 A4 04 0C 07 A0 00 00 02 47 10 01 8A 2E

Type 4B Response Frame Received:

-> 0A 01 62 36 82 01 38 83 02 00 11 85 01 00 84 07 A0 00 00 02 47 10 01 86 0D FF FF FF FF FF FF FF FF FF FF FF FF FF 8B 12 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 90 00

Then I try to get a challenge nonce by sending Type 4B Frame:

->0A 01 00 84 00 00 00 8E 3E

Note: For some reason I need to set Le to 00 for this to not give me a wrong length error

Type 4B Response Frame Received:

->0B 01 90 9C 46 70 EC 02 BF FC 6E E2 A6 40 2D A5 0C 5F 93 02 B6 EB B5 61 1B BA 90 00

The first two bytes are the PCB and the CID, and the last are the SW1 SW2, that I understand.

It is the bytes in BOLD that I cannot interpret. Does anyone have any experience with US MRTDs or other Type B NFC chips that can help me interpret these bytes? Is there a reference that I lack that can explain these extra bytes?

*****UPDATE 27-Nov-2014*******

Okay no, I wasn't crazy, the Get Challenge command is weird with this passport in that setting Le to 0x08 as per the ICAO spec yields a 6700 error, but with Le=0x00, too many bytes returned. Using inDataExchange (not inCommunicateThru) to get the challenge works (as in, I get 8 bytes). This way I don't have to guess which 8 bytes are the challenge.

So great, now I with the challenge and the static public key in hand, I can execute the mutual authenticate instruction with the extended timeout mode and get the response bytes. The INS is 0x82, P1,P2 = 0x00, Le,Lc=0x28

The result is that I get back a 0x00 from the PN532 (NFC controller), but no return bytes! Not even SW1 or SW2. Below is an example:

Sending Type 4B Frame: 0A 01 00 82 00 00 28 73 3D 4E 2E C1 37 18 99 49 7C 4B 2A E0 79 A8 08 E2 6B 14 53 56 2C A4 66 D5 3E D8 94 56 79 50 2A 0D 6B C6 9A 75 5E B1 CB 28 11 75

Type 4B Response Frame Received: D5 43 00

The ITALIC bytes are the protocol bytes, the BOLD are the actual APDU

Does anyone know what the idiosyncrasies are in the U.S MRTD Passport issued 2008-2010?

In the first APDU response you probably get the FCP and FCI data back from the chip. This is weird because you explicitly told the application that you didn't want it (by specifying P2=0C in the SELECT by NAME APDU that you send).

What you get back is ASN.1 encoded, check the link here. The explanation of these bytes is in ISO/IEC 7816-4. You probably need to get that standard somehow.

As for the get challenge, you specify an Le with value 00. This translates into an Ne with value 256. As Ne is the maximum size, you basically ask the eMRTD to return everything it can, up to 256 bytes. The 22 bytes you get (+9000) is civil, it could have returned the full 256 bytes. Usually you need a challenge of 8 bytes, so try Le set to 08 instead.

The good thing to notice is that this is all at the ISO/IEC 7816-4 level, so your ISO/IEC 14443 type B code is probably alright.