Control method for mcu controller security start verification and diagnosis

Abstract

The application discloses a control method for MCU controller safe starting verification and diagnosis, comprising the following steps: 1) presetting parameters S1, S2 and S3 in NVM; 2) predefining parameters X1, X2 and X3 which can be accessed by reading data 22 service through UDS; 3) verifying all starting codes; 4) verifying all boot loader codes; 5) verifying application program codes by using random segment extraction mode; and 6) verifying all calibration program codes, and storing failure logs in the preset S1, S2 and S3 if the verification fails; and if the verification succeeds, the MCU starts successfully. The application can guarantee the safe starting of the vehicle MCU controller and provide accurate diagnosis information for vehicle after-sales maintenance by using the MCU control unit to verify and diagnose the starting code, the boot loader code, the application program code and the calibration program code.

Description

TECHNICAL FIELD

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

[0002] With the rapid development of the automobile industry, the risks and threats suffered by automobiles have also increased, and network attack events targeting vehicles have been emerging everywhere. Nowadays, vehicle network security is no longer only related to individual road users, but also affects social, national and even global security. New energy has become an inevitable trend in the future automotive field, and MCU, as the core electronic controller of new energy vehicles, is vulnerable to network attacks, leading to a high probability of safety accidents. Therefore, it is crucial to verify the authenticity and accuracy of MCU code. Currently, most MCU startup verification uses HSM hardware modules to verify the authenticity of the code, ensuring 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, which cannot improve the robustness of the MCU controller software, and the software iteration speed cannot keep up with the upgrade, resulting in continuous tampering of the program; second, after-sales maintenance is difficult, and generally returns to the MCU controller supplier for analysis, increasing the cost of after-sales maintenance and customer complaints. SUMMARY

[0003] The present application provides a control method for MCU controller security startup verification and diagnosis, which can ensure the safe startup of the vehicle MCU controller and provide accurate diagnostic information for vehicle after-sales maintenance by verifying and diagnosing the startup code, bootloader code, application program code, and calibration program code using the MCU control unit.

[0004] The technical solution to solve the above problems is as follows:

[0005] A control method for MCU controller security startup verification and diagnosis, comprising the following steps:

[0006] Step 1) presetting the parameter bootloader code verification failure log S1, application program verification failure log S2, and calibration program code failure log S3 stored in NVM;

[0007] Step 2) predefining the bootloader code verification failure before and after parameter X1, the application program verification failure before and after parameter X2, and the calibration program code verification failure before and after parameter X3 accessible through the UDS read data 22 service;

[0008] Step 3) all of the boot code is checked, if the check fails, the failure log is stored in the HSM module DFLASH fixed address segment, the value of the part is read through the debugger, and the program is confirmed to stop in the address segment of the HSM module; if the check is successful, step 4) is entered;

[0009] Step 4) all of the boot loader code is checked, if the check fails, the failure log is stored in the pre-set boot loader code check failure log S1, the parameters X1 before and after the boot loader code check failure are accessed through the UDS-22 service, and the program stops in the address segment of the boot code; if the check is successful, step 5) is entered;

[0010] Step 5) the application program code is checked in a random segment extraction manner, if the check fails, the failure log is stored in the pre-set application program check failure log S2, the parameters X2 before and after the application program check failure are accessed through the UDS-22 service, and the program stops in the boot loader; if the check is successful, step 6 is entered;

[0011] Step 6) all of the calibration program code is checked, if the check fails, the failure log is stored in the pre-set calibration program code failure log S3, the parameters X3 before and after the calibration program code check failure are accessed through the UDS-22 service, and the program stops in the boot loader; if the check is successful, the MCU starts successfully.

[0012] The beneficial technical effects of the present application are:

[0013] 1. The MCU control unit is used to check the security boot code, the boot loader code, the application program code and the calibration program code in sequence, so that the code is ensured not to be tampered with and damaged, and the safety of the user is protected.

[0014] 2. When the security boot code, the boot loader code, the application program code and the calibration program code fail to be checked, the process check logs are all stored in the DFLASH of the HSM, the safety is not lost, and the failure logs can be obtained by reading the DID.

[0015] 3. The MCU code is checked in a hierarchical manner, the specific security boot failure position can be locked, software improvement is facilitated, after-sales personnel can be facilitated to maintain, after-sales cost is reduced, maintenance efficiency is improved, and customer complaint rate is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is the main control flowchart of the present application.

