Vehicle controller starting method and device and vehicle controller

Abstract

The invention relates to the technical field of vehicle safety, in particular to a starting method and device of a vehicle controller and the vehicle controller, and the method comprises the steps that a starting instruction for starting the vehicle controller is received; judging whether an application program in the vehicle controller needs to be upgraded or not; if the application program does not need to be upgraded, performing signature verification on a starting program of the application program, and running the application program after the signature verification of the starting program is passed; and if the application program needs to be upgraded, performing signature verification on a second flash memory boot loader of the application program, and after the verification of the second flash memory boot loader is passed, running the second flash memory boot loader to upgrade the application program. Therefore, the technical problems that in the related technology, safe starting is achieved based on a built-in encryption engine or an external encryption chip, so that cost is high, safe starting consumes too long time, the actual requirement of safe starting cannot be met, and user experience is reduced are solved.

Description

Technical Field

[0001] The present application relates to the field of vehicle safety technology, and in particular to a method and device for starting a vehicle controller, and a vehicle controller. Background Art

[0002] In related technologies, in order to enable the vehicle controller to achieve secure startup, the chip's own hardware encryption engine (such as HSE (Hardware Security Engine) / HSM (Hardware Security Modules)) is mainly used or an external encryption chip is added. After the vehicle controller receives the startup command, the encryption engine or encryption chip is used to accelerate the encryption operation, unload computationally intensive encryption tasks from the main processor, and improve encryption efficiency; or provide key management to protect sensitive information, promote secure communications, and ensure the integrity of key operations in networked vehicles.

[0003] However, in the related technology, whether using the chip's own hardware encryption engine or adding an external encryption chip, the use cost of the vehicle controller will increase. And through the above-mentioned safe startup method, although the purpose of safe startup is achieved, the startup takes too long, that is, the response time is too long, resulting in a startup delay. Then the user will feel a sense of lag, which seriously affects the user experience and cannot meet the startup requirements of the vehicle controller, which urgently needs to be improved. Summary of the Invention

[0004] The present application provides a vehicle controller startup method, device and vehicle controller to solve technical problems in related technologies such as achieving secure startup based on a built-in encryption engine or an external encryption chip, resulting in high costs and long secure startup time, failing to meet the actual needs of secure startup, and reducing user experience.

[0005] A first aspect of the present application provides a method for starting a vehicle controller, the method comprising: receiving a startup instruction for starting a vehicle controller; controlling the startup of the vehicle controller in response to the startup instruction; during the startup process of the vehicle controller, determining whether an application in the vehicle controller needs to be upgraded; if the application does not need to be upgraded, verifying the startup program of the application through a first flash memory boot loader, and running the application after the startup program is verified; if the application needs to be upgraded, verifying the second flash memory loader boot program of the vehicle controller through the first flash memory boot loader, and running the second flash memory loader boot program to download an upgrade package for the application after the second flash memory loader boot program is verified, and upgrading the application through the upgrade package.

[0006] Optionally, in one embodiment of the present application, determining whether the application in the vehicle controller needs to be upgraded includes: starting the security firmware in the security area of ​​the vehicle controller; running the startup management program through the security firmware to use the startup management program to determine whether the application needs to be upgraded.

[0007] Optionally, in one embodiment of the present application, the security area is a one-time programmable (OTP) area or an Efuse area.

[0008] Optionally, in one embodiment of the present application, the signature verification of the second flash boot loader of the vehicle controller includes: obtaining identification information of the second flash boot loader, wherein the identification information is the current MAC value of the second flash boot loader; judging whether the second flash boot loader meets a preset verification condition based on the identification information; if the identification information meets the preset verification condition, determining that the second flash boot loader has passed the verification.

[0009] Optionally, in one embodiment of the present application, before verifying the signature of the second flash boot loader of the vehicle controller, it also includes: generating a key for the vehicle controller using a preset encryption algorithm to calculate the current MAC value using the key; and storing the key in a secure area of ​​the vehicle controller.

[0010] Optionally, in one embodiment of the present application, before verifying the signature of the startup program of the application, it also includes: extracting the image file signature of the application; parsing the image file signature to obtain the information summary of the application; and obtaining the visa of the application based on the information summary.

[0011] Optionally, in one embodiment of the present application, determining whether the application in the vehicle controller needs to be upgraded includes: detecting whether the vehicle controller has an upgrade task; and determining that the application needs to be upgraded if it is detected that the vehicle controller has the upgrade task.

[0012] A second aspect of the present application provides a starting device for a vehicle controller, including a module having the functions of the above-mentioned starting method for a vehicle controller.

[0013] A third embodiment of the present application provides a vehicle controller, which includes the starting device of the vehicle controller described in the above embodiment.

[0014] The fourth aspect of the present application provides a vehicle, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method for starting the vehicle controller as described in the above embodiment.

[0015] The fifth aspect of the present application provides a computer-readable storage medium, which stores a computer program. When the program is executed by a processor, it implements the above-mentioned method for starting the vehicle controller.

[0016] The sixth aspect of the present application provides a computer program, which, when executed, is used to implement the above-mentioned method for starting the vehicle controller.

[0017] Therefore, this application has at least the following beneficial effects:

[0018] The embodiment of the present application can verify the signature of the application when no upgrade is required, so that the application can be run after the signature verification is passed. Otherwise, the signature of the second flash boot loader is verified, so that the second flash boot loader is run after the signature verification is passed, and the application is upgraded. Finally, the upgraded application that has passed the verification is run. While ensuring security, the startup time is effectively shortened, and the safe startup is prevented from taking too long. There is no need for a hardware encryption engine or an external encryption chip, and no additional cost is required. The user experience is effectively improved, the startup requirements of the vehicle controller are met, and the safety and practicality of the vehicle are improved. Therefore, the technical problems in the related art of implementing safe startup based on a built-in encryption engine or an external encryption chip are solved, which result in high costs and long safe startup time, cannot meet the actual requirements of safe startup, and reduce user experience.

[0019] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A flowchart of a method for starting a vehicle controller according to an embodiment of the present application;

[0021] Figure 2 A schematic diagram of the principle of a method for starting a vehicle controller in the related art;

[0022] Figure 3 A schematic diagram of a method for starting a vehicle controller according to an embodiment of the present application;

[0023] Figure 4 This is a flowchart of a method for starting a vehicle controller according to an embodiment of the present application;

[0024] Figure 5A schematic diagram of the principle of a method for starting a vehicle controller in the related art;

[0025] Figure 6 A schematic diagram of the principle of a method for starting an optimized vehicle controller according to one embodiment of the present application;

