WO2023232045A1

WO2023232045A1 - Vehicle verification method, and related apparatus and system

Info

Publication number: WO2023232045A1
Application number: PCT/CN2023/097264
Authority: WO
Inventors: 侯林; 付天福; 余舟毅; 陈勇; 杜小强; 张作强
Original assignee: 华为技术有限公司
Priority date: 2022-06-01
Filing date: 2023-05-30
Publication date: 2023-12-07
Also published as: CN117195216A

Abstract

Disclosed in the present application are a vehicle verification method, and a related apparatus and system. The method mainly relates to a vehicle and a server, wherein the vehicle can receive a vehicle identity identifier and/or an anti-replay parameter, and integrity information and an upgrade package, which are sent by the server. During the upgrade of the vehicle, upon determining that the vehicle identity identifier, which is sent by the server, is consistent with a local vehicle identity identifier, and/or the anti-replay parameter, which is sent by the server, is consistent with a local anti-replay parameter, and the integrity information, which is sent by the server, is consistent with integrity information which is calculated according to the upgrade package that is sent by the server, the vehicle can be upgraded according to the upgrade package, wherein the vehicle identity identifier is used for identifying the vehicle, and the anti-replay parameter is used for identifying the present upgrade. In this way, a vehicle can be prevented from being upgraded using an upgrade package that is not suitable for the vehicle, for example, an upgrade package of an earlier version, upgrade packages of other vehicles, and an upgrade package which is used in a research and development stage.

Description

Vehicle verification methods, related devices and systems

This application claims priority to the Chinese patent application submitted to the China Patent Office on June 1, 2022, with the application number 202210618805.7 and the application name "Vehicle Verification Method, Related Devices and Systems", the entire content of which is incorporated herein by reference. Applying.

Technical field

This application relates to the field of Internet of Vehicles and communication technologies, and in particular to vehicle verification methods, related devices and systems.

Background technique

With the continuous development of Internet of Vehicles technology in the automotive field, more and more software and hardware are installed on vehicles, making the vehicle's software functions more and more complex. During the operation of the vehicle and the continuous development of technology, certain software functions will gradually reveal their flaws or backwardness. Therefore, it is necessary to continuously upgrade and update the vehicle, optimize software functions or develop new software. function, improve the performance of the vehicle and realize the intelligence of the vehicle.

Contents of the invention

This application provides vehicle verification methods, related devices and systems, realizes the safe upgrade or safe start of the vehicle, and ensures the safety of the vehicle.

In a first aspect, this application provides a vehicle verification method, which is characterized in that the method includes: the vehicle receives a first file and a first upgrade package, and the first file includes: a first vehicle identification, first integrity information, and, the first signature determined based on the first vehicle identification and the first integrity information; the vehicle uses the public key of the first server to verify the first signature, and the verification passes; the first server is used to manage the upgrade of the vehicle; the vehicle is determined The first vehicle identification is the same as the vehicle identification, and the first upgrade package is an upgrade package indicated by the first integrity information; the vehicle is upgraded according to the first upgrade package to enhance the first function or add the first function.

By implementing the method provided by the embodiments of this application, the vehicle can obtain the authorization file and upgrade package when it needs to be upgraded. Before using the upgrade package for upgrade, the vehicle will verify the authorization file, including: verification of the vehicle identity, Verification of integrity information and verification of signatures. Among them, the purpose of verifying the signature is to determine whether the authorization file is sent by the car cloud server that manages vehicle upgrades, and whether the authorization file has been tampered with by a third party. The purpose of verifying the integrity information is to determine whether the received upgrade package is the same as the car cloud server. The upgrade package sent together with the authorization file prevents third parties from replacing the upgrade package sent together with the car cloud server and the upgrade package in the authorization file with other upgrade packages. The purpose of verifying the vehicle identity is to determine whether the received upgrade package is a vehicle The cloud server sends the upgrade package specifically to the vehicle to avoid mixing upgrade packages sent by the vehicle cloud server to other vehicles for upgrade, or using upgrade packages that do not carry the vehicle identity. After the authorization file is verified, the vehicle can be upgraded using the upgrade package.

In this way, on the one hand, the vehicle can be prevented from being upgraded using the upgrade package sent by the car cloud server to other vehicles. For example, if the owner obtains the official upgrade package sent to other vehicles from unofficial channels, the vehicle can be upgraded at a lower or free price. Upgrade to avoid harming the interests of car manufacturers and software suppliers; on the other hand, the vehicle can verify whether the upgrade package is sent by a trusted server, and only use the upgrade package sent by the trusted server for upgrade, because the server will not Upgrade packages that are not used for authorization, such as upgrade packages used in the research and development stage, upgrade packages carrying viruses, upgrade packages with vulnerabilities, etc., are sent to the vehicle. Therefore, the vehicle will only be upgraded according to the safe upgrade package, ensuring that the vehicle uses the upgrade package. Security for making upgrades.

In conjunction with the first aspect, in one implementation, after the vehicle is upgraded according to the first upgrade package, the method further includes: the vehicle uses the public key of the first server again to verify the first signature, and if the verification passes, the vehicle determines the first signature again. A vehicle identification is the same as the vehicle identification, and the upgraded vehicle data includes data in the upgrade package indicated by the first integrity information; the vehicle activates the first function.

Furthermore, in addition to verifying the authorization file during the upgrade stage, the vehicle can also verify the authorization file again during the safe start stage. Only after the verification of the authorization file passes, the vehicle will be started. In this way, any unauthorized access can be avoided. The authorized software program runs in the vehicle. The software program that ensures the operation of the vehicle comes from the upgrade stage. After the authorization file is verified and passed, the upgrade package is installed to prevent the vehicle from running the software program in the upgrade package sent by the car cloud server to other vehicles. Or, the software programs in the upgrade package used in the research and development stage ensure the safe operation of the vehicle.

In a second aspect, this application provides another vehicle verification method. The method includes: the vehicle receives a first file and a first upgrade package. The first file includes: a first anti-replay parameter, a first integrity information, and , the first signature determined based on the first anti-replay parameter and the first integrity information; the vehicle uses the public key of the first server to verify the first signature, and the verification passes; the first server is used to manage the upgrade of the vehicle; the vehicle It is determined that the first anti-replay parameter is the same as the anti-replay parameter of the vehicle, and the first upgrade package is the upgrade package indicated by the first integrity information; the anti-replay parameter of the vehicle is used to identify this upgrade of the vehicle; the vehicle is based on The first upgrade package is upgraded to enhance the first function or add the first function.

By implementing the method provided by the embodiments of this application, the vehicle can obtain the authorization file and upgrade package when it needs to be upgraded. Before using the upgrade package to upgrade, the vehicle will verify the authorization file, including: verification of anti-replay parameters. , Verification of integrity information and verification of signatures. Among them, the purpose of verifying the signature is to determine whether the authorization file is sent by the car cloud server that manages vehicle upgrades, and whether the authorization file has been tampered with by a third party. The purpose of verifying the integrity information is to determine whether the received upgrade package is the same as the car cloud server. The upgrade package that is generated together with the authorization file prevents third parties from replacing the upgrade package sent together with the car cloud server and the upgrade package in the authorization file with other upgrade packages, and verifies whether the anti-replay parameters are correct to ensure that the vehicle can pass the upgrade package with the car cloud server. Upgrade with the upgrade package of the agreed upgrade package version. For example, the vehicle and the server can agree on different anti-replay parameters for each upgrade. If an attacker exploits the vulnerability of the old version of the upgrade package to attack the vehicle, intercept the upgrade package sent by the server to the vehicle and replace it with the old version of the upgrade package. package, but because the anti-replay parameters of the old version of the upgrade package are inconsistent with the anti-replay parameters of the current vehicle upgrade, the vehicle will not be upgraded based on the old version of the upgrade package, thus preventing attackers from replaying the old version of the upgrade. package, using the vulnerabilities of old versions to attack vehicles, ensuring the safety of vehicles and the interests of car owners.

Combined with the second aspect, in one implementation, the first file further includes a first vehicle identification, and the first signature is a signature determined based on the first vehicle identification and the first anti-replay parameter; the vehicle is upgraded according to the first upgrade package Previously, the method also includes: the vehicle determines that the first vehicle identification is the same as the vehicle identification of the vehicle.

Further, the verification of the authorization file may also include verification of the vehicle identity. The purpose of verifying the vehicle identity is to ensure that the upgrade package received by the vehicle is the upgrade package sent by the car cloud server and is suitable for the vehicle. Prevent vehicles from being upgraded using upgrade packages sent by the car cloud server to other vehicles, or upgrade packages used in the research and development stage, to ensure vehicle safety from the vehicle upgrade stage.

Combined with the second aspect, in one embodiment, after the vehicle is upgraded according to the first upgrade package, the method further includes: the vehicle uses the public key of the first server again to verify the first signature, and the verification passes; the vehicle again determines the first signature. The first anti-replay parameter is the same as the anti-replay parameter of the vehicle, and the upgraded vehicle data includes data in the upgrade package indicated by the first integrity information; the vehicle activates the first function.

Furthermore, in addition to verifying the authorization file during the upgrade phase, the vehicle can also verify the authorization file again during the secure startup phase, including: verification of signatures, verification of anti-replay parameters, and verification of integrity information. In this way, it can be ensured that the software program running on the vehicle is the official server, that is, the software program in the upgrade package sent by the car cloud server. Furthermore, it does not come from the software program in the upgrade package of the old version, which prevents attackers from running the vehicle during the operation phase. Use vulnerabilities in older version upgrade packages to attack vehicles.

Combined with the second aspect, in one embodiment, after the vehicle is upgraded according to the first upgrade package, the method further includes: the vehicle uses the public key of the first server again to verify the first signature, and the verification passes; the vehicle again determines the first signature. The first anti-replay parameter is the same as the anti-replay parameter of the vehicle, and the first vehicle identification is the same as the vehicle identification of the vehicle, and the data of the upgraded vehicle includes the data in the upgrade package indicated by the first integrity information; the vehicle Start the first function.

Furthermore, in addition to verifying the authorization file during the upgrade phase, the vehicle can also verify the authorization file again during the safe startup phase, including: verification of signatures, verification of anti-replay parameters, verification of vehicle identity, Verification of integrity information. In this way, it can be ensured that the software program running on the vehicle is the official server, that is, the software program in the upgrade package sent by the car cloud server. Furthermore, it does not come from the upgrade package of the old version, the upgrade package used in the research and development stage, or the upgrade package sent by the car cloud server to other The software program in the upgrade package sent by the vehicle ensures the safety of the vehicle during its operation.

In a third aspect, this application provides another vehicle verification method. The method includes: the vehicle receives a first file and a first upgrade package. The first file includes: a first vehicle identification, first integrity information, and, according to The first vehicle identification and the first signature determined by the first integrity information; the vehicle detects an instruction to activate the first function, and the first function is a function that is enhanced or added after the vehicle is upgraded according to the first upgrade package; the vehicle uses the first server The public key verifies the first signature, and the verification passes; the first server is used to manage the upgrade of the vehicle; the vehicle again determines that the first vehicle identification is the same as the vehicle identification, and the upgraded vehicle data includes the first complete The data in the upgrade package indicated by the sexual information; the vehicle starts the first function.

By implementing the method provided by the embodiments of this application, the vehicle can receive the upgrade package and authorization file during the upgrade phase, and perform upgrades based on the upgrade package. When the vehicle is started, the authorization file is then used to verify whether the vehicle's upgraded software program comes from the source The vehicle will start only after the software program in the upgrade package sent by the server to the vehicle has passed the verification. In this way, any unauthorized software program can be prevented from running in the vehicle. The software program that ensures the operation of the vehicle comes from the software program in the upgrade package received during the upgrade stage, and during the startup stage, it is determined that the upgrade package is sent by the car cloud server. The upgrade package applicable to this vehicle prevents the vehicle from running the software program in the upgrade package sent by the car cloud server to other vehicles, or the software program in the upgrade package used in the research and development stage, etc., ensuring the safe operation of the vehicle.

In a fourth aspect, this application provides another vehicle verification method. The method includes: the vehicle receives a first file and a first upgrade package. The first file includes: a first anti-replay parameter, a first integrity information, and , the first signature determined based on the first anti-replay parameter and the first integrity information; the vehicle detects an instruction to start the first function, and the first function is a function that is enhanced or added after the vehicle is upgraded according to the first upgrade package; the vehicle The first signature is verified using the public key of the first server, and the verification passes; the first server is used to manage the upgrade of the vehicle; the vehicle again determines that the first anti-replay parameter is the same as the vehicle identification of the vehicle, and the upgraded vehicle The data includes the data in the upgrade package indicated by the first integrity information; the vehicle starts the first function.

By implementing the method provided by the embodiments of this application, the vehicle can receive the upgrade package and authorization file during the upgrade phase, and perform upgrades based on the upgrade package. When the vehicle is started, the authorization file is then used to verify whether the vehicle's upgraded software program comes from the source The software program in the upgrade package sent by the server to the vehicle for this upgrade will only start after the verification passes. In this way, any unauthorized software programs can be prevented from running in the vehicle, and the software programs running on the vehicle can be guaranteed to The program is derived from the software program in the upgrade package received during the upgrade stage, and during the startup stage, it is determined that the upgrade package is an upgrade package sent by the car cloud server that is suitable for the current upgrade of the vehicle, so as to prevent the vehicle from running an old version of the upgrade package. Software programs, etc., ensure the safe operation of the vehicle.

Combined with the fourth aspect, in one implementation, the first file further includes a first vehicle identification, and the first signature is a signature determined based on the first vehicle identification and the first anti-replay parameter; before the vehicle starts the first function, the method It also includes: the vehicle determines that the first vehicle identification is the same as the vehicle identification of the vehicle. Furthermore, the verification of the authorization file also includes the verification of the vehicle identity, which can further prevent the vehicle from running the software program in the upgrade package sent by the car cloud server to other vehicles, or the software program in the upgrade package used in the research and development phase. etc. to ensure the safe operation of the vehicle.

Combined with the second aspect and the fourth aspect, in one embodiment, the anti-replay parameters of the vehicle are updated with each upgrade of the vehicle and are only used to identify an upgrade of the vehicle, or the anti-replay parameters of the vehicle are Multiple upgrades to identify vehicles.

In one case, the anti-replay parameter can be a random number randomly generated for each upgrade. This random number can be used to uniquely identify an upgrade. That is to say, for each upgrade, the car cloud server and the vehicle can agree on a random number. The generated "secret code" ensures that the vehicle will not be upgraded using an old version of the upgrade package at any time.

In another case, the anti-replay parameter can be a monotonically increasing count value, which can change each time it is upgraded, or can be changed under preset conditions, such as when a vulnerability is found in an old version upgrade package. . Among them, each time the count value is changed, it can be ensured that the vehicle will not be upgraded using the old version of the upgrade package at any time. Changing the count value when a vulnerability in the old version of the upgrade package is discovered can avoid the need to The vehicle is upgraded using the old version upgrade package.

Combined with the second aspect and the fourth aspect, in one implementation, the anti-replay parameters of the vehicle are stored in the replay protection storage partition RPMB or the one-time programmable storage area OTP.

The vehicle stores the local anti-replay parameters in RPMB and OTP, which can prevent third parties from maliciously tampering with the locally stored anti-replay parameters and ensure that the vehicle compares the received anti-replay parameters with the local anti-replay parameters. , the credibility of local anti-replay parameters.

Combining the first aspect and the third aspect, in one implementation, the vehicle identification of the vehicle is stored in the one-time programmable storage area OTP.

The vehicle stores local anti-replay parameters in the OTP, which can prevent third parties from maliciously tampering with the locally stored vehicle identity and ensure that when the vehicle compares the received vehicle identity with the local vehicle identity, the local vehicle identity The credibility of the logo.

Combining the first aspect, the second aspect, the third aspect and the fourth aspect, in one embodiment, when the first upgrade package is an upgrade package identified by the first integrity information, the first integrity information includes a or multiple parameters, one or more parameters are used to identify the first upgrade package.

That is to say, the integrity information can be a parameter that is used to identify the data in the entire upgrade package. In this way, when the vehicle verifies the integrity information, it can quickly determine whether the data in the upgrade package has been tampered with, or whether it is complete. The sexual information can be multiple parameters, and these multiple parameters can respectively identify multiple upgrade files in the upgrade package. In this way, when the vehicle verifies the integrity information, it can accurately determine which data in the upgrade package has been tampered with.

Combining the first aspect, the second aspect, the third aspect and the fourth aspect, in one implementation, the first file further includes: a first public key; the vehicle has a first identifier of the public key of the first server pre-stored, and the vehicle Before using the public key of the first server to verify the first signature, the method further includes: the vehicle determines the identity of the first public key; when the identity of the first public key is the same as the first identity, the vehicle determines that the first public key is The public key of the first server.

That is to say, the authorization file can also include the authorization public key for verifying the signature in the authorization file. Before verifying the signature, the vehicle can first verify whether the authorization public key has been tampered with by a third party to ensure that the signature verification is successful. Credibility. Among them, the vehicle can preset the identification of the authorized public key locally, such as a hash value. If the hash value of the received authorized public key is the same as the locally preset hash value, it means that the authorized public key comes from the car cloud. server and has not been tampered with by a third party. That is to say, the vehicle can verify the received public key through the identification of the locally preset authorized public key.

In combination with the first aspect, the second aspect, the third aspect, and the fourth aspect, in one implementation, the first file further includes: a first public key, and a second signature determined based on the first public key, the vehicle Before using the public key of the first server to verify the first signature, the method also includes: the vehicle uses the public key of the second server to verify the second signature; wherein the second server is a server that develops and provides an upgrade package required for vehicle upgrades. ; When the verification of the second signature passes, the vehicle determines that the first public key is the public key of the first server.

That is to say, when the authorization file includes an authorization public key that verifies the signature in the authorization file, other trusted third parties other than the car cloud server and the vehicle can provide proof of the legitimacy of the authorization public key. The trusted third party may refer to the software vendor. In other words, the vehicle can use the legality certificate provided by the software supplier's supplier server to determine whether the authorized public key comes from the vehicle cloud server and has not been tampered with, ensuring the credibility of the signature verification.

Combining the first aspect, the second aspect, the third aspect and the fourth aspect, in one implementation, the vehicle stores usage information of the first public key, and the usage information is used to indicate that the first public key is only used to verify the first public key. One signature.

When the legitimacy of the authorized public key in the authorization file is guaranteed by the supplier server, the purpose information of the first public key is used to specify the purpose of the authorized public key to avoid confusion between the signature capabilities of the supplier server and the car cloud server. The cloud server has the possibility of forging the signature of the upgrade package.

Combining the first aspect, the second aspect, the third aspect and the fourth aspect, in one implementation, before the vehicle uses the public key of the first server to verify the first signature, the method further includes: the vehicle determines that the first public key is The first server allows the vehicle to use the public key.

Since there can be multiple car cloud servers, different vehicles can obtain authorization files and upgrade packages sent by different car cloud servers. In addition to sending authorization files and upgrade packages to the vehicle, the car cloud server can also control the vehicle to allow or prohibit the authorization public key used to verify the signature of the authorization file. In this way, the authorization public keys provided by different car cloud servers can be distinguished. , to avoid the loss of authorized private keys of some vehicle manufacturers' car cloud servers, which will also affect other vehicle manufacturers.

Combining the first aspect, the second aspect, and the fourth aspect, in one embodiment, the vehicle identification of the vehicle is used to identify the first component of the vehicle; the vehicle is upgraded according to the first upgrade package, which specifically includes: the vehicle is upgraded according to the first upgrade package The package performs an upgrade of the first component or the second component, and the upgrade of the second component is managed by the first component.

Since the upgrade of the vehicle specifically refers to the upgrade of each component of the vehicle, the vehicle identity identifier can be used to identify the components of the vehicle upgrade. Further, the vehicle identity identifier can be the chip ID of the component, or, for components with lower security capabilities, for components with lower security capabilities, the vehicle identity identifier can be the chip ID of the component. When upgraded, the vehicle identity is the identification of a component with strong security capabilities that manages the component, such as the chip ID of the component.

Combining the first aspect, the second aspect, and the fourth aspect, in one embodiment, when the vehicle upgrades the second component, the vehicle's identity is also used to identify the third component.

Among them, the vehicle identity is used to identify multiple components, which can prevent the occurrence of malicious parts replacement attack scenarios on the vehicle.

With reference to the first aspect, the second aspect, and the fourth aspect, in one implementation, the vehicle verifies the first file through the first component, or the vehicle verifies the first file through the first component and the third component.

That is to say, when the vehicle undergoes a component upgrade, the verification of the authorization file can be completed by one or more component verifications.

Combining the first aspect, the second aspect, the third aspect and the fourth aspect, in one implementation, it is characterized in that the first file further includes: second integrity information, and the first signature is also based on the second integrity information. It is determined that the vehicle determines that the upgraded vehicle data includes the data in the upgrade package indicated by the first integrity information, specifically including: the vehicle determines that the upgraded vehicle data is the same as the data indicated by the second integrity information, and the second integrity information The data indicated by the information includes data in the first upgrade package.

When the vehicle upgrade mode is differential upgrade, the upgrade package is a differential package. The integrity information in the authorization file may include: the integrity information of the data in the differential package, and the integrity information of the complete upgrade data.

Combining the first aspect, the second aspect, the third aspect and the fourth aspect, in an implementation manner, the first file further includes: third integrity information, the first signature is further determined based on the third integrity information. If the verification of a signature passes, the third integrity information is used to indicate the data after the vehicle upgrade fails.

When the vehicle upgrade mode is A/B upgrade, the integrity information in the authorization file may include: the integrity information of the data in the upgrade package, and the integrity information of the data after the upgrade fails. This prevents attackers from maliciously tampering with data in the vehicle by taking advantage of vehicle upgrade failures.

Combining the first aspect, the second aspect, the third aspect and the fourth aspect, in one implementation, the first upgrade package includes a third signature and/or a fourth signature, and the third signature is obtained by signing the first server, The fourth signature is obtained by signing the second server, which is a server that develops and provides upgrade files required for vehicle upgrades; before the vehicle is upgraded according to the first upgrade package, the method also includes: the vehicle uses the public key of the first server to verify the signature. The vehicle verifies the third signature and the verification passes; and/or the vehicle uses the public key of the second server to verify the fourth signature and the verification passes.

In the above embodiment, the upgrade package may include a package signature and an outer signature. The package signature is obtained by the supplier server signing the upgrade file, and the outer signature is obtained by the CheCloud server signing the upgrade package. The vehicle can determine by verifying the package signature that the upgrade file was sent by the supplier server and that it was not tampered with by a third party during the transmission process. By verifying the outer signature, the vehicle can determine that the upgrade package was sent by the vehicle cloud server and that it was not tampered with by a third party during the transmission process. Third-party tampering to ensure that the upgrade package used when upgrading the vehicle is from a reliable source and has not been tampered with.

Combining the first aspect, the second aspect, the third aspect and the fourth aspect, in one implementation, before the vehicle receives the first file and the first upgrade package, the method further includes: the vehicle receives the upgrade strategy; the vehicle performs the upgrade according to The policy determines the first address, which is the address where the first upgrade package is stored; the vehicle sends a download request to the server where the first address is located, and the download request is used to request to obtain the first upgrade package.

In the above embodiment, the vehicle can receive the download address of the upgrade package and download the upgrade package from the corresponding car cloud according to the download address. The server obtains the upgrade package required for the upgrade, which can speed up the vehicle to obtain the upgrade package and reduce the storage space occupied by the upgrade package in each vehicle cloud server.

