Electronic control unit and starting method thereof, microcontroller and computer program product

Abstract

The invention relates to an electronic control unit and a starting method thereof, a microcontroller and a computer program product, and the starting method comprises the following steps: when the electronic control unit is awakened, running a starting bootstrap program, and calling trusted security hardware to carry out integrity verification on a client bootstrap program; receiving a first verification result of integrity verification of the client bootstrap program by the trusted security hardware, and when the first verification result indicates that the verification of the client bootstrap program is passed, skipping to run the client bootstrap program to execute an application program authentication process; the application program authentication process comprises the steps of obtaining an enabling identifier and an authorization code of the application program, and if the enabling identifier is non-enabling or the authorization code is invalid, determining that the application program authentication is not passed; and if the enabling identifier is enabled and the authorization code is valid, determining that the application program passes authentication, setting the authorization code of the application program to be invalid, exiting the application program authentication process, and skipping to run the application program. The starting time of the electronic control unit can be shortened.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic control unit (ECU) technology, specifically to an electronic control unit and its starting method, a microcontroller (MCU), and a computer program product. Background Technology

[0002] In modern automobiles, the vehicle's electronic system contains ECUs that support a wide variety of functions. These ECUs need to communicate and cooperate with each other to ensure the normal operation of the entire vehicle. Traditional ECU security startup verification is a sequential verification process. When the ECU wakes up and starts, it uses a Hardware Security Module (HSM) or Secure Hardware Extension (SHE) and a protected Startup Boot (SB) as trusted roots to verify the legitimacy and integrity of the Customer Boot (CB). After the verification passes, based on the result, the Customer Boot is used to verify the legitimacy and integrity of the ECU's application program (APP). If the verification passes, the ECU system is allowed to start, the ECU runs the application program, and communicates with other ECUs.

[0003] In the traditional ECU startup process described above, the ECU must undergo two levels of verification during startup, which results in a longer startup time. This causes delays in both the ECU's execution of application-level functions and its communication with other ECUs after startup, negatively impacting the overall startup performance of the ECU. For example, it may cause some switch button triggers to fail to be detected or their status to be issued in a timely manner, or even affect the establishment of communication with other ECUs, leading to fault codes or the loss of some monitoring functions. Summary of the Invention

[0004] The purpose of this application is to provide an electronic control unit (ECU) and its startup method, a microcontroller (MCU), and a computer program product to shorten the startup time of the ECU and enable the ECU to enter the operating state more quickly.

[0005] To achieve the above objectives, according to a first aspect of this application, a method for starting a vehicle electronic control unit is provided, the method comprising:

[0006] If, during the operation of an application by the electronic control unit, it is detected that the application is about to terminate and enter a sleep state, an integrity check is performed on the application, and the enable flag and authorization code of the application are set and stored based on the integrity check result.

[0007] When the electronic control unit is woken up, it runs the boot program and calls trusted security hardware to perform integrity verification on the customer boot program.

[0008] The system receives a first verification result from the trusted security hardware's integrity verification of the client bootloader. When the first verification result indicates that the client bootloader has passed verification, it jumps to run the client bootloader to execute the application authentication process. The application authentication process includes obtaining the application's enable identifier and authorization code. If the enable identifier is disabled or the authorization code is invalid, the application authentication is determined to fail. If the enable identifier is enabled and the authorization code is valid, the application authentication is determined to pass, and the application's authorization code is set to invalid before exiting the application authentication process.

[0009] After exiting the application authentication process, you will be redirected to run the application.

[0010] According to a second aspect of this application, a microcontroller is provided for performing the method described in the first aspect of this application.

[0011] According to a third aspect of this application, an electronic control unit is provided, comprising:

[0012] The microcontroller described in the second aspect of this application;

[0013] Trusted and secure hardware is used to perform integrity verification on the client bootloader or the application in response to the call request of the microcontroller;

[0014] A first memory is used to store the bootloader, the client bootloader, and the application program;