[0026] Figure 7 A flowchart of an application verification method for starting a vehicle controller according to an embodiment of the present application;

[0027] Figure 8 A flowchart of a second flash boot loader verification method of a vehicle controller according to an embodiment of the present application;

[0028] Figure 9 A flowchart of an application program upgrade for a method of starting a vehicle controller according to an embodiment of the present application;

[0029] Figure 10 This is a schematic diagram of the signature verification principle in a normal startup scenario according to an embodiment of the present application.

[0030] Figure 11 A schematic diagram of the upgrade principle of related technologies in OTA scenarios;

[0031] Figure 12 This is a schematic diagram of the upgrade principle in an OTA scenario according to an embodiment of the present application;

[0032] Figure 13 A schematic structural diagram of a vehicle provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0033] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0034] The following describes the vehicle controller startup method, device, and vehicle controller of the embodiments of the present application with reference to the accompanying drawings. It should be noted that the vehicle controller startup method in the following embodiments is applied to assisted driving fields such as vehicle safety, and the execution subject is the vehicle controller. The vehicle controller startup method in the following embodiments can effectively shorten the startup time while ensuring safety, avoid the safe startup taking too long, and does not require a hardware encryption engine and an external encryption chip, without any additional cost, effectively improving the user experience, meeting the startup requirements of the vehicle controller, and improving the safety and practicality of the vehicle.

[0035] like Figure 11 is a flow chart of a method for starting a vehicle controller according to an embodiment of the present application.

[0036] like Figure 1 As shown, the vehicle controller startup method includes the following steps:

[0037] In step S101 , a start instruction for starting a vehicle controller is received.

[0038] Optionally, the vehicle controller can be but is not limited to being used to control the vehicle's electrical system. For example, the body controller is a related ECU (Electronic Control Unit) that controls the body's electrical system. It can be used to control electric windows, electric rearview mirrors, air conditioning, headlights, turn signals, anti-theft locking system, central locking, defrost device, etc. It can be connected to other vehicle-mounted ECUs through a bus.

[0039] The above-mentioned ECU can be composed of a microcomputer, input, output and control circuits, and calculates, processes and judges the information input by the air flow meter and various sensors according to the programs and data in its memory, and then outputs instructions, such as providing an electric pulse signal of a certain width to the injector to control the amount of fuel injection.

[0040] As the degree of automobile electrification continues to increase, many functions require the use of vehicle controllers, such as active braking, adaptive cruise control, remote start, etc. Therefore, in addition to real-time applications based on relevant applications, the embodiments of the present application can optimize functions and fix vulnerabilities by upgrading the applications of relevant functions, thereby allowing users to obtain not only the best user experience but also the best safety experience when using the relevant functions of the vehicle.

[0041] It should be noted that once the vehicle controller is attacked, such as malicious tampering, it will have a huge impact on the safety of the vehicle, such as sudden braking at high speed, vehicle brake failure, steering wheel failure and other safety accidents, or when there is a security vulnerability in the vehicle controller, illegal personnel can use it to remotely control the vehicle, such as unlocking, honking, flashing lights, opening the sunroof and other actions that are not user-friendly, causing the user to lose control of the vehicle controller, seriously threatening the safety of vehicle use.

[0042] During the actual implementation process, the embodiment of the present application can receive a start-up instruction for starting the vehicle controller after the vehicle is powered on, wherein the start-up instruction can be, but is not limited to, triggered by a user through various methods such as operating the vehicle's hard buttons, touch screen buttons, voice commands, or remote control through a mobile terminal; it can also be a start-up instruction automatically generated under the corresponding working conditions in advance, such as a welcome mode based on the positioning information of the vehicle key, so that the vehicle can be self-started in the power-off state, that is, the vehicle automatically generates a start-up instruction for starting the vehicle controller after it automatically changes to the power-on state, etc., and is not limited to user triggering.

[0043] In step S102 , in response to the start instruction, the vehicle controller is controlled to start.

[0044] After the vehicle receives the startup command from the vehicle controller, the embodiment of the present application can control the startup of the vehicle controller, such as the battery manager or the body controller, based on the actual command content, so as to safely start the corresponding controller. For example, when the control command is to open the window, the vehicle controller controls the corresponding body controller to start.

[0045] In the embodiments of the present application, the vehicle controller can be set by those skilled in the art according to actual conditions, without specific restrictions, so as to improve the safety, reliability and practicality of the vehicle and effectively meet the user's usage needs.

[0046] In step S103 , during the startup of the vehicle controller, it is determined whether the application in the vehicle controller needs to be upgraded.

[0047] Understandably, applications are typically developed by vehicle manufacturers or related suppliers to enhance vehicle performance, safety, and driving comfort.

[0048] Application upgrades can be achieved through OTA (Over the Air) technology, which uses the air interface of mobile communications to remotely manage the data of terminal devices and apply it to vehicle data or application updates.

[0049] OTA is a technology for remotely updating, configuring, and managing devices over wireless networks. It allows for improvements and maintenance of device functionality and performance through network transmission and application updates after device deployment, without requiring physical access to the device or user intervention. However, when utilizing OTA technology for application updates, the security of information transmission must be considered to ensure the integrity and confidentiality of data and updates transmitted via OTA, and to ensure that the OTA process is not interrupted by network outages or instability. Furthermore, user privacy and data protection must be taken into consideration.

[0050] As a possible implementation method, the embodiment of the present application can determine the corresponding application according to the startup instruction. After clarifying the application to be started, the embodiment of the present application can use, for example, the startup management program to determine whether the application is upgraded, and then determine the corresponding signature verification part based on whether the application is upgraded or not. There is no need to perform a comprehensive signature verification on each application, ensuring security while improving startup efficiency. For example, when the application does not need to be upgraded, the embodiment of the present application can confirm whether the startup of the application to be started is safe; when the application needs to be upgraded, the embodiment of the present application needs to verify the upgrade of the application, and after the verification is passed, confirm whether the startup of the upgraded application is safe. For example, in the signature verification method, the embodiment of the present application can use a fixed block length calculation mode for information authentication or encryption authentication, which will be described in detail below.

[0051] Optionally, in one embodiment of the present application, determining whether an application in a vehicle controller needs to be upgraded includes: starting security firmware within a security area of ​​the vehicle controller; running a startup management program through the security firmware to utilize the startup management program to determine whether the application needs to be upgraded.

[0052] Specifically, the secure firmware is a program embedded in the hardware for secure booting using an encryption algorithm. In the embodiments of the present application, the secure firmware is stored in a secure area to prevent it from being rewritten externally, thereby improving the privacy and security of the secure firmware.

