CCC数字钥匙3.0标准解读(5)

2024-02-11 03:20
文章标签 解读 标准 ccc 钥匙 数字 3.0

本文主要是介绍CCC数字钥匙3.0标准解读(5),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

  • 4 数据结构
    • 4.1 Applet实例展开
    • 4.2 数字钥匙结构
    • 4.3 邮箱
      • 4.3.1 专用邮箱
      • 4.3.2 机密邮箱
      • 4.3.3 防盗令牌
      • 4.3.4 邮箱访问权限


4 数据结构

4.1 Applet实例展开

一个数字钥匙小程序实例持有设备执行数字钥匙服务所需的所有数据,如图Figure 4-1所示,包括所有数字钥匙和一个或多个CA实例。
数字钥匙用一个结构表示,如第4.2节所述。CA实例是一个中间CA,保存在设备中相当于设备制造商CA。CA实例证明在Applet中创建的数字钥匙(的公钥)的有效性。CA实例的签名可以使用设备制造商 CA证书进行验证。每个车辆制造商应使用不同的CA实例。
Figure 4.1:Applet实例展开
在这里插入图片描述
理解说明:需要给每个车辆厂预先创建对应的CA。需要和手机商建立合作,预先生成CA。

4.2 数字钥匙结构

数字钥匙结构存储在Applet实例中,包含一个公钥/私钥对、一个专用邮箱、一个机密邮箱和其他元素,如图Figure 4-2所示。
车主数字钥匙仅由数字钥匙结构组成,没有有效性和访问权限方面的配置。
好友数字钥匙由数字钥匙结构和授权证明部分组成,授权证明部分包含相同的设备公钥并由车主钥匙签名。
Figure 4-2:好友数字钥匙结构及授权证明部分
在这里插入图片描述
数字钥匙组成如下:
 Vehicle Identifier(vehicle_identifier)(车辆标识):车辆在车厂的唯一标识,不是通常汽车中的VIN码。在非接触式交互中由车辆发送。
 Endpoint Identifier(端点标识):用于设备内部密钥管理。设备根据附录B.2中给出的规则创建端点标识符。在第15节中,名称“endpoint_identifier”用于密钥创建。标识符反映在数字钥匙证书[H]的主题字段中,也称为“数字钥匙端点证书”,附录A第A.4.7节介绍了与证书格式和解析相关的规则。
理解说明:该标识符由手机端创建。
 Digital Key Identifier (keyID)(数字钥匙标识):用于在车辆制造商服务器系统中识别数字钥匙。数字钥匙标识符在每个车辆制造商中是唯一的。该标识符在第14节中根据X.509证书定义命名为““subject key identifier”。该标识符是设备公钥的SHA-1(参见[23]和[24])算法哈希值。详见附录B.2。
 Slot Identifier(槽标识符): 由车辆提供给车主设备的一个值,用于识别所使用的数字钥匙。该值由车辆端在非接触交易中发送。当共享钥匙时,车主设备或车辆制造商服务器向好友设备提供槽标识符值,以用于创建好友钥匙,并且可以用于识别相关的防盗令牌。
 Instance CA Identifier(CA实例标识): 指可以对数字密钥进行签名的CA实例。它是由设备创建CA实例时分配。
 Key Options(钥匙选项): 指示允许钥匙使用哪种传输(快速、标准)。还有几个选项,例如通过有线接口执行传输等。请注意这些选项不是访问权限。
 Device Public Key(设备公钥):在本规范中也称为device.PK和endpoint.PK)用于标准交互中。设备公钥应具有全局唯一性。它在端点创建时生成,并存储在车辆中。它由第15节中端点证书的“subjectPublicKey”字段表示。注意设备Device.Enc.PK(见第14节)不同于设备公钥。类似地,设备私钥,device.SK和endpoint.SK在本规范中可互换使用。
 Vehicle Public Key:(车辆公钥):(在本规范中也称为Vehicle.PK和vehicle_pk)用于标准传输中。对于与同一车辆相关联的所有设备,车辆公钥是相同的。
 Authorized public keys(授权公钥): 由车辆提供,并在钥匙共享时用作好友公钥验证链中的根(见第11节)。在本规范版本中,车辆应仅包括一个单独的authorized__PK。其他授权公钥的使用留给将来使用。