[0015] The second memory is used to store the application's enable identifier and authorization code.

[0016] According to a fourth aspect of this application, a computer program product is provided, including computer program instructions that instruct a computer device to perform an operation corresponding to the method described in the first aspect.

[0017] The electronic control unit and its starting method, microcontroller, and computer program product provided in this application have the following beneficial effects:

[0018] During the ECU's application execution, when it detects that the application is about to terminate and enter hibernation, an integrity check is performed on the application in advance. Based on the integrity check result, the application's enable flag and authorization code are set and stored. This completes part of the verification work in advance, eliminating the need to repeat the full verification process on each startup. When the ECU wakes up from hibernation, it runs the bootloader and performs an integrity check on the client bootloader using trusted security hardware. After the client bootloader's integrity check passes, it enters the application authentication process. Compared to the traditional startup process, this application only needs to check the enable flag and authorization code stored before entering hibernation during the application authentication process, instead of performing a full check again. If the previously stored enable flag and authorization code indicate that the application has already passed verification, it can directly jump to running the application, thereby reducing the verification work at startup, simplifying the verification steps, shortening the ECU's startup time, and enabling the ECU to enter the running state more quickly. This is especially beneficial when the ECU frequently hibernates and wakes up, significantly improving efficiency. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings required in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an electronic control unit startup method according to an embodiment of this application.

[0021] Figure 2 This is a schematic diagram illustrating the workflow of the MCU and trusted security hardware in the embodiments of this application.

[0022] Figure 3 This is a schematic diagram of the frame structure of an electronic control unit in an embodiment of this application. Detailed Implementation

[0023] The detailed description of the accompanying drawings is intended to illustrate the present embodiments of this application and is not intended to represent only the forms in which this application can be implemented. It should be understood that the same or equivalent functions can be accomplished by different embodiments intended to be included within the spirit and scope of this application.

[0024] See Figure 1 One embodiment of this application provides an electronic control unit (ECU) start-up method, the method comprising the following steps:

[0025] Step S10: During the operation of the application by the electronic control unit, if it is detected that the application is about to end and enter a sleep state, the integrity of the application is verified, and the enable identifier and authorization code of the application are set and stored according to the integrity verification result.

[0026] Specifically, the ECU's microcontroller (MCU) monitors the application's running status in real time while executing the application. The MCU detects when the application completes its tasks or prepares to enter sleep mode due to certain conditions (such as inactivity or external signals). Before the application enters sleep mode, an integrity check is performed on the ECU's application. This check verifies, for example, whether the application's code and data have been tampered with, ensuring the application is intact before sleep. If the integrity check passes, the MCU sets two key pieces of information based on the result: an enable flag (CB_Mode) and an authorization code (Auth_Code). The enable flag indicates whether the application is allowed to run; if the check passes, the enable flag is set to enabled, represented as CB_Mode = APP_Able, indicating that the application is allowed to run. The authorization code further confirms the application's legitimacy; if the check passes, the authorization code is set to valid, represented as Auth_Code = Valid. The set enable flag and authorization code can then be stored in the ECU's non-volatile memory, ensuring that this information is not lost even if the ECU is powered off. In step S10, the ECU has completed the verification of the application and saved the verification results when the application is about to go into sleep mode.

[0027] Step S20: When the electronic control unit is woken up, the boot program is run and trusted security hardware is invoked to perform integrity verification on the customer boot program.

[0028] Specifically, the ECU wake-up in step S20 includes both initial wake-up (first power-on) and non-initial wake-up (wake-up from hibernation). The ECU is responsible for performing specific control functions in the vehicle. When the vehicle needs to perform these functions, the ECU wakes up from a low-power hibernation state to prepare for its control tasks. At this time, the MCU first runs the Startup Boot (SB). The Startup Boot is a piece of code that executes first when the MCU is powered on or reset. It is responsible for initializing the hardware and loading the operating system or application. During the execution of the Startup Boot, trusted security hardware (such as HSM or SHE) in the ECU is invoked to perform integrity checks on the Customer Boot, such as verifying whether the Customer Boot has been tampered with or corrupted. Through this process, the MCU ensures that the Customer Boot is trustworthy and has not been tampered with by malicious software or erroneous operations before executing the application. This is one of the key steps in the secure startup of the automotive electronic system, helping to prevent security vulnerabilities and system failures.

