CN116827544B - 一种用于更换车载obu信任根的方法及系统 - Google Patents

Abstract

本发明公开了一种用于更换车载OBU信任根的方法及系统，属于车载OBU技术领域。本发明方法，包括：获取车载OBU的信息数据；基于车载OBU的信息数据，定义车载OBU中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。采取本发明的方法对车载OBU的信任根进行更换，成本较低，能够满足车载OBU信息安全需求。

Description

一种用于更换车载OBU信任根的方法及系统

技术领域

本发明涉及车载OBU技术领域，并且更具体地，涉及一种用于更换车载OBU信任根的方法及系统。

背景技术

随着车载信息系统、车云通信系统的不断发展，车载 OBU（On Board Unit）作为车载智能终端日益重要。车载OBU 需要与云端平台、充电桩、维修设备等多种外部系统或设备进行大量信息交互，这使得车载 OBU 面临较高的安全威胁，如非法访问、数据窃取、病毒感染等。

为保障车载 OBU 信息安全，数字证书、数字签名等非对称密钥技术被广泛应用于车载 OBU 系统，用于对通信对象及数据信息进行认证和加密。车载 OBU 通常会预置出厂时签发的数字证书（如根证书）作为 OBU 自身的身份凭证。车载 OBU 同时会预置多种根证书，作为车载 OBU 的信任根。在车载 OBU 与外界通信时，通过这些根证书来验证另一个通信实体的身份真实性，以及验证重要通信信息的有效性。但随着时间推移，上述根证书会面临证书过期、证书所采用的签名算法出现安全漏洞，以及证书私钥泄露等多种风险，这将直接威胁车载 OBU 乃至车辆和车联网平台的系统安全。

现有技术中，车载 OBU 系统难以在线对信任根进行安全替换，通常只能通过换卡、硬件更换等物理方式进行更新，这无疑会带来较高的成本与难度。一些支持证书在线更新的方案，又难以保证更新过程的安全性，面临中间人攻击、伪证书注入等威胁。

通过严密的根证书管理方法，能够有效提升现有系统的安全性，在保证根证书可靠的前提下，延长根证书的安全使用周期，利用管理手段上解决上述问题。但是这一方法的成本较高，在车载 OBU 的使用场景下，并非每个必须进行严格身份校验的通信实体（或信息的提供方）都具备严格的根证书管理能力，因此只适用于通信实体能够长期保持不变、较为静态化的场景。但车辆智能化水平正在快速提升，车联网应用场景日益丰富和复杂，因此车载 OBU 需要进行通信的目标也逐渐变得更加多样化和动态化，因此静态的预置根证书机制难以在车载 OBU 的整个使用周期（通常意义上，车载 OBU 的使用周期即为对应车辆的使用周期）既提供足够强的安全防护，又提供足够开放动态变更和扩展能力。

因此，如何在车载 OBU 的全生命周期内，以低成本且安全可靠的方式持续更新其信任根，是车载信息安全领域需要解决的问题。

发明内容

针对上述问题，本发明提出了一种用于更换车载OBU信任根的方法，包括：

获取车载OBU的信息数据；

基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。

可选的，在车载 OBU 中预置有初始信任根和信任根升级算法。

可选的，信任根以文件格式进行存储或以二进制格式进行封装；

文件格式包括如下中的至少一种：json文件格式、yaml文件格式和xml文件格式；

二进制格式包括：protobuf格式。

可选的，信任根的数据结构，包括：根据车载OBU需求自定义的扩展属性数据和信任根的基础数据；

基础数据包括如下：序列号、受信实体列表、签发信息、可信变更渠道列表、变更条件和发布日期；

受信实体列表至少包括一个授信实体，受信实体包括受信实体的身份凭证，身份凭证为用于对受信实体进行非对称加密机制验证的凭证信息，包括：受信实体的公钥及公钥签名算法，或证书信息；

签发信息，包括：签名者所对应的受信实体标识、签名者使用持有的私钥对新版信任根的签名值和签名时间；

可信变更渠道，包括如下中的至少一种：可信url、可信文件路径和可信物理接口；

变更条件包括签名阈值。

可选的，信任根的发布流程，包括：信任根的首次发布流程和更新发布流程；

首次发布流程中，信任根的签发信息包括当前信任根所有受信实体的签名；

