CN117195216A - 车辆校验方法、相关装置及系统 - Google Patents

Abstract

本申请公开了车辆校验方法、相关装置及系统，该方法主要涉及车辆和服务器，车辆可以接收服务器发送的车辆身份标识，和/或，防重放参数，以及完整性信息，升级包。在车辆升级时，车辆可以在确定服务器发送的车辆身份标识与本地的车辆身份标识一致，和/或，服务器发送的防重放参数与本地的防重放参数，以及服务器发送的完整性信息与根据服务器发送的升级包计算得到的完整性信息一致的情况下，根据该升级包进行升级。其中，该车辆身份标识用于标识该车辆，防重放参数用于标识本次升级。这样，可以避免车辆使用不适用于该车辆的升级包，例如老版本的升级包、其他车辆的升级包、研发阶段使用的升级包进行升级。

Description

车辆校验方法、相关装置及系统

技术领域

本申请涉及车联网、通信技术领域，尤其涉及车辆校验方法、相关装置及系统。

背景技术

随着汽车领域车联网技术的不断发展，车辆上搭载的软硬件越来越多，使得车辆的软件功能越来越复杂。而在车辆的运行过程中及技术的不断发展下，某些软件功能也会逐渐显露出其存在的缺陷或其落后性，因此需要对车辆进行不断的升级更新，优化软件功能或开发新的软件功能，提升车辆的性能，实现车辆的智能化。

发明内容

本申请提供了车辆校验方法、相关装置及系统，实现了车辆的安全升级或安全启动，保障了车辆的安全。

第一方面，本申请提供了一种车辆校验方法，其特征在于，方法包括：车辆接收到第一文件和第一升级包，第一文件包括：第一车辆标识，第一完整性信息，和，根据第一车辆标识以及第一完整性信息确定的第一签名；车辆使用第一服务器的公钥校验第一签名，且校验通过；第一服务器用于管理车辆的升级；车辆确定第一车辆标识与车辆的车辆标识相同，且，第一升级包为第一完整性信息指示的升级包；车辆根据第一升级包进行升级，以增强第一功能或增加第一功能。

实施本申请实施例提供的方法，车辆可以在需要升级时，获取到授权文件和升级包，在使用升级包进行升级之前，车辆会对授权文件进行校验，包括：车辆身份标识的校验、完整性信息的校验、签名的校验。其中，校验签名是为了判断授权文件是否由管理车辆升级的车云服务器发送，以及授权文件是否被第三方篡改，校验完整性信息是为了判断接收到的升级包，是否为车云服务器同该授权文件一起发送的升级包，避免第三方将车云服务器一起发送的升级包和授权文件中的升级包替换成其他升级包，校验车辆身份标识是为了判断接收到的升级包是否为车云服务器专门发送给该车辆的升级包，避免混用车云服务器给其他车辆发送的用于升级的升级包，或者使用未携带车辆身份标识的升级包。在授权文件的校验通过后，车辆即可使用该升级包进行升级。

这样，一方面，可以避免车辆使用车云服务器发送给其他车辆的升级包进行升级，例如车主从非官方渠道获取到的官方发送给其他车辆的升级包，以更低或免费的价格完成车辆的升级，避免损害车厂和软件供应商的利益；另一方面，车辆可以校验升级包是否由可信的服务器发送给，只使用可信服务器发送过的升级包进行升级，由于服务器并不会将不用于授权的升级包，例如研发阶段使用的升级包、携带病毒的升级包、存在漏洞的升级包等等发送给车辆，因此车辆只会根据安全的升级包进行升级，保障了车辆使用升级包进行升级的安全性。

结合第一方面，在一种实施方式中，车辆根据第一升级包进行升级之后，方法还包括：车辆再次使用第一服务器的公钥校验第一签名，并且校验通过，车辆再次确定第一车辆标识与车辆的车辆标识相同，且，升级后的车辆的数据包括第一完整性信息指示的升级包中的数据；车辆启动第一功能。

进一步地，车辆除了在升级阶段进行授权文件的校验外，还可以在安全启动阶段再次校验授权文件，只有授权文件的校验通过后，车辆才会进行启动，这样，可以避免任何未经授权的软件程序在车辆中运行，保证车辆运行的软件程序来源于升级阶段，授权文件校验通过后，安装的升级包，避免车辆运行车云服务器发送给其他车辆的升级包中的软件程序，或者，研发阶段使用的升级包中的软件程序等等，保证了车辆的安全运行。

第二方面，本申请提供了另一种车辆校验方法，方法包括：车辆接收到第一文件和第一升级包，第一文件包括：第一防重放参数，第一完整性信息，和，根据第一防重放参数和第一完整性信息确定的第一签名；车辆使用第一服务器的公钥校验第一签名，且校验通过；第一服务器用于管理车辆的升级；车辆确定第一防重放参数与车辆的防重放参数相同，且，第一升级包为第一完整性信息指示的升级包；车辆的防重放参数用于标识车辆本次的升级；车辆根据第一升级包进行升级，以增强第一功能或增加第一功能。

实施本申请实施例提供的方法，车辆可以在需要升级时，获取到授权文件和升级包，在使用升级包进行升级之前，车辆会对授权文件进行校验，包括：防重放参数的校验、完整性信息的校验、签名的校验。其中，校验签名是为了判断授权文件是否由管理车辆升级的车云服务器发送，以及授权文件是否被第三方篡改，校验完整性信息是为了判断接收到的升级包，是否为车云服务器同该授权文件一起发生的升级包，避免第三方将车云服务器一起发送的升级包和授权文件中的升级包替换成其他升级包，校验防重放参数是否了保证车辆能够根据与车云服务器约定的升级包版本的升级包进行升级。例如，车辆与服务器可以在每次升级时约定不同的防重放参数，如果攻击者利用老版本的升级包的漏洞来攻击车辆，截取服务器给车辆发送的升级包，并替换成老版本的升级包，但是由于老版本的升级包的防重放参数与车辆本次升级的防重放参数不一致，车辆不会根据该老版本的升级包进行升级，从而预防了攻击者重放老版本的升级包，利用老版本的漏洞攻击车辆，保障了车辆的安全以及车主的利益。

结合第二方面，在一种实施方式中，第一文件还包括第一车辆标识，第一签名为根据第一车辆标识和第一防重放参数确定的签名；车辆根据第一升级包进行升级之前，方法还包括：车辆确定第一车辆标识和车辆的车辆标识相同。

进一步地，授权文件的校验，还可以包括：车辆身份标识的校验。校验车辆身份标识是为了保证车辆接收到的升级包为车云服务器发送给的适用于本车辆的升级包。避免车辆使用车云服务器发送给其他车辆的升级包进行升级，或者研发阶段使用的升级包进行升级，从车辆的升级阶段保障车辆的安全。

结合第二方面，在一种实施方式中，车辆根据第一升级包进行升级之后，方法还包括：车辆再次使用第一服务器的公钥校验第一签名，且校验通过；车辆再次确定第一防重放参数与车辆的防重放参数相同，且，升级后的车辆的数据包括第一完整性信息指示的升级包中的数据；车辆启动第一功能。

进一步地，车辆除了在升级阶段进行授权文件的校验外，还可以在安全启动阶段再次校验授权文件，包括：签名的校验、防重放参数的校验、完整性信息的校验。这样，可以保证车辆运行的软件程序为官方服务器，即车云服务器发送的升级包中的软件程序，进一步地，不是来源于老版本的升级包中的软件程序，避免攻击者在车辆的运行阶段使用老版本升级包的漏洞攻击车辆。

结合第二方面，在一种实施方式中，车辆根据第一升级包进行升级之后，方法还包括：车辆再次使用第一服务器的公钥校验第一签名，且校验通过；车辆再次确定第一防重放参数与车辆的防重放参数相同，且，第一车辆标识与车辆的车辆标识相同，且，升级后的车辆的数据包括第一完整性信息指示的升级包中的数据；车辆启动第一功能。

进一步地，车辆除了在升级阶段进行授权文件的校验外，还可以在安全启动阶段再次校验授权文件，包括：签名的校验、防重放参数的校验、车辆身份标识的校验、完整性信息的校验。这样，可以保证车辆运行的软件程序为官方服务器，即车云服务器发送的升级包中的软件程序，进一步地，不是来源于老版本的升级包、研发阶段使用的升级包、车云服务器给其他车辆发送的升级包中的软件程序，保障车辆运行阶段的安全。

第三方面，本申请提供了另一种车辆校验方法，方法包括：车辆接收到第一文件和第一升级包，第一文件包括：第一车辆标识，第一完整性信息，和，根据第一车辆标识以及第一完整性信息确定的第一签名；车辆检测到启动第一功能的指令，第一功能为车辆根据第一升级包进行升级后增强或增加的功能；车辆使用第一服务器的公钥校验第一签名，且校验通过；第一服务器用于管理车辆的升级；车辆再次确定第一车辆标识与车辆的车辆标识相同，且，升级后的车辆的数据包括第一完整性信息指示的升级包中的数据；车辆启动第一功能。

实施本申请实施例提供的方法，车辆可以在升级阶段接收到升级包和授权文件，并根据该升级包进行升级，在车辆启动时，再使用授权文件校验车辆升级后的软件程序，是否来源于服务器专门发送给该车辆的升级包中的软件程序，只有在校验通过后，车辆才会进行启动。这样，可以避免任何未经授权的软件程序在车辆中运行，保证车辆运行的软件程序来源于升级阶段接收到的升级包中的软件程序，并在启动阶段，确定该升级包为车云服务器发送的适用于本车辆的升级包，避免车辆运行车云服务器发送给其他车辆的升级包中的软件程序，或者，研发阶段使用的升级包中的软件程序等等，保证了车辆的安全运行。

第四方面，本申请提供了另一种车辆校验方法，方法包括：车辆接收到第一文件和第一升级包，第一文件包括：第一防重放参数，第一完整性信息，和，根据第一防重放参数以及第一完整性信息确定的第一签名；车辆检测到启动第一功能的指令，第一功能为车辆根据第一升级包进行升级后增强或增加的功能；车辆使用第一服务器的公钥校验第一签名，且校验通过；第一服务器用于管理车辆的升级；车辆再次确定第一防重放参数与车辆的车辆标识相同，且，升级后的车辆的数据包括第一完整性信息指示的升级包中的数据；车辆启动第一功能。

实施本申请实施例提供的方法，车辆可以在升级阶段接收到升级包和授权文件，并根据该升级包进行升级，在车辆启动时，再使用授权文件校验车辆升级后的软件程序，是否来源于服务器专门发送给该车辆本次升级的升级包中的软件程序，只有在校验通过后，车辆才会进行启动。这样，可以避免任何未经授权的软件程序在车辆中运行，保证车辆运行的软件程序来源于升级阶段接收到的升级包中的软件程序，并在启动阶段，确定该升级包为车云服务器发送的适用于车辆本次升级的升级包，避免车辆运行老版本的升级包中的软件程序等等，保证了车辆的安全运行。

结合第四方面，在一种实施方式中，第一文件还包括第一车辆标识，第一签名为根据第一车辆标识和第一防重放参数确定的签名；车辆启动第一功能之前，方法还包括：车辆确定第一车辆标识和车辆的车辆标识相同。进一步地，授权文件的校验还包括对车辆身份标识的校验，可以进一步避免车辆运行车云服务器发送给其他车辆的升级包中的软件程序，或者，研发阶段使用的升级包中的软件程序等等，保证车辆的安全运行。

结合第二方面、第四方面，在一种实施方式中，车辆的防重放参数随着车辆的每一次升级而更新且仅用于标识车辆的一次升级，或者，车辆的防重放参数用于标识车辆的多次升级。

在一种情况下，防重放参数可以为每次升级随机生成的随机数，该随机数可用于唯一标识一次升级，也就是说，每次升级时，车云服务器和车辆都可以约定一个随机生成的“暗号”，保证车辆在任何一次升级都不会使用老版本的升级包进行升级。

在另一种情况下，防重放参数可以为单调递增的计数值，该计数值可以在每次升级时发生更改，也可以在预设条件发发送更改，例如发现老版本升级包中存在漏洞。其中，每次更改计数值，可以保证车辆在任何一次升级都不会使用老版本的升级包进行升级，在发现老版本升级包存在漏洞时更改计数值，可以避免在发现老版本存在漏洞后，车辆使用老版本升级包进行升级。

结合第二方面、第四方面，在一种实施方式中，车辆的防重放参数存储于重放保护存储分区RPMB或一次性可编程存储区域OTP中。

车辆将本地的防重放参数存放在RPMB和OTP中，可以避免第三方恶意篡改本地存放的防重放参数，保证车辆在对接收到的防重放参数和本地的防重放参数进行比较时，本地的防重放参数的可信度。

结合第一方面、第三方面，在一种实施方式中，车辆的车辆标识存储于一次性可编程存储区域OTP中。

车辆将本地的防重放参数存放在OTP中，可以避免第三方恶意篡改本地存放的车辆身份标识，保证车辆在对接收到的车辆身份标识和本地的车辆身份标识进行比较时，本地的车辆身份标识的可信度。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，在第一升级包为第一完整性信息标识的升级包的情况下，第一完整性信息包括一个或多个参数，一个或多个参数用于标识第一升级包。

也就是说，完整性信息可以为一个参数，该参数用于标识整个升级包中的数据，这样，当车辆校验完整性信息时，可以快速确定升级包中的数据是否被篡改，或者，完整性信息可以为多个参数，这多个参数可以分别标识升级包中的多个升级文件，这样，当车辆校验完整性信息时，可以精准的确定升级包中的哪些数据遭到了篡改。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，第一文件还包括：第一公钥；车辆预存有第一服务器的公钥的第一标识，车辆使用第一服务器的公钥校验第一签名之前，方法还包括：车辆确定第一公钥的标识；在第一公钥的标识和第一标识相同的情况下，车辆确定第一公钥为第一服务器的公钥。

也就是说，授权文件中还可以包括校验该授权文件中的签名的授权公钥，在校验该签名之前，车辆可以先校验该授权公钥是否被第三方篡改，保证签名校验的可信度。其中，车辆可以在本地预置授权公钥的标识，例如哈希值，如果接受到的授权公钥的哈希值与本地预置的哈希值相同，则说明该授权公钥来源于车云服务器，且没有被第三方篡改。也就是说，车辆可以通过本地预置授权公钥的标识来实现对接收到的公钥的校验。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，第一文件中还包括：第一公钥，和，根据第一公钥确定的第二签名，车辆使用第一服务器的公钥校验第一签名之前，方法还包括：车辆使用第二服务器的公钥校验第二签名；其中，第二服务器为开发并提供车辆升级所需的升级包的服务器；在第二签名的校验通过的情况下，车辆确定第一公钥为第一服务器的公钥。

也就是说，当授权文件中包括校验该授权文件中的签名的授权公钥时，可以通过除车云服务器和车辆之外的其他可信第三方来提供该授权公钥的合法性证明，该可信的第三方可以是指软件供应商。也就是说，车辆可以通过该软件供应商的供应商服务器提供的合法性证明来判断授权公钥是否来源于车云服务器，且未被篡改，保证签名校验的可信度。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，车辆存储有第一公钥的用途信息，用途信息用于指示第一公钥仅用于校验第一签名。

当授权文件中的授权公钥的合法性由供应商服务器保证时，该第一公钥的用途信息用于规定授权公钥的用途，避免供应商服务器和车云服务器的签名能力混淆，避免车云服务器拥有伪造升级包的签名的可能性。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，车辆使用第一服务器的公钥校验第一签名之前，方法还包括：车辆确定第一公钥为第一服务器允许车辆使用的公钥。

由于车云服务器可以存在多个，不同的车辆可以获取到不同车云服务器发送给的授权文件和升级包。车云服务器除了向车辆发送授权文件和升级包之外，还可以控制车辆允许或禁止用来校验授权文件的签名的授权公钥，这样，可以对不同车云服务器提供的授权公钥进行区分，避免部分车辆厂商的车云服务器的授权私钥丢失，而连带影响到其他车辆厂商。

结合第一方面，第二方面，第四方面，在一种实施方式中，车辆的车辆标识用于标识车辆的第一部件；车辆根据第一升级包进行升级，具体包括：车辆根据第一升级包进行第一部件或第二部件的升级，第二部件的升级由第一部件管理。

由于车辆的升级具体为车辆各部件的升级，车辆身份标识可用于标识车辆升级的部件，进一步地，车辆身份标识可以为部件的芯片ID，或者，对于安全能力较低的部件，对于该部件的升级，其车辆身份标识为管理该部件的，安全能力较强的部件的标识，例如该部件的芯片ID。

结合第一方面，第二方面，第四方面，在一种实施方式中，在车辆升级第二部件的情况下，车辆的身份标识还用于标识第三部件。

其中，车辆身份标识用于标识多个部件，可以防止出现对车辆进行恶意换件的攻击场景。

结合第一方面，第二方面，第四方面，在一种实施方式中，车辆通过第一部件校验第一文件，或者，车辆通过第一部件和第三部件校验第一文件。

也就是说，当车辆进行一个部件的升级时，该授权文件的校验可以由一个或多个部件校验完成。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，其特征在于，第一文件还包括：第二完整性信息，第一签名还根据第二完整性信息确定，车辆确定升级后的车辆的数据包括第一完整性信息指示的升级包中的数据，具体包括：车辆确定升级后的车辆的数据与第二完整性信息指示的数据相同，第二完整性信息指示的数据包括第一升级包中的数据。

当车辆的升级方式为差分升级时，此时升级包为差分包，授权文件中的完整性信息可以包括：差分包中的数据的完整性信息，和，完整升级数据的完整性信息。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，第一文件还包括：第三完整性信息，第一签名还根据第三完整性信息确定，在第一签名的校验通过的情况下，第三完整性信息用于指示车辆升级失败后的数据。

当车辆的升级方式为A/B升级时，授权文件中的完整性信息可以包括：升级包中的数据的完整性信息，和，升级失败后的数据的完整性信息。避免攻击者利用车辆升级失败，恶意篡改车辆中的数据。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，第一升级包中包括第三签名和/或第四签名，第三签名由第一服务器签名得到，第四签名由第二服务器签名得到，第二服务器为开发并提供车辆升级所需的升级文件的服务器；车辆根据第一升级包进行升级之前，方法还包括：车辆使用第一服务器的公钥校验第三签名，且校验通过；和/或，车辆使用第二服务器的公钥校验第四签名，且校验通过。

在上述实施例中，升级包中可以包括编包签名和外层签名，其中，编包签名由供应商服务器对升级文件签名得到，外层签名由车云服务器对升级包签名得到。车辆可以通过校验编包签名来判断升级文件由供应商服务器发送，且传输过程中未被第三方篡改，校验外层签名可以判断升级包由车云服务器发送给，且传输过程中未被第三方篡改，从而保证车辆升级时使用的升级包来源可靠，且未被篡改。

结合第一方面、第二方面、第三方面、第四方面，在一种实施方式中，车辆接收到第一文件和第一升级包之前，方法还包括：车辆接收到升级策略；车辆根据升级策略确定第一地址，第一地址为存储第一升级包的地址；车辆向第一地址所在的服务器发送下载请求，下载请求用于请求获取第一升级包。

在上述实施例中，车辆可以通过接收升级包的下载地址，根据该下载地址从相应的车云服务器获取升级所需的升级包，这样可以加快车辆获取升级包的速度，减少升级包在各车云服务器中所占用的存储空间。

第五方面，本申请提供了另一种车辆校验方法，方法包括：第一服务器获取车辆的车辆标识；第一服务器确定升级包的完整性信息，完整性信息用于标识升级包；第一服务器根据车辆标识和完整性信息确定签名；第一服务器发送文件和升级包，文件包括：车辆标识、完整性信息和签名；升级包用于升级车辆。

实施本申请实施例提供的方法，车云服务器可以在向车辆发送升级包时，将针对该升级包的授权文件一起发送给车辆，其中，该授权文件中可以包括：车辆身份标识、完整性信息、签名。其中，签名由于证明该授权文件由车云服务器发送，避免第三方伪造授权文件，完整性信息用于绑定升级包和授权文件，避免第三方恶意截取授权文件，将授权文件与伪造的升级包一起发送给车辆，车辆身份标识用于指示此次发送的升级包为专门针对该车辆所发送的升级包。这样，可以避免车辆使用车云服务器发送给其他车辆的升级包进行升级，或者，使用其他不用于售卖的升级包，例如，研发阶段使用的升级包、携带病毒的升级包、存在漏洞的升级包等等进行升级，保证车辆使用合法且合适的升级包进行升级，或者，保证车辆运行的数据来源于合法且合适的升级包，保证车辆的安全运行，维护车主、车厂和软件供应商的利益。

结合第五方面，在一种实施方式中，第一服务器根据车辆标识和完整性信息确定签名，具体包括：第一服务器根据防重放参数、车辆标识和完整性信息确定签名，防重放参数用于标识车辆本次的升级。

进一步地，授权文件中还可以包括防重放参数，保证车辆能够根据与服务器约定的升级版本的升级包进行升级。还可以避免攻击者重放老版本的升级包，利用老版本的漏洞攻击车辆，保障了车辆的安全以及车主的利益。

