CCC3.0学习笔记_证书数据

系列文章目录


文章目录

  • 系列文章目录
  • 前言
    • 1. [A] - SE Root CA Certificate
    • 2. [B] - SE Root Certificate
    • 3. [C] - Instance CA Attestation (signed by SE Root) per Vehicle OEM
    • 4. [D] - Device OEM CA Certificate
    • 5. [E] - Instance CA Certificate (Signed by Device OEM) per Vehicle OEM
    • 6. [F] – Device OEM CA Certificate (Signed by Vehicle OEM)
    • 7. [G] - Digital Key per vehicle
    • 8. [H] - Digital Key Certificate
    • 9. [J] - Vehicle OEM CA Certificate
    • 10. [K] - Vehicle Public Key Certificate
    • 11. [L] - Digital Key Creation Data
    • 10. [M] – Vehicle OEM CA Certificate (signed by Device OEM)
    • 11. [N] – Instance CA Attestation (self-signed) per Vehicle OEM
  • 总结

前言

数字密钥是目前车钥匙发展的大趋势,但是在给车主提供极大便利的同时,也伴随着风险性的增加,所以把手机当做数字钥匙与车辆进行交互的时候,需要手机车辆以及服务器之间的联动,每个环节都涉及到信息安全的问题,所以数字钥匙是基于PKI公钥基础设施来做信息安全,而其中以证书为重点,大家都知道数字证书在网络中就等同于身份证一样的地位,所以简单聊一下数字钥匙实现中使用到的一些证书数据。


1. [A] - SE Root CA Certificate

This certificate applies to Variant 1. This certificate is provided by the entity that controls the root key pair in the SE, e.g., the SE manufacturer. It is trusted by the Device OEM CA. The SE Root CA private key has signed the SE Root Certificates [B] embedded in the SE. Those certificates include immutable identifiers that could allow device tracking. It is mandatory for every Digital Key-eligible Device OEM to be able to validate SE root signatures from the SEs on its devices.
这个证书是一个自签名证书,是一个受信任的证书。

2. [B] - SE Root Certificate

This certificate applies to Variant 1. The SE Root Certificate [B] is generated securely and attests to the identity of the SE. [B] is signed by the SE Root CA. [B] is used to verify the Instance CA Attestation [C] created by the Digital Key applet instance. If [C] is successfully verified by [B], the Device OEM signed Instance CA Certificate [E] is issued by the Device OEM Server and stored in the device OS of the corresponding device. Within the SE, [B] is stored in the CASD. The provisioning of the [B] in the SE is out of scope of this specification.
每一片SE加密芯片内部在上产生时由供应商内置一组公私密钥对(SE-Root.SK/PK),证书【B】是由 SE-Root CA对SE的根密钥进行签名得到,证书【B】对数字密钥小程序产生的实例CA证书进行校验,如果实例CA证书【C】校验通过,设备服务器端的 DeviceOEM CA会发行实例CA证书【E】,证书【E】会在车主配对的过程中发送到车辆端,并且是手机端提供给车辆端证书链中的一环。

3. [C] - Instance CA Attestation (signed by SE Root) per Vehicle OEM

This certificate applies to Variant 1. The Instance CA Attestation [C] is generated after an Instance CA is created by the Digital Key applet instance. [C] includes the public key of the Instance CA and is signed by the private key of the SE root. One Instance CA is created per Vehicle OEM. The Device OEM CA verifies and signs [C] with its private key to issue a new Instance CA Certificate [E] (See Section 16.2.5). [E] is verifiable using the Device OEM CA Certificate [D] and Vehicle OEM signed Device OEM CA Certificate [F]. Within the SE, the private key of the SE root is stored in the CASD. The provisioning of this private key is out of scope of this specification. The signature of [C] by the private key of the SE root may rely on a proprietary API implemented by the CASD or may rely on the CASD signature service available through AuthoritySignature interface as defined in [16].
实例CA证书【C】是数字密钥小程序创建了一个实例CA后产生的,这个证书【C】是利用SE的根密钥 SE-Root.SK私钥签名生成,对于每一个不同的车厂,数字密钥小程序都会产生一个 Instance CA来与之对应,这为一部手机成为不同车厂的车辆的数字钥匙成为可能,因为证书【B】是需要提供给 Device OEM Server , 因此设备厂商服务器可以对证书【C】进行验证,如果验证通过后,就会使用 Devcie OEM CA.SK 对证书【C】进一步签名从而发行一个新的证书【E】,这个新的证书【E】在车主配对的时候由手机端发送给车辆。