In a fifth aspect, this application provides another vehicle verification method. The method includes: the first server obtains the vehicle identification of the vehicle; the first server determines the integrity information of the upgrade package, and the integrity information is used to identify the upgrade package; The server determines the signature based on the vehicle identification and integrity information; the first server sends a file and an upgrade package. The file includes: vehicle identification, integrity information and signature; the upgrade package is used to upgrade the vehicle.

Implementing the method provided by the embodiments of this application, the car cloud server can send the authorization file for the upgrade package to the vehicle when sending the upgrade package to the vehicle, where the authorization file can include: vehicle identity identification, integrity information ,sign. Among them, the signature proves that the authorization file was sent by the Cheyun server, preventing a third party from forging the authorization file. The integrity information is used to bind the upgrade package and the authorization file, preventing a third party from maliciously intercepting the authorization file and combining the authorization file with the forged upgrade package. are sent to the vehicle together, and the vehicle identity identifier is used to indicate that the upgrade package sent this time is an upgrade package sent specifically for the vehicle. In this way, vehicles can be prevented from being upgraded using upgrade packages sent by the car cloud server to other vehicles, or from using other upgrade packages not for sale, such as upgrade packages used in the research and development stage, upgrade packages carrying viruses, and upgrade packages with vulnerabilities. Wait for the upgrade to ensure that the vehicle is upgraded using a legal and appropriate upgrade package, or to ensure that the vehicle operation data comes from a legal and appropriate upgrade package to ensure the safe operation of the vehicle and safeguard the interests of car owners, car manufacturers and software suppliers.

Combined with the fifth aspect, in one implementation, the first server determines the signature based on the vehicle identification and integrity information, which specifically includes: the first server determines the signature based on the anti-replay parameters, the vehicle identification, and the integrity information, and the anti-replay parameters Used to identify this upgrade of the vehicle.

Furthermore, the authorization file may also include anti-replay parameters to ensure that the vehicle can be upgraded according to the upgrade package of the upgraded version agreed with the server. It can also prevent attackers from replaying the old version of the upgrade package and using the vulnerabilities of the old version to attack the vehicle, ensuring the safety of the vehicle and the interests of the car owner.

In the sixth aspect, embodiments of the present application provide another vehicle verification method. The method includes: the first server determines the integrity information of the upgrade package, and the integrity information is used to identify the upgrade package; the first server determines the integrity information of the upgrade package according to the anti-replay parameters and The integrity information determines the signature, and the anti-replay parameters are used to identify the current upgrade of the vehicle; the first server sends a file and an upgrade package. The file includes: anti-replay parameters, integrity information, and signature; the upgrade package is used to upgrade the vehicle.

Implementing the method provided by the embodiments of this application, the car cloud server can send the authorization file for the upgrade package to the vehicle when sending the upgrade package to the vehicle, where the authorization file can include: anti-replay parameters, integrity information, signature. Among them, the signature proves that the authorization file was sent by the Cheyun server, preventing a third party from forging the authorization file. The integrity information is used to bind the upgrade package and the authorization file, preventing a third party from maliciously intercepting the authorization file and combining the authorization file with the forged upgrade package. Sent to the vehicle together, the anti-replay parameters are used to identify this upgrade of the vehicle. This prevents the vehicle from being upgraded based on the old version of the upgrade package, thereby preventing attackers from replaying the old version of the upgrade package and using the vulnerabilities of the old version to attack the vehicle, thus ensuring the safety of the vehicle and the interests of the car owner.

With reference to the sixth aspect, in one implementation, the first server determines the signature based on the anti-replay parameters and the integrity information, which specifically includes: the first server determines the signature based on the anti-replay parameters, the vehicle identification of the vehicle, and the integrity information.

Furthermore, the authorization file may also include vehicle identification to prevent vehicles from mixing upgrade packages sent by the vehicle cloud server to other vehicles, or upgrade packages used in the research and development stage, etc.

In conjunction with the fifth aspect and the sixth aspect, in one implementation, the method further includes: the first server sending a first list, the first list indicating the public keys used when the first server allows or prohibits the vehicle from verifying the signature.

In combination with the fifth and sixth aspects, in one implementation, the file further includes a public key generated by the first server and used to verify the signature.

In combination with the fifth and sixth aspects, in one implementation, the file further includes a signature of the public key. Before the first server sends the file and the upgrade package, the method further includes: the first server sends the public key to the second server, and the first server sends the public key to the second server. The second server is a server that develops and provides upgrade files required for vehicle upgrades; the first server receives the signature of the public key, and the signature of the public key is determined by the second server based on the public key.

In other words, the legitimacy of the authorization public key in the authorization file can be guaranteed by the supplier server to ensure the credibility of the vehicle's signature in the verification authorization file.

In a seventh aspect, the application provides a vehicle, including a memory, one or more processors, and one or more programs; when the one or more processors execute the one or more programs, the vehicle implements the first aspect or any embodiment of the first aspect, the second aspect or any embodiment of the second aspect, the third aspect or any embodiment of the third aspect, the fourth aspect or any one of the fourth aspect method described in each embodiment.

In an eighth aspect, the present application provides an electronic device, including a memory, one or more processors, and one or more programs; when the one or more processors execute the one or more programs, the electronic device implements the first The method described in the fifth aspect or any embodiment of the fifth aspect, the sixth aspect or any embodiment of the sixth aspect.

In a ninth aspect, the present application provides a communication system, which includes the vehicle of the seventh aspect and the electronic device of the eighth aspect.

In a tenth aspect, the present application provides a computer-readable storage medium, including instructions. When the instructions are run on an electronic device, the electronic device causes the electronic device to execute the first aspect or any one of the embodiments of the first aspect or the second aspect. Or any embodiment of the second aspect, the third aspect or any embodiment of the third aspect, the fourth aspect or any embodiment of the fourth aspect, the fifth aspect or any one of the fifth aspect The method described in any one of the embodiments, the sixth aspect, or the sixth aspect.

It can be seen that before the vehicle is upgraded or started, by verifying the data carried in the upgrade package, including vehicle identification, anti-replay parameters, etc., the vehicle can be prevented from importing upgrade packages that are not suitable for the vehicle. vehicle, or to prevent the vehicle from running the data in the upgrade package that is not applicable to the vehicle, thereby affecting the safety of the vehicle, and safeguarding the commercial interests between car owners, car manufacturers and software suppliers.

Description of the drawings

Figure 1 is a schematic structural diagram of a communication system 10 provided by an embodiment of the present application;

Figure 2A is a schematic structural diagram of a vehicle 300 provided by an embodiment of the present application;

Figure 2B is an electronic and electrical architecture diagram of the vehicle 300 provided by an embodiment of the present application;

Figure 3 is a hardware structure diagram of the electronic device 500 provided by the embodiment of the present application;

Figure 4 is a schematic flow chart of the vehicle verification method in the remote upgrade scenario provided by the embodiment of the present application;

Figure 5 is a schematic diagram of the logical structure of the supplier server signing the upgrade package provided by the embodiment of the present application;

Figure 6 is a schematic diagram of the logical structure of the package signature of the vehicle verification upgrade package provided by the embodiment of the present application;

Figure 7 is a schematic flow chart of the vehicle verification method in the near-end upgrade scenario provided by the embodiment of the present application;

Figure 8 is a flow chart of interaction between domain controllers when multiple domain controllers verify the vehicle identity in the authorization file provided by the embodiment of the present application;

Figure 9 is a sequence diagram of a vehicle upgrade provided by an embodiment of the present application;

Figure 10 is a sequence diagram of another vehicle upgrade provided by an embodiment of the present application;

Figure 11 is a flow chart of the interaction between the supplier server and the car cloud server when multi-level keys are used to set the signature of the authorized public key provided by the embodiment of the present application;

Figure 12 is a schematic structural diagram of a multi-level key provided by an embodiment of the present application;

Figure 13 is a logical schematic diagram of the supplier server signing the authorized public keys of multiple car cloud servers provided by the embodiment of this application;

Figure 14 is a schematic structural diagram of another multi-level key provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be described clearly and in detail below with reference to the accompanying drawings. Among them, in the description of the embodiments of this application, unless otherwise stated, "/" means or, for example, A/B can mean A or B; "and/or" in the text is only a way to describe related objects. The association relationship means that there can be three relationships. For example, A and/or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiment of the present application , "plurality" means two or more than two.

Hereinafter, the terms “first” and “second” are used for descriptive purposes only and shall not be understood as implying or implying relative importance or implicitly specifying the quantity of indicated technical features. Therefore, the features defined as “first” and “second” may explicitly or implicitly include one or more of the features. In the description of the embodiments of this application, unless otherwise specified, “plurality” The meaning is two or more.

In order to upgrade the vehicle, the upgrade package can be imported and installed in the vehicle system to achieve the upgrade effect of expanding or enhancing the vehicle software functions. For example, on the premise that the vehicle has the hardware capabilities for autonomous driving, the autonomous driving function of the vehicle can be enabled by importing an upgrade package for the autonomous driving function. For another example, when a vehicle has a software vulnerability, the software vulnerability can be fixed by importing a higher version upgrade package.

Among them, the vehicle upgrade methods mainly include the following two types:

1) Remote upgrade

Remote upgrade, also known as Over-the-Air (OTA) upgrade, OTA upgrade means that the vehicle directly interacts with the server that holds the upgrade package through the wireless network to obtain the upgrade package and complete the upgrade.

It can be seen that OTA upgrades can remotely repair vehicle software faults, and automakers do not have to recall vehicles for repairs. Maintenance reduces the recall costs of automobile manufacturers, and car owners can also complete vehicle repairs conveniently and quickly, reducing the time cost of car owners.

2) Near-end upgrade

In the near-end upgrade scenario, the device with the upgrade package can use the vehicle's port, for example, through a wired connection to the vehicle's on-board diagnostic system (On Board Diagnostics, OBD) port, import the upgrade package into the vehicle and trigger the installation, thereby completing the vehicle upgrade. For example, the vehicle can drive to a car sales and service store, that is, a 4S store, and the after-sales staff of the 4S store will connect the diagnostic instrument/host computer to the OBD port of the vehicle, import the upgrade package into the vehicle, and complete the vehicle upgrade.

It is understandable that in addition to OTA upgrades, other legal upgrade methods, such as USB upgrades and card package upgrades, can be regarded as near-end upgrades.

It can be seen that in the near-end upgrade scenario, the vehicle can be quickly upgraded without being connected to the network.

In summary, whether it is a remote upgrade or a local upgrade, the upgrade package needs to be imported into the vehicle to achieve the vehicle upgrade. This presents a problem. Since the vehicle only receives the upgrade package unilaterally, the attacker can Upgrade packages that are not applicable to the vehicle, such as upgrade packages for older versions, upgrade packages for other vehicles, upgrade packages used in the research and development stage, etc., are imported into the vehicle, thereby affecting the commercial interests of car owners, car manufacturers and software suppliers.

For example, an attacker can import an older version of an upgrade package with a vulnerability into a vehicle, and then use the vulnerability to attack the vehicle and harm the interests of the car owner. For another example, attackers can import upgrade packages sent by officials (such as car manufacturers) to other vehicles into vehicles at a lower price, achieving the same effect as purchasing from the official website, harming the commercial interests of car manufacturers and software suppliers. For another example, an attacker can import the upgrade package used in the research and development stage into the vehicle, and use the privileges included in the upgrade package to maliciously modify the vehicle's program, reduce the safety of the vehicle, and harm the interests of the car owner.

Therefore, how to prevent attackers from importing upgrade packages that are not applicable to the vehicle, such as old version upgrade packages, upgrade packages for other vehicles, upgrade packages used in the research and development stage, etc., or how to avoid the above being not applicable to the vehicle. The data in the vehicle's upgrade package is running in the vehicle, which is an urgent problem that needs to be solved.

The embodiment of the present application provides a vehicle verification method, which mainly involves a vehicle and a server. The server stores upgrade packages required for vehicle upgrades. When the vehicle needs to be upgraded, the server can send the vehicle identity, integrity information, and the signature and upgrade package calculated based on the vehicle identity and integrity information to the vehicle, where the vehicle identity is used to uniquely identify the upgraded vehicle. Integrity information is used to identify the upgrade package. After receiving the vehicle identity, integrity information, signature and upgrade package, the vehicle can first verify the signature to make sure that the vehicle identity comes from the server and has not been tampered with by a third party, and then verify the received vehicle. The identity identifier is consistent with the local identity identifier of the vehicle, and whether the received integrity information is consistent with the integrity information calculated by the vehicle for the received upgrade package. If they are consistent, it means that the upgrade package received by the vehicle was specifically sent by the server to The vehicle's upgrade package, the vehicle can trigger vehicle upgrades based on the upgrade package.

That is to say, when the server sends upgrade packages to different vehicles, they all carry the vehicle identity that identifies the vehicle. This prevents the vehicle from mixing upgrade packages sent by the server to other vehicles for upgrade, or using uncarried vehicles when upgrading. Identity upgrade package.

In this way, on the one hand, it is possible to prevent the vehicle from being upgraded using the upgrade package sent by the server to other vehicles. For example, the car owner obtains the official upgrade package sent to other vehicles from unofficial channels and completes the vehicle upgrade at a lower or free price. Avoid harming the interests of car manufacturers and software suppliers; on the other hand, the vehicle can verify whether the upgrade package is sent by a trusted server, and only use the upgrade package sent by the trusted server for upgrade, because the server will not use the upgrade package that is not for sale. Upgrade packages, for example, upgrade packages used in the research and development stage, upgrade packages carrying viruses, upgrade packages with vulnerabilities, etc. are sent to the vehicle, because This vehicle will only be upgraded based on a secure upgrade package. Furthermore, even if the vehicle receives a tampered upgrade package or a forged upgrade package sent by a third party, it will not pass the verification and will not proceed based on the upgrade package. Upgrade, thereby ensuring the safety of vehicles using upgrade packages.

The embodiment of the present application also provides another vehicle verification method. This method mainly involves the vehicle and the server. When the vehicle needs to be upgraded, the server can transfer the anti-replay parameters and integrity information according to the anti-replay parameters and integrity information. The signature calculated by the information and the upgrade package applicable to this upgrade are sent to the vehicle. The anti-replay parameters are used to identify this upgrade, and the integrity information is used to identify the upgrade package. After receiving the anti-replay parameters, signature and upgrade package, the vehicle can first verify the signature to make sure that the anti-replay parameters come from the server and have not been tampered with by a third party, and then verify the received anti-replay data. The parameters are consistent with the local anti-replay parameters of the vehicle, and whether the received integrity information is consistent with the integrity information calculated by the vehicle for the received upgrade package. If they are consistent, it means that the upgrade package received by the vehicle was sent by the server. The upgrade package is applicable to this upgrade, and the vehicle can trigger the vehicle upgrade based on the upgrade package.

That is to say, when the server sends the upgrade package to the vehicle, it carries the anti-replay parameters that identify the current upgrade of the vehicle. The server uses the anti-replay parameters to distinguish upgrades of different versions of the vehicle.

It can be seen that this vehicle verification method can ensure that the vehicle can be upgraded according to the upgrade package of the upgraded version agreed with the server. For example, the vehicle and the server can agree on different anti-replay parameters for each upgrade. If an attacker exploits the vulnerability of the old version of the upgrade package to attack the vehicle, intercept the upgrade package sent by the server to the vehicle and replace it with the old version of the upgrade package. package, but because the anti-replay parameters of the old version of the upgrade package are inconsistent with the anti-replay parameters of the current vehicle upgrade, the vehicle will not be upgraded based on the old version of the upgrade package, thus preventing attackers from replaying the old version of the upgrade. package, using the vulnerabilities of old versions to attack vehicles, ensuring the safety of vehicles and the interests of car owners.

In some embodiments, the above two vehicle verification methods can be implemented in combination. Specifically, the server can send the vehicle identity, anti-replay parameters and complete information, as well as the signature calculated based on the vehicle identity, anti-replay parameters, and integrity information, along with the upgrade package to the vehicle, and verify it. When the vehicle identity, anti-replay parameters and integrity information are all verified, the vehicle upgrade is triggered. For specific verification of the vehicle identity and anti-replay parameters, reference may be made to the descriptions in the two aforementioned embodiments, and the beneficial effects of this embodiment may include the beneficial effects of the above two vehicle verification methods.

It should be noted that the vehicle identity and/or anti-replay parameters and integrity information mentioned above, and the signature obtained based on the vehicle identity and/or anti-replay parameters and integrity information can be included in the authorization file. Inside, that is to say, the server can send the upgrade package and authorization file to the vehicle when the vehicle needs to be upgraded. The vehicle can verify the authorization file before using the upgrade package to upgrade. Specifically, the verification of the authorization file and authorization file is as follows The description can be found in the following content, and will not be expanded upon here.

It can be seen that before the vehicle is upgraded, by verifying the data carried in the upgrade package, including vehicle identification, anti-replay parameters, etc., the vehicle can be prevented from importing upgrade packages that are not suitable for the vehicle, and thus It affects the safety of vehicles and protects the commercial interests among car owners, car manufacturers and software suppliers.

The communication system 10 provided by the embodiment of the present application will be introduced below with reference to FIG. 1 .

Figure 1 is a schematic structural diagram of a communication system 10 provided by an embodiment of the present application. As shown in FIG. 1 , the communication system 10 may include: a server 100 , a server 200 , and a vehicle 300 . in:

The server 100 may refer to a server used by a software supplier to maintain vehicle components, which may be referred to as a supplier server below. The server 100 is a server that develops and provides upgrade packages required for vehicle upgrades. The number of servers 100 may be one or more. The server 100 may store one or more upgrade files for upgrading vehicle components. The server 100 may sign the one or more upgrade files, obtain the package signatures of the one or more upgrade files, and convert the one or more upgrade files into The upgrade file and the package signature are packaged into an installation package and sent to the server 200. The package signature is used to prove that the installation package is sent by the server 100 and has not been tampered with during transmission. The specific description of package signature can be found in the following content, which will not be discussed here.

The server 200 may refer to a vehicle manufacturer's server, which may be referred to as a vehicle cloud server below. The server 200 is used to manage vehicle upgrades. The number of servers 200 may be one or more. The server 200 can obtain the installation packages for different components of the vehicle from the servers of various software suppliers (for example, the server 100), perform an outer signature on the installation package, and package the installation package and the outer signature to obtain an upgrade package. The outer signature proves that the upgrade package was sent by the server 200 and has not been tampered with during transmission. In addition, the server 200 can also obtain the asset information of the vehicle 300, generate an authorization file based on the asset information, and directly interact with the vehicle to send the upgrade package and authorization file to the vehicle for the vehicle to upgrade. Among them, the asset information may include the software and hardware versions of the vehicle 300, as well as vehicle identification, anti-replay parameters, and so on. The specific description of the outer signature can be found in the following content, and will not be discussed here.

Vehicle 300 may refer to a vehicle that needs to be upgraded. The vehicle 300 can be used to send asset information to the server 200, receive upgrade packages and authorization files, and verify the authorization files, including signature verification in the authorization file, verification of anti-replay parameters, verification of vehicle identity, Verification of integrity information, etc., as well as verification of the outer signature and inner signature in the upgrade package, and vehicle upgrades are implemented based on the upgrade package. For details about the verification of the authorization file and the verification process of the outer signature and the inner signature in the upgrade package, please refer to the following content, which will not be discussed here.

In some embodiments, in a remote upgrade scenario, the server 100 can package and sign one or more upgrade files, and package the upgrade files and package signatures into an installation package and send it to the server 200, and the server 200 can obtain Installation packages of different versions and for different components of the vehicle are externally signed and packaged to obtain upgrade packages for different components of the vehicle. When the vehicle 300 needs to be upgraded, the server 200 can determine the upgrade version applicable to the vehicle 300 , the upgrade package of the component to be upgraded, generates the authorization file of the upgrade package, and sends the upgrade package and the authorization file to the vehicle 300. The vehicle 300 then verifies the authorization file and the signature in the upgrade package. After the verification is passed, according to the Upgrade packages for vehicle upgrades.

In other embodiments, in a near-end upgrade scenario, the communication system 10 may also include an electronic device 400. The electronic device 400 relays the upgrade package sent to the vehicle 300 by the server 200 . For example, the electronic device 400 can be used to obtain the upgrade package and the authorization file sent by the server 200, and import the upgrade package and the authorization file into the vehicle 300 through wired transmission. For example, the electronic device 400 may refer to equipment such as a diagnostic instrument and a computer in a car sales store.

In the embodiment of the present application, the only difference between the near-end upgrade and the remote upgrade is that when the vehicle 300 needs to be upgraded, the vehicle 300 can interact with the server 200 through the relay of the electronic device 400 . That is to say, when the vehicle is upgraded through near-end upgrade, the server 200 can send the upgrade package to the electronic device 400, and the electronic device 400 then imports the upgrade package into the vehicle 300 through wired transmission, and the vehicle 300 then according to the Upgrade packages for vehicle upgrades.

The embodiment of the present application does not limit the communication connection method between the server 100, the server 200, the vehicle 300 and the electronic device 400. Specifically, the communication connection may be a wired connection or a wireless connection. Among them, the wireless connection can be a high-fidelity wireless communication (wireless fidelity, Wi-Fi) connection, a Bluetooth connection, an infrared connection, an NFC connection, a ZigBee connection and other short-range connections, or it can be a long-distance connection, and the long-distance connection includes but does not Limited to long-distance connections based on mobile networks based on 2G, 3G, 4G, 5G and subsequent standard protocols. For example, the server 100 may send the upgrade package and the signature of the upgrade package to the server 200 through a wireless connection.

In addition, it should be noted that the server mentioned in the embodiments of this application, such as server 100 or server 200, etc., may be one server or a server cluster composed of multiple servers. For example, the server 200 can be a server cluster in which multiple servers are deployed through a distributed architecture. The cluster can include a cloud computing server, a Content Delivery Network (Content Delivery Network, CDN) server, and a Network Time Protocol (Network Time Protocol). NTP), Domain Name System (Domain Name System, DNS) server, etc. One or more. Among them, various servers can coordinate with each other to jointly complete functions such as computing, data storage, and communication. For example, the server 200 can include a server 201 and a server 202. Both the server 201 and the server 202 include upgrade packages provided by various software vendors. The vehicle 300 can interact with the server 201 to complete the vehicle upgrade, and can also interact with the server 202 to complete the vehicle upgrade. upgrade. For convenience of description, in the embodiments of this application, a single server, a distributed server, a server cluster, etc. are collectively referred to as servers.

For a specific explanation of the concepts of remote upgrade and near-end upgrade, please refer to the above content and will not be repeated here. For details about the detailed interaction process between the devices during the remote upgrade and local upgrade processes, please refer to subsequent method embodiments, and will not be described in detail here.

FIG. 2A is a schematic structural diagram of a vehicle 300 provided by an embodiment of the present application.

As shown in Figure 2A, the vehicle 300 includes: a controller area network (CAN) bus 11, a plurality of electronic control units (ECUs), an engine 13, and a vehicle box (telematics box, T-box) 14. Transmission 15. Driving recorder 16. Antilock brake system (ABS) 17. Sensor system 18. Camera system 19. Microphone 20, etc.

The CAN bus 11 is a serial communication network that supports distributed control or real-time control and is used to connect various components of the vehicle 300 . Any component on the CAN bus 11 can monitor all data transmitted on the CAN bus 11. The frames transmitted by CAN bus 11 can include data frames, remote frames, error frames, and overload frames. Different frames transmit different types of data. In the embodiment of the present application, the CAN bus 11 can be used to transmit data involved in various components in the control method based on voice instructions. For the specific implementation of this method, please refer to the detailed description of the method embodiment below.

Not limited to the CAN bus 11, in some other embodiments, various components of the vehicle 300 can also be connected and communicated through other methods. For example, each component can also communicate through the vehicle Ethernet (ethernet) local interconnect network (LIN) bus, FlexRay and common vehicle network system (media oriented systems, MOST) bus, etc., the embodiments of this application are No restrictions. The following embodiments are described based on the communication of various components through the CAN bus 11.

