Firmware starting method and system of controller, vehicle and electronic equipment

Abstract

The invention provides a firmware starting method and system of a controller, a vehicle and electronic equipment, and relates to the technical field of controller starting. Before target firmware of a target controller is started, version information of the target firmware is verified, and after the version information passes verification, the target firmware is started; in the embodiment of the invention, the starting configuration information of the target firmware is continuously verified, and the target firmware is started after the starting configuration information passes the verification, so that the rollback attack of the firmware with the vulnerability of the version information can be effectively solved, the smooth starting of the target firmware is ensured, and the safety and the stability of the vehicle are maintained.

Description

Technical Field

[0001] The present application relates to the technical field of controller startup, and in particular to a controller firmware startup method, system, vehicle and electronic equipment. Background Art

[0002] At present, during the startup process of the vehicle controller, a secure cryptographic algorithm is often used to sign the firmware of the vehicle controller offline, and the firmware signature is forced to be verified when the controller is started to ensure the authenticity and integrity of the firmware.

[0003] However, simply signing and forcibly verifying the firmware of the vehicle controller is not enough to ensure the startup security of the controller. For example, if a high-risk vulnerability is found in a certain version of the vehicle's controller firmware, an attacker can use the vulnerability to attack the controller and thus the entire vehicle. In this scenario, the vehicle's main engine manufacturer will update the firmware version to fix the vulnerability. However, when the vulnerability is discovered, the attacker can use special equipment to solder off the ECU (Electronic Control Unit) of the vehicle controller and read the signed vulnerable firmware version from the ECU. Since the firmware is legally signed by the vehicle's main engine manufacturer, the attacker can flash the vulnerable version to the newly released OTA version of the vehicle ECU, thereby launching a rollback attack, which seriously affects the safety and stability of the vehicle.

[0004] Therefore, a new controller firmware startup method is urgently needed. Summary of the invention

[0005] In view of the above problems, embodiments of the present application provide a controller firmware startup method, system, vehicle and electronic device to overcome the above problems or at least partially solve the above problems.

[0006] In a first aspect of the present application, a controller firmware startup method is provided, the method comprising:

[0007] After the target controller is powered on, respectively calling a first preset code and a second preset code pre-stored in a first storage area of ​​the target controller;

[0008] Execute the first preset code to obtain first version information of the target firmware from the second storage area of ​​the target controller, where the first version information is current version information of the target firmware;

[0009] Execute the second preset code to obtain second version information of the target firmware from the third storage area of ​​the target controller, where the second version information is pre-stored version information of the target firmware;

[0010] Performing a first verification on the first version information based on the second version information;

[0011] When the first version information is the same as the second version information, or when the first version information is updated based on the second version information, performing a second check on the startup configuration information of the target firmware;

[0012] After the second verification passes, the target firmware is started.

[0013] Optionally, performing a first verification on the first version information based on the second version information includes:

[0014] Determine, according to the first version information, a first version number corresponding to the first version information;

[0015] Determine, according to the second version information, a second version number corresponding to the second version information;

[0016] Based on the second version number, a first check is performed on the first version number, wherein the first check is to determine the size relationship between the first version number and the second version number.

[0017] Optionally, the performing a second check on the startup configuration information of the target firmware includes:

[0018] Generate a startup check value according to the startup configuration information;

[0019] Performing a startup check on the target firmware according to the startup check value;

[0020] After the second verification is passed, starting the target firmware includes:

[0021] After the startup verification of the target firmware passes, the target firmware is signature-verified, and after the signature verification passes, the target firmware is started.

[0022] Optionally, the step of verifying the signature of the target firmware includes:

[0023] Obtaining firmware information of the target firmware and signature information corresponding to the firmware information;

[0024] According to the firmware information, calculating a hash value corresponding to the firmware information;

[0025] Decrypting the signature information to obtain an initial hash value corresponding to the signature information;

[0026] The hash value corresponding to the firmware information is compared with the initial hash value corresponding to the signature information to complete the signature verification of the target firmware.

[0027] Optionally, when the first version information is version information updated based on the second version information, the method further includes:

[0028] Acquire a plurality of storage bits of the third storage area, and determine a first target storage bit from the plurality of storage bits;

[0029] The first version number corresponding to the first version information is written into the first target storage bit, and the first target storage bit is blown, so that the second version number corresponding to the second version information stored in the third storage area is updated to the first version number.

[0030] Optionally, acquiring the second version information of the target firmware from the third storage area of ​​the target controller includes:

[0031] Acquire a pre-stored version configuration file of the target firmware from the third storage area;

[0032] The version configuration file of the target firmware is parsed, and the second version information is extracted from the parsed version configuration file.

