Topic: Reading ePassport (MRTD) as per ICAO doc 9303
I'm trying to read the EF.COM file from an ePassport (a.k.a MRTD).
What I have successfully done:
-Selected the ePassport application using the AID 0xA0,0x00,0x00,0x02,0x47,0x10,0x01 -Requested a challenge nonce from the epassport chip -Successfully authenticated by responding to that challenge as per doc9303 appendix 5. Doc 9303 can be viewed here: http://www.icao.int/publications/Docume … ons_en.pdf
It worked and now I am attempting to read the EF.COM file using the secure messaging protocol as per ISO 7816-4 and I used the doc9303 appendix 6 examples as a guide.
What my secure messaging code does correctly as per the examples in doc9303:
-It generates the exact same secure APDUs, byte for byte, as those in the doc9303 examples given the same inputs. -I have verified that my encryption (3DES w/CBC) is working, as is my MAC algorithm
What I have tried:
So I searched and found two open source implementations of the ePassport/MRTD/doc9303. One in Python (pyPassport-1.0) and the other in Java (JMRTD). I ordered the ACR122 reader (uses the same NFC chipset - PN532) to try it and it does work. So I then looked at the code JMRTD and pyPassport use to generate the secure messaging APDUs and it appears as though I am doing the same thing. Thankfully the JMRTD comes with an option to dump/trace the APDUs to a log file. Sure enough I am creating the secure messaging APDUs exactly as JMRTD is, I even reverse engineered a session (decrypted the RND.IFD, RND.ICC, K.ICC, session keys, etc..), created a test case and my code does in fact generate the same secure APDU output.
So I think I am constructing the secure messaging APDUs and DOs (Data Objects) correctly, but after I perform BAC and authenticate and try to read the EF.COM file with a protected APDU I keep getting a 69 88 error (Incorrect secure messaging (SM) data object). This is similar to the problem reported here although I am not using Android but my own embedded NFC stack: Android NFC read data from ePassport
I think it may be a setting in the PN532 (NXP NFC Chip) that I need to change but I doubt that since I am authenticating correctly and sending and transmitting data without PN532 errors. I tried raising the baud rate to 424 kbits/s but that did not fix it.
Here is an example of a secure (protected) APDU that my code generates.
Raw (unsecured) APDU:
00 A4 02 0C 02 01 1E
Protected (secure) APDU: 0C A4 02 0C 15 87 09 01 5B B0 63 B9 2A 0D 71 C0 8E 08 E0 B6 68 D2 14 4F 28 B5 00
So as per the doc9303 I am constructing a DO87 since command parameters are present, and a DO8E since there is a checksum (MAC) present, but no DO97 since no response payload is expected. I am using 87 09 01 for the DO87 since the 01 means padding type 80 00 00... and the L is 09 (I guess it includes the 01 - padding indicator byte, this is what is in the examples and APDU traces from JMRTD.)
I have tried removing the Le=0x00 from the end since some language in the 7816-4 doc suggests that, as well as making Lc' 0x16 rather than 0x15 as shown above. I have also tried making to DO87 to be 87 08 01 instead of 87 09 01 as shown above. None of that has worked.
I am really desperate here, I've been working on this for some time and just can't figure it out. Is there something wrong with my protected APDU structure? Is there a low level PN532 setting I need to change?
I am using inDataExchange to send and receive the APDUs.