[0053] In addition, the startup management program may be a boot manager, which is responsible for managing the loading and startup process of the operating system when the computer or embedded system is started. The startup management program may also be called a BootManager.

[0054] In the embodiments of the present application, secure firmware can be used to run a boot manager. After ensuring that the boot manager is securely booted, the boot manager determines the next project to be launched. Specifically, the boot manager uses secure firmware stored in a secure area to run the boot manager, thereby determining the project to be launched next or the project to be verified next, and performing categorized verification. This effectively resolves the root of trust issue while shortening the boot time, effectively ensuring the boot security of the vehicle controller, and further ensuring the safety and practicality of the vehicle. The project to be launched can be an application upgrade or an application startup.

[0055] For example, an embodiment of the present application can use the startup management program to read the upgrade flag of the application, such as 1 for upgrade and 0 for non-upgrade. When the startup management program reads the upgrade flag as 1, it is determined that the application needs to be upgraded, and when the upgrade flag is 0, it is determined that the affected program does not need to be upgraded.

[0056] Optionally, in one embodiment of the present application, the security area is a one-time programmable (OTP) area or an Efuse area.

[0057] Among them, the security area of ​​the vehicle controller can be but is not limited to the OTP (One Time Programmable) register area, which is used to effectively store security firmware. Within the security area, after the program is burned into the microcontroller, it cannot be changed or cleared again, thereby ensuring the security and effectiveness of the security firmware.

[0058] The efuse area is a memory region used to store one-time programmable data in a vehicle. The efuse area typically consists of a series of specialized non-volatile memory cells, each of which can be programmed to either 0 or 1. The efuse area's primary function is to store a device's one-time or read-only data, typically firmware configuration information, serial numbers, keys, or other important parameters. Because the data in the efuse area is programmed once, it cannot be altered during the device's lifetime, increasing data security and reliability.

[0059] Optionally, in one embodiment of the present application, before using the startup management program to determine whether the application needs to be upgraded, it also includes: determining whether the vehicle controller meets the preset safety conditions; if the vehicle controller does not meet the preset safety conditions, controlling the vehicle to perform a first preset exception handling action.

[0060] In some embodiments, when there is a security issue with the vehicle controller, the judgment result on whether the application management program needs to be upgraded will be incorrect. At this time, flashing the erroneous upgrade data to the application or starting an application whose version is not the latest will have a certain impact on the vehicle, making it difficult for the application to start and run normally. Therefore, before making a judgment on the preset upgrade conditions, the embodiment of the present application needs to confirm whether the vehicle controller, such as the security firmware and startup management program in the controller, meets certain security conditions.

[0061] For example, the embodiment of the present application needs to determine whether the area where the security firmware is located, that is, the security area, has been flashed, and after determining that the security firmware has not been flashed, that is, the security firmware is safe, run the startup management program to prevent security problems in the vehicle controller, and after confirming safety, call the startup management program to make an upgrade judgment for the application. An example description will be given below.

[0062] It should be emphasized that the safety of the vehicle controller is particularly important. The embodiment of the present application can first determine whether the vehicle meets certain safety conditions, and only when it is determined that the safety conditions are met, can it determine whether the application meets the upgrade conditions; when it is determined that the vehicle controller does not meet the safety conditions, the embodiment of the present application will prohibit the determination of whether the application meets the upgrade conditions, and at the same time prohibit the startup of the corresponding application, and control the vehicle to execute the first preset exception handling action, where the first preset exception handling action can be but is not limited to restarting the relevant application, ending the current process, and trying again after restarting; or, the exception handling action can be to directly interrupt the current process and prohibit subsequent upgrades or running operations.

[0063] In addition, for example, the first preset exception handling action may also include:

[0064] Report to the vehicle terminal and generate a safety failure prompt, which will be pushed to the vehicle's display screen or dashboard; it can also be pushed to a mobile terminal associated with the vehicle; it can also be pushed to the corresponding car manufacturer's terminal or maintenance terminal, such as the car manufacturer's platform's after-sales service center.

[0065] After reporting to the vehicle terminal, the vehicle controller can also be restricted from operating. When the vehicle is not in driving state, the vehicle controller can be directly disabled; when the vehicle is in driving state, the user can be reminded to stop as soon as possible.

[0066] Optionally, in one embodiment of the present application, determining whether the vehicle controller meets the preset safety conditions includes: detecting whether the safety area is flashed; and determining that the processor does not meet the preset safety conditions when it is detected that the safety area is flashed.

[0067] The following describes in detail the security judgment based on whether the security area is flashed.

[0068] Specifically, the embodiment of the present application may determine whether the vehicle controller meets the preset security conditions, including starting to run the security firmware and determining whether the OTP area or the Efuse area is flashed.

[0069] It is understandable that when the OTP area or Efuse area is flashed, it means that the secure area has been invaded and changed, the internal programming is no longer reliable, and the secure boot scheme of the secure firmware becomes invalid, making the paired public and private keys generated by the key management system no longer confidential and secure.

[0070] In some embodiments, the embodiments of the present application may also evaluate whether the vehicle controller meets the preset safety conditions through the following aspects:

[0071] Evaluate whether the functions of the vehicle controller comply with the settings, simulate the operation of the vehicle controller, and determine whether there are functional defects or errors; determine the safety performance of the vehicle controller by performing security analysis and risk assessment on the vehicle controller; determine whether the communication between the vehicle controller and other systems or devices is secure by evaluating the ECU's communication protocol, encryption algorithm and authentication mechanism; determine whether the hardware design of the vehicle controller has sufficient security performance to prevent physical attacks and hardware vulnerabilities by evaluating the ECU's hardware structure, circuit design and physical protection measures; evaluate and determine whether the software design and implementation of the vehicle controller has sufficient security performance to prevent software vulnerabilities and malicious code through the ECU's software architecture, coding specifications and security testing; determine whether the update and maintenance process of the vehicle controller is secure by evaluating the ECU's update and maintenance process, security verification and control mechanism to prevent unauthorized software and configuration changes.

[0072] Optionally, in one embodiment of the present application, determining whether an application in a vehicle controller needs to be upgraded includes: detecting whether the vehicle controller has an upgrade task; and determining that the application needs to be upgraded if it is detected that the vehicle controller has an upgrade task.

[0073] Furthermore, the application will undergo iterative upgrades to increase the functionality of the application or resolve vulnerabilities in the application. By upgrading the application, on the one hand, the functions of the application can better meet the user's usage needs, and on the other hand, the security of the application can be improved to prevent the application from failing to start or starting incorrectly when the user needs it, thereby affecting the user's normal use.

