基于车路协同的通信证书管理技术规范

1 范围

本文件规定了使用注册证书获得通信证书（特指身份证书和应用证书）的技术规范，包括车载单元、路边站使用已获得的注册证书申请通信证书的流程，本文件还包括通信证书的申请主体（如车载单元、路边站等）与通信证书的颁发主体（如应用证书机构）间的接口定义。
本文件适用于申请通信证书的车载单元或路边站，其他具有相同或类似申请通信证书功能的证书申请主体和证书颁发主体也可参考使用。

2 规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
YD/T 3594-2019 基于 LTE 网络的车联网通信安全技术要求。

3 术语和定义

下列术语和定义适用于本文件。

3.1 车路协同 vehicle-infrastructure cooperation

采用无线通信和互联网等，实施车路动态实时信息交互，并在动态交通信息采集与融合的基础上开展车辆主动安全和道路协同管理，充分实现人车路的有效协同，保证交通安全，提高通行效率的道路交通系统。

3.2 注册证书机构 enrollment certificate authority

为车载单元或路边站颁发注册证书的受信机构。

3.3 应用证书机构 application certificate authority

为路边站颁发应用证书以及为车载单元颁发身份证书的受信机构。

3.4 根证书机构 root certificate authority

为注册机构或授权机构等颁发相应证书，以使得注册机构或授权机构可以为车载单元或路边站颁发相应证书的受信机构，为信任链的起始结点。

3.5 身份证书 identification certificate

车载终端向路边站证明其身份以获得某种应用服务所使用的证书。

3.6 应用证书 application certificate

路边站用于对其广播的消息进行签名的证书。

3.7 通信证书 communication certificate

为了简便，本文件中将车载单元使用的身份证书和路边站使用的应用证书统称为通信证书。

3.8 车载单元 on-board unit

安装在车辆上，与路边站或其他车载单元进行信息交互的设备。

3.9 路边站 road-side unit

安装在路边，与车载单元进行信息交互的设备，路边站与路边站之间通过光纤相连。

4 概述

本文件关注的对象为证书申请主体（如车载单元、路边站等）、应用证书机构（ACA）和应用证书注册机构（ARA）等 尤其涉 证书申请主体与 ARA、ACA 和 MA 间的接口定义。ACA 用于向车载单元（OBU）和路边站（RSU）签发身份证书和应用证书。本文件中证书管理架构基于公钥基础设施（PKI）实现，部署方统一根 PKI 架构如图 1 所示，以及非统一根 PKI 架构如图 2 所示。
image.png
在统一根架构下，注册证书机构（ECA）、ACA 等都接到统一的 RCA 下，因此 OBU 或 RSU 在储存了根证书、机构证书的情况下可以验证 ECA、ACA 等颁发的证书。
image.png
车联网安全系统可能由多个独立 PKI 系统构成（即非统一根 PKI 架构），此时这些 PKI 系统之间可以根据需要构建可信关系，以便实现证书互认，实现多 PKI 体系可信关系的原理如图 2 所示。多个车联网 PKI 系统之间的可信关系是通过一个“可信证书列表（Certificate Trust List，CTL）”实现的。该可信列表由证书可信关系管理机构（Certificate Trust Relationship Authority，CTRA）颁发 。“可信证书列表”的存在与否不会影响各个独立 PKI 系统的运行，但会影响不同 PKI 系统证书之间是否能够互认。车联网系统可以根据需要动态地向 CTL 添加或从 CTL 中移除根 CA 证书。当新 CTL 列表产生后，旧 CTL列表自动作废。关于 CTL 列表的添加、移除等操作不在本文件范围内。
本文件适用于 OBU 或 RSU 利用已获得的 ECA 颁发的有效注册证书后向 ACA 申请通信证书的场景，其中，注册证书和通信证书的格式可参考《基于 LTE 的车联网无线通信技术 安全证书管理系统技术要求》。

5 流程定义

5.1 概述

本节主要介绍在使用注册证书申请通信证书时所涉及到的证书操作流程，主要申请通信证书和申请证书撤销列表（CRL）的流程。

5.2 申请证书

当 OBU 或 RSU 需要发送车路协同的相关消息但此时还未获得相应的通信证书时，需要执行通信证书申请流程，执行该流程的前提是 OBU 或 RSU 已经获得了有效的注册证书。申请通信证书前，OBU或 RSU 应与 ARA 采用安全环境、应用层加密、TLS 安全通道等措施建立安全连接。下面以 RSU 申请应用证书为例，申请身份证书的方法流程类似：
image.png

  1. RSU 为所申请证书生成用于签名功能的公私密钥对，并生成通信证书请求消息，并使用其注册证书的私钥对上述消息进行签名。