[0033] Optionally, the version configuration file is stored in the third storage area through the following steps:

[0034] Acquire the version configuration file from the cloud server, where the version configuration file is obtained by preprocessing the version configuration information of the target firmware in the cloud server;

[0035] Acquire a plurality of storage bits of the third storage area, and determine a second target storage bit from the plurality of storage bits;

[0036] The version configuration file is stored in the second target storage location.

[0037] In a second aspect of the present application, a firmware startup system for a controller is provided, the system comprising:

[0038] A calling module, used for calling, after the target controller is powered on, respectively a first preset code and a second preset code pre-stored in a first storage area of ​​the target controller;

[0039] A first execution module, configured to execute the first preset code, and obtain first version information of a target firmware from a second storage area of ​​the target controller, wherein the first version information is current version information of the target firmware;

[0040] a second execution module, configured to execute the second preset code, and obtain second version information of the target firmware from a third storage area of ​​the target controller, where the second version information is pre-stored version information of the target firmware;

[0041] A first verification module, configured to perform a first verification on the first version information based on the second version information;

[0042] A second verification module, configured to perform a second verification on the startup configuration information of the target firmware when the first version information is the same as the second version information, or when the first version information is updated based on the second version information;

[0043] A startup module is used to start the target firmware after the second verification passes.

[0044] Optionally, the first version information is subjected to a first verification based on the second version information, and the first verification module includes:

[0045] A first determining submodule, configured to determine a first version number corresponding to the first version information according to the first version information;

[0046] A second determining submodule, configured to determine a second version number corresponding to the second version information according to the second version information;

[0047] The first check submodule is used to perform a first check on the first version number based on the second version number, wherein the first check is to determine the size relationship between the first version number and the second version number.

[0048] Optionally, the second verification is performed on the startup configuration information of the target firmware, and the second verification module includes:

[0049] A generating submodule, used to generate a startup check value according to the startup configuration information;

[0050] A startup check submodule, used to perform startup check on the target firmware according to the startup check value;

[0051] After the second verification is passed, the target firmware is started, and the startup module includes:

[0052] The startup submodule is used to verify the signature of the target firmware after the startup verification of the target firmware passes, and start the target firmware after the signature verification passes.

[0053] Optionally, the system further comprises:

[0054] A first acquisition submodule, used to acquire firmware information of the target firmware and signature information corresponding to the firmware information;

[0055] A calculation submodule, used to calculate a hash value corresponding to the firmware information according to the firmware information;

[0056] A decryption submodule, used to decrypt the signature information to obtain an initial hash value corresponding to the signature information;

[0057] The comparison submodule is used to compare the hash value corresponding to the firmware information with the initial hash value corresponding to the signature information to complete the signature verification of the target firmware.

[0058] Optionally, so that the second version number corresponding to the second version information stored in the third storage area is updated to the first version number, the system further includes:

[0059] A second acquisition submodule, used for acquiring a plurality of storage bits in the third storage area, and determining a first target storage bit from the plurality of storage bits;

[0060] The first storage submodule is used to write the first version number into the first target storage bit and fuse the first target storage bit to update the second version number corresponding to the second version information stored in the third storage area to the first version number.

[0061] Optionally, the acquiring the second version information of the target firmware from the third storage area of ​​the target controller, the second execution module includes:

[0062] A third acquisition submodule, configured to acquire a pre-stored version configuration file of the target firmware from the third storage area;

[0063] The extraction submodule is used to parse the version configuration file of the target firmware and extract the second version information from the parsed version configuration file.

[0064] Optionally, the system further comprises:

[0065] A fourth acquisition submodule, configured to acquire the version configuration file from the cloud server, wherein the version configuration file is obtained by preprocessing the version configuration information of the target firmware in the cloud server;

[0066] a fifth acquisition submodule, configured to acquire a plurality of storage bits of the third storage area, and determine a second target storage bit from the plurality of storage bits;

[0067] The second storage submodule is used to store the version configuration file in the second target storage location.

[0068] In a third aspect of the present application, a vehicle is provided, comprising a firmware startup system of a controller as described in the second aspect of the present application, and / or a firmware startup method for executing a controller as described in the first aspect of the present application.

[0069] In a fourth aspect of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the firmware startup method of the controller as described in the first aspect of the present application.

[0070] Beneficial effects of this application:

[0071] The present application provides a controller firmware startup method, the method comprising: after the target controller is powered on, respectively calling a first preset code and a second preset code pre-stored in a first storage area of ​​the target controller; executing the first preset code, obtaining the first version information of the target firmware from the second storage area of ​​the target controller, the first version information being the current version information of the target firmware; executing the second preset code, obtaining the second version information of the target firmware from the third storage area of ​​the target controller, the second version information being the pre-stored version information of the target firmware; judging whether the first version number corresponding to the first version information is greater than or equal to the second version number corresponding to the second version information; in the case where the first version number is greater than or equal to the second version number, verifying the startup configuration information of the target firmware, and after the verification passes, starting the target firmware. The present application verifies the version information of the target firmware before starting the target firmware of the target controller, and after the version information verification passes, continues to verify the startup configuration information of the target firmware, and after the startup configuration information verification passes, starts the target firmware, which can effectively solve the rollback attack on the firmware with a vulnerability in the version information, ensure the smooth startup of the target firmware, and thus maintain the safety and stability of the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments of the present application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0073] Figure 1 It is a schematic diagram of the steps of a controller firmware startup method provided in an embodiment of the present application;

[0074] Figure 2 It is a schematic diagram of a process of storing firmware version configuration information in a cloud server provided by an embodiment of the present application;

[0075] Figure 3 It is a flowchart of a target firmware startup process provided by an embodiment of the present application;

[0076] Figure 4is a schematic diagram of a firmware startup system of a controller provided in an embodiment of the present application;

[0077] Figure 5 It is a schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0078] The exemplary embodiments of the present application will be described in more detail below in conjunction with the accompanying drawings in the embodiments of the present application. Although the exemplary embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present application and to enable the scope of the present application to be fully communicated to those skilled in the art.

[0079] The vehicle-mounted ECU usually includes an embedded controller SoC (System on Chip), a general controller MCU (Microcontroller Unit), etc. Usually, the root of trust is solidified in a one-time programmable secure storage area such as the Bootroom startup module or the Fuse fuse area, HSM (Hardware Security Module, Hardware Security Module). The vehicle OEM uses a secure cryptographic algorithm to sign the core images and firmware such as the Bootloader, Hypervisor, TrustZone security area offline, and forces the firmware to be signed when the ECU is started to ensure the authenticity and integrity of the firmware.

[0080] When signing, the specific ID of the car manufacturer is usually attached, such as the SoC ID, OEMID, and Product ID. However, the ECU firmware is not enough to fully guarantee the security of the ECU simply by signing and mandatory signature verification. For example, when a certain version of the vehicle firmware has a high-risk vulnerability, an attacker can exploit the vulnerability to attack the ECU or even the entire vehicle.

[0081] In this case, the vehicle OEM usually releases updated version information via OTA (Over-the-Air) to fix the vulnerability. However, after the vulnerability is discovered, the attacker can use special equipment to solder the ECU off and read the signed, vulnerable firmware version information from the ECU. Since the firmware version information is legally signed by the vehicle OEM, the attacker can flash the vulnerable signature to the vehicle ECU that has been updated with the OTA version, thereby launching a rollback attack.

[0082] Based on the above problems, in a first aspect of the embodiments of the present application, a controller firmware startup method is provided, which is applied to an ECU of a vehicle-mounted controller. The method is as follows: Figure 1 As shown, including:

[0083] Step S101, after the target controller is powered on, respectively calling a first preset code and a second preset code pre-stored in a first storage area of ​​the target controller;

[0084] In this step, after the target controller is powered on, some preset codes need to be executed first. These codes are stored in the first storage area of ​​the controller. In practical applications, the first storage area usually refers to the preset storage area of ​​the solid-state memory, which is used to save the basic code at startup. In this application, the startup module in the ECU of the target controller obtains the first preset code and the second preset code from the first storage area, wherein the first preset code is used to read the current version information of the target firmware of the target controller; the second preset code is used to read the pre-stored version information of the target firmware; in practical applications, the startup module of the ECU can be a BootRoom module. In practical applications, the BootRoom module is a key security module for managing the startup process in an embedded system, and is usually used in an ECU or other microcontroller. It is located in the earliest stage of the startup process, responsible for initializing the hardware and performing key security checks to ensure the safety and integrity of the system.

[0085] Step S102, executing the first preset code to obtain first version information of the target firmware from the second storage area of ​​the target controller, where the first version information is the current version information of the target firmware;

[0086] In this step, by executing the first preset code, the startup module of the ECU, such as the BootRoom module, reads the first version information of the target firmware from the second storage area of ​​the target controller, wherein the first version information is the current version information of the target firmware.

[0087] Step S103, executing the second preset code to obtain second version information of the target firmware from the third storage area of ​​the target controller, where the second version information is pre-stored version information of the target firmware;

[0088] In this step, by executing the second preset code, the second version information is read from the second storage area of ​​the target controller, wherein the second version information is the pre-stored version information of the target firmware.