[0074] There are several ways to determine whether the application in the vehicle controller needs to be upgraded, as follows:

[0075] For example, the embodiment of the present application can detect whether the vehicle controller has an upgrade task, such as when the vehicle automatically downloads an upgrade package through a wireless network while driving, or there is an upgrade package waiting to be updated in the background of the vehicle terminal, or the vehicle terminal receives an upgrade application, etc.

[0076] In addition, the embodiment of the present application can also determine whether the vehicle controller has an upgrade task through self-checking.

[0077] For example, embodiments of the present application can regularly evaluate whether the applications in the vehicle manager have known security vulnerabilities and defects. Relevant information can be obtained by referring to security bulletins, vulnerability databases, and security research reports. It can also be used to determine whether the vehicle had security vulnerabilities or defects when it was last used based on data in the vehicle history records. If known security vulnerabilities and defects are found, it is determined that the vehicle controller needs to be upgraded and an upgrade request is sent to the corresponding vehicle manufacturer terminal.

[0078] The embodiment of the present application can also evaluate whether the application meets business needs and consider whether there are new functions or improvements that can provide better performance or user experience. In other words, it can obtain upgrade packages by communicating with the vehicle manufacturer's terminal or related cloud platform;

[0079] The embodiment of the present application can also evaluate whether the application is compatible with other systems or devices and can interact normally. If a compatibility issue or interoperability barrier is found, it can determine that the vehicle controller needs an upgrade task and send an upgrade request to the corresponding vehicle manufacturer terminal.

[0080] When the vehicle controller has an upgrade task, the embodiment of the present application can determine that the application needs to be upgraded so that the corresponding application can be started after the upgrade to reduce the impact of security vulnerabilities on the vehicle.

[0081] In step S104, if the application does not need to be upgraded, the first flash boot loader is used to verify the signature of the startup program of the application, and the application is run after the startup program is verified.

[0082] It is understood that during signature verification, the signature can be, but is not limited to, the application's signature and certificate. The signature is to ensure the security and integrity of the application. The signature can be used to verify the source of the application and whether the content has been tampered with.

[0083] A digital certificate is issued by a trusted third-party organization, similar to an ID card. It contains the developer's personal or organizational information, as well as information related to the public key.

[0084] When applying for a digital certificate, developers must provide their identity information and public key. The certificate authority verifies the developer and signs the application. The certificate contains the certificate authority's digital signature, and users can verify the authenticity and validity of the signature by verifying the certificate authority's public key.

[0085] In actual implementation, the embodiment of the present application can use the FBL (Flash Bootloader) to perform the signature verification process after the upgrade determination is made. The FBL is a software program in the embedded system that is used to initialize the system and load the main program. It is usually located in the flash memory of the embedded device and is the first program executed during the startup process.

[0086] During the actual execution process, when starting an application, the embodiment of the present application can first verify the security firmware and start the management program through the security firmware verification. After the startup management program verification is successful, the startup management program determines whether the application needs to be upgraded. The embodiment of the present application can determine subsequent actions based on the upgrade judgment result of the application.

[0087] If the application does not need to be upgraded, the embodiment of the present application can directly verify the signature of the application's startup program through the first flash boot loader without performing the upgrade step, so as to run the application after ensuring the security of the application.

[0088] In step S105, if the application needs to be upgraded, the second flash memory boot program of the vehicle controller is verified by the first flash memory boot program, and after the second flash memory boot program is verified, the second flash memory boot program is run to download the upgrade package of the application, and the application is upgraded through the upgrade package.

[0089] If the application needs to be upgraded, the embodiment of the present application can verify the signature of the second flash boot loader of the application, and after passing the signature verification, run the second flash boot loader to upgrade the application, and verify the visa of the upgraded application, and after the visa verification of the upgraded application is passed, run the upgraded application to ensure the security of the upgraded application.

[0090] Optionally, in one embodiment of the present application, before verifying the signature of the second flash memory boot loader of the vehicle manager, it also includes: generating a key of the vehicle controller using a preset encryption algorithm to calculate the current MAC value using the key; storing the key in a secure area of ​​the vehicle controller; and when verifying the signature of the second flash memory boot loader of the vehicle manager, obtaining the identification information of the second flash memory boot loader, wherein the identification information is the current MAC value of the second flash memory boot loader; judging whether the second flash memory boot loader meets the preset verification conditions based on the identification information; if the identification information meets the preset verification conditions, determining that the second flash memory boot loader has passed the verification.

[0091] As a possible implementation method, the embodiment of the present application can generate a key for the vehicle controller before verifying the visa of the second flash boot loader, and store the key in a secure area of ​​the vehicle controller to prevent tampering.

[0092] It is understandable that the signature of the application can use asymmetric encryption technology, that is, the key includes two parts, a private key and a public key. In the embodiment of the present application, the public key and the private key can be stored in the secure area, or the private key can be stored separately to ensure the security of the key.

[0093] First, developers need to generate a key pair consisting of a private key and a public key. The private key is a secret file kept by the developer and cannot be disclosed to others. The public key can be embedded in the application to verify the application's signature.

[0094] After generating a key pair, developers can use the private key to sign their app's files. The signing process involves hashing the app's file contents and then encrypting the hash value with the private key to generate a signature file. The signature file contains the app's digital fingerprint.

[0095] During verification, the embodiment of the present application can extract the signature file and use the public key to verify the signature file. If the digital fingerprint of the signature file is consistent with the content of the application file, it means that the application has not been tampered with and can be installed and used without worry.

[0096] Based on the description of other related embodiments, it can be understood that the signature verification process of the embodiment of the present application can be as follows:

[0097] Step S1: The secure firmware uses symmetric and asymmetric encryption algorithms to boot a secure boot solution, such as software-implemented encryption algorithms, for example, symmetric encryption is SHA256 algorithm, and asymmetric encryption is RSA2048 algorithm.

[0098] In actual use, the embodiments of the present application can utilize symmetric and asymmetric encryption algorithms to guide the secure startup scheme, that is, through hybrid encryption, the shortcomings of using symmetric encryption or asymmetric encryption alone are optimized, and symmetric encryption and asymmetric encryption are combined to achieve an efficient and secure encryption process.

[0099] Step S2: Generate a pair of public and private keys using a key management system according to an encryption algorithm. The encryption algorithm may be as shown in step S1 or may be configured by a person skilled in the art based on actual conditions, and no specific limitation is imposed here.