[0029] Step S30: Receive the first verification result of the integrity verification of the client bootloader by the trusted security hardware. When the first verification result indicates that the client bootloader has passed the verification, jump to run the client bootloader to execute the application authentication process. The application authentication process includes obtaining the application's enable identifier and authorization code. If the enable identifier is disabled or the authorization code is invalid, the application authentication is determined to fail. If the enable identifier is enabled and the authorization code is valid, the application authentication is determined to pass, and the application's authorization code is set to invalid before exiting the application authentication process.

[0030] Specifically, the MCU receives the first verification result of the integrity check performed on the client bootloader by the trusted security hardware. This verification result indicates whether the client bootloader has passed the integrity check. If the verification result shows that the client bootloader is complete and has not been tampered with, the MCU will continue to the next step. The MCU will jump to the execution of the client bootloader, which will then initiate the application authentication process. The application authentication process described in this embodiment is a simplified authentication process. The MCU reads the application's enable flag and authorization code stored in step S10 and verifies them. If the enable flag shows that the application is disabled, or the authorization code is invalid (i.e., CB_Mode = APP_UnAble or Auth_Code = InValid), then the MCU will determine that the application authentication has failed and prevent the application from running. If the enable flag shows that the application is enabled and the authorization code is valid (i.e., CB_Mode = APP_Able &...), then the MCU will determine that the application authentication has failed and prevent the application from running.

[0031] If Auth_Code = Valid, the MCU will determine that the application authentication is successful. Once authentication is successful, the MCU will set the authorization code to invalid, then exit the application authentication mode and prepare to run the application. Step S40: After exiting the application authentication process, the process jumps to run the application.

[0032] In summary, the method of this embodiment performs an integrity check on the application in advance when it detects that the application is about to terminate and enter a sleep state during the ECU's application operation. Based on the integrity check result, it sets and stores the application's enable flag and authorization code. This completes part of the verification work in advance, eliminating the need to perform the full verification process every time the ECU starts. When the ECU wakes up from sleep state, it runs the bootloader and performs an integrity check on the client bootloader using trusted security hardware. After the client bootloader's integrity check passes, it enters the application authentication process. Compared to the traditional startup process, this application only needs to check the enable flag and authorization code stored before entering sleep state during the application authentication process, instead of performing a full check again. If the previously stored enable flag and authorization code indicate that the application has already passed verification, it can directly jump to running the application, thereby reducing the verification work at startup, simplifying the verification steps, shortening the startup time of the electronic control unit, and enabling the ECU to enter the operating state more quickly. This is especially beneficial when the ECU frequently sleeps and wakes up, significantly improving efficiency.

[0033] In some specific embodiments, the method further includes:

[0034] Step S40: When the application authentication fails, the client bootloader is run, and the trusted security hardware is invoked to perform integrity verification on the application.

[0035] Specifically, when the application authentication fails, the MCU continues to run the client boot program and calls the trusted security hardware to perform integrity verification on the application. At this time, the client boot program will request the trusted security hardware (such as HSM or SHE) to perform integrity verification on the application. The verification method is the same as in step S10. If the integrity verification of the application fails, it will remain in the programming mode (recovery mode) in the client boot program.

[0036] Step S50: Receive the second verification result of the integrity verification of the application by the trusted security hardware. When the second verification result indicates that the application has passed the verification, set the authorization code of the application to be valid and set the enable flag of the application to be enabled.

[0037] Specifically, the MCU receives the integrity verification result from the trusted security hardware, i.e., the second verification result. When the second verification result indicates that the application verification has passed, i.e. the application is complete and has not been tampered with, the application's authorization code is set to valid and the application's enable flag is set to enabled. In this way, the application is marked as runnable, and its authorization code is updated to allow use during the next authentication.