第六方面，本申请实施例提供了另一种车辆校验方法，方法包括：第一服务器确定升级包的完整性信息，完整性信息用于标识升级包；第一服务器根据防重放参数和完整性信息确定签名，防重放参数用于标识车辆本次的升级；第一服务器发送文件和升级包，文件包括：防重放参数、完整性信息和签名；升级包用于升级车辆。

实施本申请实施例提供的方法，车云服务器可以在向车辆发送升级包时，将针对该升级包的授权文件一起发送给车辆，其中，该授权文件中可以包括：防重放参数、完整性信息、签名。其中，签名由于证明该授权文件由车云服务器发送，避免第三方伪造授权文件，完整性信息用于绑定升级包和授权文件，避免第三方恶意截取授权文件，将授权文件与伪造的升级包一起发送给车辆，防重放参数用于标识车辆的本次升级。避免车辆根据该老版本的升级包进行升级，从而预防了攻击者重放老版本的升级包，利用老版本的漏洞攻击车辆，保障了车辆的安全以及车主的利益。

结合第六方面，在一种实施方式中，第一服务器根据防重放参数和完整性信息确定签名，具体包括：第一服务器根据防重放参数、车辆的车辆标识和完整性信息确定签名。

进一步地，授权文件中还可以包括车辆身份标识，避免车辆混用车云服务器给其他车辆发送的升级包，或者研发阶段使用的升级包等等。

结合第五方面、第六方面，在一种实施方式中，方法还包括：第一服务器发送第一列表，第一列表指示了第一服务器允许或禁止车辆校验签名时，使用的公钥。

由于车云服务器可以存在多个，不同的车辆可以获取到不同车云服务器发送给的授权文件和升级包。车云服务器除了向车辆发送授权文件和升级包之外，还可以控制车辆允许或禁止用来校验授权文件的签名的授权公钥，这样，可以对不同车云服务器提供的授权公钥进行区分，避免部分车辆厂商的车云服务器的授权私钥丢失，而连带影响到其他车辆厂商。

结合第五方面、第六方面，在一种实施方式中，文件还包括第一服务器生成的，用于校验签名的公钥。

结合第五方面、第六方面，在一种实施方式中，文件还包括公钥的签名，第一服务器发送文件和升级包之前，方法还包括：第一服务器向第二服务器发送公钥，第二服务器为开发并提供车辆升级所需的升级文件的服务器；第一服务器接收公钥的签名，公钥的签名由第二服务器根据公钥确定。

也就是说，授权文件中的授权公钥的合法性可以由供应商服务器保证，保证车辆在校验授权文件中的签名的可信度。

第七方面，本申请提供了一种车辆，包括存储器，一个或多个处理器，以及一个或多个程序；一个或多个处理器在执行一个或多个程序时，使得车辆实现如第一方面或第一方面的任意一种实施方式、第二方面或第二方面的任意一种实施方式、第三方面或第三方面的任意一种实施方式、第四方面或第四方面的任意一种实施方式所描述的方法。

第八方面，本申请提供了一种电子设备，包括存储器，一个或多个处理器，以及一个或多个程序；一个或多个处理器在执行一个或多个程序时，使得电子设备实现第五方面或第五方面的任意一种实施方式、第六方面或第六方面的任意一种实施方式所描述的方法。

第九方面，本申请提供了一种通信系统，系统包括第七方面的车辆和第八方面的电子设备。

第十方面，本申请提供了一种计算机可读存储介质，包括指令，当指令在电子设备上运行时，使得电子设备执行如如第一方面或第一方面的任意一种实施方式、第二方面或第二方面的任意一种实施方式、第三方面或第三方面的任意一种实施方式、第四方面或第四方面的任意一种实施方式、第五方面或第五方面的任意一种实施方式、第六方面或第六方面的任意一种实施方式所描述的方法。

可以看出，在车辆升级前或启动前，通过对升级包携带的数据，包括车辆身份标识、防重放参数等等，进行校验，可以避免车辆将不适用于本车辆的升级包导入本车辆，或者，避免车辆运行不适用于本车辆的升级包中的数据，进而影响车辆的安全，保障了车主、车厂与软件供应商之间的商业利益。

附图说明

图1为本申请实施例提供的通信系统10的结构示意图；

图2A为本申请实施例提供的车辆300的结构示意图；

图2B为本申请实施例提供的车辆300的电子电气架构图；

图3为本申请实施例提供的电子设备500的硬件结构图；

图4为本申请实施例提供的远端升级场景下，车辆校验方法的流程示意图；

图5为本申请实施例提供的供应商服务器对升级包进行签名的逻辑结构示意图；

图6为本申请实施例提供的车辆验证升级包的编包签名的逻辑结构示意图；

图7为本申请实施例提供的近端升级场景下，车辆校验方法的流程示意图；

图8为本申请实施例提供的多个域控制器校验授权文件中的车辆身份标识时，域控制器之间的交互流程图；

图9为本申请实施例提供的一种车辆升级的时序图；

图10为本申请实施例提供的另一种车辆升级的时序图；

图11为本申请实施例提供的采用多级密钥设置授权公钥的签名时，供应商服务器和车云服务器之间的交互流程图；

图12为本申请实施例提供的一种多级密钥的结构示意图；

图13为本申请实施例提供的供应商服务器对多个车云服务器的授权公钥进行签名的逻辑示意图；

图14为本申请实施例提供的另一种多级密钥的结构示意图。

具体实施方式

下面将结合附图对本申请实施例中的技术方案进行清楚、详尽地描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

为了实现车辆的升级，可以通过将升级包导入并安装在车辆的系统内部，达到拓展或增强车辆软件功能的升级效果。例如，在车辆具备自动驾驶的硬件能力的前提下，可以通过导入自动驾驶功能的升级包，开启车辆的自动驾驶功能。又例如，可以在车辆存在软件漏洞时，通过导入更高版本的升级包，修复该软件漏洞。

其中，车辆的升级方式主要包括以下两种：

1)远端升级

远端升级，又称空中下载(Over-the-Air，OTA)升级，OTA升级是指车辆通过无线网络，与拥有升级包的服务器直接交互，获取升级包并完成升级。

可以看出，OTA升级可以实现远程修复车辆的软件故障，汽车制造商不必召回车辆进行维修，降低了汽车制造商的召回成本，车主也可以便捷快速的完成车辆的修复，降低了车主的时间成本。

2)近端升级

在近端升级场景下，拥有升级包的设备可以通过车辆的端口，例如，通过有线连接车辆的车载自动诊断系统(On Board Diagnostics，OBD)端口，将升级包导入车辆并触发安装，进而完成车辆的升级。例如，车辆可以行驶至汽车销售服务门店，即4S店，由4S店的售后工作人员连接诊断仪/上位机至车辆的OBD端口，将升级包导入车辆进而完成车辆的升级。

可以理解的是，除了OTA升级，其他合法的升级方式，例如USB升级、卡包升级都可以看做是近端升级。

可以看出，在近端升级场景下，车辆可以在未连接网络的情况下，实现车辆的快速升级。

综上，不论是远端升级还是近端升级，都需要将升级包导入车辆中，来实现车辆的升级，这就存在这样一个问题，由于车辆仅单方面的接收升级包，那么攻击者可以将不适用该车辆的升级包，例如老版本的升级包、其他车辆的升级包、研发阶段使用的升级包等，导入该车辆，进而影响车主、车厂和软件供应商的商业利益。

例如，攻击者可以将存在漏洞的老版本的升级包导入车辆，进而利用该漏洞攻击车辆，损害车主的利益。又例如，攻击者可以以更低的售价将官方(例如车厂)发送给其他车辆的升级包导入车辆，实现和在官方购买同等的效果，损害车厂和软件供应商的商业利益。又例如，攻击者可以将研发阶段使用的升级包导入车辆，利用该升级包中自带的特权，恶意修改车辆的程序，降低车辆的安全性，损害车主的利益。

因此，如何避免攻击者将不适用于该车辆的升级包，例如老版本的升级包、其他车辆的升级包、研发阶段使用的升级包等等导入该车辆，或者，如何避免上述不适用于该车辆的升级包中的数据在车辆中运行，是目前亟待解决的问题。

本申请实施例提供了一种车辆校验方法，该方法主要涉及车辆和服务器，服务器存储车辆升级所需的升级包。服务器可以在车辆需要升级时，将车辆身份标识、完整性信息以及根据该车辆身份标识、完整性信息计算的签名和升级包发送给车辆，其中，车辆身份标识用于唯一标识该升级的车辆，完整性信息用于标识该升级包。车辆在接收到车辆身份标识，完整性信息，签名以及升级包后，可以先对签名进行校验，确定该车辆身份标识来源于服务器，且没有被第三方篡改后，再校验接收到的车辆身份标识与车辆本地的身份标识，以及，接收到的完整性信息与车辆对接收到的升级包计算得到的完整性信息是否一致，如果一致，则说明车辆接收到的升级包为服务器专门发送给该车辆的升级包，车辆则可以根据该升级包触发车辆的升级。

也就是说，服务器给不同的车辆发送升级包时，都携带了标识该车辆的车辆身份标识，避免车辆在升级时，混用服务器给其他车辆发送的用于升级的升级包，或者使用未携带车辆身份标识的升级包。

这样，一方面，可以避免车辆使用服务器发送给其他车辆的升级包进行升级，例如车主从非官方渠道获取到的官方发送给其他车辆的升级包，以更低或免费的价格完成车辆的升级，避免损害车厂和软件供应商的利益；另一方面，车辆可以校验升级包是否由可信的服务器发送，只使用可信服务器发送的升级包进行升级，由于服务器并不会将不用于售卖的升级包，例如，研发阶段使用的升级包、携带病毒的升级包、存在漏洞的升级包等等发送给车辆，因此车辆只会根据安全的升级包进行升级，进一步地，即使车辆接收到第三方发送的篡改后的升级包或伪造的升级包，也不会校验通过，也就不会根据该升级包进行升级，从而保证了车辆使用升级包进行升级的安全性。

本申请实施例还提供了另一种车辆校验方法，该方法主要涉及车辆和服务器，服务器可以在车辆需要升级时，将防重放参数、完整性信息以及根据该防重放参数、完整性信息计算的签名和适用于本次升级的升级包发送给车辆，其中，防重放参数用于标识此次升级，完整性信息用于标识该升级包。车辆在接收到防重放参数、签名以及升级包后，可以先对签名进行校验，确定该防重放参数来源于服务器，且没有被第三方篡改后，再校验接收到的防重放参数与车辆本地的防重放参数，以及，接收到的完整性信息与车辆对接收到的升级包计算得到的完整性信息是否一致，如果一致，则说明车辆接收到的升级包为服务器发送的适用于本次升级的升级包，车辆则可以根据该升级包触发车辆的升级车辆。

也就是说，服务器给车辆发送升级包时，携带了标识车辆本次升级的防重放参数，服务器通过该防重放参数来区分车辆不同版本的升级。

可以看出，该车辆校验方法可以保证车辆能够根据与服务器约定的升级版本的升级包进行升级。例如，车辆与服务器可以在每次升级时约定不同的防重放参数，如果攻击者利用老版本的升级包的漏洞来攻击车辆，截取服务器给车辆发送的升级包，并替换成老版本的升级包，但是由于老版本的升级包的防重放参数与车辆本次升级的防重放参数不一致，车辆不会根据该老版本的升级包进行升级，从而预防了攻击者重放老版本的升级包，利用老版本的漏洞攻击车辆，保障了车辆的安全以及车主的利益。

在一些实施例中，上述两种车辆校验方法可以结合实施。具体的，服务器可以将车辆身份标识、防重放参数和完整信信息，以及根据该车辆身份标识、防重放参数、完整性信息计算的签名，随升级包一起发送给车辆，并在校验时，在车辆身份标识、防重放参数和完整性信息的校验都通过后再触发车辆的升级。具体关于车辆身份标识和防重放参数的校验可以参考前述两个实施例中的描述，且本实施例的有益效果可以包含上述两个车辆校验方法的有益效果。

需要注意的是，上述提及的车辆身份标识和/或防重放参数，以及完整性信息，以及根据车辆身份标识和/或防重放参数，以及完整性信息得到的签名可以包含在授权文件里面，也就是说，服务器可以在车辆需要升级时，向车辆发送升级包和授权文件，车辆可以在使用升级包升级之前，先校验该授权文件，具体关于授权文件和授权文件的校验的描述可以参见后续内容，这里先不展开。

可以看出，在车辆升级前，通过对升级包携带的数据，包括车辆身份标识、防重放参数等等，进行校验，可以避免车辆将不适用于本车辆的升级包导入本车辆，进而影响车辆的安全，保障了车主、车厂与软件供应商之间的商业利益。

下面结合图1介绍本申请实施例提供的通信系统10。

图1为本申请实施例提供的通信系统10的结构示意图。如图1所示，该通信系统10可包括：服务器100、服务器200、车辆300。其中：

服务器100可以是指软件供应商维护车辆部件的服务器，以下可称为供应商服务器，服务器100为开发和提供所述车辆升级所需的升级包的服务器。服务器100的数量可以为一个或多个。服务器100可以存储有用于升级车辆部件的一个或多个升级文件，服务器100可以对这一个或多个升级文件进行签名，得到一个或多个升级文件的编包签名，并将这一个或多个升级文件以及编包签名打包成安装包发送给服务器200。其中，编包签名用于证明该安装包由服务器100发送，且传输过程中未被篡改。具体关于编包签名的描述可以参见后续内容，这里先不展开。

服务器200可以是指车辆厂商的服务器，以下可称为车云服务器，服务器200用于管理车辆的升级。服务器200的数量可以为一个或多个。服务器200可以从各个软件供应商的服务器(例如服务器100)获取针对车辆不同部件的安装包，对安装包进行外层签名，并对安装包和外层签名进行打包，得到升级包。外层签名由于证明该升级包由服务器200发送，且传输过程中未被篡改。另外，服务器200还可以获取车辆300的资产信息，根据该资产信息生成授权文件，并直接与车辆进行交互，将升级包，以及授权文件发送给车辆，以供车辆实现升级。其中，资产信息可包括车辆300的软硬件版本，以及车辆身份标识、防重放参数等等。具体关于外层签名的描述可以参见后续内容，这里先不展开。

车辆300可以是指需要升级的车辆。车辆300可用于向服务器200发送资产信息，接收升级包以及授权文件，并对授权文件进行校验，包括授权文件中的签名校验，防重放参数的校验，车辆身份标识的校验、完整性信息的校验等等，以及对升级包中的外层签名和内层签名的校验，根据该升级包实现车辆的升级。具体关于授权文件的校验、以及升级包中的外层签名和内层签名的校验过程，可以参见后续内容，这里先不展开。

在一些实施例中，在远端升级场景下，服务器100可以对一个或多个升级文件进行编包签名，并升级文件和编包签名打包成一个安装包发送给服务器200，服务器200可以获取到不同版本、针对车辆不同部件的安装包，对该升级包进行外层签名并打包，得到针对车辆不同部件的升级包，在车辆300需要升级时，服务器200可以确定适用于车辆300的升级版本的，待升级部件的升级包，生成该升级包的授权文件，并将升级包以及授权文件发送给车辆300，车辆300再校验授权文件以及升级包中的签名，在校验通过后，根据该升级包进行车辆升级。

在另一些实施例中，在近端升级场景下，通信系统10还可以包括电子设备400。电子设备400中转服务器200发送给车辆300的升级包。例如，电子设备400可用于获取服务器200发送的升级包，以及授权文件，并通过有线传输的方式将升级包，以及授权文件导入车辆300。示例性地，电子设备400可以是指汽车销售门店中的诊断仪、电脑等设备。

在本申请实施例中，近端升级和远端升级的不同点仅在与，在车辆300需要升级时，车辆300可以通过电子设备400的中转，来实现与服务器200的交互。也就是说，当车辆通过近端升级的方式进行升级时，服务器200可以将升级包发送给电子设备400，电子设备400再通过有线传输的方式将该升级包导入车辆300，车辆300再根据该升级包进行车辆升级。

本申请实施例不限制服务器100、服务器200、车辆300与电子设备400之间的通信连接方式。具体地，该通信连接可以是有线连接、无线连接。其中，该无线连接可以是高保真无线通信(wireless fidelity，Wi-Fi)连接、蓝牙连接、红外线连接、NFC连接、ZigBee连接等近距离连接，也可以是远距离连接，远距离连接包括但不限于基于2G，3G，4G，5G以及后续标准协议的移动网络的远距离连接。例如，服务器100可以通过无线连接的方式将升级包以及升级包的签名发送给服务器200。

另外，需要注意的是，本申请各实施例中提到的服务器，例如服务器100或服务器200等等，可以是一个服务器，也可以是指多个服务器组成的服务器集群。例如，服务器200可以为多个服务器通过分布式架构部署的服务器集群，集群中可以包括云计算服务器、内容分发网络(Content Delivery Network，CDN)服务器、网络时间协议(Network TimeProtocol，NTP)、域名解析系统(Domain Name System，DNS)服务器等等中的一个或者多个。其中，各个服务器之间可以相互协调，共同完成计算、数据存储、通信等功能。例如，服务器200可以包括服务器201和服务器202，服务器201和服务器202都包含各个软件供应商提供的升级包，车辆300可以与服务器201交互，完成车辆的升级，也可以与服务器202交互，完成车辆的升级。为了方便描述，本申请实施例中将单个服务器、分布式服务器、服务器集群等统称为服务器。

具体关于远端升级和近端升级的概念解释可以参见前述内容，这里不再赘述。具体关于远端升级和近端升级过程中，各设备之间的详细交互过程可以参见后续方法实施例，这里先不赘述。

图2A为本申请实施例提供的车辆300的结构示意图。

如图2A所示，车辆300包括：控制器局域网络(controller area network，CAN)总线11、多个电子控制单元(electronic control unit，ECU)、发动机13、车载盒子(telematics box，T-box)14、变速器15、行车记录仪16、防抱死系统(antilock brakesystem，ABS)17、传感器系统18、摄像系统19，麦克风20，等等。

CAN总线11是支持分布式控制或实时控制的串行通信网络，用于连接车辆300的各个部件。在CAN总线11上的任何部件都可以监听到CAN总线11上传输的所有数据。CAN总线11传输的帧可以包含数据帧、远程帧、错误帧、过载帧，不同的帧传输不同类型的数据。在本申请实施例中，CAN总线11可用于传输各个部件在基于语音指令的控制方法中涉及到的数据，该方法的具体实现可参考后文方法实施例的详细描述。

不限于CAN总线11，在其他一些实施例中，车辆300的各个部件还可以通过其他方式来连接及通信。如，各个部件还可以通过车载以太网(ethernet)局域互联网络(localinterconnect network，LIN)总线、FlexRay及常用车载网络系统(media orientedsystems，MOST)总线等等通信，本申请实施例对此不做限制。以下实施例以各个部件通过CAN总线11通信进行说明。

