CCC 数字钥匙 Release 3

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

2 系统架构

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

2.1 概览

这个系统是采用非对称加密作为车辆与设备的相互认证。设备只向他知道的车辆显示身份。也就是手机或者实体钥匙。
车辆和设备配对后可以相互交换公钥，所有者通过签名授权的方式让朋友和家人使用钥匙。
钥匙可以离线使用所有功能。

2.2 高级特性

安全性等同于或者优于物理钥匙
配对
分享
跨设备互操作性
支持一个设备去开多量车
车厂控制数字钥匙分发行和规则
针对主动或者被动窃听者的隐私保护

2.3 高级架构

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

2.4 角色

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

Vehicle：

决定设备在配对或者接受分享之前是否有资格匹配TSP平台
如果钥匙追踪允许，需要提供配对信息给钥匙追踪平台或者确信配对信息被钥匙追踪平台接受。
设备的真实性确认
授权合法钥匙打开车辆或者允许令牌去启动车辆
如果需要，可以提供一个界面来删除数字钥匙
提供安全的处理和存储环境

NFC

数字钥匙配对，执行

BLE

配对，数字钥匙处理（解闭锁，开车）
与所有者或朋友设备通信，以便通过UWB设置安全测距
传送数据或者第三方车辆的应用
使用蓝牙来设置peps UWB的距离

2.4.4 UWB

和设备通信，安全测距，决定一个安全的距离去被动的进入和被动的车辆引擎开启。

vehicle OEM server

TSP平台

KTS

追踪平台

Devices

安全的环境和小程序
支持非接触传输和解闭锁动作
支持配置用户认证
在允许所有者配对或接受好友数字密钥之前，请检查服务资格

Device OEM Server

2.6 设备结构

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

2.6.1 NFC 组成

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

2.6.2 蓝牙模块

• 和车端通信，配对，第一次友好的数据传输，数字钥匙传输
• 和车端交流，设置一个自动劫夺的安全距离通过UWB
• 通过通信，来遥控车辆，发送指令
• 发送通知和数据变换上报
• 与车辆通信以传输第三方车辆OEM的数据的应用

2.6.3 UWB模块

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

2.6.4 安全元件或等效元件

数字钥匙安全部分

2.6.5 数字钥匙应用小程序

包含的服务：

• 管理数字钥匙
• 实施相关通信
• 实现内部的CA去支持离线使用和私有保护
• 存储防盗令牌防止离线认证、访问配置文件，以及与数字密钥相关的其他数据
• 车辆身份认证
• 确定朋友的钥匙

2.6.6 数字钥匙框架层

实现自主配对，钥匙分享和管理
提供通用的服务功能为平台开发者

2.6.7 车厂APP

• 原厂的app 是可以选择的，这个主要的功能是支持原生的设备。
• 或许和原生APP支持同样的功能
• 提供 ID&V 通过原厂的云端

2.7 车辆状态

车辆有如下可能的内部状态：
未配对：
配对：
配对中：
阻塞：多次配对失败后的状态

2.8 数字钥匙用户组

这部分描述了和数字钥匙相关的不同的角色

2.8.1 拥有者

这个车只属于一个拥有者。（这里看应该只有一个设备能够连接车辆）。

2.8.2 朋友

这个车接受一些朋友设备，使用“访问文件”来确定朋友的钥匙权限。

2.9 访问文件

车辆存储“访问文件”和 相关的公钥文件。

NFC接口

这个章节定义了在数字钥匙使用场景下，NFC中应该被设备端和车端实现的功能。这个文件要求车辆和设备端支持NFC-A，NFC-B和NFC-F是可选的。相应的要求仅被使用一项情况，为了支持这些技术。

3.1 NFC 功能要求

这个章节定义了设备端和车端实现NFC功能的要求。

3.1.1 车端

车端NFC应该符合NFC模拟设备轮训的要求：
•无线电频率电源和信号接口的轮询器要求
•调制轮询器对侦听器的轮询器要求–NFC-A
•NFC-A负载调制侦听器到轮询器的轮询器要求
如果车端NFC智力支持NFC-B技术，它们应该符合NFC-B的轮询要求。下面介绍的都是尊徐poll的要求。

3.1.2 设备端

手机端NFC的实现应该符合监听设备需求。
电池操作模式：设备端的电池有足够的电量去支持这个模式。
电池低电量模式：其他功能都不可用了，但是NFC还能用。
一些NFC对设备端提出的要求。

3.2 NFC处理程序

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

3.2.1 NFC轮训和连接设置程序