The ECU is equivalent to the processor or brain of the vehicle 300 and is used to instruct corresponding components to perform corresponding actions according to instructions obtained from the CAN bus 11 or according to operations input by the user. ECU can be composed of a security chip, a microprocessor (microcontroller unit, MCU), a random access memory (random access memory, RAM), a read-only memory (random-only memory, ROM), and an input/output interface (I/O). , analog/digital converter (A/D converter) and input, output, shaping, drive and other large-scale integrated circuits.

There are many types of ECUs, and different types of ECUs can be used to implement different functions.

The multiple ECUs in the vehicle 300 may include, for example: an engine ECU 121, a telematics box (T-box) ECU 122, a transmission ECU 123, a driving recorder ECU 124, an anti-lock brake system (antilock brake system, ABS) ECU 125, etc.

The engine ECU121 is used to manage the engine and coordinate various functions of the engine. For example, it can be used to start the engine, shut down the engine, etc. The engine is the device that powers vehicle 300 . An engine is a machine that converts some form of energy into mechanical energy. The vehicle 300 may be used to burn chemical energy of liquid or gas, or convert electrical energy into mechanical energy and output power to the outside. The engine components can include two major mechanisms, the crank connecting rod mechanism and the valve mechanism, as well as five major systems including cooling, lubrication, ignition, energy supply, and starting system. The main components of the engine include cylinder block, cylinder head, piston, piston pin, connecting rod, crankshaft, flywheel, etc.

T-box ECU122 is used to manage T-box14.

T-box14 is mainly responsible for communicating with the Internet, providing a remote communication interface for the vehicle 300, including navigation, entertainment, Driving data collection, driving trajectory recording, vehicle fault monitoring, vehicle remote query and control (such as opening and closing, air conditioning control, window control, engine torque limit, engine start and stop, seat adjustment, battery power, fuel level, door status query etc.), driving behavior analysis, wireless hotspot sharing, roadside assistance, abnormality reminder and other services.

T-box14 can be used to communicate with car telematics service provider (TSP) and user (such as driver) side electronic devices to realize vehicle status display and control on electronic devices. When the user sends a control command through the vehicle management application on the electronic device, the TSP will send a request command to T-box14. After obtaining the control command, T-box14 sends a control message through the CAN bus and controls the vehicle 300. Finally, the operation results are fed back to the vehicle management application on the user-side electronic device. In other words, the data read by T-box14 through CAN bus 11, such as vehicle condition reports, driving reports, fuel consumption statistics, violation inquiries, location tracks, driving behavior and other data, can be transmitted to the TSP backend system through the network, and the TSP The background system forwards it to the electronic device on the user side for viewing by the user.

T-box14 may specifically include a communication module and a display screen.

Among them, the communication module can be used to provide wireless communication functions to support the vehicle 300 through wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), Bluetooth (bluetooth, BT), global navigation Satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field communication technology (near field communication, NFC), infrared technology (infrared, IR), ultra-wideband (UWB), etc. Wireless communication technology communicates with other devices. The communication module can also be used to provide mobile communication functions to support the vehicle 300 through the global system for mobile communications (GSM), universal mobile telecommunications system (UMTS), wideband code division multiple access (wideband code division) multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), 5G and 6G and other communication technologies that will appear in the future and communicate with other devices.

The communication module can establish connections and communicate with other devices such as servers and user-side electronic devices through vehicle to everything (V2X) communication technology (cellular V2X, C-V2X) based on cellular networks. C-V2X may include, for example, V2X based on long term evolution (LTE) (LTE-V2X), 5G-V2X, etc.

In some embodiments, the communication module can be used to implement communication between the vehicle 300 and a server, such as the server 200, and send asset information in the vehicle 300, such as software and hardware versions, vehicle identification, anti-replay parameters, etc., to the server. , so that the server can determine the upgrade package applicable to the vehicle 300, and the communication module can also be used to obtain the upgrade package and authorization file sent by the server, etc.

The display screen is used to provide a visual interface to the driver. The vehicle 300 may include one or more display screens, for example, it may include a vehicle-mounted display screen disposed in front of the driver's seat, a display screen disposed above the seat for displaying surrounding conditions, and may also include projecting information onto the windshield. Head-up digital display (HUD) on the computer, etc.

T-box 14 may also be called a vehicle-machine system, a telematics processor, a vehicle gateway, etc., and the embodiments of this application do not limit this.

The transmission ECU123 is used to manage the transmission.

The transmission 15 can be used to change the engine speed and torque. It can fix or change the output shaft and input shaft transmission ratios in stages. The components of the transmission 15 may include a transmission mechanism, a control mechanism, a power output mechanism, etc. The main function of the speed change transmission mechanism is to change the value and direction of torque and rotational speed; the main function of the control mechanism is to control the transmission mechanism to realize the transformation of the transmission ratio, that is, to achieve gear shifting, in order to achieve variable speed and torque.

The driving recorder ECU 124 is used to manage the driving recorder 16 .

The driving recorder 16 components may include a host computer, a vehicle speed sensor, data analysis software, etc. The driving recorder 16 refers to an instrument that records the images and sounds of the vehicle during driving, including driving time, speed, location and other related information. exist In the embodiment of the present application, when the vehicle is driving, the vehicle speed sensor collects the wheel speed and sends the vehicle speed information to the driving recorder 16 through the CAN bus.

ABS ECU125 is used to manage ABS17.

ABS17 automatically controls the braking force of the brake when the vehicle is braking, so that the wheels are not locked and are in a rolling and sliding state to ensure the maximum adhesion between the wheels and the ground. During the braking process, when the electronic control device determines that a wheel tends to lock based on the wheel speed signal input by the wheel speed sensor, the ABS will enter the anti-lock brake pressure adjustment process.

The sensor system 18 may include: an acceleration sensor, a vehicle speed sensor, a vibration sensor, a gyroscope sensor, a radar sensor, a signal transmitter, a signal receiver, etc. The acceleration sensor and the vehicle speed sensor are used to detect the speed of the vehicle 300 . The shock sensor can be disposed under the seat, on the seat belt, on the seat back, on the operating panel, on the airbag or in other locations to detect whether the vehicle 300 is collided and where the user is. A gyro sensor may be used to determine the motion attitude of vehicle 300 . Radar sensors can include lidar, ultrasonic radar, millimeter wave radar, etc. The radar sensor is used to emit electromagnetic waves to illuminate the target and receive its echo, thereby obtaining information such as the distance from the target to the electromagnetic wave emission point, distance change rate (radial velocity), orientation, altitude, etc., thereby identifying other vehicles near the vehicle 300 , pedestrians or roadblocks, etc. The signal transmitter and signal receiver are used to send and receive signals. The signals can be used to detect the location of the user. The signals can be, for example, ultrasonic waves, millimeter waves, lasers, etc.

Camera system 19 may include multiple cameras for capturing still images or video. The cameras in the camera system 19 can be set in front, behind, side, or inside the car to facilitate functions such as assisted driving, driving recording, panoramic view, and in-car monitoring.

The sensor system 18 and the camera system 19 can be used to detect the surrounding environment to facilitate the vehicle 300 to make corresponding decisions to respond to environmental changes. For example, they can be used to complete the task of paying attention to the surrounding environment during the autonomous driving phase.

Microphone 20, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or outputting a voice command, the user can speak close to the microphone 20 with the human mouth and input the sound signal to the microphone 20 . The vehicle 300 may be provided with at least one microphone 20 . In other embodiments, the vehicle 300 may be provided with two microphones 20, which in addition to collecting sound signals, may also implement a noise reduction function. In other embodiments, the vehicle 300 can also be equipped with three, four or more microphones 20 to form a microphone array to collect sound signals, reduce noise, identify sound sources, and implement directional recording functions, etc.

In addition, the vehicle 300 may also include multiple interfaces, such as a USB interface, an RS-232 interface, an RS485 interface, etc., and may be connected to external cameras, microphones, headphones, and user-side electronic devices.

In this embodiment of the present application, the microphone 20 may be used to detect voice instructions input by the user. The sensor system 18, the camera system 19, the T-box 14, etc. can be used to obtain the character information of the user who inputs the voice command. For the manner in which each component in the vehicle 300 obtains the user's role information, please refer to the relevant descriptions in subsequent method embodiments. The T-box ECU 122 can be used to determine whether the current user has the permission corresponding to the voice command based on the role information. Only if the user has the permission, the T-box ECU 122 dispatches the corresponding components in the vehicle 300 to respond to the voice command.

In some embodiments, the memory in the vehicle 300 may be used to store the vehicle identity, anti-replay parameters, public keys and hash values of the public keys, and the like. For details about the content stored in the vehicle 300, please refer to the following content, which will not be discussed here.

It can be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the vehicle system. The embodiment of the present application does not limit the number of electronic control units ECU. Vehicle 300 may include more or fewer components than illustrated, some components combined, some components separated, or different component arrangements. The components illustrated may be implemented in hardware, software, or a combination of software and hardware.

For example, the vehicle 300 may also include a separate memory, battery, lights, wipers, instrument panel, audio, vehicle terminal (transmission control unit, TCU), auxiliary control unit (auxiliary control unit, ACU), smart entry and start-up. Passive entry passive start (PEPS), on board unit (OBU), body control module (BCM), charging interface, etc.

FIG. 2B illustrates an electrical and electronic architecture diagram of the vehicle 300 .

It can be seen from FIG. 2A that the vehicle 300 includes multiple components. According to the multiple components included in the vehicle 300, the software and hardware of the vehicle 300 can be divided to obtain the overall layout plan of the vehicle electronic and electrical system. As shown in Figure 2B, the vehicle 300 can be divided into multiple functional domains. One functional domain can include a domain controller (Domain Controller, DC) and multiple connected electronic control units (ECUs) and other components. For example, the functional domains of the vehicle may include: power domain, chassis domain, cockpit domain, body domain, and autonomous driving domain.

It should be understood that the upgrade of a vehicle actually refers to the upgrade of each component installed in the vehicle. Upgrades of components in different functional domains are mainly managed by their respective functional domains.

For vehicle upgrades, the domain controller DC contains two logical functional modules: Domain Upgrade Controller (Domain Update Controller, DUC) and Domain Installer (Domain Installer, DI). in:

The domain upgrade controller DUC is responsible for the upgrade packages of all components in the domain, downloading the authorization files of the upgrade packages, verifying the legality of the upgrade packages, and overall control of the upgrade of components in the domain. Wherein, the domain upgrade controller DUC's legality verification of the upgrade package may refer to verification of the outer signature in the upgrade package, and this verification is used to determine the source of the upgrade package (for example, the server 200 shown in Figure 1 ) is legal, whether the contents of the upgrade package have been tampered with, etc. The specific description of the outer signature can be found in the following content, and will not be discussed here.

The domain installer DI is responsible for verifying the authorization file, verifying the legality of the upgrade package of this domain, and checking the conditions of the vehicle before upgrading, including voltage, speed, etc., before installing the upgrade package, and upgrading. During the process, the components of this domain are upgraded and refreshed. The legality verification of the upgrade package by the domain installer DI may refer to the verification of the package signature in the upgrade package. This verification is used to determine whether the source of the upgrade package (for example, the server 100 shown in Figure 1) Legal, whether the contents of the upgrade package have been tampered with, etc. Among them, the verification of authorization files includes verification of vehicle identity, verification of anti-replay parameters, verification of integrity information, signature verification of authorization files, etc. Specific descriptions of packaged signatures and authorization files can be See the subsequent content, which will not be expanded upon here.

In addition, the vehicle 300 also includes a Vehicle Update Controller (VUC), which is deployed on a certain domain controller DC.

Among them, during the vehicle upgrade process, the vehicle upgrade controller VUC can be responsible for interacting with the server (such as the server 200 shown in Figure 1) and uploading asset information to the server, such as software and hardware versions, vehicle identification, and anti-replay parameters. Wait, obtain the Download Policy (DP) package from the server. Among them, the DP package can include the download address of the upgrade package of each functional domain. The vehicle upgrade controller VUC can be used to parse the DP package, send the download address of the upgrade package to the domain controller DC of the corresponding functional domain, and coordinate the upgrade. Download and install the package so that each domain controller DC can download the upgrade package for the components in the functional domain, thereby completing the upgrade of each component of the vehicle. Specific descriptions of the DP package and obtaining the upgrade package through the DP package can be found in subsequent method embodiments, which will not be discussed here.

It can be understood that the module for verifying the authorization file is not limited to the domain installer DI. For example, the authorization file is verified through the domain upgrade controller DUC. The embodiment of the present application does not limit the module for verifying the authorization file.

In addition, the domain controller DC generally supports a secure boot function, which can use a preset public key, such as the public key in the key pair generated by the server 100, to verify whether the software loaded on the vehicle is trusted. In other words, only software signed by the private key corresponding to the public key can pass verification and start normally inside the vehicle, while software that fails verification cannot be loaded. In this way, attackers can be prevented from directly disassembling the vehicle components and maliciously reading and writing the vehicle's software. Harm the commercial interests of car manufacturers and software manufacturers.

In the embodiment of this application, after the vehicle receives the upgrade package and the authorization file, and completes the upgrade of the vehicle components according to the upgrade package, the verification of the authorization file can be triggered again when the components are safely started through the safe start function. This further prevents attackers from directly disassembling the machine, importing upgrade packages that are not applicable to the vehicle, and changing components to software programs that have been upgraded through the upgrade packages. Due to the secure startup process of components, specifically the step-by-step startup of software, that is, the upper-level software starts the lower-level software, and before starting the lower-level software, the security of the lower-level software is verified, including the authorization file. Verification, package signature verification, etc. If the verification passes, it means that the next-level software is safe, and the control flow is handed over to the next-level software, and the security of the software continues to be verified, and so on, until the component If all the software passes the verification, it means that the software in the component is safe, that is, the software comes from the software supplier and has not been tampered with by the attacker, and the source of the software is not an old version upgrade package, an upgrade package for other vehicles, or one used in the research and development stage. upgrade packages, etc. Furthermore, if the component is upgraded using the upgrade package sent by the car cloud server, and the verification of the authorization file passes during the secure startup phase, it means that the program currently running on the component is imported into the program after being upgraded with the upgrade package sent by the car cloud server. The software data of this component avoids the need for vehicles to run old version upgrade packages, upgrade packages for other vehicles, upgrade packages used in the research and development stage, and other software data in upgrade packages.

It can be seen that verifying the authorization file during the safe startup phase of the vehicle can prevent the vehicle from running unverified programs and prevent attackers from directly disassembling upgrade packages that are not applicable to the vehicle, such as old version upgrade packages and other upgrade packages. The software data in the vehicle's upgrade package and the upgrade package used in the research and development phase are imported into the vehicle, thereby strictly controlling the safe operation of the vehicle during the startup phase, ensuring the safety of the vehicle and maintaining the business of the car factory and software manufacturer. Benefit.

For a detailed description of the secure boot process, please refer to the following content, so I won’t go into details here.

The above electronic and electrical architecture diagram is only an illustrative example and does not constitute a limitation of the present application. It should be understood that in other embodiments of the present application, the electronic and electrical architecture diagram of the vehicle may also have other structures, and the embodiment of the present application does not limit the above electronic and electrical architecture. There are no restrictions on the names of domain controller DC, domain upgrade controller DUC, domain installer DI, and vehicle upgrade controller VUC mentioned in the architecture diagram.

FIG. 3 is a hardware structure diagram of the electronic device 500 provided by the embodiment of the present application.

As shown in FIG. 3 , electronic device 500 may include: one or more processors 201 , memory 202 , communication interface 203 , transmitter 205 , receiver 206 , coupler 207 and antenna 208 . These components can be connected through the bus 204 or other ways. Figure 3 takes the connection through the bus as an example. in:

The communication interface 203 may be used between the electronic device 500 and other communication devices, such as the electronic device 400 . Specifically, the communication interface 203 may be a 3G communication interface, a Long Term Evolution (LTE) (4G) communication interface, a 5G communication interface, a WLAN communication interface, a WAN communication interface, etc. Not limited to wireless communication interfaces, the electronic device 500 can also be configured with a wired communication interface 203 to support wired communication. For example, the backhaul link between the electronic device 500 and other servers can be a wired communication connection.

In some embodiments of the present application, transmitter 205 and receiver 206 may be viewed as a wireless modem. The transmitter 205 can be used to transmit the signal output by the processor 201. Receiver 206 may be used to receive signals. In the electronic device 500, the number of each of the transmitter 205 and the receiver 206 may be one or more. Antenna 208 may be used to convert electromagnetic energy in the transmission line into electromagnetic waves in free space, or to convert electromagnetic waves in free space into electromagnetic energy in the transmission line. The coupler 207 can be used to split the mobile communication signal into multiple channels and distribute them to multiple receivers 206 . It can be understood that the antenna 208 of the electronic device 500 can be implemented as a large-scale antenna array.

Memory 202 is coupled to processor 201 for storing various software programs and/or sets of instructions. Specifically, the memory 202 may include high-speed random access memory, and may also include non-volatile memory, such as one or more disk memories. storage device, flash memory device or other non-volatile solid-state storage device.

The memory 202 can store an operating system (hereinafter referred to as the system), such as uCOS, VxWorks, RTLinux and other embedded operating systems.

In this embodiment of the present application, the processor 201 may be used to read and execute computer-readable instructions.

In this embodiment of the present application, when the electronic device 500 is a supplier server:

The transmitter 205 can be used to send the installation package to the car cloud server.

The processor 201 may be configured to generate a key for package signing, and perform package signing on one or more upgrade files.

Memory 202 may be used to store locally generated keys, such as private keys used to package-sign upgrade files.

In this embodiment of the present application, when the electronic device 500 is a car cloud server:

The transmitter 205 can be used to send DP packages, upgrade packages, authorization files, etc. to the vehicle or diagnostic terminal.

The receiver 206 may be used to receive installation packages sent by the supplier server, as well as asset information, download requests, etc. sent by the vehicle or diagnostic terminal.

The processor 201 can be used to generate a key pair, perform an outer signature on the installation package, determine the upgrade package based on the asset information, and generate authorization files and DP packages, etc.

The memory 202 may be used to store the upgrade package and locally generated keys, such as a private key used to sign the vehicle identity, anti-replay parameters, and integrity information, and a private key used to sign the outer layer of the installation package.

It should be noted that the electronic device 500 shown in FIG. 3 is only an implementation manner of the embodiment of the present application. In actual applications, the electronic device 500 may also include more or fewer components, which is not limited here.

The following describes the vehicle verification method in the remote upgrade scenario with reference to Figure 4.

Figure 4 is a schematic flowchart of the vehicle verification method in the remote upgrade scenario provided by the embodiment of the present application.

The remote upgrade scenario mainly involves the interaction between the supplier server, the vehicle cloud server, and the vehicle. The vehicle can obtain the upgrade package through wireless communication to complete the vehicle upgrade. For specific explanations of remote upgrades and the communication systems involved in remote upgrades, please refer to the relevant content mentioned above and will not be repeated here.

As shown in Figure 4, the vehicle verification method may include:

S101. The supplier server signs one or more upgrade files and generates an installation package.

The supplier server may refer to a server where the software supplier maintains vehicle components. After the developer develops an upgrade file for the vehicle component, the supplier server can obtain the newly developed upgrade file. For example, the supplier server may refer to the server 100 shown in Figure 1. For a specific description of the server 100, please refer to the relevant content of Figure 1, which will not be described again here.

For an upgrade of a vehicle component, the supplier server may provide one or more upgrade files for upgrading the component. The one or more upgrade files can be used to achieve upgrade effects such as operating system updates for vehicle components, application software version updates, bug fixes, etc. Specifically, the one or more upgrade files may be used to upgrade one or more software included in the component. Among them, an upgrade file can contain upgrade data of a software in the component.

Signing one or more upgrade files specifically refers to digitally signing the one or more upgrade files respectively, and obtaining the package signature of the one or more upgrade files. The supplier server may compress the one or more upgrade files and the one or more packaging signatures to generate an installation package.

Among them, a digital signature, also known as a public key digital signature, is a digital string that can only be generated by the sender of the information and cannot be forged by others. This digital string is also an effective proof of the authenticity of the information sent by the sender of the information. Specifically, the sender can generate a pair of keys and use the private key in the key pair to sign the information through a signature algorithm. Afterwards, the recipient can use the public key in the key pair to verify the signature through the signature verification algorithm to determine whether the information comes from to the sender of the information and whether it has been tampered with during the sending process. In other words, data signatures can ensure the legitimacy of the information, which includes that the source of the information is legitimate and has not been tampered with.

In other words, the supplier server uses its own private key to package and sign the upgrade file, so that the recipient of the upgrade file can confirm the source of the upgrade file based on the package signature and prevent others from impersonating the supplier server and sending it out. a.

For example, the supplier server can generate a pair of keys, including public key 1 and private key 1, where private key 1 is kept locally and is used to sign the upgrade file, and public key 1 can be sent to the vehicle for After the vehicle obtains the upgrade package, it verifies the package signature.

It should be noted that the supplier server can send the public key used to verify the packet signature, such as public key 1, to the vehicle when the vehicle is upgraded, or it can be sent to the vehicle through the vehicle cloud server, such as , when the supplier server sends the installation package to the car cloud server, it also sends the public key to the car cloud server. For details about the process of the supplier server sending the installation package to the car cloud server, please refer to the content of subsequent step S102. Alternatively, the supplier server can send the public key used to verify the signature to the CheCloud server in advance before signing the upgrade file. Alternatively, the vehicle can directly preset the public key for verifying the signature into the vehicle's chip during the vehicle production line stage. The embodiment of this application does not limit the method and time for the vehicle to obtain the public key.

It can be understood that the signature of the upgrade file performed by the supplier server can also be called an inner signature, a small package signature, a package signature, etc., and the embodiment of this application does not limit this name.

Furthermore, the supplier server can use multi-level keys to implement package signatures for upgrade files. In other words, the supplier server can generate multiple pairs of keys, and implement the package signature of the upgrade file through the step-by-step signature of the upper-level private key to the lower-level public key. Correspondingly, when verifying the packaged signature, it is necessary to verify the packaged signature through level-by-level verification of the signature of the lower-level public key by the upper-level public key.

The following uses the third-level key as an example to introduce the detailed process of the supplier server signing the upgrade file.

First, the supplier server generates three pairs of keys: the packaged root public key and the packaged root private key, the packaged layer 2 public key and the packaged layer 2 private key, the packaged layer 3 public key and the packaged layer 3 private key.

Figure 5 is a schematic logical structure diagram of the supplier server signing the upgrade file provided by the embodiment of the present application.

The supplier server's signing of the upgrade file mainly includes the following steps:

1) The supplier server uses the compilation root private key to sign the compilation layer 2 public key and obtains the signature of the compilation layer 2 public key.

2) The supplier server uses the second-layer private key to sign the third-layer public key and obtains the signature of the third-layer public key.

3) The supplier server uses the packaged three-layer private key to sign the upgrade file and obtains the packaged signature.

After that, when sending the installation package to the Cheyun server, the supplier server can include the above-mentioned packaged root public key, packaged second-level public key, packaged layer-2 public key signature, packaged layer-3 public key, packaged layer-2 public key, and packaged layer-2 public key. The signature and packaged signature containing the third-level public key are sent to the vehicle, or forwarded to the vehicle through the vehicle cloud server. When the vehicle verifies the packaged signature in the upgrade package, it can use the above-mentioned packaged root public key, packaged second-level public key, etc. The public key, the signature of the second-layer public key, the third-layer public key, the signature of the third-layer public key, and the signature are verified. For details about the verification of the signature, please refer to the subsequent step S115. The relevant content will not be expanded upon here.