ECU相当于车辆300的处理器或大脑，用于根据从CAN总线11上获取的指令或者根据用户输入的操作，指示对应的部件执行相应的动作。ECU可以由安全芯片、微处理器((microcontroller unit，MCU)、随机存取存储器(random access memory，RAM)、只读存储器(random-only memory，ROM)、输入/输出接口(I/O)、模拟/数字转换器(A/D转换器)以及输入、输出、整形、驱动等大规模集成电路组成。

ECU的种类繁多，不同种类的ECU可以用于实现不同的功能。

车辆300中的多个ECU例如可包括：发动机ECU121，车载盒子(telematics box，T-box)的ECU122，变速器ECU123，行车记录仪ECU124，防抱死系统(antilock brake system，ABS)ECU 125等。

发动机ECU121用于管理发动机，协调发动机的各个功能，例如可用于启动发动机、关闭发动机等等。发动机是为车辆300提供动力的装置。发动机是将某一种形式的能量转换为机械能的机器。车辆300可用于将液体或气体燃烧的化学能，或者将电能转化为机械能并对外输出动力。发动机组成部分可以包括曲柄连杆机构和配气机构两大机构，以及冷却、润滑、点火、能量供给、启动系统等五大系统。发动机的主要部件有气缸体、气缸盖、活塞、活塞销、连杆、曲轴、飞轮等。

T-box ECU122用于管理T-box14。

T-box14主要负责和互联网通信，为车辆300提供远程通讯接口，提供包括导航、娱乐、行车数据采集、行驶轨迹记录、车辆故障监控、车辆远程查询和控制(如开闭锁、空调控制、车窗控制、发动机扭矩限制、发动机启停、调整座椅，查询电池电量、油量、车门状态等)、驾驶行为分析、无线热点分享、道路救援、异常提醒等服务。

T-box14可用于和汽车远程服务提供商(telematics service provider，TSP)以及用户(如驾驶员)侧电子设备通信，实现电子设备上的车辆状态显示与控制。当用户通过电子设备上的车辆管理应用发送控制命令后，TSP会发出请求指令到T-box14，T-box14在获取到控制命令后，通过CAN总线发送控制报文并实现对车辆300的控制，最后反馈操作结果到用户侧电子设备上的车辆管理应用上。也就是说，T-box14通过CAN总线11读取到的数据，例如车况报告、行车报告、油耗统计、违章查询、位置轨迹、驾驶行为等数据，可以通过网络将传输到TSP后台系统，由TSP后台系统转发给用户侧的电子设备，以供用户查看。

T-box14具体可包括通信模块和显示屏。

其中，通信模块可用于提供无线通信功能，支持车辆300通过无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)、超宽带(ultra-wideband，UWB)等无线通信技术和其他设备通信。通信模块还可用于提供移动通信功能，支持车辆300通过全球移动通讯系统(globalsystem for mobile communications，GSM)、通用移动通信系统(universal Mobiletelecommunications system，UMTS)、宽带码分多址(wideband code division multipleaccess，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，5G以及未来出现的6G等通信技术和其他设备通信。

通信模块可以通过基于蜂窝网络的车辆与万物(vehicle to everything，V2X)通信技术(cellular V2X，C-V2X)和其他设备如服务器、用户侧电子设备等建立连接并通信。C-V2X例如可包括基于长期演进(long term evolution，LTE)的V2X(LTE-V2X)、5G-V2X等。

在一些实施例中，通信模块可用于实现车辆300和服务器，例如服务器200之间的通信，将车辆300中的资产信息，例如软硬件版本、车辆身份标识、防重放参数等等发送给服务器，以便服务器确定适用于车辆300的升级包，通信模块还可用于获取服务器发送的升级包以及授权文件等等。

显示屏用于为驾驶员提供可视化的界面。车辆300中可包括一个或多个显示屏，例如可包括设置于驾驶座前方的车载显示屏，设置于座椅上方的用于显示周边情况的显示屏，还可包括将信息投射到风窗玻璃上的抬头数字显示仪(head up display，HUD)等等。

T-box14也可以被称为车机系统、远程信息处理器、车辆网关等等，本申请实施例对此不作限制。

变速器ECU123用于管理变速器。

变速器15可以用来改变发动机的转速和转矩的机构，它能固定或分档改变输出轴和输入轴传动比。变速器15组成部分可以包含变速传动机构、操纵机构以及动力输出机构等。变速传动机构的主要作用是改变转矩和转速的数值和方向；操纵机构的主要作用是控制传动机构，实现变速器传动比的变换，即实现换档，以达到变速变矩。

行车记录仪ECU124用于管理行车记录仪16。

行车记录仪16组成部分可以包括主机、车速传感器、数据分析软件等。行车记录仪16是指记录车辆行驶途中的影像及声音包括行车时间、速度、所在位置等相关资讯的仪器。在本申请实施例中，当车辆行驶时，车速传感器采集到车轮转速，并将车速信息通过CAN总线发送给行车记录仪16。

ABS ECU125用于管理ABS17。

ABS17是在车辆制动时，自动控制制动器制动力的大小，使车轮不被抱死，处于边滚边滑的状态，以保证车轮与地面的附着力为最大值。在制动过程中，电子控制装置根据车轮转速传感器输入的车轮转速信号判定有车轮趋于抱死时，ABS就进入防抱死制动压力调节过程。

传感器系统18可包括：加速度传感器、车速传感器、震动传感器、陀螺仪传感器、雷达传感器，信号发射器，信号接收器等等。加速度传感器及车速传感器用于检测车辆300的速度。震动传感器可以设置在座位下方、安全带、椅背、操作面板、气囊或其他位置，用于检测车辆300是否被碰撞以及用户所在位置。陀螺仪传感器可以用于确定车辆300的运动姿态。雷达传感器可包括激光雷达、超声波雷达、毫米波雷达等。雷达传感器用于发射电磁波对目标进行照射并接收其回波，由此获得目标至电磁波发射点的距离、距离变化率(径向速度)、方位、高度等信息，从而识别车辆300附近的其他车辆、行人或路障等。信号发射器和信号接收器用于收发信号，该信号可用于检测用户所在位置，该信号例如可以是超声波、毫米波、激光等。

摄像系统19可包括多个摄像头，摄像头用于捕获静态图像或视频。摄像系统19中的摄像头可以设置在车前、车后、侧边、车内等位置，便于实现辅助驾驶、行车记录、全景环视、车内监控等功能。

传感器系统18、摄像系统19可用于检测周边环境，便于车辆300做出相应的决策来应对环境变化，例如可用于自动驾驶阶段完成对周边环境进行关注的任务。

麦克风20，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或输出语音指令时，用户可以通过人嘴靠近麦克风20发声，将声音信号输入到麦克风20。车辆300可以设置至少一个麦克风20。在另一些实施例中，车辆300可以设置两个麦克风20，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，车辆300还可以设置三个，四个或更多麦克风20，形成麦克风阵列，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

此外，车辆300还可以包括多个接口，例如USB接口，RS-232接口、RS485接口等等，可外接摄像头、麦克风、耳机以及用户侧电子设备。

在本申请实施例中，麦克风20可用于检测用户输入的语音指令。传感器系统18、摄像系统19、T-box14等可用于获取输入该语音指令的用户的角色信息。车辆300中各个部件获取用户的角色信息的方式，可参考后续方法实施例中的相关描述。T-box ECU122可用于根据该角色信息判断当前该用户是否具备该语音指令对应的权限，仅在具备权限的情况下，T-box ECU122才调度车辆300中的相应部件来响应该语音指令。

在一些实施例中，车辆300中的存储器可用于存储车辆身份标识、防重放参数，以及公钥和公钥的哈希值等等。具体关于车辆300中存储的内容可以参见后续内容，这里先不展开。

可以理解的是，本申请实施例示意的结构并不构成对车辆系统的具体限定。本申请实施例对电子控制单元ECU的数量不作限制。车辆300可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

例如，车辆300还可包括单独的存储器、电池、车灯、雨刷、仪表盘、音响、车载终端(transmission control unit，TCU)、辅助控制单元(auxiliary control unit，ACU)、智能进入及启动系统(passive entry passive start，PEPS)、车载单元(on board unit，OBU)、车身控制模块(body control module，BCM)、充电接口等等。

图2B示例性示出了车辆300的电子电气架构图。

从图2A可以看出，车辆300包含多个部件，可以根据车辆300包含的多个部件，对车辆300的软硬件进行划分，得到整车电子电气系统的总布局方案。如图2B所示，可以将车辆300划分为多个功能域，一个功能域可以包含一个域控制器(Domain Controller，DC)及其连接的多个电子控制单元ECU等部件。示例性地，车辆的功能域可以包括：动力域、底盘域、座舱域、车身域、自动驾驶域。

应理解，车辆的升级实际是指车辆中搭载的各部件的升级。不同功能域中的部件的升级主要由各自功能域进行管理。

对于车辆的升级，域控制器DC包含两个逻辑功能模块：域升级控制器(DomainUpdate Controller，DUC)、域安装器(Domain Installer，DI)。其中：

域升级控制器DUC用于负责本域的所有部件的升级包，以及升级包的授权文件的下载，对升级包的合法性校验，以及对本域部件升级的整体控制。其中，该域升级控制器DUC对升级包的合法性校验可以是指对升级包中的外层签名的校验，该校验用于确定升级包的来源(例如图1所示的服务器200)是否合法，升级包的内容是否被篡改等等。具体关于外层签名的描述可以参见后续内容，这里先不展开。

域安装器DI用于负责对授权文件的校验，对本域的升级包的合法性校验，以及安装升级包之前，对车辆升级前的条件检查，包括电压、车速等等的检查，以及升级过程中对本域部件的升级刷写。其中，域安装器DI对升级包的合法性校验可以是指对升级包中的编包签名的校验，该校验用于确定升级包的来源(例如图1所示的服务器100)是否合法，升级包的内容是否被篡改等等。其中，授权文件的校验包括车辆身份标识的校验、防重放参数的校验、完整性信息的校验、授权文件的签名校验等等，具体关于编包签名、授权文件的描述可以参见后续内容，这里先不展开。

另外，车辆300中还包括一个车辆升级控制器(Vehicle Update Controller，VUC)，该车辆升级控制器VUC部署在某一个域控制器DC上。

其中，在车辆升级过程中，车辆升级控制器VUC可以负责与服务器(例如图1所示的服务器200)交互，向该服务器上传资产信息，例如，软硬件版本，车辆身份标识，防重放参数等等，从服务器获取下载策略(Download Policy，DP)包。其中，该DP包可以包括各功能域的升级包的下载地址，车辆升级控制器VUC可用于解析该DP包，将升级包的下载地址发送给对应的功能域的域控制器DC，并协调升级包的下载和安装，以供各域控制器DC下载得到该功能域中部件的升级包，从而完成车辆各个部件的升级。具体关于DP包，以及通过DP包获取升级包的描述可以参见后续方法实施例，这里先不展开。

可以理解的是，校验授权文件的模块不限于域安装器DI，例如，通过域升级控制器DUC校验授权文件，本申请实施例对校验授权文件的模块不做限制。

另外，域控制器DC一般还支持安全启动功能，该安全启动功能能够利用预置的公钥，例如服务器100生成的密钥对中的公钥，验证车辆上加载的软件，是否受信任。也就是说，只有通过公钥对应的私钥签名过的软件才能够通过验证并在车辆内部正常启动，而未通过验证的软件则无法加载。这样，可以避免攻击者直接拆机干涉车辆部件，恶意读写车辆的软件，损害车厂和软件制造厂商的商业利益。

在本申请实施例中，在车辆接收到升级包和授权文件，并根据该升级包完成车辆部件的升级后，可以在部件通过安全启动功能进行安全启动时，再触发对授权文件的校验，进一步避免攻击者直接拆机将不适用于本车辆的升级包导入本车辆，更改部件通过升级包升级后的软件程序。由于部件的安全启动过程，具体为软件的逐级启动，即上一级软件启动下一级软件，并在启动下一级软件之前，校验该下一级软件的安全性，其中包括授权文件的校验、编包签名的校验等等，校验通过则说明该下一级软件安全，控制流再移交给下一级软件，继续校验软件的安全性，依次类推，直到该部件中的所有软件都通过校验，则说明部件中的软件安全，即软件来源于软件供应商，且未被经过攻击方篡改，且软件来源不是老版本升级包、其他车辆的升级包、研发阶段使用的升级包等等。进一步地，如果部件使用了车云服务器发送的升级包进行升级，且安全启动阶段对授权文件的校验通过，则说明当前部件运行的程序为经过车云服务器发送的升级包升级后，导入到该部件的软件数据，避免了车辆运行老版本的升级包、其他车辆的升级包、研发阶段使用的升级包等等升级包中的软件数据。

可以看出，在车辆的安全启动阶段校验授权文件，可以避免车辆运行未经校验的程序，防止攻击者直接拆机将不适用于本车辆的升级包，例如老版本的升级包、其他车辆的升级包、研发阶段使用的升级包中的软件数据导入到本车辆，从而在车辆的启动阶段，严格把控车辆的安全运行，保障了车辆的安全，维护了车厂和软件制造厂商的商业利益。

具体关于安全启动过程中的详细描述可以参见后续内容，这里先不赘述。

上述电子电气架构图只是示例性举例，不构成对本申请的限制，应理解，在本申请其他实施例中，车辆的电子电气架构图还可以存在其他结构，并且，本申请实施例对上述电子电气架构图中提及的域控制器DC、域升级控制器DUC、域安装器DI、车辆升级控制器VUC的名称不作限制。

图3为本申请实施例提供的电子设备500的硬件结构图。

如图3所示，电子设备500可以包括：一个或多个处理器201、存储器202、通信接口203、发射器205、接收器206、耦合器207和天线208。这些部件可通过总线204或者其他方式连接，图3以通过总线连接为例。其中：

通信接口203可用于电子设备500与其他通信设备，例如电子设备400。具体的，通信接口203可以是3G通信接口、长期演进(LTE)(4G)通信接口、5G通信接口、WLAN通信接口、WAN通信接口等等。不限于无线通信接口，电子设备500还可以配置有线的通信接口203来支持有线通信，例如电子设备500与其他服务器之间的回程链接可以是有线通信连接。

在本申请的一些实施例中，发射器205和接收器206可看作一个无线调制解调器。发射器205可用于对处理器201输出的信号进行发射处理。接收器206可用于接收信号。在电子设备500中，发射器205和接收器206的数量均可以是一个或者多个。天线208可用于将传输线中的电磁能转换成自由空间中的电磁波，或者将自由空间中的电磁波转换成传输线中的电磁能。耦合器207可用于将移动通信号分成多路，分配给多个的接收器206。可理解的，电子设备500的天线208可以实现为大规模天线阵列。

存储器202与处理器201耦合，用于存储各种软件程序和/或多组指令。具体的，存储器202可包括高速随机存取的存储器，并且也可包括非易失性存储器，例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。

存储器202可以存储操作系统(下述简称系统)，例如uCOS、VxWorks、RTLinux等嵌入式操作系统。

本申请实施例中，处理器201可用于读取和执行计算机可读指令。

在本申请实施例中，当电子设备500为供应商服务器时：

发射器205可用于向车云服务器发送安装包。

处理器201可用于生成用于编包签名的密钥，对一个或多个升级文件进行编包签名。

存储器202可用于存储本地生成的密钥，例如，用于对升级文件进行编包签名的私钥。

在本申请实施例中，当电子设备500为车云服务器时：

发射器205可用于将DP包、升级包和授权文件等等发送给车辆或诊断终端。

接收器206可用于接收供应商服务器发送的安装包，以及车辆或诊断终端发送的资产信息、下载请求等等。

处理器201可用于生成密钥对，对安装包进行外层签名，根据资产信息确定升级包并生成授权文件以及DP包等等。

存储器202可用于存储升级包，以及本地生成的密钥，例如用于对车辆身份标识、防重放参数、完整性信息进行签名的私钥，用于对安装包进行外层签名的私钥。

需要说明的，图3所示的电子设备500仅仅是本申请实施例的一种实现方式，实际应用中，电子设备500还可以包括更多或更少的部件，这里不作限制。

下面结合图4介绍远端升级场景下的车辆校验方法。

图4为本申请实施例提供的远端升级场景下，车辆校验方法的流程示意图。

远端升级场景主要涉及供应商服务器、车云服务器、车辆之间的交互，车辆可以通过无线通信的方式获取升级包，完成车辆的升级。具体关于远端升级的解释，以及远端升级涉及到的通信系统可以参见前述的相关内容，这里不再赘述。

如图4所示，该车辆校验方法可包括：

S101.供应商服务器对一个或多个升级文件进行签名，并生成安装包。

供应商服务器可以是指软件供应商维护车辆部件的服务器，在开发人员开发出车辆部件的升级文件后，供应商服务器可以获取到该新开发的升级文件。示例性地，该供应商服务器可以是指图1中所示的服务器100，具体关于服务器100的描述可以参见图1的相关内容，这里不再赘述。

针对车辆部件的一次升级，供应商服务器可以提供一个或多个升级文件用于升级该部件。该一个或多个升级文件可用于实现车辆部件的操作系统更新、应用软件版本的更新、修复漏洞等等升级效果。具体地，这一个或多个升级文件可用于升级该部件中包含的一个或多个软件。其中，一个升级文件可以包含部件中一个软件的升级数据。

对一个或多个升级文件进行签名具体是指对这一个或多个升级文件分别进行数字签名，获得该一个或多个升级文件的编包签名。供应商服务器可以对这一个或多个升级文件以及这一个或多个编包签名进行压缩，从而生成一个安装包。

其中，数字签名，又称公钥数字签名，是只有信息的发送方才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。具体地，发送方可以生成一对密钥，利用密钥对中的私钥，通过签名算法对信息进行签名。之后，接收方可以利用该密钥对中的公钥，通过验签算法对签名进行验证，从而确定该信息是否来源于信息的发送方，且发送过程中是否被篡改。也就是说，数据签名可以保证信息的合法性，该合法性包括信息的来源合法以及未被篡改。

也就是说，供应商服务器使用自己的私钥对升级文件进行编包签名，可以使得升级文件的接收方能够根据该编包签名来确认升级文件的来源，避免他人冒充供应商服务器，向外发送升级文件。

示例性地，供应商服务器可以生成一对密钥，包括公钥1和私钥1，其中，私钥1留存在本地，用于对升级文件进行签名，公钥1可以发送给车辆，用于车辆在获取到升级包后对该编包签名进行校验。

其中需要注意的是，供应商服务器可以在车辆升级时，将该用于校验编包签名的公钥，例如公钥1，发送给车辆，或者，通过车云服务器的中转发送给车辆，例如，供应商服务器在向车云服务器发送安装包时，将该公钥同时发送给车云服务器，具体关于供应商服务器向车云服务器发送安装包的过程，可以参见后续步骤S102的内容。或者，供应商服务器可在对升级文件进行签名前，提前将用于校验该签名的公钥发送给车云服务器。或者，车辆可以在整车产线阶段，直接将校验该签名的公钥预置到车辆的芯片中。本申请实施例对车辆获取该公钥的方式及时间不作限制。

可以理解的是，供应商服务器对升级文件进行的签名还可以被称为内层签名、小包签名、编包签名等等，本申请实施例对该名称不作限制。

进一步的，供应商服务器可以利用多级密钥来实现对升级文件的编包签名。也就是说，供应商服务器可以生成多对密钥，通过上一级私钥对下一级公钥的逐级签名，来实现对升级文件的编包签名。相应的，在校验编包签名时，需要通过上一级公钥对下一级公钥的签名的逐级校验，来实现对编包签名的校验。

下面以三级密钥为例来介绍供应商服务器对升级文件进行签名的详细过程。

首先供应商服务器生成三对密钥：编包根公钥和编包根私钥、编包二层公钥和编包二层私钥、编包三层公钥和编包三层私钥。

图5为本申请实施例提供的供应商服务器对升级文件进行签名的逻辑结构示意图。

供应商服务器对升级文件进行签名主要包括以下步骤：

1)供应商服务器利用编包根私钥对编包二层公钥进行签名，得到编包二层公钥的签名。

2)供应商服务器利用编包二层私钥对编包三层公钥进行签名，得到编包三层公钥的签名。

3)供应商服务器利用编包三层私钥对升级文件进行签名，得到编包签名。

之后，供应商服务器可以在将安装包包发送给车云服务器时，将上述编包根公钥、编包二层公钥、编包二层公钥的签名、编包三层公钥、编包三层公钥的签名、编包签名发送给车辆，或通过车云服务器转发给车辆，在车辆校验升级包中的编包签名时，可以通过上述编包根公钥、编包二层公钥、编包二层公钥的签名、编包三层公钥、编包三层公钥的签名、编包签名进行校验，具体关于编包签名的校验可以参见后续步骤S115中的相关内容，这里先不展开。

可以理解的是，本申请实施例对供应商服务器使用的密钥层级数不作限制，例如，供应商服务器可以生成四对密钥来实现对升级文件的编包签名，其原理类似于上述供应商服务器利用三级密钥对升级文件进行签名的过程，这里不再赘述。

S102.供应商服务器将安装包发送给车云服务器。

可以理解的，供应商服务器将安装包发送给车云服务器，相应的，车云服务器接收到来自于供应商服务器的安装包。

车云服务器是指直接与车辆进行交互的服务器，它可以获取并存储多个软件供应商的服务器发送的安装包，并在车辆需要升级时，将升级包发送给车辆。其中，升级包为安装包以及安装包的外层签名打包后的文件，具体关于升级包以及外层签名的描述可以参见后续内容，这里先不展开。

车辆可以是指车辆所在的终端设备，车辆可用于接收升级包，并根据该升级包实现车辆的升级。

示例性地，该车云服务器可以是指图1所示的服务器200，该车辆可以是指图1所示的车辆300。具体关于服务器200和车辆300的描述可以参见图1的相关内容，这里不再赘述。

可以理解的是，供应商服务器也可以不对升级文件进行编包签名，本申请实施例对此不作限制。也就是说，S101为可选步骤，那么此时步骤S101中供应商服务器向车云服务器发送的安装包中可以包括升级文件，不包括编包签名。另外，供应商服务器也可以不对升级文件以及升级文件的编包签名进行压缩，也就是说，供应商服务器向车云服务器发送的数据不一定是安装包，供应商服务器可以直接将升级文件和编包签名发送给车云服务器，本申请实施例对供应商服务器向车云服务器发送的数据的数据形式不作限制。另外，本申请实施例对供应商服务器向车云服务器发送的安装包的名称不做限制，该安装包还可以被称为软件包、升级包、压缩包等等。

S103.车云服务器对安装包进行签名，并生成升级包。

具体地，车云服务器可以在接收到供应商服务器发送的安装包之后，可以对安装包进行数据签名，得到该安装包的外层签名。之后，车云服务器可以对该安装包以及外层签名进行打包，从而生成该升级包，实现对供应商服务器发送的安装包的归档。具体关于数字签名的描述可以参见前述的相关内容，这里不再赘述。

其中，升级包可用于增强或增加车辆的功能，例如自动驾驶功能、导航功能等等，在本申请实施例中，该功能还可以被称为第一功能。

车云服务器对安装包进行签名，可以使得安装包的接收方能够根据该签名来确定安装包的来源，避免他人冒充车云服务器，向外发送包含该安装包的升级包。