给RF模块上电，车辆执行射频模块的防撞活动。车辆跑一个NFC轮询功能。
CON_POLL_A enable
一些初始化的设置

3.2.2 NFC 数据传输程序

在数据交互活动中，APDU交换有在这个文档中定义。
对于使用哪种技术，车端NFC应该做如下配置
INT_PROTOCOL.具体操作需要看详细文档的操作。

3.2.3 NFC 断开程序

具体操作

NFC reset程序

具体操作

NFC 相关要求

3.2 NFC 程序

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

3.2.1 NFC轮询和链接设置

4 数据结构

应用实例布置

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

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

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

是表示设备OEM CA并驻留在设备内的中间CA。一

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

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

用于各车辆OEM。

4.2 数字钥匙结构

一个数字钥匙结构存储在小程序实例中，并且包含一个公钥，私钥对，一个私钥mailbox，一个可信mailbox。和其他元素。如表格显示。
一个所有者钥匙只包含数字钥匙结构，它没有任何的局限性，有效性，和通过权限。
一个朋友要是包含钥匙结构和应享权利证明部分。朋友要是包含相同设备公钥，和被所有者要是签名的公钥。

数字钥匙结构元素：
车辆标识：通用标识车辆，这个数字钥匙属于哪一个车辆。
末端标识：

5 所有者配对命令

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

5.1 支持的配对命令

5.1.1 选择命令

5.1.2 SPAKE2 命令

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

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

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

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

。。。

6 所有者配对

详细配对流程，其中NFC有参与
其中包括配对流程和协议

7 标准交易

标准交易协议计划提供下面的性质：
• 相互认证
• 前向保密
• 跟踪弹性
• 完整性和保密性
通过生成临时密钥来初始化手机和车辆之间的安全通道，使用密钥同意方法，一个分享的秘密能够衍生双侧并且用来生成一个共享的对称密钥，使用diffie-hellman，一个密钥衍生功能。
这个短暂的公钥在车端产生，被车端的私钥签名。这个结果是车端被手机端签名。按照手机端的观点，这个确保了没有私人敏感数据能够被MUTM攻击。这个原则允许设备发传输数据给车辆不带有任何被窃听者主动或者被动的可能。
最后，这个设备使用建立的安全通道去加密他的公钥标识，使用车辆数据计算的签名，衍生的挑战和一些额外的应用，标准的数据。这些通过手机签名的确认允许车辆去验证这个设备。

end

8 快速交易

这个快速交易协议计划提供下面目的性质。
。设备签名或者相互的认证。
。 完整性和保密性
。跟踪恢复力
这个设备在之前加密分享的标准交易阶段产生一个密钥，并且这个允许车辆去认证设备。可选的，一个安全的通道建立通过衍生一段时间的密钥通过之前的标准交易阶段的分项项和临时密钥，车辆有能力去建立。

end

9 用户身份验证

10 检查状态事物

11 钥匙分享

12 删除钥匙分享

13 钥匙终止和删除

14 身份验证和隐私

15 数字钥匙应用程序

15.1 介绍

数字密钥小程序旨在提供基于SE的多用途事务机制
结合点对点密钥分发和安全性强的数据存储系统
隐私属性。可以使用三种非接触式交易：标准交易（参见
第7节）、快速事务（参见第8节）和检查状态事务（参见第10节）。
在本规范中，根据设备的不同，提供了两种小程序实现模型
OEM的实施或数字密钥服务部署模型。
•以SE为中心的小程序模型：对于此模型，设备OEM CA证书
相应的公钥受SE和非SE端点（如车辆、，
服务器等）由SE验证。
•以框架为中心的小程序模型：对于此模型，设备OEM CA证书
相应的公钥受设备OS本机密钥存储保护，非SE
端点（如车辆、服务器等）由框架进行验证
接下来分别详细介绍各个步骤和各个模块的具体流程

15.2 钥匙和数据

定义了一些名词

15.3 小程序实现

15.3.1 介绍
下面的章节秒速了内部版数据结构河北APDU命令，这个文档仅支持一个数字钥匙应用程序协议版本，这个数字钥匙应用程序版本号被设置如下0100.
15.3.1.1 TLV 领域。
这个变化的 标签长度值表示在这个文档中应该遵守在ISO 7816-4 BER-TLV格式。这个TLV域应该像被文档中描述的一样定义。一个不同的域预定是认为可用除非特殊的。这个嵌套等级被Tag 值表示。

小程序详细实现介绍

15.5 车端实现

15.5.1 安全导引