It can be understood that the embodiment of the present application does not limit the number of key levels used by the supplier server. For example, the supplier server can generate four pairs of keys to implement the package signature of the upgrade file. The principle is similar to the above-mentioned supplier. The process of the server using the third-level key to sign the upgrade file will not be described again here.

S102. The supplier server sends the installation package to the Cheyun server.

It is understandable that the supplier server sends the installation package to the car cloud server, and accordingly, the car cloud server receives it. Installation package from vendor server.

The car cloud server refers to a server that directly interacts with the vehicle. It can obtain and store installation packages sent by servers of multiple software vendors, and send the upgrade package to the vehicle when the vehicle needs to be upgraded. Among them, the upgrade package is a packaged file of the installation package and the outer signature of the installation package. The specific description of the upgrade package and the outer signature can be found in the following content, which will not be discussed here.

The vehicle may refer to the terminal device where the vehicle is located, and the vehicle may be used to receive an upgrade package and implement vehicle upgrades based on the upgrade package.

For example, the vehicle cloud server may refer to the server 200 shown in FIG. 1 , and the vehicle may refer to the vehicle 300 shown in FIG. 1 . For specific descriptions of the server 200 and the vehicle 300, please refer to the relevant content in Figure 1 and will not be described again here.

It can be understood that the supplier server may not package and sign the upgrade file, and the embodiment of the present application does not limit this. In other words, S101 is an optional step, so the installation package sent by the supplier server to the car cloud server in step S101 may include the upgrade file, but not the package signature. In addition, the supplier server does not need to compress the upgrade file and the package signature of the upgrade file. That is to say, the data sent by the supplier server to the Cheyun server is not necessarily an installation package. The supplier server can directly compress the upgrade file and package signature. The package signature is sent to the car cloud server. The embodiment of this application does not limit the data form of the data sent by the supplier server to the car cloud server. In addition, the embodiment of this application does not limit the name of the installation package sent by the supplier server to the car cloud server. The installation package may also be called a software package, an upgrade package, a compressed package, etc.

S103. The Cheyun server signs the installation package and generates an upgrade package.

Specifically, after receiving the installation package sent by the supplier server, the car cloud server can perform data signature on the installation package to obtain the outer signature of the installation package. Afterwards, the Cheyun server can package the installation package and the outer signature to generate the upgrade package and archive the installation package sent by the supplier server. For specific descriptions of digital signatures, please refer to the relevant content mentioned above and will not be repeated here.

The upgrade package can be used to enhance or add vehicle functions, such as autonomous driving functions, navigation functions, etc. In the embodiment of the present application, this function can also be called the first function.

The CheCloud server signs the installation package so that the recipient of the installation package can determine the source of the installation package based on the signature, preventing others from impersonating the CheCloud server and sending out upgrade packages containing the installation package.

For example, the car cloud server can generate a pair of keys, including public key 2 and private key 2. Private key 2 is retained locally and is used to sign the installation package. Public key 2 can be sent to the vehicle for signing. The vehicle verifies the signature after obtaining the upgrade package.

It should be noted that the signature of the installation package performed by the car cloud server can also be called a large package signature, an outer signature, a vehicle manufacturer (Original Equipment Manufacturer, OEM) signature, etc. The embodiment of this application does not limit this name.

It is understandable that the car cloud server may not sign the installation package, and in this case, step S103 is optional.

In addition, the embodiment of the present application does not limit the name of the upgrade package. In other embodiments of the present application, the upgrade package may also be called a software package, an installation package, a software upgrade package, a software installation package, an installation file, etc. In addition, it should be noted that the installation package sent by the supplier server to the car cloud server can also be called an upgrade package. In the embodiment of the present application, in order to distinguish the files for vehicle upgrade sent by the supplier server to the car cloud server, and The files sent by the car cloud server to the supplier server for vehicle upgrade are called installation packages, and the files sent by the car cloud server to the vehicle are called upgrade packages. It should be understood that this name does not constitute a limitation on the embodiments of the present application.

S104. The vehicle sends asset information to the vehicle cloud server.

It can be understood that the vehicle sends asset information to the vehicle cloud server, and accordingly, the vehicle cloud server receives the asset information from the vehicle.

Asset information is used to describe relevant information required for vehicle upgrades, including but not limited to one or more of the following: software and hardware version information, vehicle identification, anti-replay parameters for this upgrade, etc. Among them, the software and hardware version information can be used to determine the version of the upgrade package used for the software and hardware upgrade of the vehicle, the vehicle identity identifier can be used to identify the upgraded vehicle, and the anti-replay parameters can identify the upgrade. Further, the vehicle identity can be used to uniquely identify the upgraded vehicle, and the anti-replay parameters can uniquely identify the upgraded vehicle.

Among them, the vehicle can obtain the version information of the software and hardware by querying the software and hardware installed in the vehicle. The specific description of vehicle identification and anti-replay parameters can be found in the following content, and will not be discussed here. For a detailed description of the vehicle identity and anti-replay parameters, please refer to the subsequent specific implementation of the vehicle identity and anti-replay parameters, which will not be discussed here.

For example, the vehicle can send asset information to the vehicle cloud server when it needs to be upgraded. Alternatively, the vehicle can periodically send asset information to the vehicle cloud server. In this way, the vehicle can periodically update the asset information obtained by the vehicle cloud server. The embodiment of this application does not limit the triggering timing of asset information sent by the vehicle.

Vehicles can trigger upgrades in the following two situations:

1) The vehicle detects user operations and triggers upgrades

In this case, the vehicle can, after detecting the user's upgrade operation, send asset information to the vehicle cloud server in response to the operation, triggering the upgrade of the vehicle.

In this way, users can decide whether to upgrade their vehicles, control the time of vehicle upgrades, and enhance users' control over vehicle upgrades.

2) The vehicle receives the upgrade instruction from the car cloud server and triggers the upgrade.

In this case, after receiving the upgrade instruction from the car cloud server, the vehicle can send the asset information to the car cloud server to trigger the upgrade of the vehicle.

In this way, the vehicle can passively trigger vehicle upgrades under the control of the vehicle cloud server.

It can be understood that the triggering timing of vehicle upgrade is not limited to the above two situations. The vehicle can trigger the upgrade in combination with the above situations. For example, the vehicle can detect the upgrade instruction of the car cloud server and the user's upgrade operation at the same time. The asset information is triggered to be sent to the vehicle cloud server. The embodiment of the present application does not limit the triggering timing of the vehicle upgrade.

In specific implementation, the vehicle can send asset information to the vehicle cloud server through the vehicle upgrade controller VUC. For a specific description of the vehicle upgrade controller VUC, please refer to the relevant content in Figure 2B, which will not be described again here.

S105. The car cloud server determines the upgrade package based on the asset information.

For example, the vehicle cloud server may trigger the determination of the upgrade package after receiving the asset information, or the vehicle cloud server may trigger the determination of the upgrade package based on the asset information when the vehicle has an upgrade requirement, such as when an upgrade request from the vehicle is received.

Specifically, the car cloud server can determine the components of the vehicle to be upgraded based on the software and hardware version information in the asset information and the upgrade version of the installation package obtained by the car cloud server from the supplier server, thereby determining the upgrade package that needs to be sent to the vehicle. , this upgrade package is the upgrade package for the vehicle parts to be upgraded. For example, assume that the asset information indicates that the software version of the first component of the vehicle is V2. When the vehicle cloud server stores the V3 version upgrade package of the first component, the vehicle cloud server can determine that the first component is the version that needs to be upgraded. , then it is determined that the first component is a component to be upgraded of the vehicle, and the V3 version upgrade package of the first component is an upgrade package that needs to be sent to the vehicle.

It should be noted that in step S103, the CheCloud server signs the installation package, or execution can be triggered after the CheCloud server receives the asset information and determines the installation package that meets the requirements based on the asset information. In other words, this application actually The embodiment does not limit the timing when the CheCloud server signs the installation package.

S106. The car cloud server generates an authorization file.

The authorization file may include but is not limited to one or more of the following parameters: vehicle identification, anti-replay parameters, and integrity information.

The vehicle identity can be used to uniquely identify the upgraded vehicle. For example, the vehicle identity can be obtained based on the vehicle identity in the asset information sent by the vehicle. The anti-replay parameter can identify this upgrade. For example, the anti-replay parameter can be obtained based on the anti-replay parameter in the asset information sent by the vehicle. The integrity information is used to identify the upgrade package sent by the car cloud server during this upgrade process. Furthermore, the integrity information is used to uniquely identify the upgrade package. For example, the integrity information may be a hash value calculated on the upgrade package using a hash function. The integrity information can be parameters calculated by the Che Cloud server based on the upgrade package, or can be parameters calculated by the server provided by the software supplier based on the upgrade package and sent to the Che Cloud server. For a specific description of the vehicle identity, anti-replay parameters, and integrity information, please refer to the subsequent specific implementation of the vehicle identity, anti-replay parameters, and integrity information, which will not be discussed here.

Further, the authorization file may also include a signature of the authorization file, and the signature of the authorization file is used to prove the legitimacy of the authorization file. The signature of the authorization file can be obtained by digitally signing the parameters in the authorization file using the private key (hereinafter referred to as the authorization private key) of the car cloud server.

For example, the signature of the authorization file may be a signature obtained by digitally signing the vehicle identity, anti-replay parameters, and integrity information in the authorization file. In this case, the signature of the authorization file can be implemented as an example. The car cloud server can generate a pair of keys, including public key 3 and private key 3. Private key 3 is retained locally and is used to calculate the authorization file. The signature, public key 3, can be sent to the vehicle for the vehicle to verify the signature after obtaining the authorization file.

It should be understood that when the authorization file only contains one or more parameters among the vehicle identification, anti-replay parameters, and integrity information, the signature of the authorization file is a signature calculated based on this one or more parameters.

Furthermore, the authorization file may also include a public key used to verify the signature of the authorization file (hereinafter referred to as the authorization public key), such as the above-mentioned public key 3. In this way, when the vehicle obtains the authorization file, the signature of the authorization file can be verified based on the authorization public key. Furthermore, the authorization file may also include a legality certificate used to prove that the authorized public key is legal. For a specific description of the legality certificate, please refer to the subsequent specific implementation, which will not be discussed here.

By way of example, Table 1 shows a structure of the authorization file provided by the embodiment of this application.

Table 1

As can be seen from Table 1, the authorization file can include three parts: attribute field M, signature field and verification public key field. Among them, the attribute domain M may include: vehicle identity identifier Space_Attr, anti-replay parameter Time_Attr, and integrity information Integrity_Attr. The signature field includes the signature Sig(sk,M) calculated by the car cloud server on the attribute field M using its own authorized private key sk (for example, private key 3). The verification public key field includes: the authorized public key pk (for example, public key 3) corresponding to the authorized private key sk. The authorized public key pk is used to verify the signature Sig(sk,M) in the signature field. In addition, verification The public key field may also include: a validity certificate pk_validity_proof used to verify that the authorized public key pk is legitimate.

It can be understood that the structure of the authorization file shown in Table 1 is only an illustrative example and does not constitute a limitation on the authorization file. In other embodiments of the present application, the attribute domain of the authorization file may contain more or less information. For example, the attribute field may only include the vehicle identity identifier Space_Attr and the anti-replay parameter Time_Attr. For another example, the verification public key field may not include the validity certificate pk_validity_proof. Alternatively, the authorization document is not limited to consisting of the above three parts. The embodiment of this application does not limit the structure of the authorization file.

In addition, it should be noted that the vehicle identity sent by the vehicle to the car cloud server mentioned in step S103 may be different from the vehicle identity in the authorization file mentioned in step S106. For details, please refer to the subsequent article on vehicle identity. In the implementation part, in addition, the asset information sent by the vehicle to the car cloud server may not include anti-replay parameters, and the authorization file returned by the car cloud server to the vehicle may include anti-replay parameters, that is, the asset information mentioned in step S103 , the anti-replay parameter may not be included, and the authorization file mentioned in step S106 may include the anti-replay parameter. For details, please refer to the subsequent implementation section on the anti-replay parameter, which will not be discussed here.

S107. The car cloud server determines the upgrade strategy.

Since the number of vehicle cloud servers can be one or more, upgrade packages for different components may be stored in different vehicle cloud servers. After determining the vehicle components to be upgraded, the vehicle cloud server can determine the location of the upgrade packages of these components to be upgraded. The storage address determines the upgrade strategy, which is used to indicate the download address of the upgrade package for the vehicle components to be upgraded.

The upgrade policy may refer to a download policy (DP) package, and the DP package may include download addresses of upgrade packages for multiple components of the vehicle to be upgraded, and the download addresses may be used to obtain the upgrade packages. For example, the download address may be a uniform resource locator (URL).

Optionally, the DP package may also include a download address of the authorization file, and the download address is used to obtain the authorization file. For example, the download address may be a URL.

Optionally, the DP package may also include one or more of upgrade rules, upgrade conditions, download rules, etc. Among them, upgrade rules can be used to define the order of the upgrade, whether rollback is required, and other rules. Upgrade conditions can include whether the power supply is normal, storage space, network status, etc. Download rules can be used to define the order of downloading and indicate the components of the upgrade package to be downloaded. etc. The embodiment of this application does not limit the content contained in the DP package.

S108. The vehicle cloud server sends the upgrade strategy to the vehicle.

The car cloud server sends the upgrade strategy to the vehicle, and accordingly, the vehicle obtains the upgrade strategy sent by the car cloud server.

In specific implementation, the vehicle can obtain the upgrade strategy through the vehicle upgrade controller VUC. For details about the vehicle upgrade controller VUC, please refer to the relevant content of Figure 2B mentioned above, and will not be described again here.

S109. The vehicle resolves the download address according to the upgrade strategy.

The download address may include a storage address, such as a first address, of an upgrade package for one or more components of the vehicle.

Optionally, the download address may also include the storage address of the authorization file of the upgrade package.

Specifically, the vehicle can parse the upgrade strategy through the vehicle upgrade controller VUC to obtain the download address of the upgrade package for one or more components. The vehicle sends the download address to the corresponding functional domain according to the functional domain where the one or more components are located. The domain controller DC. For example, the vehicle obtains the download address 1 of the upgrade package of the first component and the download address 2 of the upgrade package of the second component according to the upgrade strategy. It is assumed that the first component is located in the first functional domain and the second component is located in the second functional domain. , then the vehicle sends the download address 1 to the domain controller DC in the first functional domain, and sends the download address 2 to the domain controller DC in the second functional domain.

S110. The vehicle sends a download request to the vehicle cloud server according to the download address.

The vehicle sends a download request to the car cloud server, and accordingly, the car cloud server receives the download request from the vehicle.

This download request can be used to obtain the upgrade package. The car cloud server here may refer to a server that stores the upgrade package requested by the download request.

Optionally, this download request can also be used to obtain the authorization file.

S111. The car cloud server sends the upgrade package to the vehicle.

The car cloud server sends the upgrade package to the vehicle, and accordingly, the vehicle receives the upgrade package from the car cloud server. Specifically, the vehicle can obtain the upgrade package through the domain upgrade controller DUC.

In addition, similar to the supplier server sending the public key to the car cloud server in step S102, when the car cloud server sends the upgrade package to the vehicle, the car cloud server can also send the public key ( For example, public key 1) and the public key for verifying the outer signature (for example, public key 2) are sent to the vehicle. Or, before the car cloud server performs an outer signature on the installation package, it verifies the public key of the outer signature in advance and sends it to the vehicle. Alternatively, the vehicle can directly store the public key inside the vehicle's chip during the vehicle production line stage. The embodiment of the present application does not limit the method and time for the vehicle to obtain the public key for verifying the outer signature.

It can be understood that the car cloud server may also directly send the installation package to the vehicle without signing the installation package, and the embodiments of this application do not limit this.

S112. The car cloud server sends the authorization file to the vehicle.

The car cloud server sends the authorization file to the vehicle, and accordingly, the vehicle receives the authorization file from the car cloud server. Specifically, the vehicle can obtain the authorization file through the domain upgrade controller DUC.

Vehicle acquisition authorization documents can include the following two situations:

1) The vehicle obtains the authorization file through the upgrade policy

That is to say, after the car cloud server generates the authorization file, it can send the download address of the authorization file to the vehicle along with the upgrade policy. In this way, the vehicle can, after obtaining the upgrade policy, send the authorization file to the authorization file based on the download address of the authorization file. The device where the file resides sends a download request.

In this case, in step S108, the upgrade policy sent by the car cloud server to the vehicle may include the download address of the authorized file. In step S109, the download address parsed by the vehicle may include the download address of the authorized file. Similarly, In step S110, the download request sent by the vehicle to the vehicle cloud server is also used to request the authorization file.

2) The vehicle directly obtains the authorization file sent by the car cloud server

That is to say, after the car cloud server generates the authorization file, it directly sends the authorization file to the vehicle without going through the process of sending the address first and then the authorization file.

In this case, in step S108, the upgrade policy sent by the car cloud server to the vehicle may not include the download address of the authorized file. In step S109, the download address parsed by the vehicle may not include the download address of the authorized file. At the same time, Processing, in step S110, the download request sent by the vehicle to the vehicle cloud server may only be used to request to obtain the upgrade package.

In addition, the embodiment of the present application does not limit the execution order of step S111 and step S112. For example, step S111 may be performed after step S112, or step S111 and step S112 may be performed simultaneously.

S113. Vehicle verification authorization document.

Vehicle verification of authorization documents may include one or more of the following:

1) Verify the signature of the authorization file

The vehicle verifies the signature of the authorization file to verify the legality of the authorization file, including confirming the source of the authorization file. legal, and whether the authorization file has been tampered with. In this way, attackers can be prevented from maliciously tampering with the parameters in the authorization file after obtaining the authorization file, including: vehicle identification, anti-replay parameters, integrity information, etc.

In the specific implementation, the vehicle can use the authorized public key (for example, public key 3) to verify the signature to decrypt the signature, obtain the message digest of the parameters of the authorization file, and use the hash algorithm to decrypt the parameters in the authorization file received by the vehicle. Perform operations to obtain the locally calculated message digest. The vehicle verifies the signature of the authorization file to determine whether the decrypted message digest is consistent with the locally calculated message digest. For example, the parameters of the authorization file include vehicle identification, anti-replay parameters, and integrity information.

In addition, it should be noted that the hash algorithm used by the vehicle for the authorization file is the same as the hash algorithm used by the car cloud server to sign the authorization file.

2) Verify the vehicle identification in the authorization document

The vehicle identification in the vehicle verification authorization file is to determine whether the upgrade package sent by the car cloud server is an upgrade package suitable for the vehicle sent by the car cloud server. In this way, attackers can be prevented from sending upgrade packages from the server to other vehicles or using unauthorized upgrades to upgrade their own vehicles.

In specific implementation, the vehicle can complete the verification of the vehicle identity by determining whether the vehicle identity in the authorization file is consistent with the local vehicle identity. For details about the verification of the vehicle identity, please refer to the subsequent specific implementation, and will not be described in detail here.

3) Verify the anti-replay parameters in the authorization file

The anti-replay parameter in the vehicle verification authorization file is to determine whether the upgrade package sent by the vehicle cloud server is an upgrade package suitable for this upgrade. In this way, attackers can be prevented from using a version of the upgrade package that is not suitable for the current upgrade of the vehicle to upgrade the vehicle.

In specific implementation, the vehicle can complete the verification of the anti-replay parameters by determining whether the anti-replay parameters in the authorization file are consistent with the local anti-replay parameters. For details about the verification of anti-replay parameters, please refer to the subsequent specific implementation, and will not be described in detail here.

4) Verify the integrity information in the authorization file

The vehicle verifies the integrity information in the authorization file to determine whether the currently verified authorization file is the authorization file for the upgrade package. This can prevent attackers from counterfeiting the authorization file of the upgrade package and provide false vehicle identification, anti-replay parameters and other information for the vehicle, or prevent attackers from only intercepting the authorization file of the upgrade package and binding the authorization file to other upgrades. The package is sent to this vehicle, affecting the safety of the vehicle.

For example, the vehicle can use a hash function to calculate the hash value of the upgrade package received by the vehicle. The hash value is the integrity information of the upgrade package calculated locally by the vehicle. The vehicle then determines the completeness information obtained by the local calculation. The integrity information is consistent with the integrity information in the authorization file to complete the verification of the integrity information.

In addition, it should be noted that the hash function used by the vehicle for the upgrade package is the same as the hash function used by the vehicle cloud server when calculating the integrity information of the upgrade package.

In addition, since the integrity information is used to bind the upgrade package and the authorization file, it prevents attackers from maliciously intercepting the authorization file and using the authorization file with other vulnerable upgrade packages to upgrade the vehicle, thus endangering the safety of the vehicle. The transmission process of the authorization file and upgrade package itself is absolutely safe, or the authorization file and upgrade package are encrypted during the transmission process, making it impossible for attackers to obtain the contents of the authorization file and upgrade package, or the upgrade package and authorization file are inaccessible segmented so that an attacker cannot intercept the authorization file alone, the integrity information does not need to be included in the authorization file. Alternatively, the Cheyun server can sign the authorization file and upgrade package when sending it, preventing attackers from maliciously splitting the authorization file and upgrade package.

It can be understood that the verification of the authorization file determines what needs to be verified based on the content contained in the authorization file. For example, when the authorization file only contains the vehicle identification, the verification of the authorization file may only include the vehicle identity. Verification of the identity. When the authorization file contains the vehicle identity and anti-replay parameters, the verification of the authorization file may include verification of the vehicle identity and verification of the anti-replay parameters.

Since the vehicle upgrade is specifically an upgrade of each component in the vehicle, when the vehicle obtains the authorization file of the upgrade package, it can complete the verification of the authorization file through the domain controller DC of the functional domain where the component to be upgraded is located. Specifically, the vehicle can verify the authorization file through the domain installer DI in the domain controller DC. Or, further, the vehicle can also assist in completing the verification of the authorization file through the domain controller DC of other functional domains. In other words, the verification of an authorization file can be completed by one or more domain controllers DC. The embodiment of this application does not limit the number of domain controller DCs that verify authorization files. For a specific description of the domain installer DI, please refer to the relevant content of Figure 3 mentioned above, and will not be repeated here.

S114. The vehicle determines whether the verification of the authorization file has passed.

When all the contents of the vehicle inspection are consistent, the verification of the authorization document passes. Otherwise, when there is an inconsistency in the verification of the vehicle, the verification of the authorization document fails.

For example, when the verification of the authorization file includes verification of the signature of the authorization file, verification of vehicle identification, verification of anti-replay parameters, and verification of integrity information, only the message obtained by decrypting the signature of the authorization file The digest is consistent with the locally calculated message digest, and the vehicle identity in the authorization file is consistent with the local vehicle identity, and the anti-replay parameters in the authorization file are consistent with the local anti-replay parameters. The authorization file Only when the integrity information in the vehicle is consistent with the integrity information calculated locally, the vehicle determines that the verification of the authorization file has passed. Otherwise, when the signature verification, vehicle identity verification, and anti-replay parameter verification . During the verification of integrity information, if one or more verifications are inconsistent, the verification of the authorization file will fail.

It can be understood that the vehicle can perform multiple verifications in the authorization file at the same time, or can perform individual verifications one by one, and the embodiment of the present application does not limit this.

For example, when the signed authorization file includes: vehicle identity, anti-replay parameters, integrity information, and signature of the authorization file, the vehicle can first verify the signature of the authorization file, and then verify it after the signature verification passes. For the vehicle identity in the authorization file, after the vehicle identity is verified, the integrity information in the authorization file is verified. After the integrity information is verified, the anti-replay parameters in the authorization file are verified. If If the verification of the anti-replay parameters passes, it means that the verification of the authorization file passes. When any verification of the authorization file fails, the vehicle stops verification and determines that the verification of the authorization file fails.

