与Mifare DESFire EV1进行Android NFC通信

Question

使用Nexus 4和最新的Android API级别18与Mifare DESFire EV1 AES标签进行通信让我头疼.遵循NXP本机协议以编写和读取此类型的标记,必须遵循以下步骤:

1. 选择申请
2. 认证
3. 写或读

为此,我使用Android的IsoDep类,它提供对ISO 14443-4属性和I/O操作的访问.关于它的一个非常奇怪的事情是,一旦我发送选择应用程序本机命令,我得到一个意外的响应.想象一下,我有AID F4013D所以我发送:

-> 5AF4013D
<- 6E00

所有可能的响应必须是一个字节长度(成功0x00或error_code),而不是两个或更多.因此,0x6E在成功响应之前是绝对意外的.它并不总是发生,当它没有并且工作正常时,选择的应用程序和身份验证过程可以正常工作.但是,一旦经过身份验证,写入命令就没有正确的行为,所有写入命令都会0xAF从PICC 完成,而不是成功0x00.似乎PICC不应该期待一些额外的数据(我发送正确长度的有效载荷).如果我发送任何其他命令,我会得到一个0xCA(命令中止)错误代码.

-> 5AF4013D
<- 00 /*Success*/
-> AA01
<- AFA8394ED57A5E83106B4EE72FD2BB0CC4
-> AF148F525E1DDE0AD6AB60B4B615552475C91F2E8D89B8523E4465113DD5BD19C6 
<- 0066D255C93F2F492AFE3715C88964F1BD /*Authentication success*/
-> 3D02000000030000222222 /*Write 3 bytes to file nº2*/
<- AF /*Unexpected, 0x00 was expected*/

正常情况下,如果我使用个人阅读器(非Android NFC)发送这些类型的命令,它总能正常工作.似乎Android NFC API中的某些内容很奇怪,它应该只是一个从不解释或修改数据的原始数据传输器.

我也尝试过使用ISO 7816-4 APDU结构,结果相同.作为一个好奇心,Galaxy Nexus不会发生选择应用程序奇怪的响应,但是一直是写命令.

Answer 1

(1)关于状态代码6E00的第一部分:

6E 00不是"奇怪的字节0x6E+成功状态代码0x00".相反,它是响应APDU状态字6E 00("不支持类").这表示先前使用基于APDU的访问与卡进行了通信(例如,Android本身尝试将卡读取为类型4标签,之后没有重置连接).因此,该卡将期望所有进一步的通信都在ISO 7816-4 APDU中.在这种情况下(例如,如果您收到类似的ISO 7816-4状态代码6E 00),您可以通过简单地包装本机命令继续使用DESFire APDU包装的命令.

编辑:事实上,这在NFC设备上有些预期的行为.这个想法是NFC设备将自动扫描检测到的NDEF消息标签.在DESFire卡的情况下,NFC设备将检测到卡作为潜在的Type 4标签.因此,NFC设备将发送ISO 7816-4 APDU,因为它将发送到任何其他类型4标签.因此,如果NFC设备在将检测到的标签交给应用程序之前没有重置与标签的通信,则应用程序只能使用ISO 7816-4 APDU进行通信.但请注意,我认为这只是在同一设备上进行某些激活时才会发生的错误.在我看来,一个特定设备模型上的行为应该是一致的.

编辑:虽然我不认为这种行为是一个错误,但它实际上是由Android的NFC堆栈中的已知错误(#58773)引起的,这些错误适用于具有Broadcom NFC控制器的设备.在受影响的设备上,自动存在检查以定时间隔发送ISO 7816-4 APDU,导致DESFire卡切换到ISO 7816-4 APDU模式.

(2)关于(意外)响应代码0xAF的第二部分:

可能是您的文件的通信设置是为"通过MACing保护的普通通信"还是"完全加密的通信"设置的？在这种情况下,仅发送三个数据字节是不够的.相反,您需要发送普通数据加MAC或填充,CRC化和加密数据.因此,0xAF表明该卡期望进一步的数据.

编辑:所以总结下面的评论.在发送了更多字节(每个接收到的0xAF状态代码一次一个字节:)之后AF FF,结果证明该卡预计还有8个字节.8个字节正好是AES身份验证的CMAC大小.因此,通信设置被设置为"通过MACing保证的普通通信".