CCC数字钥匙设计【NFC】--NFC通信之APDU & TLV

发布时间:2024年01月07日

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

文章来源:https://blog.csdn.net/zzx3111/article/details/135441851
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。