更新发布流程中，新版本的信任根的签发信息和受信实体列表需满足上一版本的信任根的变更条件，且默认要求新增实体对新版本的信任根进行签发。

可选的，信任根升级算法，包括如下：

基于可信变更渠道获取新版本的信任根；

对新版本的信任根作为候选信任根，与当前版本信任根进行比较；

若候选信任根的版本号等于当前版本信任根的版本号加1，则对候选信任根进行验证，若候选信任根的签发列表的签名值正确，签发列表的受信实体列表满足当前版本信任根的变更条件，且候选信任根的受信实体列表满足当前版本信任根的变更条件，则将当前版本信任根更换为候选信任根；

若候选信任根的版本号小于或等于当前版本信任根的版本号，则丢弃候选信任根；

若候选信任根的版本号大于当前版本信任根的版本号加1，则获取候选信任根的历史版本中版本号等于当前版本信任根的版本号加1的信任根，进行验证。

可选的，车载OBU 不得采用包含以过期证书为受信实体身份凭证的信任根，作为车载OBU信任根的最终版本。

可选的，对车载OBU的信任根进行存储，包括车载OBU的初始信任根至当前版本信息根，基于存储的信任根生成信任链。

可选的，更换方式，满足信任根的数据结构和信任根的发布流程要求，且使用信任根升级算法进行更换。

再一方面，本发明还提出了一种用于更换车载OBU信任根的系统，包括：

采集单元，用于获取车载OBU的信息数据；

定义单元，用于基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

更换单元，用于基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。

与现有技术相比，本发明的有益效果为：

本发明提供了一种用于更换车载OBU信任根的方法，包括：获取车载OBU的信息数据；基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。采取本发明的方法对车载OBU的信任根进行更换，成本较低，能够满足车载 OBU 信息安全需求。

附图说明

图1为本发明的用于更换车载OBU信任根的方法的流程图；

图2为本发明的用于更换车载OBU信任根的方法及系统中信任根所对应的文件中包含数据的示意图；

图3为本发明的用于更换车载OBU信任根的方法及系统中信任根的签发的说明图；

图4为本发明的用于更换车载OBU信任根的方法及系统中信任根的更新的说明图；

图5为本发明的一种用于更换车载OBU信任根的系统600的模块单元图。

具体实施方式

现在参考附图介绍本发明的示例性实施方式，然而，本发明可以用许多不同的形式来实施，并且不局限于此处描述的实施例，提供这些实施例是为了详尽地且完全地公开本发明，并且向所属技术领域的技术人员充分传达本发明的范围。对于表示在附图中的示例性实施方式中的术语并不是对本发明的限定。在附图中，相同的单元/元件使用相同的附图标记。

除非另有说明，此处使用的术语（包括科技术语）对所属技术领域的技术人员具有通常的理解含义。另外，可以理解的是，以通常使用的词典限定的术语，应当被理解为与其相关领域的语境具有一致的含义，而不应该被理解为理想化的或过于正式的意义。

实施例1：

本发明提出了一种用于更换车载OBU信任根的方法s100，如图1所示，包括：

步骤s101、获取车载OBU的信息数据；

步骤s102、基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

步骤s103、基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。

其中，在车载 OBU 中预置有初始信任根和信任根升级算法。

其中，信任根以文件格式进行存储或以二进制格式进行封装；

文件格式包括如下中的至少一种：json文件格式、yaml文件格式和xml文件格式；

二进制格式包括：protobuf格式。

其中，信任根的数据结构，包括：根据车载OBU需求自定义的扩展属性数据和信任根的基础数据；

基础数据包括如下：序列号、受信实体列表、签发信息、可信变更渠道列表、变更条件和发布日期；

受信实体列表至少包括一个授信实体，受信实体包括受信实体的身份凭证，身份凭证为用于对受信实体进行非对称加密机制验证的凭证信息，包括：受信实体的公钥及公钥签名算法，或证书信息；

签发信息，包括：签名者所对应的受信实体标识、签名者使用持有的私钥对新版信任根的签名值和签名时间；

可信变更渠道，包括如下中的至少一种：可信url、可信文件路径和可信物理接口；

变更条件包括签名阈值。

其中，信任根的发布流程，包括：信任根的首次发布流程和更新发布流程；

首次发布流程中，信任根的签发信息包括当前信任根所有受信实体的签名；

