CCC3.0学习笔记_Digital Key Structure
蓝牙OOB配对 数字钥匙 CCC3.0 车辆认证 安全交互
系列文章目录
第六章 CCC3.0 DIGITAL KEY Structure
文章目录
- 系列文章目录
- 前言
- 一、数字钥匙的数据结构
- 1. Digital Key 数据结构说明
- 2. Digital Key 使用说明
- 总结
前言
随着科技不断发展,车钥匙经历了传统机械钥匙到高低频的电子钥匙再到目前的数字钥匙的转变,由于现在手机或者手环等成为人们生活中必不可少的随身携带的电子产品,于是人们开始寻思着用手机或手环来代替先前的车钥匙,而蓝牙作为数字车钥匙的一个重要部件,本文将介绍CCC3.0中关于蓝牙OOB配对的那部分内容,至于蓝牙模块之间的配对特性交换,认证以及密钥生成分发则不在讨论的范围内。
一、数字钥匙的数据结构
1. Digital Key 数据结构说明
- 左边的数据是车主的数字密钥证书,在车主配对过程中,车辆提供必要的信息,如 vehicle.PK 和 vehicle OEM CA.PK 等,车主设备在接收到车辆相关信息时,创建一个与车辆相关联的数字密钥并使用自身的Instance CA.SK 进行签名得到数字密钥证书,这个数字密钥证书在车主配对的时候由车主设备发送至车辆端。
- 如果是朋友设备的数字密钥证书,就是把箭头指向的部分数据替换,只不过替换为朋友设备的公钥的时候附带一些权限信息(例如密钥有效期,访问配置权限等,而车主的公钥则没有任何限制拥有所有的访问权限)
- Authorized Public Keys 授权公钥的#1强制性为 Vehicle OEM CA.PK,此授权公钥是分享密钥证书链验证的起点。
2. Digital Key 使用说明
说说朋友设备的数字密钥使用说明:
- 朋友设备与车辆之间进行标准交易,在AUTH1 response的时候会反馈 endpoint_signature
- 车辆与朋友设备双向认证通过之后,通过一条或多条 EXCHANGE command 来获取朋友设备端的 attestation package, 这个 attestation package 是用车主设备的私钥进行签名得到的,对于车辆端来说不关心车主设备与朋友设备之间的交互过程,不论是同平台的手机还是跨平台的手机,车辆端是不关心它们之间的交互过程,重点是朋友设备与车辆首次交易时,需要从朋友设备端获取 attestation package 。
- 当车辆端获取到 attestation package 时,会使用车主设备公钥验签,通过后会使用其中的朋友设备公钥来验 签AUTH1反馈的 endpoint_signature,然后也验证通过之后再对配置权限部分进行验证,比如时间有效期是否已过,再比如是否没有启动车辆的权限等等,如果权限检查也满足自身设定的策略,那么朋友设备也算作是一把合法的数字钥匙
总结
这里就简单描述一下朋友设备与车辆交互时的过程,首先肯定也是进行的标准交易,标准交易完成后,车辆会拿到朋友设备的签名也叫做 endpoint_signature, 当标准交易成功后,车辆会通过 EXCHANGE command 来获取朋友设备的 attestation package,因为这个 attestation package 是使用车主的私钥签名的,所以车辆端是可以验签通过的,当通过以后提取朋友设备的公钥对 endpoint_signature进行验签,这个验签自然也是通过的,剩下的车辆端需要对访问权限部分的数据是否满足设定的策略即可。
小小吖℡: 博主,在NFC流程中spake2+协商出来的Kcmac、Kenc、Krmac和标准交易协商出来的值是不一样的吗,技术文档中有提到第一次通过spake2+派出的安全通道可以在NFC第二次会话中使用,第二次会话中执行的就是标准交易流程
2301_76825220: 车企服务器是如何获得ownerKeyId的呢?
MicroRover: 大佬,弱弱问个问题,CCC规范是定义车端的还是车钥匙端的?
是小镜子鸭: 这个SCP03通道建立是哪个技术文档,我在CCC里面并没有看到
Eris.F: 不一样的,从PBSM到RMS是有两种情况的,如果是主动唤醒,则进入Normal immediate state,会快速发送nm报文唤醒整个网络,然后进入Normal transimit state,正常发送nm报文;若是被动唤醒,则直接进入Normal transmit state,正常发送报文