与Mifare DESFire EV1的Android NFC通信

Question

使用Nexus 4和最新的Android API level 18与Mifare DESFire EV1 AES标签通信让我头疼。根据恩智浦本机协议，要写入和读取此类标签，必须遵循以下步骤：

1. 选择应用程序
2. 身份验证
3. 写入或读取

-> 5AF4013D
<- 6E00

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

我也用ISO 7816-4 APDU结构进行了同样的尝试。奇怪的是，使用Galaxy Nexus不会发生select应用程序的奇怪响应，而是总是写命令一个。

Answer 1

（1）关于状态代码6E00的第一部分：

6E00不是“奇怪字节0x6E+成功状态代码0x00”。相反，它是一个响应APDU状态字6e00（“不支持类”）。这表明之前存在使用基于APDU的访问与该卡进行通信的情况（例如Android本身试图将该卡读取为Type 4标签，之后没有重置连接）。因此，卡将期望所有进一步的通信都在ISO 7816-4 APDU中。在这种情况下（即，如果您接收到一个ISO7816-4状态代码，如6e00)，您可以继续使用DESFire APDU包装的命令，只需包装您的本机命令。

编辑：事实上，这在NFC设备上多少是意料之中的行为。这个想法是，NFC设备将自动扫描检测到的标签以获取NDEF消息。在DESFire卡的情况下，NFC设备将检测该卡为潜在的Type 4标签。因此，NFC设备将发送ISO 7816-4 APDU，就像它将发送到任何其他类型4标签一样。因此，如果NFC设备在将检测到的标签交给应用程序之前没有重置与标签的通信，则应用程序只能使用ISO 7816-4 APDU进行通信。但是，请注意，我认为这只发生在同一设备上的某些激活上是一个bug。在我看来，在一个特定的设备模型上的行为应该是一致的。

编辑：所以总结下面的评论。在发送更多的字节（每个接收的0xAF状态代码:AF FF，一次发送一个字节）后，结果显示卡需要多8个字节。8字节正好是用于AES身份验证的CMAC的大小。因此，通信设置被设置为“使用Macing保护的普通通信”。