[0038] Step S60: Obtain a wake-up identifier. If the wake-up identifier indicates that this wake-up is the first wake-up after power-on, then set the wake-up identifier to non-first wake-up. If the wake-up identifier indicates that this wake-up is not the first wake-up after power-on, then do not change the setting of the wake-up identifier.

[0039] Specifically, in this embodiment, a wake-up flag is set to indicate whether the ECU is being woken up for the first time. For example, Batt_1st_ON = True indicates that the ECU is being woken up for the first time, and Batt_1st_ON = False indicates that the ECU is not being woken up for the first time. The MCU determines whether the ECU is being woken up for the first time by reading the wake-up flag.

[0040] Step S70: Execute the application authentication process again.

[0041] It should be noted that when the ECU is powered on for the first time (i.e., the first wake-up), since the ECU is powered on for the first time, the application integrity verification and setting CB_Mode = APP_Able & before hibernation have been performed.

[0042] Since Auth_Code = Valid, the MCU will find that CB_Mode = APP_Able & Auth_Code = Valid does not meet the requirement during the application authentication process, causing the application authentication to fail. In this case, the MCU will execute steps S40 to S50. If the application integrity verification passes, CB_Mode = APP_Able & Auth_Code = Valid will be set so that the application authentication process can be successfully executed again in step S70. At the same time, the wake-up flag will be set to Batt_1st_ON = False.

[0043] When the ECU is not waking up for the first time, since the ECU has already performed an application integrity check before hibernation and set CB_Mode = APP_Able & Auth_Code = Valid if the integrity check passes, the MCU will find that CB_Mode = APP_Able & Auth_Code = Valid during the application authentication process.

[0044] Auth_Code = Valid, at which point the application authentication is successful.

[0045] However, if the application integrity check fails before hibernation, CB_Mode = APP_UnAble or Auth_Code = InValid will be set. Therefore, during the application authentication process, the MCU will find that CB_Mode = APP_Able & Auth_Code = Valid is not satisfied, causing application authentication to fail. In this case, the MCU will also execute steps S40 to S50. If the application integrity check passes, CB_Mode = APP_Able & Auth_Code = Valid will be set so that the application authentication process can be successfully executed again in step S70. Meanwhile, since this is not the first wake-up, the wake-up flag is always Batt_1st_ON = False and does not need to be changed.

[0046] Therefore, the ECU design in this embodiment considers two different wake-up scenarios: first-time wake-up and non-first-time wake-up, and ensures that the application authentication process is handled correctly in each case. For the first power-up, more comprehensive security checks and initialization steps are required, while for non-first-time wake-ups, the authentication process can be simplified by utilizing previously stored enable flags and authorization codes. This design improves the efficiency and security of ECU startup.

[0047] In some specific embodiments, step S10, which involves setting and storing the application's enable identifier and authorization code based on the application's integrity verification result, further includes:

[0048] The application's enable flag is set to disabled to trigger the application authentication process. If the application authentication fails, the client bootloader is run to call the trusted security hardware to perform an integrity check on the application. The second verification result of the integrity check on the application by the trusted security hardware is received. When the second verification result indicates that the application verification has passed, the application's authorization code is set to valid, and the application's enable flag is set to enabled. The wake-up flag, the application's enable flag, and the authorization code are stored, and the application enters a sleep state.

[0049] Specifically, when the application is about to enter sleep mode, the MCU first disables the application's enable flag (CB_Mode = APP_UnAble), triggering the MCU to run the client bootloader to execute the application authentication process. At this point, because the enable flag is disabled, the condition CB_Mode = APP_Able & Auth_Code = Valid is not met, so the MCU's execution of the application authentication process will fail. In this case, an integrity check of the application is performed, thus pre-verifying the application. Based on the check result, the enable flag and authorization code are set and saved. If the application integrity check passes, CB_Mode = APP_Able & Auth_Code = Valid is set. Therefore, when the ECU is woken from sleep mode again, the MCU can execute the application authentication process, determine if CB_Mode = APP_Able & Auth_Code = Valid is met, and the application is authenticated, enabling the ECU to quickly start.