[0089] In the present application, before the target firmware is started, by respectively obtaining the current first version information and the pre-stored second version information of the target firmware, and based on the comparison between the first version information and the second version information, it is possible to determine whether the current first version information is a valid or secure version information.

[0090] In a preferred embodiment, the step of obtaining the second version information of the target firmware from the third storage area of ​​the target controller includes:

[0091] Acquire a pre-stored version configuration file of the target firmware from the third storage area;

[0092] The version configuration file of the target firmware is parsed, and the second version information is extracted from the parsed version configuration file.

[0093] Specifically, in this embodiment, a version configuration file of the target firmware is stored in the third storage area of ​​the target controller. In actual applications, the version configuration file usually contains a dedicated data structure of the version information of the target firmware, which may include the version number, release date, verification information, etc. of the target firmware.

[0094] This embodiment obtains a pre-stored version configuration file of the target firmware from the third storage area through the startup module of the ECU, and parses the obtained version configuration file of the target firmware. After the parsing of the version configuration file is completed, the second version information, that is, the pre-stored version number of the target firmware, is extracted from the parsing result.

[0095] In a preferred embodiment, the version configuration file is stored in the third storage area through the following steps:

[0096] Acquire the version configuration file from the cloud server, where the version configuration file is obtained by preprocessing the version configuration information of the target firmware in the cloud server;

[0097] Acquire a plurality of storage bits of the third storage area, and determine a second target storage bit from the plurality of storage bits;

[0098] The version configuration file is stored in the second target storage location.

[0099] Specifically, the cloud server pre-stores version configuration information of multiple firmware. In this embodiment, it is necessary to pre-acquire the version configuration information of the target firmware from the version configuration information of multiple firmware stored in the cloud server, and store the acquired version configuration information of the target firmware in the second target storage position of the third storage area.

[0100] In this embodiment, the third storage area is an area in the target controller specifically used to store firmware version configuration information. This area is usually reserved by chip manufacturers in the Fuse or HSM area when designing the ECU for use by automobile OEMs.

[0101] In a preferred embodiment, there is provided a Figure 2 The schematic diagram of the process of storing firmware version configuration information in the cloud server shown in FIG. Figure 2 The process shown is set before the target controller is started. Through the process of storing firmware version configuration information on the cloud server described below, the version information of the target firmware can be stored in advance in a preset storage area of ​​the cloud server, so that during the startup process, the ECU can obtain the pre-configured version information from the cloud server. In addition, combining the configuration of the version information with the configuration of the signature information can not only save setup costs, but also greatly reduce the time for file generation.

[0102] Specifically, first, you need to prepare signature configuration information and firmware version configuration information. The signature configuration information includes certificate configuration, key configuration, and algorithm configuration. The signature configuration information is processed by the signature tool. In actual applications, the signature tool integrates multiple encryption and signature tools, including encryption tools, MBN tools, OpenSSL tools, SSD tools, and Image Signer tools. These tools are responsible for processing file signatures and encryption operations in different formats.

[0103] In terms of version configuration information processing, the version configuration information of the target firmware is first obtained. The version configuration information usually contains the firmware version number, update information, and other information related to signing and encryption. After obtaining the version configuration information, the version configuration information is preprocessed by a preprocessing tool, such as compression, encryption, or verification, to ensure the integrity and security of the version information.

[0104] Furthermore, the signature information and version configuration information are embedded into their respective files. The version configuration information is bound to the code file to generate the version configuration file, and the signature information is also bound to the corresponding code file to generate the signature file, such as Atsec certificate, CA certificate and root certificate. Each certificate level provides additional authentication and security to ensure the integrity of the file, the authenticity of the source and the legitimacy of the version.

[0105] Finally, the version configuration file containing the version configuration information and the signature file containing the signature information are stored in a specific storage area of ​​the cloud server;

[0106] When the target controller is started, the version configuration files and signature files of the target firmware are obtained through the ECU and stored in a preset area of ​​the target controller, such as the third storage area (Fuse area) of the target controller.

[0107] Step S104, performing a first verification on the first version information based on the second version information;

[0108] In this step, after the first version information and the second version information are obtained, the second version information is used as a verification benchmark to verify the first version information through the second version information.

[0109] In a preferred embodiment, the first verification of the first version information based on the second version information includes:

[0110] Determine, according to the first version information, a first version number corresponding to the first version information;

[0111] Determine, according to the second version information, a second version number corresponding to the second version information;

[0112] Based on the second version number, a first check is performed on the first version number, wherein the first check is to determine the size relationship between the first version number and the second version number.

[0113] Specifically, in this embodiment, after obtaining the first version information and the second version information, the first version information and the second version information need to be parsed respectively to obtain a first version number corresponding to the first version information and a second version number corresponding to the second version information.