理解说明:指车厂提供的授权公钥。
 Private Mailbox(专用邮箱): 一个缓冲区,用于在数字钥匙交互期间将数据发送到车辆或从车辆读取。(详见4.3.1节)
 Confidential Mailbox(机密邮箱): 一种缓冲区,用于在数字钥匙交互期间将需要加密保护的数据发送到车辆或从车辆读取。(详见4.3.2节)
在接受设备公钥之前,车辆应在车主配对程序(见第6节)中验证数字钥匙的所有相关数据元素,并在钥匙共享过程中(见第11节)在签署好友设备公钥之前由车主设备验证数字钥匙。在签署好友的公钥之前,车主验证好友的公钥对是否是在符合条件的SE上创建。验证链从车主数字钥匙结构中的授权公钥开始,该公钥已被证实并受到车辆信任,例如车辆制造商 CA公钥(见第16.8节)。
授权证明中提供的元素(仅适用于朋友密钥)如下:
 Friend Public Key(好友公钥):好友设备创建该公钥和私钥。在钥匙共享过程中,该公钥应由车主设备与授权证明包中的其他字段一起签名。
 Profile:由共享钥匙的发送人选择。它需要遵守车辆制造商策略,并由车辆进行验证。不符合车辆制造商策略设置的数字钥匙将被车辆拒绝(即不接受其公钥)。车辆制造商策略不在本规范的范围内。
 Sharing password information(共享密码信息):包含车辆产生一个共享密码的种子,该共享密码是在车主配对时保密确认共享的。它还包含有关车主设备策略是否要求(或不要求)车辆在激活共享数字钥匙之前向好友请求共享密码的信息。
 Validity start date(有效期开始日期): 可以使用钥匙的最早日期和时间。当数字钥匙提前提交给车辆时,可以接受该数字钥匙,但在到达日期和时间之前,该数字钥匙不得生效。此字段要求车辆中据有有效的时间,该时间的准确性、可靠性和安全性取决于车辆制造商策略和车辆的能力。
 Validity end date(有效期结束日期): 钥匙可以使用的最新日期和时间。此字段要求车辆中据有有效的时间,该时间的准确性、可靠性和安全性取决于车辆制造商策略和车辆的能力。
 Key friendly name(钥匙友好名称): 一个包含用户的名称的字段,在钥匙共享给予该数字钥匙一个包含友好信息的名称(见第11节)。它可以是在共享钥匙时车主联系人中相同的名字。应允许车主编辑该名称以进行可识别和个性化的设置。出于隐私原因,友好名称不应包含私人信息,如好友的全名。
除专用邮箱和机密邮箱外,数字钥匙元素在数字钥匙有效期内不可更改。可以创建、终止和删除数字密钥。在“已终止”状态下,数字钥匙不可用,但仍然能够提供终止证明,直到数字钥匙最终从内存中删除。数字钥匙状态由Applet内部管理。

4.3 邮箱

邮箱机制允许SE生成数字钥匙框架和车辆都可访问的小型数据缓冲区。这些数据缓冲区存储在SE的非易失性存储器中,并在事务交互、密钥共享和配对过程中进行读取/写入。在设备的Applet实例中创建的每个数字钥匙(称为端点)可以有两种邮箱类型(专用和机密),它们具有不同的安全属性,并针对不同的用途。邮箱支持随机访问,因此可以使用偏移量/长度参数来访问内容。
端点之间不共享机密邮箱,因此只有与端点配对的车辆才能访问该端点的机密邮箱。
端点之间也不共享专用邮箱;然而,数字钥匙框架和车辆可以自由地读取和写入其内容。
机密邮箱用于存储数字密钥框架中不能以明文形式提供的机密数据。此外,只有相关车辆具有对此邮箱内容的读/写访问权限。数字密钥框架只能以加密格式提取或推送部分机密邮箱。机密邮箱用于存储防盗令牌。
专用邮箱用于存储以明文形式可被数字密钥框架、车辆和SE访问的数据。使用专用邮箱可确保这些数据永远不会以明文形式传输,并且只能使用EXCHANGE命令进行邮箱访问。专用邮箱用于传输授权证明包,并指示哪些邮箱字段存在/不存在(信令),如以下部分所述。
Figure 4-3:邮箱读/写权限
在这里插入图片描述