[0100] A public key and a private key form a pair of keys with an asymmetric relationship. The public key can be made public, while the private key must remain confidential. The security of public key cryptography relies on the confidentiality of the private key. Only those holding the private key can decrypt encrypted messages and generate valid digital signatures, thus ensuring the confidentiality and integrity of communications.

[0101] The embodiment of the present application generates pairs of public keys and private keys according to an encryption algorithm through a key management system, so as to use the public key and private key pairs to verify the application and improve the safe startup performance of the vehicle.

[0102] Step S3: The security firmware and the key can be stored in a secure area of ​​the MCU (Microcontroller Unit), such as an OTP area, to implement the root of trust function.

[0103] Here, the concepts involved in secure boot are explained in detail:

[0104] Verification: A process that checks whether the code to be run is officially released. This verification process requires the use of a cryptographic algorithm. When an official software package is released, this algorithm calculates a specific value for the package and writes it along with the package into the MCU's flash memory. During startup, the package's signature value is calculated in real time and compared with the signature value written to the flash memory. If the two match, the package is considered legitimate; otherwise, it is invalid.

[0105] Root of Trust: The above authentication process also needs to be implemented through code. If an attacker can modify the verification process code, they can still bypass the verification process or tamper with the verification results. Therefore, a code that the attacker cannot modify at all is needed to verify the above authentication code and ensure that the above verification code cannot be modified. This code that the attacker cannot modify at all can be understood as the root of trust. The root of trust is a piece of code that is generally believed to be untamperable. It is usually implemented through hardware, such as the BootROM of a chip. BootROM is a piece of code solidified in the chip. Once the chip is manufactured, the BootROM cannot be changed (such as the OTP area of ​​the chip, which cannot be changed after being flashed once).

[0106] Chain of Trust: The software of a vehicle controller is generally divided into multiple parts, such as the bootloader and app. Starting from the root of trust, a chain of trust is formed by continuously implementing level-by-level verification to ensure the validity of each module's authentication. For example, the BootROM verifies the bootloader, and the bootloader verifies the app.

[0107] Step S4: The secure firmware starts and verifies the boot management program, and after passing the verification, jumps to the boot management program to run, so as to use the boot management program to start the application.

[0108] Step S5: The startup management program determines whether the application needs to be upgraded, that is, whether the preset upgrade conditions are met. Based on the determination of the preset upgrade conditions, the startup time can be shortened.

[0109] Specifically, the startup management program can be used to determine whether the application meets the preset upgrade conditions by verifying the identifier written by the application developer or technician in the application. When the startup management program of the embodiment of the present application reads the corresponding identifier, it can be considered that the application meets the preset upgrade conditions.

[0110] The identification information may be a current MAC value of the second flash memory boot loader calculated using the private key.

[0111] In other embodiments, the identification information of the embodiment of the present application can be a current MAC value of the second flash boot loader calculated using a private key and an algorithm. The current MAC value can be processed by dividing the message or data into blocks of fixed length.

[0112] In cryptographic techniques such as symmetric encryption algorithms, message authentication codes (MACs), and cipher block chaining (CBC), messages are often too long to be encrypted or processed directly, so they need to be split into fixed-size blocks and then the corresponding operations are performed on each block.

[0113] Fixed-length blocks make it easier to process messages because each block is the same length, making calculations and operations easier during processing. Secondly, it can improve performance because multiple blocks can be processed in parallel, speeding up processing.

[0114] The steps for calculating the current MAC value using the symmetric key can be as follows:

[0115] Step S1: Select an appropriate symmetric key to ensure its security and confidentiality. The symmetric key will be used to calculate the MAC value and verify the integrity of the MAC value.

[0116] Step S2: Divide the information in the second flash boot loader into blocks of a fixed size, usually n bits. If the information length is not a multiple of n, a padding method can be used to fill it to a multiple of n.

[0117] Step S3: Initialize the MAC value using an initial vector or a zero vector.

[0118] Step S4: For each block, calculation is performed using the symmetric key and the MAC value of the previous block (or the initialized MAC value).

[0119] Step S5: Calculate the calculation result of each block and the MAC value of the previous block (for example, using an XOR operation), and then update the MAC value.

[0120] Step S6: For the last block, if padding is used, the padding needs to be processed.

[0121] Step S7: Outputting the MAC value: Finally, the calculated MAC value is outputted as the authentication identifier of the second flash boot loader.

[0122] The embodiment of the present application can use the private key to calculate the current MAC value when verifying the second flash boot loader, so as to subsequently perform security verification of the second flash boot loader, use encryption to perform information parsing, effectively ensure the reliability and security of the verification, ensure the integrity of the upgrade, and enhance the user's upgrade experience.

[0123] Furthermore, in the embodiment of the present application, the signature verification of the second flash boot loader may include: comparing the current MAC value with the preset MAC value to obtain a comparison result to determine whether the current MAC value is consistent with the preset MAC value.

[0124] During the actual execution process, the embodiment of the present application can compare the MAC value stored in the OTP area with the current MAC value. If they are consistent, it means that the second flash boot loader matches the application and the second flash boot loader has not been tampered with, and the verification is successful. If they are inconsistent, the verification fails to determine whether the second flash boot loader can meet the verification conditions. Among them, upgrading is reliable and easy to implement when they are consistent.

[0125] Optionally, in one embodiment of the present application, before verifying the signature of the application startup program, it also includes: extracting the image file signature of the application; parsing the image file signature to obtain the information summary of the application; and obtaining the visa of the application based on the information summary.

[0126] Specifically, the embodiment of the present application can extract the signature of the application image file, decrypt the application signature, and obtain the information summary. That is to say, the embodiment of the present application can extract the verification data written in advance in the application by the technician or developer. It is reliable and easy to implement, and improves the startup smoothness of the vehicle controller, effectively improving the user experience, and is simpler and more reliable.

[0127] If the visa acquisition of the application fails, the feedback verification failure is given; if the visa verification of the application passes, proceed to the next step.

[0128] Verify the application image. If the application image verification fails, feedback is given as verification failure; if the application image verification passes, feedback is given as verification success.

[0129] In addition, the embodiment of the present application can generate verification failure information after verification fails, and send the verification failure information to the vehicle's display screen, instrument panel and other display devices, or send it to the user's mobile terminal associated with the vehicle to remind the user that there is a potential danger in the application so that the user can repair it as soon as possible.

[0130] The embodiment of the present application may also attempt a second verification after verification fails to review the verification result.

[0131] The embodiment of the present application can also send verification failure information to the vehicle manufacturer terminal, after-sales terminal or cloud platform after the verification fails, so that relevant technical personnel and customers can perform more targeted upgrades and optimizations based on the feedback of the verification failure information.