示例性地，车云服务器可以生成一对密钥，包括公钥2和私钥2，其中，私钥2留存在本地，用于对安装包进行签名，公钥2可以发送给车辆，用于车辆在获取到升级包后对该签名进行校验。

需要注意的是，车云服务器对安装包进行的签名还可以被称为大包签名、外层签名、车辆厂商(Original Equipment Manufacturer，OEM)签名等等，本申请实施例对该名称不作限制。

可以理解的是，车云服务器也可以不对安装包进行签名，则这时，步骤S103是可选的。

另外，本申请实施例对升级包的名称不作限制，在本申请其他实施例中，升级包还可以被称为软件包、安装包、软件升级包、软件安装包、安装文件等等。另外，需要注意的是供应商服务器给车云服务器发送的安装包也可以称为升级包，在本申请实施例中，为了区分供应商服务器给车云服务器发送的用于车辆升级的文件，以及车云服务器给供应商服务器发送的用于车辆升级的文件，供应商服务器发送给的文件称为安装包，车云服务器给车辆发送的文件称为升级包。应理解，该名称并不构成对本申请实施例的限制。

S104.车辆将资产信息发送给车云服务器。

可以理解的是，车辆将资产信息发送给车云服务器，相应的，车云服务器则接收来自车辆的资产信息。

资产信息用于描述车辆升级所需的相关信息，包括但不限于以下一项或多项：软硬件版本信息、车辆身份标识、此次升级的防重放参数等等。其中，软硬件版本信息可用于确定使用该车辆的软硬件升级的升级包的版本，车辆身份标识可用于标识该升级的车辆，防重放参数可以标识此次升级。进一步地，车辆身份标识可用于唯一标识该升级的车辆，防重放参数可以唯一标识此次升级

其中，车辆可以通过查询车辆中搭载的软硬件，获得软硬件的版本信息。具体关于车辆身份标识以及防重放参数的描述可以参见后续内容，这里先不展开。具体关于车辆身份标识和防重放参数的描述可以参见后续车辆身份标识和防重放参数的具体实现，这里先不展开。

示例性地，车辆可以在需要升级时，将资产信息发送给车云服务器。或者，车辆可以周期性将资产信息发送给车云服务器。这样车辆可以周期性更新车云服务器获取到的资产信息。本申请实施例对车辆发送给资产信息的触发时机不作限制。

车辆可以在以下两种情况下触发升级：

1)车辆检测到用户操作，触发升级

在这种情况下，车辆可以在检测到用户的升级操作后，响应于该操作，将资产信息发送给车云服务器，触发车辆的升级。

这样，用户可以自行决定是否升级车辆，控制车辆升级的时间，提升用户对车辆升级的控制权。

2)车辆接收到车云服务器的升级指令，触发升级

在这种情况下，车辆可以在接收到车云服务器的升级指令后，将资产信息发送给车云服务器，触发车辆的升级。

这样，车辆可以在车云服务器的控制下，被动触发车辆的升级。

可以理解的是，车辆升级的触发时机不限于上述两种情况，车辆可以结合上述多种情况触发升级，例如，车辆可以在检测到车云服务器的升级指令，同时检测到用户的升级操作后，触发将资产信息发送给车云服务器，本申请实施例对车辆升级的触发时机不作限制。

具体实现中，车辆可以通过车辆升级控制器VUC向车云服务器发送资产信息，具体关于车辆升级控制器VUC的描述可以参见前述图2B中的相关内容，这里不再赘述。

S105.车云服务器根据资产信息确定升级包。

示例性地，车云服务器可以在接收到资产信息后，触发确定升级包，或者，车云服务器可以在车辆存在升级需求时，例如接收到车辆的升级请求时，触发根据资产信息确定升级包。

具体地，车云服务器可以根据资产信息中的软硬件版本信息，以及车云服务器从供应商服务器获取的安装包的升级版本，确定车辆待升级的部件，从而确定出需要向车辆发送的升级包，该升级包即为车辆待升级部件的升级包。例如，假设资产信息中指示了车辆的第一部件的软件版本为V2，当车云服务器存储有第一部件的V3版本的升级包，则车云服务器可以确定该第一部件为需要升级的版本，则确定该第一部件为车辆的待升级部件，该第一部件的V3版本的升级包为需要向车辆发送的升级包。

需要注意的是，步骤S103中车云服务器对安装包进行签名，也可以在车云服务器接收到资产信息，根据该资产信息确定符合要求的安装包之后，再触发执行。也就是说，本申请实施例对车云服务器对安装包进行签名的时机不做限制。

S106.车云服务器生成授权文件。

授权文件中可以包括但不限于以下一项或多项参数：车辆身份标识、防重放参数、完整性信息。

其中，车辆身份标识可用于唯一标识该升级的车辆，示例性地，该车辆身份标识可以为根据车辆发送的资产信息中的车辆身份标识得到。防重放参数可以标识此次升级，示例性地，该防重放参数可以为根据车辆发送的资产信息中的防重放参数得到。完整性信息用于标识此次升级过程中，车云服务器发送的升级包，进一步地，完整性信息用于唯一标识该升级包。示例性地，该完整性信息可以为使用哈希函数，对升级包计算得到的哈希值。该完整性信息可以为车云服务器根据升级包计算得到的参数，也可以为软件供应商提供的服务器根据升级包计算得到，并发送给车云服务器的参数。具体关于车辆身份标识、防重放参数、完整性信息的描述可以参见后续车辆身份标识、防重放参数、完整性信息的具体实现，这里先不展开。

进一步的，授权文件中还可以包括授权文件的签名，该授权文件的签名用于证明授权文件的合法性。该授权文件的签名可以为车云服务器使用私钥(以下称为授权私钥)，对授权文件中的参数进行数字签名，得到的签名。

示例性地，该授权文件的签名可以为对授权文件中的车辆身份标识、防重放参数、完整性信息进行数字签名，得到的签名。在这种情况下，授权文件的签名可以示例性实现为，车云服务器可以生成一对密钥，包括公钥3和私钥3，其中，私钥3留存在本地，用于计算授权文件的签名，公钥3可以发送给车辆，用于车辆在获取到授权文件后对该签名进行校验。

应理解，当授权文件仅包含车辆身份标识、防重放参数、完整性信息中的一个或多个参数时，授权文件的签名为根据这一个或多个参数计算得到的签名。

进一步的，授权文件中还可以包括用于校验授权文件的签名的公钥(以下称为授权公钥)，例如上述提及的公钥3。这样，在车辆获取到授权文件时，可以根据该授权公钥校验该授权文件的签名。进一步地，授权文件中还可以包括用于证明该授权公钥合法的合法性证明，具体关于合法性证明的描述可以参考后续的具体实现，这里先不展开。

示例性地，表1示出了本申请实施例提供的授权文件的一种结构。

表1

从表1可以看出，授权文件可以包括三个部分：属性域M、签名域和验证公钥域。其中，属性域M中可包括：车辆身份标识Space_Attr、防重放参数Time_Attr、完整性信息Integrity_Attr。签名域中包括车云服务器用自己的授权私钥sk(例如私钥3)对属性域M计算得到的签名Sig(sk,M)。验证公钥域中包括：与该授权私钥sk对应的授权公钥pk(例如公钥3)，该授权公钥pk用于校验签名域中的签名Sig(sk,M)，另外，验证公钥域中还可以包括：用于验证该授权公钥pk合法的合法性证明pk_validity_proof。

可以理解的是，表1所示的授权文件的结构只是示例性举例，不构成对授权文件的限制，在本申请其他实施例中，授权文件的属性域可以包含更多或更少的信息，例如，属性域中可以仅包括车辆身份标识Space_Attr、防重放参数Time_Attr，又例如，验证公钥域中可以不包含合法性证明pk_validity_proof。或者，授权文件不限于由上述三个部分组成。本申请实施例对授权文件的结构不作限制。

另外，需要注意的是，步骤S103中提及的车辆向车云服务器发送的车辆身份标识，与步骤S106中提及的授权文件中的车辆身份标识可以不同，具体可以参见后续关于车辆身份标识的实现部分，另外，车辆向车云服务器发送的资产信息中可以不包括防重放参数，而车云服务器向车辆返回的授权文件中可以包括防重放参数，即步骤S103中提及的资产信息中，可以不包含防重放参数，而在步骤S106中提及的授权文件中可以包含防重放参数，具体可以参见后续关于防重放参数的实现部分，这里先不展开。

S107.车云服务器确定升级策略。

由于车云服务器的数量可以为一个或多个，不同部件的升级包可能存储在不同的车云服务器中，车云服务器在确定车辆的待升级部件后，可以根据这些待升级部件的升级包所在的存储地址，确定升级策略，该升级策略用于指示车辆待升级部件的升级包的下载地址。

其中，该升级策略可以是指下载策略(Downloadpolicy，DP)包，该DP包可以包括车辆多个待升级部件的升级包的下载地址，该下载地址可用于获取升级包。示例性地，该下载地址可以为统一资源定位符(uniform resource locator，URL)。

可选地，该DP包中还可以包括授权文件的下载地址，该下载地址用于获取授权文件。示例性地，该下载地址可以为URL。

可选的，DP包中还可以包括升级规则、升级条件、下载规则等等中的一项或多项。其中，升级规则可用于定义升级的次序、是否需要进行回滚等规则，升级条件可以包含是否供电正常、存储空间、网络状态等等，下载规则可用于定义下载的顺序，指示下载升级包的部件等等。本申请实施例对DP包中包含的内容不做限制。

S108.车云服务器将升级策略发送给车辆。

车云服务器将升级策略发送给车辆，相应的，车辆获取到车云服务器发送的升级策略。

具体实现中，车辆可以通过车辆升级控制器VUC获取升级策略。具体关于车辆升级控制器VUC可以参见前述图2B的相关内容，这里不再赘述。

S109.车辆根据升级策略解析下载地址。

该下载地址可以包括车辆的一个或多个部件的升级包的存储地址，例如第一地址。

可选的，该下载地址还可以包括升级包的授权文件的存储地址。

具体地，车辆可以通过车辆升级控制器VUC解析升级策略，得到一个或多个部件的升级包的下载地址，车辆根据该一个或多个部件所在的功能域，将下载地址发送给相应的功能域的域控制器DC。例如，车辆根据升级策略解析得到第一部件的升级包的下载地址1，和第二部件的升级包的下载地址2，假设该第一部件位于第一功能域，第二部件位于第二功能域，则车辆将该下载地址1发送给第一功能域中的域控制器DC，将下载地址2发送给第二功能域中的域控制器DC。

S110.车辆根据下载地址向车云服务器发送下载请求。

车辆向车云服务器发送下载请求，相应的，车云服务器则接收到来自车辆的下载请求。

该下载请求可用于获取升级包。这里的车云服务器可以是指存储有该下载请求所请求获取的升级包的服务器。

可选的，该下载请求还可用于获取授权文件。

S111.车云服务器将升级包发送给车辆。

车云服务器将升级包发送给车辆，相应的，车辆则接收到来自车云服务器的升级包。具体的，车辆可以通过域升级控制器DUC获取升级包。

另外，类似于步骤S102中供应商服务器将公钥发送给车云服务器，在车云服务器将升级包发送给车辆的同时，车云服务器还可以将用于校验该编包签名的公钥(例如公钥1)和校验该外层签名的公钥(例如公钥2)一起发送给车辆。或者，车云服务器在对安装包进行外层签名之前，提前校验该外层签名的公钥发送给车辆。或者，车辆可以在整车产线阶段，直接将该公钥存储在车辆的芯片内部。本申请实施例对车辆获取该校验外层签名的公钥的方式及时间不作限制。

可以理解的是，车云服务器也可以不对安装包进行签名，直接将安装包发送给车辆，本申请实施例对此不做限制。

S112.车云服务器将授权文件发送给车辆。

车云服务器将授权文件发送给车辆，相应的，车辆接收到来自车云服务器的授权文件。具体的，车辆可以通过域升级控制器DUC获取授权文件。

车辆获取授权文件可以包括以下两种情况：

1)车辆通过升级策略获取到授权文件

也就是说，车云服务器在生成授权文件之后，可以将该授权文件的下载地址随升级策略，发送给车辆，这样，车辆可以在获取到升级策略之后，根据该授权文件的下载地址，向授权文件所在的设备发送下载请求。

这种情况下，步骤S108中，车云服务器向车辆发送的升级策略中，可以包括授权文件的下载地址，步骤S109中，车辆解析的下载地址中，可以包括授权文件的下载地址，同理，步骤S110中，车辆向车云服务器发送的下载请求还用于请求获取授权文件。

2)车辆直接获取到车云服务器发送的授权文件

也就是说，车云服务器在生成授权文件后，直接将该授权文件发送给车辆，无需经过先发送地址，再发送给授权文件的过程。

这种情况下，步骤S108中，车云服务器向车辆发送的升级策略中，可以不包括授权文件的下载地址，步骤S109中，车辆解析的下载地址中，可以不包括授权文件的下载地址，同理，步骤S110中，车辆向车云服务器发送的下载请求可以仅用于请求获取升级包。

另外，本申请实施例对步骤S111和步骤S112的先后执行顺序不作限制。例如，步骤S111可以在步骤S112之后执行，或者，步骤S111和步骤S112可以同时执行。

S113.车辆校验授权文件。

车辆对授权文件的校验可以包括以下一项或多项：

1)校验授权文件的签名

车辆校验授权文件的签名是为了校验授权文件的合法性，包括确认授权文件的来源是否合法，以及授权文件是否被篡改。这样，可以避免攻击者获取到授权文件后，恶意篡改授权文件中的参数，包括：车辆身份标识、防重放参数、完整性信息等等。

具体实现中，车辆可以利用校验该签名的授权公钥(例如公钥3)对签名进行解密，获得授权文件的参数的消息摘要，并利用哈希算法对车辆接收到的授权文件中的参数进行运算，得到本地计算得到的消息摘要。车辆校验授权文件的签名，即为判断解密得到的消息摘要与本地计算得到的消息摘要是否一致。示例性地，授权文件的参数包括车辆身份标识、防重放参数、完整性信息。

另外，需要注意的是，车辆对授权文件使用的哈希算法，与车云服务器对授权文件进行签名时，使用的哈希算法相同。

2)校验授权文件中的车辆身份标识

车辆校验授权文件中的车辆身份标识，是为了确定车云服务器发送的升级包是否为车云服务器发送的适用于该车辆的升级包。这样，可以避免攻击者将服务器发送给其他车辆的升级包或者未经授权的升级用于升级本车辆。

具体实现中，车辆可以通过判断授权文件中的车辆身份标识，与本地的车辆身份标识是否一致，来完成车辆身份标识的校验。具体关于车辆身份标识的校验可以参见后续的具体实现，这里先不赘述。

3)校验授权文件中的防重放参数

车辆校验授权文件中的防重放参数，是为了确定车云服务器发送的升级包是否为适用于本次升级的升级包。这样，可以避免攻击者将不适用于车辆本次升级的版本的升级包用于升级本车辆。

具体实现中，车辆可以通过判断授权文件中的防重放参数，与本地的防重放参数是否一致，来完成防重放参数的校验。具体关于防重放参数的校验可以参见后续的具体实现，这里先不赘述。

4)校验授权文件中的完整性信息

车辆校验授权文件中的完整性信息，是为了确定当前校验的授权文件是否为该升级包的授权文件。这样可以避免攻击者仿冒升级包的授权文件，为车辆提供虚假的车辆身份标识、防重放参数等信息，或者，避免攻击者仅截取升级包的授权文件，将该授权文件绑定在其他升级包中发送给本车辆，影响车辆的安全。

示例性地，车辆可以使用哈希函数，计算车辆接收到的升级包的哈希值，该哈希值为车辆在本地计算得到的升级包的完整性信息，车辆再通过判断本地计算得到的完整性信息，与授权文件中的完整性信息是否一致，来完成完整性信息的校验。

另外，需要注意的是，车辆对升级包使用的哈希函数，与车云服务器计算升级包的完整性信息时，使用的哈希函数相同。

另外，由于完整性信息是为了实现升级包和授权文件的绑定，避免攻击者恶意截取授权文件，将该授权文件随其他存在漏洞的升级包来实现车辆的升级，进而危害车辆的安全，如果本身授权文件和升级包的传输过程是绝对安全的，或者传输过程中对授权文件和升级包进行了加密，使得攻击者无法获取到授权文件和升级包的内容，或者升级包和授权文件是不可分割的，使得攻击者无法单独截取到授权文件，则该授权文件中可以不包括该完整性信息。或者，车云服务器可以在发送授权文件和升级包时，对该授权文件和升级包进行签名，避免了攻击者恶意拆分授权文件和升级包。

可以理解的是，授权文件的校验具体根据授权文件中包含的内容来决定需要校验的内容，例如，当授权文件中仅包含车辆身份标识时，授权文件的校验可以仅包括对车辆身份标识的校验，当授权文件中包含车辆身份标识以及防重放参数，则授权文件的校验可以包括车辆身份标识的校验以及防重放参数的校验。

由于车辆的升级具体为车辆中各个部件的升级，车辆在获取到升级包的授权文件时，可以具体通过待升级部件所在功能域的域控制器DC完成授权文件的校验。具体地，车辆可以通过域控制器DC中的域安装器DI校验授权文件。或者，进一步的，车辆还可以具体通过其他功能域的域控制器DC协助完成授权文件的校验。也就是说，一个授权文件的校验，可以具体由一个或多个域控制器DC完成。本申请实施例对校验授权文件的域控制器DC的数量不作限制。具体关于域安装器DI的描述可以参见前述图3的相关内容，这里不再赘述。

S114.车辆判断授权文件的校验是否通过。

当车辆检验的全部内容都一致时，则授权文件的校验通过，否则，当车辆的校验中存在一项不一致时，则授权文件的校验不通过。

例如，当授权文件的检验包括对授权文件的签名的校验、车辆身份标识的校验、防重放参数的校验、完整性信息的校验时，只有在授权文件的签名解密得到的消息摘要，与本地计算得到的消息摘要一致，且，授权文件中的车辆身份标识，与本地的车辆身份标识一致，且，授权文件中的防重放参数与本地的防重放参数一致，授权文件中的完整性信息与本地计算得到的完整性信息一致的情况下，车辆才判断授权文件的校验通过，否则，当签名的校验、车辆身份标识的校验、防重放参数的校验、完整性信息的校验中，存在一个或多个校验不一致时，则授权文件的校验不通过。

可以理解的是，车辆可以同时执行授权文件中的多项校验，也可以逐个执行单项校验，本申请实施例对此不做限制。

示例性地，当签名的授权文件中包括：车辆身份标识、防重放参数、完整性信息、授权文件的签名时，车辆可以先验证授权文件的签名，在签名校验通过后，再校验授权文件中的车辆身份标识，在车辆身份标识校验通过后，再校验授权文件中的完整性信息，在完整信信息校验通过后，再校验授权文件中的防重放参数，如果防重放参数的校验通过，则说明授权文件的校验通过，当授权文件中的任意一个校验不通过，则车辆停止校验，并确定授权文件的校验不通过。

当车辆判断授权文件的校验通过时，则车辆执行步骤S115，否则，车辆执行步骤S118。

S115.车辆校验升级包。

在授权文件的校验通过后，车辆可以校验升级包。升级包中包括安装包和安装包的外层签名，安装包中包括一个或多个升级文件和与这一个或多个升级文件一一对应的编包签名。

升级包的校验可以包括以下一项或多项：

1)外层签名的校验

车辆校验外层签名，是为了确认升级包由车云服务器发送到车辆时，该升级包的来源是否合法，以及升级包是否被篡改。

外层签名是指车云服务器对安装包的签名，具体关于外层签名的描述可以参见前述步骤S103的相关内容，这里不再赘述。

示例性地，当升级包中包含车云服务器对安装包的签名时，车辆可以先对升级包进行解包，获得安装包和对安装包的外层签名。然后，车辆可以利用校验该签名的公钥(例如公钥2)来实现对签名的校验。

具体地，车辆可以通过域升级控制器DUC，用车云服务器的生成的用于签名-验签外层签名密钥对中的公钥校验升级包的外层签名。具体关于域升级控制器DUC的描述可以参见前述图3的相关内容，这里不再赘述。

2)编包签名的校验

车辆校验编包签名，是为了确认安装包由供应商服务器发送到车云服务器时，该安装包的来源是否合法，以及安装包是否被篡改。

编包签名是指供应商服务器对升级文件的签名，具体关于编包签名的描述可以参见前述步骤S101的相关内容，这里不再赘述。

示例性地，当升级包包含供应商服务器对升级文件的签名时，车辆可以先对安装包进行解包，获得一个或多个升级文件和一个或多个编包签名，之后，车辆可以利用校验该签名的公钥(例如公钥1)来实现对编包签名的校验。

具体地，车辆可以通过域安装器DI，用供应商服务器生成的用于签名-验签编包签名密钥对中的公钥校验升级包的编包签名。具体关于域安装器DI的描述可以参见前述图3的相关内容，这里不再赘述。