[0114] Furthermore, the first version number is verified based on the second version number. The verification logic is to compare the size relationship between the two. The specific operations include:

[0115] If the first version number is greater than or equal to the second version number, it means that the current version information of the target firmware is valid or safe version information, and the next step of the boot process can be continued.

[0116] If the first version number is smaller than the second version number, it means that the current version of the target firmware is not a valid or safe version, that is, it may be a version that has been attacked by a rollback attack and does not meet the startup requirements. At this time, the ECU will prevent startup and may prompt the user to update the firmware or take other measures.

[0117] Step S105: When the first version information is the same as the second version information, or when the first version information is updated based on the second version information, a second check is performed on the startup configuration information of the target firmware.

[0118] According to the verification result of step S104, if the first version information is the same as the second version information, that is, the first version number is the same as the second version number, or the first version information is the updated version information based on the second version information, that is, the first version number is greater than the second version number, and the first version number is the updated version number based on the second version number, then the next step of the startup process is entered: a second verification of the startup configuration information of the target firmware is performed.

[0119] If the first version information is not the updated version information based on the second version information, or in other words, the first version number corresponding to the first version information is smaller than the version number corresponding to the second version information, it means that the current firmware may be about to be attacked by a rollback, and therefore, the startup condition is not met, and the target firmware is prohibited from starting.

[0120] In the present application, the version information verification step is set before the verification of the startup configuration information, so that the validity and security of the version information can be discovered in time, and after the version information of the target firmware is found to have a problem, the startup of the target firmware is terminated in time to avoid the impact on the target controller or vehicle corresponding to the target firmware after the version information of the target firmware is attacked.

[0121] Step S106: after the second verification passes, start the target firmware.

[0122] In this step, after the second verification of the startup configuration information of the target firmware passes, the target firmware can be started.

[0123] The present application verifies the version information of the target firmware before the target firmware of the target controller is started, and after the version information verification passes, continues to verify the startup configuration information of the target firmware, and after the startup configuration information verification passes, starts the target firmware. This can effectively resolve the rollback attack on the firmware with version information vulnerabilities, ensure the smooth startup of the target firmware, and thus maintain the safety and stability of the vehicle.

[0124] In a preferred embodiment, the second verification of the startup configuration information of the target firmware includes:

[0125] Generate a startup check value according to the startup configuration information;

[0126] Performing a startup check on the target firmware according to the startup check value;

[0127] After the second verification is passed, starting the target firmware includes:

[0128] After the startup verification of the target firmware passes, the target firmware is signature-verified, and after the signature verification passes, the target firmware is started.

[0129] The startup configuration information contains key parameters and configurations related to firmware startup, such as memory allocation, system initialization parameters, security mode configuration, etc. This information directly affects the startup process of the firmware. In this embodiment, the startup configuration information is usually stored in the Fuse area of ​​the target controller, and the startup check value is generated by calculating the startup configuration information, in order to ensure that these configurations are not tampered with or damaged during the startup process. In practical applications, the check value can be generated by calculating the hash value of the startup configuration information or other algorithms. It should be noted that the Fuse area is an irreversible storage area, which is designed as a one-time writable storage space, and is usually used to store some critical, unchangeable configuration or security information. After writing, the storage bit will be "fused", making its content unchangeable.

[0130] Furthermore, after the startup check value is generated, the target firmware is checked for startup using the startup check value. The specific steps are as follows: During the startup process, the current startup configuration information check value is regenerated and compared with the previously generated check value. If the two are consistent, it means that the startup configuration information has not been modified, and the subsequent verification steps can be continued; if they are inconsistent, the startup process stops, indicating that the configuration information may have been tampered with or damaged.

[0131] In this embodiment, by verifying the startup check value, startup failures caused by incorrect configuration or malicious tampering can be effectively prevented.

[0132] In a preferred embodiment, the step of verifying the signature of the target firmware includes:

[0133] Obtaining firmware information of the target firmware and signature information corresponding to the firmware information;

[0134] According to the firmware information, calculating a hash value corresponding to the firmware information;

[0135] Decrypting the signature information to obtain an initial hash value corresponding to the signature information;

[0136] The hash value corresponding to the firmware information is compared with the initial hash value corresponding to the signature information to complete the signature verification of the target firmware.

[0137] Specifically, in this embodiment, during the process of starting the target firmware, after the version information and startup configuration information of the target firmware are verified, the signature information of the target firmware also needs to be verified, wherein the signature information is previously generated by a signature tool and is securely stored for subsequent verification of the integrity of the firmware.