[0017] Figure 2 is the application program code check flowchart of the present application. DETAILED DESCRIPTION

[0018] As shown in Figure 1 and Figure 2 The MCU controller safe start verification and diagnosis control method of the application comprises the following steps:

[0019] Step 1) presetting the parameter bootloader code verification failure log S1, application program verification failure log S2 and calibration program code failure log S3 stored in NVM (NVM is a non-volatile memory).

[0020] Preferably, the storage size of the bootloader code verification failure log parameter S1 stored in NVM is 64 bytes, the storage size of the application program verification failure log S2 is 256 bytes, and the storage size of the calibration program code failure log S3 is 128 bytes.

[0021] Step 2) predefining bootloader code verification failure before and after parameters X1, application program verification failure before and after parameters X2 and calibration program code verification failure before and after parameters X3 accessible through the read data 22 service of UDS. UDS (Unified Diagnostic Services) is a diagnostic protocol widely used in the automotive industry.

[0022] Preferably, the storage size of the bootloader code verification failure before and after parameters X1 accessible through the read data 22 service of UDS is 66 bytes, the storage size of the application program verification failure before and after parameters X2 is 66 bytes, and the storage size of the calibration program code verification failure before and after parameters X3 is 66 bytes.

[0023] Step 3) checking all start codes, if the verification fails, storing the failure log in the HSM module (hardware security module (English: hardware security module, abbreviation HSM)) DFLASH (DFLASH is a technology for managing and accessing flash memory through a distributed architecture) fixed address segment, reading the value of this part through the debugger, confirming that the program stops in the address segment of the HSM module; the range of the address segment is 0x800XXXXX-0x800XXXXX, if the verification is successful, go to step 4).

[0024] Preferably, the process of checking the whole boot code in step 3) adopts the HSM module, calculates the CMAC1 value (CMAC1 represents symmetric key message authentication code, the meaning of CMAC2 to CMAC10 in the following is also symmetric key message authentication code) of the first time of burning the boot code in the factory by the chip self-owned key through the AES-128 algorithm, stores the CMAC1 value into the DFLASH fixed address of the HSM module, calculates the CMAC2 value by using the same algorithm and the chip self-owned key every time of starting, judges whether the CMAC1 value and the CMAC2 value are the same, if not, stores the CMAC1 value and the CMAC2 value into the DFLASH fixed address of the HSM module, if yes, enters step 4).

[0025] The chip self-owned key has a key length of 16 Byte, is written into the key for each chip in the factory, and is read by the MCU control through the HSM function port to calculate and check the secure boot code. The AES-128 algorithm is one of the most widely used key science standards, and the generation and decryption rules of the key are quite clear and easy to accept and understand.

[0026] The CMAC1 value and the CMAC2 value after failure are stored into the DFLASH of the HSM starting from the address of 0xAF00XXXX, and the size is 66 Byte address segment, and the code of this part can be exported through the debugger to analyze the failure reason.

[0027] Step 4) checks the whole boot loader code, if the checking fails, stores the failure log into the pre-set boot loader code checking failure log S1, accesses the boot loader code checking failure parameters X1 before and after through the UDS-22 service, and the program stops in the address segment of the boot code; if the checking succeeds, enters step 5).

[0028] Preferably, the process of checking the whole boot loader code in step 4) adopts the HSM module, calculates the CMAC3 value of the first time of burning the boot loader code in the factory by the chip self-owned key through the AES-128 algorithm, stores the CMAC3 value into the DFLASH of the HSM module, calculates the CMAC4 value by using the same algorithm and the chip self-owned key every time of starting, judges whether the CMAC3 value and the CMAC3 value are the same, if not, stores the CMAC3 value and the CMAC4 value into the pre-set boot loader code checking failure log S1, if yes, enters step 5).

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

[0030] Preferably, the boot loader code verification failure log S1 in step 4) is the complete log of the boot loader code verification process, and is stored in the DFLASH of the HSM in the fixed address, and the failure reason can be exported and analyzed by the debugger; the values of CMAC3 and CMAC4 participating in the comparison are assigned to parameter X1, and the failure information can be obtained by reading parameter X1 through UDS-22 service access after sale.

[0031] In step 5), the application code is verified by random segment extraction, and if the verification fails, the failure log is stored in the pre-set application verification failure log S2, which can be obtained by accessing parameter X2 before and after the application verification failure through UDS-22 service, and the program stops in the boot loader; if the verification is successful, step 6 is entered.