安全指南
以下项目描述了车辆的重要实施指南。
1、在标准交易过程中，车辆应始终验证端点签名
（endpoint\u sig）进行任何其他操作之前。此签名的成功验证是
车辆验证端点的唯一方法。
2、在标准事务期间，车辆不得修改其永久存储器
在成功验证端点签名（endpoint\u sig）之前。
3、在标准交易过程中，车辆不得在端点写入数据
成功验证终结点签名之前的机密邮箱或专用邮箱
（endpoint\u sig）。
数字关键技术规范第3版第216页共442页
CCC-TS-101
版权所有©2021 Car Connectivity Consortium LLC.保留所有权利。
保密的
4、在标准和fast交易过程中，车辆应验证
非接触式接口在对AUTH0和AUTH1命令的响应中指示
通过NFC接口执行事务时。
优化

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

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

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

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

一对短暂的钥匙。

16 证书

17 服务对服务的通信和API

17.1 介绍

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

和车辆OEM服务器。
请求和响应正文的格式应为JSON。用于
所有接口应为HTTPS。所有字符串应采用UTF-8编码（Unicode规范化格式
C（NFC））

18 安全

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

实施细节。

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

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

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

有关信息，请参见【10】。

应使用NIST P-256曲线【8】。

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

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

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

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

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

表演

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

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

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

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

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

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

安全测距服务提供BLE框架去发现，管理，控制UWB-based设备和车辆之间的测距。BLE ，安全元素和UWB是数字钥匙解决方案的核心。蓝牙提供安全设备和车端的安全数据的交互，然后使能安全元素去提供相互认证，数据分享。BLE通道的建立和管理安全测距服务。

19.1 BLE 功能要求

BLE控制和Host对于设备和车辆应该是蓝牙5.0或以后的强制性能力，应该支持下面的额外的功能。
LE L2CAP 连接原始通道支持
LE 私有的
LE 安全连接
支持如下选择：
长距离 LELR
LE 广播扩展，如果产距离支持

19.1.1 车辆

车辆应该支持GAP外围角色。
车辆应该支持私有广播。车辆应该使用可解决的私有地址对于广播事件。
如果车辆支持多蓝牙控制，所有的蓝牙应该使用相同的标识地址，决定的钥匙，每一个控制这有不同的随机数决定地址在任何时刻。
车辆应该支持GATT在服务角色。

19.1.2 设备

设备端应该支持GAP 中心角色。
设备端应该支持协议私有地址在车辆广播阶段，
当设备端收到车辆的配对广播包应该初始化去连接车辆。一个连接间隔30ms，设备端应该支持GATT client模式。

19.2 BLE程序

19.2.1 所有者配对连接建立

下面的流程对于所有者配对连接建立使用蓝牙 out of band OOB 配对，BLE设置被拆分如下步骤：
BLE 连接层建立，ble配对GATT 流程。
BLE配对，加密设置。
不支持安全测距的车辆应该不允许通过BLE接口配对，不应该广播配对广播。所有者配对应该从NFC开始，section 6 有描述，按照ble活动流程在19.5.8描述。

19.2.1.1 BLE 连接层建立，ble owner pairing GATT 流程

19.2.2 蓝牙加密

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

19.2.3 被动进入：BLE 设置

一但蓝牙加密和配对完成，后来的车辆的链接应该使用被动进入流程。
对于被动进入，能力交换有一个更新的DK 协议版本。UWB 配置识别，波形结合，参数结合，在19.5.1中有描述。

19.2.3.1 被动进入广播

19.2.3.2 被动进入 L2CAP 连接

19.2.3.3 连接性能建议

在这节，连接性能参数和他的值被要求。这个确切的值是完善的和定稿的。
设备需求：
在用户接近车辆的时候，用于95%可用，UWB需要在3m的时候，由蓝牙启动（不知道对不对）。这些应该基于如下假设。
最大的接近速度是2.1m/s 并且测试在6米开始
这个条件在测试的文档中
在测试的开始，就开启了蓝牙的扫描。
传输建议：
接收建议：
通用建议：
应该使用最佳测距流程和先前导出的URSK。

19.3 DK Message 格式

这个DK message 应该通过 L2CAP 交换， 使用DK Service SPSM。
设备端应该检索来自车辆的DK Service SPSM 并且建立一个LE L2CAP 连接的信用基础通过安全协议。
DK message的格式如下：

这个信息的头一字节并且表示message的类型。如果message选择的是 APDU wrapped within DK_APDU_RQ,这个消息头表示消息是不是owner SE 消息。payload Header field 是DK_APDU_RQ.
Message Header定义Message Type定义。