[0132] Those skilled in the art should understand that, in the embodiment of the present application, the process of running the second flash boot loader to upgrade the application may include the following steps:

[0133] Step S1: copy the application image from the primary partition to the backup area;

[0134] Step S2: Download the OTA image to the main partition;

[0135] Step S3: Verify the application process. If the verification passes, run the new application logic. If the verification fails, proceed to the next step.

[0136] Step S4: copy the image from the backup area to the primary partition; verify the application process.

[0137] Optionally, in one embodiment of the present application, after verifying the signature of the second flash boot loader, the method further includes: after the verification of the second flash boot loader fails, controlling the vehicle to execute a second preset exception handling action.

[0138] The second preset exception handling action may be restarting the verification or interrupting the verification process.

[0139] In addition, for example, the second preset exception handling action may also include:

[0140] Report to the vehicle terminal and generate a prompt of failure in verification of the second flash boot loader program, and push the prompt of failure in verification of the second flash boot loader program to the display screen or instrument panel of the vehicle; it can also be pushed to a mobile terminal associated with the vehicle; it can also be pushed to the corresponding automobile manufacturer terminal or maintenance terminal, such as the after-sales service center of the automobile manufacturer platform.

[0141] After reporting to the vehicle terminal, the upgrade of the vehicle controller can also be restricted.

[0142] The embodiment of the present application can effectively avoid safety hazards or usage failures by immediately performing corresponding processing after the second flash boot loader verification fails, and facilitates subsequent maintenance personnel to conduct timely inspection and processing, thereby improving the intelligence of the vehicle.

[0143] Specifically, the preset exception handling action is set by those skilled in the art according to actual conditions and is not specifically limited.

[0144] Optionally, in one embodiment of the present application, after the signature of the application startup program is verified, the method further includes: sending an application error prompt to the user after the application signature verification fails.

[0145] In actual implementation, embodiments of the present application can prompt the user after an application fails to verify the signature. The prompt method can be through the vehicle's sound and light error prompt, or through a mobile terminal associated with the vehicle. The application error prompt can include a verification failure code, so that the reason for the verification failure can be determined based on the verification failure code.

[0146] Furthermore, the present embodiment can also send application error notifications to maintenance terminals such as vehicle manufacturers' terminals to determine whether the error is an upload error or a malicious tampering error, allowing for timely correction based on the error type. This prevents users from unknowingly entering an infinite waiting period and prompts users to understand the situation, effectively improving the user experience and increasing vehicle customer stickiness.

[0147] Optionally, after verifying the signature of the second flash boot loader of the application, the method further includes: if the signature verification of the second flash boot loader fails, stopping the application upgrade and sending an upgrade failure prompt to the user.

[0148] Furthermore, after the second flash boot loader fails to verify the signature, the embodiment of the present application can stop upgrading the application to prevent the erroneous second flash boot loader or the second flash boot loader with viruses or security vulnerabilities from upgrading the application of the vehicle controller. At the same time, an upgrade failure prompt is sent to the maintenance terminal such as the vehicle manufacturer terminal, so that the maintenance terminal can determine the cause of the failure and respond in time, or facilitate users to take corresponding solutions, thereby increasing the diversity of measures and the effectiveness of problem solving, and improving the practicality of the vehicle.

[0149] Combine Figure 2-Figure 9 As shown, the working principle of the startup method of the embodiment of the present application is explained accordingly with an embodiment.

[0150] In the actual application process of the startup method of the embodiment of the present application, the internal structure and working principle of the vehicle controller can be as follows: Figure 2 and Figure 3 As shown, Figure 2 This is a schematic diagram of the startup principle of a vehicle controller in the related art. Figure 3 This is a schematic diagram of the startup principle of the vehicle controller according to an embodiment of the present application.

[0151] like Figure 2 As shown, it is a schematic diagram of the starting principle of the vehicle controller in the related art.

[0152] Related technologies may include a secure area and a non-secure area. The secure area is used to store secure firmware and keys to prevent the secure firmware from being tampered with and to prevent the keys from being leaked.

[0153] After passing the signature verification in the secure area, the Flash boot loader (FBL) in the non-secure area is launched. For example, during actual execution, after Bootrom, the process jumps to Bootloader, where the legitimacy of the root certificate, the Bootloader itself, and the next startup module is verified. The next module in the Bootloader (for example, APP1) is launched, and the legitimacy of the subsequent startup module is verified in this module. Following the verification of the next module in the current module, if the verification passes, the link verification of the next module is continued until all modules are verified. If the verification fails, the process jumps to the startup failure handling process: the failure reason and failure count are recorded in the Flash memory, and a software reset is performed.

[0154] In other words, the relevant technology needs to be verified layer by layer until all verifications are completed before feedback of verification failure can be given or the application can be started.

[0155] like Figure 3 , which is a schematic diagram of the startup principle of the vehicle controller according to an embodiment of the present application.

[0156] The embodiments of the present application may include a secure area and a non-secure area.

[0157] The secure area is used to store secure firmware and keys to prevent the secure firmware from being tampered with and the keys from being leaked.

[0158] After passing the signature verification in the secure area, the secure firmware starts and verifies the boot management program, and after passing, jumps to the boot management operation; in the boot management, it is determined whether an upgrade is required: if an upgrade is required, the flash boot loader FBL is verified, and after passing, it is transferred to the flash boot loader FBL for operation; if an upgrade is not required, the startup program of the application APP is verified, and after passing, it jumps to the application APP for operation.

[0159] exist Figure 2 and Figure 3 Based on the structure shown, Figure 4 As shown, the embodiment of the present application may include the following steps:

[0160] Step S401: Set the security firmware in a secure area, where the secure area can be an OTP area or an EFUSE area. Use the key management system to generate a pair of public and private keys, and store the private key in the OTP area to implement the function of the root of trust.

[0161] Among them, the programming in the OTP area or Efuse area will not be able to be changed or cleared again, thereby ensuring the security and effectiveness of the security firmware; the security firmware can be a program solidified into the hardware for secure booting through an encryption algorithm. The security firmware is stored in a secure area, which can prevent the security firmware from being rewritten externally, thereby improving the privacy and security of the security firmware.

[0162] Step S402: Determine whether the vehicle controller meets the preset safety conditions, that is, whether the OTP area or the Efuse area has been flashed. If it has been flashed, proceed to step S403; otherwise, proceed to step S404.

