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