[0138] In this embodiment, it is first necessary to obtain the firmware information of the target firmware and the signature information corresponding to the firmware information, and then calculate the hash value corresponding to the firmware information based on the obtained firmware information of the target firmware. In practical applications, the hash value is a numerical summary of a fixed length, and the hash value is extracted from the firmware information through a hash algorithm. This is a one-to-one mapping, that is, any minor firmware modification will cause the hash value to change, so the hash value can reflect whether the firmware content has been tampered with.

[0139] Furthermore, the acquired signature information is decrypted. The signature information is usually generated by private key encryption, and the corresponding public key is required for decryption. By decrypting, the initial hash value generated when the initial signature is signed can be obtained, which represents the hash value of the firmware when it is signed, and serves as the unique identifier of the firmware information.

[0140] Finally, the hash value of the currently calculated firmware information is compared with the initial hash value obtained by decryption. If the hash value of the currently calculated firmware information is equal to the initial hash value obtained by decryption, it means that the firmware has not been tampered with since it was signed, the signature verification passes, and the boot process of the target firmware continues; if the two are inconsistent, it means that the firmware may have been modified, the signature verification fails, and the boot of the target firmware is prohibited or other security measures are taken.

[0141] This embodiment ensures the integrity and security of the target firmware by comparing the hash calculation of the firmware information and the decryption of the signature information. The comparison of the hash value can accurately detect whether the firmware has been tampered with after signing, while the decryption process ensures the legitimacy of the signature and the credibility of the firmware source. This signature verification mechanism provides reliable protection for the secure boot of the firmware.

[0142] In a preferred embodiment, when the first version information is updated based on the second version information, the method further includes:

[0143] Acquire a plurality of storage bits of the third storage area, and determine a first target storage bit from the plurality of storage bits;

[0144] The first version number corresponding to the first version information is written into the first target storage bit, and the first target storage bit is blown, so that the second version number corresponding to the second version information stored in the third storage area is updated to the first version number.

[0145] Specifically, in this embodiment, when the first version number is greater than the second version number, in addition to the steps described above, the first version number needs to be stored in the third storage area. Specifically:

[0146] First, it is necessary to obtain multiple storage bits in the third storage area, and obtain a suitable storage bit from the multiple storage bits, that is, the first target storage bit. In practical applications, the first target storage bit is used to store the latest firmware version number. When selecting the first target storage bit, the optimal storage bit will be determined based on the current storage space usage, fuse status, and storage security policy to ensure the security of data storage. It should be noted that the first storage bit and the second storage bit mentioned in this application do not have a relative position relationship, and are only used to distinguish different storage bits.

[0147] Further, after the first target storage bit is determined, the first version number is written into the storage bit. After the first version number is successfully written into the first target storage bit, a fuse operation is performed. Fusing refers to an irreversible operation on a storage bit, so that the storage bit cannot be physically modified or erased. This step ensures that once the version number is updated, it will not be tampered with or rolled back, ensuring the security of the firmware version information and the stability of the system. By writing the first version number into the first target storage bit, the second version number corresponding to the second version information stored in the third storage area is updated to the first version number, so that the next time it is started, the version number corresponding to the second version information obtained from the third storage area is the updated version number.

[0148] In a preferred embodiment, there is provided a Figure 3 The target firmware startup flow chart shown in Figure 3 As shown:

[0149] First, after the vehicle is powered on, the target controller is started, that is, the ECU of the target controller is started, and then the ECU runs BootRoom, that is, performs initial safety checks and boot preparations for the target firmware.

[0150] Furthermore, the first preset code and the second preset code stored in the first storage area of ​​the target controller are called by BootRoom to obtain the first version information of the target firmware from the second storage area of ​​the target controller and the second version information of the target firmware from the third storage area of ​​the target controller, wherein the first version information is the current version information of the target firmware and the second version information is the pre-stored version information of the target firmware.

[0151] Furthermore, based on the first version information and the second version information, it is determined whether the target firmware meets the initial startup condition, that is, whether the first version number corresponding to the first version information is greater than or equal to the second version number corresponding to the second version information; if the first version number corresponding to the first version information is greater than or equal to the second version number corresponding to the second version information, the target firmware meets the initial startup condition; if the first version number corresponding to the first version information is less than the second version number corresponding to the second version information, the initial startup condition is not met, and startup of the target firmware is prohibited.

[0152] Furthermore, after the target firmware meets the initial startup conditions, the next step is to verify the startup configuration information of the target firmware to determine whether the verification passes. If the verification passes, the next step is to verify the signature of the target firmware. If the verification fails, the startup of the target firmware is prohibited.

[0153] Furthermore, after the target firmware is verified and signed, the target firmware is started, and the cycle is repeated until all target firmware are successfully started, and then the target controller is successfully started.