可以理解的是，升级包的校验具体根据升级包中包含的签名来决定需要校验的内容，例如当升级包中仅包含外层签名时，则升级包的校验可以仅包括对外层签名的校验，当升级包中仅包含编包签名时，则升级包的校验可以仅包括对编包签名的校验，当升级包中包括外层签名和编包签名时，升级包的校验可以包括外层签名的校验和编包签名的校验。另外，当车辆接收的升级包不存在签名时，则车辆不存在升级包的签名校验。示例性地，针对电子控制单元ECU的升级包，该升级包中可以仅包含外层签名，不包含编包签名。需要注意的是，即使升级包中包含编包签名，车辆在升级阶段也可以不校验该编包签名，而在安全启动阶段校验编包签名，具体关于安全启动阶段的描述可以参见后续内容，这里先不展开。

另外，当升级包的校验同时包括编包签名的校验和外层签名的校验时，具体实现中，车辆可以先通过域升级控制器DUC校验外层签名，在外层签名的校验通过后，再通过域安装器DI校验编包签名。

进一步的，当供应厂服务器是利用的多级密钥来进行升级包的编包签名时，车辆在对编包签名的校验时涉及到多个公钥的校验过程。

下面以三级密钥为例来介绍车辆对编包签名的校验的详细过程。

当供应商服务器利用三级密钥来进行升级文件的编包签名时，例如，供应商服务器生成的三对密钥：编包根公钥和编包根私钥、编包二层公钥和编包二层私钥、编包三层公钥和编包三层私钥。车辆可以获取到编包根公钥、编包二层公钥、编包二层公钥的签名、编包三层公钥、编包三层公钥的签名、编包签名。具体关于供应商服务器利用三级密钥来进行升级包的编包签名的描述，可以参见前述图5的相关内容，这里不再赘述。

图6为本申请实施例提供的车辆验证升级包的编包签名的逻辑结构示意图。

如图6所示，车辆验证编包签名主要包括以下步骤：

步骤1：车辆验证编包根公钥的可信度

为了避免车辆接收到的编包根公钥是攻击者伪造的，首先车辆需要验证该编包根公钥的可信度。

其中，车辆可以在本地存储有该编包根公钥的哈希值，在验证编包根公钥的可信度时，可以计算该编包根公钥的哈希值，再与本地存储的编包根公钥的哈希值进行比较。如果两者一致，则说明该编包根公钥是可信的，不是伪造的数据，否则，则说明该编包根公钥是不可信的。

优选的，该编包根公钥的哈希值可以存储在芯片的一次性可编程(One TimeProgrammable，OTP)存储区域中，由于该OTP的内容不可篡改，且该不可篡改特性由硬件机制保障。这样，可以防止攻击者篡改车辆存储的编包根公钥的哈希值，保证编包根公钥的验证过程的可行度。

在编包根公钥可信的情况下，车辆可以执行步骤2。

步骤2：车辆利用编包根公钥校验编包二层公钥的签名

由于编包二层公钥的签名是供应商服务器利用编包根私钥，对编包二层公钥签名得到的。因此，在校验编包二层公钥的签名时，可以利用与编包根公钥来校验该签名。

当编包二层公钥的签名的校验通过时，则说明编包二层公钥是可信的。在编包二层公钥可信的情况下，车辆可以执行步骤3。

步骤3：车辆利用编包二层公钥校验编包三层公钥的签名

由于编包三层公钥的签名是供应商服务器利用编包二层私钥，对编包三层公钥签名得到的。因此，在校验编包三层公钥的签名时，可以利用与编包二层公钥来校验该签名。

当编包三层公钥的签名的校验通过时，则说明编包三层公钥是可信的。在编包三层公钥可信的情况下，车辆可以执行步骤4。

步骤4：车辆利用编包三层公钥校验编包签名

由于编包签名是供应商服务器利用编包三层私钥，对升级包中的升级文件签名得到的。因此，在校验编包签名时，可以利用与编包三层公钥来校验该编包签名。

当编包签名的校验通过时，则说明该升级包中的升级文件是可信的。

可以理解的是，本申请实施例对供应商服务器使用的密钥层级数不作限制，例如，当供应商服务器使用四对密钥来实现编包签名时，该编包签名的校验过程中可以涉及对更多公钥的签名的校验，其原理类似于上述车辆对编包签名的校验过程，这里不再赘述。

S116.车辆判断升级包的校验是否通过。

如果车辆对升级包的所有签名的校验都通过，则升级包的校验通过，否则，升级包的校验不通过。

车辆判断升级包的校验通过时，则执行步骤S117，否则，执行步骤S118。

S117.车辆安装升级包。

车辆安装升级包是指车辆执行升级包的刷写，将升级包中的升级文件写入车辆的存储分区中，具体地，将车辆待升级部件的升级包中的升级文件写入该待升级的部件的存储分区中。

具体地，车辆可以通过域安装器DI安装升级包，完成车辆的部件的升级。

这样，车辆只有在确定升级包为适用于本车辆的升级包，升级包来源合法且未被篡改的前提下，才会触发安装升级，从车辆升级阶段严格把控车辆的安全运行，为车辆的升级提供安全保障。

S118.车辆取消升级。

如果授权文件的校验不通过，则车辆取消升级，车辆的升级失败。这样，可以避免车辆将不适用于本车辆的升级包，例如老版本的升级包、其他车辆的升级包、研发阶段使用的升级包等等导入该车辆，尽可能地维护车主、软件供应商、车厂的商业利益，提高车辆的安全性。

同样地，如果升级包的校验不通过，则车辆取消升级，车辆的升级失败。这样，可以避免车辆将恶意篡改或来源不合法的升级包导入该车辆，尽可能地提高车辆升级的安全性。

应理解，在本申请实施例中，车云服务器还可以被称为第一服务器，供应商服务器还可以被称为第二服务器，车辆本地的车辆身份标识还可以被称为车辆标识，车辆接收到的授权文件还可以被称为第一文件，接收到的升级包还可以被称为第一升级包，授权文件中的车辆身份标识还可以被称为第一车辆标识，授权文件中防重放参数还可以被称为第一防重放参数，授权文件中的完整性信息还可以被称为第一完整性信息，授权文件中的签名还可以被称为第一签名，授权文件中的授权公钥还可以被称为第一公钥，升级包中的外层签名还可以被称为第三签名，升级包中的编包签名还可以被称为第四签名。

下面结合图7介绍近端升级场景下的车辆校验方法。

图7为本申请实施例提供的近端升级场景下，车辆校验方法的流程示意图。

近端升级场景主要涉及供应商服务器、车云服务器、车辆、诊断终端之间的交互，车辆可以通过有线通信的方式获取升级包，完成车辆的升级。

如图7所示，该车辆校验方法可包括：

S201.供应商服务器对一个或多个升级文件进行签名，并生成安装包。

S202.供应商服务器将安装包发送给车云服务器。

S203.车云服务器对安装包进行签名，并生成升级包。

其中，步骤S201-S203和图4中的步骤S101-S103相同，可参考相关描述。

S204.诊断终端获取车辆的资产信息。

S205.诊断终端将资产信息发送给车云服务器。

其中，步骤S204-S205和图4中的步骤S104类似，不同之处在于图7中的车辆的资产信息是通过诊断终端与车辆建立有线连接，从车辆中读取到的，之后，诊断终端再将资产信息发送给车云服务器。而图4中是车辆直接将资产信息发送给车云服务器。

其中，诊断终端用于获取车辆的资产信息，并从车云服务器获取升级包，通过有线传输的方式将升级包导入车辆。示例性地，该诊断终端可以是指图1所示的电子设备400。具体关于电子设备400的描述可以参见图1的相关内容，这里不再赘述。

另外，在车辆将资产信息发送给诊断终端之前，需要用户手动将诊断终端连接到车辆的端口，例如OBD端口，诊断终端可通过该OBD端口获取车辆的资产信息，以及，将升级包导入车辆。

S206.车云服务器根据资产信息确定升级包。

S207.车云服务器生成授权文件。

S208.车云服务器确定升级策略。

其中，步骤S206-S208和图4中的步骤S105-S107相同，可参考相关描述。

S209.车云服务器将升级策略发送给诊断终端。

S210.诊断终端根据升级策略解析下载地址。

S211.诊断终端根据下载地址向车云服务器发送下载请求。

S212.车云服务器将升级包发送给诊断终端。

S213.车云服务器将授权文件发送给诊断终端。

S214.诊断终端将升级包发送给车辆。

S215.诊断终端将授权文件发送给车辆。

其中，步骤S209-S215和图4中的步骤S108-S112类似，不同之处在于图7中的车云服务器是将升级策略发送给诊断终端，由诊断终端解析出下载地址，之后，再由诊断终端向车云服务器发送下载请求，并且，车云服务器是将升级包和授权文件发送给诊断终端，诊断终端再将该升级包和授权文件转发给车辆。而图4中的车云服务器直接将升级策略发送给车辆，由车辆解析出下载地址，之后，再由车辆向车云服务器发送下载请求，并且，车云服务器是将升级包和授权文件直接发送给车辆。

需要注意的是，在步骤S214和步骤S215中，诊断终端是通过有线连接的方式将升级包和授权文件发送给车辆，例如，诊断终端连接车辆的OBD端口，通过该OBD端口将升级包传输给车辆。

另外，本申请实施例不限制步骤S212-S215的先后执行顺序，例如，步骤S214可以在步骤S213之前执行，也可以在步骤S215之后执行。可以看出，只需要步骤S214在步骤S212之后执行，步骤S215在步骤S213之后执行即可。

S216.车辆校验授权文件。

S217.车辆判断授权文件的校验是否通过。

如果车辆判断授权文件的校验通过，则执行步骤S218，否则，执行步骤S221。

S218.车辆校验升级包。

S219.车辆判断升级包的校验是否通过。

如果车辆判断升级包的校验通过，则执行步骤S220，否则，执行步骤S221。

S220.车辆安装升级包。S221.车辆取消升级。

其中，步骤S216-S221和图4中的步骤S113-S118类似。不同之处在于，步骤S216中车辆校验授权文件可以由车辆自动触发对授权文件的校验，也可以由诊断终端触发车辆对授权文件的校验，类似的，步骤S218中车辆校验升级包可以由车辆自动触发对升级包的校验，也可以由诊断终端触发车辆对升级包的校验。

另外，在步骤S220中，车辆在近端升级场景下的安装升级包可以包括以下三个阶段：

1)预编程阶段

预编程阶段也可以被称为刷写准备阶段，该阶段主要用于搭建升级前的升级环境。具体地，车辆可以将待升级部件的运行模式切换到会话模式，在该会话模式下，待升级部件存在更高的诊断权限，待升级部件可以在该模式下进行升级刷写。

2)安装阶段

安装阶段主要是车辆将升级包的数据刷写到待升级部件的存储中。

3)后编程阶段

在刷写结束后，车辆可以将待升级部件的运行模式切换回默认会话模式，从而结束车辆的升级。

可以看出，在近端升级场景下，车辆无需联网，直接通过有线连接诊断终端，由诊断终端主导，完成车辆的升级，并且车辆会在升级之前，检验升级包是否为适用于本车辆的升级包，来源是否合法，以及是否被篡改，从车辆升级阶段严格把控车辆的安全运行，保证车主、软件供应商和车厂的商业利益。

另外，对于车辆中支持安全启动功能的部件，例如车辆中的域控制器DC，在车辆完成升级之后，启动车辆的过程中，车辆的部件同样也存在验证授权文件的过程。这样，可以防止车辆升级后，任何未经授权或恶意修改的软件在车辆内部运行，尽可能地保证车辆运行时的系统安全。

在车辆部件进行安全启动的过程中，部件中的软件依次启动，且前一个软件校验后一个软件的安全性，验证通过后，前一个软件将控制权移交给后一个软件，以此类推，从而完成车辆部件的安全启动。

车辆的安全启动可以是指启动车辆的功能，例如第一功能。示例性地，车辆可以在检测到启动第一功能的指令后，触发对授权文件的校验，并在校验通过后，触发启动第一功能。

下面以车辆部件安全启动过程中，第一软件校验第二软件为例，来详细介绍安全启动场景下，该车辆校验方法还包括的内容。其中，该第二软件可以为使用升级包升级后的程序。

步骤1：车辆安全启动第一软件。

该第一软件可以是已校验过安全性的软件，也可以是开始安全启动时，存在绝对安全性的软件。其绝对安全性由硬件机制保障，这时，第一软件的代码位于不可篡改的存储区域中，例如OCR中。

步骤2：车辆通过第一软件校验授权文件。

该授权文件为第二软件通过升级包升级时，该升级包的授权文件。具体关于授权文件的描述以及授权文件的获取可以参见前述图4的相关内容，这里不再赘述。示例性地，该第二软件可以为xloader。

其中，授权文件的校验包括以下一项或多项：校验授权文件的签名、校验车辆身份标识、校验完整性信息、校验防重放参数。

其中，车辆在安全启动阶段对授权文件的校验类似于升级阶段对授权文件的校验，不同的是，在安全启动阶段和升级阶段校验的完整性信息不同。

在车辆升级阶段，车辆是通过计算接收到的升级包的完整性信息，将该完整性信息与授权文件中的完整性信息进行比较，来实现完整性信息的校验。

而在安全启动阶段，由于升级包的数据已经导入到第二软件内部，车辆校验的是第二软件的镜像文件的完整性信息。具体的，车辆可以使用哈希算法，计算第二软件的镜像文件的完整性信息，将该完整性信息与授权文件中的完整性信息比较，如果一致，则完整性信息的校验通过，否则，完整性信息的校验不通过。其中，镜像是一种文件存储形式，是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。所谓镜像文件其实和安装包类似，它将特定的一系列文件按照一定的格式制作成单一的文件，以方便用户下载和使用，例如一个测试版的操作系统、游戏等。

在授权文件的校验通过后，车辆可以执行步骤3，否则，车辆终止安全启动。

步骤3：车辆校验第二软件的编包签名。

一个升级包可以实现部件中一个或多个软件的升级，第二软件的编包签名可以为升级包中的其中一个升级文件的编包签名。

由于该第二软件为车辆使用升级包升级后的软件，在车辆升级完成后，升级包的编包签名存储在第二软件的存储分区中，车辆校验第二软件的编包签名即为校验第二软件的编包签名。

也就是说，车辆校验第二软件的编包签名，与车辆升级阶段，校验升级包的编包签名的过程类似。不同的是，在安全启动阶段，车辆是从第二软件的存储分区中，获取第二软件的编包签名和用于校验该编包签名的公钥，来完成对编包签名的校验。

可以理解的是，当编包签名是利用多级密钥实现的，该第二软件的存储分区中还包括其他公钥和其他公钥的签名。具体关于编包签名的校验可以参见前述步骤S115中的相关内容，这里不再赘述。

这样，可以防止在车辆升级完成后，任何未经授权或恶意修改的软件在车辆内部运行。

在编包签名的校验通过后，车辆可以执行步骤4；否则，车辆终止安全启动。

可以理解的是，车辆也可以先校验升级包的编包签名，再校验授权文件，也就是说步骤3可以在步骤2之前执行，本申请实施例对该执行顺序不作限制。

步骤4：车辆安全启动第二软件。

车辆在安全启动第二软件之后，可以将控制权移交给第二软件，车辆继续通过第二软件校验第二软件的下一级软件(例如第三软件)的安全性，包括校验授权文件和编包签名，依次类推，直到车辆校验完当前车辆部件的所有软件，则车辆安全启动该车辆部件。

可以看出，车辆在升级阶段可以接收到授权文件和升级包，并通过校验授权文件来确定是否使用该升级包升级，之后，在车辆的安全启动阶段，车辆可以再次校验该授权文件，来防止攻击方恶意拆件更改车辆升级后的数据。

需要注意的是，车辆在升级阶段接收到授权文件和升级包后，可以既在升级阶段校验授权文件，又在安全启动阶段校验授权文件，或者，车辆可以仅在升级阶段校验授权文件，或者，车辆可以仅在安全启动阶段校验授权文件，本申请实施例对此不作限制。示例性地，当车辆仅在安全启动阶段校验授权文件时，车辆可以直接根据该升级包进行升级，不进行授权文件的校验，而在车辆的安全启动阶段，车辆再进行授权文件的校验，校验车辆的数据是否是根据升级包升级后的数据，只有校验通过后，才能启动车辆，保证车辆的安全运行。

应理解，安全启动阶段提及的升级包和授权文件为车辆在升级阶段获取到的升级包和授权文件，具体关于授权文件的获取，可以参考前述图4和图7的相关内容，这里不再赘述。

下面详细介绍车辆身份标识的具体实现过程。

车辆身份标识用于唯一标识当前升级的车辆，进一步的，唯一表示当前升级的部件。车辆在升级时，可以通过校验该车辆身份标识，来防止攻击者利用其他车辆的升级包或研发阶段使用的升级包等等不适用于本车辆的升级包来升级本车辆。

由于授权文件的校验可以由下载该授权文件的域控制器DC校验，或者，由下载该授权文件的域控制器DC以及其他域控制器DC共同校验。根据授权文件校验时涉及到的域控制器DC的数量，车辆身份标识的实现主要涉及以下两个方案：

方案一：授权文件的校验由单个域控制器DC完成

当授权文件的校验仅由单个域控制器DC完成时，该车辆身份标识Space_Attr可以为该域控制器DC的芯片ID。

可以看出，授权文件的校验由单个域控制器DC完成，可以使得车辆能够快速完成车辆身份标识的校验。

进一步地，该车辆身份标识Space_Attr可以预存在车辆的不可篡改的存储区域中。这样，可以避免其他人恶意篡改该车辆身份标识，保证车辆身份标识在校验过程中的可信度。

示例性地，该车辆身份标识Space_Attr可以熔丝在域控制器DC的芯片的一次性可编程(One Time Programmable，OTP)存储区域中。

这样，在车辆需要将资产信息发送给车云服务器时，可以从域控制器DC的OTP存储区域中读取车辆身份标识Space_Attr，在车辆通过域控制器DC校验授权文件中的车辆身份标识Space_Attr时，可以通过比较域控制器DC的OTP存储区域中存储的车辆身份标识，和授权文件中的车辆身份标识是否一致，来确定车辆身份标识的校验是否通过。

需要注意的是，当升级的部件为电子控制单元ECU时，如果该电子控制单元ECU的安全能力较弱，车辆可以通过该电子控制单元ECU连接的域控制器DC来校验该电子控制单元ECU的升级包对应的授权文件。那么，此时授权文件中的车辆身份标识为该域控制器DC的芯片ID。可以理解的是，如果电子控制单元ECU安全能力较强，电子控制单元ECU的升级包对应的授权文件的校验也可以由其本身完成。本申请实施例对电子控制单元ECU的授权文件的校验部件不做限制。也就是说，车辆身份标识可以用于标识第一部件，该第一部件可以是指升级的部件，也可以是指管理升级部件(例如第二部件)的部件。

方案二：授权文件的校验由多个域控制器DC完成

当授权文件的校验由多个域控制器DC完成时，授权文件中的车辆身份标识Space_Attr可以包括：这多个域控制器DC的芯片ID。

可以看出，当授权文件的校验由多个域控制器DC完成时，只有在确定授权文件中的多个域控制器DC的芯片ID，都与本地这多个域控制器DC的芯片ID一致的情况下，车辆身份标识的校验才算通过，这样可以防止出现对车辆进行恶意换件的攻击场景。

以升级的部件为电子控制单元ECU，校验授权文件的部件为域控制器DC为例，假设车辆A存在待升级的部件ECU1，该部件ECU1的升级包的授权文件，由与其连接的部件DC1进行校验。那么，部件DC1拥有ECU1的升级包和授权文件，车辆B存在部件ECU2以及其连接的部件DC2。其中，部件ECU1和部件ECU2为同一类型的部件，部件DC1和部件DC2为同一类型的部件。在对部件ECU1进行升级前，对部件DC2与部件DC1进行替换，并在车辆B上触发对替换后的部件DC1的授权文件中的车辆身份标识的验证，如果车辆身份标识仅为部件DC1的芯片ID，那么该校验可以通过，车辆B可以在未合法获取升级包的情况下触发对车辆B中的部件ECU2的升级。这就使得攻击者可以利用该漏洞，不按照正规升级方式进行车辆升级，进而影响到车主、软件供应商和车厂的商业利益。

也就是说，使用多个域控制器DC的芯片ID来实现车辆身份标识，可以通过多个域控制器DC的绑定，来避免攻击者对车辆的部件进行替换。例如，车辆身份标识可以用于标识第一部件和第三部件。其中，第一部件可以为升级部件，也可以为管理升级部件(例如第二部件)的部件。

可选的，授权文件中的车辆身份标识Space_Attr可以包括：这多个域控制器DC的芯片ID，以及，这一个或多个域控制器DC生成的验签公钥。

优选的，该授权文件中的车辆身份标识Space_Attr可以包括：这多个域控制器DC的芯片ID，以及，这多个域控制器DC生成的验签公钥。

另外，需要注意的是，在该方案二中，车辆发送给车云服务器的资产信息中的车辆身份标识，与车云服务器返回的授权文件中的车辆身份标识可以不同。具体可参见下面例子中对车辆发送的车辆身份标识和车云服务器返回的车辆身份标识的描述。

