数字钥匙技术文档版本30

数字钥匙技术文档版本3.0

数字钥匙技术文档版本3基于BLE/UWB或者NFC等基础无线电

通信技术开发的。

2系统架构

作为功能，组成，架构，钥匙系统的操作。

2.1概览

这个系统是采用非对称加密作为车辆与设备的相互认证。设备只

向他知道的车辆显示身份。也就是手机或者实体钥匙。

车辆和设备配对后可以相互交换公钥，所有者通过签名授权的方

式让朋友和家人使用钥匙。

钥匙可以离线使用所有功能。

2.2高级特性

安全性等同于或者优于物理钥匙

配对

分享

跨设备互操作性

支持一个设备去开多量车

车厂控制数字钥匙分发行和规则

针对主动或者被动窃听者的隐私保护

2.3高级架构

系统分为不同的角色和对应的功能，如2-1的图

不同的角色之间的关系。

2.4角色

描述了各个角色实体的功能

Vehicle:

决定设备在配对或者接受分享之前是否有资格匹配TSP平台

如果钥匙追踪允许，需要提供配对信息给钥匙追踪平台或者确信

配对信息被钥匙追踪平台接受。

设备的真实性确认

授权合法钥匙打开车辆或者允许令牌去启动车辆

如果需要，可以提供一个界面来删除数字钥匙

提供安全的处理和存储环境

NFC

数字钥匙配对，执行

BLE

配对，数字钥匙处理（解闭锁，开车）

与所有者或朋友设备通信，以便通过UWB设置安全测距

传送数据或者第三方车辆的应用

使用蓝牙来设置pepsUWB的距离

2.4.4UWB

和设备通信，安全测距，决定一个安全的距离去被动的进入和被

动的车辆引擎开启。

vehicleOEMserver

TSP平台

KTS

追踪平台

Devices

安全的环境和小程序

支持非接触传输和解闭锁动作

支持配置用户认证

在允许所有者配对或接受好友数字密钥之前，请检查服务资格

DeviceOEMServer

2.6设备结构

设备端系统功能性元素，这个结构像是实体钥匙或者手机上面的

实现

2.6.1NFC组成

非接触方式传输所需要的的卡仿真模式

配对需要的主卡仿真模式

262蓝牙模块

和车端通信，配对，第一次友好的数据传输，数字钥匙传输

和车端交流，设置一个自动劫夺的安全距离通过UWB

通过通信，来遥控车辆，发送指令

发送通知和数据变换上报

与车辆通信以传输第三方车辆OEM的数据的应用

2.6.3UWB模块

和车辆通信去决定无钥匙进入的安全距离

2.6.4安全元件或等效元件

数字钥匙安全部分

2.6.5数字钥匙应用小程序

包含的服务：

管理数字钥匙

实施相关通信

实现内部的CA去支持离线使用和私有保护

存储防盗令牌防止离线认证、访问配置文件，以及与数字密钥相

关的其他数据

车辆身份认证

确定朋友的钥匙

2.6.6数字钥匙框架层

实现自主配对，钥匙分享和管理

提供通用的服务功能为平台开发者

2.6.7车厂APP

原厂的叩p是可以选择的，这个主要的功能是支持原生的设备。

或许和原生APP支持同样的功能

提供ID&V通过原厂的云端

2.7车辆状态

车辆有如下可能的内部状态：

未配对：

配对：

配对中：

这一章节定义了车辆操作NFC接口去检测设备并且建立连接的。

3.2.1NFC轮训和连接设置程序

给RF模块上电，车辆执行射频模块的防撞活动。车辆跑一个NFC

轮询功能。

CON_POLL_Aenable

一些初始化的设置

3.2.2NFC数据传输程序

在数据交互活动中，APDU交换有在这个文档中定义。

对于使用哪种技术，车端NFC应该做如下配置

INT_PROTOCOL.具体操作需要看详细文档的操作。

3.2.3NFC断开程序

具体操作

NFCreset程序

具体操作

NFC相关要求

3.2NFC程序