[0032] Preferably, in step 5), the application code is verified by random segment extraction, and the application code is randomly divided into three segments, and each time a segment is extracted by a random function for verification, which can save the initialization time, and the process of verification is performed by the HSM module, and the values of 3 segments CMAC5, CMAC6 and CMAC7 of the application code are calculated by a self-defined key according to the AES-128 algorithm when the application code is first burned in the factory, and are stored in the DFLASH of the HSM module, and each time a segment is extracted randomly for verification using the same algorithm and self-defined key, and it is judged whether the CMAC5, CMAC6 and CMAC7 of the randomly extracted segment and the CMAC8 of the same segment are the same, if they are different, the CMAC5, CMAC6 and CMAC7 of the randomly extracted segment and the CMAC8 value are stored in the pre-set application verification failure log S2, if they are the same, step 6 is entered.

[0033] The size of the self-defined key is 16 bytes, which is set according to the vehicle model equipped with the MCU, and is prevented from being tampered with, and the self-defined key is pre-stored in the DFLASH of the HSM.

[0034] The application verification failure log S2 is the complete log of the application verification process, and is stored in the DFLASH of the HSM starting at 0xAF0BXXXX address with a size of 256 bytes in the fixed address segment, and the failure reason can be exported and analyzed by the debugger.

[0035] Preferably, the application program check failure log S2 in step 5) is the whole log of the application program check process, and is stored in the DFLASH fixed address of the HSM, and the failure reason can be exported and analyzed through the debugger; the CMAC5, CMAC6, CMAC7 and CMAC8 values participating in comparison are assigned to the parameter X2, and the after-sales can access and read the parameter X2 to obtain the failure information through the UDS-22 service.

[0036] Step 6) checks the whole calibration program code, if the check fails, the failure log is stored in the pre-set calibration program code failure log S3, and the parameter X3 before and after the calibration program code check failure is obtained through the UDS-22 service access, and the program is stopped in the boot loader; if the check succeeds, the MCU starts successfully.

[0037] Preferably, the process of step 6) that the whole calibration program code is checked adopts the HSM module, the CMAC9 value when the boot loader code is first burned in the factory is calculated through the self-defined key and the AES-128 algorithm, the CMAC9 value is stored in the DFLASH of the HSM, the CMAC10 is calculated by using the same algorithm and the self-defined key every time the MCU starts, and it is judged whether the CMAC9 and the CMAC10 values are the same; if not, the CMAC9 and the CMAC10 values are stored in the pre-set calibration program code failure log S3, and if the same, the MCU starts successfully.

[0038] The calibration program code failure log S3 is the whole log of the calibration program code check process, and is stored in the DFLASH of the HSM, starts from the 0xAF0CXXXX address, and the size is 128Byte fixed address segment, and the failure reason can be exported and analyzed through the debugger.

[0039] Preferably, the calibration program code failure log S3 in step 6) is the whole log of the calibration program code check process, and is stored in the DFLASH fixed address of the HSM CMAC, and the failure reason can be exported and analyzed through the debugger; the CMAC9 and the CMAC10 values participating in comparison are assigned to the parameter X3, and the after-sales can access and read the parameter X3 to obtain the failure information through the UDS-22 service.

[0040] The application can guarantee that the whole vehicle MCU controller starts safely, and can provide accurate diagnostic information for the whole vehicle after-sales maintenance by adopting the MCU control unit to check and diagnose the control design of the start code, the boot loader code, the application program code and the calibration program code.

[0041] The above described examples are only some embodiments of the present application, but not all the embodiments. Based on the examples in the present application, all the other embodiments obtained by those skilled in the art without making creative labor are within the protection scope of the present application.

Claims