4.3.1 专用邮箱

专用邮箱可以被数字钥匙框架使用设备内部有线链路进行读取和写入,如第15节所述。一旦在车辆和设备之间使用数字钥匙建立了第15节中描述的安全通道,车辆也可以读取和写入专用邮箱。与车辆交换的数据始终受到已建立的安全通道的保护。
专用邮箱的映射由数字密钥框架所需的数据结构定义,并提供了双向信令机制,以向接收器指示新数据可用,如图4-4所示。
专用邮箱使车辆制造商能够通过信令机制定义其(专用邮箱)数据结构。这些数据结构对数字钥匙框架来说是不透明的,并且只有车辆和车辆制造商应用程序或车辆制造商服务器才知道。在向车辆提交钥匙的情况下,与每个数字钥匙相关联的任意数据,包括信令位图、插槽标识符位图、插槽识别符、车辆制造商专有数据和证明包,都可以存储到专用邮箱或从专用邮箱读取。车主邮箱和好友邮箱应相同,但某些字段可能不用于好友邮箱。
车主邮箱和好友邮箱都需要信号位图。槽标识符位图由车主设备用来跟踪可用的槽标识符,如果适用,还用于数字钥匙共享时的防盗器令牌。槽标识符仅在车主邮箱中使用。
槽标识符和防盗令牌(如适用)由车辆或车辆制造商服务器提供给车主设备。这由车辆通过表5-14中SHARING_CONFIGURATION字段控制(标签7F60h和标签DAh)。
好友设备的槽标识符和防盗令牌(如果适用)由车主设备或车辆制造商服务器提供。这由车主设备通过表11-5中SHARING_CONFIGURATION字段控制(标签7F60h和标签DAh),该字段源自车主设备在车主配对期间接收的表5-14中的SHARING_ CONFIGURION字段(标签7F60h)。
车辆专有数据可以在车主和朋友的邮箱中使用。车辆中可用钥匙的最大数量取决于具体实施。私人邮箱中好友钥匙的七个槽标识符的限制是指可共享的朋友钥匙的最大数量,之后车主需要从车辆获得新的槽标识符。
密钥证书包可用车主和好友邮箱传递。请注意,这些邮箱有不同的用途和结构。
Figure 4-4:车主专有邮箱信号
在这里插入图片描述
SigBmp字段中包含的信令位图允许车辆和设备通知另一方发生的变化或另一方对某个邮箱字段采取的行动。车辆或占用该位的设备有责任重置该位并在需要时删除数据。信号关系和数据元素的偏移量由车辆在车主配时配置(见第6节)。
此字段的长度为1字节。该字段是大端排序的,这意味着位0是该字段的最右边位。
以下常量是本文档的其余部分定义的:
SLOT_IDENTIFIER_BITMAP_BIT = 00h
SLOT_IDENTIFIERS_BIT = 01h
VEHICLE_OEM_PROPRIETARY_DATA_BIT = 02h
ATTESTATION_PACKAGE_BIT = 03h
SLOT_IDENTIFIER_LENGTH = (VEHICLE_OEM_PROPRIETARY_DATA_OFFSET-SLOT_IDENTIFIERS_OFFSET) / 8
表4-1显示了SigBmp字段中每个比特的用途。信号位可以由车辆和/或设备读取和/或写入。
Table 4-1:信号映射编码
在这里插入图片描述
SlotIdentBmp字段中包含的槽标识符位图表示槽标识符的相应条目中的槽标识符的有效性,如图4-5所示。
Figure 4-5:槽标识符位图分配
在这里插入图片描述
此字段的长度为1字节。最高有效位表示条目7的状态;最低有效位表示条目0的状态。
如果某位设置为0,则槽标识符无效。如果从车辆中检索到防盗器令牌(见表5-14),则在下一个标准交互中,车辆应写入一个新的槽标识符值,并将位设置为1,如果适用,还应填充一个新防盗器令牌。
SlotIdentBmp中的每个位还应指示保密邮箱的相应条目和内存偏移中是否存在防盗令牌(见表4-3和图4-6)。如果从车辆中检索到防盗令牌,则此位图允许设备和车辆在机密邮箱内容上同步。
激活的车主防盗器令牌(ImTok A)应始终位于条目0中(对应于内存偏移量0)。其存在应通过在SlotIdentBmp中将位0设置为值1来发出信号。其他防盗令牌(例如,图4-6中的条目1至3)用于好友共享。
Figure 4-6:车主防盗器令牌信号
在这里插入图片描述
SlotIdentLst字段中包含的槽标识符有用于车辆跟踪哪些槽标识符和防盗器令牌(如果从车辆中检索到槽标识符和防盗器令牌)已经分发或正在使用。SlotIdentLst字段由八个子字段SlotEntry组成,每个SlotEntry子字段都包含一个插槽标识符值,如图4-7所示。SlotIdentLst字段的长度应为槽标识符大小的八倍。
每个槽标识符都映射到机密邮箱中防盗器令牌相同位置索引处。此数据字段的长度由定义
(VEHICLE_OEM_proparity_DATA_OFFSET–SLOT_IDENTIFIERS_OFFSET)。
Figure 4-7: 机密邮箱的槽标识符列表映射
在这里插入图片描述
槽标识符由车辆或车辆制造商服务器发布。槽标识符由车辆或车辆制造商服务器发布。如果车辆检索到防盗令牌,则车辆将其与相关的防盗令牌一起提供给车主设备。或者,它们由车辆制造商服务器在车主配对或钥匙共享后提供。车辆保证槽标识符在车辆的使用寿命内是唯一的。
共享钥匙时,槽标识符和防盗器令牌包含在提供给好友设备的数据中(见第11节)。
VehiclePropDat字段中包含的车辆制造商专有数据是每个车辆制造商特有的任意数据。
此数据字段的长度由(ATTESTATION_PACKAGE_OFFSET–VEHICLE_OEM_PROPRIETARY_data_OFFSET)定义。车辆制造商专有数据存在于专用邮箱中,直到被设备或车辆消耗和清除。
如果该数据字段的长度大于0,车辆制造商专有数据应在数字钥匙终止过程中由数字密钥框架读取,并与终止证明一起发送给KTS。由于技术限制,车辆制造商专有数据可能不会在所有情况下发送。
KeyAtt字段中包含的证据包可用于:
i) 向设备提供不透明证明(见第6.3.4.1节),
ii) 向车辆提供kts签名,表明车主密钥已在kts成功注册(见第6.3.2.4节),
iii) 支持好友共享(向车辆提供密钥证明包;见第11.8.4节),以及iv)使用设备提供的恢复证明来恢复挂起的密钥(参见第13.4.3节)。
证据包存在于私人邮箱中,直到被车辆或设备消费和清除为止(取决于证明类型)。此数据字段的长度由(MAILBOX_CONTENT_END_OFFSET–ATTESTATION_PACKAGE_OFFSET)定义。
表4-2描述了数据元素(“字段”)、存储器偏移和信令位之间的关系。专用邮箱中数据元素的大小由偏移量定义,偏移量由车辆在车主配对期间提供。数据结构大小是通过减去偏移值来计算的。
Table 4-2: 专用邮箱内容
在这里插入图片描述
上表中的Sig-Bit列标识负责用信号通知相关数据结构中的值变化的信令位图的比特。关联由车辆配置(见表5-13)。
SIGNALING_BITMAP_OFFSET 设置为 0。
SLOT_IDENTIFIER_BITMAP_OFFSET设置为1。字段SlotIdentBmp将机密邮箱中的八个偏移量(条目0–7)分配给八个信令位。
SLOT_IDENTIFIERS_OFFSET定义了车辆制造商用于存储八个槽标识符的位置,如果从车辆中检索到槽标识符和防盗器令牌,则这些槽标识符用于管理槽标识符和锁止器令牌。SlotIdentLst数据块的大小应为八的倍数。一个槽标识符的大小由表15-13中的标签4Eh的大小来确定。
VEHICLE_OEM_PROPRIETARY_DATA_OFFSET定义由车辆制造商定义的结构VehiclePropDat的起始位置。该结构对于数字钥匙框架是不透明的,该结构的一部分可以向数字框架框架公开。
ATTESTATION_PACKAGE_OFFSET定义了当车辆在第一次交易时处于离线时,用于在好友设备上共享钥匙的结构KeyAtt的起始位置(见第11节)。
MAILBOX_CONTENT_END_OFFSET指示专用邮箱的最后一个数据结构之后的空闲内存的第一个字节的偏移量。
邮箱缓冲区中数据结构的顺序应为相关信令位(S-Bit)的顺序,从Bit 0开始。
偏移值由车辆制造商和设备制造商共同定义,不在本技术规范的范围内。

