Control method for verifying and diagnosing safe start of MCU (Microprogrammed Control Unit) controller

Abstract

The invention discloses a control method for safe start verification and diagnosis of an MCU (Microprogrammed Control Unit) controller. The control method comprises the following steps: 1) presetting parameters S1, S2 and S3 stored in an NVM (Non-Volatile Memory); 2) predefining parameters X1, X2 and X3 which can be accessed through a data reading 22 service of the UDS; (3) all the starting codes are verified; (4) checking all codes of the boot loader; 5) verifying the application program code by adopting a random segmentation extraction mode; (6) all the calibration program codes are verified, and if verification fails, failure logs are stored in preset S1, S2 and S3; and if the verification is successful, the MCU is started successfully. The MCU control unit is adopted to carry out verification and diagnosis control design on the starting code, the boot loader code, the application program code and the calibration program code, so that safe starting of the MCU of the whole vehicle can be ensured, and accurate diagnosis information can be provided for after-sales maintenance of the whole vehicle.

Description

Technical Field

[0001] The present invention relates to the field of automobile MCU controller software information security, and in particular to a control method for safe startup verification and diagnosis of an MCU controller. Background Art

[0002] With the rapid development of the automotive industry towards networking and intelligence, the risks and threats to automobiles have also increased. Cyber ​​attacks on vehicles have emerged in various places. Today, vehicle network security is no longer just about individual road users, but also affects the security of society, the country and even the world. In the future, new energy in the automotive field has become an inevitable trend. As the core electronic controller of new energy vehicles, MCU is subject to network attacks and has a high probability of causing safety accidents. Therefore, the authenticity and accurate verification of MCU code is crucial. At present, most MCU startup verification uses HSM hardware modules to verify the authenticity of the code to ensure that the MCU program is not maliciously tampered with, and the security level is generally recognized in the industry. However, there are two problems: First, the specific address segment of the attacked program is not locked, and the robustness of the MCU controller software cannot be improved. The software iteration speed cannot keep up, and the slow upgrade leads to the program being tampered with all the time; second, after-sales maintenance is difficult, and it is generally returned to the MCU controller supplier for self-analysis, which increases the after-sales maintenance cost and customer complaint rate. Summary of the invention

[0003] The present invention provides a control method for the safe startup verification and diagnosis of an MCU controller. By adopting an MCU control unit to verify and diagnose the startup code, boot loader program code, application program code, and calibration program code, the safe startup of the MCU controller of the whole vehicle can be ensured, and accurate diagnostic information can be provided for after-sales maintenance of the whole vehicle.

[0004] The technical solutions to the above problems are as follows: A control method for safe startup verification and diagnosis of an MCU controller comprises the following steps: Step 1) preset the parameters stored in NVM to boot the loader code verification failure log S1, the application verification failure log S2 and the calibration program code failure log S3; Step 2) pre-define the bootloader code verification failure parameters X1, the application program verification failure parameters X2, and the calibration program code verification failure parameters X3 that can be accessed through the UDS read data 22 service; Step 3) Verify all the startup codes. If the verification fails, store the failure log in the fixed address segment of the HSM module DFLASH. Read the value of this part through the debugger to confirm that the program stops in the address segment of the HSM module. If the verification succeeds, go to step 4); Step 4) Verify all bootloader codes. If verification fails, save the failure log into the preset bootloader code verification failure log S1. Access the bootloader code verification failure parameters X1 before and after the failure through the UDS-22 service. The program stops at the address segment of the startup code. If verification succeeds, go to step 5); Step 5) Verify the application code by random segment extraction. If the verification fails, the failure log is stored in the pre-set application verification failure log S2. The parameters X2 before and after the application verification failure are accessed through the UDS-22 service, and the program stops in the boot loader. If the verification succeeds, go to step 6. Step 6) Verify all calibration program codes. If the verification fails, store the failure log in the preset calibration program code failure log S3. Access the parameter X3 before and after the calibration program code verification failure through the UDS-22 service, and the program stops in the boot loader; if the verification succeeds, the MCU starts successfully.

[0005] The beneficial technical effects of the present invention are: 1. The MCU control unit is used to verify the secure boot code, boot loader code, application code, and calibration program code in sequence to ensure that the code has not been tampered with or damaged, while protecting the safety of users.

[0006] 2. When the security boot code, boot loader code, application code, and calibration code fail to be verified, all process verification logs are stored in the DFLASH of the HSM. This ensures security and will not be lost. At the same time, the failure log can be obtained by reading the DID.

[0007] 3. By using hierarchical verification on the MCU code, the specific location of the security startup failure can be locked, which is convenient for software improvement and after-sales personnel to carry out maintenance, reducing after-sales costs, improving maintenance efficiency, and reducing customer complaints. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 It is the main control flow chart of the present invention.