下面以授权文件的校验由车辆中的第一域控制器和第二域控制器完成为例，来详细介绍车辆身份标识Space_Attr的实现过程。其中，车辆身份标识Space_Attr主要涉及到车辆的两个相关阶段：整车产线阶段和车辆升级阶段。

在整车产线阶段，主要包括以下步骤：

1)首先通过产线装备工具读取第一域控制器和第二域控制器的芯片ID：socid_one和socid_two。

2)触发第一域控制器和第二域控制器在各自的安全系统环境，例如可信执行环境(Trusted Execution Environment，TEE)中生成一对签名-验签密钥对(pk_one,sk_one),(pk_two,sk_two)。其中，pk_one和sk_one分别为第一域控制器生成的签名-验签密钥对中的验签公钥和签名私钥，pk_two和sk_two分别为第二域控制器生成的签名-验签密钥对中的验签公钥和签名私钥。

3)产线装备工具将第一域控制器和第二域控制器的芯片ID，以及，第一域控制器和第二域控制器生成的验签公钥绑定在一起上传到车云服务器。示例性地，产线装备工具上传的数据包括：socid_one：socid_two，pk_one：pk_two。其中，该数据不仅指示了第一域控制器和第二域控制器的芯片ID，以及，第一域控制器和第二域控制器生成的验签公钥这四个参数，还指示了这四个参数的绑定关系。当车云服务器获取到这四个参数中的一个或多个参数时，可以根据该绑定关系，查找到与这一个或多个参数相关的这四个参数。

在车辆升级阶段，主要包括以下步骤：

1)车辆在发送资产信息时，可以将至少一个域控制器DC的芯片ID(例如第一域控制器的芯片ID，socid_one)作为车辆身份标识，发送给车云服务器。

2)车云服务器在获取到资产信息后，可以根据该至少一个域控制器DC的芯片ID，查找到在整车产线阶段接收到的，包含该域控制器的芯片ID的多个域控制器的芯片ID，以及这多个域控制器生成的验签公钥，即第一域控制器和第二域控制器的芯片ID，以及，第一域控制器和第二域控制器生成的验签公钥。

3)车云服务器将该第一域控制器和第二域控制器的芯片ID，以及，第一域控制器和第二域控制器生成的验签公钥作为车辆身份标识，放入授权文件中，发送给车辆。

4)车辆通过第一域控制器和第二域控制器，校验授权文件中的车辆身份标识。

可以看出，车辆发送的资产信息中的车辆身份标识可以为一个域控制器DC的芯片ID，例如第一域控制器的芯片ID，但车云服务器返回的授权文件中的车辆身份标识为多个域控制器的芯片ID和生成的验签公钥，例如，第一域控制器和第二域控制器的芯片ID，以及，第一域控制器和第二域控制器生成的验签公钥。也就是说，车辆可以仅发送了一个参数，车云服务器便可根据该参数查找到与该参数有关的所有参数，将这所有参数一起返回给车辆。这里，与该参数有关的其他参数可以是指车云服务器存储的与该参数存在绑定关系的所有参数。

下面通过图8详细描述上述车辆升级阶段，步骤4的详细校验过程。

图8为本申请实施例提供的多个域控制器校验授权文件中的车辆身份标识时，域控制器之间的交互流程图。

如图8所示，这多个域控制器以第一域控制器与第二域控制器为例，域控制器之间的交互流程如下：

S301.第一域控制器校验授权文件中，第一域控制器的芯片ID与本地第一域控制器的芯片ID是否一致。

授权文件中包括：第一域控制器和第二域控制器的芯片ID，以及，第一域控制器和第二域控制器生成的公钥。

第一域控制器可以先获取本地第一域控制器的芯片ID，然后比较该本地第一域控制器的芯片ID与授权文件中的第一域控制器的芯片ID是否一致。如果一致，则执行步骤S302。

S302.第一域控制器将授权文件发送给第二域控制器。

S303.第二域控制器校验授权文件中，第二域控制器的芯片ID与本地第二域控制器的芯片ID是否一致。

第二域控制器可以先获取本地第二域控制器的芯片ID，然后比较该本地第二域控制器的芯片ID与授权文件中指示的第二域控制器的芯片ID是否一致。如果一致，则执行步骤S304。

S304.第二域控制器用签名私钥计算授权文件的签名。

该签名私钥为上述整车产线阶段，第二域控制器在安全系统环境下生成的签名-验签密钥对中的签名私钥sk_two。

第二域控制器用签名私钥对授权文件中的参数进行签名，得到该授权文件的签名。

S305.第二域控制器将授权文件的签名发送给第一域控制器。

S306.第一域控制器用授权文件中的第二域控制器的验签公钥校验授权文件的签名。

该验证公钥为上述整车产线阶段，第二域控制器在安全系统环境下生成的签名-验签密钥对中的验签公钥pk_two。第一域控制器可以在授权文件中找到该第二域控制器生成的验签公钥。

第一域控制器校验授权文件的签名，具体为，第一域控制器利用该第二域控制器的验签公钥对授权文件的签名进行校验。

其中，如果签名校验通过，则授权文件中的车辆身份标识的校验通过，否则，授权文件中的车辆身份标识的校验不通过。

可以看出，当授权文件的校验由多个域控制器DC完成，该车辆身份标识的校验可以为多个域控制器的芯片ID的校验，以及对授权文件的签名的校验。

需要注意的是，上述车辆身份标识中使用的第二域控制器的验签公钥，是为了进一步保证第二域控制器向第一域控制器发送给的信息的可信程度。如果域控制器之前的数据传输过程足够安全，则车辆身份标识中可以不涉及公钥。

可以理解的是，当车辆身份标识不包括公钥时，在整车产线阶段，产线装备工具可以仅读取和上传芯片ID，在车辆升级阶段，也可以不涉及利用该公钥，计算授权文件的签名以及利用该签名校验车辆身份标识的过程。

另外，需要注意的是，上述步骤S301-S306仅描述了车辆身份标识所涉及的校验过程，但在实际校验过程中，域控制器除了校验车辆身份标识外，还会校验防重放参数，完整性信息等等，例如，在步骤S301中，第一域控制器除了校验芯片ID之外，还会校验授权文件的签名、完整性信息以及防重放参数等等，在所有校验都通过后，才会执行步骤S302，将授权文件发送给第二域控制器，另外，在步骤S302中，第二域控制器除了校验芯片ID外，还会校验授权文件的签名等等，在所有校验都通过后，才会执行步骤S304。具体关于授权文件的校验过程可以参见前述步骤S107-S108的相关内容，这里不再赘述。

示例性地，该第一域控制器可以为汽车盒子(Telematics BOX，Tbox)，该第二域控制器可以为座舱域控制器(cockpit domaincontroller，CDC)，本申请实施例对该第一域控制器和第二域控制器所对应的车辆中的部件不作限制。当第一域控制器为Tbox，第二域控制器为CDC时，表2示例性示出了本申请实施提供的签名的授权文件的另一种可能的结构。

表2

从表2可以看出，授权文件中的车辆身份标识Space_Attr具体包括：socid_Tbox：socid_CDC以及pk_Tbox：pk_CDC。其中，socid_Tbox为Tbox的芯片ID，socid_CDC为CDC的芯片ID，pk_Tbox为Tbox生成的公钥，pk_CDC为CDC生成的公钥。socid_Tbox：socid_CDC用于表示Tbox和CDC的芯片ID的绑定关系，pk_Tbox：pk_CDC用于表示Tbox和CDC的公钥的绑定关系。

另外，关于授权文件中的Time_Attr、Integrity_Attr、Sig(sk,M)和pk&pk_validity_proof的描述可以参见前述表1的相关内容，这里不再赘述。

可以理解的是，表2所示的签名的授权文件的结构只是示例性举例，不构成对授权文件的限制。另外，上面以两个域控制器为例描述了车辆身份标识Space_Attr的具体实现过程，但是本申请实施例对校验授权文件涉及到的域控制器的数量不做限制，例如，当授权文件的校验由三个域控制器完成时，车辆身份标识Space_Attr可以包括这三个域控制器的芯片ID的绑定关系，以及，这三个域控制器生成的公钥的绑定关系。

下面详细介绍防重放参数的具体实现过程。

防重放参数Time_Attr用于唯一标识一次升级。车辆在升级时，可以通过校验该防重放参数Time_Attr，来防止攻击者利用老版本的升级包来升级车辆。

方案一：利用重放保护存储分区(Replay Protected MemoryBlock，RPMB)设置防重放参数Time_Attr

RPMB是一个具有安全特性的存储分区，当存在数据写入RPMB时，会校验数据的合法性，只有指定的发送方才能够写入数据，同时在读数据时，也提供了签名机制，保证对方读取到的数据是RPMB的内部数据，而不是攻击者伪造的数据。因此，在RPMB实际应用中，通常用于存储一些有防止非法篡改需求的数据。

在本申请实施例中，可以将该防重放参数Time_Attr存储在域控制器的RPMB中。

其中，该防重放参数Time_Attr可以有以下两种设计方式：

1)利用随机数来设置防重放参数Time_Attr

为了避免车辆在升级时，再次根据已升级过的版本进行升级，在车辆升级过程中，车辆和车云服务器可以预定一个“暗号”，在车辆校验防重放参数Time_Attr时，只有“暗号”一致，防重放参数Time_Attr的校验才通过。

这时，防重放参数Time_Attr可以是一个随机数nonce，且该随机数为一个仅一次有效的数，该仅一次有效是指车辆在每次升级生成该防重放参数Time_Attr时，该随机数nonce都不同，即每一次生成的防重放参数Time_Attr都唯一代表了一次升级。例如，车辆和车云服务器在某一次升级时约定了一个随机数A，只有在此次升级时，车云服务器向车辆发送的防重放参数Time_Attr为该随机数A时，该防重放参数Time_Attr的校验才通过。

那么，在前述步骤S103-S114中，关于防重放参数Time_Attr主要涉及到以下实现过程：

a)在车辆向车云服务器发送资产信息之前，车辆可以在安全系统环境，例如TEE环境中，随机生成一个字符串nonce，并将该字符串nonce作为防重放参数Time_Attr写入RPMB中。

b)在车辆发送资产信息时，车辆将该nonce作为防重放参数Time_Attr随资产信息发送给车云服务器。

c)在车云服务器获取到该nonce后，将该nonce作为授权文件中的防重放参数Time_Attr，发送给车辆。

d)在车辆校验授权文件的过程中，车辆在获取到该授权文件中的防重放参数Time_Attr后，从本地的RPMB中读取防重放参数Time_Attr，并判断该授权文件中的防重放参数Time_Attr与本地的防重放参数Time_Attr是否一致。如果该授权文件中的防重放参数Time_Attr与本地的防重放参数Time_Attr一致，则防重放参数的校验通过，否则，防重放参数的校验不通过。

具体关于步骤S103-S114的详细描述可以参见前述图4的相关内容，这里不再赘述。

可以理解的是，上面仅详细描述了远端升级场景中，防重放参数Time_Attr的具体实现过程，在近端升级场景中，防重放参数Time_Attr的具体实现过程与远端升级场景类似，不同的是，在近端升级场景中，车辆和车云服务器通过诊断终端中转资产信息、签名的升级包和授权文件，而远端升级场景中，车辆和车云服务器直接交互，不涉及诊断终端的中转。具体关于近端升级场景中，防重放参数Time_Attr的具体实现过程可以参考前述远端升级场景中，防重放参数Time_Attr的具体实现过程以及前述步骤S203-S217，这里不再展开。

另外，需要注意的是，上述实现过程中，防重放参数Time_Attr由车辆来生成，在本申请其他实施例中，该防重放参数Time_Attr也可以由车云服务器生成，并发送给车辆，本申请实施例对利用随机数来设置防重放参数Time_Attr时，生成该防重放参数Time_Attr的设备不作限制。

2)利用计数器来设置防重放参数Time_Attr

为了避免车辆在升级时，再次根据已升级过的版本进行升级，在车辆升级过程中，车辆与车云服务器可以约定一个计数器，该计数器的数值可以根据升级包的版本进行单向递增，车辆与车云服务器可以将该计数器的数值作为防重放参数，在车辆校验防重放参数的过程中，如果车辆接收到的防重放参数与本地的防重放参数不一致，则说明车云服务器发送的升级包的版本与车辆升级所需的升级包的版本不符合。

这时，防重放参数Time_Attr是一个单向递增的数值，示例性地，每次递增的数值为1。例如，当车辆进行第5次升级时，该防重放参数Time_Attr可以为5，当车辆进行第6次升级时，该防重放参数Time_Attr可以为6。其中，在车辆进行第6次升级时，如果车辆接收到的防重放参数Time_Attr为5，则说明车云服务器发送给的升级包可能是车辆在进行第5次升级时，发送的升级包，该防重放参数Time_Attr的校验不通过。

该计数器的数值的更改可以存在以下两种情况：

情况1：车辆每升级一个版本更改一次计数器的数值

这种情况下，车辆每升级一次，计数器的数值就会加1。这样，车辆每升级一个版本的升级包都会对应一个防重放参数，且不同版本的防重放参数不一致。例如，假设车辆升级V7版本的升级包时，防重放参数为7，如果车云服务器发送的防重放参数为6，则车云服务器发送的升级包可能是V6版本的升级包，即为老版本的升级包，则车辆判断防重放参数的校验不通过，车辆取消升级。

这样，可以避免车辆用老版本的升级包升级车辆，保证车辆每次升级都与之前的升级不同。

示例性地，下面结合图9描述情况1中，利用计数器来保障防重放的原理。

图9为本申请实施例提供的一种车辆升级的时序图。

如图9所示，车辆在时间点T1、T2、T3分别使用升级包V1、V2、V3成功进行了一次升级，每一次升级，计数器的数值都会加1，假设T1时刻之前防重放参数为0，那么，T1、T2、T3车辆能够成功进行升级，是因为车辆在T1时刻接收到的授权文件1、T2时刻接收到的授权文件2、T3时刻接收到的授权文件3中的防重放参数分别为0、1、2。

以此类推，在T4时刻再次进行升级时，此时车辆本地的防重放参数为3。可以看出，如果T4时刻再次接收到T1时刻发送过的授权文件1和升级包V1时，由于授权文件1中的防重放参数为0，与本地的防重放参数不一致，所以车辆不会使用升级包V1进行升级，避免了车辆再次使用老版本升级包进行升级，而如果T4时刻，车辆接收到授权文件4中的防重放参数为3，则车辆可以使用该升级包V4进行升级。

可以看出，通过每次升级更改一次计数器的数值，可以避免车辆在每次升级时，使用老版本的升级包进行升级。

情况2：车辆升级过一个有漏洞的版本后更改一次计数器的数值

这种情况下，车辆只有在升级到有漏洞的版本时，计数器的数值才会加1。这样，虽然车辆每升级一个版本的升级包都会对应一个防重放参数，但是不同版本的防重放参数可能一致，只有在车辆某一次升级过有漏洞的版本时，该防重放参数才会发生更改。

其中，车辆更改计数器的数值可以由车云服务器触发。具体的，当车云服务器检测到车辆升级过一个有漏洞的版本，向车辆发送调整指令，车辆可以根据该调整指令触发更改技计数器的数值，例如，计数器的数值加1。

这样，车辆只有在升级过有漏洞的版本时才更改计数器的数值，可以降低计数器的数值的更改频率。

示例性地，下面结合图10来描述情况2中，利用计数器来保障防重放的原理。

图10为本申请实施例提供的另一种车辆升级的时序图。

如图10所示，车辆在时间点T1、T2、T3分别使用升级包V1、V2、V3成功进行了一次升级，且每次升级的授权文件中的防重放参数都为0。当T4时刻发现车辆在T2时刻升级的升级包V2存在安全漏洞时，车辆会将计数器的数值加1。

也就是说，在T5时刻再次进行升级时，此时车辆本地的防重放参数为1。可以看出，如果T5时刻再次接收到T2时刻发送过的授权文件2和升级包V2时，由于授权文件2中的防重放参数为0，与本地的防重放参数不一致，所以车辆不会使用升级包V2进行升级，避免了车辆再次使用老版本升级包进行升级，而如果T5时刻，车辆接收到授权文件4中的防重放参数为1，则车辆可以使用该升级包V4进行升级。

可以看出，通过在发现车辆升级过存在漏洞的升级包后更改计数器的数值，可以在发现有漏洞的版本后，避免车辆使用老版本的升级包进行升级。

类似于前述利用随机数来设置防重放参数Time_Attr，在利用计数器来设置防重放参数Time_Attr时，车辆可以在向车云服务器发送资产信息之前，确定该计数器的数值，并将该数值作为防重放参数Time_Attr写入RPMB中，之后将该数值作为防重放参数Time_Attr随资产信息发送给车云服务器，再接收到车云服务器发送的授权文件，校验授权文件中的防重放参数Time_Attr。具体关于利用计数器来设置防重放参数Time_Attr时，防重放参数Time_Attr的实现过程可以参考前述利用计数器来设置防重放参数Time_Attr时，防重放参数Time_Attr的实现过程，以及前述步骤S103-S114和步骤S203-S217的相关内容，这里不再展开。

需要注意的是，当利用计数器来设置防重放参数Time_Attr时，车辆也可以不用向车云服务器发送防重放参数Time_Attr。也就是说，在步骤S103以及步骤S203中提及的资产信息中也可以不包括防重放参数Time_Attr。这是由于如果车辆和车云服务器都约定使用计数器来设置防重放参数Time_Attr，即在何种情况下更改计数器的值，以及计数器的初始值，则车辆和车云服务器可以根据车辆的升级情况，自行在本地确定该防重放参数Time_Attr。例如车辆和车云服务器约定每升级一个版本时更改一次计数器的数值，并且初始值为0，则车辆第三次升级时，车辆和车云服务器可以自行确定当前的防重放参数Time_Attr为3。

另外，由于车辆中某些域控制器DC不具备RPMB，因此当授权文件的校验由多个域控制器DC完成时，该域控制器可以利用其它具备域控制器DC中的RPMB开设置防重放参数Time_Attr，这样，克服了某些域控制器DC不具备RPMB，无法使用RPMB来设置防重放参数Time_Attr的缺陷。

并且，需要注意的是，防重放参数Time_Attr由生成该防重放参数Time_Attr的域控制器校验。例如，第一域控制器利用第二域控制器来设置第一域控制器所需的防重放参数Time_Attr，即第一域控制器获取第二域控制器设置的防重放参数Time_Attr，第一域控制器设置资产信息中的其他参数，例如车辆身份标识后，并将该防重放参数Time_Attr随资产信息发送给车云服务器，之后，在校验授权文件时，第一域控制器完成除防重放参数Time_Attr之外的其他参数的校验，之后，再将授权文件发送给第二域控制，由第二域控制器校验该防重放参数Time_Attr。

方案二：利用非易变计数器(Non-Volatile Counter，NV-Cnt)设置防重放参数Time_Attr

由于NV-Cnt可以生成单方向依次递增的数值，且该数值的更改由熔断机制保证，其数值大小不能够随意篡改。因此可以在NV-Cnt中存放计数器的数值，将该数值作为防重放参数Time_Attr。这样可以保证防重放参数的不可篡改性，保障防重放参数的校验过程的可信度。其中，熔断机制是通过熔断芯片中的熔丝位，一次性且不可逆的更改熔丝位的状态，从而保证数据存储后的不可篡改。具体关于利用计数器来设置防重放参数Time_Attr的描述可以参考前述方案一利用设置防重放参数Time_Attr的相关内容，这里不再展开。

示例性地，可以预留车辆芯片的OTP中的固定位域，例如32bit，作为设置防重放参数Time_Attr的NV-Cnt，示例性地，NV-Cnt的初始数值为0。本申请实施例对NV-Cnt的初始数值不做限制。

下面详细描述利用NV-Cnt设置防重放参数Time_Attr的具体实现过程。

1)车云服务器和车辆约定NV-Cnt的初始值为0，并将该NV-Cnt的数值作为防重放参数Time_Attr。

2)当车云服务器检测到本车辆或其他车辆升级的升级包中存在有安全漏洞的版本，则车云服务器对车辆发送调整指令，该调整指令用于更改NV-Cnt的数值，例如使NV-Cnt的数值加1。

3)车辆在获取到该调整指令后，更改NV-Cnt的数值，例如由3更改为4。

4)在车辆发送资产信息时，车辆将该更改后的NV-Cnt的数值作为防重放参数Time_Attr，随资产信息发送给车云服务器。

5)车云服务器再将该NV-Cnt的数值作为防重放参数Time_Attr，随授权文件发送给车辆。

6)车辆在获取到该授权文件中的防重放参数Time_Attr后，从本地的NV-Cnt中读取防重放参数Time_Attr，并判断该授权文件中的防重放参数Time_Attr与本地的防重放参数Time_Attr是否一致。如果该授权文件中的防重放参数Time_Attr与本地的防重放参数Time_Attr一致，则防重放参数的校验通过，否则，防重放参数的校验不通过。