When the vehicle determines that the verification of the authorization file passes, the vehicle executes step S115; otherwise, the vehicle executes step S118.

S115. Vehicle verification upgrade package.

After the verification of the authorization file passes, the vehicle can verify the upgrade package. The upgrade package includes an installation package and an outer signature of the installation package. The installation package includes one or more upgrade files and a package signature corresponding to the one or more upgrade files.

Verification of the upgrade package may include one or more of the following:

1) Verification of outer signature

The vehicle verifies the outer signature to confirm whether the source of the upgrade package is legal when it is sent to the vehicle by the car cloud server, and whether the upgrade package has been tampered with.

The outer signature refers to the signature of the installation package by the CheCloud server. For a detailed description of the outer signature, please refer to the previous steps. The relevant content of S103 will not be repeated here.

For example, when the upgrade package contains the signature of the installation package by the vehicle cloud server, the vehicle can first unpack the upgrade package to obtain the installation package and the outer signature of the installation package. The vehicle can then use the public key that verifies the signature (for example, public key 2) to verify the signature.

Specifically, the vehicle can use the domain upgrade controller DUC to verify the outer signature of the upgrade package using the public key in the signature-verification outer signature key pair generated by the vehicle cloud server. For a specific description of the domain upgrade controller DUC, please refer to the relevant content in Figure 3 mentioned above, and will not be repeated here.

2) Verification of package signature

The vehicle verifies the package signature to confirm whether the source of the installation package is legal when it is sent from the supplier server to the vehicle cloud server, and whether the installation package has been tampered with.

The package signature refers to the signature of the upgrade file by the supplier server. For a specific description of the package signature, please refer to the relevant content of the aforementioned step S101, which will not be described again here.

For example, when the upgrade package contains the signature of the upgrade file by the supplier server, the vehicle can first unpack the installation package to obtain one or more upgrade files and one or more package signatures. Afterwards, the vehicle can use the calibration Verify the public key of the signature (for example, public key 1) to verify the packaged signature.

Specifically, the vehicle can verify the package signature of the upgrade package through the domain installer DI using the public key in the signature-verification package signature key pair generated by the supplier server. For a specific description of the domain installer DI, please refer to the relevant content of Figure 3 mentioned above, and will not be repeated here.

It can be understood that the verification of the upgrade package determines what needs to be verified based on the signature contained in the upgrade package. For example, when the upgrade package only contains the outer signature, the verification of the upgrade package can only include the outer signature. When the upgrade package only contains the package signature, the verification of the upgrade package can only include the verification of the package signature. When the upgrade package includes the outer signature and the package signature, the verification of the upgrade package can only include the verification of the package signature. Verification can include verification of outer signatures and verification of packaged signatures. In addition, when the upgrade package received by the vehicle does not have a signature, the vehicle does not have signature verification of the upgrade package. For example, for the upgrade package of the electronic control unit ECU, the upgrade package may only contain the outer signature and not the packaged signature. It should be noted that even if the upgrade package contains a compilation signature, the vehicle does not need to verify the compilation signature during the upgrade phase, but verifies the compilation signature during the safe start phase. For a detailed description of the safe start phase, please refer to the following content. , will not be expanded upon here.

In addition, when the verification of the upgrade package includes both the verification of the package signature and the verification of the outer signature, in the specific implementation, the vehicle can first verify the outer signature through the domain upgrade controller DUC, and then verify the outer signature. After passing, verify the package signature through the domain installer DI.

Furthermore, when the supplier server uses multi-level keys to compile and sign the upgrade package, the vehicle's verification of the package signature involves the verification process of multiple public keys.

The following uses the third-level key as an example to introduce the detailed process of the vehicle's verification of the package signature.

When the supplier server uses the third-level key to package and sign the upgrade file, for example, the supplier server generates three pairs of keys: the package root public key and the package root private key, the package second-level public key and the package root private key. The packaged layer 2 private key, the packaged layer 3 public key, and the packaged layer 3 private key. The vehicle can obtain the packaged root public key, packaged layer 2 public key, packaged layer 2 public key signature, packaged layer 3 public key, packaged layer 3 public key signature, and packaged signature. For a specific description of the supplier server using the third-level key to compile and sign the upgrade package, please refer to the relevant content of Figure 5 mentioned above, and will not be repeated here.

Figure 6 is a schematic diagram of the logical structure of the package signature of the vehicle verification upgrade package provided by the embodiment of the present application.

As shown in Figure 6, vehicle verification package signature mainly includes the following steps:

Step 1: Vehicle verifies the credibility of the packaged root public key

In order to prevent the packaged root public key received by the vehicle from being forged by an attacker, the vehicle first needs to verify the credibility of the packaged root public key.

Among them, the vehicle can store the hash value of the packaged root public key locally. When verifying the credibility of the packaged root public key, the hash value of the packaged root public key can be calculated, and then compared with the locally stored hash value. Compare the hash value of the wrapped root public key. If the two are consistent, it means that the wrapped root public key is trustworthy and not forged data. Otherwise, it means that the wrapped root public key is not trustworthy.

Preferably, the hash value of the packaged root public key can be stored in the One Time Programmable (OTP) storage area of the chip, because the content of the OTP cannot be tampered with, and the non-tampering feature is guaranteed by the hardware mechanism. . In this way, attackers can be prevented from tampering with the hash value of the packaged root public key stored in the vehicle, and the feasibility of the verification process of the packaged root public key is ensured.

If the packaged root public key is trustworthy, the vehicle can perform step 2.

Step 2: The vehicle uses the packaged root public key to verify the signature of the packaged second-level public key.

Because the signature of the packaged layer 2 public key is obtained by the supplier server using the packaged root private key to sign the packaged layer 2 public key. Therefore, when verifying the signature of the packaged layer-2 public key, the packaged root public key can be used to verify the signature.

When the verification of the signature of the packaged Layer 2 public key passes, it means that the packaged Layer 2 public key is trustworthy. If the packaged Layer 2 public key is trustworthy, the vehicle can perform step 3.

Step 3: The vehicle uses the packaged layer 2 public key to verify the signature of the packaged layer 3 public key.

Because the signature of the packaged layer 3 public key is obtained by the supplier server using the packaged layer 2 private key to sign the packaged layer 3 public key. Therefore, when verifying the signature of the packaged layer 3 public key, the packaged layer 2 public key can be used to verify the signature.

When the verification of the signature of the packaged three-layer public key passes, it means that the packaged three-layer public key is trustworthy. If the compiled three-layer public key is trustworthy, the vehicle can perform step 4.

Step 4: The vehicle uses the three-layer public key of the package to verify the package signature.

Because the package signature is obtained by the supplier server using the package three-layer private key to sign the upgrade file in the upgrade package. Therefore, when verifying the packaged signature, the packaged three-layer public key can be used to verify the packaged signature.

When the verification of the package signature passes, it means that the upgrade file in the upgrade package is trustworthy.

It can be understood that the embodiment of the present application does not limit the number of key levels used by the supplier server. For example, when the supplier server uses four pairs of keys to implement the package signature, the verification process of the package signature can be The principle involved in verifying the signatures of more public keys is similar to the vehicle's verification process of package signatures mentioned above, and will not be described again here.

S116. The vehicle determines whether the verification of the upgrade package has passed.

If the vehicle passes the verification of all signatures of the upgrade package, the verification of the upgrade package passes; otherwise, the verification of the upgrade package fails.

When the vehicle determines that the verification of the upgrade package passes, step S117 is executed; otherwise, step S118 is executed.

S117. Vehicle installation upgrade package.

Installing the upgrade package on the vehicle means that the vehicle executes the flashing of the upgrade package and writes the upgrade file in the upgrade package into the storage partition of the vehicle. Specifically, the upgrade file in the upgrade package of the vehicle component to be upgraded is written into the to-be-upgraded in the component's storage partition.

Specifically, the vehicle can install the upgrade package through the domain installer DI to complete the upgrade of vehicle components.

In this way, the vehicle can only confirm that the upgrade package is suitable for the vehicle and that the source of the upgrade package is legal and has not been tampered with. Under the premise, the installation upgrade will be triggered, and the safe operation of the vehicle will be strictly controlled from the vehicle upgrade stage to provide safety guarantee for the vehicle upgrade.

S118. Vehicle upgrade canceled.

If the verification of the authorization file fails, the vehicle upgrade will be canceled and the vehicle upgrade will fail. In this way, the vehicle can be prevented from importing upgrade packages that are not applicable to the vehicle, such as upgrade packages of old versions, upgrade packages of other vehicles, upgrade packages used in the research and development stage, etc., so as to protect car owners, software suppliers, The commercial interests of car manufacturers are to improve vehicle safety.

Similarly, if the verification of the upgrade package fails, the vehicle upgrade will be canceled and the vehicle upgrade will fail. In this way, the vehicle can be prevented from being maliciously tampered with or upgrade packages from illegal sources imported into the vehicle, and the security of vehicle upgrades can be improved as much as possible.

It should be understood that in the embodiment of this application, the vehicle cloud server may also be called the first server, the supplier server may also be called the second server, and the vehicle's local vehicle identity may also be called the vehicle identification. The vehicle receives The received authorization file may also be called the first file, the received upgrade package may also be called the first upgrade package, and the vehicle identity in the authorization file may also be called the first vehicle identification. The replay parameter may also be called the first anti-replay parameter, the integrity information in the authorization file may also be called the first integrity information, the signature in the authorization file may also be called the first signature, and the integrity information in the authorization file may also be called the first signature. The authorized public key may also be called the first public key, the outer signature in the upgrade package may also be called the third signature, and the packaged signature in the upgrade package may also be called the fourth signature.

The following describes the vehicle verification method in the near-end upgrade scenario with reference to Figure 7.

Figure 7 is a schematic flowchart of the vehicle verification method in the near-end upgrade scenario provided by the embodiment of the present application.

The near-end upgrade scenario mainly involves the interaction between the supplier server, vehicle cloud server, vehicle, and diagnostic terminal. The vehicle can obtain the upgrade package through wired communication to complete the vehicle upgrade.

As shown in Figure 7, the vehicle verification method may include:

S201. The supplier server signs one or more upgrade files and generates an installation package.

S202. The supplier server sends the installation package to the Cheyun server.

S203. The Cheyun server signs the installation package and generates an upgrade package.

Among them, steps S201-S203 are the same as steps S101-S103 in Figure 4. Please refer to the relevant description.

S204. The diagnostic terminal obtains the asset information of the vehicle.

S205. The diagnostic terminal sends the asset information to the car cloud server.

Among them, steps S204-S205 are similar to step S104 in Figure 4. The difference is that the asset information of the vehicle in Figure 7 is read from the vehicle by establishing a wired connection with the vehicle through the diagnostic terminal. After that, the diagnostic terminal then Send asset information to the car cloud server. In Figure 4, the vehicle directly sends asset information to the vehicle cloud server.

Among them, the diagnostic terminal is used to obtain the asset information of the vehicle, obtain the upgrade package from the vehicle cloud server, and import the upgrade package into the vehicle through wired transmission. For example, the diagnostic terminal may refer to the electronic device 400 shown in FIG. 1 . For a specific description of the electronic device 400, please refer to the relevant content of FIG. 1 and will not be described again here.

In addition, before the vehicle sends asset information to the diagnostic terminal, the user needs to manually connect the diagnostic terminal to the vehicle's port, such as the OBD port. The diagnostic terminal can obtain the vehicle's asset information through the OBD port and import the upgrade package into the vehicle.

S206. The car cloud server determines the upgrade package based on the asset information.

S207. The car cloud server generates an authorization file.

S208. The car cloud server determines the upgrade strategy.

Among them, steps S206-S208 are the same as steps S105-S107 in Figure 4. Please refer to the relevant description.

S209. The car cloud server sends the upgrade strategy to the diagnostic terminal.

S210. The diagnostic terminal parses the download address according to the upgrade policy.

S211. The diagnostic terminal sends a download request to the car cloud server according to the download address.

S212. The car cloud server sends the upgrade package to the diagnostic terminal.

S213. The car cloud server sends the authorization file to the diagnostic terminal.

S214. The diagnostic terminal sends the upgrade package to the vehicle.

S215. The diagnostic terminal sends the authorization file to the vehicle.

Among them, steps S209-S215 are similar to steps S108-S112 in Figure 4. The difference is that the car cloud server in Figure 7 sends the upgrade policy to the diagnostic terminal, and the diagnostic terminal parses the download address. After that, the diagnostic terminal The terminal sends a download request to the car cloud server, and the car cloud server sends the upgrade package and authorization file to the diagnostic terminal, and the diagnosis terminal forwards the upgrade package and authorization file to the vehicle. The car cloud server in Figure 4 directly sends the upgrade policy to the vehicle, and the vehicle parses the download address. After that, the vehicle sends a download request to the car cloud server, and the car cloud server directly sends the upgrade package and authorization file. to vehicles.

It should be noted that in steps S214 and S215, the diagnostic terminal sends the upgrade package and authorization file to the vehicle through a wired connection. For example, the diagnostic terminal is connected to the OBD port of the vehicle, and the upgrade package is transmitted to the vehicle through the OBD port. vehicle.

In addition, the embodiment of the present application does not limit the execution order of steps S212-S215. For example, step S214 may be executed before step S213 or after step S215. It can be seen that step S214 only needs to be executed after step S212, and step S215 only needs to be executed after step S213.

S216. Vehicle verification authorization document.

S217. The vehicle determines whether the verification of the authorization file has passed.

If the vehicle determines that the verification of the authorization file passes, step S218 is executed; otherwise, step S221 is executed.

S218. Vehicle verification upgrade package.

S219. The vehicle determines whether the verification of the upgrade package has passed.

If the vehicle determines that the verification of the upgrade package passes, step S220 is executed; otherwise, step S221 is executed.

S220. Vehicle installation upgrade package. S221. Vehicle upgrade canceled.

Among them, steps S216-S221 are similar to steps S113-S118 in Figure 4. The difference is that the vehicle verification authorization file in step S216 can be automatically triggered by the vehicle to verify the authorization file, or the diagnosis terminal can trigger the verification of the authorization file by the vehicle. Similarly, the vehicle verification upgrade package in step S218 The vehicle can automatically trigger the verification of the upgrade package, or the diagnostic terminal can trigger the vehicle's verification of the upgrade package.

In addition, in step S220, the vehicle's installation of the upgrade package in the local upgrade scenario may include the following three stages:

1) Preprogramming stage

The pre-programming stage can also be called the flash preparation stage. This stage is mainly used to build an upgrade environment before upgrading. Specifically, the vehicle can switch the operating mode of the component to be upgraded to the session mode. In the session mode, the component to be upgraded has higher diagnostic authority, and the component to be upgraded can be upgraded and refreshed in this mode.

2) Installation stage

The installation phase is mainly for the vehicle to flash the data of the upgrade package into the storage of the components to be upgraded.

3) Post-programming stage

After the flashing is completed, the vehicle can switch the operating mode of the component to be upgraded back to the default session mode, thus ending the vehicle upgrade.

It can be seen that in the near-end upgrade scenario, the vehicle does not need to be connected to the Internet, and is directly connected to the diagnostic terminal through a wire. The diagnostic terminal takes the lead to complete the vehicle upgrade, and the vehicle will check whether the upgrade package is suitable for the vehicle before upgrading. Check whether the source of the package is legal and whether it has been tampered with. Strictly control the safe operation of the vehicle from the vehicle upgrade stage to ensure the commercial interests of car owners, software suppliers and car manufacturers.

In addition, for components in the vehicle that support the secure boot function, such as the domain controller DC in the vehicle, after the vehicle is upgraded and the vehicle is started, the vehicle components also have a process of verifying the authorization file. In this way, any unauthorized or maliciously modified software can be prevented from running inside the vehicle after the vehicle is upgraded, ensuring system security when the vehicle is running as much as possible.

During the safe startup of vehicle components, the software in the component starts in sequence, and the previous software verifies the safety of the next software. After the verification is passed, the previous software hands over control to the next software, and so on. This completes the safe start of vehicle components.

Safe starting of the vehicle may refer to starting a function of the vehicle, such as a first function. For example, after detecting an instruction to start the first function, the vehicle can trigger verification of the authorization file, and after passing the verification, trigger starting of the first function.

The following takes the first software to verify the second software during the safe startup of vehicle components as an example to introduce in detail the contents of the vehicle verification method in the safe startup scenario. The second software may be a program upgraded using an upgrade package.

Step 1: Start the first software of the vehicle safely.

The first software may be software whose security has been verified, or it may be software that has absolute security when secure startup is started. Its absolute security is guaranteed by the hardware mechanism. At this time, the code of the first software is located in a storage area that cannot be tampered with, such as OCR.

Step 2: The vehicle verifies the authorization file through the first software.

The authorization file is the authorization file of the upgrade package when the second software is upgraded through the upgrade package. For the specific description of the authorization file and the acquisition of the authorization file, please refer to the relevant content in Figure 4, and will not be repeated here. For example, the second software may be xloader.

Among them, the verification of the authorization file includes one or more of the following: verification of the signature of the authorization file, verification of vehicle identity, verification of integrity information, and verification of anti-replay parameters.

Among them, the verification of the authorization file by the vehicle in the safe start stage is similar to the verification of the authorization file in the upgrade stage. The difference is that the integrity information verified in the safe start stage and the upgrade stage are different.

During the vehicle upgrade phase, the vehicle verifies the integrity information by calculating the integrity information of the received upgrade package and comparing the integrity information with the integrity information in the authorization file.

In the safe startup phase, since the data of the upgrade package has been imported into the second software, the vehicle verifies the integrity information of the image file of the second software. Specifically, the vehicle can use a hash algorithm to calculate the integrity information of the image file of the second software, and compare the integrity information with the integrity information in the authorization file. If they are consistent, the verification of the integrity information passes, otherwise , the integrity information verification failed. Among them, mirroring is a form of file storage and a type of redundancy. The data on one disk has an identical copy on another disk, which is a mirror. The so-called image file is actually similar to an installation package. It produces a specific series of files into a single file in a certain format to facilitate users to download and use, such as a test version of an operating system, a game, etc.

After the verification of the authorization file passes, the vehicle can perform step 3, otherwise, the vehicle terminates the safe start.

Step 3: The vehicle verifies the package signature of the second software.

An upgrade package can upgrade one or more software in the component, and the package signature of the second software can be the package signature of one of the upgrade files in the upgrade package.

Since the second software is the software upgraded by using the upgrade package for the vehicle, after the vehicle upgrade is completed, the package signature of the upgrade package is stored in the storage partition of the second software, and the vehicle verifies the package signature of the second software. Verify the package signature of the second software.

That is to say, the process of the vehicle verifying the package signature of the second software is similar to the process of verifying the package signature of the upgrade package during the vehicle upgrade phase. The difference is that during the secure startup phase, the vehicle obtains the package signature of the second software and the public key used to verify the package signature from the storage partition of the second software to complete the verification of the package signature. .

It can be understood that when the package signature is implemented using multi-level keys, the storage partition of the second software also includes other public keys and signatures of other public keys. For details about the verification of the packet signature, please refer to the relevant content in the aforementioned step S115, which will not be described again here.

This prevents any unauthorized or maliciously modified software from running inside the vehicle after the vehicle upgrade is completed.

After the verification of the package signature passes, the vehicle can perform step 4; otherwise, the vehicle terminates the safe start.

It can be understood that the vehicle can also verify the package signature of the upgrade package first, and then verify the authorization file. That is to say, step 3 can be executed before step 2. The embodiment of the present application does not limit the execution order.

Step 4: The vehicle safely starts the second software.

After the vehicle safely starts the second software, the vehicle can transfer control to the second software, and the vehicle continues to verify the security of the next-level software of the second software (such as third software) through the second software, including verifying the authorization file. and package signature, and so on, until the vehicle has verified all the software of the current vehicle component, and the vehicle safely starts the vehicle component.

It can be seen that the vehicle can receive the authorization file and upgrade package during the upgrade phase, and determine whether to use the upgrade package by verifying the authorization file. After that, during the safe start stage of the vehicle, the vehicle can verify the authorization file again. To prevent attackers from maliciously dismantling components and changing the vehicle’s upgraded data.

It should be noted that after the vehicle receives the authorization file and upgrade package during the upgrade stage, it can verify the authorization file both during the upgrade stage and during the secure startup stage, or the vehicle can verify the authorization file only during the upgrade stage. , or the vehicle can only verify the authorization file during the safe startup phase, which is not limited in the embodiment of the present application. For example, when the vehicle only verifies the authorization file during the safe startup phase, the vehicle can be directly upgraded according to the upgrade package without verifying the authorization file. During the safe startup phase of the vehicle, the vehicle then verifies the authorization file. Verification, verify whether the vehicle data is the data upgraded according to the upgrade package. Only after the verification passes, the vehicle can be started to ensure the safe operation of the vehicle.

It should be understood that the upgrade package and authorization file mentioned in the safe start stage are the upgrade packages and authorization files obtained by the vehicle during the upgrade stage. For specific information on obtaining the authorization file, please refer to the relevant content of Figure 4 and Figure 7 mentioned above, which will not be discussed here. Repeat.

The specific implementation process of vehicle identification is introduced in detail below.

The vehicle identity is used to uniquely identify the currently upgraded vehicle, and further, uniquely represents the currently upgraded components. When a vehicle is being upgraded, the identity of the vehicle can be verified to prevent attackers from upgrading the vehicle using upgrade packages from other vehicles or upgrade packages used in the research and development phase that are not applicable to the vehicle.

The authorization file can be verified by the domain controller DC that downloaded the authorization file, or by the domain controller DC that downloaded the authorization file and other domain controller DCs. Depending on the number of domain controller DCs involved in authorization file verification, the implementation of vehicle identity mainly involves the following two solutions:

Solution 1: Verification of the authorization file is completed by a single domain controller DC

When the verification of the authorization file is only completed by a single domain controller DC, the vehicle identity Space_Attr can be The chip ID of the domain controller DC.

It can be seen that the verification of the authorization file is completed by a single domain controller DC, which allows the vehicle to quickly complete the verification of the vehicle identity.

Further, the vehicle identity Space_Attr can be pre-stored in a non-tamperable storage area of the vehicle. In this way, other people can be prevented from maliciously tampering with the vehicle identity, and the credibility of the vehicle identity during the verification process can be ensured.

For example, the vehicle identity Space_Attr can be fused in a one-time programmable (One Time Programmable, OTP) storage area of a chip of the domain controller DC.

In this way, when the vehicle needs to send asset information to the car cloud server, it can read the vehicle identity identifier Space_Attr from the OTP storage area of the domain controller DC, and then the vehicle verifies the vehicle identity identifier Space_Attr in the authorization file through the domain controller DC. At this time, you can determine whether the verification of the vehicle identity has passed by comparing whether the vehicle identity stored in the OTP storage area of the domain controller DC is consistent with the vehicle identity in the authorization file.

It should be noted that when the upgraded component is an electronic control unit ECU, if the security capability of the electronic control unit ECU is weak, the vehicle can verify the electronic control unit ECU through the domain controller DC connected to the electronic control unit ECU. The authorization file corresponding to the upgrade package. Then, at this time, the vehicle identity in the authorization file is the chip ID of the domain controller DC. It can be understood that if the electronic control unit ECU has strong security capabilities, the verification of the authorization file corresponding to the upgrade package of the electronic control unit ECU can also be completed by itself. The embodiment of the present application does not limit the verification components of the authorization file of the electronic control unit ECU. That is to say, the vehicle identification may be used to identify the first component, and the first component may refer to an upgraded component or a component that manages the upgraded component (eg, a second component).

Solution 2: Verification of authorization files is completed by multiple domain controllers DC

When the verification of the authorization file is completed by multiple domain controllers DC, the vehicle identity identifier Space_Attr in the authorization file may include: the chip IDs of the multiple domain controllers DC.