[0009] Figure 2 It is a flow chart of the application code verification of the present invention. DETAILED DESCRIPTION

[0010] like Figure 1 and Figure 2 As shown, the control method for safe startup verification and diagnosis of the MCU controller of the present invention comprises the following steps: Step 1) preset the parameter bootloader code verification failure log S1, the application verification failure log S2 and the calibration program code failure log S3 stored in NVM (NVM is non-volatile memory).

[0011] Preferably, the storage size of the boot loader code verification failure log parameter S1 stored in the NVM is preset to be 64 Byte, the storage size of the application verification failure log S2 is 256 Byte, and the storage size of the calibration program code failure log S3 is 128 Byte.

[0012] Step 2) Predefine the bootloader code verification failure parameters X1, application verification failure parameters X2, and calibration program code verification failure parameters X3 that can be accessed through the UDS read data 22 service. UDS (Unified Diagnostic Services) is a diagnostic protocol widely used in the automotive industry.

[0013] Preferably, the storage size of the boot loader code verification failure parameter X1 accessible through the UDS read data 22 service is predefined to be 66Byte, the storage size of the application program code verification failure parameter X2 is 66Byte, and the storage size of the calibration program code verification failure parameter X3 is 66Byte.

[0014] Step 3) Verify all the boot codes. If the verification fails, store the failure log in the fixed address segment of the HSM module (hardware security module (HSM)) DFLASH (DFLASH is a technology that manages and accesses flash memory through a distributed architecture). Read the value of this part through the debugger to confirm that the program stops in the address segment of the HSM module; the address segment ranges from 0x800XXXXX to 0x800XXXXX. If the verification succeeds, go to step 4).

[0015] Preferably, in step 3), the process of verifying all the boot codes uses an HSM module, and uses the chip's own key and the AES-128 algorithm to calculate the CMAC1 value when the boot code is burned for the first time before leaving the factory (CMAC1 represents a symmetric key message authentication code, and the subsequent CMAC2 to CMAC10 also mean a symmetric key message authentication code), and stores the CMAC1 value in the DFLASH fixed address of the HSM module. Each time the boot is started, the same algorithm and the chip's own key are used to calculate CMAC2, and it is determined whether the CMAC1 and CMAC2 values ​​are the same. If different, both the CMAC1 and CMAC2 values ​​are stored in the DFLASH fixed address of the HSM module. If they are the same, proceed to step 4).

[0016] The chip comes with a key with a length of 16 bytes. Each chip will be written with the key when it leaves the factory. The MCU controls the reading of the key through the HSM function port to calculate and verify the secure boot code. The AES-128 algorithm is one of the most widely used cryptographic standards, and its key generation and decryption rules are quite clear and easy to accept and understand.

[0017] The CMAC1 and CMAC2 values ​​after the failure are stored in the DFLASH of the HSM starting at the address 0xAF00XXXX and the address segment of 66 bytes. The code of this part can be exported through the debugger to analyze the cause of the failure.

[0018] Step 4) Verify all boot loader codes. If the verification fails, save the failure log into the pre-set boot loader code verification failure log S1. Access the boot loader code verification failure parameters X1 before and after the failure through the UDS-22 service. The program stops at the address segment of the startup code. If the verification succeeds, go to step 5).

[0019] Preferably, in step 4), the process of verifying the entire boot loader code uses an HSM module, and uses the chip's own key and the AES-128 algorithm to calculate the CMAC3 value when the boot loader code is burned for the first time before leaving the factory, and the CMAC3 value is stored in the DFLASH of the HSM module. Each time the boot is started, the same algorithm and the chip's own key are used to calculate CMAC4, and it is determined whether the CMAC3 and CMAC4 values ​​are the same. If different, both CMAC3 and CMAC4 values ​​are stored in the pre-set boot loader code verification failure log S1. If they are the same, proceed to step 5).

[0020] The boot loader code verification failure log S1 is a complete log of the boot loader process verification, and is stored in the DFLASH of the HSM starting with the address 0xAF0AXXXX and a size of 64Byte in a fixed address segment. The cause of the failure can be exported and analyzed through the debugger.

[0021] Preferably, the boot loader code verification failure log S1 in step 4) is the entire log of the boot loader code verification process, and is stored in the DFLASH fixed address of the HSM, and the cause of the failure can be exported and analyzed through the debugger; the values ​​of CMAC3 and CMAC4 involved in the comparison are assigned to parameter X1, and after-sales service can access the reading parameter X1 through the UDS-22 service to obtain the failure information.