若所申请证书中应包含有专门用于数据加密的加密公钥，则还应生成一个用于数据加密的公私密钥对。
基于具体的安全需求，可对通信证书申请消息提供机密性保护。机密性保护应使用接收方的公钥证书中的公钥对通信证书申请请求消息进行公钥加密保护。若接收方公钥证书中包含有加密公钥，则应优先使用该加密公钥。

  1. RSU 将签名的通信证书请求消息连同注册证书发送给 ARA。
  2. ARA 首先验证注册证书的有效性，例如有效期和是否已被撤销等，然后使用 RSU 注册中的公钥验证通信证书请求消息签名的正确性。若该消息为加密消息，则在验证消息签名之前使用与加密钥对应的私钥对加密消息进行解密。
  3. ARA 向 RSU 返回应用证书申请响应。响应中包含所申请证书的下载时间和与所下载证书相关的标识等信息。
  4. 若此证书颁发过程需要具有证书颁发授权能力的 AAA 的授权，则 ARA 应向该 AAA 发送证书颁发授权请求。授权请求中应包含有该 RSU 标识和代表证书应用领域的应用标识信息，并可包含有描述证书具体适用领域权限的应用描述信息和描述该应用对 RSU 本身需求的设备需求描述信息。若 RSU证书请求消息中包含有 RSU 提供给 AAA 的数据，则应在该授权请求中包含有该数据。AAA 的地址可由 RSU 通过其证书申请消息提供，或由 ARA 本地配置据确定。
  5. AAA 检查 ARA 发送的授权请求，包括包含在授 请求中的由 RSU 生成的车辆和/或设备描述信息，确定是否允许向该 RSU 颁发所申请的应用证书。若允许，则 AAA 应为该 RSU 颁发一个经其数字签名的授权令牌，并将该授权令牌发送给 ARA。
  6. ARA 基于本地证书颁发策略确定是否向该 RSU 颁发证书。若允许，则为该 RSU 生成一个通信证书生成请求，并将该请求发送给 ACA
  7. ACA 基于 ARA 发送的证书生成请求为该 RSU 生成一个通信证书。
  8. ACA 将生成的通信证书 过证书生成响应发送给 ARA。
  9. ARA 使用接收到的 RSU 应用证书数据生成证书下载包，并存储证书下载包以供 V2X 设备下载。
  10. RSU 向 ARA 发用证书下载请求，其中包含有与下载证书相关的标识信息。
  11. ARA依据下载请求中的标识信息，获取存储在本地的 RSU 应用证书数据，生成 V2X 应用证书下载包，然后通过应用证书下载响应发送给 RSU。

  12. RSU验证应用证书下载响应，并存储颁发的应用证书。

    5.3 更新证书

    当 OBU 或 RSU 所使用的通信证书不再有效（包括过期、被吊销等）时，需要执行通信证书更新流程。流程同 5.2 申请证书。

    5.4 申请证书撤销列表

    当 OBU/RSU 收到对端发来的消息时，首先需要确认对端所使用的通信证书是否已经被撤销，在确定通信证书没有被撤销时再对通信证书和消息签名进行验证。OBU/RSU 通信证书的撤销，主要基于不当行为机制实现。当 MA 收到针对某 OBU/RSU 的不当行为上报信息后，根据 MA 的不当行为决策策略，判断该 OBU/RSU 通信证书是否需要撤销。当判断该 OBU/RSU 通信证书需要撤销时，由 MA 负责该设备应用证书、身份证书 CRL 的签发。同时，ARA 也可将注册证书加入黑名单，当收到通信证书申请时，拒绝该申请。
    当通信证书的撤销列表过大时，可根据实际需求，针对不同的设备类型、证书类型、地理区域书，签发不同的 CRL，以减小单个 CRL 文件的大小。
    本文件支持全量和增量 CRL，CRL 签发机构可根据实际情况，签发全量和增量 CRL。
    证书撤销列表相关应用使用的 AID，其应用标识取值为十进制 3628。
    在下载 CRL 前，OBU/RSU 应和 RA 建立 TLS 安全通道，OBU/RSU 获取证书撤销 表的过程如下：
    image.png

  13. 证书撤销机构 CRA 根据 CRA 的证书撤销列表更新策略，定期更新 CRL，并使用 CRA 的私钥对 CRL 签名。

  14. CRA 将生成的CRL下发至ARA。
  15. OBU/RSU 根据设备的 CRL 更新策略，向 ARA 发送 CRL 下载请求。
  16. ARA 将向 OBU/RSU 发送 CRL 下载应答。
  17. OBU/RSU 先验证 CRL 的签名有效性和内容完整性，然后判断是否更新本地 CRL，若需要更新，则将CRL写入本地安全存储中。

    6 接口定义

    6.1 申请证书

    以下接口用于 OBU/RSU 向 ACA 申请通信证书。
    证书申请请求类型：HTTP POST 或 HTTPS POST
    HTTP Content-Type: application/octet-stream
    HTTP request body 中包含版本信息、时间、公钥等参数，具体如下；
  • version：包含结构的当前版本，在本文件中此处版本号为 1。
  • generationTime：包含通信证书请求生成时间。
  • type：指示 OBU/RSU 申请的证书类型。
  • cracaId：指示颁发此证书的 CRL CA 的证书的哈希值，本文件置为全 0。
  • crlSeries：指示 CRL 序列号，本文件中取值为 0。
  • appPermissions：指示所具有的应用数据签名权限（例如 OBU/RSU 签名的应用消息类 ）。
  • verifyKeyIndicator：包含 OBU/RSU 发送的公钥信息。