更新发布流程中，新版本的信任根的签发信息和受信实体列表需满足上一版本的信任根的变更条件，且默认要求新增实体对新版本的信任根进行签发。

其中，信任根升级算法，包括如下：

基于可信变更渠道获取新版本的信任根；

对新版本的信任根作为候选信任根，与当前版本信任根进行比较；

若候选信任根的版本号等于当前版本信任根的版本号加1，则对候选信任根进行验证，若候选信任根的签发列表的签名值正确，签发列表的受信实体列表满足当前版本信任根的变更条件，且候选信任根的受信实体列表满足当前版本信任根的变更条件，则将当前版本信任根更换为候选信任根；

若候选信任根的版本号小于或等于当前版本信任根的版本号，则丢弃候选信任根；

若候选信任根的版本号大于当前版本信任根的版本号加1，则获取候选信任根的历史版本中版本号等于当前版本信任根的版本号加1的信任根，进行验证。

其中，车载OBU 不得采用包含以过期证书为受信实体身份凭证的信任根，作为车载OBU信任根的最终版本。

其中，对车载OBU的信任根进行存储，包括车载OBU的初始信任根至当前版本信息根，基于存储的信任根生成信任链。

其中，更换方式，满足信任根的数据结构和信任根的发布流程要求，且使用信任根升级算法进行更换。

实施例2：

与图1示出的本发明的用于更换车载OBU信任根的方法s100类似，

本发明提出了一种用于更换车载OBU信任根的方法s200，包括：

步骤s201、获取车载OBU的信息数据；

步骤s202、基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

步骤s203、基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。

其上述步骤s201-s203的实施过程，主要在于通过定义实现信任根安全替换能力：定义车载 OBU 中信任根的数据结构、定义信任根的发布流程、定义车载OBU 信任根升级算法的核心逻辑、定义在车载 OBU 中预置“初始信任根”和“信任根升级算法”的主要流程、定义车载 OBU 和周边系统交互的接口、定义车载 OBU 上系统和应用对信任根的使用方式。

其中，在车载 OBU 中预置有初始信任根和信任根升级算法。

其中，信任根以文件格式进行存储或以二进制格式进行封装；

文件格式包括如下中的至少一种：json文件格式、yaml文件格式和xml文件格式；

二进制格式包括：protobuf格式。

其中，信任根的数据结构，包括：根据车载OBU需求自定义的扩展属性数据和信任根的基础数据；

基础数据包括如下：序列号、受信实体列表、签发信息、可信变更渠道列表、变更条件和发布日期；

受信实体列表至少包括一个授信实体，受信实体包括受信实体的身份凭证，身份凭证为用于对受信实体进行非对称加密机制验证的凭证信息，包括：受信实体的公钥及公钥签名算法，或证书信息；

签发信息，包括：签名者所对应的受信实体标识、签名者使用持有的私钥对新版信任根的签名值和签名时间；

可信变更渠道，包括如下中的至少一种：可信url、可信文件路径和可信物理接口；

变更条件包括签名阈值。

其中，信任根的发布流程，包括：信任根的首次发布流程和更新发布流程；

首次发布流程中，信任根的签发信息包括当前信任根所有受信实体的签名；

更新发布流程中，新版本的信任根的签发信息和受信实体列表需满足上一版本的信任根的变更条件，且默认要求新增实体对新版本的信任根进行签发。

其中，信任根升级算法，包括如下：

基于可信变更渠道获取新版本的信任根；

对新版本的信任根作为候选信任根，与当前版本信任根进行比较；

若候选信任根的版本号等于当前版本信任根的版本号加1，则对候选信任根进行验证，若候选信任根的签发列表的签名值正确，签发列表的受信实体列表满足当前版本信任根的变更条件，且候选信任根的受信实体列表满足当前版本信任根的变更条件，则将当前版本信任根更换为候选信任根；

若候选信任根的版本号小于或等于当前版本信任根的版本号，则丢弃候选信任根；

若候选信任根的版本号大于当前版本信任根的版本号加1，则获取候选信任根的历史版本中版本号等于当前版本信任根的版本号加1的信任根，进行验证。

其中，车载OBU 不得采用包含以过期证书为受信实体身份凭证的信任根，作为车载OBU信任根的最终版本。