这个章节定义了车辆操作NFC接口去检测设备和建立、终止NFC

和设备的通信。

321NFC轮询和链接设置

4数据结构

应用实例布置

一个数字钥匙小程序实例承载设备执行数字钥匙所需的所有数据

服务，如图4-1所示,包括所有数字密钥和一个或多个实例CAO

数字密钥由结构表示，如第4,2节所述。实例CAs

是表示设备OEMCA并驻留在设备内的中间CA。-

实例CA证明在小程序实例中创建的数字密钥（的公钥）。它的

可以使用设备OEMCA证书验证签名。不同的实例CA应为

用于各车辆OEM。

4.2数字钥匙结构

一个数字钥匙结构存储在小程序实例中，并且包含一个公钥，私

钥对，一个私钥mailbox,一个可信mailbox。和其他元素。如表格

显ZE。

一个所有者钥匙只包含数字钥匙结构，它没有任何的局限性，有

效性，和通过权限。

一个朋友要是包含钥匙结构和应享权利证明部分。朋友要是包含

相同设备公钥，和被所有者要是签名的公钥。

数字钥匙结构元素：

车辆标识：通用标识车辆，这个数字钥匙属于哪一个车辆。

末端标识：

5所有者配对命令

本节定义了用于所有者配对过程的NFC命令和数据元素。

5.1支持的配对命令

5.1.1选择命令

5.1.2SPAKE2命令

在此命令中,车辆应发送选定的SPAKE2+版本，所有支持的数字

密钥小程序协议版本，以及SPAKE2+协议的Scrypt参数。车辆

应在响应中检索SPAKE2+协议的曲线点X。使用的参数

第18节介绍了SPAKE2+请求命令。

OOO

6所有者配对

详细配对流程，其中NFC有参与

其中包括配对流程和协议

7标准交易

标准交易协议计划提供下面的性质：

•相互认证

•前向保密

・跟踪弹性

・完整性和保密性

通过生成临时密钥来初始化手机和车辆之间的安全通道，使用密

钥同意方法，一个分亨的秘密能够衍生双侧并且用来生成一个共亨的

对称密钥，使用diffie-hellman,一个密钥衍生功能。

这个短暂的公钥在车端产生，被车端的私钥签名。这个结果是车

端被手机端签名。按照手机端的观点，这个确保了没有私人敏感数据

能够被MUTM攻击。这个原则允许设备发传输数据给车辆不带有但可

被窃听者主动或者被动的可能。

最后，这个设备使用建立的安全通道去加密他的公钥标识，使用

车辆数据计算的签名，衍生的挑战和一些额外的应用，标准的数据。

这些通过手机签名的确认允许车辆去验证这个设备。

end

8快速交易

这个快速交易协议计划提供下面目的性质。

o设备签名或者相互的认证。

o完整性和保密性

o跟踪恢复力

这个设备在之前加密分享的标准交易阶段产生一个密钥，并且这

个允许车辆去认证设备。可选的，一个安全的通道建立通过衍生一段

时间的密钥通过之前的标准交易阶段的分项项和临时密钥，车辆有能

力夫建立。

end

9用户身份验证

10检查状态事物

11钥匙分享

12删除钥匙分享

13钥匙终止和删除

14身份验证和隐私

15数字钥匙应用程序

15.1介绍

数字密钥小程序旨在提供基于SE的多用途事务机制

结合点对点密钥分发和安全性强的数捱存储系统

隐私属性。可以使用三种非接触式交易：标准交易（参见

第7节）、快速事务（参见第8节）和检查状态事务（参见第10

节）。

在本规范中，根据设备的不同，提供了两种小程序实现模型

OEM的实施或数字密钥服务部署模型。

♦以SE为中心的小程序模型：对于此模型，设备OEMCA证书

相应的公钥受SE和非SE端点（如车辆、,

服务器等）由SE验证。

•以框架为中心的小程序模型：对于此模型，设备OEMCA证书

相应的公钥受设备OS本机密钥存储保护，非SE

端点（如车辆、服务器等）由框架进行验证

接下来分别详细介绍各个步骤和各个模块的具体流程

