Android NFC 与 Mifare DESFire EV1 通信

标签 android nfc mifare apdu contactless-smartcard

使用 Nexus 4 和最新的 Android API 级别 18 与 Mifare DESFire EV1 AES 标签通信让我很头疼。按照 NXP 本地协议(protocol),为了写入和读取此类标签,必须遵循以下步骤:

  1. 选择应用
  2. 验证
  3. 写或读

为此,我使用了 Android 的 IsoDep提供对 ISO 14443-4 属性和 I/O 操作的访问的类。非常奇怪的是,一旦我发送 select application native 命令,我就会收到意想不到的响应。假设我有 AID F4013D,所以我发送:

-> 5AF4013D
<- 6E00

所有可能的响应都必须是一个字节长度(成功 0x00 或 error_code),绝不能是两个或更多。因此,成功响应之前的 0x6E 绝对是意外的。它并不总是发生,当它不发生并且工作正常时,选择应用程序和身份验证过程工作正常。但是,一旦通过身份验证,写命令就没有正确的行为,所有写命令都会以来自 PICC 的 0xAF 而不是成功的 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 不会发生选择应用程序奇怪的响应,但是写入命令总是会发生。

最佳答案

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

6E 00 不是“奇怪的字节 0x6E + 成功状态代码 0x00”。相反,它是一个响应 APDU 状态字 6E 00(“不支持的类别”)。这表明之前使用基于 APDU 的访问与卡进行过通信(例如,Android 本身尝试将卡读取为 Type 4 标签并且之后没有重置连接)。因此,该卡将期望所有进一步的通信都在 ISO 7816-4 APDU 中进行。在这种情况下(即,如果您收到 ISO 7816-4 状态代码,如 6E 00),您可以通过简单地包装您的 native 命令来继续使用 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 Controller 的设备。在受影响的设备上,自动存在检查会以定时间隔发送 ISO 7816-4 APDU,这会导致 DESFire 卡切换到 ISO 7816-4 APDU 模式。


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

您的文件的通信设置是否设置为“由 MACing 保护的普通通信”或“完全加密的通信”?在那种情况下,仅仅发送三个数据字节是不够的。相反,您需要发送纯数据加 MAC 或填充、CRC 和加密数据。因此 0xAF 表示卡需要更多数据。

编辑: 所以总结下面的评论。发送更多字节后(每次收到一个字节,每次接收到 0xAF 状态代码:AF FF),事实证明卡还需要 8 个字节。 8 个字节正是用于 AES 认证的 CMAC 的大小。因此,通信设置被设置为“由 MACing 保护的普通通信”。

关于Android NFC 与 Mifare DESFire EV1 通信,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19589534/

相关文章:

java - 如何在 Android 上的 Java 应用程序中运行 Lua 脚本?

android - 只需读取 NFC 标签

java - 如何解密从 Mifare Desfire EV1 发送的第一条消息

nfc - PN532向Mifare卡写入数据

rfid - 从身份验证跟踪中恢复 Mifare Classic key

java - 重新加载共享首选项

java - Facebook android sdk 需要 java 1.7 才能工作吗?

android - 如何清理 Android Studio 中的 Gradle 依赖项?

java - 如果有人通过快速设置菜单关闭 NFC,如何通知应用程序?

nfc - Apple Pay 和支持 NFC 的信用卡在伦敦地铁等入住/退房场景中如何使用?