其中，对车载OBU的信任根进行存储，包括车载OBU的初始信任根至当前版本信息根，基于存储的信任根生成信任链。

其中，更换方式，满足信任根的数据结构和信任根的发布流程要求，且使用信任根升级算法进行更换。

其中，在车载 OBU 中预置有初始信任根和信任根升级算法。

其中，信任根的发布流程，包括：信任根的首次发布流程和更新发布流程；

首次发布流程中，信任根的签发信息包括当前信任根所有受信实体的签名；

更新发布流程中，新版本的信任根的签发信息和受信实体列表需满足上一版本的信任根的变更条件，且默认要求新增实体对新版本的信任根进行签发。

其中，信任根升级算法，包括如下：

基于可信变更渠道获取新版本的信任根；

对新版本的信任根作为候选信任根，与当前版本信任根进行比较；

若候选信任根的版本号等于当前版本信任根的版本号加1，则对候选信任根进行验证，若候选信任根的签发列表的签名值正确，签发列表的受信实体列表满足当前版本信任根的变更条件，且候选信任根的受信实体列表满足当前版本信任根的变更条件，则将当前版本信任根更换为候选信任根；

若候选信任根的版本号小于或等于当前版本信任根的版本号，则丢弃候选信任根；

若候选信任根的版本号大于当前版本信任根的版本号加1，则获取候选信任根的历史版本中版本号等于当前版本信任根的版本号加1的信任根，进行验证。

其中，车载OBU 不得采用包含以过期证书为受信实体身份凭证的信任根，作为车载OBU信任根的最终版本。

其中，对车载OBU的信任根进行存储，包括车载OBU的初始信任根至当前版本信息根，基于存储的信任根生成信任链。

其中，更换方式，满足信任根的数据结构和信任根的发布流程要求，且使用信任根升级算法进行更换。

其中，车载 OBU 上信任根的数据结构，具体如下：

车载 OBU 的信任根可以用 json/yaml/xml 等文本文件格式存储，也可以用protobuf 等二进制格式封装。在信任根对应的文件中，除了根据 OBU 需求自定义的扩展属性外，至少应当包含如下数据，其示意图如图2所示：

1.序列号：信任根的版本序列号，为从 1 开始的递增证书；也可以叫做版本号；

2.受信实体列表：至少一个受信实体组成的受信实体列表；

3.签发信息：发布该信任根所采用的数字签名列表；

4.可信变更渠道列表：可用于查询新版信任根的外部地址列表，或允许的信任根变更方法（比如离线变更）；

5.变更条件1：当信任根发生变更时，新版本信任根的签发信息必须满足的签发；

6.发布日期：该信任根签发的日期和时间，该日期和时间不带时区信息时应当按照标准时间处理；

7.变更条件2：当信任根发生变更时，在新版本信任根中，新的受信实体列表必须满足的条件；

8.过期时间，即在该时间之后，当前版本的信任根不再生效，仅可用于验证新版信任根是否有效；

9.描述信息：描述类的辅助信息；

其中受信实体主要包括如下：

1.受信实体的身份凭证，即能够通过非对称加密机制验证受信实体身份的凭证信息。由受信实体的公钥、公钥签名算法，或完整的证书信息构成（含自签名证书）；

2.受信实体的身份标识，即该实体的显示名称，建议（但不强制）采用该受信实体的全局唯一标识；

3.受信实体的角色，即受信实体能够用来在对应信任根所保护的范围内可执行的操作（以及可访问的数据）；

4.受信实体被授权的有效期；

其中1为必须项，2-4非必须项；

其中，签发信息是一个完整的签名列表，列表中的每个签名包含如下：

1.签名者所对应的受信实体标识，标识的选择建议按如下顺序：全局唯一的身份标识、证书标识、公钥 ID（计算方式：hash256(public_key)）；

2.签名者用所持有的私钥对新版信任根做的签名值（签名内容包括：新版信任根中，除签发信息之外的所有信息，以及当前签名者的受信实体标识和签名时间）；

3.签名时间；

其中可信变更渠道主要包含如下：

1.从哪些 url、文件路径、物理接口等途径，OBU 可以获取新的信任根；注意，从可信渠道获取新版信任根，并不意味着可以跳过信任根的安全性检查；

其中变更条件1包括如下内容：

