Android设备与MRTD交互时APDU响应差异的原因咨询

遇到这种单设备差异化的NFC问题，大概率是硬件芯片或系统层的协议处理细节差异导致的，我结合过往处理类似问题的经验，给你拆解几个可能的原因和解决方向：

核心原因推测 #

1. NFC控制器的ISO 7816-4上下文维护差异 #

不同品牌的NFC芯片（比如NXP PN系列 vs Broadcom BCM系列）对ISO 7816-4规范的实现细节有区别。有些芯片在执行SELECT APPLICATION（选中电子护照的AID：A0000002471001）后，会自动将当前EF（基本文件）切换到护照的默认EF（比如EF.COM，文件ID 0001），但部分芯片可能不会自动完成这一步。而EXTERNAL AUTHENTICATE指令需要依赖当前选中的EF上下文，没有默认EF的话就会返回69 86（无当前EF）。

2. Android系统NFC服务的定制化差异 #

不同厂商的Android定制ROM（比如三星、小米、华为）对NFC服务的实现有修改，有些会在指令转发过程中调整上下文状态。比如部分厂商为了优化NFC交互速度，可能在SELECT APPLICATION后没有正确保留EF上下文，导致后续指令找不到当前选中的文件。

3. 指令序列的隐性干扰 #

仔细检查该设备上的APDU发送日志，看是否在获取BAC挑战（GET CHALLENGE）和EXTERNAL AUTHENTICATE之间，有系统自动插入的指令或者你的代码不小心发送了额外指令，导致EF上下文被重置。

解决建议 #

• 手动选中默认EF后再执行认证：在GET CHALLENGE拿到挑战值后，先发送SELECT指令选中EF.COM（文件ID 0001），示例APDU指令：

  00 A4 02 0C 02 00 01
  

  确认返回90 00后，再发送EXTERNAL AUTHENTICATE指令，强制指定当前EF上下文。
• 对比APDU交互日志：在问题设备和正常设备上同时打印完整的APDU收发日志，逐行对比差异。重点看SELECT APPLICATION返回后，是否有额外的响应包，或者指令顺序是否有细微不同。
• 调整APDU的CLA字段：有些NFC控制器对指令的CLA字节（第一个字节）有特殊要求，尝试将EXTERNAL AUTHENTICATE的CLA从00改为90（符合ISO 7816-4中安全相关指令的规范），指令示例：

  90 82 00 00 10 [你的认证数据]
  

• 禁用厂商NFC优化功能：部分设备有NFC省电模式、快速连接等优化功能，尝试在系统设置中关闭这些功能，再测试是否能正常执行认证。

内容的提问来源于stack exchange，提问作者Ben Steele