NFC Tag-4 协议问题 [英] NFC Tag-4 protocol questions

问题描述

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

I'm using a springcard reader and a standard Type 4 passive tag. I've logged the communication protocol and I don't quite understand what is going on.

完整序列位于消息底部.

The full sequence is at the bottom of the message.

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

Why after receiving the CC+OK the reader restarts with the initial message

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

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

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

and also gets an error from the tag.

我正在尝试理解该协议，因为我需要使用微控制器和 NFC 前端 (AS3953) 来实现无源 Type 4 标签的仿真

I'm trying to understand the protocol because I need to implement an emulation of a passive Type 4 tag using a microcontroller and a NFC frontent (AS3953)

完整的通信日志:

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

推荐答案

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

没有什么要求阅读器应用程序这样做(但也没有什么禁止这种行为).因此，阅读器这样做是因为阅读器应用程序是这样实现的.

There is nothing that requires the reader application to do this (but there is also nothing the prohibits this behavior). Thus, the reader does this because the reader application is implemented that way.

例如，应用程序可能被分成几个层.第一层仅检查是否存在 NFC 论坛 4 类标签应用程序(通过选择应用程序并尝试查找功能容器)，然后第二层尝试从 NFC 论坛 4 类标签应用程序访问和读取数据，而不管是否存在该应用程序之前已被选中.

It could be, for instance, that the application is split in several layers. The first layer only checks for presence of an NFC Forum Type 4 Tag application (by selecting the application and trying to find a capability container) and the second layer then tries to access and read data from the NFC Forum Type 4 Tag application independent of whether the application had been selected before.

为什么标签在收到 NFC Forum Type 4 Tag 应用的后续 SELECT 命令后返回错误(6A82)?

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

This is a good question and suggests that the tag application is poorly implemented and does not recognize a SELECT command while it is already selected.

似乎只有在选择了主文件(因此隐式取消选择了 NFC 论坛类型 4 标签应用程序)之后，才会识别用于 NFC 论坛类型 4 标签应用程序的新 SELECT 命令.同样，这不是 NFC 论坛类型 4 标签操作规范所强制要求的.第一个 SELECT 命令本来可以(并且在我看来:应该)同样有效.

It seems that only after the master file had been selected (and consequently the NFC Forum Type 4 Tag application had implicitly been deselected) a new SELECT command for the NFC Forum Type 4 Tag application is recognized. Again this is not mandated by the NFC Forum Type 4 Tag Operation specification. The first SELECT command could have (and in my opinion: should have) worked just as well.

为什么读取器在通信序列的末尾请求 0x3B (59) 字节，即使之前读取的 NDEF 消息大小指示只有 0x0A (10) 个字节?

阅读器似乎并没有通过仅读取 NDEF 文件的相关字节来优化通信.根据 Type 4 标签操作规范，这是一个合法的场景.功能容器包含允许阅读器执行此操作的参数:

It seems that the reader does not optimize communication by reading only the relevant bytes of the NDEF file. That's a legitimate scenario according to the Type 4 Tag Operation specification. The capability container contains parameters that permit the reader to do this:

• 能力容器是000F20003B00340406E10410000000.
• 所以最大 Le 是 0x003B(59 字节).
• 最大 NDEF 大小为 0x1000(4096 字节).

• The capability container is 000F20003B00340406E10410000000.
• So the maximum Le is 0x003B (59 bytes).
• And the maximum NDEF size is 0x1000 (4096 bytes).

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

Therefore, the reader may read up to 4096 bytes from the NDEF file and is allowed to read up to 59 bytes in one READ BINARY APDU. Consequently, the reader may read up to 59 bytes (starting at offset 2) which is far below byte offset 4096.

这篇关于NFC Tag-4 协议问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！