1.签名阈值，即至少需要多少个信任根的签名，才能够变更信任根；

2.在新版信任根的签发信息中，必须包含哪些受信实体的签名；

3.在新版信任根的签发信息中，有哪些受信实体可以（或必须）用多签、或签等方式联合签名；

其中，1为必须项，2和3为非必须项；

其中，变更条件2为非必须的，包括如下内容：

1.在变更信任根时，是否允许增加或者删除受信实体；

2.在变更信任根时，有哪些当前信任根中存在的受信实体禁止变更。

实施例3：

与图1所示的本发明的一种用于更换车载OBU信任根的方法s100类似，

本发明提出了一种用于更换车载OBU信任根的方法s300，包括：

步骤s301、获取车载OBU的信息数据；

步骤s302、基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

步骤s303、基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。

其上述步骤s301-s303的实施过程，主要在于通过定义实现信任根安全替换能力：定义车载 OBU 中信任根的数据结构、定义信任根的发布流程、定义车载OBU 信任根升级算法的核心逻辑、定义在车载 OBU 中预置“初始信任根”和“信任根升级算法”的主要流程、定义车载 OBU 和周边系统交互的接口、定义车载 OBU 上系统和应用对信任根的使用方式。

其中，在车载 OBU 中预置有初始信任根和信任根升级算法。

其中，信任根以文件格式进行存储或以二进制格式进行封装；

文件格式包括如下中的至少一种：json文件格式、yaml文件格式和xml文件格式；

二进制格式包括：protobuf格式。

其中，信任根的数据结构，包括：根据车载OBU需求自定义的扩展属性数据和信任根的基础数据；

基础数据包括如下：序列号、受信实体列表、签发信息、可信变更渠道列表、变更条件和发布日期；

受信实体列表至少包括一个授信实体，受信实体包括受信实体的身份凭证，身份凭证为用于对受信实体进行非对称加密机制验证的凭证信息，包括：受信实体的公钥及公钥签名算法，或证书信息；

签发信息，包括：签名者所对应的受信实体标识、签名者使用持有的私钥对新版信任根的签名值和签名时间；

可信变更渠道，包括如下中的至少一种：可信url、可信文件路径和可信物理接口；

变更条件包括签名阈值。

其中，信任根的发布流程，包括：信任根的首次发布流程和更新发布流程；

其信任根的发布流程，如图3所示，包括：

1. 首次发布，即发布 sequence = 1 的信任根；

2. 更新发布，即发布 sequence > 1 的信任根；

两次发布的主要区别在于：

1.在首次发布中，签发信息必须包含当前信任根所有受信实体的签名，即取得所有受信实体的授权才可以签发；

2.在后续的发布中，签发信息中包含的签名必须满足上一个版本的变更条件要求，新的信任实体列表也必须满足上一个版本的变更条件要求；

3.在变更条件中，默认要求所有新增实体对新版本的信任根进行签发；

由于信任实体的身份凭证可以是证书，在签发信任根时，所签发的信任根的过期时间必须小于等于所有信任实体所对应的证书的最早过期时间。

由于信任实体的身份凭证可以是证书，在签发信任根时，如果变更条件允许，即可以使用新版证书所对应的私钥进行签发。

与此对应的签发条件可能（但不限于）有如下几种：

1.必须使用原证书对应的私钥签发，且签发日期不得晚于证书的过期时间（最安全）；

2.信任原证书的根证书，可以由该根证书签发的、且 subject 等同于原有证书的新证书；

其中，信任根升级算法，包括如下：

基于可信变更渠道获取新版本的信任根；

对新版本的信任根作为候选信任根，与当前版本信任根进行比较；

若候选信任根的版本号等于当前版本信任根的版本号加1，则对候选信任根进行验证，若候选信任根的签发列表的签名值正确，签发列表的受信实体列表满足当前版本信任根的变更条件，且候选信任根的受信实体列表满足当前版本信任根的变更条件，则将当前版本信任根更换为候选信任根；

若候选信任根的版本号小于或等于当前版本信任根的版本号，则丢弃候选信任根；

若候选信任根的版本号大于当前版本信任根的版本号加1，则获取候选信任根的历史版本中版本号等于当前版本信任根的版本号加1的信任根，进行验证。

其中，车载OBU 不得采用包含以过期证书为受信实体身份凭证的信任根，作为车载OBU信任根的最终版本。