15.2钥匙和数据

定义了一些名词

15.3小程序实现

15.3.1介绍

下面的章节秒速了内部版数据结构河北APDU命令,这个文档仅

支持一个数字钥匙应用程序协议版本，这个数字钥匙应用程序版本号

被设置如下0100.

TLV领域。

这个变化的标签长度值表示在这个文档中应该遵守在ISO7816-4

BER-TLV格式。这个TLV域应该像被文档中描述的一样定义。一个不

同的域预定是认为可用除非特殊的。这个嵌套等级被Tag值表示。

小程序详细实现介绍

15.5车端实现

15.5.1安全导引

安全指南

以下项目描述了车辆的重要实施指南。

L在标准交易过程中，车辆应始终验证端点签名

（endpoint\usig）进行任何其他操作之前。此签名的成功验证

是

车辆验证端点的唯一方法。

2、在标准事务期间，车辆不得修改其永久存储器

在成功验证端点签名(endpoint\usig)之前。

3、在标准交易过程中，车辆不得在端点写入数据

成功验证终结点签名之前的机密邮箱或专用邮箱

(endpoint\usig)o

数字关键技术规范第3版第216页共442页

CCC-TS-101

版权所有©2021CarConnectivityConsortiumLLC.保留所有权

利。

保密的

4、在标准和fast交易过程中，车辆应验证

非接触式接口在对AUTH0和AUTH1命令的响应中指示

通过NFC接口执行事务时。

优化

15.5.2以下项目描述了车辆的推荐实施指南。

1、可以预先生成一个或多个车辆临时钥匙，以使新的临时钥匙

下一个事务开始时，密钥立即就绪。

2、如果车辆只支持快速交易，可以生成随机数

一对短暂的钥匙。

16证书

17服务对服务的通信和API

17.1介绍

本节介绍设备OEM服务器之间通信的API规范

和车辆OEM服务器。

请求和响应正文的格式应为用于

JSONo

所有接口应为所有字符串应买用编码(

HTTPSOUTF-8Unicode

规范化格式

C(NFC))

18安全

本节介绍SPAKE2+协议的原则。有关详细信息，请参阅第18.4节

实施细节。

该系统使用基于ECC的配对算法协议SPAKE2+,以

根据客户端提供的密码知识对两个实体进行身份验证（即。，

设备）和验证器，永久存储在服务器（即车辆）中。有关更多详

细信息

有关信息，请参见

[10]o

应使用NISTP-256曲线【8】。

车辆OEM服务器应生成密码并提供必要的元素

（w0,L;参见18.1.2）在车主配对开始之前，将其放入车辆中，

以便配对

即使在车主配对时车辆处于脱机状态,也可能出现这种情况。

Scrypt密钥派生在服务器和设备上执行,这允许服务器

和设备，以适应随时间变化的派生<>参数，以对抗攻击者的增加

表演

密码pwd应通过车辆OEM帐户提供给车主，受保护

通过只有所有者知道的登录凭据。密码是UTF-8编码的,应该

在此编码中被传递到scrypt函数。

所有值均假定为大端字节顺序。x和y随机发生器应具有

在所需范围内均匀分布，并具有加密安全性

19蓝牙接口（page273）几乎大多数车端流程的东西都在这里介

绍

安全测距服务提供BLE框架去发现，管理，控制UWB-based设

备和车辆之间的测距。BLE,安全元素和UWB是数字钥匙解决方案的

核心。蓝牙提供安全设备和车端的安全数据的交互，然后使能安全元

素去提供相互认证，数据分享。BLE通道的建立和管理安全测距服务。

19.1BLE功能要求

BLE控制和Host对于设备和车辆应该是蓝牙5.0或以后的强制性

能力，应该支持下面的额外的功能。

LEL2CAP连接原始通道支持

LE私有的

LE安全连接

支持如下选择：

长距离LELR

LE广播扩展，如果产距离支持

19.1.1车辆

车辆应该支持GAP外围角色。

车辆应该支持私有广播。车辆应该使用可解决的私有地址对于广