[0154] The present application provides a controller firmware startup method, the method comprising: after the target controller is powered on, respectively calling a first preset code and a second preset code pre-stored in a first storage area of ​​the target controller; executing the first preset code, obtaining the first version information of the target firmware from the second storage area of ​​the target controller, the first version information being the current version information of the target firmware; executing the second preset code, obtaining the second version information of the target firmware from the third storage area of ​​the target controller, the second version information being the pre-stored version information of the target firmware; judging whether the first version number corresponding to the first version information is greater than or equal to the second version number corresponding to the second version information; in the case where the first version number is greater than or equal to the second version number, verifying the startup configuration information of the target firmware, and after the verification passes, starting the target firmware. The present application verifies the version information of the target firmware before starting the target firmware of the target controller, and after the version information verification passes, continues to verify the startup configuration information of the target firmware, and after the startup configuration information verification passes, starts the target firmware, which can effectively solve the rollback attack on the firmware with a vulnerability in the version information, ensure the smooth startup of the target firmware, and thus maintain the safety and stability of the vehicle.

[0155] Based on the same inventive concept, the second aspect of the present application provides a firmware startup system for a controller, such as Figure 4 As shown, the system comprises:

[0156] The calling module 201 is used to call the first preset code and the second preset code pre-stored in the first storage area of ​​the target controller respectively after the target controller is powered on;

[0157] A first execution module 202 is used to execute the first preset code to obtain first version information of the target firmware from the second storage area of ​​the target controller, where the first version information is the current version information of the target firmware;

[0158] A second execution module 203, configured to execute the second preset code, and obtain second version information of the target firmware from a third storage area of ​​the target controller, where the second version information is pre-stored version information of the target firmware;

[0159] A first verification module 204, configured to perform a first verification on the first version information based on the second version information;

[0160] A second verification module 205 is used to perform a second verification on the startup configuration information of the target firmware when the first version information is the same as the second version information, or when the first version information is updated based on the second version information;

[0161] The startup module 206 is used to start the target firmware after the second verification passes.

[0162] Optionally, the first version information is first verified based on the second version information, and the first verification module 204 includes:

[0163] A first determining submodule, configured to determine a first version number corresponding to the first version information according to the first version information;

[0164] A second determining submodule, configured to determine a second version number corresponding to the second version information according to the second version information;

[0165] The first check submodule is used to perform a first check on the first version number based on the second version number, wherein the first check is to determine the size relationship between the first version number and the second version number.

[0166] Optionally, the second verification is performed on the startup configuration information of the target firmware, and the second verification module 205 includes:

[0167] A generating submodule, used to generate a startup check value according to the startup configuration information;

[0168] A startup check submodule, used to perform startup check on the target firmware according to the startup check value;

[0169] After the second verification is passed, the target firmware is started, and the starting module 206 includes:

[0170] A startup submodule is used to verify the signature of the target firmware after the startup verification of the target firmware passes, and to start the target firmware after the signature verification passes. Optionally, the system also includes:

[0171] A first acquisition submodule, used to acquire firmware information of the target firmware and signature information corresponding to the firmware information;

[0172] A calculation submodule, used to calculate a hash value corresponding to the firmware information according to the firmware information;

[0173] A decryption submodule, used to decrypt the signature information to obtain an initial hash value corresponding to the signature information;

[0174] The comparison submodule is used to compare the hash value corresponding to the firmware information with the initial hash value corresponding to the signature information to complete the signature verification of the target firmware.

[0175] Optionally, in a case where the first version information is version information updated based on the second version information, the system further includes:

[0176] A second acquisition submodule, used for acquiring a plurality of storage bits in the third storage area, and determining a first target storage bit from the plurality of storage bits;

[0177] The first storage submodule is used to write the first version number corresponding to the first version information into the first target storage bit, and fuse the first target storage bit.

[0178] Optionally, the acquiring the second version information of the target firmware from the third storage area of ​​the target controller, the second execution module 203 includes:

[0179] A third acquisition submodule, configured to acquire a pre-stored version configuration file of the target firmware from the third storage area;

[0180] The extraction submodule is used to parse the version configuration file of the target firmware and extract the second version information from the parsed version configuration file.

[0181] Optionally, the system further comprises:

[0182] A fourth acquisition submodule, configured to acquire the version configuration file from the cloud server, wherein the version configuration file is obtained by preprocessing the version configuration information of the target firmware in the cloud server;

[0183] a fifth acquisition submodule, configured to acquire a plurality of storage bits of the third storage area, and determine a second target storage bit from the plurality of storage bits;

[0184] The second storage submodule is used to store the version configuration file in the second target storage location.

[0185] Based on the same inventive concept, the third aspect of the present application provides a vehicle, which includes a firmware startup system of the controller as described in the second aspect of the present application, and / or a firmware startup method for executing the controller as described in the first aspect of the present application.