4. [D] - Device OEM CA Certificate

This certificate is the Device OEM root of trust for the Digital Key system. This certificate is trusted by the Device OEM and all Vehicle OEMs. The Vehicle OEM receives a CSR from the Device OEM in order to countersign the Device OEM CA Certificate [D]. This then becomes a Vehicle OEM signed Device OEM CA Certificate [F] with the same Device OEM public key. Depending on the Device OEM’s implementation or the Digital Key service deployment model, the Device OEM CA Certificate [D] may be stored in the device OS or in the SE.
同理证书【D】也是一个受信任的自签名证书。

5. [E] - Instance CA Certificate (Signed by Device OEM) per Vehicle OEM

The Device OEM-signed Instance CA Certificate [E] contains the public key of the Instance CA Attestation [C] (Variant 1) or [N] (Variant 2) and is signed by the private key of the Device OEM CA. [E] allows the verification of the Instance CA Attestation using a Device OEM CA Certificate [F]. Using the Device OEM CA signature removes the requirements of otherwise having to trust the SE Root CA. It also anonymizes the static device information to external parties. During the owner paring, [E] is transferred to the vehicle and is used to verify the Digital Key Certificate [H]. The certificate should have a short lifetime and should be renewed often. Revocation may be achieved by stopping the renewal process or through revocation methods (CRL, OCSP), which are out of scope of this specification
证书【E】在前面已经提及到,当设备端服务器对证书【C】验签过后,就会使用 DeviceOEM CA.SK 对证书【C】签名而发行的证书。

6. [F] – Device OEM CA Certificate (Signed by Vehicle OEM)

The Vehicle OEM CA public key is embedded in the Vehicle OEM CA Certificate [J] in the vehicle (for owner pairing) and in authorized PK in the owner SE (for key sharing). This Vehicle OEM CA public key is used to verify the Vehicle OEM signed Device OEM CA Certificate [F] (note that [F] is also referred to as an “external CA certificate” in Section 15). [F] is then used to verify the Device OEM signed Instance CA Certificate [E]. [F] shall be stored in the device OS of all devices eligible for Digital Keys.
证书【F】是VehicleOEM CA.SK 对自签名证书【D】进行签名,而且证书【F】也是需要在车主配对的时候由手机端发送至车辆端,并且是手机端的一条证书链的一环。

7. [G] - Digital Key per vehicle

[G] is the Digital Key generated by the Digital Key applet. There is one Digital Key per vehicle. During owner pairing, all Digital Key elements are provided by the vehicle and transferred to the device.
在车主配对过程中,车辆需要将创建数字密钥,比如车辆标识符等所需数据单元提供给手机端,由数字密钥小程序创建一个数字密钥,因为每一辆车的信息都不一样,所以每一辆车都会有一个不同的数字密钥【G】。

8. [H] - Digital Key Certificate

When a Digital Key is created, the applet signs the public key of the Digital Key structure using the corresponding Instance CA’s private key (see Section 4.1) to create the Digital Key Certificate [H]. The certificate is required for owner pairing and key sharing.
证书【H】是实例CA(对应一个车厂)私钥对数字密钥进行签名得到数字密钥证书,因为每辆车的数字密钥【G】都是不同的,所以这个证书【H】也是不一样的,这个证书【H】也是需要在车主配对的过程中由手机发送至车辆端,并且与【E】和证书【F】组成一条完整的证书链。

9. [J] - Vehicle OEM CA Certificate

This certificate is the Vehicle OEM root of trust for the Digital Key system. [J] is trusted by all Device OEMs and the corresponding Vehicle OEM. The private key corresponding to the Vehicle OEM CA Certificate is used to sign the Device OEM CA Certificate [D] to become [F]. [F] is transferred to the vehicle in order to verify the certificate chain at owner pairing, in which [F] is first verified by [J]. This leads to the Digital Key attestation as shown in Figure 6-7. The public key of this certificate is also embedded in the owner’s Digital Key (as authorized PK). It is used during key sharing to verify the certificate chain, i.e., to validate the friend’s public key origin. The Device OEM may embed [J] on the device and use it to validate the authenticity of the vehicle public key (i.e., Vehicle.PK) contained in [K].
证书【J】也是一个受信任的自签名证书,这个证书【J】需要事先提供给到手机端。
每一辆车都是使用同样的一个证书【J】作为证书链验证的起点,经过多级证书的验签操作,车辆端才会获取到一个合法的数字密钥的公钥,校验过程中的任何一级验签失败,则终止提取数字密钥公钥的操作。