[0022] Step 5) The application code is verified by random segment extraction. If the verification fails, the failure log is stored in the pre-set application verification failure log S2. The parameters X2 before and after the application verification failure are accessed through the UDS-22 service, and the program stops in the boot loader; if the verification succeeds, go to step 6.

[0023] Preferably, in step 5), the application code is verified by randomly extracting segments, and the application code is randomly divided into three segments. Each time it is started, a segment is extracted for verification through a random function, which can save startup initialization time. The verification process uses an HSM module, and uses a custom key to calculate the values ​​of the three segments CMAC5, CMAC6, and CMAC7 when the application code is burned for the first time at the factory according to the AES-128 algorithm and store them in the DFLASH of the HSM module. Each time it is started, a segment is randomly extracted for verification using the same algorithm and custom key to determine whether the CMAC5, CMAC6, and CMAC7 of the randomly extracted segment are the same as the CMAC8 of the same calculated segment. If different, one of the randomly extracted CMAC5, CMAC6, and CMAC7 segments and the CMAC8 value are stored in the preset application verification failure log S2. If they are the same, go to step 6).

[0024] The size of the custom key is 16 Byte, which is set according to the vehicle model on which the MCU is mounted to prevent tampering. The custom key is pre-stored in the DFLASH of the HSM.

[0025] The application verification failure log S2 is a complete log of the application verification process, and is stored in the DFLASH of the HSM starting with the address 0xAF0BXXXX, with a size of 256 Byte in a fixed address segment, and can be exported through the debugger to analyze the cause of the failure.

[0026] Preferably, the application verification failure log S2 in step 5) is the entire log of the application verification process, and is stored in the fixed address of DFLASH of the HSM, and the cause of the failure can be exported and analyzed through the debugger; the CMAC5, CMAC6, CMAC7 and CMAC8 values ​​involved in the comparison are assigned to parameter X2, and after-sales service can access the reading parameter X2 through the UDS-22 service to obtain the failure information.

[0027] Step 6) Verify all calibration program codes. If the verification fails, store the failure log in the preset calibration program code failure log S3. Access the parameter X3 before and after the calibration program code verification failure through the UDS-22 service, and the program stops in the boot loader; if the verification succeeds, the MCU starts successfully.

[0028] Preferably, in step 6), the entire calibration program code is verified using an HSM module, and the CMAC9 value when the boot loader code is burned for the first time at the factory is calculated using the AES-128 algorithm through a custom key, and the CMAC9 value is stored in the DFLASH of the HSM. Each time the MCU is started, the same algorithm and custom key are used to calculate CMAC10, and it is determined whether the CMAC9 and CMAC10 values ​​are the same. If different, the CMAC9 and CMAC10 values ​​are stored in the pre-set calibration program code failure log S3. If they are the same, the MCU is started successfully.

[0029] The calibration program code failure log S3 is a complete log of the calibration program code verification process, and is stored in the DFLASH of the HSM starting with the address 0xAF0CXXXX and having a size of 128 Byte in a fixed address segment. The cause of the failure can be exported and analyzed through the debugger.

[0030] Preferably, the calibration program code failure log S3 in step 6) is the entire log of the calibration program code verification process, and is stored in the DFLASH fixed address of HSMCMAC, and the cause of the failure can be exported and analyzed through the debugger; the CMAC9 and CMAC10 values ​​involved in the comparison are assigned to parameter X3, and after-sales service can access and read parameter X3 through the UDS-22 service to obtain failure information.

[0031] The present invention adopts an MCU control unit to perform verification and diagnostic control design on the startup code, boot loader program code, application program code, and calibration program code, thereby ensuring the safe startup of the MCU controller of the whole vehicle and providing accurate diagnostic information for after-sales maintenance of the whole vehicle.

[0032] The examples described above are only some embodiments of the present invention, rather than all of them. Based on the examples in the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative work are within the scope of protection of the present invention.

Claims

1. A control method for MCU controller safety startup verification and diagnosis, characterized in that: The following steps are involved: Step 1) preset the parameters stored in NVM to boot the loader code verification failure log S1, the application verification failure log S2 and the calibration program code failure log S3; Step 2) pre-define the bootloader code verification failure parameters X1, the application program verification failure parameters X2, and the calibration program code verification failure parameters X3 that can be accessed through the UDS read data 22 service; Step 3) Verify all the startup codes. If the verification fails, store the failure log in the fixed address segment of the HSM module DFLASH. Read the value of this part through the debugger to confirm that the program stops in the address segment of the HSM module. If the verification succeeds, go to step 4); Step 4) Verify all bootloader codes. If verification fails, save the failure log into the preset bootloader code verification failure log S1. Access the bootloader code verification failure parameters X1 before and after the failure through the UDS-22 service. The program stops at the address segment of the startup code. If verification succeeds, go to step 5); Step 5) The application code is verified by random segment extraction. If the verification fails, the failure log is stored in the pre-set application verification failure log S2. The parameters X2 before and after the application verification failure are accessed through the UDS-22 service, and the program stops in the boot loader; If the verification is successful, go to step 6; Step 6) Verify all calibration program codes. If verification fails, store the failure log in the preset calibration program code failure log S3. Access the parameters X3 before and after the calibration program code verification failure through the UDS-22 service, and the program stops in the boot loader; If the verification is successful, the MCU starts successfully.