长度的两字节是大端模式。
数据域的长度是变化的，数据结构在19.3.1 to 19.3.8中定义。
UWB定义数据如下

下面是如何编码APDU并通过蓝牙传输的DK Message，同样可以用来解码收到的数据。

19.3.1 UWB 测距服务消息

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

19.3.1.1 测距能力请求（RC-RQ）

这些message是在测距期间，车辆发送到设备端的。
测距能力请求报文及其参数定义见表19-14和表分别为19-15。


详细解释一下其中的数据：车辆返回所有支持的协议版本。
UWB_Config_Id 是一个标识支持UWB配置。这个配置包含支持的 PHY 层参数，m是支持UWB配置的数。

19.3.1.2 测距能力响应

该信息由设备发送至车辆，以响应测距能力请求。测距能力响应
消息及其参数分别在表19-16和表19-17中定义

19.3.1.3 测距会话请求

此信息由车辆发送至设备，以启动测距会话设置握手第20.5.2节规定的程序。Ranging\u Session\u RQ消息及其参数。
车辆应使用选定的协议版本、选定的 UWB配置
设备在测距能力交换期间选择的\u脉冲形状\u组合如果车辆具有更新的DK协议版本或UWB配置标识符，或脉冲形状组合或这些参数的组合，车辆应执行如第19.5.1节所述，再次与设备进行能力交换。
分别在表19-18和表19-19中定义

19.3.14 测距会话响应

设备发送给车端的；测距会话响应消息和参数在下面表格定义，如果这个设备有更新DK协议版本或者UWB配置或者参数组合，这个设备应该响应DK Event 提醒。
测距会话消息和参数
range 范围
range = 1 ~ 255
T_Block RAN = RAN_Multiplier
时间范围为 96ms to 24 480ms
slot_bitMask 槽
同步代码指针
选择uwb通道 5 、9

19.3.1.5 测距会话设置请求

20.5.2 ranging session setup
下面步骤的程序描述了initiator and responder-device MAC 参数协商。 首先 responder-device 和 initiator 通过蓝牙连接执行测距能力交换： responder-devicee send RC-RQ message 头 initiator；initiator 回复RC-RS，
一但交换成功后，通过蓝牙协商设置 ranging session。

1. 车辆通过返送 ranging session Request 初始化ranging session 设置，详细文本：
   select_protocol_version:
   select_uwb_config_ID
   uwb_session_id:当前测距会话
   select_pulseshape_combo:设备选择单脉冲形状组合常见支持的列表。
   Channel_bitMask: 可用通道；
2. 设备（手机端）反馈消息，内容如下：
   RAN_Multiplier: 设置initiator 支持的第k个测距会话的最小测距块持续时间，设置启动器可以支持的最大测距频率。 10HZ； T block run 96ms。

19.3.15 测距会话设置请求

此信息由车辆作为测距会话设置握手的一部分发送；
这个设置里面包含：测距范围，测试数据，节点数量，一个循环多少数据，数据掩码，等等

19.3.1.6 测试会话设置响应

该信息由设备发送至车辆，以完成测距会话设置，根据第20.5.2节进行握手。测距会话设置响应消息及其参数分别在表19-24和表19-25中定义。
（个人理解这些设置项是设备通过蓝牙通道传送给主模块，主模块再分发给其他锚点）。

蓝牙传过来的数据如下：

19.3.1.7 测距休眠请求消息

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

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

19.3.1.8 测距暂定响应消息

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

19.3.1.9 测距恢复请求

这也是使用的session id

19.3.1.10 测距恢复响应消息

作为恢复响应的消息，STS_Index() UWB_TIME()

19.3.1.11 配置测距恢复请求消息

19.4 时间同步

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

19.4.1.1 设备UWB时钟 和 UWB 设备时间

设备UWB时钟定位为设备的时间，UWB设备的时间定义为设备UWB的时钟。
设备的UWB时钟显示在车端：

19.5 数字钥匙流程

19.5.1 所有者配对流程

20 UWB mac和通道

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

20.1 uwb mac 架构

本小节描述了在UWB MAC中使用的概念（参见【31】和【33】）。

20.1.1.1 角色范围定义

范围角色定义

在DK UWB测距服务中，测距设备角色基于哪个设备启动测距程序，并负责设置测距交换。
以下角色定义仅适用于UWB层：