其中，对车载OBU的信任根进行存储，包括车载OBU的初始信任根至当前版本信息根，基于存储的信任根生成信任链。

其中，更换方式，满足信任根的数据结构和信任根的发布流程要求，且使用信任根升级算法进行更换。

实施例4：

与图1所示的本发明的一种用于更换车载OBU信任根的方法s100类似，

本发明提出了一种用于更换车载OBU信任根的方法s400，包括：

步骤s401、获取车载OBU的信息数据；

步骤s402、基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

步骤s403、基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。

其上述步骤s401-s403的实施过程，主要在于通过定义实现信任根安全替换能力：定义车载 OBU 中信任根的数据结构、定义信任根的发布流程、定义车载OBU 信任根升级算法的核心逻辑、定义在车载 OBU 中预置“初始信任根”和“信任根升级算法”的主要流程、定义车载 OBU 和周边系统交互的接口、定义车载 OBU 上系统和应用对信任根的使用方式。

其中，在车载 OBU 中预置有初始信任根和信任根升级算法。

其中，信任根以文件格式进行存储或以二进制格式进行封装；

文件格式包括如下中的至少一种：json文件格式、yaml文件格式和xml文件格式；

二进制格式包括：protobuf格式。

其中，信任根的数据结构，包括：根据车载OBU需求自定义的扩展属性数据和信任根的基础数据；

基础数据包括如下：序列号、受信实体列表、签发信息、可信变更渠道列表、变更条件和发布日期；

受信实体列表至少包括一个授信实体，受信实体包括受信实体的身份凭证，身份凭证为用于对受信实体进行非对称加密机制验证的凭证信息，包括：受信实体的公钥及公钥签名算法，或证书信息；

签发信息，包括：签名者所对应的受信实体标识、签名者使用持有的私钥对新版信任根的签名值和签名时间；

可信变更渠道，包括如下中的至少一种：可信url、可信文件路径和可信物理接口；

变更条件包括签名阈值。

其中，信任根的发布流程，包括：信任根的首次发布流程和更新发布流程；

首次发布流程中，信任根的签发信息包括当前信任根所有受信实体的签名；

更新发布流程中，新版本的信任根的签发信息和受信实体列表需满足上一版本的信任根的变更条件，且默认要求新增实体对新版本的信任根进行签发。

其中，信任根升级算法，的主要工作机制如下：

1.从可信变更渠道获取新的候选信任根；

2.比较候选信任根与当前信任根的版本：

如果候选信任根的版本 < 当前信任根的版本，则丢弃候选信任根；

如果候选信任根的版本 = 当前信任根的版本，则丢弃候选信任根；

如果候选信任根的版本 = 当前信任根的版本 + 1，则进入步骤 3，验证新的信任根；

如果候选信任根的版本 > 当前信任根的版本 + 1，则获取比当前信任根版本大1 的下一个信任根，校验成功后反复执行，直到升级直最新的信任根；

3.验证信任根：

验证候选信任根中，签发列表的签名值是否正确；

验证候选信任根中，签发列表的实体列表是否满足当前信任根的变更条件；

验证候选信任根中，新的实体列表是否满足当前信任根的变更条件；

4.以上验证过程如果全部成功，则变更本地信任根；否则丢弃候选信任根；

当候选信任根验证失败后，OBU 应当尝试从公开的可信变更渠道查询当前的最新信任根版本。

在从较低版本升级多个版本到较高版本的过程中，有可能遇到某个版本信任根上的受信实体的证书凭证已经过期，在此情况下，证书的时间效应不影响信任链的构建。

但 OBU 不得采用包含以过期证书为受信实体身份凭证的信任根作为最终版本。

其中，车载OBU 不得采用包含以过期证书为受信实体身份凭证的信任根，作为车载OBU信任根的最终版本。

其中，对车载OBU的信任根进行存储，包括车载OBU的初始信任根至当前版本信息根，基于存储的信任根生成信任链。

其中，更换方式，满足信任根的数据结构和信任根的发布流程要求，且使用信任根升级算法进行更换。

实施例5：

与图1所示的本发明的一种用于更换车载OBU信任根的方法s100类似，

本发明提出了一种用于更换车载OBU信任根的方法s500，包括：

步骤s501、获取车载OBU的信息数据；