HTTP response body 中包含版本信息、证书下载时间等参数，具体如下：

  • version：包含结构的当前版本，在本文件中此处版本号为 1。
  • generationTime：包含通信证书响应生成时间。
  • requestHash：包含对应的通信证书申请的哈希值。
  • nextDlTime：在此时间之后，OBU/RSU 可以连接到 ARA 以下载通信证书。

以下接口用于 OBU/RSU 从 ARA 下载通信证书。
证书下载请求类型：HTTP GET 或 HTTPS GET
响应中包含通信证书等参数。

6.2 申请证书撤销列表

该接口用于 OBU/RSU 申请证书撤销列表。
证书撤销列表申请请求类型：HTTP GET 或 HTTPS GET
响应中包含证书吊销列表等参数。

7 互信机制

7.1 互信架构

为实现跨域认证，一 认证域中的设备需要获取另一个认证域签发证书的 CA 证书或证书链。本文件将一个 证域提供给 一个认证域的用于互信操作的顶级 CA 证书为可信根 CA 证书（Trusted Root）。该顶级CA证书可以是该认证域的自签名的根CA证书，也可以是该认证域的非自签名的子CA证书。
PKI互信架构如图5所示。
image.png
该架构由如下功能实体和数据构成：
可信根证书列表管理机构（Trusted Root Certificate List Authority，TRCLA）：负责颁发可信根证书列表。
可信根证书列表（Trusted Root Certificate List，TRCL）：由可信的 PKI 系统的根证书、可信的 PKI系统的可信域 CA 证书列表下载地址和保护可信根证书列表的安全机制构成。保护可信根证书列表的安全机制为数字签名技术。
可信根证书列表证书：用于对可信根证书列表提供数字签名保护的公钥证书。该证书可以是符合本文件定义的车联网证 ，也可以是符合 X.509 证书规范的证书。
可信证书管理功能 （Trusted Certificate Management Function，TCMF）：在一个 PKI 系统内负责与可信根证书列表管理机构交互，向可信根证书列表管理机构提供本 PKI 系统与互信操作相关的数据，从可信根证书列表管理机构获取实现PKI互信所需要的数据和向本 PKI 系统内的 OBU/RSU 提供实现PKI互信所需要的数据。
可信域 CA 证书列表（Trusted Domain CA Certificates List，TDCL）：由一个 PKI 系统颁发的包含有其他 PKI 系统验证本 PKI 系统所颁发证书时需要 CA 证书的列表和保护可信域 CA 证书列表的安全机制构成。列表中的 CA 证书应为从相关 CA 至该 PKI 根的证书链。保护可信域 CA 证书列表的安全机制为数字签名技术。
可信根证书列表（TRCL）和可信域 CA 证书列表（TDCL）的发布可以分为集中式和分布式两种。
集中式发布方式是指可信根证书列表管理机构（TRCLA）将 TRCL 和各个安全域的 TDCL 发送给各个安全域，然后由各个安全域确定如何分发给域内的 OBU/RSU。
分布式发布方式是指向 OBU/RSU 提供下载 TRCL 和各个安全域的 TDCL，然后由 OBU/RSU 自行下载交叉认证时需要的各个认证域的 CA 证书。

7.2 可信根证书列表结构

可信根证书列表结构及各字段的用途如表 1 所示。
image.png

7.3 可信域 CA 证书列表结构

可信域CA证书列表结构及各字段的用途如表2所示。
image.png

7.4 PKI 互信管理过程

7.4.1 分布式 PKI 互信管理过程