播事件。

如果车辆支持多蓝牙控制，所有的蓝牙应该使用相同的标识地址,

决定的钥匙，每一个控制这有不同的随机数决定地址在任何时刻。

车辆应该支持GATT在服务角色。

19.1.2设备

设备端应该支持GAP中心角色。

设备端应该支持协议私有地址在车辆广播阶段，

当设备端收到车辆的配对广播包应该初始化去连接车辆。一个连

接间隔30ms,设备端应该支持GATTclient模式。

19.2BLE程序

19.2.1所有者配对连接建立

下面的流程对于所有者配对连接建立使用蓝牙outofband00B

配对，BLE设置被拆分如下步骤：

BLE连接层建立，ble配对GATT流程，

BLE酉己对，加密设置。

不支持安全测距的车辆应该不允许通过BLE接口配对，不应该广

播配对广播。所有者配对应该从NFC开始，section6有描述,按照

ble活动流程在19.5.8描述。

BLE连接层建立,bleownerpairingGATT流程

19.2.2蓝牙加密

下面的流程要求提供给蓝牙加密。

19.2.3被动进入：BLE设置

一但蓝牙加密和配对完成，后来的车辆的链接应该使用被动进入

流程。

对于被动进入，能力交换有一个更新的DK协议版本。UWB配置

识别，波形结合，参数结合，在19.5.1中有描述。

被动进入广播

被动进入L2CAP连接

连接性能建议

在这节，连接性能参数和他的值被要求。这个确切的值是完善的

和定稿的。

设备需求：

在用户接近车辆的时候，用于95%可用,UWB需要在3m的时

候，由蓝牙启动（不知道对不对）。这些应该基于如下假设。

最大的接近速度是2.1m/s并且测试在6米开始

这个条件在测试的文档中

在测试的开始，就开启了蓝牙的扫描。

传输建议：

接收建议：

通用建议：

应该使用最佳测距流程和先前导出的URSK。

19.3DKMessage格式

这个DKmessage应该通过L2CAP交换，使用DKService

SPSMe

设备端应该检索来自车辆的DKServiceSPSM并且建立一个LE

L2CAP连接的信用基础通过安全协议。

DKmessage的格式如下：

这个信息的头一字节并且表示message的类型。如果message

选择的是APDUwrappedwithinDK_APDU_RQ这个消息头表示消息

是不是ownerSE消息。payloadHeaderfield是DK_APDU_RQ.

MessageHeader定义MessageType定义。

长度的两字节是大端模式。

数据域的长度是变化的，数据结构在19.3.1to19.3.8中定义。

UWB定义数据如下

下面是如何编码APDU并通过蓝牙传输的DKMessage,同样可

以用来解码收到的数据。

19.3.1UWB测距服务消息

本节详细介绍了UWB测距服务程序去协商、初始化和完成设备和

车辆之间的测距。

测距能力请求(RC-RQ)

这些message是在测距期间,车辆发送到设备端的。

测距能力请求报文及其参数定义见表19-14和表分别为19-15。

详细解释一下其中的数据：车辆返回所有支持的协议版本。

UWB_ConfigJd是一个标识支持UWB配置。这个配置包含支持

的PHY层参数，m是支持UWB配置的数。

测距能力响应

该信息由设备发送至车辆，以响应测距能力请求。测距能力响应

消息及其参数分别在表19-16和表19-17中定义

测距会话请求

此信息由车辆发送至设备,以启动测距会话设置握手第20.5.2节

规定的程序。Ranging\uSession\uRQ消息及其参数。

车辆应使用选定的协议版本、选定的UWB配置

设备在测距能力交换期间选择的\u脉冲形状\u组合如果车辆具有

更新的DK协议版本或UWB配置标识符,或脉冲形状组合或这些参数

的组合，车辆应执行如第19.5.1节所述，再次与设备进行能力交换。

分别在表19-18和表19-19中定义

19.3.14测距会话响应

设备发送给车端的；测距会话响应消息和参数在下面表格定义，