It can be seen that when the verification of the authorization file is completed by multiple domain controller DCs, only after it is determined that the chip IDs of the multiple domain controller DCs in the authorization file are consistent with the local chip IDs of the multiple domain controller DCs. Only when they are consistent, the verification of the vehicle identity will be considered passed, which can prevent the occurrence of malicious replacement attack scenarios on the vehicle.

Take the upgraded component as the electronic control unit ECU and the component that verifies the authorization file as the domain controller DC. Assume that vehicle A has a component ECU1 to be upgraded. The authorization file of the upgrade package of this component ECU1 is determined by the component DC1 connected to it. Perform verification. Then, component DC1 has the upgrade package and authorization file of ECU1, and vehicle B has component ECU2 and its connected component DC2. Among them, component ECU1 and component ECU2 are components of the same type, and component DC1 and component DC2 are components of the same type. Before upgrading component ECU1, replace component DC2 with component DC1, and trigger the verification of the vehicle identity in the authorization file of the replaced component DC1 on vehicle B. If the vehicle identity is only the chip of component DC1 ID, then the verification can pass, and vehicle B can trigger the upgrade of component ECU2 in vehicle B without legally obtaining the upgrade package. This allows attackers to exploit this vulnerability and upgrade vehicles without following formal upgrade methods, thereby affecting the commercial interests of car owners, software suppliers and car manufacturers.

In other words, using the chip IDs of multiple domain controller DCs to implement vehicle identification can prevent attackers from replacing vehicle components through the binding of multiple domain controller DCs. For example, a vehicle identification tag may be used to identify the first component and the third component. The first component may be an upgrade component, or may be a component that manages the upgrade component (for example, the second component).

Optionally, the vehicle identity identifier Space_Attr in the authorization file may include: the chip IDs of the multiple domain controller DCs, and the signature verification public keys generated by the one or more domain controller DCs.

Preferably, the vehicle identity identifier Space_Attr in the authorization file may include: cores of the multiple domain controllers DC. Slice ID, and signature verification public keys generated by these multiple domain controller DCs.

In addition, it should be noted that in the second solution, the vehicle identity in the asset information sent by the vehicle to the car cloud server can be different from the vehicle identity in the authorization file returned by the car cloud server. For details, please refer to the description of the vehicle identity sent by the vehicle and the vehicle identity returned by the car cloud server in the following example.

The following takes the verification of the authorization file completed by the first domain controller and the second domain controller in the vehicle as an example to introduce in detail the implementation process of the vehicle identity identifier Space_Attr. Among them, the vehicle identity mark Space_Attr mainly involves two related stages of the vehicle: the vehicle production line stage and the vehicle upgrade stage.

In the vehicle production line stage, it mainly includes the following steps:

1) First, read the chip IDs of the first domain controller and the second domain controller through the production line equipment tool: socid_one and socid_two.

2) Trigger the first domain controller and the second domain controller to generate a pair of signature-verification key pairs (pk_one, sk_one) in their respective security system environments, such as Trusted Execution Environment (TEE), (pk_two,sk_two). Among them, pk_one and sk_one are respectively the signature verification public key and signature private key in the signature-verification key pair generated by the first domain controller, and pk_two and sk_two are respectively the signature-signature verification key generated by the second domain controller. The signature verification public key and signature private key in the pair.

3) The production line equipment tool binds the chip IDs of the first domain controller and the second domain controller, as well as the signature verification public keys generated by the first domain controller and the second domain controller, and uploads them to the car cloud server. . For example, the data uploaded by the production line equipment tool includes: socid_one: socid_two, pk_one: pk_two. Among them, the data not only indicates the four parameters of the chip ID of the first domain controller and the second domain controller, and the signature verification public key generated by the first domain controller and the second domain controller, but also indicates these four parameters. The binding relationship of the four parameters. When the car cloud server obtains one or more of the four parameters, it can find the four parameters related to the one or more parameters based on the binding relationship.

In the vehicle upgrade stage, it mainly includes the following steps:

1) When a vehicle sends asset information, it can send the chip ID of at least one domain controller DC (for example, the chip ID of the first domain controller, sociod_one) as the vehicle identity identifier to the car cloud server.

2) After obtaining the asset information, the vehicle cloud server can find multiple domain controls containing the chip ID of the domain controller received during the vehicle production line stage based on the chip ID of at least one domain controller DC. The chip ID of the controller, and the signature verification public keys generated by these multiple domain controllers, that is, the chip IDs of the first domain controller and the second domain controller, and the signature verification public keys generated by the first domain controller and the second domain controller. Verification public key.

3) The car cloud server uses the chip IDs of the first domain controller and the second domain controller and the signature verification public keys generated by the first domain controller and the second domain controller as the vehicle identity and puts them into the authorization file. , sent to the vehicle.

4) The vehicle passes the first domain controller and the second domain controller to verify the vehicle identity in the authorization file.

It can be seen that the vehicle identity in the asset information sent by the vehicle can be the chip ID of a domain controller DC, such as the chip ID of the first domain controller, but the vehicle identity in the authorization file returned by the car cloud server is multiple. The chip ID of a domain controller and the generated signature verification public key, for example, the chip ID of the first domain controller and the second domain controller, and the signature verification public key generated by the first domain controller and the second domain controller. key. In other words, the vehicle can only send one parameter, and the vehicle cloud server can find all parameters related to this parameter based on this parameter, and return all parameters to the vehicle together. Here, other parameters related to the parameter may refer to all parameters stored in the car cloud server that have a binding relationship with the parameter.

The above-mentioned vehicle upgrade stage and the detailed verification process of step 4 will be described in detail below through Figure 8 .

Figure 8 is a flow chart of interaction between multiple domain controllers when verifying the vehicle identity in the authorization file provided by the embodiment of the present application.

As shown in Figure 8, these multiple domain controllers take the first domain controller and the second domain controller as an example. The interaction process between the domain controllers is as follows:

S301. The first domain controller verifies whether the chip ID of the first domain controller in the authorization file is consistent with the chip ID of the local first domain controller.

The authorization file includes: the chip IDs of the first domain controller and the second domain controller, and the public keys generated by the first domain controller and the second domain controller.

The first domain controller may first obtain the chip ID of the local first domain controller, and then compare whether the chip ID of the local first domain controller is consistent with the chip ID of the first domain controller in the authorization file. If they are consistent, step S302 is executed.

S302. The first domain controller sends the authorization file to the second domain controller.

S303. The second domain controller verifies whether the chip ID of the second domain controller in the authorization file is consistent with the chip ID of the local second domain controller.

The second domain controller may first obtain the chip ID of the local second domain controller, and then compare whether the chip ID of the local second domain controller is consistent with the chip ID of the second domain controller indicated in the authorization file. If they are consistent, step S304 is executed.

S304. The second domain controller uses the signature private key to calculate the signature of the authorization file.

The signature private key is the signature private key sk_two in the signature-verification key pair generated by the second domain controller in a secure system environment during the vehicle production line stage.

The second domain controller uses the signature private key to sign the parameters in the authorization file to obtain the signature of the authorization file.

S305. The second domain controller sends the signature of the authorization file to the first domain controller.

S306. The first domain controller verifies the signature of the authorization file using the signature verification public key of the second domain controller in the authorization file.

The verification public key is the signature verification public key pk_two in the signature-verification key pair generated by the second domain controller in a secure system environment during the vehicle production line stage. The first domain controller can find the signature verification public key generated by the second domain controller in the authorization file.

The first domain controller verifies the signature of the authorization file. Specifically, the first domain controller verifies the signature of the authorization file using the signature verification public key of the second domain controller.

If the signature verification passes, the verification of the vehicle identity in the authorization file passes; otherwise, the verification of the vehicle identity in the authorization file fails.

It can be seen that when the verification of the authorization file is completed by multiple domain controllers DC, the verification of the vehicle identity can be verification of the chip IDs of multiple domain controllers and verification of the signature of the authorization file.

It should be noted that the signature verification public key of the second domain controller used in the above vehicle identification is to further ensure the credibility of the information sent by the second domain controller to the first domain controller. If the data transmission process before the domain controller is sufficiently secure, the public key may not be involved in the vehicle identification.

It can be understood that when the vehicle identity does not include a public key, during the vehicle production line stage, the production line equipment tool can only read and upload the chip ID. During the vehicle upgrade stage, it does not involve using the public key to calculate The signature of the authorization document and the process of using that signature to verify the vehicle's identity.

In addition, it should be noted that the above steps S301-S306 only describe the verification process involved in the vehicle identity. However, in the actual verification process, in addition to verifying the vehicle identity, the domain controller will also verify the anti-replication process. Put the parameters and complete the information Information, etc., for example, in step S301, in addition to verifying the chip ID, the first domain controller will also verify the signature of the authorization file, integrity information, anti-replay parameters, etc., after all verifications pass Only then will step S302 be executed to send the authorization file to the second domain controller. In addition, in step S302, in addition to verifying the chip ID, the second domain controller will also verify the signature of the authorization file, etc. Step S304 will be executed only after all verifications pass. For specific details about the verification process of the authorization file, please refer to the relevant content of the aforementioned steps S107-S108, which will not be described again here.

For example, the first domain controller may be a Telematics BOX (Tbox), and the second domain controller may be a cockpit domain controller (CDC). This embodiment of the present application controls the first domain. There are no restrictions on the components in the vehicle corresponding to the controller and the second domain controller. When the first domain controller is Tbox and the second domain controller is CDC, Table 2 exemplarily shows another possible structure of the signed authorization file provided by the implementation of this application.

Table 2

As can be seen from Table 2, the vehicle identity identifier Space_Attr in the authorization file specifically includes: socid_Tbox: socid_CDC and pk_Tbox: pk_CDC. Among them, socid_Tbox is the chip ID of Tbox, socid_CDC is the chip ID of CDC, pk_Tbox is the public key generated by Tbox, and pk_CDC is the public key generated by CDC. socid_Tbox: socid_CDC is used to represent the binding relationship between Tbox and CDC's chip ID, pk_Tbox: pk_CDC is used to represent the binding relationship between Tbox and CDC's public key.

In addition, for descriptions of Time_Attr, Integrity_Attr, Sig(sk,M) and pk&pk_validity_proof in the authorization file, please refer to the relevant content in the aforementioned Table 1 and will not be repeated here.

It can be understood that the structure of the signed authorization file shown in Table 2 is only an illustrative example and does not constitute a limitation on the authorization file. In addition, the specific implementation process of the vehicle identity identifier Space_Attr is described above by taking two domain controllers as an example. However, the embodiment of this application does not limit the number of domain controllers involved in verifying the authorization file. For example, when the authorization file When the verification is completed by three domain controllers, the vehicle identity identifier Space_Attr may include the binding relationship of the chip IDs of the three domain controllers and the binding relationship of the public keys generated by the three domain controllers.

The specific implementation process of anti-replay parameters is introduced in detail below.

The anti-replay parameter Time_Attr is used to uniquely identify an upgrade. When the vehicle is being upgraded, the anti-replay parameter Time_Attr can be verified to prevent attackers from using old version upgrade packages to upgrade the vehicle.

Solution 1: Use Replay Protected MemoryBlock (RPMB) to set the anti-replay parameter Time_Attr

RPMB is a storage partition with security features. When data is written to RPMB, the validity of the data will be verified. Only the designated sender can write the data. At the same time, when reading data, a signature mechanism is also provided to ensure that the other party reads it. The data obtained is the internal data of RPMB, not the data forged by the attacker. Therefore, in practical applications, RPMB is usually used to store some data that needs to be prevented from illegal tampering.

In this embodiment of the present application, the anti-replay parameter Time_Attr can be stored in the RPMB of the domain controller.

Among them, the anti-replay parameter Time_Attr can be designed in the following two ways:

1) Use random numbers to set the anti-replay parameter Time_Attr

In order to prevent the vehicle from being upgraded again based on the upgraded version during the vehicle upgrade process, the vehicle and the vehicle cloud server can reserve a "secret code". When the vehicle verifies the anti-replay parameter Time_Attr, only the "secret code" If they are consistent, the verification of the anti-replay parameter Time_Attr will pass.

At this time, the anti-replay parameter Time_Attr can be a random number nonce, and the random number is a number that is only valid once. The only valid one time means that when the vehicle upgrades and generates the anti-replay parameter Time_Attr, the random number The nonces are different, that is, each generated anti-replay parameter Time_Attr uniquely represents an upgrade. For example, the vehicle and the vehicle cloud server agree on a random number A during a certain upgrade. Only when the anti-replay parameter Time_Attr sent by the vehicle cloud server to the vehicle during this upgrade is the random number A, the anti-replay parameter The verification of Time_Attr is passed.

Then, in the aforementioned steps S103-S114, the anti-replay parameter Time_Attr mainly involves the following implementation process:

a) Before the vehicle sends asset information to the vehicle cloud server, the vehicle can randomly generate a string nonce in a secure system environment, such as a TEE environment, and write the string nonce into the RPMB as the anti-replay parameter Time_Attr.

b) When the vehicle sends asset information, the vehicle sends the nonce as the anti-replay parameter Time_Attr along with the asset information to the vehicle cloud server.

c) After the vehicle cloud server obtains the nonce, it uses the nonce as the anti-replay parameter Time_Attr in the authorization file and sends it to the vehicle.

d) During the process of the vehicle verifying the authorization file, after obtaining the anti-replay parameter Time_Attr in the authorization file, the vehicle reads the anti-replay parameter Time_Attr from the local RPMB and determines the anti-replay parameter Time_Attr in the authorization file. Check whether the replay parameter Time_Attr is consistent with the local anti-replay parameter Time_Attr. If the anti-replay parameter Time_Attr in the authorization file is consistent with the local anti-replay parameter Time_Attr, the anti-replay parameter verification passes; otherwise, the anti-replay parameter verification fails.

For a detailed description of steps S103-S114, please refer to the relevant content of Figure 4, and will not be described again here.

It can be understood that the above only describes in detail the specific implementation process of the anti-replay parameter Time_Attr in the remote upgrade scenario. In the near-end upgrade scenario, the specific implementation process of the anti-replay parameter Time_Attr is similar to the remote upgrade scenario, but different What is interesting is that in the near-end upgrade scenario, the vehicle and the vehicle cloud server transfer asset information, signed upgrade packages, and authorization files through the diagnostic terminal, while in the remote upgrade scenario, the vehicle and the vehicle cloud server interact directly, without involving the diagnostic terminal. transit. Regarding the specific implementation process of the anti-replay parameter Time_Attr in the near-end upgrade scenario, please refer to the specific implementation process of the anti-replay parameter Time_Attr in the aforementioned remote upgrade scenario and the aforementioned steps S203-S217, which will not be discussed here.

In addition, it should be noted that in the above implementation process, the anti-replay parameter Time_Attr is generated by the vehicle. In other embodiments of the present application, the anti-replay parameter Time_Attr can also be generated by the vehicle cloud server and sent to the vehicle. The application embodiment does not limit the device that generates the anti-replay parameter Time_Attr when using random numbers to set the anti-replay parameter Time_Attr.

2) Use the counter to set the anti-replay parameter Time_Attr

In order to prevent the vehicle from being upgraded again based on the upgraded version during the vehicle upgrade process, the vehicle and the vehicle cloud server can agree on a counter. The value of the counter can be incremented in one direction according to the version of the upgrade package. The vehicle and the vehicle cloud server can The car cloud server can use the value of this counter as an anti-replay parameter. During the process of the vehicle verifying the anti-replay parameters, if the anti-replay parameters received by the vehicle are inconsistent with the local anti-replay parameters, it means that the car cloud server Upgrade package sent The version of does not match the version of the upgrade package required for vehicle upgrade.

At this time, the anti-replay parameter Time_Attr is a value that increases in one direction. For example, the value that increases each time is 1. For example, when the vehicle is upgraded for the fifth time, the anti-replay parameter Time_Attr may be 5, and when the vehicle is upgraded for the sixth time, the anti-replay parameter Time_Attr may be 6. Among them, when the vehicle is upgraded for the sixth time, if the anti-replay parameter Time_Attr received by the vehicle is 5, it means that the upgrade package sent by the car cloud server may be the upgrade package sent by the vehicle when it is upgraded for the fifth time. The verification of the anti-replay parameter Time_Attr failed.

The value of this counter can change in the following two situations:

Situation 1: The value of the counter changes every time the vehicle is upgraded to a version

In this case, every time the vehicle is upgraded, the counter value will be increased by 1. In this way, each version of the upgrade package for the vehicle will correspond to an anti-replay parameter, and the anti-replay parameters of different versions are inconsistent. For example, assume that when the vehicle upgrades the V7 version of the upgrade package, the anti-replay parameter is 7. If the anti-replay parameter sent by the car cloud server is 6, the upgrade package sent by the car cloud server may be the V6 version upgrade package, which is For an old version of the upgrade package, the vehicle determines that the anti-replay parameter verification fails, and the vehicle cancels the upgrade.

In this way, the vehicle can be prevented from being upgraded with an old version of the upgrade package, ensuring that each vehicle upgrade is different from the previous upgrade.

By way of example, the principle of using a counter to prevent replay in case 1 is described below with reference to FIG. 9 .

Figure 9 is a sequence diagram of a vehicle upgrade provided by an embodiment of the present application.

As shown in Figure 9, the vehicle was successfully upgraded using upgrade packages V1, V2, and V3 at time points T1, T2, and T3 respectively. For each upgrade, the counter value will be increased by 1. Assume that the anti-replay parameters before time T1 are 0, then, T1, T2, and T3 vehicles can be successfully upgraded because of the anti-replay in the authorization file 1 received by the vehicle at T1, the authorization file 2 received at T2, and the authorization file 3 received at T3. The parameters are 0, 1, and 2 respectively.

By analogy, when the upgrade is performed again at T4, the vehicle's local anti-replay parameter is 3. It can be seen that if T4 receives the authorization file 1 and upgrade package V1 sent at T1 again, since the anti-replay parameter in authorization file 1 is 0, which is inconsistent with the local anti-replay parameter, the vehicle will not Upgrading with upgrade package V1 avoids the vehicle being upgraded with the old version upgrade package again. If at T4, the vehicle receives the anti-replay parameter in authorization file 4 as 3, the vehicle can use the upgrade package V4 to upgrade.

It can be seen that by changing the value of the counter for each upgrade, it is possible to avoid using the old version of the upgrade package every time the vehicle is upgraded.

Scenario 2: The vehicle changes the value of the counter after being upgraded to a vulnerable version

In this case, the counter will only be incremented by one when the vehicle is upgraded to a vulnerable version. In this way, although each version of the upgrade package of the vehicle will correspond to an anti-replay parameter, the anti-replay parameters of different versions may be the same. Only when the vehicle has been upgraded to a vulnerable version, the anti-replay parameters will be changed. Changes occur.

Among them, the value of the vehicle change counter can be triggered by the vehicle cloud server. Specifically, when the car cloud server detects that the vehicle has been upgraded to a vulnerable version, it sends an adjustment instruction to the vehicle. The vehicle can trigger a change in the value of the technical counter based on the adjustment instruction. For example, the value of the counter is increased by 1.

In this way, the vehicle will only change the value of the counter when it has been upgraded to a vulnerable version, which can reduce the frequency of changing the value of the counter.

For example, the principle of using counters to prevent replay in case 2 is described below with reference to FIG. 10 .

Figure 10 is a sequence diagram of another vehicle upgrade provided by an embodiment of the present application.

As shown in Figure 10, the vehicle was successfully upgraded using upgrade packages V1, V2, and V3 at time points T1, T2, and T3 respectively, and the anti-replay parameter in the authorization file for each upgrade was 0. When it is discovered at T4 that there is a security vulnerability in the upgrade package V2 upgraded by the vehicle at T2, the vehicle will increase the counter value by 1.

That is to say, when the upgrade is performed again at time T5, the local anti-replay parameter of the vehicle is 1 at this time. It can be seen that if the authorization file 2 and upgrade package V2 sent at T2 are received again at time T5, since the anti-replay parameter in authorization file 2 is 0, which is inconsistent with the local anti-replay parameter, the vehicle will not Upgrading using the upgrade package V2 avoids the vehicle being upgraded with the old version upgrade package again. If at T5, the vehicle receives the anti-replay parameter in authorization file 4 as 1, the vehicle can use the upgrade package V4 to upgrade.

It can be seen that by changing the value of the counter after discovering that the vehicle has been upgraded with a vulnerable upgrade package, it can prevent the vehicle from being upgraded with an old version of the upgrade package after a vulnerable version is discovered.

Similar to the aforementioned use of random numbers to set the anti-replay parameter Time_Attr, when using a counter to set the anti-replay parameter Time_Attr, the vehicle can determine the value of the counter before sending asset information to the vehicle cloud server, and use this value as the anti-replay parameter. The replay parameter Time_Attr is written into RPMB, and then this value is used as the anti-replay parameter Time_Attr and is sent to the Che Cloud server along with the asset information. Then the authorization file sent by the Che Cloud server is received and the anti-replay parameter Time_Attr in the authorization file is verified. . Specifically regarding the implementation process of the anti-replay parameter Time_Attr when using a counter to set the anti-replay parameter Time_Attr, please refer to the implementation process of the anti-replay parameter Time_Attr when using the counter to set the anti-replay parameter Time_Attr, as well as the aforementioned steps S103-S114. The related content of steps S203-S217 will not be expanded here.

It should be noted that when using a counter to set the anti-replay parameter Time_Attr, the vehicle does not need to send the anti-replay parameter Time_Attr to the car cloud server. That is to say, the asset information mentioned in step S103 and step S203 may not include the anti-replay parameter Time_Attr. This is because if the vehicle and the car cloud server both agree to use a counter to set the anti-replay parameter Time_Attr, that is, under what circumstances the value of the counter is changed, and the initial value of the counter, then the vehicle and the car cloud server can use the counter to set the anti-replay parameter Time_Attr. , determine the anti-replay parameter Time_Attr locally. For example, the vehicle and the vehicle cloud server agree to change the value of the counter every time a version is upgraded, and the initial value is 0. Then when the vehicle is upgraded for the third time, the vehicle and the vehicle cloud server can determine the current anti-replay parameter Time_Attr to be 3.

In addition, since some domain controller DCs in the vehicle do not have RPMB, when the verification of the authorization file is completed by multiple domain controller DCs, the domain controller can use the RPMB settings in other domain controller DCs to set up defenses. The replay parameter Time_Attr overcomes the defect that some domain controller DCs do not have RPMB and cannot use RPMB to set the anti-replay parameter Time_Attr.

Furthermore, it should be noted that the anti-replay parameter Time_Attr is verified by the domain controller that generates the anti-replay parameter Time_Attr. For example, the first domain controller uses the second domain controller to set the anti-replay parameter Time_Attr required by the first domain controller, that is, the first domain controller obtains the anti-replay parameter Time_Attr set by the second domain controller. The first domain controller sets other parameters in the asset information, such as the vehicle identification, and sends the anti-replay parameter Time_Attr along with the asset information to the car cloud server. Afterwards, when verifying the authorization file, the first domain controller completes After verifying other parameters except the anti-replay parameter Time_Attr, the authorization file is sent to the second domain controller, and the second domain controller verifies the anti-replay parameter Time_Attr.

Solution 2: Use Non-Volatile Counter (NV-Cnt) to set the anti-replay parameter Time_Attr

Since NV-Cnt can generate values that increase sequentially in one direction, and the change of this value is guaranteed by the fuse mechanism, its value cannot be tampered with at will. Therefore, the counter value can be stored in NV-Cnt and used as the anti-replay parameter Time_Attr. This can ensure that the anti-replay parameters cannot be tampered with and ensure the credibility of the verification process of the anti-replay parameters. Among them, the fusing mechanism is to blow the fuse bit in the chip to change the state of the fuse bit one-time and irreversibly, thereby protecting the The data cannot be tampered with after being stored. For a specific description of using a counter to set the anti-replay parameter Time_Attr, please refer to the above-mentioned solution 1 for setting the anti-replay parameter Time_Attr, which will not be elaborated here.