[0186] Based on the same inventive concept, in a fourth aspect of the present application, there is provided a Figure 5 The electronic device 100 shown includes a memory 110, a processor 120, and a computer program stored in the memory 110. The processor 120 executes the computer program to implement the firmware startup method of the controller as described in the first aspect of the present application.

[0187] Each embodiment in this specification focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referenced to each other.

[0188] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, devices, or computer program products. Therefore, the embodiments of the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the embodiments of the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0189] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0190] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0191] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0192] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0193] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0194] The above is a detailed introduction to the firmware startup method, system, vehicle and electronic device of a controller provided. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A controller firmware startup method, characterized in that: The method comprises: After the target controller is powered on, respectively calling a first preset code and a second preset code pre-stored in a first storage area of ​​the target controller; Execute the first preset code to obtain first version information of the target firmware from the second storage area of ​​the target controller, where the first version information is current version information of the target firmware; Execute the second preset code to obtain second version information of the target firmware from the third storage area of ​​the target controller, where the second version information is pre-stored version information of the target firmware; Performing a first verification on the first version information based on the second version information; When the first version information is the same as the second version information, or when the first version information is updated based on the second version information, performing a second check on the startup configuration information of the target firmware; After the second verification passes, the target firmware is started.

2. A controller firmware startup method according to claim 1, characterized in that: The performing a first verification on the first version information based on the second version information includes: Determine, according to the first version information, a first version number corresponding to the first version information; Determine, according to the second version information, a second version number corresponding to the second version information; Based on the second version number, a first check is performed on the first version number, wherein the first check is to determine the size relationship between the first version number and the second version number.

3. The controller firmware startup method according to claim 1, characterized in that: The second checking of the startup configuration information of the target firmware includes: Generate a startup check value according to the startup configuration information; Performing a startup check on the target firmware according to the startup check value; After the second verification is passed, starting the target firmware includes: After the startup verification of the target firmware passes, the signature of the target firmware is verified, and after the signature verification passes, the target firmware is started.

4. The method for starting the firmware of a controller according to claim 3, characterized in that: The step of verifying the signature of the target firmware includes: Obtaining firmware information of the target firmware and signature information corresponding to the firmware information; According to the firmware information, calculating a hash value corresponding to the firmware information; Decrypting the signature information to obtain an initial hash value corresponding to the signature information; The hash value corresponding to the firmware information is compared with the initial hash value corresponding to the signature information to complete the signature verification of the target firmware.

5. The method for starting the firmware of a controller according to claim 1, characterized in that: In a case where the first version information is version information updated based on the second version information, the method further includes: Acquire a plurality of storage bits of the third storage area, and determine a first target storage bit from the plurality of storage bits; The first version number corresponding to the first version information is written into the first target storage bit, and the first target storage bit is blown, so that the second version number corresponding to the second version information stored in the third storage area is updated to the first version number.

6. The method for starting the firmware of a controller according to claim 1, characterized in that: The acquiring the second version information of the target firmware from the third storage area of ​​the target controller includes: Acquire a pre-stored version configuration file of the target firmware from the third storage area; The version configuration file of the target firmware is parsed, and the second version information is extracted from the parsed version configuration file.

7. A controller firmware startup method according to claim 6, characterized in that: The version configuration file is stored in the third storage area through the following steps: Acquire the version configuration file from the cloud server, where the version configuration file is obtained by preprocessing the version configuration information of the target firmware in the cloud server; Acquire a plurality of storage bits of the third storage area, and determine a second target storage bit from the plurality of storage bits; The version configuration file is stored in the second target storage location.

8. A firmware startup system for a controller, characterized in that: The system comprises: A calling module, used for calling, after the target controller is powered on, respectively a first preset code and a second preset code pre-stored in a first storage area of ​​the target controller; A first execution module, configured to execute the first preset code, and obtain first version information of a target firmware from a second storage area of ​​the target controller, where the first version information is current version information of the target firmware; a second execution module, configured to execute the second preset code, and obtain second version information of the target firmware from a third storage area of ​​the target controller, where the second version information is pre-stored version information of the target firmware; A first verification module, configured to perform a first verification on the first version information based on the second version information; A second verification module, configured to perform a second verification on the startup configuration information of the target firmware when the first version information is the same as the second version information, or when the first version information is updated based on the second version information; A startup module is used to start the target firmware after the second verification passes.

9. A vehicle, characterized in that: The vehicle comprises a firmware startup system of a controller as claimed in claim 8, and / or a firmware startup method of a controller for executing any one of claims 1-7.

10. An electronic device comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the firmware startup method of the controller according to any one of claims 1 to 7.

Images