CCC 数字钥匙 Release 3_云端钥匙追踪

最新推荐文章于 2024-09-26 19:31:56 发布

2401_85012504

最新推荐文章于 2024-09-26 19:31:56 发布

阅读量1.1k

点赞数 7

分类专栏： 2024年程序员学习文章标签：物联网嵌入式硬件面试

本文链接：https://blog.csdn.net/2401_85012504/article/details/138974695

版权

2024年程序员学习专栏收录该内容

33 篇文章 0 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上物联网嵌入式知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、电子书籍、讲解视频，并且后续会持续更新

需要这些体系化资料的朋友，可以加我V获取：vip1024c （备注嵌入式）

如果你需要这些资料，可以戳这里获取

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。

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