需要注意的是，利用NV-Cnt来设置防重放参数Time_Attr时，同样存在上述方案一中计数器数值更改的两种情况：车辆每升级一个版本更改一次计数器的数值，以及，车辆升级过一个有漏洞的版本后更改一次计数器的数值。其中，由于NV-Cnt的数值更改由硬件机制保障，其数值的更改不可逆，而V-Cnt的位数是固定的，因此NV-Cnt的数值更改次数是有限的。例如，32bit的NV-Cnt支持最多熔断32次，即NV-Cnt最多仅能支持更改32次数值。可以看出，在车辆升级过一个有漏洞的版本后更改一次计数器的数值，可以减少NV-Cnt的数值的更改次数，能够尽可能的延长芯片的使用时长，避免车辆的频繁换件。

另外，安全启动场景下的授权文件的校验，相比于方案一，利用方案二来设置防重放参数Time_Attr，能够提高车辆的检测效率。这是由于部件的安全启动为启动链中各软件的逐级校验过程，而RPMB在启动链的后期才能够校验到，因此无法保护启动链的前端的安全，校验效率较低，通过NV-Cnt设置的防重放参数Time_Attr，可以保护启动链的前端的安全，提高校验效率。

方案三：结合RPMB和NV-Cnt设置防重放参数Time_Attr

当结合RPMB和NV-Cnt设置防重放参数Time_Attr时，可以通过RPMB设置一个随机数，通过NV-Cnt设置计数器，并将该随机数和计数器的数值作为防重放参数Time_Attr。

那么，防重放参数Time_Attr可以包括：域控制器DC的RPMB中存放的随机数nonce，以及，该域控制器DC中的NV-Cnt的数值。

示例性地，以域控制器DC为CDC为例，表3示例性示出了本申请实施例提供的签名的授权文件的另一种可能的结构。

表3

从表3可以看出，授权文件中的防重放参数Time_Attr具体包括：NV-Cnt_CDC、nonce_CDC。其中，NV-Cnt_CDC为CDC的NV-Cnt中的数值，nonce_CDC为CDC生成的随机数。

另外，关于授权文件中的Space_Attr、Integrity_Attr、Sig(sk,M)和pk&pk_validity_proof的描述可以参见前述表1的相关内容，这里不再赘述。

可以理解的是，表3所示的签名的授权文件的结构只是示例性举例，不构成对授权文件的限制。

另外，需要注意的是，当升级的部件为电子控制单元ECU时，由于电子控制单元ECU对应的授权文件的校验可以由其连接的域控制器DC来进行校验，那么防重放参数的设置可以由该域控制器DC来完成。也就是说，电子控制单元ECU对应的授权文件中的防重放参数，由其连接的域控制器DC生成得到。

总的来说，防重放参数为车云服务器与车辆约定的用于标识车辆本地的升级的参数，其中，该防重放参数可以随着车辆每次升级而更新，那么这是防重放参数仅用于标识的一次升级，防重放参数还可以不定期更新，这种情况下，防重放参数可以在预设情况下更新，例如车云服务器发现了已经发送的老版本升级包存在漏洞时，通知车辆跟随车云服务器同步更新防重放参数。

下面详细介绍完整性信息的具体实现过程。

完整性信息Integrity_Attr用于唯一标识此次升级，车云服务器发送的升级包。

在车辆升级阶段，该授权文件中完整性信息Integrity_Attr可用于唯一标识车云服务器发送的升级包。也就是说，当车辆接收到升级包和该升级包的授权文件时，车辆可以通过校验该完整性信息Integrity_Attr来确定该授权文件，是否为车辆接收到的升级包的授权文件，或者，换句话说，确定车辆接收到的升级包是否完整或被篡改。这样，可以避免攻击者伪造升级包，用假冒的升级包来进行车辆升级，保证车辆升级的安全性。

在安全启动阶段，该授权文件中的完整性信息Integrity_Attr可用于唯一标识车辆按照车云服务器发送的升级包升级后，车辆升级后的软件数据。换句话说，当车辆接收到升级包和该升级包的授权文件，并按照该升级包升级后，车辆可以在安全启动时，通过校验该完整性信息Integrity_Attr，来确定车辆的数据是否为根据该升级包升级后的软件数据。这样，可以防止车辆升级后，攻击者直接拆机，将升级包非法导入车辆部件，更改车辆部件的软件数据。

由于车辆的升级方式不同时，完整性信息Integrity_Attr包含的内容不同。下面按照车辆不同的升级方式，来介绍完整性信息Integrity_Attr。

方案一：全量升级

全量升级是指车辆升级时，通过下载完整的软件数据，直接将下载完成的软件数据搬运到软件运行的位置，来实现车辆的升级。

也就是说，全量升级时，车云服务器发送的升级包中包含部件升级后的完整的数据。

这种情况下，完整性信息Integrity_Attr可以包括升级包的哈希值Hash[]，该哈希值为对该升级包使用哈希算法计算得到哈希值。

方案二：差分升级

差分升级是指车辆升级时，通过下载与老版本软件数据存在差异的增量部分，再利用算法，根据该增量部分合成升级版本的软件数据，再将其搬运到软件运行的位置，来实现车辆的升级。

也就是说，差分升级时，车云服务器发送给的升级包中只包含部件升级前后存在差异的软件数据。这时，车云服务器发送的升级包还可以被称为差分包。

这种情况下，完整性信息Integrity_Attr可以包括：升级包的哈希值Hash_diff[]，镜像文件的哈希值Hash_full[]。

其中，Hash_diff[]为对升级包使用哈希算法计算得到的哈希值。该升级包的哈希值Hash_diff[]为车辆在车辆升级阶段，校验授权文件时，校验的完整性信息。镜像文件的哈希值Hash_full[]为对部件升级所需的完整的软件数据使用哈希算法，计算得到的哈希值。该镜像文件的哈希值Hash_full[]为车辆在安全启动阶段，校验授权文件时，校验的完整性信息。

也就是说，当车辆的升级方式为差分升级时，车云服务器给车辆发送的授权文件中包含两个完整性信息，在车辆升级阶段和安全启动阶段分别校验不同的完整性信息。

在本申请实施例中，镜像文件的哈希值Hash_full[]还可以被称为第二完整性信息。

方案三：A/B升级

A/B升级的前提是车辆存在两套系统，A/B升级是指在升级过程中，保证一个系统正常运行，升级另一个系统。

这种情况下，完整性信息Integrity_Attr可以包括：升级包的哈希值Hash_update[]，回滚文件的哈希值Hash_rollback[]。

其中，升级包的哈希值Hash_update[]为对升级包使用哈希算法计算得到的哈希值。该升级包的哈希值Hash_diff[]用于在车辆升级阶段和安全启动阶段，校验授权文件时，校验的完整性信息。回滚文件的哈希值Hash_rollback[]为结合当前车辆的数据和升级后的数据，计算得到的哈希值。该回滚文件包含车辆部件升级失败后，回滚到原版本时，部件中包含的数据。该回滚文件的哈希值Hash_rollback[]用于在车辆升级失败后，对车辆中的数据的校验。

具体地，在车云服务器接收到资产信息后，车云服务器可以根据资产信息终端的软硬件信息来确定车辆的升级方式，从而确定需要向车辆发送给的完整性信息。

在本申请实施例中，回滚文件的哈希值Hash_rollback[]还可以被称为第三完整性信息。

另外，针对升级的不同部件，完整性信息Integrity_Attr的表现形式也不同。下面结合两个方案来介绍完整性信息Integrity_Attr。

方案一：对整个升级包计算哈希值

这时，完整性信息Integrity_Attr可以是指对整个升级包使用哈希算法，计算得到的一个数值。

该方案适用于升级的部件为域控制器DC连接的电子控制单元ECU。

这种对整个升级包计算哈希值的方法，能够加快完整性信息的校验。在车辆升级阶段，车辆只需在校验授权文件时，计算升级包的哈希值，判断该哈希值与授权文件中的完整性信息是否一致，即可确定完整性信息的校验是否通过。在车辆部件升级之后的安全启动阶段，车辆只需在校验授权文件时，计算车辆部件的整个软件的哈希值，判断该哈希值与授权文件中的完整新信息是否一致，即可确定完整性信息的校验是否通过。

方案二：对升级文件计算哈希值

这时，完整性信息Integrity_Attr可以是指对升级包中包含的多个升级文件使用哈希算法，计算得到的多个哈希值。也就是说，完整性信息Integrity_Attr表现为一个数组，其中包含多个数值。

该方案适用于升级的部件为域控制器DC。

这种对升级文件计算哈希值的方法，能够升级包的完整性校验更加精准，车辆能够根据这多个哈希值，更加准确的得知在传输升级包过程中，升级包中遭到篡改的部分，或者，在车辆启动阶段，部件中遭到篡改的软件部分。

也就会说，完整性信息可以包括一个或多个参数，这一个或多个参数可以用于标识升级包。

另外，在实际情况中，可以将车辆的升级方式以及车辆升级的部件来综合设置完整性信息Integrity_Attr。例如，当车辆的升级方式为全量升级，升级的部件为电子控制单元ECU，则完整性信息Integrity_Attr为对该部件的整个升级包计算得到的哈希值。又例如，当车辆的升级方式为差分升级，升级的部件为域控制器DC，则完整性信息Integrity_Attr可以包括升级包中的多个升级文件的哈希值，以及，升级后的多个完整镜像文件的哈希值。

下面详细介绍用于验证授权公钥合法的合法性证明的具体实现过程。

由于授权文件的签名是利用车云服务器生成的授权私钥进行加密得到的，而签名的校验也是通过车云服务器提供的授权公钥来实现的，为了防止攻击者通过伪造该授权私钥和授权公钥来篡改授权文件，需要车云服务器在提供用于校验签名的授权公钥时，存在能够校验该授权公钥的合法性的校验机制。

也就是说，在车辆触发对授权文件的校验之前，例如步骤S113之前，可以先校验授权公钥的合法性。

下面提供了两种校验机制，来实现对授权公钥的合法性证明。

方案一：车辆在芯片中预存用于校验授权文件签名的授权公钥的哈希值

示例性地，车辆可以在芯片的OTP中预留熔丝位，用于存储校验授权文件签名的授权公钥的哈希值。可以看出，在OTP中存储该授权公钥的哈希值可以避免攻击者篡改车辆本地存储的授权公钥的哈希值，保证校验授权公钥的合法性时，校验机制的可信度。

具体地，在车辆获取到授权文件时，可以利用哈希算法计算授权文件中的授权公钥的哈希值，然后将该哈希值，与车辆本地预存的用于校验授权文件签名的授权公钥的哈希值进行比较，如果两者一致，则说明授权文件中的授权公钥合法，没有被篡改，否则，则说明授权文件中的授权公钥不合法。

可以看出，在这种情况下，授权文件中可以不包含授权公钥的合法性证明pk_validity_proof。

方案二：复用校验编包签名的公钥

车云服务器在生成用于加密和校验授权文件签名的密钥对后，可以将该密钥对中的授权公钥发送给供应商服务器，供应商服务器利用生成编包签名的私钥对该授权公钥进行加密，得到该授权公钥的签名，并将该签名发送给车云服务器。这样，在车辆得到授权文件中的授权公钥和该授权公钥的签名时，可以通过用于校验编包签名的公钥来校验该授权公钥的合法性。

这时，授权公钥的合法性证明可以为供应商服务器利用生成编包签名的私钥，对该授权公钥进行数字签名时得到的签名。在本申请实施例中，供应商服务器利用生成编包签名的私钥，得到的授权文件的签名还可以被称为第二签名。

具体地，车辆在获得授权文件之后，可以计算授权文件中的授权公钥的消息摘要，并利用用于解密编包签名的公钥对授权文件中的授权公钥的合法性证明进行解密，得到一个消息摘要，车辆可以通过比较该消息摘要，与计算得到的授权文件中的授权公钥的消息摘要是否一致，来确定授权文件中的消息摘要是否未被篡改，如果两者一致，则说明授权文件中的授权公钥合法，没有被篡改，否则，则说明授权文件中的授权公钥不合法。

当编包签名是供应商服务器采用多级密钥对升级文件签名得到的，采用方案二来设置授权公钥的合法证明时，还需要额外包括以下内容：

1)规定授权公钥的用途，或，采用多级密钥设置授权公钥的签名

当供应商服务器采用三级密钥来实现升级包中的编包签名，那么，车云服务器可以自行生成密钥对来伪造该升级包中的编包签名，从而造成供应商服务器和车云服务器的签名能力的混淆。

由于编包签名为供应商服务器采用三级密钥对升级文件签名得到的，则车辆在校验编包签名时，需要校验三次，才能最终完成编包签名的校验。具体可以参见前述步骤S115中的相关内容。

假设授权公钥的合法性证明为供应商服务器利用三级密钥中的编包根私钥，对该授权公钥进行的签名。则车云服务器可以自行在授权公钥和授权私钥的下一级生成一对密钥，并使用该密钥对中的私钥对升级包进行签名，在车辆对该签名进行校验时，同样可以实现车辆校验三次的效果，且对该签名的校验和对供应商服务器生成编包签名的校验，都是从校验供应商服务器生成的编包根公钥开始。可以看出，车云服务器能够伪造编包签名的可能性，降低了编包签名的校验的可信度。

因此，可以通过规定授权公钥的用途，或，采用多级密钥设置授权公钥的签名，来实现供应商服务器和车云服务器的签名能力的区分。

其中，规定授权公钥的用途是指，车云服务器在向车辆发送授权公钥时，还包括该授权公钥的用途信息，该用途信息用于指示该授权公钥仅能用于校验授权文件的签名，从而从公钥用途上区分开供应商服务器和车云服务器的签名能力。示例性地，该用途信息可以存储在usage字段中。采用多级密钥设置授权公钥的签名时，校验该授权公钥的签名时，其校验次数应大于校验编包签名时的校验次数，从而从校验次数上区分开供应商服务器和车云服务器的签名能力。

图11为本申请实施例提供的采用多级密钥设置授权公钥的签名时，供应商服务器和车云服务器之间的交互流程图。

如图11所示，供应商服务器和车云服务器之间的交互流程包括：

S401.车云服务器将授权公钥发送给供应商服务器。

授权公钥为车云服务器生成的用于校验授权文件的签名的公钥。其中，授权文件的签名对车云服务器利用授权私钥对授权文件进行签名得到的。具体关于该授权公钥的描述可以参见前述内容，这里不再赘述。

S402.供应商服务器生成N对密钥。

当供应商服务器采用多级密钥实现编包签名，假设供应商服务器采用M级密钥实现编包签名，其中，M≥2，且M为正整数。

为了实现供应商服务器和车云服务器的签名能力的区分，N≥M-1，且N为正整数。例如，当M＝3，则供应商服务器采用三级密钥实现编包签名，则N可以取2，即供应商服务器可以生成2对密钥。又例如，当M＝4，则供应商服务器采用四级密钥实现编包签名，则N可以取4，即供应商服务器可以生成4对密钥。

S403.供应商服务器利用编包根私钥、该N对密钥实现对授权公钥的签名。

编包根私钥为实现编包签名时，采用的多级密钥中的第一层级的私钥。

具体地，该N对密钥可以包括：第1公钥和第1私钥、第2公钥和第2私钥、……、第N公钥和第N私钥。

当供应商服务器利用编包根私钥、该N对密钥实现对授权公钥的签名时，供应商服务器可以利用编包根私钥对第1公钥进行签名，得到第1公钥的签名、利用第1私钥对第2公钥进行签名，得到第2公钥的签名、……、利用第N私钥对授权公钥进行签名，得到授权公钥的签名，从而实现利用多级密钥设置授权公钥的签名。

下面以一个具体了例子来描述供应商服务器利用编包根私钥、该N对密钥实现对授权公钥的签名。

其中，假设M＝3、N＝2。即供应商服务器采用三级密钥实现编包签名，生成2对密钥用于授权文件的签名。

示例性地，图12为本申请实施例提供的多级密钥的结构示意图。

其中，图12中所示的编包根公钥和编包根私钥、编包二层公钥和编包二层私钥、编包三层公钥和编包三层私钥为供应商服务器生成的三级密钥，这三级密钥用于完成升级包中的升级文件的编包签名。

可以看出，在校验编包签名时，需要完成编包根公钥校验编包二层公钥的签名，编包二层公钥校验编包三层公钥的签名，编包三层公钥校验软件数据的编包签名这三次校验过程。具体关于这三级密钥的描述可以参见前述步骤S101和步骤S115的相关内容，这里不再赘述。

另外，图12所示的一车一授权公钥和一车一授权私钥、授权根公钥和授权根私钥为供应商服务器生成的用于实现授权文件的签名的2对密钥。

具体地，供应商服务器可以利用编包根私钥对一车一授权公钥进行签名，得到一车一授权公钥的签名，利用一车一授权私钥对授权根公钥进行签名，得到授权根公钥的签名，利用授权根私钥对授权公钥进行签名，得到授权公钥的签名。

可以看出，在校验授权文件的签名时，需要完成编包根公钥校验一车一授权公钥的签名，一车一授权公钥校验授权根公钥的签名，授权根公钥校验授权公钥的签名，授权公钥校验授权文件的签名这四次校验过程。这样即可避免车云服务器自行生成密钥对来伪造该升级包的编包签名的问题。

S404.供应商服务器将该授权公钥的签名发送给车云服务器。

供应商服务器可以将该授权公钥的签名作为该授权公钥的合法性证明发送给车云服务器，从而实现了复用校验编包签名的公钥，来验证授权公钥合法的目的。

2)对不同车云服务器的授权公钥进行区分

应理解，由于车辆厂商通常存在多家，不同车辆厂商的服务器可以完成车辆的升级。例如，车辆厂商A(以下简称车厂A)生产的车辆可以通过车厂A的服务器(以下简称车云服务器A)获取升级包，完成升级，车辆厂商B(以下简称车厂B)生产的车辆可以通过车厂B的服务器(以下简称车云服务器B)获取升级包，完成升级。

图13为本申请实施例提供的供应商服务器对多个车云服务器的授权公钥进行签名的逻辑示意图。

如图13所示，存在车云服务器A和车云服务器B通过供应商服务器对授权公钥进行签名。其中，供应商服务器使用密钥生成器Kg(1ⁿ)生成一对密钥(pk,sk)，其中，sk为用于对升级文件x进行编包签名Sig(sk,x)的编包私钥，pk为用于校验编包签名σ_x的编包公钥。车云服务器A使用密钥生成器Kg(1ⁿ)生成一对密钥(pk_A,sk_A)，其中，sk_A为用于对授权文件auth_doc_A进行签名Sig(sk_A,auth_doc_A)的授权私钥，pk_A为用于校验授权文件auth_doc_A的签名σauth_doc_A的授权公钥，车云服务器B使用密钥生成器Kg(1ⁿ)生成一对密钥(pk_B,sk_B)，其中，sk_B为用于对授权文件auth_doc_B进行签名Sig(sk_B,auth_doc_B)的授权私钥，pk_B为用于校验授权文件auth_doc_B的签名σauth_doc_B的授权公钥。

车云服务器A可以将pk_A发送给供应商服务器，供应商服务器可以使用sk对该pk_A进行签名，即Sig(sk,pk_A),得到pk_A的签名σ_A，并将其返回给车云服务器A。

车云服务器B可以将pk_B发送给供应商服务器，供应商服务器可以使用sk对该pk_B进行签名，即Sig(sk,pk_B),得到pk_B的签名σ_B，并将其返回给车云服务器B。

从图13可以看出，针对供应商服务器提供的同一个升级文件，车云服务器A的授权公钥和车云服务器B的授权公钥的合法性都是由供应商服务器提供的同一个公钥来保证的。

也就是说，车厂A生产的车辆升级时，不仅车云服务器A提供的授权文件中的授权公钥能够通过合法性证明，车云服务器B提供的授权文件中的授权公钥也能够通过合法性证明。

那么，如果车厂B的授权私钥被攻击者窃取，进而伪造授权文件的签名，利用伪造的授权文件来攻击车厂A生产的车辆，容易造成车厂A的商业利益受到牵连。

对不同车辆厂商的车云服务器的授权公钥进行区分，就是为了避免部分车辆厂商的车云服务器的授权私钥丢失，而连带影响到其他车辆厂商。也就是说，在车辆在获取到授权文件后，可以先判断授权文件中的授权公钥的生成方是否为目标车厂，来决定是否用该授权公钥来校验授权文件的合法性。

示例性地，车辆厂商可以利用黑/白名单来设置该目标车厂，其中，白名单中的车厂生成的授权公钥，为允许用来校验授权文件的公钥，黑名单中的车厂生成的授权公钥，为不允许用来校验授权文件的公钥。

例如，当车辆厂商利用白名单来设置目标车厂时，车辆厂商可以在车辆校验授权文件之前，提前将白名单发送给车辆，车辆在校验授权文件的合法性之前，先判断该授权公钥的生成方是否为白名单中的车厂，如果是，则车辆可以使用该授权公钥校验授权文件的合法性，否则，车辆不可以使用该授权公钥校验授权文件的合法性。

另外，为了避免攻击者伪造黑/白名单，车辆厂商在提供黑/白名单之前，可以将黑/白名单发送给供应商服务器，由供应商服务器生成的密钥对设置该黑/白名单的签名。进一步地，供应商服务器可以利用多级密钥来设置该黑/白名单的签名。