4.3.2 机密邮箱

一旦在车辆和设备之间使用数字钥匙建立了第7节或第8节所述的安全通道,车辆就可以读取和写入机密邮箱。
与车辆交换的数据始终受到已建立的安全通道的保护。当数据被端点使用加密公钥进行加密时,数字钥匙框架也可以通过内部有线链路把该数据写入机密邮箱。如果端点配置允许并征得用户同意,则可以使用另一个受信任SE的加密公钥以加密形式导出机密邮箱的内容。
如果车辆制造商要求,防盗锁止令牌可以存储到机密邮箱和从机密邮箱中读出,并且可以与每个数字钥匙关联。
好友机密邮箱通常只包含与其活动防盗器令牌相对应的一个条目。活动防盗令牌是在数字钥匙交易过程中提供给车辆的一段秘密数据。
车主机密邮箱通常包含八个条目。第一个条目(索引0)专用于活动防盗器令牌,而其他七个条目包含要在共享钥匙操作期间分发给好友的防盗器令牌。
表4-3描述了当需要防盗令牌时的机密邮箱内存映射。
Figure 4-3:机密邮箱内容
在这里插入图片描述
活动防盗令牌应存在于偏移0处(见图4-6),并且是车辆在数字钥匙交换过程中所需的。如果车辆制造商需要防盗令牌,则该令牌应出现在车主和好友设备上。
条目1至7中的防盗令牌用于钥匙共享期间的分发使用(见第11节)。
IMMOBILIZER_TOKEN_LENGTH由数字钥匙框架提供。它在第一次NFC会话中的邮箱配置表中传输(见表5-13)。