[0163] Step S403: handle the exception, interrupt or restart the current process. In addition, the exception can also be reported so that the exception can be handled as soon as possible.

[0164] Step S404: Run the boot management program using the secure firmware and verify the boot management program, such as BootManager, to ensure its security.

[0165] Among them, the boot management program manages the loading and startup process of the operating system. Some functions of the boot management program, such as BootManager, may include boot sequence control, operating system selection, error recovery, and firmware update.

[0166] Step S405: Determine whether the BootManager verification is passed. If the verification fails, proceed to step S403; otherwise, proceed to step S406.

[0167] Step S406: BootManager is started to determine subsequent startup items.

[0168] Step S407: BootManager starts to determine whether the application meets the preset upgrade conditions, that is, whether there is a pre-written logo in the application. When BootManager recognizes the logo, it determines that the preset upgrade conditions are met and enters step S411, otherwise it enters step S408.

[0169] Combine Figure 5 and Figure 6As shown, the safety startup process in the related technology can verify the application in the running area after the vehicle is powered on. After the verification is successful, the application can be run. After the verification fails, multiple restart verifications can be performed until a certain number of verifications are exceeded, and the current process is interrupted.

[0170] The optimized secure boot process in this embodiment can load the BootROM in the secure area to determine whether an application upgrade is required. If an application upgrade is required, the signature of the second flash boot loader is verified and the OTA process is entered. If an application upgrade is not required, the signature of the application startup program is verified and the application running process is entered.

[0171] Step S408: Verify the application process.

[0172] Step S409: Verify the visa of the application. If the verification is successful, proceed to step S410; otherwise, proceed to step S411.

[0173] like Figure 7 As shown, the verification process of the application startup program may include:

[0174] Step S1: Extract the image file signature of the application.

[0175] Step S2: Decrypt the application signature using the public key.

[0176] Step S3: Verify the application signature. If the verification fails, interrupt or restart the verification. If the verification succeeds, proceed to step S4.

[0177] Step S4: Verify the application image.

[0178] Step S5: Determine whether the application image has passed the verification. If not, interrupt or restart the verification. If successful, enter the second flash boot loader verification.

[0179] Step S410: Run the application logic and start the application.

[0180] Step S411: Verify the upgrade process, that is, perform signature verification on the second flash boot loader.

[0181] like Figure 8 As shown, the embodiment of the present application can use a symmetric key to calculate the current MAC value and compare it with the preset MAC value stored in the OTP area. If they are consistent, the verification is successful; if they are inconsistent, the verification fails.

[0182] Step S412: Determine whether the upgrade process is successfully verified. If so, proceed to step S414; otherwise, proceed to step S413.

[0183] Step S413: Perform error handling, interrupt or restart verification.

[0184] Step S414: Run the second flash boot loader logic to upgrade the application. There is no need to perform upgrade verification after the application is started, which saves startup efficiency and avoids security risks caused by system vulnerabilities and other reasons in the non-upgraded application.

[0185] Step S415: Copy the application image from the backup area to the primary area.

[0186] Among them, Figure 9 As shown, taking OTA upgrade as an example, the application upgrade process of the embodiment of the present application may include the following steps:

[0187] Step S901: Determine whether an upgrade task of the application is detected. If no upgrade task is detected, proceed to step S913; otherwise, proceed to step S902.

[0188] Step S902: The secure firmware starts the BootManager.

[0189] Step S903: Utilize BootManager to verify the second flash boot loader process.

[0190] Step S904: Determine whether the second flash boot loader is successfully verified. If successful, proceed to step S906; otherwise, proceed to step S905.

[0191] Step S905: reject the upgrade.

[0192] Step S906: The application image is copied from the primary partition to the backup partition.

[0193] Step S907: Download the OTA image to the primary partition.

[0194] Step S908: Verify the application process.

[0195] Step S909: Determine the verification result of the application program. If the verification is successful, proceed to step S910; otherwise, proceed to step S911.

[0196] Step S910: Run the application logic.

[0197] Step S911: The application image is copied from the backup area to the primary area.

[0198] Step S912: Verify the application process.

[0199] Step S913: Run the application logic.

[0200] In summary, the embodiments of the present application can use a secure area to implement software encryption and signature verification. When the vehicle is powered on, the code in the secure area starts running, solving the root of trust problem. At the same time, after the secure firmware is started, a BootManager is added to determine the content that needs to be verified, thereby optimizing the secure boot time. This allows the embodiments of the present application to use a secure area (which cannot be changed after a single flash) to solve the root of trust problem and implement encryption and signature verification using a software algorithm without a hardware encryption engine (HSE / HSM) and an external encryption chip. By adding a BootManager, it is determined whether the program needs to be refreshed, thereby determining the content to be verified next, shortening the overall secure boot time.

[0201] In addition, the embodiments of the present application can also be applied in low-cost MCU controllers. During secure startup, the embodiments of the present application can reduce the size of the image to be verified during startup and reduce the startup time by prioritizing the verification of the application (if flashing is required or the application verification fails, the flash boot loader will be checked).

[0202] For example, in a normal startup scenario, Figure 2 Compared with the operation logic of the related technology shown in FIG Figure 10 FIG. 1 shows the signature verification process in a normal startup scenario according to an embodiment of the present application.

[0203] The embodiment of the present application can first run the security firmware and verify the first flash boot loader based on the security firmware, so that after the first flash boot loader is successfully verified, the first flash boot loader can be run, and then the application program can be verified after the first flash boot loader is successfully verified.

[0204] In the OTA scenario, such as Figure 11 The figure shows the upgrade principle of the related technology in the OTA scenario. The related technology can detect whether there is an upgrade task after running the application, and jump to the flash boot loader to perform OTA if there is an upgrade task.

[0205] like Figure 12 The figure shows the upgrade principle of the embodiment of the present application in the OTA scenario. After running the application, the embodiment of the present application can detect whether there is an upgrade task, jump to the first flash boot loader, and then verify the signature of the second flash boot loader. After the signature verification is successful, it jumps to the second flash boot loader to perform OTA.

[0206] During the actual implementation process, the comparison of the verification package size between the related technology and the embodiment of the present application can be shown in Table 1 and Table 2, where Table 1 is the verification package volume table of the related technology, and Table 2 is the verification package volume table of the embodiment of the present application.

[0207] Table 1

[0208]

[0209] Table 2

[0210]