10. [K] - Vehicle Public Key Certificate

Before accepting the Digital Key Creation Data [L] from the vehicle during owner pairing, the device verifies the origin of the vehicle public key (i.e., Vehicle.PK) using the Vehicle Public Key Certificate [K]. The Vehicle.PK is attested to by the Vehicle OEM CA Certificate [J]. Note: The device uses the Vehicle OEM CA Certificate [J] or Device OEM signed Vehicle OEM CA Certificate [M] to verify [K] as described in Sections 16.2.9 and 16.2.12, respectively, before using [K] to verify Digital Key Creation Data [L].
证书【K】是利用 VehicleOEM CA私钥对车辆端的永久公私密钥对进行签名得到,此证书【K】需要在车主配对的时候发送至手机端,因为证书【J】提前预置在手机端,所以利用证书【J】对证书【K】进行验签,当进行车主配对的时候,手机端在接收车辆端的数字密钥创建数据【L】之前,需要先验证车辆永久公钥来源的合法性。

11. [L] - Digital Key Creation Data

The Digital Key Creation Data [L] (not shown in Figure 16-1) is described in Figure 6-5. The authorized public keys are the root of trust for key sharing. Authorized Public Key #1: Vehicle OEM CA PK (mandatory)
This is used as the root for the key sharing validation chain. It cannot be updated once the Digital Key is created.
从规范中的第四章描述的数字钥匙数据结构中可以看到授权公钥一共有5个,但是第一个强制性设置为 VehicleOEM CA.PK,其它几个可以根据需要添加,授权公钥主要是在密钥分享时的证书链的校验。

10. [M] – Vehicle OEM CA Certificate (signed by Device OEM)

The device may use the Device OEM signed Vehicle OEM CA Certificate [M] to validate the authenticity of the vehicle public key (i.e., Vehicle.PK) contained in the Vehicle Public Key Certificate [K]. The root of the validation chain is the Device OEM CA Certificate [D], which is trusted by the device. The public key of the Device OEM is used to validate the signature of [M].
根据前面提到的利用VehicleOEM CA.SK 对手机端的证书【D】签名得到证书【F】然后将证书【F】发送至车辆端,当然反过来也是可以的,就是利用手机端的DeviceOEM CA.SK对车辆端的自签名证书【J】签名就得到车端证书【M】然后证书【M】由车辆端发送至手机端,然后手机端就可以使用自签名证书【D】对证书【M】进行验签。

11. [N] – Instance CA Attestation (self-signed) per Vehicle OEM

This attestation applies to Variant 2. [N] is generated when a new Instance CA is created in the Digital Key applet. [N] contains the public key of the Instance CA in the Digital Key applet and is self-signed by the Instance CA using its private key, instanceCA.SK. [N] is retrieved and verified by the Device OEM Server, and then the Device OEM Server issues a new Instance CA Certificate [E] by signing the InstanceCA.PK with the DeviceOEM.SK. When implementing Variant 2, the SE root of trust is ensured by the following mechanisms: • The Digital Key applet generates the Instance CA Attestation [N]. • The Device OEM Server opens a secure channel with the Digital Key applet to retrieve [N]. • One of the SCPs defined by GlobalPlatform (e.g., SCP03) shall be used. This secure channel shall be set to provide, at a minimum, integrity and data origin authentication on the APDU responses (i.e., requesting R-MAC with or without R-ENCRYPTION in parameter “i” when SCP03 is used). • The Digital Key applet relies on its security domain for the implementation of the secure channel. • The secure channel keys used by the security domain (i.e., AES keys when SCP03 is used) are specific to a given SE and are trusted by the Device OEM Server.
• When the Device OEM Server analyzes the response of the Digital Key applet, a successful verification of the R-MAC ensures that the data received over this secure channel has been generated by the expected Digital Key applet in the SE. Figure 16-2 depicts the adaptation of the certificate chain model for Variant 2. After successful verification of the Instance CA Attestation [N], the Instance CA Certificate [E] is issued by the Device OEM Server.
证书【N】就是数字密钥小程序产生一个实例公私密钥对(注意一个车厂对应一个,并不是每一辆车都有一个不同的),然后进行自签名就得到自签名证书【N】,证书【N】是证书链模型2中使用到的,而目前都是按照证书链模型1来执行的。

总结

以上内容主要是介绍了数字钥匙系统中使用到的一些数字证书,本次就先说到这里吧。

