本文主要是介绍CCC数字钥匙设计【NFC】--NFC通信之APDU TLV，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
CCC3.0，包含NFC、BLE、UWB技术。当采用NFC通信时，车端与手机端是通过APDU来进行交互的。而在APDU中的data数据段，又可能会嵌入TLV协议的数据，以完成车端与手机端的通信交互。
本文先介绍APDU及TLV的一些基础知识，再通过示例说明下，车端与手机端是如何进行通信交互的。
1、什么是APDU？
APDU，应用协议数据单元，英文全称为Application Protocal Data Unit。APDU是无线通信中的一种协议，用于在NFC设备之间传递数据。
APDU分为发送命令（C-APDU）和返回命令（R-APDU）。
APDU包含一条指令或响应信息。在智能卡的世界里采用的是主从模式，而智能卡永远扮演从的角色。
在CCC数字钥匙系统中，手机扮演的是智能卡的角色。
换句话说，手机总是在等待来自终端（车端模块）的命令APDU（C-APDU）。随后，手机执行APDU规定的动作，并以一个 应答APDU（R-APDU）向终端（车端模块）作出回答。
下图，前面绿色背景部分是命令APDU，后面蓝色背景部分是响应APDU。
两种命令的数据格式简化描述如下：
上表【】中的内部为可选部分。
具体展开描述如下。
1.1命令APDU
发送命令（C-APDU）的格式如下，包含一个必须头部段和一个可选数据段。
1.1.1命令详细解析
下面对命令APDU的每个字段展开介绍：
1)类别码CLA（1字节）
类别码字节，用于命令类别的标示。在很多智能卡上，这个字节用来表示应用程序。
如0x00表示标准指令集，0x80表示安全指令集。具体详见ISO IEC 7816-4-2020的第5.4章节。
CCC3.0规范规定4 个CLA类别，如下表：
2)命令码INS（1字节）
表示指令代码（instruction）。
1) b1（即最低位）指明数据字段格式
b1=1，即该INS为奇数，数据字段按BER-TLV编码。--详见ISO IEC 7816-4-2020的8.1章节
b1=0，即该INS为偶数，不提供数据字段格式的指示
2) 6X和9X为无效的INS。
具体详见ISO IEC 7816-4-2020的第5.5章节。
3)参数P1（1字节）
指令参数1，如果没有，则填0
4)参数P2（1字节）
指令参数2，如果没有，则填0
5)Lc（1字节）
可选字段，指的是命令的数据字段的字节数。
6)Data Field
可选字段，采用TLV数据格式进行填充。
7)Le（1字节）
可选字段，指定在期望响应的数据字段中的最大字节数。
1.1.2四种C-APDU结构
上图4种Case分别说明如下：
-
Case1: CLA INS P1 P2
命令中没有数据送到卡（Lc）中，也没有数据从卡中返回（Le）。
-
Case2: CLA INS P1 P2 Le
命令中没有数据送到卡（ Lc）中，有数据从卡中返回（ Le）。
-
case3 : CLA INS P1 P2 Lc Data
命令中有数据送到卡（ Lc）中，没有数据从卡中返回（ Le）
-
case4 : CLA INS P1 P2 Lc Data Le
命令中既有数据送到卡（ Lc）中，也有数据从卡中返回（ Le）。
1.2、响应APDU
响应命令（R-APDU）的格式如下，包含一个必须头部段和一个可选数据段。
R-APDU由一个可变长度的Data Field和两个字节Tailer组成，具体报文格式如下图：
其中CCC规范使用了如下几个Status Word充当SW1-SW2，具体可详见CCC3.0规范15.3章节。
2、什么是TLV？
TLV协议是BER编码的一种，全称是Tag、Length、Value。该协议简单高效，能适用于各种通信场景，且具有良好的可扩展性。
有如下两种编码方式：
方式1：基础类型Primitive Data编码（单一编码）--当Tag的bit5=0时
方式2：结构类型Constructed Data编码（嵌套编码）--当Tag的bit5=1时
具体采用哪一种编码方式，取决于Tag字节中的bit5。
2.1Tag
Tag由一个或多个字节组成，下图描述首字节0~7位的具体含义
① Tag首字节说明
-
Bit6~7：表示TLV的类型
-
Bit5：表示Value的编码方式，分别支持Primitive及Constructed两种编码方式。
0：为Primitive Data编码，即后续的Value未嵌套TLV。
1：为Constructed Data编码，即后续的Value有嵌套TLV。
-
Bit0-4：当Tag Value小于0x1F(31)时，首字节0～4位用来描述Tag Value，否则0~4位全部置1，作为存在后续字节的标志，Tag Value将采用后续字节进行描述。
② Tag后续字节说明
后续字节采用每个字节的0～6位（即7bit）来存储Tag Value, 第7位用来标识是否还有后续字节。
-
Bit7：用来描述是否还有后续字节，1表示有后续字节，0表示没有后续字节，即结束字节。
-
Bit0~6：填充Tag Value的对应bit(从低位到高位开始填充)。
如：Tag Value为：0000001 11111111 11111111 (即16进制：0x1FFFF)，填充后实际字节内容为：10000111 11111111 01111111。
整体的Tag值应该为XXX11111 10000111 11111111 01111111
CCC3.0规范中使用的Tag，最长为2字节。
2.2Length
用来描述Value的长度。
描述Value部分所占字节的个数，编码格式分两类：定长方式（DefiniteForm）和不定长方式（IndefiniteForm）。
当第一个Length取值为0x80时，则为不定长方式。其他值，则为定长方式。
2.2.1定长方式
定长方式中，按长度是否超过一个字节，又分为短、长两种形式，编码方式如下：
-
短形式（Length占用1个字节）：
字节第7位为0，表示Length使用1个字节即可满足Value类型长度的描述，范围在0~127之间的。
-
长形式（Length占用多个字节）：
即Value类型的长度大于127时，Length需要多个字节来描述，这时第一个字节的bit7为1，bit0~6用来描述Length值占用的字节数。然后将Length值转为byte后附在其后。
如：Value大小占202个字节（11001010）,由于大于127，这时Length需要使用两个字节来描述，如下：
10000001 11001010
示例中绿色的1，表示后面的length占用1字节；
示例中蓝色的11001010，表示length为202；
示例2：
若Value需占用0x114578个字节，则Length取值如下：0x83114578
2.2.2不定长方式
Length所在八位组固定编码为0x80，但在Value编码结束后以两个0x00结尾。这种方式使得可以在编码没有完全结束的情况下，可以先发送部分数据给对方。
2.3Value
Value中存放需交互的数据。
但其里面可能还嵌套着其他TLV的值，具体需根据本TVL中Tag的bit5来确定。
3、示例Select Command发送与响应
CCC规范中要求SELECT command的通信数据格式如下，具体详见CCC规范15.3章节：
command: CLA1 A4 04 00 Lc [instance AID] 00
response: [Table 15-12] 90 00
CLA1取值为0，如下表：
Table15-12的定义如下：
根据前面APDU及TLV的知识，解析该Select Command命令的发送数据与响应数据，具体分析如下：
Command实际发送数据可能为：00 A4 04 00 0D A000000809434343444B467631 00，具体分析如下表：
Response实际响应数据可能为：5C 04 01 00 01 10 90 00，具体分析如下表：
4、总结
1) 车端与手机端通过APDU来进行NFC通信交互。
2) APDU分为发送命令（C-APDU）和返回命令（R-APDU）。数据格式简化描述如下表：
| 指令 | 格式 |
| 命令APDU | CLA INS P1 P2 【Lc Data】【Le】 |
| 响应APDU | 【Data】 SW1 SW2 |
3) APDU中的data数据段，又可能会嵌入包含TLV的通信协议的数据。
4) TLV，即该数据包可以分为三个部分Tag，Length，Value。
5) TLV数据可单一发送，也可以嵌套发送，具体根据本Tag的bit5来决定
6) Tag取值 1~n个字节，但一般最多为4字节。CCC使用的长度为1-2字节。
7) Length取值长度为1~n字节，但一般最多为4字节。
5、参考文章
1.http://www.3scard.com/index.php?articleID=11&f=read&m=book
2.https://blog.csdn.net/Hakuryou/article/details/107289012
这篇关于CCC数字钥匙设计【NFC】--NFC通信之APDU TLV的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