[0050] In some specific embodiments, the method further includes:

[0051] Step S80: When the electronic control unit is powered off and then powered on again, the wake-up identifier, the enable identifier of the application, and the authorization code are all initialized to default values. The initial default value of the enable identifier of the application is disabled, the initial default value of the application is invalid, and the initial default value of the wake-up identifier indicates that this wake-up is the first wake-up after power-on.

[0052] Specifically, when the ECU is powered off and then powered on again, it indicates that the ECU is being woken up for the first time. At this time, the default values ​​are CB_Mode = APP_UnAble, Auth_Code = InValid, and Batt_1st_ON = True. The MCU then executes step S20. Since CB_Mode = APP_Able & Auth_Code = Valid are not satisfied, the application authentication fails. This causes the MCU to continue executing steps S40 to S70 to complete the integrity verification of the application. If the integrity verification in step S40 passes, CB_Mode = APP_Able and Auth_Code = Valid will be set in step S50, and Batt_1st_ON = False will be set in step S60.

[0053] In some specific embodiments, step S20 further includes:

[0054] When the trusted security hardware is invoked to perform integrity verification on the client bootloader, the trusted security hardware calculates the code verification value of the client bootloader based on a preset security encryption algorithm. If the calculated code verification value is consistent with the preset first code verification value, the client bootloader is determined to have passed the verification. If the calculated code verification value is inconsistent with the preset first code verification value, the client bootloader is determined to have failed the verification.

[0055] Specifically, the trusted security hardware stores an integrity verification program and a preset first code verification value (CB_CMAC). The MCU sends a first verification request to the trusted security hardware to invoke the trusted security hardware to perform integrity verification on the client boot program. When the trusted security hardware receives the first verification request from the MCU, it runs the integrity verification program and calculates the code verification value CB_CMAC' of the client boot program code segment based on a preset security encryption algorithm (e.g., AES128-MAC algorithm). The integrity verification program compares whether the preset CB_CMAC and the calculated CB_CMAC' are consistent and feeds back the comparison result to the MCU. If CB_CMAC and CB_CMAC' are consistent, the first verification result is successfully fed back; if CB_CMAC and CB_CMAC' are inconsistent, the first verification result is unsuccessful.

[0056] In some specific embodiments, step S40 further includes:

[0057] When the trusted security hardware is invoked to perform integrity verification on the application, the trusted security hardware calculates the code verification value of the application based on a preset security encryption algorithm. If the calculated code verification value is consistent with the preset second code verification value, the application is determined to have passed the verification. If the calculated code verification value is inconsistent with the preset second code verification value, the application is determined to have failed the verification.

[0058] Specifically, the trusted security hardware stores an integrity verification program and a preset second code verification value (APP_CMAC). The MCU sends a second verification request to the trusted security hardware to invoke the trusted security hardware to perform integrity verification on the application. When the trusted security hardware receives the second verification request from the MCU, the trusted security hardware runs the integrity verification program and calculates the code verification value APP_CMAC' of the application code segment based on a preset security encryption algorithm (e.g., AES128-MAC algorithm). The integrity verification program compares whether the preset APP_CMAC and the calculated APP_CMAC' are consistent and feeds back the comparison result to the MCU. If APP_CMAC and APP_CMAC' are consistent, the first verification result is successfully fed back; if APP_CMAC and APP_CMAC' are inconsistent, the first verification result is unsuccessful.

[0059] Figure 2 The workflow of the MCU and the trusted security hardware is illustrated. When the ECU is woken up, Secure Boot is initiated. The MCU jumps to run the bootloader (SB), triggering the integrity verification process of the client bootloader (CB). It sends a first verification request to the trusted security hardware. The trusted security hardware responds to the first verification request, verifies the CB, and returns a first verification result to the MCU. The MCU determines whether the verification is successful based on the first verification result. If it is, it jumps to run the CB; otherwise, it remains in programming mode (recovery mode).