CCC3.0学习笔记_证书数据相关推荐

  1. CCC3.0学习笔记_数字密钥数据结构

    CCC3.0学习笔记_数字密钥数据结构 系列文章目录 文章目录 系列文章目录 前言 4.1 Applet Instance Layout 4.2 Digital Key Structure 4.2.1 ...

  2. CCC3.0学习笔记_认证和隐私保护

    CCC3.0学习笔记_Authentication and Privacy Keys 系列文章目录 文章目录 系列文章目录 前言 1. 手机端和车厂服务器端的密钥存储 2. 密钥的产生和使用的说明 3 ...

  3. CCC3.0学习笔记_数字密钥分享

    系列文章目录 第六章 CCC3.0 DIGITAL KEY SHARING 数字密钥分享 文章目录 系列文章目录 前言 一.跨平台密钥分享通道建立 1. Channel Establishment f ...

  4. CCC3.0学习笔记_蓝牙OOB配对

    系列文章目录 第四章 CCC3.0数字车钥匙学习入门之蓝牙OOB配对 文章目录 系列文章目录 前言 一.蓝牙的几种配对方式 1. Numeric Comparision 2. Just Works 3 ...

  5. CCC3.0学习笔记_数字钥匙系统架构

    系列文章目录 第六章 CCC3.0 System Architecture 文章目录 系列文章目录 前言 1. 概述和范围 2. 高层级功能 3. 高层级架构 总结 前言 随着科技不断发展,车钥匙经历 ...

  6. CCC3.0学习笔记_快速交易

    上一次有提及只有进行过车辆与手机的标准交易之后,才有可能进行快速交易,假定双方已进行过标准交易,也就是在车辆和手机端的NVM中已经保存了长期的对称密钥 Kpersistent, 下面将详细快速交易的整 ...

  7. CCC3.0学习笔记_标准交易

    下面对车辆与手机进行标准交易的整个过程的详细解释: 执行此标准交易的前提条件是车辆已经从车厂服务器获取到公私密钥对(Vehicle.PK&Vehicle.SK)同时手机端也具有自身终端的公私密 ...

  8. CCC3.0学习笔记_SPAKE2+ Flow 流程

    系列文章目录 第五章 CCC3.0 SPAKE2+ Flow 流程说明 文章目录 系列文章目录 前言 一.Vehicle OEM Server 1. CCC中车辆服务器的职责 2. 车辆服务器产生配对 ...

  9. CCC3.0学习笔记_SCP03安全通道

    1. 在安全通道建立的情况下,数据安全交互的应答流程图如下所示,具体步骤解释如下: 1> 避免SCP03安全通道协议中的CMAC与C-MAC的混淆,CMAC是计算C-MAC校验值的一       ...

最新文章

  1. 火爆 GitHub!这个 AI 神器究竟有什么魅力?
  2. java -jar 未响应_Java 方法性能监控和统计工具 MyPerf4J
  3. php sf框架,GitHub - YanCastle/sf: php swoole framework
  4. POJ-2391 Ombrophobic Bovines 网络流-拆点构图
  5. 申请表怎么填才能提高信用卡额度?
  6. Android之Only fullscreen opaque activities can request orientation
  7. PPT快捷键大全(作分析报告的人有福了)
  8. POP Animation 和 layoutSubviews 的冲突
  9. adb devices出现no permissions
  10. 组态王软件自动邮件EMAIL发送
  11. linux基础-命令
  12. Yolov5检测并生成文本及标签文件
  13. hud.java_什么是HUD
  14. TensorFlow实现CGAN
  15. ios让您的today变得更加有节奏,新出品Today:日历、提醒、习惯养成、倒计时
  16. 激活windows转到电脑设置的水印怎么消失
  17. Linux tar 命令 将归档内指定文件解压到指定目录
  18. 循环中continue用法
  19. 摇摇招车CEO:本月北京打车App将共用同一运营后台
  20. geoserver+nginx

热门文章

  1. 超实用k8s集群资源清理命令
  2. python性能测试方法_Python性能测试之performance
  3. 关于qt上实现基于百度的语音识别
  4. 如何将Luminar作为Photoshop滤镜插件使用?
  5. MTK在编译10A的target时报错:make: *** [mmi_feature_check]
  6. EReg 1.0: SPSS中的扩展回归分析插件
  7. 【jQuery 教程系列第 10 篇】jQuery 中的过滤选择器(基本筛选器)
  8. AppLocale使用后安装程序乱码问题的解决
  9. 游戏场景设计之项目最终的气氛营造烘托
  10. Pytorch Note32 稠密连接的卷积网络 DenseNet