步骤s502、基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

步骤s503、基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。

其上述步骤s501-s503的实施过程，主要在于通过定义实现信任根安全替换能力：定义车载 OBU 中信任根的数据结构、定义信任根的发布流程、定义车载OBU 信任根升级算法的核心逻辑、定义在车载 OBU 中预置“初始信任根”和“信任根升级算法”的主要流程、定义车载 OBU 和周边系统交互的接口、定义车载 OBU 上系统和应用对信任根的使用方式。

其中，在车载 OBU 中预置“初始信任根”和“信任根升级算法”；

在车载 OBU 中，应当预置上述信任根升级算法，并保证信任根升级算法的安全性；

在车载 OBU 中，应当预置初始信任根，该初始信任根的版本应当是最新版本的信任根；

OBU 同时应该保存从序号为 1 的信任根开始，到当前信任根为止的所有信任根，从而构建完整的信任链。

系统和应用使用信任根的方法即更新流程，原理如图4所示，具体包括：

1.车载 OBU 连接到云端服务或通过其他方式获取新的信任根;

2.车载 OBU 利用预置的信任根更换算法对新的信任根进行检查，如果不满足要求，则拒绝更新；

3.当新证书通过检查，车载 OBU 将新证书保存为新的信任根;

4.车载 OBU 根据新的信任根重新建立系统信任链，实现对通信对象及信息的重新认证;

5.车载 OBU 持续使用新信任根，直至再次需要进行信任根更新;

6.车载 OBU厂商或汽车厂商定期发布新的信任根和对应的更新算法，以指导车载OBU 进行更新。

上述流程中，步骤 2 的算法检查是确保新信任根安全和可靠的关键，各算法应严谨设计以免被绕过。采用该流程，可在车载 OBU 完整生命周期内持续高效地进行信任根更新。

实施例6：

本发明还提出了一种用于更换车载OBU信任根的系统600，如图5所示，包括：

采集单元601，用于获取车载OBU的信息数据；

定义单元602，用于基于车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

更换单元603，用于基于定义数据，生成用于更换车载OBU信任根的更换策略，以更换策略，对车载OBU的信任根进行更换。

本发明提供一种低成本而安全的车载 OBU 信任根更换方案，能够满足车载 OBU信息安全需求。

本发明提供的更换方案，能够在车载 OBU 完整生命周期内安全更换其信任根。

在车联网应用场景下，本发明主要有以下有益效果:

1.降低了现有信任根中部分私钥泄露或算法失效的风险，增强系统安全性；

2.无需通过物理方式或专用安全通道进行信任根更新，省去高昂的管理和维护成本；

3.采用预置的信任根更换算法，确保更换得到的新信任根满足安全要求；

4.新信任根更新后，车载 OBU 重新对通信对象和信息进行认证和校验，确保安全。

5.支持通过多种方式（云端、离线等）进行信任根更新，方便实施；

6.通过动态更换（升级）信任根，车企或者车联网运营等生态相关企业可以根据业务需求动态调整信任根，在汽车的生命周期内提升服务能力而不损害 OBU 及相关系统的安全性；

本发明设计于车载 OBU 相关的车载信息系统、车云通信系统，以及通过诊断工具、调试工具、维修工具等方式，通过有线、物理接口或者近场通信等方式直接或间接和车载 OBU 进行通信。在通信过程中，车载 OBU 需要做如下两项安全检查中的至少一项：1）对通信的另一方进行身份识别，2）对通信过程中收到的消息、数据等信息进行安全检查。

在车载 OBU 中，系统和应用通常将信任根建立在共同或独立的根证书上，且通常无法为该根证书提供有效的升级替换机制。而对于 OBU 的系统以及系统之上的不同应用，如果要在他们基于 PKI 体系的多个根证书之间建立某种关联，从而形成系统级或应用级的、用于复杂业务场景的信任根，在 PKI 体系之中尚无标准解决方案。

本发明主要解决上述信任根（根证书）分散管理、信任根难以动态更换等问题。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。本发明实施例中的方案可以采用各种计算机语言实现，例如，面向对象的程序设计语言Java和直译式脚本语言JavaScript等。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (9)

1.一种用于更换车载OBU信任根的方法，其特征在于，所述方法包括：

获取车载OBU的信息数据；

基于所述车载OBU的信息数据，定义车载OBU中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