4.3.3 防盗令牌

一个车辆制造商对设备可选的要求是存储和发布防盗令牌。防盗令牌是一个机密数据元素,在被要求时(例如,在启动发动机时)提供给车辆。防盗令牌的格式和内容不在本规范的范围内。
如果实施,车辆或车辆制造商服务器会在车主配对期间或之后向车主设备提供防盗令牌。好友设备的防盗令牌由车主设备或车辆制造商服务器提供。防盗锁令牌存储在机密邮箱中预先分配的条目中。机密邮箱大小应配置为防盗令牌大小的八倍。
防盗器令牌应与槽标识符相关联,如图4-7所示。

4.3.4 邮箱访问权限

下表总结了车辆和数字钥匙框架中邮箱的访问权限。
Table 4-4: 邮箱访问权
在这里插入图片描述

这篇关于CCC数字钥匙3.0标准解读(5)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/698701

相关文章

从去中心化到智能化:Web3如何与AI共同塑造数字生态

在数字时代的演进中,Web3和人工智能(AI)正成为塑造未来互联网的两大核心力量。Web3的去中心化理念与AI的智能化技术,正相互交织,共同推动数字生态的变革。本文将探讨Web3与AI的融合如何改变数字世界,并展望这一新兴组合如何重塑我们的在线体验。 Web3的去中心化愿景 Web3代表了互联网的第三代发展,它基于去中心化的区块链技术,旨在创建一个开放、透明且用户主导的数字生态。不同于传统

usaco 1.2 Name That Number(数字字母转化)