[0211] According to the startup method of the vehicle controller proposed in the embodiment of the present application, the application can be verified when no upgrade is required, so that the application can be run after the verification is passed. Otherwise, the second flash boot loader can be verified, so that the second flash boot loader can be run after the verification is passed, and the application can be upgraded. Finally, the upgraded application that has passed the verification can be run. While ensuring security, the startup time is effectively shortened, and the safe startup is avoided from taking too long. There is no need for a hardware encryption engine and an external encryption chip, and no additional cost is required. The user experience is effectively improved, the startup requirements of the vehicle controller are met, and the safety and practicality of the vehicle are improved.

[0212] An embodiment of the present application provides a starting device for a vehicle controller, including a functional module of the above-mentioned starting method for the vehicle controller.

[0213] The present invention also provides a vehicle controller capable of executing computer instructions that, when executed by a processor, implement the vehicle controller startup device provided in the present invention. Specifically, the executable program can be built into or installed in the vehicle, so that the vehicle can implement the vehicle controller startup device provided in the present invention by executing the built-in or installed executable program.

[0214] Figure 13 A schematic diagram of the structure of a vehicle provided in an embodiment of the present application. The vehicle may include: a processor 1301, a memory 1302, and a computer program stored in the memory 1302 and executable on the processor 1301. When the processor 1301 executes the computer program, the startup method provided in an embodiment of the present application is implemented.

[0215] The vehicle provided in the embodiment of the present application may further include a bus 1303 connecting different components (including the processor 1301 and the memory 1302). The bus 1303 represents one or more of several types of bus structures, including a memory bus, a peripheral bus, a local bus, and the like.

[0216] The memory 1302 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 13021 and / or a cache memory 13022 , and may further include a read-only memory (ROM) 13013 .

[0217] The memory 1302 may also include a program tool 13025 having a set (at least one) of program modules 13024, including but not limited to: an operating subsystem, one or more applications, other program modules and program data, each of which or some combination may include an implementation of a network environment.

[0218] The vehicle can communicate with one or more devices that enable users to interact with the vehicle (e.g., mobile phones, computers, etc.), and / or any device that enables the vehicle to communicate with one or more other devices, such as server terminals, etc. (e.g., routers, modems, etc.). Such communication can be performed through the input / output (I / O) interface 1305. In addition, the vehicle can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) through the network adapter 1306. Figure 13 As shown, the network adapter 1306 communicates with other modules of the vehicle via the bus 1303. Figure 13 Not shown, other hardware and / or software modules may be used in conjunction with the vehicle, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, disk arrays (Redundant Arrays of Independent Disks, RAID) subsystems, tape drives, and data backup storage subsystems.

[0219] It should be noted that Figure 13 The vehicle shown is merely an example and should not limit the functionality and scope of use of the embodiments of the present application.

[0220] The present application also provides a computer program that can execute computer instructions that, when executed by a processor, implement the startup method provided in the present application. Specifically, the executable program can be built into or installed in a vehicle / vehicle controller. In this way, the vehicle / vehicle controller can implement the startup method provided in the present application by executing the built-in or installed executable program.

[0221] The present invention also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the startup method provided in the present invention. Specifically, the executable program can be built into or installed in a vehicle. Thus, the vehicle can implement the startup method provided in the present invention by executing the built-in or installed executable program.

[0222] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

[0223] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Thus, a feature specified as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of this application, "N" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0224] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing a custom logical function or process step, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed in a different order than shown or discussed, including performing functions in a substantially simultaneous manner or in a reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application pertain.

[0225] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or N wires (electronic devices), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program can be obtained electronically by optically scanning the paper or other medium and then editing, interpreting or processing it in other suitable ways as necessary, and then storing it in a computer memory.

[0226] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiment, the N steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. If implemented using hardware, as in another embodiment, it can be implemented using any one or a combination of the following technologies known in the art: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0227] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0228] In addition, the functional units in the various embodiments of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into a module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0229] The storage medium mentioned above may be a read-only memory, a magnetic disk, or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application. Persons skilled in the art may make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

Claims

1. A method for starting a vehicle controller, characterized in that: include: receiving a start command from a vehicle controller; In response to the start instruction, controlling the vehicle controller to start; During the startup of the vehicle controller, determining whether an application in the vehicle controller needs to be upgraded; If the application does not need to be upgraded, the startup program of the application is verified by the first flash boot loader, and the application is run after the startup program passes the verification; If the application needs to be upgraded, the second flash boot loader of the vehicle controller is verified by the first flash boot loader, and after the second flash boot loader is verified, the second flash boot loader is run to download the upgrade package of the application, and the application is upgraded through the upgrade package.

2. The method for starting a vehicle controller according to claim 1, characterized in that: Determining whether the application in the vehicle controller needs to be upgraded includes: Starting the secure firmware within the secure area of ​​the vehicle controller; A boot management program is run through the secure firmware to use the boot management program to determine whether the application needs to be upgraded.

3. The method for starting a vehicle controller according to claim 2, characterized in that: The security area is a one-time programmable (OTP) area or an Efuse area.

4. The method for starting a vehicle controller according to claim 1, wherein: The verifying the signature of the second flash boot loader of the vehicle controller includes: Obtain identification information of the second flash boot loader, wherein the identification information is a current MAC value of the second flash boot loader; determining whether the second flash memory boot loader meets a preset verification condition according to the identification information; If the identification information meets the preset verification condition, it is determined that the second flash boot loader has passed verification.

5. The method for starting a vehicle controller according to claim 4, characterized in that: Before verifying the signature of the second flash boot loader of the vehicle controller, the method further includes: Generate a key of the vehicle controller using a preset encryption algorithm, and calculate the current MAC value using the key; The key is stored in a secure area of ​​the vehicle controller.

6. The method for starting a vehicle controller according to claim 1, characterized in that: Before verifying the signature of the startup program of the application, the following steps are also included: Extracting the image file signature of the application; Parsing the image file signature to obtain the information summary of the application; A visa for the application is obtained based on the information summary.

7. The method for starting a vehicle controller according to claim 1, characterized in that: Determining whether the application in the vehicle controller needs to be upgraded includes: Detecting whether the vehicle controller has an upgrade task; When it is detected that the vehicle controller has the upgrade task, it is determined that the application needs to be upgraded.

8. A starting device for a vehicle controller, characterized in that: Contains a module for implementing the functions of any one of the methods described in claims 1-7.

9. A vehicle controller, characterized in that: include: The starting device of the vehicle controller as claimed in claim 8.

10. A vehicle, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method for starting a vehicle controller according to any one of claims 1 to 7.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the method for starting a vehicle controller as described in any one of claims 1 to 7.

12. A computer program, characterized in that When the computer program is executed, it is used to implement the startup method of the vehicle controller as described in any one of claims 1 to 7.

Images