问题描述
我正在尝试从ePassport(也称为MRTD)读取EF.COM文件.
I'm trying to read the EF.COM file from an ePassport (a.k.a MRTD).
我成功完成的事情:
-使用AID 0xA0,0x00,0x00,0x02,0x47,0x10,0x01选择ePassport应用程序-向epassport芯片请求挑战随机数-根据doc9303附录5通过响应该挑战成功进行了身份验证.可以在此处查看Doc 9303号文件: http://www.icao.int/publications/Documents/9303_p1_v2_cons_en.pdf
-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/Documents/9303_p1_v2_cons_en.pdf
它起作用了，现在我正尝试使用符合ISO 7816-4的安全消息传递协议来读取EF.COM文件，并且我使用了doc9303附录6示例作为指南.
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.
我的安全消息传递代码按照doc9303中的示例正确执行的操作:
What my secure messaging code does correctly as per the examples in doc9303:
-生成与doc9303示例中给定相同输入的字节完全相同的安全APDU(逐字节).-我已经验证了我的加密(3DES w/CBC)和MAC算法是否正常工作
-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
我尝试过的事情:
因此，我搜索并找到了ePassport/MRTD/doc9303的两个开源实现.一个使用Python(pyPassport-1.0)，另一个使用Java(JMRTD).我订购了ACR122阅读器(使用相同的NFC芯片组-PN532)进行尝试，它确实可以工作.因此，然后我查看了JMRTD和pyPassport用于生成安全消息传递APDU的代码，看起来好像我在做相同的事情.值得庆幸的是，JMRTD带有一个选项，可以将APDU转储/跟踪到日志文件.当然，我完全按照JMRTD的方式创建安全消息传递APDU，甚至对会话进行了反向工程(解密了RND.IFD，RND.ICC，K.ICC，会话密钥等)，创建了测试用例和我的代码实际上会生成相同的安全APDU输出.
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.
所以我认为我正在正确地构造安全消息传递APDU和DO(数据对象)，但是在执行BAC并进行身份验证并尝试使用受保护的APDU读取EF.COM文件后，我不断收到69 88错误(不正确安全消息传递(SM)数据对象).这类似于此处报告的问题，尽管我未使用Android，但使用了自己的嵌入式NFC堆栈: Android NFC从ePassport读取数据
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
我认为这可能是我需要更改的PN532(NXP NFC芯片)中的设置，但我对此表示怀疑，因为我进行了正确的身份验证并且发送和传输的数据没有PN532错误.我试图将波特率提高到424 kbit/s，但这并没有解决.
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.
这是我的代码生成的安全(受保护)APDU的示例.
Here is an example of a secure (protected) APDU that my code generates.
原始(不安全的)APDU:
00 A4 02 0C 02 01 1E
Raw (unsecured) APDU:
00 A4 02 0C 02 01 1E
受保护的(安全的)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
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
因此，按照doc9303，由于存在命令参数，因此我正在构造DO87，由于存在校验和(MAC)而正在构造DO8E，但是由于没有响应有效载荷，所以没有DO97.我对DO87使用87 09 01，因为01表示填充类型为80 00 00 ...，而L为09(我猜它包括01-填充指示符字节，这是示例和来自JMRTD的APDU跟踪)
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.)
我尝试从最后删除Le = 0x00，因为7816-4文档中的某些语言建议这样做，并如上所述使Lc'为0x16而不是0x15.我还尝试将DO87设置为87 08 01，而不是上面所示的87 09 01.这些都没有奏效.
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.
我在这里真的很拼命，我已经为此工作了一段时间，只是想不通.我的受保护的APDU结构有问题吗?我需要更改低级别的PN532设置吗?
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?
2014年3月19日更新 这是PN532命令/响应跟踪(我已对其进行了注释，以使它不再是卧床不起的家伙):
UPDATE ON 19-March-2014Here is the PN532 command/response trace (I annotated it so it's less gobedy gook):
-> GetFirmwareVersion (test command to verify PN532 is awake and online):
00FF02FED4022A0000
0000FF00FF0000 ->ACK
-> Response to GetFirwareVersion:
00FF06FAD50332010607E80000
-> Diagnose, NumTst=0x00:
00FF12EED400000102030405060708090A0B0C0D0E0FB40000
00FF00FF0000 ->ACK
-> Successfull diagnostic (Data returned):
00FF12EED501000102030405060708090A0B0C0D0E0FB20000
-> Diagnose NumTst=0x01:
00FF03FDD400012B0000
00FF00FF0000 ->ACK
-> Successfull diagnostic (0x00):
00FF03FDD501002A0000
-> Diagnose NumTst=0x02:
00FF03FDD400022A0000
00FF00FF0000 ->ACK
-> Successfull diagnostic (0x00):
00FF03FDD501002A0000
-> InListPassiveTarget (max targets one, 106kbit/s Type A anticollision)
00FF04FCD44A0100E10000
00FF00FF0000 ->ACK
-> Found one target, Tg=0x01, SENS_RES=0x07,0x04, SEL_RES=0x20
-> UID = 0x08,0x8B,0x05,0xCF, ATS = 0x05,0x78,0x77,0xB4,0x02 DCS=0x9E:
00FF11EFD54B010107042004088B05CF057877B4029E0000
-> inPSL (change baud to 424kbits/s)
00FF05FBD44E010202D90000
00FF00FF0000 -> ACK
00FF03FDD54F00DC0000 -> Status = 0x00, success
-> inDataExchange (select ePassport application w/ AID in doc9303):
00FF0FF1D4400100A4040C07A0000002471001360000
00FF00FF0000 -> ACK
00FF05FBD5410090005A0000 -> SW1SW2 = 9000 (success)
-> inDataExchange (get nonce/challenge)
00FF08F8D4400100840000085F0000
00FF00FF0000 -> ACK
00FF0DF3D541008EAF826F89F1E5259000A80000 -> SW1SW2 = 9000 (success), RND.ICC = 0x8E,0xAF,0x82,0x6F,0x89,0xF1,0xE5,0x25
-> inDataExchange (mutual authenticate)
00FF31CFD4400100820000284782B1700DD4F60373DA6632FCD1AB1E500D46FA11DEBDF9B88C39FCA7FDF8DBBE51F41D52D4B87928310000
00FF00FF0000 -> ACK
00FF2DD3D5410055A930856698D46C2AEF3CEDF3C56E71668150F2FECC75E28F42AB2A57CD2BA2F42727AE656CB3F49000470000 -> SW1SW2 = 9000 (success)
-> inDataExchange (select EF.COM)
00FF1EE2D440010CA4020C158709012CA8E7AB995D13248E0810061DDC725A159300DB0000
00FF00FF0000 ->ACK
00FF05FBD541006988F90000 -> SW1SW2 = 6988 (Incorrect SM Data Objects)..BAH!!
会议详细信息如下:
MRZ = GF043591<586012072309062
Computed values from MRZ:
Kenc = BA 43 43 3B F4 7A AE F8 75 23 4F DF 32 08 20 6D
Kmac = EA 64 45 CD 62 2C EA EC BF 7C 9B 7C B0 20 B9 5D
RND.ICC = 8E AF 82 6F 89 F1 E5 25
RND.IFD = 23 E8 5A 99 3A 9A C5 B4
K.IFD = 75 DC 87 E5 0C 8E F3 00 47 D0 B5 32 5E 83 20 4D
SSC = 89 F1 E5 25 3A 9A C5 B4
The computed E.IFD = 47 82 B1 70 0D D4 F6 03 73 DA 66 32 FC D1 AB 1E 50 0D 46 FA 11 DE BD F9 B8 8C 39 FC A7 FD F8 DB
The computed MAC of the above = BE 51 F4 1D 52 D4 B8 79
The tag's response to the mutual authenticate was:
E[Kenc](RND.ICC) = 55 A9 30 85 66 98 D4 6C
E[Kenc](RND.IFD) = 2A EF 3C ED F3 C5 6E 71
E[Kenc](K.ICC) = 66 81 50 F2 FE CC 75 E2 8F 42 AB 2A 57 CD 2B A2
MAC = F4 27 27 AE 65 6C B3 F4
The computed session keys:
KSenc = 4C E6 EF A8 3D 3E DA FB FB 02 1A F2 D5 E0 6E 4F
KSmac = EA C7 5B 64 D9 80 52 23 4F 64 7A 51 45 7F 40 1A
推荐答案
好的，所以我知道了！感谢您让我创建PN532命令跟踪.当我将其与通用调试日志中的会话详细信息结合在一起时，我开始编写代码进行验证.到一半时，我意识到我的错误，那是会话密钥不正确，因为我没有将整个相互认证响应解密为一个32字节的块，而是零散的，并且由于MRTD的芯片使用了对K.ICC进行密码块链接解密不正确，因此我的K.SEED错误，因此会话密钥错误.我更正了这个错误，现在我可以读取EF.COM文件！！
Okay so I figured it out!! Thanks for making me create a PN532 command trace. When I combined that with the session details from my all purpose debug log, I started to write code to verify it. Half way through I realized my mistake, which was that the session keys are incorrect because I did not decrypt the entire mutual authenticate response as a 32 byte block but rather piecemeal, and since the MRTD's chip uses cipher-block-chaining the K.ICC was decrypted incorrectly, and thus my K.SEED was incorrect, ergo the session keys were wrong. I corrected that mistake and now I can read the EF.COM file!!
这篇关于使用PN532进行ePassport读取，保持获取SW1 SW2 = 0x69 0x88(不正确的安全消息数据对象)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！