2. The control method for secure startup verification and diagnosis of an MCU controller according to claim 1, characterized in that: Step 3) The HSM module is used to verify the entire boot code. The CMAC1 value when the boot code is burned for the first time at the factory is calculated using the AES-128 algorithm through the chip's own key, and the CMAC1 value is stored in the DFLASH fixed address of the HSM module. Each time the boot is started, the same algorithm and the chip's own key are used to calculate CMAC2, and it is determined whether the CMAC1 and CMAC2 values ​​are the same. If different, both CMAC1 and CMAC2 values ​​are stored in the DFLASH fixed address of the HSM module. If they are the same, proceed to step 4).

3. The control method for secure startup verification and diagnosis of an MCU controller according to claim 1, characterized in that: Step 4) The entire boot loader code is verified using an HSM module. The chip's built-in key and the AES-128 algorithm are used to calculate the CMAC3 value when the boot loader code is burned for the first time at the factory. The CMAC3 value is stored in the DFLASH of the HSM module. Each time the boot is started, the same algorithm and the chip's built-in key are used to calculate CMAC4. It is determined whether the CMAC3 and CMAC4 values ​​are the same. If they are different, both CMAC3 and CMAC4 values ​​are stored in the pre-set boot loader code verification failure log S1. If they are the same, proceed to step 5).

4. The control method for secure startup verification and diagnosis of an MCU controller according to claim 3, characterized in that: Step 4) Boot loader code verification failure log S1 is the entire log of the boot loader code verification process and is stored in the fixed address of DFLASH of HSM. The reason for the failure can be exported and analyzed through the debugger; the values ​​of CMAC3 and CMAC4 involved in the comparison are assigned to parameter X1. After-sales service can access and read parameter X1 through UDS-22 service to obtain failure information.

5. The control method for secure startup verification and diagnosis of an MCU controller according to claim 1, characterized in that: In step 5), the application code is verified by random segment extraction. The application code is randomly divided into three sections. Each time it is started, a section is extracted for verification through a random function, which can save startup initialization time. The verification process uses an HSM module. Through a custom key, the values ​​of the three sections of CMAC5, CMAC6, and CMAC7 when the application code is burned for the first time at the factory are calculated according to the AES-128 algorithm and stored in the DFLASH of the HSM module. Each time it is started, a section is randomly extracted for verification using the same algorithm and custom key to determine whether the CMAC5, CMAC6, and CMAC7 of the randomly extracted section are the same as the CMAC8 of the same calculated section. If different, one of the randomly extracted CMAC5, CMAC6, and CMAC7 and the CMAC8 value are stored in the pre-set application verification failure log S2. If they are the same, go to step 6).

6. The control method for secure startup verification and diagnosis of an MCU controller according to claim 5, characterized in that: The application verification failure log S2 in step 5) is the entire log of the application verification process and is stored in the fixed address of DFLASH of the HSM. The cause of the failure can be exported and analyzed through the debugger; the CMAC5, CMAC6, CMAC7 and CMAC8 values ​​involved in the comparison are assigned to parameter X2. After-sales service can access and read parameter X2 through the UDS-22 service to obtain failure information.

7. The control method for secure startup verification and diagnosis of an MCU controller according to claim 1, characterized in that: Step 6) The entire calibration program code verification process uses the HSM module. The custom key and AES-128 algorithm are used to calculate the CMAC9 value when the boot loader code is burned for the first time at the factory. The CMAC9 value is stored in the DFLASH of the HSM. The same algorithm and custom key are used to calculate CMAC10 each time the system is started. It is determined whether the CMAC9 and CMAC10 values ​​are the same. If they are different, the CMAC9 and CMAC10 values ​​are stored in the preset calibration program code failure log S3. If they are the same, the MCU starts successfully.

8. The control method for secure startup verification and diagnosis of an MCU controller according to claim 6, characterized in that: The calibration program code failure log S3 in step 6) is the entire log of the calibration program code verification process, and is stored in the DFLASH fixed address of HSMCMAC. The cause of the failure can be exported and analyzed through the debugger; the CMAC9 and CMAC10 values ​​involved in the comparison are assigned to parameter X3, which can be accessed and read through the UDS-22 service by after-sales service.

Images