For example, a fixed bit field, such as 32 bits, in the OTP of the vehicle chip can be reserved as the NV-Cnt for setting the anti-replay parameter Time_Attr. For example, the initial value of NV-Cnt is 0. The embodiment of the present application does not limit the initial value of NV-Cnt.

The specific implementation process of using NV-Cnt to set the anti-replay parameter Time_Attr is described in detail below.

1) The car cloud server and the vehicle agree that the initial value of NV-Cnt is 0, and the value of this NV-Cnt is used as the anti-replay parameter Time_Attr.

2) When the car cloud server detects that there is a version with security vulnerabilities in the upgrade package of this vehicle or other vehicles, the car cloud server sends an adjustment instruction to the vehicle. The adjustment instruction is used to change the value of NV-Cnt, for example, to make NV -The value of Cnt is increased by 1.

3) After the vehicle obtains the adjustment instruction, it changes the value of NV-Cnt, for example, from 3 to 4.

4) When the vehicle sends asset information, the vehicle uses the changed value of NV-Cnt as the anti-replay parameter Time_Attr and sends it to the vehicle cloud server along with the asset information.

5) The car cloud server then uses the value of the NV-Cnt as the anti-replay parameter Time_Attr and sends it to the vehicle along with the authorization file.

6) After obtaining the anti-replay parameter Time_Attr in the authorization file, the vehicle reads the anti-replay parameter Time_Attr from the local NV-Cnt, and determines whether the anti-replay parameter Time_Attr in the authorization file is consistent with the local anti-replay parameter. Check whether the parameter Time_Attr is consistent. If the anti-replay parameter Time_Attr in the authorization file is consistent with the local anti-replay parameter Time_Attr, the anti-replay parameter verification passes; otherwise, the anti-replay parameter verification fails.

It should be noted that when using NV-Cnt to set the anti-replay parameter Time_Attr, there are also two situations where the counter value changes in the above solution one: the counter value changes every time the vehicle upgrades to a version, and the vehicle upgrades to a new version. The value of the counter is changed once after the version of the vulnerability is released. Among them, since the numerical change of NV-Cnt is guaranteed by the hardware mechanism, the numerical change is irreversible, and the number of digits of V-Cnt is fixed, so the number of numerical changes of NV-Cnt is limited. For example, 32-bit NV-Cnt supports up to 32 fusing times, that is, NV-Cnt can only support changing values up to 32 times. It can be seen that changing the counter value after the vehicle has been upgraded to a vulnerable version can reduce the number of changes to the NV-Cnt value, extend the use time of the chip as much as possible, and avoid frequent replacement of vehicle parts.

In addition, when verifying the authorization file in the secure boot scenario, compared to the first solution, using the second solution to set the anti-replay parameter Time_Attr can improve the vehicle detection efficiency. This is because the secure startup of components is a step-by-step verification process for each software in the startup chain, and RPMB can only be verified at the later stage of the startup chain. Therefore, it cannot protect the security of the front end of the startup chain, and the verification efficiency is low. The anti-replay parameter Time_Attr set by NV-Cnt can protect the security of the front end of the startup chain and improve verification efficiency.

Solution 3: Combine RPMB and NV-Cnt to set the anti-replay parameter Time_Attr

When setting the anti-replay parameter Time_Attr in combination with RPMB and NV-Cnt, you can set a random number through RPMB, set the counter through NV-Cnt, and use the random number and the value of the counter as the anti-replay parameter Time_Attr.

Then, the anti-replay parameter Time_Attr can include: the random number nonce stored in the RPMB of the domain controller DC, and the value of NV-Cnt in the domain controller DC.

Taking the domain controller DC as CDC as an example, Table 3 illustrates another possible structure of the signed authorization file provided by the embodiment of the present application.

table 3

As can be seen from Table 3, the anti-replay parameter Time_Attr in the authorization file specifically includes: NV-Cnt_CDC, nonce_CDC. Among them, NV-Cnt_CDC is the value in NV-Cnt of CDC, and nonce_CDC is the random number generated by CDC.

In addition, for descriptions of Space_Attr, Integrity_Attr, Sig(sk,M) and pk&pk_validity_proof in the authorization file, please refer to the relevant content in the aforementioned Table 1 and will not be repeated here.

It can be understood that the structure of the signed authorization file shown in Table 3 is only an illustrative example and does not constitute a limitation on the authorization file.

In addition, it should be noted that when the upgraded component is an electronic control unit ECU, since the verification of the authorization file corresponding to the electronic control unit ECU can be verified by its connected domain controller DC, then the anti-replay parameters The setup can be done by this domain controller DC. In other words, the anti-replay parameters in the authorization file corresponding to the electronic control unit ECU are generated by the domain controller DC to which it is connected.

In general, the anti-replay parameters are parameters agreed between the car cloud server and the vehicle to identify the local upgrade of the vehicle. The anti-replay parameters can be updated with each upgrade of the vehicle, so this is the anti-replay parameter. The parameters are only used for one upgrade of the logo. The anti-replay parameters can also be updated from time to time. In this case, the anti-replay parameters can be updated under preset circumstances. For example, the car cloud server discovers the existence of an old version upgrade package that has been sent. When a vulnerability occurs, the vehicle is notified to follow the vehicle cloud server and update the anti-replay parameters simultaneously.

The specific implementation process of integrity information is introduced in detail below.

The integrity information Integrity_Attr is used to uniquely identify this upgrade and the upgrade package sent by the Che Cloud server.

During the vehicle upgrade phase, the integrity information Integrity_Attr in the authorization file can be used to uniquely identify the upgrade package sent by the vehicle cloud server. That is to say, when the vehicle receives the upgrade package and the authorization file of the upgrade package, the vehicle can determine whether the authorization file is the authorization file of the upgrade package received by the vehicle by verifying the integrity information Integrity_Attr, or replace it with In other words, determine whether the upgrade package received by the vehicle is complete or has been tampered with. In this way, attackers can be prevented from forging upgrade packages and using fake upgrade packages to upgrade vehicles, ensuring the safety of vehicle upgrades.

During the secure startup phase, the integrity information Integrity_Attr in the authorization file can be used to uniquely identify the vehicle's upgraded software data after it is upgraded according to the upgrade package sent by the vehicle cloud server. In other words, when the vehicle receives the upgrade package and the authorization file of the upgrade package, and upgrades according to the upgrade package, the vehicle can determine whether the vehicle's data is based on the integrity information Integrity_Attr during safe startup. The software data after the upgrade package is upgraded. In this way, it can be prevented that after the vehicle is upgraded, the attacker can directly disassemble the vehicle, illegally import the upgrade package into the vehicle components, and change the software data of the vehicle components.

Because the vehicle upgrade methods are different, the integrity information Integrity_Attr contains different contents. The integrity information Integrity_Attr is introduced below according to different vehicle upgrade methods.

Option 1: Full upgrade

Full upgrade means that when a vehicle is upgraded, the vehicle is upgraded by downloading the complete software data and directly moving the downloaded software data to the location where the software runs.

In other words, during a full upgrade, the upgrade package sent by the car cloud server contains the complete data after the component upgrade.

In this case, the integrity information Integrity_Attr may include the hash value Hash[] of the upgrade package, which is a hash value calculated using a hash algorithm for the upgrade package.

Option 2: Differential upgrade

Differential upgrade means that when a vehicle is upgraded, it is implemented by downloading the incremental part that is different from the old version of the software data, then using the algorithm to synthesize the upgraded version of the software data based on the incremental part, and then moving it to the location where the software runs. Vehicle upgrades.

In other words, during differential upgrade, the upgrade package sent by the car cloud server only contains software data that is different before and after the component upgrade. At this time, the upgrade package sent by the car cloud server can also be called a differential package.

In this case, the integrity information Integrity_Attr may include: the hash value Hash_diff[] of the upgrade package and the hash value Hash_full[] of the image file.

Among them, Hash_diff[] is the hash value calculated using the hash algorithm for the upgrade package. The hash value Hash_diff[] of the upgrade package is the integrity information verified when the vehicle is verifying the authorization file during the vehicle upgrade stage. The hash value Hash_full[] of the image file is the hash value calculated using the hash algorithm for the complete software data required for component upgrade. The hash value Hash_full[] of the image file is the integrity information verified when the vehicle verifies the authorization file during the safe startup phase.

That is to say, when the vehicle upgrade method is differential upgrade, the authorization file sent by the vehicle cloud server to the vehicle contains two integrity information, and different integrity information is verified during the vehicle upgrade stage and the safe startup stage.

In this embodiment of the present application, the hash value Hash_full[] of the image file may also be called the second integrity information.

Option 3: A/B upgrade

The premise of A/B upgrade is that there are two systems in the vehicle. A/B upgrade means ensuring the normal operation of one system and upgrading the other system during the upgrade process.

In this case, the integrity information Integrity_Attr may include: the hash value Hash_update[] of the upgrade package, and the hash value Hash_rollback[] of the rollback file.

Among them, the hash value Hash_update[] of the upgrade package is the hash value calculated using the hash algorithm for the upgrade package. The hash value Hash_diff[] of the upgrade package is used to verify the integrity information when verifying the authorization file during the vehicle upgrade phase and secure startup phase. The hash value Hash_rollback[] of the rollback file is the hash value calculated by combining the current vehicle data and the upgraded data. This rollback file contains the data contained in the parts when the vehicle part upgrade fails and is rolled back to the original version. The hash value Hash_rollback[] of the rollback file is used to verify the data in the vehicle after the vehicle upgrade fails.

Specifically, after the vehicle cloud server receives the asset information, the vehicle cloud server can determine the vehicle upgrade method based on the software and hardware information of the asset information terminal, thereby determining the integrity information that needs to be sent to the vehicle.

In this embodiment of the present application, the hash value Hash_rollback[] of the rollback file may also be called the third integrity information.

In addition, the integrity information Integrity_Attr has different expression forms for different components that are upgraded. The following combines two solutions to introduce the integrity information Integrity_Attr.

Option 1: Calculate the hash value of the entire upgrade package

At this time, the integrity information Integrity_Attr may refer to a value calculated using a hash algorithm for the entire upgrade package.

This solution is applicable to the electronic control unit (ECU) connected to the domain controller DC as the upgraded component.

This method of calculating hash values for the entire upgrade package can speed up the verification of integrity information. During the vehicle upgrade phase, the vehicle only needs to calculate the hash value of the upgrade package when verifying the authorization file, and determine whether the hash value matches the integrity information in the authorization file. If the information is consistent, you can determine whether the integrity information verification has passed. During the secure startup phase after vehicle component upgrades, the vehicle only needs to calculate the hash value of the entire software of the vehicle component when verifying the authorization file, and determine whether the hash value is consistent with the complete new information in the authorization file. Whether the integrity information verification passes.

Option 2: Calculate the hash value of the upgrade file

At this time, the integrity information Integrity_Attr may refer to multiple hash values calculated using a hash algorithm on multiple upgrade files included in the upgrade package. In other words, the integrity information Integrity_Attr is represented as an array containing multiple values.

This scenario applies to the upgraded component being the domain controller DC.

This method of calculating the hash value of the upgrade file can make the integrity check of the upgrade package more accurate. Based on these multiple hash values, the vehicle can more accurately know that during the transmission of the upgrade package, the upgrade package has been damaged. The tampered part, or the software part of the component that was tampered with during the vehicle start-up phase.

In other words, the integrity information may include one or more parameters, and the one or more parameters may be used to identify the upgrade package.

In addition, in actual situations, the integrity information Integrity_Attr can be set comprehensively based on the vehicle upgrade method and vehicle upgrade components. For example, when the vehicle upgrade mode is full upgrade and the upgraded component is the electronic control unit ECU, the integrity information Integrity_Attr is the hash value calculated for the entire upgrade package of the component. For another example, when the vehicle upgrade method is differential upgrade and the upgraded component is a domain controller DC, the integrity information Integrity_Attr can include the hash values of multiple upgrade files in the upgrade package, as well as multiple complete images after the upgrade. The hash value of the file.

The following describes in detail the specific implementation process of the legality certificate used to verify the legality of the authorized public key.

Since the signature of the authorized file is encrypted using the authorized private key generated by the CheCloud server, and the verification of the signature is also implemented through the authorized public key provided by the CheCloud server, in order to prevent attackers from forging the authorized private key and To authorize the public key to tamper with the authorization file, the car cloud server needs to have a verification mechanism that can verify the legitimacy of the authorized public key when it provides the authorized public key for verifying the signature.

That is to say, before the vehicle triggers the verification of the authorization file, for example, before step S113, the legality of the authorization public key can be verified first.

Two verification mechanisms are provided below to prove the legitimacy of the authorized public key.

Option 1: The vehicle pre-stores in the chip the hash value of the authorized public key used to verify the signature of the authorized file.

For example, the vehicle can reserve a fuse bit in the OTP of the chip for storing the hash value of the authorized public key for verifying the signature of the authorized file. It can be seen that storing the hash value of the authorized public key in OTP can prevent attackers from tampering with the hash value of the authorized public key stored locally in the vehicle, ensuring the credibility of the verification mechanism when verifying the legitimacy of the authorized public key. Spend.

Specifically, when the vehicle obtains the authorization file, the hash algorithm can be used to calculate the hash value of the authorization public key in the authorization file, and then the hash value is compared with the authorization stored locally in the vehicle for verifying the signature of the authorization file. Compare the hash value of the public key. If the two are consistent, it means that the authorized public key in the authorization file is legal and has not been tampered with. Otherwise, it means that the authorized public key in the authorization file is illegal.

It can be seen that in this case, the authorization file does not need to contain the legality proof pk_validity_proof of the authorization public key.

Solution 2: Reuse the public key to verify the package signature

After the Cheyun server generates a key pair for encrypting and verifying the signature of the authorized file, it can send the authorized public key in the key pair to the supplier server, and the supplier server uses the private key to generate the package signature. The authorized public key is encrypted, the signature of the authorized public key is obtained, and the signature is sent to the car cloud server. In this way, when the vehicle obtains the authorized public key in the authorization file and the signature of the authorized public key, the legitimacy of the authorized public key can be verified through the public key used to verify the package signature.

At this time, the legality proof of the authorized public key can be the signature obtained when the supplier server uses the private key to generate the package signature and digitally signs the authorized public key. In this embodiment of the present application, the supplier server uses the private key to generate the packet signature, and the obtained signature of the authorization file may also be called a second signature.

Specifically, after the vehicle obtains the authorization file, it can calculate the message digest of the authorized public key in the authorization file, and use the public key used to decrypt the package signature to decrypt the legality certificate of the authorized public key in the authorization file, obtaining A message digest. The vehicle can determine whether the message digest in the authorization file has not been tampered with by comparing the message digest with the calculated message digest of the authorization public key in the authorization file. If the two are consistent, it indicates authorization. The authorized public key in the file is legal and has not been tampered with. Otherwise, it means that the authorized public key in the authorization file is illegal.

When the package signature is obtained by the supplier server using a multi-level key to sign the upgrade file, and using option 2 to set the legal proof of the authorized public key, the following additional content needs to be included:

1) Specify the purpose of the authorized public key, or use multi-level keys to set the signature of the authorized public key

When the supplier server uses a third-level key to implement the package signature in the upgrade package, then the CheCloud server can generate a key pair on its own to forge the package signature in the upgrade package, thus causing a problem between the supplier server and the CheCloud server. Confusion about signature capabilities.

Since the package signature is obtained by the supplier's server using a third-level key to sign the upgrade file, when the vehicle verifies the package signature, it needs to be verified three times to finally complete the verification of the package signature. For details, please refer to the relevant content in the aforementioned step S115.

It is assumed that the legality proof of the authorized public key is the signature of the authorized public key by the supplier server using the wrapped root private key in the third-level key. Then the car cloud server can generate a pair of keys at the next level of the authorized public key and authorized private key, and use the private key in the key pair to sign the upgrade package. When the vehicle verifies the signature, The effect of vehicle verification three times can also be achieved, and the verification of the signature and the verification of the packaged signature generated by the supplier server start from verifying the packaged root public key generated by the supplier server. It can be seen that the Cheyun server can forge the possibility of compiling signatures, which reduces the credibility of verification of compilation signatures.

Therefore, the signature capabilities of the supplier server and the car cloud server can be distinguished by specifying the purpose of the authorized public key, or by using multi-level keys to set the signature of the authorized public key.

Among them, stipulating the purpose of the authorized public key means that when the car cloud server sends the authorized public key to the vehicle, it also includes the purpose information of the authorized public key. This purpose information is used to indicate that the authorized public key can only be used to verify authorization. Sign the file, thereby distinguishing the signature capabilities of the supplier server and the car cloud server from the use of public keys. For example, the usage information can be stored in the usage field. When using multi-level keys to set the signature of an authorized public key, the number of verifications when verifying the signature of the authorized public key should be greater than the number of verifications when verifying the packaged signature, so as to distinguish the supplier from the number of verifications Signature capabilities of servers and car cloud servers.

Figure 11 is a flow chart of the interaction between the supplier server and the car cloud server when multi-level keys are used to set the signature of the authorized public key provided by the embodiment of the present application.

As shown in Figure 11, the interaction process between the supplier server and the car cloud server includes:

S401. The car cloud server sends the authorized public key to the supplier server.

The authorization public key is the public key generated by the car cloud server and used to verify the signature of the authorization file. Among them, the signature of the authorization file is obtained by using the authorization private key to sign the authorization file on the Cheyun server. For a specific description of the authorized public key, please refer to the foregoing content and will not be repeated here.

S402. The supplier server generates N pairs of keys.

When the supplier server uses multi-level keys to implement package signature, it is assumed that the supplier server uses M-level keys to implement package signature, where M≥2 and M is a positive integer.

In order to distinguish the signature capabilities of the supplier server and the car cloud server, N≥M-1, and N is a positive integer. For example, when M=3, the supplier server uses a third-level key to implement package signature, and N can be 2, that is, the supplier server can generate 2 pairs of keys. For another example, when M=4, the supplier server uses a four-level key to implement package signature, and N can be 4, that is, the supplier server can generate 4 pairs of keys.

S403. The supplier server uses the wrapped root private key and the N pairs of keys to sign the authorized public key.

The package root private key is the first-level private key among the multi-level keys used to implement package signature.

Specifically, the N pairs of keys may include: the first public key and the first private key, the second public key and the second private key, ..., the Nth public key and the Nth private key.

When the supplier server uses the wrapped root private key and the N pairs of keys to sign the authorized public key, the supplier server can use the wrapped root private key to sign the first public key to obtain the signature of the first public key. , use the first private key to sign the second public key, and obtain the signature of the second public key..., use the Nth private key to sign the authorized public key, and obtain the signature of the authorized public key, thereby realizing the use of multi-level encryption The key sets the signature of the authorized public key.

The following uses a specific example to describe how the supplier server uses the wrapped root private key and the N pairs of keys to implement the signature of the authorized public key.

Among them, it is assumed that M=3 and N=2. That is, the supplier server uses a three-level key to implement package signature and generates 2 pairs of keys for signing the authorization file.

Exemplarily, FIG. 12 is a schematic structural diagram of a multi-level key provided by an embodiment of the present application.

Among them, the packaged root public key and packaged root private key, packaged layer 2 public key and packaged layer 2 private key, packaged layer 3 public key and packaged layer 3 private key shown in Figure 12 are the suppliers. A third-level key generated by the server. This third-level key is used to complete the package signature of the upgrade file in the upgrade package.

It can be seen that when verifying the packaged signature, it is necessary to complete the packaged root public key to verify the signature of the packaged layer 2 public key, the packaged layer 2 public key to verify the packaged layer 3 public key, and the packaged layer 3 public key. This is the three verification processes of layer public key verification software data package signature. For a specific description of these three-level keys, please refer to the relevant content of the aforementioned step S101 and step S115, which will not be described again here.

In addition, the one-vehicle-authorization public key and one-vehicle authorization private key, the authorization root public key, and the authorization root private key shown in Figure 12 are two pairs of keys generated by the supplier server to implement the signature of the authorization file.

Specifically, the supplier server can use the packaged root private key to sign the one-vehicle-authorized public key to obtain the signature of the one-vehicle-authorized public key, and use the one-vehicle authorized private key to sign the authorized root public key to obtain authorization. For the signature of the root public key, use the authorized root private key to sign the authorized public key to obtain the signature of the authorized public key.

It can be seen that when verifying the signature of the authorized file, it is necessary to complete the packaged root public key to verify the signature of one authorized public key for each vehicle, and verify the signature of the authorized root public key for each vehicle. The authorized root public key Verify the signature of the authorized public key, and verify the signature of the authorized file with the authorized public key. This is a four-step verification process. This can avoid the problem of the CheCloud server generating a key pair on its own to forge the package signature of the upgrade package.

S404. The supplier server sends the signature of the authorized public key to the car cloud server.

The supplier server can send the signature of the authorized public key to the CheCloud server as proof of the legality of the authorized public key, thereby achieving the purpose of reusing the public key for verification and package signature to verify the legality of the authorized public key.

2) Distinguish the authorized public keys of different car cloud servers

It should be understood that since there are usually multiple vehicle manufacturers, the servers of different vehicle manufacturers can complete vehicle upgrades. For example, vehicles produced by vehicle manufacturer A (hereinafter referred to as vehicle manufacturer A) can obtain the upgrade package through the server of vehicle manufacturer A (hereinafter referred to as vehicle cloud server A) and complete the upgrade. Vehicles produced by vehicle manufacturer B (hereinafter referred to as vehicle manufacturer B) can obtain the upgrade package through the vehicle manufacturer A's server (hereinafter referred to as vehicle cloud server A). Server B (hereinafter referred to as Cheyun Server B) obtains the upgrade package and completes the upgrade.

Figure 13 is a logical schematic diagram of the supplier server signing the authorized public keys of multiple car cloud servers provided by the embodiment of the present application.

As shown in Figure 13, there are car cloud server A and car cloud server B that sign the authorized public key through the supplier server. Among them, the supplier server uses the key generator Kg(1 ⁿ ) to generate a pair of keys (pk, sk), where sk is the package secret used to package the upgrade file x with the package signature Sig(sk,x). key, pk is the packet public key used to verify the packet signature σ _x . Cheyun server A uses the key generator Kg(1 ⁿ ) to generate a pair of keys (pk _A , sk _A ), where sk _A is used to sign the authorization file auth_doc _A Sig (sk _A , auth_doc _A ) Authorization private key, pk _A is the authorization public key used to verify the signature σauth_doc _A of the authorization file auth_doc _A. Cheyun server B uses the key generator Kg(1 ⁿ ) to generate a pair of keys (pk _B , sk _B ) , where sk _B is the authorization private key used to sign the authorization file auth_doc _B Sig (sk _B , auth_doc _B ), and pk _B is the authorization public key used to verify the signature σauth_doc _B of the authorization file auth_doc _B.

The car cloud server A can send pk _A to the supplier server, and the supplier server can use sk to sign the pk _A , that is, Sig(sk,pk _A ), get the signature σ _A of pk _A , and return it to the car cloud server A. Cloud server A.

The car cloud server B can send pk _B to the supplier server, and the supplier server can use sk to sign the pk _B , that is, Sig(sk,pk _B ), get the signature σ _B of pk _B , and return it to the car cloud server B. Cloud server B.

As can be seen from Figure 13, for the same upgrade file provided by the supplier server, the legality of the authorized public key of Car Cloud Server A and the authorized public key of Car Cloud Server B are the same public key provided by the supplier server. To guarantee.

