NFC Tag-4 协议问题

Posted 2023-02-22

【中文标题】NFC Tag-4 协议问题

【英文标题】：NFC Tag-4 protocol questions

【发布时间】：2014-07-05 14:52:55

【问题描述】：

我使用的是 springcard 读卡器和标准的 Type 4 无源标签。 我已经记录了通信协议，但我不太明白发生了什么。

完整的序列在消息的底部。

为什么在收到 CC+OK 后阅读器会以初始消息重新启动

00 A4 04 00 07 D2 76 00 00 85 01 01 00

并且还会从标签中获取错误。

我正在尝试理解该协议，因为我需要使用微控制器和 NFC 前端 (AS3953) 来模拟被动类型 4 标签

---

完整的通讯日志：

NFC Tag Tool v.2.10.5227.20069

Reader: EMPTY

Disconnect, disposition=1
Reader: MUTE
Reader: EMPTY
Reader: PRESENT

Connect to 'SpringCard NFC'Roll NFC 0', share=2, protocol=3
Connected to the card
Is the card a NFC Forum Tag ???
Reader: INUSE
< 00 A4 04 00 07 D2 76 00 00 85 01 01 00
Transmit << 00A4040007D276000085010100
Transmit >> 9000
> 90 00
< 00 A4 00 0C 02 E1 03
Transmit << 00A4000C02E103
Transmit >> 9000
> 90 00
< 00 B0 00 00 0F
Transmit << 00B000000F
Transmit >> 000F20003B00340406E104100000009000
> 00 0F 20 00 3B 00 34 04 06 E1 04 10 00 00 00 90 00
This card is a NFC type 4 Tag
< 00 A4 04 00 07 D2 76 00 00 85 01 01 00
Transmit << 00A4040007D276000085010100
Transmit >> 6A82
> 6A 82
SelectNfcApplication failed Check error : file not found (Check error : file not found)
< 00 A4 00 00 02 3F 00
Transmit << 00A40000023F00
Transmit >> 9000
> 90 00
< 00 A4 04 00 07 D2 76 00 00 85 01 01 00
Transmit << 00A4040007D276000085010100
Transmit >> 9000
> 90 00
< 00 A4 00 0C 02 E1 03
Transmit << 00A4000C02E103
Transmit >> 9000
> 90 00
< 00 B0 00 00 0F
Transmit << 00B000000F
Transmit >> 000F20003B00340406E104100000009000
> 00 0F 20 00 3B 00 34 04 06 E1 04 10 00 00 00 90 00
< 00 A4 00 0C 02 E1 04
Transmit << 00A4000C02E104
Transmit >> 9000
> 90 00
< 00 B0 00 00 02
Transmit << 00B0000002
Transmit >> 000A9000
> 00 0A 90 00
< 00 B0 00 02 3B
Transmit << 00B000023B
Transmit >> D101065402656E6F6B0A000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000009000
> D1 01 06 54 02 65 6E 6F 6B 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 90 00
Found a Text
Done!
1 NDEF record(s) found in the tag
Read terminated

【参考方案1】：

为什么阅读器收到能力容器+OK后会重启选择NFC Forum Type 4 Tag应用？

没有什么要求阅读器应用程序执行此操作（但也没有什么禁止此行为）。因此，阅读器这样做是因为阅读器应用程序就是这样实现的。

例如，应用程序可能被拆分为多个层。第一层仅检查是否存在 NFC Forum Type 4 Tag 应用程序（通过选择应用程序并尝试查找功能容器），然后第二层尝试从 NFC Forum Type 4 Tag 应用程序访问和读取数据，而与是否该应用程序之前已被选中。

为什么标签在收到 NFC Forum Type 4 Tag 应用程序的后续 SELECT 命令后返回错误（6A82）？

这是一个很好的问题，表明标签应用程序实现得很差，并且在选择命令时无法识别它。

似乎只有在选择了主文件之后（因此 NFC Forum Type 4 Tag 应用程序已隐式取消选择），NFC Forum Type 4 Tag 应用程序的新 SELECT 命令才会被识别。同样，NFC 论坛类型 4 标签操作规范并未强制执行此操作。第一个 SELECT 命令也可以（并且在我看来：应该）同样有效。

为什么阅读器在通信序列结束时请求 0x3B (59) 字节，尽管之前读取的 NDEF 消息大小仅指示 0x0A (10) 字节？

阅读器似乎并没有通过仅读取 NDEF 文件的相关字节来优化通信。根据 Type 4 Tag Operation 规范，这是一个合法的场景。能力容器包含允许读者这样做的参数：

能力容器是000F20003B00340406E10410000000。 所以最大 Le 是0x003B（59 字节）。 NDEF 的最大大小为0x1000（4096 字节）。

因此，阅读器最多可以从 NDEF 文件中读取 4096 个字节，并且允许在一个 READ BINARY APDU 中读取最多 59 个字节。因此，阅读器最多可以读取 59 个字节（从偏移量 2 开始），远低于字节偏移量 4096。

【讨论】：

我也想知道为什么阅读器在通信序列的末尾请求 0x3B 字节，但根据能力容器，NDEF 消息只有 10 个字节长。我在其他示例中也看到了这一点。看起来像冗余数据交易，只请求10个字节也有效吗？