[0060] When the MCU jumps to run the CB, it triggers the application authentication process, checking whether CB_Mode = APP_Able & Auth_Code = Valid is satisfied. If yes, it sets Auth_Code = InValid, ends the application authentication process, and the MCU jumps to run the application. If not, it triggers the application integrity verification process. At this time, the MCU sends a second verification request to the trusted security hardware. The trusted security hardware responds to the second verification request, verifies the application, and returns a second verification result to the MCU. The MCU determines whether the verification is successful based on the second verification result. If yes, it sets Auth_Code = Valid and CB_Mode = APP_Able, then reads Batt_1st_ON and checks whether Batt_1st_ON = True is satisfied. If yes, it sets Batt_1st_ON = False. If not, it enters a sleep state.

[0061] When the MCU jumps to run the application, it monitors whether the application needs to enter a low-power process and go into sleep mode. If so, it sets CB_Mode = APP_UnAble, triggers the ECU software to restart, and returns to the application authentication process.

[0062] Another embodiment of this application provides a microcontroller (MCU) disposed in an electronic control unit (ECU) and serving as the processing core of the ECU. The microcontroller (MCU) is used to execute the method steps described in the above embodiments.

[0063] It should be noted that the microcontroller (MCU) in this embodiment is the hardware used to execute the above embodiments. Therefore, the detailed technical principles of the microcontroller in this embodiment can be obtained by referring to the content of the methods in the above embodiments, and will not be repeated in this embodiment.

[0064] Another embodiment of this application provides an electronic control unit (ECU), including:

[0065] The microcontroller (MCU) described in the above embodiments;

[0066] Trusted security hardware is used to respond to the call request of the microcontroller and perform integrity verification on the Customer Boot or the application (APP); specifically, the trusted security hardware is a hardware security module (HSM) or a security hardware extension module (SHE);

[0067] The first memory is used to store the Startup Boot, the Customer Boot, and the application program (APP); specifically, the first memory is a read-only memory (ROM);

[0068] The second memory is used to store the enable flag (CB_mode) and authorization code (Auth_Code) of the application (APP) as well as the wake-up flag (Batt_1st_ON); specifically, the second memory is static random access memory (SRAM);

[0069] The third memory is used to support the MCU in running the application program (APP), the customer boot program, and the startup boot program, and to store and operate dynamic data and instructions; specifically, the third memory is RAM;

[0070] In addition, other peripherals, such as power supplies and I / O devices, are used to provide operating power to the various components of the ECU and to communicate with external devices, such as other ECUs.

[0071] It should be noted that the electronic control unit (ECU) in this embodiment is hardware used to execute the above embodiments. Therefore, the detailed technical principles of the microcontroller, trusted security hardware, first memory and second memory of the electronic control unit (ECU) can be obtained by referring to the content of the method in the above embodiments, and will not be repeated in this embodiment.

[0072] This application also provides a computer program product, including computer program instructions, which instruct a computer device to perform operations corresponding to the methods described in the above embodiments.

[0073] Specifically, the computer program product includes a series of computer program instructions that instruct a computer device to execute the vehicle ECU starting method described in this application. These instructions are code written in a computer program that defines how to perform specific operations. In this embodiment, these instructions are used to execute the vehicle ECU starting method of the above embodiments.

[0074] These program instructions are designed to be loaded onto a computer device and to instruct the device to perform specific operations, which refer to the various steps in the vehicle ECU startup method described in the above embodiments.

[0075] In this way, the computer program product provides a complete software solution that can run on various computer devices to implement the vehicle ECU start-up method described in the above embodiments.