image.png
分布式 PKI 互信管理过程如下：

  1. 可信根证书列表管理机构将可信根证书列表签名证书和可信根证书列表下载地址提供给一个可信 PKI 系统中的可信证书管理功能。
  2. 一个可信 PKI 系统的可信证书管理功能生成并发布可信 CA 证列表。该列表的管理和发布应符合相关规范。
  3. 可信证书管理功能向可证书列表管理机构提供其根证书和可信域 CA 证书列表下载地址。
  4. 可信根证书列 管理机构利用各可信 PKI 系统提供的根证书和可信域 CA 证书列表下载地址生成一个可信根证书列表并 该列表发布至可公开下载的网络上。
  5. 在一个可信PKI系统内，可信证书管理功能以安全的方式向其域内的 OBU/RSU 写入可信根证书列和可信根证书列表下载地址。
  6. 首先依据可信根证书列表下载地址下载可信根证书列表，然后使用可信根证书列表签证书验证可信根证书列表的数字签名。
  7. 基于下载的可信根证书列表，OBU/RSU 执行如下操作：

1）获取可信根证书列表中的某个列项；
2）使用该列项中的可信域 CA 证书列表下载地址下载可信域 CA 证书列表；
3）使用该列项中的根证书验证下载的可信域 CA 证书列表的数字签名；
4）使用该列项中的根证书验证可信域 CA 证书列表中证书链的正确性。
5）若可信域 CA 证书列表提供了 CRL 下载地址，则还应下载相应的 CRL。

7.4.2 集中式 PKI 互信管理过程

集中式 PKI 互信管理的一般过程如图 7 所示。
image.png
集中式 PKI 互信管理过程如下：

  1. 可信根证书列表管理机构将可信根证书列表签提供给一个可信 PKI 系统中的可信证书管理功能。
  2. 可信证书管理功能向可信根证书列表管理机构提供其根证书和可信域 CA 证书列表。
  3. 可信根证书列表管理机构生成一个可信根证书列表，并将该列表和其他可信域的可信域 CA 证书列表提供可信 PKI 系统的可信证书管理功能。
  4. 可信 PKI 系统的可信证书管理功能以安全的方式向其域内的 OBU/RSU 写入可信根证书列表签名证书和各可信列表的下载地址。
  5. OBU/RSU 依据提供的可信根证书列表下载地址下载可信根证书列表，然后使用可信根证书列表签名证书验证可信根证书列表的数字签名。
  6. OBU /RSU 依据提供的可信CA证列表下载地址可信域CA证书列表，然后利用可信根证书列表中的相应的可信域根证书验证下载的列表。

证书撤销列表使用的AID应为十进制3628。

7 5 PKI 互 认证过程

PKI 互信认证的一般过程为：

  1. OBU/RSU 接收其他 OBU/RSU 播发的签名消息。
  2. OBU/RSU 获取签名消息中携带的签名证书。
  3. OBU/RSU 获取签名证书中证书颁发者标识。
  4. OBU/RSU 利用获取的证书颁发者标识与本 PKI 系统的 CA 证书和其他可信 PKI 系统的 CA 证书的 HashedId8 值相比较，若有匹配，则利用相应的 CA 证书验证消息签名证书，并检查相应的 CRL，以确定该证书是否已被撤销。

  5. OBU/RSU 利用通过验证的消息签名证书验证消息签名。

    8 异常行为检测上报流程

    异常行为是指在直连通信中，部分节点由于有意或无意的原因，对外发送包含虚假或错误内容的信息，从而对于直连通信自组网络中其它的通信节点造成影响其进行业务判断的行为。其中恶意的 击者可能对于整体直连通信自组网络的运转效率和安全性带来严重的影响。因此，需要考虑在直连通信自网中实现异常行为检测的能力。
    异常行为检测，通常包括如下过程：

  6. 本地异常行为检测：终端设备根据接收到的周边消息，以及本地的检测算法，判断消息是否异常；

  7. 上报：对于确定的终端设备异常行为，需要上报给专门的异常行为检测中心（MisbehaviorAuthority，MA）进行进一步的检测。
  8. 全局异常行为检测：MA 根据收到的多方上报的本地异常行为检测报告信息，汇总并决策是否确实是异常行为；
  9. 证书吊销：对于确认为异常行为的终端设备，需要对其证书进行吊销。

本文件当前版本中仅考虑终端设备与异常行为检测机构之间的通信交互接口定义。不涉及系统中各实体如何实现本地异常行为检测、全局异常行为检测，也不涉及具体执行相关检测的实体如何在当前PKI 架构中的映射和定义关系。