基于所述定义数据，生成用于更换车载OBU信任根的更换策略，以所述更换策略，对所述车载OBU的信任根进行更换；

所述信任根升级算法，包括如下：

基于可信变更渠道获取新版本的信任根；

对新版本的信任根作为候选信任根，与当前版本信任根进行比较；

若候选信任根的版本号等于当前版本信任根的版本号加1，则对候选信任根进行验证，若候选信任根的签发列表的签名值正确，签发列表的受信实体列表满足当前版本信任根的变更条件，且候选信任根的受信实体列表满足当前版本信任根的变更条件，则将当前版本信任根更换为候选信任根；

若候选信任根的版本号小于或等于当前版本信任根的版本号，则丢弃候选信任根；

若候选信任根的版本号大于当前版本信任根的版本号加1，则获取候选信任根的历史版本中版本号等于当前版本信任根的版本号加1的信任根，进行验证。

2.根据权利要求1所述的方法，其特征在于，在车载 OBU 中预置有初始信任根和信任根升级算法。

3.根据权利要求1所述的方法，其特征在于，所述信任根以文件格式进行存储或以二进制格式进行封装；

所述文件格式包括如下中的至少一种：json文件格式、yaml文件格式和xml文件格式；

所述二进制格式包括：protobuf格式。

4.根据权利要求1所述的方法，其特征在于，所述信任根的数据结构，包括：根据车载OBU需求自定义的扩展属性数据和信任根的基础数据；

所述基础数据包括如下：序列号、受信实体列表、签发信息、可信变更渠道列表、变更条件和发布日期；

所述受信实体列表至少包括一个受信实体，所述受信实体包括受信实体的身份凭证，所述身份凭证为用于对受信实体进行非对称加密机制验证的凭证信息，包括：受信实体的公钥及所述公钥签名算法，或证书信息；

所述签发信息，包括：签名者所对应的受信实体标识、签名者使用持有的私钥对新版信任根的签名值和签名时间；

所述可信变更渠道，包括如下中的至少一种：可信url、可信文件路径和可信物理接口；

所述变更条件包括签名阈值。

5.根据权利要求1所述的方法，其特征在于，所述信任根的发布流程，包括：信任根的首次发布流程和更新发布流程；

所述首次发布流程中，信任根的签发信息包括当前信任根所有受信实体的签名；

所述更新发布流程中，新版本的信任根的签发信息和受信实体列表需满足上一版本的信任根的变更条件，且默认要求新增实体对所述新版本的信任根进行签发。

6.根据权利要求1所述的方法，其特征在于，所述车载OBU 不得采用包含以过期证书为受信实体身份凭证的信任根，作为车载OBU信任根的最终版本。

7.根据权利要求1所述的方法，其特征在于，对车载OBU的信任根进行存储，包括车载OBU的初始信任根至当前版本信任根，基于存储的信任根生成信任链。

8.根据权利要求1所述的方法，其特征在于，所述更换方式，满足信任根的数据结构和信任根的发布流程要求，且使用信任根升级算法进行更换。

9.一种用于更换车载OBU信任根的系统，其特征在于，所述系统包括：

采集单元，用于获取车载OBU的信息数据；

定义单元，用于基于所述车载OBU的信息数据，定义车载 OBU 中，信任根的数据结构、信任根的发布流程、信任根升级算法和更换方式，以生成对信任根的定义数据；

更换单元，用于基于所述定义数据，生成用于更换车载OBU信任根的更换策略，以所述更换策略，对所述车载OBU的信任根进行更换；

所述信任根升级算法，包括如下：

基于可信变更渠道获取新版本的信任根；

对新版本的信任根作为候选信任根，与当前版本信任根进行比较；

若候选信任根的版本号等于当前版本信任根的版本号加1，则对候选信任根进行验证，若候选信任根的签发列表的签名值正确，签发列表的受信实体列表满足当前版本信任根的变更条件，且候选信任根的受信实体列表满足当前版本信任根的变更条件，则将当前版本信任根更换为候选信任根；

若候选信任根的版本号小于或等于当前版本信任根的版本号，则丢弃候选信任根；

若候选信任根的版本号大于当前版本信任根的版本号加1，则获取候选信任根的历史版本中版本号等于当前版本信任根的版本号加1的信任根，进行验证。