[0076] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technological improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for starting an electronic control unit, characterized in that, The method includes: If, during the operation of an application by the electronic control unit, it is detected that the application is about to terminate and enter a sleep state, an integrity check is performed on the application, and the enable flag and authorization code of the application are set and stored based on the integrity check result. When the electronic control unit is woken up, it runs the boot program and calls trusted security hardware to perform integrity verification on the customer boot program. The system receives a first verification result from the trusted security hardware's integrity verification of the client bootloader. When the first verification result indicates that the client bootloader has passed verification, it jumps to run the client bootloader to execute the application authentication process. The application authentication process includes obtaining the application's enable identifier and authorization code. If the enable identifier is disabled or the authorization code is invalid, the application authentication is determined to fail. If the enable identifier is enabled and the authorization code is valid, the application authentication is determined to pass, and the application's authorization code is set to invalid before exiting the application authentication process. After exiting the application authentication process, you will be redirected to run the application.

2. The method according to claim 1, characterized in that, The method further includes: When the application authentication fails, the client bootstrap program is run, and the trusted security hardware is invoked to perform an integrity verification on the application. The system receives a second verification result from the trusted security hardware's integrity verification of the application. When the second verification result indicates that the application has passed the verification, the system sets the application's authorization code to valid and sets the application's enable flag to enabled. The system also obtains a wake-up flag. If the wake-up flag indicates that this wake-up is the first wake-up after power-on, the system sets the wake-up flag to non-first wake-up. If the wake-up flag indicates that this wake-up is not the first wake-up after power-on, the system does not change the setting of the wake-up flag. The application authentication process is executed again.

3. The method according to claim 2, characterized in that, The step of setting and storing the application's enable identifier and authorization code based on the application's integrity verification result further includes: The application's enable flag is set to disabled to trigger the application authentication process. If the application authentication fails, the client bootloader is run to call the trusted security hardware to perform an integrity check on the application. The second verification result of the integrity check on the application by the trusted security hardware is received. When the second verification result indicates that the application verification has passed, the application's authorization code is set to valid, and the application's enable flag is set to enabled. The wake-up flag, the application's enable flag, and the authorization code are stored, and the application enters a sleep state.

4. The method according to claim 2 or 3, characterized in that, The method further includes: When the electronic control unit is powered off and then powered on again, the wake-up flag, the application's enable flag, and the authorization code are all initialized to their default values. The initial default value of the application's enable flag is disabled, the initial default value of the application is invalid, and the initial default value of the wake-up flag indicates that this wake-up is the first wake-up after power-on.

5. The method according to claim 1, characterized in that, The method further includes: When the trusted security hardware is invoked to perform integrity verification on the client bootloader, the trusted security hardware calculates the code verification value of the client bootloader based on a preset security encryption algorithm. If the calculated code verification value is consistent with the preset first code verification value, the client bootloader is determined to have passed the verification. If the calculated code verification value is inconsistent with the preset first code verification value, the client bootloader is determined to have failed the verification.

6. The method according to any one of claims 2 to 4, characterized in that, The method further includes: When the trusted security hardware is invoked to perform integrity verification on the application, the trusted security hardware calculates the code verification value of the application based on a preset security encryption algorithm. If the calculated code verification value is consistent with the preset second code verification value, the application is determined to have passed the verification. If the calculated code verification value is inconsistent with the preset second code verification value, the application is determined to have failed the verification.

7. A microcontroller, characterized in that, The microcontroller is used to perform the method according to any one of claims 1 to 6.

8. An electronic control unit, characterized in that, include: The microcontroller of claim 7; Trusted and secure hardware is used to perform integrity verification on the client bootloader or the application in response to the call request of the microcontroller; A first memory is used to store the bootloader, the client bootloader, and the application program; The second memory is used to store the application's enable identifier and authorization code.

9. The electronic control unit according to claim 8, characterized in that, When the microcontroller is used to perform the method of any one of claims 2 to 4 and 6, the second memory is also used to store the wake-up identifier.

10. A computer program product, characterized in that, It includes computer program instructions that instruct a computer device to perform an operation corresponding to the method described in any one of claims 1 to 6.

Images