下面以一个具体的例子来描述供应商服务器利用多级密钥来设置该黑/白名单的签名。

假设供应商服务器利用三级密钥来设置白名单，存在车厂服务器A生成的授权公钥A和授权私钥A，车厂服务器B生成的授权公钥B和授权私钥B，以及车厂A的白名单A，车厂B的白名单B，白名单A中列举的车厂的授权公钥，为车厂A生产的车辆允许用来校验授权文件的公钥，白名单B中列举的车厂的授权公钥，为车厂B生产的车辆允许用来校验授权文件的公钥。

示例性地，图14为本申请实施例提供的另一种多级密钥的结构示意图。

如图14所示，授权公钥A和授权私钥A/>为车厂服务器A生成的密钥对，授权公钥B/>和授权公钥B/>为车厂服务器B生成的密钥对，编包根公钥(pk₁)和编包根私钥(sk₁)、一车一授权公钥(pk₂)和一车一授权私钥(sk₂)、授权根公钥/>和授权根私钥/>为供应商服务器生成的用来设置车厂服务器A的授权公钥A和车厂服务器B的授权公钥B的签名的密钥对，具体关于这些密钥对的描述可以参见前述图8的相关内容，这里不再赘述。

另外，为了设置白名单的签名，供应商服务器还可以生成一对密钥：许可公钥和许可私钥/>并利用一车一授权私钥对许可公钥进行签名，得到许可公钥的签名，利用许可私钥对白名单A和白名单B进行签名，得到白名单A的签名和白名单B的签名。

车厂服务器可以向车辆发送许可列表，该许可列表中可以包括：车辆厂商设置的白名单，以及该白名单的签名。示例性地，表4示出了授权文件A的结构，表5示出了授权文件B的结构，表6示出了车厂服务器A发送的许可列表A的结构，表7示出了车厂服务器B发送的许可列表B的结构。

表4

其中，授权文件A可以包括三个部分：属性域M₁、签名域和授权公钥域。其中，属性域M₁中可包括：车辆身份标识Space_Attr1、防重放参数Time_Attr1、完整性信息Integrity_Attr1。签名域中包括车云服务器A用自己的授权私钥对属性域M₁计算得到的签名/>授权公钥域中包括：授权公钥/>以及，用于验证/>的合法性的多个参数，这多个参数包括：多个公钥和公钥的签名，即，编包根公钥(pk₁)，一车一授权公钥pk₂,一车一授权公钥pk₂的签名Sig(sk₁,pk₂),授权根公钥/>授权根公钥/>的签名授权公钥/>的签名/>其中，授权公钥/>用于校验签名授权根公钥/>用于校验签名/>一车一授权公钥pk₂用于校验签名编包根公钥(pk₁)用于校验签名Sig(sk₁,pk₂)。

具体关于属性域的描述可以参见前述表1的相关内容，具体关于pk₁，pk₂,的描述可以参见图13的相关内容。

表5

其中，授权文件B可以包括三个部分：属性域M₂、签名域和授权公钥域。其中，属性域M₂中可包括：车辆身份标识Space_Attr2、防重放参数Time_Attr2、完整性信息Integrity_Attr2。签名域中包括车云服务器B用自己的授权私钥对属性域M₁计算得到的签名/>授权公钥域中包括：授权公钥/>以及，用于验证/>的合法性的多个参数，这多个参数包括：多个公钥和公钥的签名，即，编包根公钥(pk₁)，一车一授权公钥pk₂,一车一授权公钥pk₂的签名Sig(sk₁,pk₂),授权根公钥/>授权根公钥/>的签名授权公钥/>的签名/>其中，授权公钥/>用于校验签名授权根公钥/>用于校验签名/>一车一授权公钥pk₂用于校验签名编包根公钥(pk₁)用于校验签名Sig(sk₁,pk₂)。

具体关于属性域的描述可以参见前述表1的相关内容，具体关于pk₁，pk₂,的描述可以参见图13的相关内容。

表6

其中，许可列表A可以包括三个部分：属性域M_A、签名域和密钥链域。其中，属性域M_A中可包括：车辆身份标识Space_Attr1、防重放参数Time_Attr1和白名单公钥签名域中包括供应商服务器用自己的许可私钥/>对属性域M_A计算得到的签名/>密钥链域中包括：编包根公钥(pk₁)，一车一授权公钥(pk₂)，一车一授权公钥(pk₂)的签名Sig(sk₁,pk₂)，许可公钥/>许可公钥/>的签名/>其中，许可公钥/>用于校验签名/>一车一授权公钥(pk₂)用于校验签名/>编包根公钥(pk₁)用于校验签名Sig(sk₁,pk₂)。

具体关于车辆身份标识和防重放参数的描述可以参见前述内容，具体关于pk₁，pk₂，的描述可以参见图13的相关内容。

从表6可以看出，属性域M_A中的指示了车厂A的车辆只能使用车厂A生成的授权公钥/>来校验授权文件的合法性，签名域中的签名用于证明属性域M_A的合法性，密钥链域中包含用于校验签名的公钥和该公钥的合法性证明。

表7

其中，许可列表B可以包括三个部分：属性域M_B、签名域和密钥链域。其中，属性域M_B中可包括：车辆身份标识Space_Attr2、防重放参数Time_Attr2和白名单公钥签名域中包括供应商服务器用自己的许可私钥/>对属性域M_B计算得到的签名/>密钥链域中包括：编包根公钥(pk₁)，一车一授权公钥(pk₂)，一车一授权公钥(pk₂)的签名Sig(sk₁,pk₂)，许可公钥/>许可公钥/>的签名/>其中，许可公钥/>用于校验签名/>一车一授权公钥(pk₂)用于校验签名/>编包根公钥(pk₁)用于校验签名Sig(sk₁,pk₂)。

具体关于车辆身份标识和防重放参数的描述可以参见前述内容，具体关于pk₁，pk₂，Sig(sk₁,pk₂)，的描述可以参见图10的相关内容。

从表7可以看出，属性域M_B中的指示了车厂B的车辆只能使用车厂B生成的授权公钥/>来校验授权文件的合法性，签名域中的签名用于证明属性域M_B的合法性，密钥链域中包含用于校验签名的公钥和该公钥的合法性证明。

在本申请实施例中，许可列表或黑/白名单还可以被称为第一列表。

可以理解的是，上述表5-表7只是示例性举例，不构成对本申请实施例的限定。在本申请其他实施例中，许可列表中可以包含更多或更少的参数。例如，属性域中可以仅包含白名单公钥，当供应商服务器用更多或更少层级的密钥对来设置白名单的签名时，密钥链域中可以包含更多或更少的公钥和公钥的签名。

总的来说，本申请实施例提供的车辆升级验证方法，能够在车辆升级阶段，对车辆接收到的升级包进行校验，只有在该升级包为适用于本车辆此次升级的升级包时，才触发对车辆的升级，当升级包为不适用于该车辆的升级包，例如，老版本的升级包、其他车辆的升级包、研发阶段使用的升级包时，则取消车辆的升级。进一步地，在安全启动阶段，该方法也能够触发对车辆升级后的数据进行校验，只有在车辆升级的数据为经过车辆升级阶段，通过升级包升级得到的数据时，才能够启动车辆的运行，避免了攻击者恶意拆件，将不适用于该车辆的升级包导入该车辆，更改车辆的数据，保障了车辆的安全。

应理解，上述方法实施例中的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

本申请还提供一种电子设备，该电子设备可以包括：存储器和处理器。其中，存储器可用于存储计算机程序；处理器可用于调用所述存储器中的计算机程序，以使得该电子设备执行上述任意一个实施例中供应商服务器、车云服务器或车辆执行的方法。

本申请还提供了一种芯片系统，所述芯片系统包括至少一个处理器，用于实现上述任一个实施例中供应商服务器、车云服务器或车辆执行的方法中所涉及的功能。

在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存程序指令和数据，存储器位于处理器之内或处理器之外。

该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

可选地，该芯片系统中的处理器可以为一个或多个。该处理器可以通过硬件实现也可以通过软件实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等。当通过软件实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现。

可选地，该芯片系统中的存储器也可以为一个或多个。该存储器可以与处理器集成在一起，也可以和处理器分离设置，本申请实施例并不限定。示例性地，存储器可以是非瞬时性处理器，例如只读存储器ROM，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型，以及存储器与处理器的设置方式不作具体限定。

示例性地，该芯片系统可以是现场可编程门阵列(field programmable gatearray，FPGA)，可以是专用集成芯片(application specific integrated circuit，ASIC)，还可以是系统芯片(system on chip，SoC)，还可以是中央处理器(central processorunit，CPU)，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。

本申请还提供一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行上述任一个实施例中供应商服务器、车云服务器或车辆任意一个执行的方法。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当所述计算机程序被运行时，使得计算机执行上述任一个实施例中供应商服务器、车云服务器或车辆任意一个执行的方法。

应理解，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(digitalsignal processor，DSP)、专用集成电路(AP 800plication specific integratedcircuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

另外，本申请实施例还提供一种装置。该装置具体可以是组件或模块，该装置可包括相连的一个或多个处理器和存储器。其中，存储器用于存储计算机程序。当该计算机程序被一个或多个处理器执行时，使得装置执行上述各方法实施例中的方法。

其中，本申请实施例提供的装置、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法。因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

本申请的各实施方式可以任意进行组合，以实现不同的技术效果。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solidstate disk，SSD))等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

总之，以上所述仅为本发明技术方案的实施例而已，并非用于限定本发明的保护范围。凡根据本发明的揭露，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (33)

1.一种车辆校验方法，其特征在于，所述方法包括：

车辆接收到第一文件和第一升级包，所述第一文件包括：第一车辆标识，第一完整性信息，和，根据所述第一车辆标识以及所述第一完整性信息确定的第一签名；

所述车辆使用第一服务器的公钥校验所述第一签名，且校验通过；所述第一服务器用于管理所述车辆的升级；

所述车辆确定所述第一车辆标识与所述车辆的车辆标识相同，且，所述第一升级包为所述第一完整性信息指示的升级包；

所述车辆根据所述第一升级包进行升级，以增强第一功能或增加第一功能。

2.根据权利要求1所述的方法，其特征在于，所述车辆根据所述第一升级包进行升级之后，所述方法还包括：

所述车辆再次使用所述第一服务器的公钥校验所述第一签名，并且校验通过，

所述车辆再次确定所述第一车辆标识与所述车辆的车辆标识相同，且，升级后的所述车辆的数据包括所述第一完整性信息指示的升级包中的数据；

所述车辆启动所述第一功能。

3.一种车辆校验方法，其特征在于，所述方法包括：

车辆接收到第一文件和第一升级包，所述第一文件包括：第一防重放参数，第一完整性信息，和，根据所述第一防重放参数和所述第一完整性信息确定的第一签名；

所述车辆使用第一服务器的公钥校验所述第一签名，且校验通过；所述第一服务器用于管理所述车辆的升级；

所述车辆确定所述第一防重放参数与所述车辆的防重放参数相同，且，所述第一升级包为所述第一完整性信息指示的升级包；所述车辆的防重放参数用于标识所述车辆本次的升级；

所述车辆根据所述第一升级包进行升级，以增强第一功能或增加第一功能。

4.根据权利要求3所述的方法，其特征在于，所述第一文件还包括第一车辆标识，所述第一签名为根据所述第一车辆标识和所述第一防重放参数确定的签名；

所述车辆根据所述第一升级包进行升级之前，所述方法还包括：

所述车辆确定所述第一车辆标识和所述车辆的车辆标识相同。

5.根据权利要求3或4所述的方法，其特征在于，所述车辆根据所述第一升级包进行升级之后，所述方法还包括：

所述车辆再次使用第一服务器的公钥校验所述第一签名，且校验通过；

所述车辆再次确定所述第一防重放参数与所述车辆的防重放参数相同，且，升级后的所述车辆的数据包括所述第一完整性信息指示的升级包中的数据；

所述车辆启动所述第一功能。

6.根据权利要求4所述的方法，其特征在于，所述车辆根据所述第一升级包进行升级之后，所述方法还包括：

所述车辆再次使用所述第一服务器的公钥校验所述第一签名，且校验通过；

所述车辆再次确定所述第一防重放参数与所述车辆的防重放参数相同，且，所述第一车辆标识与所述车辆的车辆标识相同，且，升级后的所述车辆的数据包括所述第一完整性信息指示的升级包中的数据；

所述车辆启动所述第一功能。

7.一种车辆校验方法，其特征在于，所述方法包括：

车辆接收到第一文件和第一升级包，所述第一文件包括：第一车辆标识，第一完整性信息，和，根据所述第一车辆标识以及所述第一完整性信息确定的第一签名；

所述车辆检测到启动第一功能的指令，所述第一功能为所述车辆根据所述第一升级包进行升级后增强或增加的功能；

所述车辆使用第一服务器的公钥校验所述第一签名，且校验通过；所述第一服务器用于管理所述车辆的升级；

所述车辆再次确定所述第一车辆标识与所述车辆的车辆标识相同，且，升级后的所述车辆的数据包括所述第一完整性信息指示的升级包中的数据；

所述车辆启动所述第一功能。

8.一种车辆校验方法，其特征在于，所述方法包括：

车辆接收到第一文件和第一升级包，所述第一文件包括：第一防重放参数，第一完整性信息，和，根据所述第一防重放参数以及所述第一完整性信息确定的第一签名；

所述车辆检测到启动第一功能的指令，所述第一功能为所述车辆根据所述第一升级包进行升级后增强或增加的功能；

所述车辆使用第一服务器的公钥校验所述第一签名，且校验通过；所述第一服务器用于管理所述车辆的升级；

所述车辆再次确定所述第一防重放参数与所述车辆的车辆标识相同，且，升级后的所述车辆的数据包括所述第一完整性信息指示的升级包中的数据；

所述车辆启动所述第一功能。

9.根据权利要求8所述的方法，其特征在于，所述第一文件还包括第一车辆标识，所述第一签名为根据所述第一车辆标识和所述第一防重放参数确定的签名；

所述车辆启动所述第一功能之前，所述方法还包括：

所述车辆确定所述第一车辆标识和所述车辆的车辆标识相同。

10.根据权利要求3-6，8，9任一项所述的方法，其特征在于，所述车辆的防重放参数随着所述车辆的每一次升级而更新且仅用于标识所述车辆的一次升级，或者，所述车辆的防重放参数用于标识所述车辆的多次升级。

11.根据权利要求1-10任一项所述的方法，其特征在于，在所述第一升级包为所述第一完整性信息标识的升级包的情况下，所述第一完整性信息包括一个或多个参数，所述一个或多个参数用于标识所述第一升级包。

12.根据权利要求1-11任一项所述的方法，其特征在于，所述第一文件还包括：第一公钥；所述车辆预存有所述第一服务器的公钥的第一标识，所述车辆使用第一服务器的公钥校验所述第一签名之前，所述方法还包括：

所述车辆确定所述第一公钥的标识；

在所述第一公钥的标识和所述第一标识相同的情况下，所述车辆确定所述第一公钥为所述第一服务器的公钥。

13.根据权利要求1-12任一项所述的方法，其特征在于，所述第一文件中还包括：第一公钥，和，根据所述第一公钥确定的第二签名，所述车辆使用第一服务器的公钥校验所述第一签名之前，所述方法还包括：

所述车辆使用第二服务器的公钥校验所述第二签名；其中，所述第二服务器为开发并提供所述车辆升级所需的升级包的服务器；

在所述第二签名的校验通过的情况下，所述车辆确定所述第一公钥为所述第一服务器的公钥。

14.根据权利要求13所述的方法，其特征在于，所述车辆存储有所述第一公钥的用途信息，所述用途信息用于指示所述第一公钥仅用于校验所述第一签名。

15.根据权利要求1-14任一项所述的方法，其特征在于，所述车辆使用第一服务器的公钥校验所述第一签名之前，所述方法还包括：

所述车辆确定所述第一公钥为所述第一服务器允许所述车辆使用的公钥。

16.根据权利要求1，2，4-6，8，9任一项所述的方法，其特征在于，所述车辆的车辆标识用于标识所述车辆的第一部件；

所述车辆根据所述第一升级包进行升级，具体包括：

所述车辆根据所述第一升级包进行所述第一部件或第二部件的升级，所述第二部件的升级由所述第一部件管理。

17.根据权利要求16所述的方法，其特征在于，在所述车辆升级所述第二部件的情况下，所述车辆的身份标识还用于标识第三部件。

18.根据权利要求17所述的方法，其特征在于，所述车辆通过所述第一部件校验所述第一文件，或者，所述车辆通过所述第一部件和所述第三部件校验所述第一文件。

19.根据权利要求2，5-10任一项所述的方法，其特征在于，所述第一文件还包括：第二完整性信息，所述第一签名还根据所述第二完整性信息确定，

所述车辆确定升级后的所述车辆的数据包括所述第一完整性信息指示的升级包中的数据，具体包括：

所述车辆确定所述升级后的车辆的数据与所述第二完整性信息指示的数据相同，所述第二完整性信息指示的数据包括所述第一升级包中的数据。

20.根据权利要求1-19任一项所述的方法，其特征在于，所述第一文件还包括：第三完整性信息，所述第一签名还根据所述第三完整性信息确定，在所述第一签名的校验通过的情况下，所述第三完整性信息用于指示所述车辆升级失败后的数据。

21.根据权利要求1-20任一项所述的方法，其特征在于，所述第一升级包中包括第三签名和/或第四签名，所述第三签名由所述第一服务器签名得到，所述第四签名由第二服务器签名得到，所述第二服务器为开发并提供所述车辆升级所需的升级文件的服务器；

所述车辆根据所述第一升级包进行升级之前，所述方法还包括：

所述车辆使用所述第一服务器的公钥校验所述第三签名，且校验通过；

和/或，

所述车辆使用所述第二服务器的公钥校验所述第四签名，且校验通过。

22.根据权利要求1-21任一项所述的方法，其特征在于，所述车辆接收到第一文件和第一升级包之前，所述方法还包括：

所述车辆接收到升级策略；

所述车辆根据所述升级策略确定第一地址，所述第一地址为存储所述第一升级包的地址；

所述车辆向所述第一地址所在的服务器发送下载请求，所述下载请求用于请求获取所述第一升级包。

23.一种车辆校验方法，其特征在于，所述方法包括：

第一服务器获取车辆的车辆标识；

所述第一服务器确定升级包的完整性信息，所述完整性信息用于标识所述升级包；

所述第一服务器根据所述车辆标识和所述完整性信息确定签名；所述第一服务器发送文件和所述升级包，所述文件包括：所述车辆标识、所述完整性信息和所述签名；所述升级包用于升级所述车辆。

24.根据权利要求23所述的方法，其特征在于，所述第一服务器根据所述车辆标识和所述完整性信息确定签名，具体包括：

所述第一服务器根据防重放参数、所述车辆标识和所述完整性信息确定所述签名，所述防重放参数用于标识所述车辆本次的升级。

25.一种车辆校验方法，其特征在于，所述方法包括：

所述第一服务器确定升级包的完整性信息，所述完整性信息用于标识所述升级包；

第一服务器根据防重放参数和所述完整性信息确定签名，所述防重放参数用于标识车辆本次的升级；

所述第一服务器发送文件和所述升级包，所述文件包括：所述防重放参数、所述完整性信息和所述签名；所述升级包用于升级所述车辆。

26.根据权利要求25所述的方法，其特征在于，所述第一服务器根据所述防重放参数和所述完整性信息确定签名，具体包括：

所述第一服务器根据所述防重放参数、所述车辆的车辆标识和所述完整性信息确定所述签名。

27.根据权利要求23-26任一项所述的方法，其特征在于，所述方法还包括：

所述第一服务器发送第一列表，所述第一列表指示了所述第一服务器允许或禁止所述车辆校验所述签名时，使用的公钥。

28.根据权利要求23-27任一项所述的方法，其特征在于，所述文件还包括所述第一服务器生成的，用于校验所述签名的公钥。

29.根据权利要求28所述的方法，其特征在于，所述文件还包括所述公钥的签名，所述第一服务器发送文件和升级包之前，所述方法还包括：

所述第一服务器向第二服务器发送所述公钥，所述第二服务器为开发并提供所述车辆升级所需的升级文件的服务器；

所述第一服务器接收所述公钥的签名，所述公钥的签名由所述第二服务器根据所述公钥确定。

30.一种车辆，其特征在于，包括存储器，一个或多个处理器，以及一个或多个程序；所述一个或多个处理器在执行所述一个或多个程序时，使得所述车辆实现如权利要求1至22任一项所述的方法。

31.一种电子设备，其特征在于，包括存储器，一个或多个处理器，以及一个或多个程序；所述一个或多个处理器在执行所述一个或多个程序时，使得所述电子设备实现如权利要求23至29任一项所述的方法。

32.一种通信系统，其特征在于，所述系统包括如权利要求30所述的车辆和如权利要求31所述的电子设备。

33.一种计算机可读存储介质，包括指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1至22，或，23至29任一项所述的方法。