1、通过发送第一个UWB轮询来启动UWB测距分组交换的实体数据包被称为“启动器”对于DK，这是设备。
响应UWB轮询包的实体称为“响应者”。假使DK，这些是车上的锚。
包含多个应答器的实体称为“应答器设备”。在这种情况下这是DK的车辆。
通过发送预轮询数据包来控制测距过程的实体称为
控制器。对于DK，这是设备，即设备是启动器
控制器
请注意，上述角色定义可能不适用于蓝牙LE层。

2.1.1.2 逻辑和物理响应者

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

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

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

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

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

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

顺序应确保来自两个逻辑

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

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

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

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

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

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

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

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

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

CCC-TS-101

版权所有©2021 Car Connectivity Consortium LLC.保留所有权利。

保密的

3、一个RAN只能有一个启动器，并且可以有多个响应器设备（例如，一个包含两辆车的设备）。在图20-1所示的示例中，

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

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

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

响应者）。

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

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

属于装置2控制的RAN 2和装置2控制的RAN 3的车辆2

设备3。

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

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

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

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

1、RAN间干扰：

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

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

CCC-TS-101

版权所有©2021 Car Connectivity Consortium LLC.保留所有权利。

保密的

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

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

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

2、RAN内资源冲突：

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

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

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

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

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

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

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

3、RAN间资源冲突：

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

同时有两个（或多个）不同的RAN。

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

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

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

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

圆形（见第20.4节）。

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

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

逻辑响应程序。

21 UWB PHY

21.1 简介

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

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

本规范中描述的物理层基于【33】中的HRP UWB物理层。

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

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

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

采用【33】中规定的BPRF模式下的基本PPDU格式

IEEE标准定义了非常灵活的UWB PHY。IEEE标准提供了灵活性

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

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

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

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

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

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

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

22 UWB 安全

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

22.1 密码学

22.2 UWB测距

以下内容适用于UWB测距会话

22. 2 STS索引管理

一个 URSK，一个测距会话，用在一次测距中？
STS指数增量应符合以下要求（见第20.6节）。

1、在给定测距会话开始时选择的STS_index的初始值（参考此处为初始STS_Index0）。因此，它应为[0…2^30]范围内的随机值
STS_index可以至少增加2^30倍。初始STS_Index0为包括在测距会话设置响应中（见第19.3.1.6节）。

2、STS_index应单调递增。在给定的测距会话内由UWB_ Session_ID标识，STS_index永远不会返回，或者在任意两个不同的帧之间重复使用。
给定测距会话中STS\U索引的最大值应为2^31-1。当这个达到最大值时，应结束测距会话，并使用应使用新的URSK。

4、恢复的测距会话的第一个STS_index（此处称为恢复
STS_Index0）包含在测距恢复响应中（见第19.3.1.10节），或
可配置测距恢复响应（见第19.3.1.12节）。恢复
STS_index0应大于测距暂停前最后使用的STS_index在同一范围会话中。

5、第一次预轮询的Poll_STS_Index参数中包含的STS_Index值
信息（由车辆接收）应大于初始STS_Index0或恢复
STS_Index0用于新的测距会话或恢复暂停的测距会话。

重新同步:
锚点重新同步发生在车辆侧。
此机制涉及mUPSK1、STS_index, nonce（根据
MAC头）：设备执行帧加密（SP0），车辆解密。

22.3 UWB 模块

预派生的URSK由DK小程序生成。然后，当其变为活动时，从该URSK导出的URSK或子密钥（取决于设备架构）被传输到UWB模块。
UWB模块主要负责一些加密操作的处理，如PPDU加密或STS的推导。实施应在与UWB安全测距相关的所有资产的整个生命周期内提供硬件和软件保护，以防逻辑和某些物理攻击。
SE和UWB模块之间的传输信道应保护机密性和完整性。SE应提供与UWB模块的安全绑定，以抵抗生产后的操作。
应防止在应用处理器上运行的任何代码访问或可以在该通道上注入数据。SE应能够区分UWB芯片接口和其他接口之间的通信。
对UWB模块及其与SE的接口进行有效攻击的可能性应表示为成功发起攻击所需的总努力，如所识别的威胁所定义。此类潜在攻击的详细语义将根据DKCTG的定义和相关文件确定（例如，在进行威胁分析练习时）。
应采取适当的安全措施，以防止具有专业知识的攻击者
定制设备利用漏洞成功利用
CCC DK第3版解决方案组件，将破坏用例的安全性（被动
无钥匙进入或启动引擎），提供实施解决方案的敏感知识，以及
有几个月的时间可以搜索漏洞。

23 参考