如果这个设备有更新DK协议版本或者UWB配置或者参数组合，这个

设备应该响应DKEvent提醒。

测距会话消息和参数

range范围

range=1~255

T.BIockRAN=RAN_Multiplier

时间范围为96msto24480ms

slot_bitMask槽

同步代码指针

选择uwb通道5、9

测距会话设置请求

20.5.2rangingsessionsetup

下面步骤的程序描述了initiatorandresponder-deviceMAC参

数协商。首先responder-device和initiator通过蓝牙连接执行测距

能力交换:responder-deviceesendRC-RQmessage头initiator;

initiator回复RC-RS,

一但交换成功后,通过蓝牙协商设置

rangingsessiono

车辆通过返送rangingsessionRequest初始化rangingsession

设置，详细文本：

select_protocol_version:

select_uwb_config_ID

uwb_session_id:当前测距会话

select_pulseshape_combo:设备选择单脉冲形状组合常见支持的

列表。

Channel_bitMask:可用通道;

设备（手机端）反馈消息，内容如下：

RAN_Multiplier:设置initiator支持的第k个测距会话的最小测

距块持续时间，设置启动器可以支持的最大测距频率。10HZ;T

blockrun96mso

19.3.15测距会话设置请求

此信息由车辆作为测距会话设置握手的一部分发送；

这个设置里面包含：测距范围，测试数据，节点数量，一个循环

多少数据，数据掩码，等等

测试会话设置响应

该信息由设备发送至车辆，以完成测距会话设置，根据第20.5.2

节进行握手。测距会话设置响应消息及其参数分别在表19-24和表19-

25中定义。

（个人理解这些设置项是设备通过蓝牙通道传送给主模块，主模

块再分发给其他锚点）。

蓝牙传过来的数据如下：

测距休眠请求消息

此消息用于暂停给定UWB会话的活动。

UWB_Session_Id:UWB会话ID-当前激活的UWB测距会话。

测距暂定响应消息

这个消息作为响应成功的回复

测距恢复请求

这也是使用的sessionid

0测距恢复响应消息

作为恢复响应的消息，STSJndexOUWB_TIME（）

1配置测距恢复请求消息

19.4时间同步

设备必须进行时间同步。时间同步支持为提升了延迟和车辆节能

效益。

设备UWB时钟和UWB设备时间

设备UWB时钟定位为设备的时间，UWB设备的时间定义为设备

UWB的时钟。

设备的UWB时钟显示在车端：

19.5数字钥匙流程

19.5.1所有者配对流程

20UWBmac和通道

本节定义了用于数字超宽带测距的MAC层和信道访问协议。

20.1uwbmac架构

本小节描述了在UWBMAC中使用的概念（参见【31】和

[33]）.

角色范围定义

范围角色定义

在DKUWB测距服务中,测距设备角色基于哪个设备启动测距程

序，并负责设置测距交换。

以下角色定义仅适用于UWB层：

1、通过发送第一个UWB轮询来启动UWB测距分组交换的实体

数据包被称为〃启动器〃对于DK,这是设备。

响应UWB轮询包的实体称为〃响应者〃。假使DK,这些是车上

的锚。

包含多个应答器的实体称为〃应答器设备〃。在这种情况下这是

DK的车辆。

通过发送预轮询数据包来控制测距过程的实体称为

控制器。对于DK,这是设备，即设备是启动器

控制器

请注意，上述角色定义可能不适用于蓝牙LE层。

逻辑和物理响应者

响应者可以是逻辑响应者，也可以是物理响应者。

物理应答器应具有一个UWB模块和一个或多个物理天线。

逻辑响应程序对应于一个响应程序角色，例如，可以是

分配给特定的UWB模块和一个特定的物理天线。因此，物理

响应器可以包括一个或多个逻辑响应器。

4、应答器设备应协调哪些逻辑应答器进行传输，以及在哪些逻辑

应答器中进行传输

顺序应确保来自两个逻辑

属于同一应答器设备的应答器。

测距局域网DK测距局域网（RAN）

L参与连续测距过程的启动器和响应器设备，即