That is to say, when the vehicle produced by car manufacturer A is upgraded, not only the authorized public key in the authorization file provided by car cloud server A can pass the legality certificate, but the authorized public key in the authorization file provided by car cloud server B can also pass the legality certificate. prove.

Then, if the authorization private key of car manufacturer B is stolen by an attacker, and then forges the signature of the authorization document, and uses the forged authorization document to attack the vehicles produced by car manufacturer A, the commercial interests of car manufacturer A may be easily affected.

Distinguishing the authorized public keys of the car cloud servers of different vehicle manufacturers is to avoid the loss of the authorized private keys of the car cloud servers of some vehicle manufacturers, which will also affect other vehicle manufacturers. That is to say, after the vehicle obtains the authorization file, it can first determine whether the generator of the authorization public key in the authorization file is the target car manufacturer, and then decide whether to use the authorization public key to verify the legality of the authorization file.

For example, the vehicle manufacturer can use a black/white list to set the target vehicle manufacturer. The authorization public key generated by the vehicle manufacturer in the white list is a public key that is allowed to be used to verify the authorization file, and the authorization public key generated by the vehicle manufacturer in the black list is Authorization public key is a public key that is not allowed to be used to verify authorized files.

For example, when a vehicle manufacturer uses a whitelist to set a target vehicle manufacturer, the vehicle manufacturer can send the whitelist to the vehicle in advance before the vehicle verifies the authorization file. The vehicle first determines the authorization public key before verifying the legality of the authorization file. Is the generator in the whitelist a car manufacturer? If so, the vehicle can use the authorized public key to verify the legality of the authorized file. Otherwise, the vehicle cannot use the authorized public key to verify the legality of the authorized file.

In addition, in order to prevent attackers from forging the black/white list, the vehicle manufacturer can send the black/white list to the supplier server before providing the black/white list, and the key pair generated by the supplier server sets the black/white list sign. Further, the supplier server can use multi-level keys to set the signature of the black/white list.

The following uses a specific example to describe how the supplier server uses multi-level keys to set the signature of the black/white list.

Assume that the supplier server uses a third-level key to set up a whitelist. There are authorized public key A and authorized private key A generated by car factory server A, authorized public key B and authorized private key B generated by car factory server B, and whitelist of car factory A. List A, whitelist B of car manufacturer B, authorized public keys of car manufacturers listed in whitelist A, public keys allowed to be used to verify authorization files for vehicles produced by car manufacturer A, authorized public keys of car manufacturers listed in whitelist B , the public key that is allowed to be used to verify the authorization file for vehicles produced by vehicle manufacturer B.

Exemplarily, FIG. 14 is a schematic structural diagram of another multi-level key provided by an embodiment of the present application.

As shown in Figure 14, authorized public key A and authorized private key A Key pair generated for car factory server A, authorized public key B and authorized public key B The key pair generated for the car factory server B, the packaged root public key (pk ₁ ) and the packaged root private key (sk ₁ ), the one-vehicle-one-authorization public key (pk ₂ ) and the one-vehicle-one-authorization private key (sk ₂ ), authorized root public key and authorized root private key A key pair generated by the supplier server to set the signature of the authorized public key A of the car manufacturer server A and the authorized public key B of the car manufacturer server B. For a detailed description of these key pairs, please refer to the relevant content of Figure 8. I won’t go into details here.

In addition, in order to set up the signature of the whitelist, the supplier server can also generate a pair of keys: the permission public key and license private key And use the one-vehicle-one-authorized private key to sign the license public key to obtain the signature of the license public key. Use the license private key to sign whitelist A and whitelist B to obtain the signature of whitelist A and the signature of whitelist B.

The car manufacturer's server can send a permission list to the vehicle, and the permission list can include: a whitelist set by the vehicle manufacturer, and the signature of the whitelist. Exemplarily, Table 4 shows the structure of authorization file A, Table 5 shows the structure of authorization file B, Table 6 shows the structure of the permission list A sent by car manufacturer server A, and Table 7 shows the structure of car manufacturer server B. The structure of the sent permission list B.

Table 4

Among them, the authorization file A may include three parts: attribute field M ₁ , signature field and authorized public key field. Among them, the attribute domain M ₁ may include: vehicle identity identifier Space_Attr1, anti-replay parameter Time_Attr1, and integrity information Integrity_Attr1. The signature domain includes the car cloud server A using its own authorized private key. Signature calculated for attribute domain M ₁ The authorized public key field includes: authorized public key and, for verification Multiple parameters for _the legality _of Signature Sig(sk ₁ ,pk ₂ ) of key pk ₂ , authorized root public key Authorized root public key signature Authorized public key signature Among them, the authorized public key Used to verify signature Authorized root public key Used for school Verification signature One vehicle, one authorized public key pk ₂ is used to verify signatures The packaged root public key (pk ₁ ) is used to verify the signature Sig (sk ₁ ,pk ₂ ).

For the specific description of the attribute domain, please refer to the relevant content of the aforementioned Table 1, specifically regarding pk ₁ , pk ₂ , Sig(sk ₁ , pk ₂ ), The description can be found in Figure 13.

table 5

Among them, the authorization file B may include three parts: attribute field M ₂ , signature field and authorized public key field. Among them, the attribute domain M ₂ may include: vehicle identity identifier Space_Attr2, anti-replay parameter Time_Attr2, and integrity information Integrity_Attr2. The signature domain includes the car cloud server B using its own authorized private key. Signature calculated for attribute domain M ₁ The authorized public key field includes: authorized public key and, for verification Multiple parameters for _the legality _of Signature Sig(sk ₁ ,pk ₂ ) of key pk ₂ , authorized root public key Authorized root public key signature Authorized public key signature Among them, the authorized public key Used to verify signature Authorized root public key Used to verify signature One vehicle, one authorized public key pk ₂ is used to verify signatures The packaged root public key (pk ₁ ) is used to verify the signature Sig (sk ₁ ,pk ₂ ).

Table 6

Among them, the permission list A may include three parts: attribute domain M _A , signature domain and key chain domain. Among them, the attribute domain M _A may include: vehicle identity identifier Space_Attr1, anti-replay parameter Time_Attr1 and whitelist public key The signing domain includes the vendor server with its own licensing private key The signature calculated for the attribute domain M _A dense The key chain domain includes: packaged root public key (pk ₁ ), one-car-one-authorized public key (pk ₂ ), one-car-one authorized public key (pk ₂ ) signature Sig (sk ₁ , pk ₂ ), license public key key License public key signature Among them, the license public key Used to verify signature One vehicle, one authorized public key (pk ₂ ) is used to verify signatures The packaged root public key (pk ₁ ) is used to verify the signature Sig (sk ₁ ,pk ₂ ).

For specific descriptions of vehicle identification and anti-replay parameters, please refer to the foregoing content, specifically regarding pk ₁ , pk ₂ , Sig(sk ₁ ,pk ₂ ), The description can be found in Figure 13.

As can be seen from Table 6, in the attribute domain M _A Vehicles instructed by car manufacturer A can only use the authorized public key generated by car manufacturer A. To verify the legality of the authorization file, the signature in the signature field is used to prove the legality of the attribute field M _A. The key chain field contains the public key used to verify the signature and the legality certificate of the public key.

Table 7

Among them, the permission list B may include three parts: the attribute field _MB , the signature field and the key chain field. Among them, the attribute domain M _B may include: vehicle identity identifier Space_Attr2, anti-replay parameter Time_Attr2 and whitelist public key The signing domain includes the vendor server with its own licensing private key The signature calculated for the attribute domain M _B The key chain domain includes: packaged root public key (pk ₁ ), one-car-one-authorized public key (pk ₂ ), one-car-one authorized public key (pk ₂ ) signature Sig (sk ₁ , pk ₂ ), license public key License public key signature Among them, the license public key Used to verify signature One vehicle, one authorized public key (pk ₂ ) is used to verify signatures The packaged root public key (pk ₁ ) is used to verify the signature Sig (sk ₁ ,pk ₂ ).

For specific descriptions of vehicle identification and anti-replay parameters, please refer to the foregoing content, specifically regarding pk ₁ , pk ₂ , Sig(sk ₁ ,pk ₂ ), The description can be found in the relevant content of Figure 10.

As can be seen from Table 7, in the attribute domain M _B Vehicles instructed by Depot B can only use the authorized public key generated by Depot B. To verify the legality of the authorization file, the signature in the signature field is used to prove the legality of the attribute field _MB . The key chain field contains the public key used to verify the signature and the legality certificate of the public key.

In the embodiment of this application, the permission list or black/white list may also be called the first list.

It can be understood that the above-mentioned Tables 5 to 7 are only illustrative examples and do not constitute a limitation on the embodiments of the present application. In other embodiments of the present application, the permission list may contain more or fewer parameters. For example, the attribute field can contain only whitelist public keys, and when the supplier server uses more or fewer levels of key pairs to set up the whitelist's signature, the keychain field can contain more or fewer public keys. key and public key signature.

In general, the vehicle upgrade verification method provided by the embodiment of the present application can verify the upgrade package received by the vehicle during the vehicle upgrade stage, only when the upgrade package is an upgrade package suitable for the current upgrade of the vehicle. , the vehicle upgrade is triggered. When the upgrade package is not applicable to the vehicle, for example, an upgrade package for an old version, an upgrade package for other vehicles, or an upgrade package used in the research and development phase, the vehicle upgrade will be cancelled. Furthermore, during the safe startup phase, this method can also Triggers the verification of vehicle upgraded data. Only when the vehicle upgraded data is the data obtained through the vehicle upgrade stage and the upgrade package, the vehicle can be started to run. This avoids malicious disassembly by attackers and will not be applicable. Import the vehicle's upgrade package into the vehicle and change the vehicle's data to ensure vehicle safety.

It should be understood that each step in the above method embodiment can be completed by an integrated logic circuit of hardware in the processor or instructions in the form of software. The method steps disclosed in conjunction with the embodiments of this application can be directly implemented by a hardware processor, or executed by a combination of hardware and software modules in the processor.

This application also provides an electronic device, which may include a memory and a processor. The memory can be used to store computer programs; the processor can be used to call the computer program in the memory, so that the electronic device executes the method executed by the supplier server, vehicle cloud server or vehicle in any of the above embodiments.

This application also provides a chip system that includes at least one processor for implementing the functions involved in the method executed by the supplier server, vehicle cloud server, or vehicle in any of the above embodiments.

In a possible design, the chip system further includes a memory, the memory is used to store program instructions and data, and the memory is located within the processor or outside the processor.

The chip system can be composed of chips or include chips and other discrete devices.

Optionally, there may be one or more processors in the chip system. The processor can be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, or the like. When implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in memory.

Optionally, there may be one or more memories in the chip system. The memory may be integrated with the processor or may be provided separately from the processor, which is not limited by the embodiments of the present application. For example, the memory may be a non-transient processor, such as a read-only memory ROM, which may be integrated with the processor on the same chip, or may be separately provided on different chips. The embodiments of this application vary on the type of memory, and The arrangement of the memory and processor is not specifically limited.

For example, the chip system can be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a system on chip (SoC). It can also be a central processor (central processor unit, CPU), a network processor (network processor, NP), a digital signal processing circuit (digital signal processor, DSP), or a microcontroller (micro controller unit (MCU), or a programmable logic device (PLD) or other integrated chip.

The present application also provides a computer program product. The computer program product includes: a computer program (which can also be called a code, or an instruction). When the computer program is run, it causes the computer to execute any of the above embodiments. A method executed by any one of the server, vehicle cloud server or vehicle.

This application also provides a computer-readable storage medium that stores a computer program (which may also be called a code, or an instruction). When the computer program is run, the computer is caused to execute the method executed by any one of the supplier server, vehicle cloud server, or vehicle in any of the above embodiments.

It should be understood that the processor in the embodiment of the present application may be an integrated circuit chip with signal processing capabilities. During the implementation process, each step of the above method embodiment can be completed through an integrated logic circuit of hardware in the processor or instructions in the form of software. The above-mentioned processor can be a general-purpose processor, a digital signal processor (DSP), an AP 800plication specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. Each method, step and logical block diagram disclosed in the embodiment of this application can be implemented or executed. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. Combined with the embodiments of this application The steps of the disclosed method can be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

In addition, the embodiment of the present application also provides a device. The device may specifically be a component or module, and the device may include one or more connected processors and memories. Among them, memory is used to store computer programs. When the computer program is executed by one or more processors, the device is caused to execute the methods in each of the above method embodiments.

Among them, the devices, computer-readable storage media, computer program products or chips provided by the embodiments of the present application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects it can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be described again here.

The various embodiments of the present application can be combined arbitrarily to achieve different technical effects.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in this application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, e.g., the computer instructions may be transferred from a website, computer, server, or data center Transmission to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more available media integrated. The available media may be magnetic media (eg, floppy disk, hard disk, magnetic tape), optical media (eg, DVD), or semiconductor media (eg, solid state disk (SSD)), etc.

Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments are implemented. This process can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, , may include the processes of the above method embodiments. The aforementioned storage media include: ROM, random access memory (RAM), magnetic disks, optical disks and other media that can store program codes.

In short, the above descriptions are only examples of the technical solutions of the present invention and are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made based on the disclosure of the present invention shall be included in the protection scope of the present invention.

Claims

A vehicle verification method, characterized in that the method includes:

The vehicle receives a first file and a first upgrade package. The first file includes: a first vehicle identification, first integrity information, and a third information determined based on the first vehicle identification and the first integrity information. a signature;

The vehicle uses the public key of the first server to verify the first signature, and the verification passes; the first server is used to manage the upgrade of the vehicle;

The vehicle determines that the first vehicle identification is the same as the vehicle identification of the vehicle, and the first upgrade package is the upgrade package indicated by the first integrity information;

The vehicle is upgraded according to the first upgrade package to enhance a first function or add a first function.
The method according to claim 1, characterized in that after the vehicle is upgraded according to the first upgrade package, the method further includes:

The vehicle again uses the public key of the first server to verify the first signature, and the verification passes,

The vehicle again determines that the first vehicle identification is the same as the vehicle identification of the vehicle, and the upgraded data of the vehicle includes data in the upgrade package indicated by the first integrity information;

The vehicle activates the first function.
A vehicle verification method, characterized in that the method includes:

The vehicle receives a first file and a first upgrade package, the first file includes: a first anti-replay parameter, first integrity information, and, according to the first anti-replay parameter and the first integrity The first signature to confirm the information;

The vehicle uses the public key of the first server to verify the first signature, and the verification passes; the first server is used to manage the upgrade of the vehicle;

The vehicle determines that the first anti-replay parameter is the same as the anti-replay parameter of the vehicle, and the first upgrade package is the upgrade package indicated by the first integrity information; the anti-replay parameter of the vehicle The parameters are used to identify the current upgrade of the vehicle;

The vehicle is upgraded according to the first upgrade package to enhance a first function or add a first function.
The method of claim 3, wherein the first file further includes a first vehicle identification, and the first signature is a signature determined based on the first vehicle identification and the first anti-replay parameter. ;

Before the vehicle is upgraded according to the first upgrade package, the method further includes:

The vehicle determines that the first vehicle identification and the vehicle identification of the vehicle are the same.
The method according to claim 3 or 4, characterized in that after the vehicle is upgraded according to the first upgrade package, the method further includes:

The vehicle uses the public key of the first server again to verify the first signature, and the verification passes;

The vehicle again determines that the first anti-replay parameter is the same as the anti-replay parameter of the vehicle, and the upgraded data of the vehicle includes the data in the upgrade package indicated by the first integrity information;

The vehicle activates the first function.
The method according to claim 4, characterized in that after the vehicle is upgraded according to the first upgrade package, the method further includes:

The vehicle uses the public key of the first server again to verify the first signature, and the verification passes;

The vehicle again determines that the first anti-replay parameter is the same as the anti-replay parameter of the vehicle, and that the first vehicle identification is the same as the vehicle identification of the vehicle, and that the upgraded vehicle's The data includes data in the upgrade package indicated by the first integrity information;

The vehicle activates the first function.
A vehicle verification method, characterized in that the method includes:

The vehicle receives a first file and a first upgrade package. The first file includes: a first vehicle identifier, first integrity information, and a third file determined based on the first vehicle identifier and the first integrity information. a signature;

The vehicle detects an instruction to activate a first function, and the first function is a function that is enhanced or added after the vehicle is upgraded according to the first upgrade package;

The vehicle uses the public key of the first server to verify the first signature, and the verification passes; the first server is used to manage the upgrade of the vehicle;

The vehicle again determines that the first vehicle identification is the same as the vehicle identification of the vehicle, and the upgraded data of the vehicle includes data in the upgrade package indicated by the first integrity information;

The vehicle activates the first function.
A vehicle verification method, characterized in that the method includes:

The vehicle receives a first file and a first upgrade package, the first file includes: a first anti-replay parameter, first integrity information, and, according to the first anti-replay parameter and the first integrity The first signature to confirm the information;

The vehicle detects an instruction to activate a first function, and the first function is a function that is enhanced or added after the vehicle is upgraded according to the first upgrade package;

The vehicle uses the public key of the first server to verify the first signature, and the verification passes; the first server is used to manage the upgrade of the vehicle;

The vehicle again determines that the first anti-replay parameter is the same as the vehicle identification of the vehicle, and the upgraded data of the vehicle includes the data in the upgrade package indicated by the first integrity information;

The vehicle activates the first function.
The method of claim 8, wherein the first file further includes a first vehicle identification, and the first signature is a signature determined based on the first vehicle identification and the first anti-replay parameter. ;

Before the vehicle activates the first function, the method further includes:

The vehicle determines that the first vehicle identification and the vehicle identification of the vehicle are the same.
The method according to any one of claims 3-6, 8, and 9, characterized in that the anti-replay parameters of the vehicle are updated with each upgrade of the vehicle and are only used to identify the vehicle. One upgrade, or the vehicle's anti-replay parameters are used to identify multiple upgrades of the vehicle.
The method according to any one of claims 1 to 10, characterized in that, when the first upgrade package is an upgrade package identified by the first integrity information, the first integrity information includes a or multiple parameters, the one or more parameters are used to identify the first upgrade package.
The method according to any one of claims 1-11, characterized in that the first file further includes: a first public key; the vehicle has a first identifier of the public key of the first server pre-stored, so Before the vehicle uses the public key of the first server to verify the first signature, the method further includes:

The vehicle determines the identity of the first public key;

When the identifier of the first public key is the same as the first identifier, the vehicle determines that the first public key is the public key of the first server.
The method according to any one of claims 1 to 12, characterized in that the first file further includes: a first public key, and a second signature determined according to the first public key, the vehicle Before verifying the first signature using the public key of the first server, the method further includes:

The vehicle uses the public key of a second server to verify the second signature; wherein the second server is a server that develops and provides an upgrade package required for the vehicle upgrade;

If the verification of the second signature passes, the vehicle determines that the first public key is the public key of the first server.
The method of claim 13, wherein the vehicle stores usage information of the first public key, and the usage information is used to indicate that the first public key is only used to verify the first public key. sign.
The method according to any one of claims 1 to 14, characterized in that before the vehicle uses the public key of the first server to verify the first signature, the method further includes:

The vehicle determines that the first public key is a public key that the first server allows the vehicle to use.
The method according to any one of claims 1, 2, 4-6, 8, 9, characterized in that the vehicle identification of the vehicle is used to identify the first component of the vehicle;

The vehicle is upgraded according to the first upgrade package, which specifically includes:

The vehicle upgrades the first component or the second component according to the first upgrade package, and the upgrade of the second component is managed by the first component.
The method of claim 16, wherein when the vehicle upgrades the second component, the vehicle's identity is also used to identify a third component.
The method of claim 17, wherein the vehicle verifies the first file through the first component, or the vehicle verifies the first file through the first component and the third component. Describe the first document.
The method according to any one of claims 2 and 5-10, wherein the first file further includes: second integrity information, and the first signature is further determined based on the second integrity information,

The vehicle determines that the data of the upgraded vehicle includes data in the upgrade package indicated by the first integrity information, specifically including:

The vehicle determines that the data of the upgraded vehicle is the same as the data indicated by the second integrity information, and the data indicated by the second integrity information includes the data in the first upgrade package.
The method according to any one of claims 1 to 19, characterized in that the first file further includes: third integrity information, the first signature is further determined based on the third integrity information, in which If the verification of the first signature passes, the third integrity information is used to indicate the data after the vehicle upgrade fails.
The method according to any one of claims 1 to 20, characterized in that the first upgrade package includes a third signature and/or a fourth signature, and the third signature is obtained by signing the first server, The fourth signature is obtained by a second server signature, and the second server is a server that develops and provides upgrade files required for the vehicle upgrade;

Before the vehicle is upgraded according to the first upgrade package, the method further includes:

The vehicle uses the public key of the first server to verify the third signature, and the verification passes;

and / or,

The vehicle uses the public key of the second server to verify the fourth signature, and the verification passes.
The method according to any one of claims 1-21, characterized in that before the vehicle receives the first file and the first upgrade package, the method further includes:

The vehicle receives an upgrade policy;

The vehicle determines a first address according to the upgrade strategy, and the first address is an address where the first upgrade package is stored;

The vehicle sends a download request to the server where the first address is located, and the download request is used to request to obtain the first upgrade package.
A vehicle verification method, characterized in that the method includes:

The first server obtains the vehicle identification of the vehicle;

The first server determines the integrity information of the upgrade package, and the integrity information is used to identify the upgrade package;

The first server determines a signature based on the vehicle identification and the integrity information; the first server sends a file and the upgrade package, the file includes: the vehicle identification, the integrity information and the Signature; the upgrade package is used to upgrade the vehicle.
The method of claim 23, wherein the first server determines a signature based on the vehicle identification and the integrity information, specifically including:

The first server determines the signature based on anti-replay parameters, the vehicle identification and the integrity information, and the anti-replay parameters are used to identify the current upgrade of the vehicle.
A vehicle verification method, characterized in that the method includes:

The first server determines the integrity information of the upgrade package, and the integrity information is used to identify the upgrade package;

The first server determines a signature based on anti-replay parameters and the integrity information, where the anti-replay parameters are used to identify this upgrade of the vehicle;

The first server sends a file and the upgrade package, where the file includes: the anti-replay parameters, the integrity information and the signature; the upgrade package is used to upgrade the vehicle.
The method of claim 25, wherein the first server determines a signature based on the anti-replay parameter and the integrity information, specifically including:

The first server determines the anti-replay parameter, the vehicle identification of the vehicle and the integrity information. sign.
The method according to any one of claims 23-26, characterized in that the method further includes:

The first server sends a first list indicating the public keys used when the first server allows or prohibits the vehicle from verifying the signature.
The method according to any one of claims 23 to 27, characterized in that the file further includes a public key generated by the first server and used to verify the signature.
The method of claim 28, wherein the file further includes a signature of the public key, and before the first server sends the file and the upgrade package, the method further includes:

The first server sends the public key to a second server, and the second server is a server that develops and provides upgrade files required for the vehicle upgrade;

The first server receives the signature of the public key, and the signature of the public key is determined by the second server based on the public key.
A vehicle, characterized in that it includes a memory, one or more processors, and one or more programs; when the one or more processors execute the one or more programs, the vehicle implements the following: The method of any one of claims 1 to 22.
An electronic device, characterized in that it includes a memory, one or more processors, and one or more programs; when the one or more processors execute the one or more programs, the electronic device causes the electronic device to Implement the method as claimed in any one of claims 23 to 29.
A communication system, characterized in that the system includes the vehicle as claimed in claim 30 and the electronic device as claimed in claim 31.
A computer-readable storage medium comprising instructions, characterized in that when the instructions are run on an electronic device, the electronic device is caused to execute the method described in any one of claims 1 to 22, or 23 to 29. method.