美国护照机读旅行证件中的B型NFC芯片 [英] Type B NFC Chip in US Passport MRTD
问题描述
我正在尝试阅读2010年发行的《美国护照》.它具有使用B型调制的NFC芯片.大多数国家/地区都使用A型，因此我现在是第一次尝试B型.
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.
我正在使用NXP PN532 NFC控制器.我使用inCommunicateThru指令而不是inDataExchange，因为我需要手动控制超时和错误处理以成功与该型号NFC控制器上的B型芯片通信.我必须自己实现ISO-14443-4协议的某些部分，例如PCB，CID和CRC字节，但是它似乎可以工作.我可以选择应用程序，并从标签中请求挑战随机数.
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.
问题在于，即使不需要返回数据，也要在SW1 SW2字节的顶部返回很多额外的数据.例如，响应选择的MRTD应用程序命令(INS = 0xA4)，返回了许多字节:
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:
发送4B型帧(PCB = 0A，CID = 01，CRC = 8A 2E)
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
-> 0A 01 00 A4 04 0C 07 A0 00 00 02 47 10 01 8A 2E
收到类型4B响应帧:
-> 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
-> 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
然后我尝试通过发送4B型帧来获得挑战性随机数:
Then I try to get a challenge nonce by sending Type 4B Frame:
-> 0A 01 00 84 00 00 00 8E 3E
->0A 01 00 84 00 00 00 8E 3E
注意:出于某种原因，我需要将Le设置为00，这样才能避免出现错误的长度错误
Note: For some reason I need to set Le to 00 for this to not give me a wrong length error
收到类型4B响应帧:
-> 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
->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
据我了解，前两个字节是PCB和CID，最后一个是SW1 SW2.
The first two bytes are the PCB and the CID, and the last are the SW1 SW2, that I understand.
我无法解释的是 BOLD 中的字节.是否有人对美国机读旅行证件或其他B型NFC芯片有任何经验，可以帮助我解释这些字节?我缺少参考资料来解释这些额外的字节吗?
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?
*****更新2014年11月27日*******
*****UPDATE 27-Nov-2014*******
好的，我并不发疯，获取挑战"命令对此护照很奇怪，因为按照ICAO规范将Le设置为0x08会产生6700错误，但是Le = 0x00时会返回太多字节.使用inDataExchange(而不是inCommunicateThru)来获得质询(例如，我得到8个字节).这样，我不必猜测哪个8字节是挑战.
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.
太好了，现在我有了质询和静态公钥，可以在扩展超时模式下执行相互认证指令并获取响应字节. INS是0x82，P1，P2 = 0x00，Le，Lc = 0x28
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
结果是我从PN532(NFC控制器)取回了0x00，但没有返回字节！甚至SW1或SW2也没有.下面是一个示例:
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:
发送类型4B帧: 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
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
收到的4B类响应帧:D5 43 00
Type 4B Response Frame Received: D5 43 00
ITALIC 字节是协议字节， BOLD 是实际的APDU
The ITALIC bytes are the protocol bytes, the BOLD are the actual APDU
有人知道2008-2010年发布的美国MRTD护照中的特质吗?
推荐答案
在第一个APDU响应中，您可能会从芯片中获取FCP和FCI数据.这很奇怪，因为您明确告诉应用程序您不希望使用它(通过在您发送的SELECT by NAME APDU中指定P2 = 0C).
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).
返回的内容是ASN.1编码，请检查链接此处.这些字节的说明在ISO/IEC 7816-4中.您可能需要以某种方式获得该标准.
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.
对于获取挑战，您可以指定一个值为00的Le.这将转换为一个值为256的Ne.由于Ne是最大大小，因此您基本上要求eMRTD返回所有可能的信息，最大为256个字节.您获得的22个字节(+ 9000)是民用的，它可能已返回完整的256个字节.通常您需要挑战8个字节，因此请尝试将Le设置为08.
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.
要注意的一件好事是，这些全部都在ISO/IEC 7816-4级别上，因此您的ISO/IEC 14443 B型代码可能还可以.
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.
这篇关于美国护照机读旅行证件中的B型NFC芯片的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