1. A control method for safe startup verification and diagnosis of an MCU controller, characterized in that, Includes the following steps: Step 1) Preset the parameters stored in NVM: bootloader code verification failure log S1, application verification failure log S2, and calibration program code failure log S3; Step 2) Predefine the parameters X1 before and after the bootloader code verification failure, the parameters X2 before and after the application verification failure, and the parameters X3 before and after the calibration program code verification failure that can be accessed through the UDS data reading service 22. Step 3) Verify the entire startup code. If the verification fails, store the failure log in the fixed address segment of the HSM module's DFLASH. Read the value of this part using a debugger to confirm that the program is stopped in the address segment of the HSM module. If the verification succeeds, proceed to step 4). Step 4) Verify all bootloader code. If verification fails, store the failure log in the pre-set bootloader code verification failure log S1. Access the parameters X1 before and after the bootloader code verification failure via the UDS-22 service. The program will stop at the address segment of the startup code. If verification succeeds, proceed to step 5). Step 5) The application code is verified by random segmentation. 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 obtained through the UDS-22 service. The program stops in the bootloader. If the verification is successful, proceed to step 6; Step 6) Verify all calibration program code. If the verification fails, store the failure log in the pre-set calibration program code failure log S3. Obtain the parameters before and after the calibration program code verification failure X3 through the UDS-22 service access parameters. The program stops in the bootloader. If the verification is successful, the MCU will start successfully.

2. The control method for safe startup verification and diagnosis of MCU controller according to claim 1, characterized in that: Step 3) The process of verifying the entire boot code is performed using the HSM module. Using the chip's built-in key, the CMAC1 value is calculated using the AES-128 algorithm during the first boot code programming at the factory. This CMAC1 value is stored in a fixed address in the HSM module's DFLASH memory. Each boot uses the same algorithm and the chip's built-in key to calculate CMAC2. The CMAC1 and CMAC2 values ​​are then compared. If they are different, both CMAC1 and CMAC2 values ​​are stored in the fixed address in the HSM module's DFLASH memory. If they are the same, proceed to step 4.

3. The control method for safe startup verification and diagnosis of MCU controller according to claim 1, characterized in that: Step 4) The process of verifying the entire bootloader code is performed using the HSM module. Using the chip's built-in key, the CMAC3 value is calculated using the AES-128 algorithm when the bootloader code is first burned at the factory. This CMAC3 value is stored in the HSM module's DFLASH. Each time the program boots, the same algorithm and the chip's built-in key are used to calculate CMAC4. The CMAC3 and CMAC4 values ​​are compared. If they are different, both CMAC3 and CMAC4 values ​​are stored in the pre-set bootloader code verification failure log S1. If they are the same, proceed to step 5.

4. The control method for safe startup verification and diagnosis of MCU controller according to claim 3, characterized in that: Step 4) Bootloader code verification failure log S1 is the complete log of the bootloader code verification process and is stored in the fixed address of HSM's DFLASH. It can be exported and analyzed through the debugger to find the cause of failure. The values ​​of CMAC3 and CMAC4, which are 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 safe startup verification and diagnosis of MCU controller according to claim 1, characterized in that: In step 5), the application code is verified using a random segmentation method. The application code is randomly divided into three segments, and each time it starts, a segment is randomly selected for verification using a random function. This saves startup initialization time. The verification process uses the HSM module. Using a custom key, the values ​​of the three segments CMAC5, CMAC6, and CMAC7, which were first burned into the application code at the factory, are calculated according to the AES-128 algorithm and stored in the DFLASH of the HSM module. Each time it starts, the same algorithm and custom key are used to randomly select a segment for verification. The CMAC5, CMAC6, and CMAC7 of the randomly selected segment are compared with the CMAC8 of the same segment. If they are different, one of the randomly selected CMAC5, CMAC6, and CMAC7 and the CMAC8 value are stored in the pre-set application verification failure log S2. If they are the same, proceed to step 6).

6. The control method for safe startup verification and diagnosis of MCU controller according to claim 5, characterized in that: The application verification failure log S2 in step 5) is the complete log of the application verification process and is stored in the fixed address of the HSM's DFLASH. It can be exported and analyzed through the debugger to find the cause of the failure. The values ​​of CMAC5, CMAC6, CMAC7 and CMAC8 that are 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 the failure information.

7. The control method for safe startup verification and diagnosis of MCU controller according to claim 1, characterized in that: Step 6) The process of verifying all calibration program code is carried out using the HSM module. Using a custom key, the CMAC9 value is calculated using the AES-128 algorithm when the bootloader program code is first burned at the factory. The CMAC9 value is stored in the DFLASH of the HSM. Each time it starts, the same algorithm and custom key are used to calculate CMAC10. It is then determined whether the CMAC9 and CMAC10 values ​​are the same. If they are different, both CMAC9 and CMAC10 values ​​are stored in the pre-set calibration program code failure log S3. If they are the same, the MCU starts successfully.

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

Images