巧妙的利用code[b[0]-'A'] 将字符ABC...Z转换为数字 需要注意的是重新开一个数组 c [ ] 存储字符串 应人为的在末尾附上 ‘ \ 0 ’ 详见代码: /*ID: who jayLANG: C++TASK: namenum*/#include<stdio.h>#include<string.h>int main(){FILE *fin = fopen (

4B参数秒杀GPT-3.5:MiniCPM 3.0惊艳登场!

​ 面壁智能 在 AI 的世界里,总有那么几个时刻让人惊叹不已。面壁智能推出的 MiniCPM 3.0,这个仅有4B参数的"小钢炮",正在以惊人的实力挑战着 GPT-3.5 这个曾经的AI巨人。 MiniCPM 3.0 MiniCPM 3.0 MiniCPM 3.0 目前的主要功能有: 长上下文功能:原生支持 32k 上下文长度,性能完美。我们引入了

MCU7.keil中build产生的hex文件解读

1.hex文件大致解读 闲来无事,查看了MCU6.用keil新建项目的hex文件 用FlexHex打开 给我的第一印象是:经过软件的解释之后,发现这些数据排列地十分整齐 :02000F0080FE71:03000000020003F8:0C000300787FE4F6D8FD75810702000F3D:00000001FF 把解释后的数据当作十六进制来观察 1.每一行数据

Java ArrayList扩容机制 (源码解读)

结论:初始长度为10,若所需长度小于1.5倍原长度,则按照1.5倍扩容。若不够用则按照所需长度扩容。 一. 明确类内部重要变量含义         1:数组默认长度         2:这是一个共享的空数组实例,用于明确创建长度为0时的ArrayList ,比如通过 new ArrayList<>(0),ArrayList 内部的数组 elementData 会指向这个 EMPTY_EL

数据治理框架-ISO数据治理标准

引言 "数据治理"并不是一个新的概念,国内外有很多组织专注于数据治理理论和实践的研究。目前国际上,主要的数据治理框架有ISO数据治理标准、GDI数据治理框架、DAMA数据治理管理框架等。 ISO数据治理标准 改标准阐述了数据治理的标准、基本原则和数据治理模型,是一套完整的数据治理方法论。 ISO/IEC 38505标准的数据治理方法论的核心内容如下: 数据治理的目标:促进组织高效、合理地

Spring 源码解读:自定义实现Bean定义的注册与解析

引言 在Spring框架中,Bean的注册与解析是整个依赖注入流程的核心步骤。通过Bean定义,Spring容器知道如何创建、配置和管理每个Bean实例。本篇文章将通过实现一个简化版的Bean定义注册与解析机制,帮助你理解Spring框架背后的设计逻辑。我们还将对比Spring中的BeanDefinition和BeanDefinitionRegistry,以全面掌握Bean注册和解析的核心原理。

C 标准库 - `<float.h>`

C 标准库 - <float.h> 概述 <float.h> 是 C 标准库中的一个头文件,它定义了与浮点数类型相关的宏。这些宏提供了关于浮点数的属性信息,如精度、最小和最大值、以及舍入误差等。这个头文件对于需要精确控制浮点数行为的程序非常有用,尤其是在数值计算和科学计算领域。 主要宏 <float.h> 中定义了许多宏,下面列举了一些主要的宏: FLT_RADIX:定义了浮点数的基数。

GPT系列之:GPT-1,GPT-2,GPT-3详细解读

一、GPT1 论文:Improving Language Understanding by Generative Pre-Training 链接:https://cdn.openai.com/research-covers/languageunsupervised/language_understanding_paper.pdf 启发点:生成loss和微调loss同时作用,让下游任务来适应预训

AIGC6: 走进腾讯数字盛会

图中是一个程序员,去参加一个技术盛会。AI大潮下,五颜六色,各种不确定。 背景 AI对各行各业的冲击越来越大,身处职场的我也能清晰的感受到。 我所在的行业为全球客服外包行业。 业务模式为: 为国际跨境公司提供不同地区不同语言的客服外包解决方案,除了人力,还有软件系统。 软件系统主要是提供了客服跟客人的渠道沟通和工单管理,内部管理跟甲方的合同对接,绩效评估,BI数据透视。 客服跟客人