以一组特定参数为特征的称为测距会话。

2、启动器及其（一个或多个）测距会话称为〃测距区域网

（运行）。〃每个RAN的特点是由

发起人。同一个RAN中的所有响应程序设备都近似于启动器E寸间

线（其中

此处没有全局同步的假设，请参见第20.3节）。

数字关键技术规范第3版第378页/共469页

CCC-TS-101

版权所有©2021CarConnectivityConsortiumLLC.保留所有权

利。

保密的

3、一个RAN只能有一个启动器,并且可以有多个响应器设备

（例如，一个包含两辆车的设备）。在图20-1所示的示例中，

这由设备、车辆和车辆表示，它们都属于

212RAN2O

4.每个响应器设备可能有不同数量的逻辑响应器（例如一个）

车辆可能有7个响应器,同一RAN中的另一辆车辆可能有5个响

应器

响应者）。

5、单个应答器设备可能属于多个RAN，例如单个车辆测距

使用两种不同的设备。在图20-1所示的示例中，这表示为

属于装置2控制的RAN2和装置2控制的RAN3的车辆2

设备3。

内部测距局域网接口和资源管理

响应器设备上的每个响应器都可以可靠地预测其允许的传输窗口

同一应答器设备上的应答器之间不会有干扰。然而，鉴于

根据上述定义，可以确定三种可能的性能下降情况：

1、RAN间干扰：

•这可能是由来自不同RAN的数据包的实际空中碰撞造成的。

数字关键技术规范第3版第379页/共469页

CCC-TS-101

版权所有©2021CarConnectivityConsortiumLLC.保留所有权

利。

保密的

•这是正常的操作模式，应该是预期的，因为没有假设

不同RAN之间的协调。这些碰撞的影响可以减轻

通过采用下文定义的测距轮翳濒策略（见第20.4节）。

2、RAN内资源冲突：

•当启动器必须为两个不同的

测距同时交换（到两个不同的应答器设备）。

•可在发起方通过对其中一个测距会话进行优先级排序来解决此场

景

卷入的目标测距轮可用于最高

优先级，发起者应跳过其他测距会话的回合。影响

跳过的测距循环次数看起来像失败的测距循环次数，可以通过

使用第20.4节中解释的测距轮跳变策略。

3、RAN间资源冲突：

•资源冲突发生在响应者必须从

同时有两个（或多个）不同的RANO

•可以通过对一次跑步进行优先级排序并跳过一轮

其他RAN。优先级由相关响应设备决定。

・对于跳过RAN的启动器,这看起来像是接收失败

当前测距交换和响应设备的响应跳到不同的

圆形（见第20.4节）。

确定优先级的标准留给设备和车辆制造商。总共

除非另有说明，否则下文后续章节和文本中的响应者应理解为

逻辑响应程序。

21UWBPHY

21.1简介

UWBPHY使用基于使用带限脉冲的脉冲无线电信号的波形。

UWBPHY主要用于测距，但也可用于数据通信。超宽带

本规范中描述的物理层基于【33］中的HRPUWB物理层。

本节介绍具有增强功能的可互操作增强测距设备（ERDEV

对攻击的免疫力。安全飞行时间的主要增强是包括

mat的基本PPDU中的加扰时间戳序列（STS）o请注意，包括

STS

采用［33］中规定的BPRF模式下的基本PPDU格式

正EE标准定义了非常灵活的UWBPHY。正EE标准提供了灵活性

通过调整参数，如同步（SYNC）长度的前导码、前导码、，

帧分隔符（SFD）开始长度/代码、脉冲重复频率（PRF）和数据

费率。然而，本规范不要求实现所有参数和模式

【33】中规定的。请参阅有关强制和可选PHY的相应章节

对于安全测距模式，链路两侧的ERDEV应预先协商具体

将用于安全测距会话的参数。安全测距的谈判

参数可以在更高层或使用蓝牙LE完成。

22UWB安全

本节介绍了数字密钥功能的UWB相关功能固有的（适用和强制的）

安全要求

22.1密码学

22.2UWB测距