A vehicle-mounted ECU safe startup system and method

Abstract

The present invention relates to a vehicle-mounted ECU safe startup system and method, belonging to the field of vehicle safety technology. The system includes a main chip, a security chip, and a memory, and also includes a compiler for processing an application to be started into blocks to obtain a first block program and a second block program; wherein the memory stores the application to be started and the boot program corresponding to the application to be started; the main chip is used to start the boot program; the security chip is used to verify the security of the first block program after the main chip starts the boot program; the main chip is also used to verify the integrity of the second block program while the security chip verifies the security of the first block program. The present invention divides the application into blocks, so that when the security chip verifies a part of the application block, the main chip simultaneously verifies another part of the application block, thereby shortening the verification time and improving the user experience.

Description

Technical Field

[0001] The present invention relates to the field of vehicle safety technology, and in particular to a vehicle-mounted ECU safety starting system and method. Background Art

[0002] As in-vehicle controllers add more and more functions, applications are becoming larger and larger.

[0003] In existing technology, the controller uses a security chip to verify the integrity and authenticity of the bootloader and application. The main chip waits for the security chip to complete the verification before deciding whether to run the application. The security algorithm and key are stored in the security chip. The data verified by the security chip ensures integrity and authenticity. The main chip is a general-purpose computing chip, and its encryption and decryption capabilities are far inferior to those of the security chip. Even if it participates in encryption and decryption operations, it often cannot meet requirements. If the application is large, the security chip may take too long to verify the signature, potentially failing to meet customer requirements, such as sending the first frame within 200ms after power-up. Because the main chip cannot read the key, it remains in a waiting state during the security chip verification and is not involved in the operation.

[0004] In summary, when the existing main chip verifies the application, it needs to wait for the security chip to complete the verification before continuing the verification, resulting in a long verification time and a poor user experience. Summary of the Invention

[0005] In view of this, it is necessary to provide a vehicle-mounted ECU safe startup system, method and terminal device to solve the problems of long verification time and poor user experience caused by the sequential verification of the security chip and the main chip.

[0006] In order to solve the above problems, the present invention provides a vehicle-mounted ECU safe startup system, including a main chip, a safety chip and a memory, and also includes:

[0007] A compiler, configured to process the application program to be started into blocks to obtain a first block program and a second block program;

[0008] The memory stores an application to be started and a boot program corresponding to the application to be started;

[0009] The main chip is used to start the boot program;

[0010] The security chip is used to check the security of the first block program after the main chip starts the boot program;

[0011] The main chip is further used to verify the integrity of the second block program while the security chip verifies the security of the first block program.

[0012] In one possible implementation, the compiler is further used to obtain the power-on time required for the security chip and the data size of the application, and divide the application to be started into a first block program and a second block program based on the power-on time required and the data size of the application to be started.

[0013] In a possible implementation, the security chip is further configured to verify the integrity and legitimacy of the boot program before the main chip starts the boot program.

[0014] In a possible implementation, the main chip is further configured to control the boot program to start the application to be started when the boot program determines that the security chip successfully verifies the security of the first block program and the main chip successfully verifies the integrity of the second block program.

[0015] On the other hand, the present invention further provides a vehicle-mounted ECU safe startup method, which is applied to a vehicle-mounted ECU safe startup system described in any one of the above implementations, and the method includes:

[0016] The compiler divides the application program to be started into blocks to obtain a first block program and a second block program;

[0017] The main chip starts the boot program;

[0018] The security chip verifies the security of the first block program after the main chip starts the boot program, wherein the boot program is a boot program corresponding to the application program to be started stored in the memory;

[0019] The main chip verifies the integrity of the second block program while the security chip verifies the security of the first block program.

[0020] In a possible implementation, the compiler divides the application program to be started into blocks to obtain a first block program and a second block program, including:

[0021] The compiler obtains the power-on time required for the security chip and the data size of the application program;

[0022] The compiler divides the application program to be started into a first block program and a second block program based on the power-on time required and the data size of the application program.

[0023] In a possible implementation, the security chip verifies the security of the first block program after the main chip starts the boot program, including:

[0024] The security chip checks the security of the first block program based on the AES-128-CMAC algorithm after the main chip starts the boot program.

[0025] In a possible implementation, the main chip verifies the integrity of the second block program while the security chip verifies the security of the first block program, including:

[0026] The main chip verifies the integrity of the second block program based on the CRC-32 algorithm while the security chip verifies the security of the first block program.

[0027] In a possible implementation, the security chip verifies the security of the first block program after the main chip starts the boot program, including:

[0028] When the security chip verifies the first block program, there is a target block that fails verification. The target block that fails verification is recorded, and the security of the target block that fails verification is checked after each system restart until the security verification of the target block that fails verification is successful.

[0029] In a possible implementation, the main chip verifies the integrity of the second block program based on the CRC-32 algorithm while the security chip verifies the security of the first block program, including:

[0030] The main chip obtains a verification code for verifying the second block program based on a CRC-32 algorithm;

[0031] Comparing the verification code with a preset verification code;

[0032] If the verification code is consistent with the preset verification code, the second block program is determined to be complete;

[0033] If the verification code is inconsistent with the preset verification code, it is determined that the second block program is incomplete.

[0034] The beneficial effects of the present invention are as follows: the present invention provides an on-vehicle ECU safety startup system, comprising a main chip, a safety chip and a memory, and also comprising a compiler, which is used to process the application to be started in blocks to obtain a first block program and a second block program, so that the main chip and the safety chip can verify the application at the same time, the memory stores the application to be started and the boot program corresponding to the application to be started, the main chip is used to start the boot program, the boot program is used to guide the application to start, the safety chip is used to verify the security of the first block program after the main chip starts the boot program, thereby ensuring that the application cannot be started if it is maliciously tampered with, and the main chip is also used to verify the integrity of the second block program while the security chip verifies the security of the first block program. The present invention divides the application into blocks, so that when the security chip verifies a part of the application block, the main chip verifies another part of the application block at the same time, thereby shortening the verification time and improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a system architecture diagram of an embodiment of a vehicle-mounted ECU safety startup system provided by the present invention;

[0036] Figure 2 A flowchart of an implementation method of a vehicle-mounted ECU safe startup method provided by the present invention;

[0037] Figure 3 For the present invention Figure 1 A flow chart of an embodiment of S201 is shown in FIG. DETAILED DESCRIPTION

[0038] The following will provide a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0039] In the description of the embodiments of the present application, unless otherwise specified, “plurality” means two or more.

[0040] The terms "including" and "having" and any variations thereof in the embodiments of the present invention are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product or device comprising a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products or devices.

[0041] The naming or numbering of the steps in the embodiments of the present invention does not mean that the steps in the method flow must be executed in the time / logical sequence indicated by the naming or numbering. The execution order of the named or numbered process steps can be changed according to the technical purpose to be achieved, as long as the same or similar technical effects can be achieved.

[0042] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute a separate or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0043] Example 1:

[0044] The present invention provides a vehicle-mounted ECU safe starting system, method and terminal device, which are described below respectively.

[0045] Figure 1 This is a system architecture diagram of an embodiment of a vehicle-mounted ECU safety startup system provided by the present invention, as shown in FIG. Figure 1 As shown, a secure boot system 100 includes a main chip 103, a security chip 104 and a memory 102, and further includes:

[0046] The compiler 101 is used to process the application program to be started into blocks to obtain a first block program and a second block program;

[0047] The memory 102 stores the application to be started and the boot program corresponding to the application to be started;

[0048] The main chip 103 is used to start the boot program;

[0049] The security chip 104 is used to check the security of the first block program after the main chip 103 starts the boot program;

[0050] The main chip 103 is further configured to verify the integrity of the second segmented program while the security chip 104 verifies the security of the first segmented program.

[0051] Compared with the prior art, this embodiment provides an on-vehicle ECU security boot system, including a main chip, a security chip and a memory, and also includes a compiler, which is used to divide the application to be started into blocks to obtain a first block program and a second block program, so that the main chip and the security chip can verify the application at the same time. The memory stores the application to be started and the boot program corresponding to the application to be started. The main chip is used to start the boot program, and the boot program is used to guide the application to start. The security chip is used to verify the security of the first block program after the main chip starts the boot program, thereby ensuring that the application cannot be started if it is maliciously tampered with. The main chip is also used to verify the integrity of the second block program while the security chip verifies the security of the first block program.

[0052] The present invention divides the application into blocks so that when the security chip verifies a part of the application blocks, the main chip verifies another part of the application blocks at the same time, thereby shortening the verification time and improving the user experience.

[0053] In this embodiment, the main chip and security chip operate in parallel. During the compilation phase, the application is divided into multiple blocks based on power-up time requirements and the size of the application data to be verified. The security chip then randomly selects some application blocks for message authentication verification using an encryption algorithm to prevent malicious tampering, while the main chip performs integrity signature verification on the remaining blocks. Since all application blocks are integrity-verified, storage failures can be prevented. The security chip's verification of randomly selected blocks prevents tampering with the application, ensuring that the entire system meets the requirements for secure boot and time control.

[0054] It's important to note that the automotive ECU (Electronic Control Unit), also known as the "brain of the vehicle," can be simply described as "collecting sensor signals, communicating with other controllers, and controlling corresponding actuators." It's a complex combination of software and hardware. This hardware includes engine controllers, motor controllers, and vehicle controllers.

[0055] From the software perspective, automotive ECU software can be divided into three parts: application layer software (Application Software, ASW), basic software (Basic Software, BSW) and bootloader (Bootloader).

[0056] Application-layer software typically consists of a number of "modules" or "units," referred to as "software components" (SWCs). Software components are not only the core of application-layer software but also the vehicle for underlying software implementation. By combining several software components and leveraging their respective functions, a relatively complete application-layer software package can be constructed. Software components interact with each other through ports. Each software component contains several runnable entities (Runnable Entities) that encapsulate control algorithms. These can be triggered by runtime environment events (RTE events), enabling precise vehicle control under various driving conditions and application scenarios through complex control logic algorithms.

[0057] Under the AUTOSAR (AUTomotive Open System ARchitecture), a globally recognized automotive embedded software architecture, the underlying software is abstracted and divided into three layers: the service layer, the ECU abstraction layer, and the microcontroller abstraction layer. From a functional perspective:

[0058] Service layer: diagnosis, memory management, operating system, communication, ECU management;

[0059] ECU abstraction layer: drivers of external devices on the ECU board, interfaces between internal and external devices (I / O);

[0060] Microcontroller abstraction layer: drivers for internal peripherals in the MCU (Microcontroller Unit) and drivers for external devices that use the MCU memory map.

[0061] A bootloader, or bootloader, is the first program code that runs after a system is powered on or reset. Its primary function is to adjust the system's hardware and software environment to a suitable state, preparing for the final invocation of application programs and the entry of software. Specifically, the bootloader serves as the intermediate interface between the underlying hardware and upper-layer application software. In automotive ECUs, the bootloader is a standalone program that begins execution at power-up. It downloads application software to the ECU via a diagnostic communication link. This download capability is crucial for reprogramming ECUs during development, production, and service.

[0062] In some embodiments of the present invention, the first block program includes a plurality of first block subprograms of relatively even size, the second block program includes a plurality of second block subprograms of relatively even size, and the sizes of any first block subprogram and any second block subprogram are relatively even. This ensures that the security chip verifies each first block subprogram in the first block program at a relatively consistent time, and the main chip verifies each second block subprogram in the second block program at a relatively consistent time. It should be noted that, for example, when the security chip selects the AES-128-CMAC algorithm to verify the first block program, the performance of this algorithm is 60MB / S. The security chip needs to send the first frame message within 200ms after power-on. The time from running the verification boot program plus the application to sending the first frame message is 100ms. Therefore, the amount of data that the security chip can verify is 60*((200-100) / 1000) = 6 MB. Then, if the first block program is divided into 10 blocks, the size of each first block subroutine is 6 / 10=0.6, that is, the size of each subroutine is kept relatively balanced.

[0063] In a specific embodiment of the present invention, the compiler divides the application to be started into N blocks during linking, and the sizes of the blocks are relatively balanced so that the verification time is relatively consistent.

[0064] In some embodiments of the present invention, the compiler 101 is further used to obtain the power-on time required for the security chip 104 and the data size of the application, and divide the application into a first block program and a second block program based on the power-on time required and the data size of the application to be started.

[0065] In a specific embodiment of the present invention, the security chip 104 is further configured to verify the integrity and legitimacy of the bootloader before the main chip initiates the bootloader. In this specific embodiment, after power-on, the security chip verifies the integrity and authenticity of the bootloader. If the message authentication code (MAC) matches a preset MAC, the security chip verifies that the verification has passed, and the main core initiates the bootloader.

[0066] In some embodiments of the present invention, the main chip 103 is also used to control the boot program to start the application to be started when the boot program determines that the security chip 104 has successfully verified the security of the first block program and the main chip 103 has successfully verified the integrity of the second block program.

[0067] In a specific embodiment of the present invention, the security chip randomly selects a portion of the N blocks of an application, performs verification based on the actual algorithm performance and time requirements, and uses a key for calculation, making it difficult for an attacker to forge a hash value.

[0068] The main chip runs the Bootloader to verify the remaining blocks of the application. The main chip cannot obtain the key and only performs integrity verification to ensure that there are no storage errors.

[0069] After the security chip and the main chip are all verified and passed, the bootloader jumps to the application and starts normally.

[0070] If the security chip or main chip fails to verify a block, this block will be recorded and the system will be restarted to verify again. The block that failed verification will continue to be verified by the security chip at each subsequent startup until it succeeds J times in a row.

[0071] This embodiment uses the security chip and the main chip to perform verification in parallel, reducing startup verification time and meeting the requirement for rapid startup. Furthermore, because the security chip randomly selects application blocks for verification, maliciously tampered software cannot be started. Furthermore, integrity verification is performed on all application blocks, preventing storage failures caused by bit flipping and other issues.

[0072] On the other hand, the present invention also provides a vehicle-mounted ECU safe startup method, which is applied to a vehicle-mounted ECU safe startup system described in any one of the above implementations, such as Figure 2 As shown, the method includes:

[0073] S201, the compiler divides the application program to be started into blocks to obtain a first block program and a second block program;

[0074] S202, the main chip starts the boot program;

[0075] S203: After the main chip starts a boot program, the security chip verifies the security of the first block program, where the boot program is a boot program corresponding to the application program to be started and stored in the memory;

[0076] S204 . The main chip verifies the integrity of the second block program while the security chip verifies the security of the first block program.

[0077] In some embodiments of the present invention, in step S201, the compiler divides the application program to be started into blocks to obtain a first block program and a second block program, including:

[0078] S301, the compiler obtains the power-on time required for the security chip and the data size of the application to be started;

[0079] S302 : The compiler divides the application to be started into a first block program and a second block program based on the power-on time required and the data size of the application to be started.

[0080] In a specific embodiment of the present invention, the compiler divides the application into n blocks, the security chip randomly selects m blocks that meet the time requirements, namely the first block program for verification, and the main chip verifies the remaining nm blocks, namely the second block program, where n and m represent positive integers.

[0081] It's important to note that the AES-128-CMAC algorithm is a block-cipher-based message authentication code (MAC) algorithm that uses the AES encryption algorithm and a 128-bit key. The primary purpose of this algorithm is to provide message integrity and authentication. The following are the basic steps of the AES-128-CMAC algorithm:

[0082] 1. Key generation: Use a 128-bit key and the AES algorithm to generate two subkeys K1 and K2.

[0083] 2. Initialization Vector: Set an initial vector (IV), usually a block of all zeros.

[0084] 3. Chunking: Divide the message into fixed-size chunks (if the last chunk is insufficient, padding is performed).

[0085] 4. Cyclic encryption: Apply AES encryption to each block, perform an XOR operation on the encrypted result of the previous block and the current block before encrypting it.

[0086] 5. Final block processing: Apply different processing to the last block. If the last block is complete, it is XORed with K1; if it is incomplete, it is filled first and then XORed with K2.

[0087] 6. Generate MAC: Apply AES encryption to the last processed block, and the result is the CMAC value of the message.

[0088] In some embodiments of the present invention, the security chip verifies the security of the first block program after the main chip starts the boot program, including:

[0089] The security chip checks the security of the first block program based on the AES-128-CMAC algorithm after the main chip starts the boot program.

[0090] It's important to note that a cyclic redundancy check (CRC) is an algorithm used to detect errors during data transmission or storage. It applies a specific polynomial to the data to generate a short, fixed-length checksum, which is typically appended to the data. The receiver verifies the integrity of the data by performing the same calculation on the received data (including the checksum). If the calculated result matches the received checksum, the data is considered intact. If not, it indicates that an error may have occurred during data transmission or storage.

[0091] The basic steps of the CRC algorithm are as follows:

[0092] Choose the right polynomial: The core of the CRC algorithm is a polynomial, which defines how to calculate the checksum. This polynomial is usually expressed as a binary number. For example, the polynomial used by CRC-16 is:

[0093] x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1

[0094] Initialization: Treat the data as a long binary number and append the same number of zeros as the number of bits in the polynomial. For example, if using CRC-16, append 16 zeros to the data.

[0095] Modulo 2 division: Use the polynomial to perform modulo 2 division on the binary number obtained in the previous step. This division is similar to normal division, but without the carry.

[0096] Get the check code: The remainder of the modulo-2 division is the CRC check code. This check code will be appended to the end of the original data.

[0097] Verification: After receiving the data, the receiver performs modulo-2 division on the entire data string, including the checksum, using the same polynomial again. If the remainder is zero, the data is considered to be error-free.

[0098] In some embodiments of the present invention, the main chip verifies the integrity of the second block program while the security chip verifies the security of the first block program, including:

[0099] The main chip verifies the integrity of the second block program based on the CRC-32 algorithm while the security chip verifies the security of the first block program.

[0100] In some embodiments of the present invention, the security chip verifies the security of the first block program after the main chip starts the boot program, including:

[0101] When the security chip verifies the first block program, there is a target block that fails verification. The target block that fails verification is recorded, and the security of the target block that fails verification is checked after each system restart until the security verification of the target block that fails verification is successful.

[0102] In some embodiments of the present invention, the main chip verifies the integrity of the second block program based on the CRC-32 algorithm while the security chip verifies the security of the first block program, including:

[0103] The main chip obtains a verification code for verifying the second block program based on a CRC-32 algorithm;

[0104] Comparing the verification code with a preset verification code;

[0105] If the verification code is consistent with the preset verification code, the second block program is determined to be complete;

[0106] If the verification code is inconsistent with the preset verification code, it is determined that the second block program is incomplete.

[0107] In a specific embodiment of the present invention, the specific process of interaction between the security chip and the main chip is as follows:

[0108] The security chip reads the message authentication code of the boot program in the memory, and when it is determined that the message authentication code is the same as the preset message authentication code, generates a first identifier for authentication, and writes the first identifier into the register;

[0109] The main chip reads the first identifier and starts the boot program. After determining that the boot program is started, the main chip stores a startup completion identifier in a register.

[0110] The security chip reads the startup completion flag and performs a security check on the first block program in the memory. At the same time, it generates a check start flag and writes the check start flag into the register. The main chip reads the check start flag and performs a CRC check on the second block program.

[0111] When the boot program determines that the security chip successfully verifies the security of the first block program and the main chip successfully verifies the integrity of the second block program, the main chip controls the boot program to start the application program.

[0112] In this embodiment, the security chip and the main chip each run their own firmware code. The security chip then verifies the bootloader, and the main chip waits for the security chip to complete verification before launching the bootloader. The security chip then verifies some application blocks while the main chip verifies other application blocks, shortening verification time and improving the user experience.

[0113] Example 2:

[0114] It uses Infineon Aurix 3xx series chips, HSM as the security chip, and Tricore as the main chip.

[0115] After power-on, the HSM and Tricore run their respective firmware codes. The Tricore waits for the HSM to verify the Bootloader result. The HSM uses the AES-128-CMAC algorithm for verification.

[0116] The HSM verifies the Bootloader's message authentication code (MAC). If the MAC matches the expected value, the Tricore starts running the Bootloader. If the MAC does not match the expected value, the boot fails.

[0117] The HSM verifies that the Bootloader's message authentication code (MAC) matches the expected value and then continues to verify the Application.

[0118] Assume the security chip uses the AES-128-CMAC algorithm, which has a performance of 60 MB / s. The first frame of the message must be sent within 200 ms after power-on. The time from bootloader verification and application execution to sending the first frame of the message is 100 ms. Therefore, the amount of data that the HSM can verify is 60 * (200 - 100) / 1000) = 6 MB.

[0119] The HSM randomly selects n blocks from the application and performs security verification using the AES-128-CMAC algorithm. The total size of the n blocks must be less than 6MB, where n is a positive integer.

[0120] Tricore performs CRC check on the rest of the application. The performance of the CRC-32 algorithm is about 1000MB / s. 60*((200-100) / 1000) = 100 MB, which is much larger than the storage space of the TC3xx series.

[0121] If the checksums of each block by HSM and Tricore are consistent with expectations, the application starts executing; otherwise, the startup fails.

[0122] If a block fails verification, the block is marked and the system is restarted for verification. The marked block must be verified by the security chip every time it is started, until J consecutive verifications are successful and the block is unmarked.

[0123] This embodiment uses the security chip and the main chip to perform verification in parallel, reducing startup verification time and meeting the requirement for rapid startup. Furthermore, because the security chip randomly selects application blocks for verification, maliciously tampered software cannot be started. Furthermore, integrity verification is performed on all application blocks, preventing storage failures caused by bit flipping and other issues.

[0124] Those skilled in the art will appreciate that all or part of the process steps of the above-described embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, such as a magnetic disk, an optical disk, a read-only memory, or a random access memory.

[0125] The above are only preferred specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or replacements that can be easily thought of by any technician familiar with this technical field within the technical scope disclosed by the present invention should be covered by the scope of protection of the present invention.

Claims

1. A vehicle-mounted ECU safe startup system, comprising a main chip, a safety chip and a memory, characterized in that: Also includes: A compiler, configured to process the application program to be started into blocks to obtain a first block program and a second block program; The memory stores an application to be started and a boot program corresponding to the application to be started; Main chip, used to start the boot program; A security chip, used to verify the security of the first block program after the main chip starts the boot program; The main chip is further used to verify the integrity of the second block program while the security chip verifies the security of the first block program; The compiler is used to process the application to be started into blocks to obtain a first block program and a second block program, including: The compiler obtains the power-on time required for the security chip and the data size of the application; The compiler divides the application into a first block program and a second block program based on the power-on time required and the data size of the application program; After the main chip starts the boot program, the security chip verifies the security of the first block program, including: When the security chip verifies the first block program, there is a target block that fails verification. The target block that fails verification is recorded, and the security of the target block that fails verification is checked after each system restart until the security verification of the target block that fails verification is successful.

2. The vehicle-mounted ECU safety starting system according to claim 1, characterized in that: The first block program includes several first block subprograms with relatively balanced sizes, the second block program includes several second block subprograms with relatively balanced sizes, and the sizes of any first block subprogram and any second block subprogram are relatively balanced.

3. The vehicle-mounted ECU safety starting system according to claim 1, characterized in that: The compiler is further configured to obtain a power-on time required for the security chip and a data size of the application program, and divide the application program to be started into a first block program and a second block program based on the power-on time required and the data size of the application program.

4. The vehicle-mounted ECU safety starting system according to claim 1, characterized in that: The main chip is further configured to control the boot program to start the application to be started when the boot program determines that the security chip successfully verifies the security of the first block program and the main chip successfully verifies the integrity of the second block program.

5. A vehicle-mounted ECU safe startup method, applied to the vehicle-mounted ECU safe startup system according to any one of claims 1 to 4, characterized in that: The method comprises: The compiler divides the application program to be started into blocks to obtain a first block program and a second block program; The main chip starts the boot program; The security chip verifies the security of the first block program after the main chip starts the boot program, wherein the boot program is a boot program corresponding to the application program to be started stored in the memory; The main chip verifies the integrity of the second block program while the security chip verifies the security of the first block program; The compiler divides the application program to be started into blocks to obtain a first block program and a second block program, including: The compiler obtains the power-on time required for the security chip and the data size of the application program; The compiler divides the application into a first block program and a second block program based on the power-on time and the data size of the application program; The security chip verifies the security of the first block program after the main chip starts the boot program, including: When the security chip verifies the first block program, there is a target block that fails verification. The target block that fails verification is recorded, and the security of the target block that fails verification is checked after each system restart until the security verification of the target block that fails verification is successful.

6. The vehicle-mounted ECU safe startup method according to claim 5, characterized in that: The security chip verifies the security of the first block program after the main chip starts the boot program, including: The security chip checks the security of the first block program based on the AES-128-CMAC algorithm after the main chip starts the boot program.

7. The vehicle-mounted ECU safe startup method according to claim 5, characterized in that: The main chip verifies the integrity of the second block program while the security chip verifies the security of the first block program, including: The main chip verifies the integrity of the second block program based on the CRC-32 algorithm while the security chip verifies the security of the first block program.

8. The vehicle-mounted ECU safe startup method according to claim 7, characterized in that: The main chip verifies the security of the first block program based on the CRC-32 algorithm while the security chip verifies the integrity of the second block program, including: The main chip obtains a verification code for verifying the second block program based on a CRC-32 algorithm; Comparing the verification code with a preset verification code; If the verification code is consistent with the preset verification code, the second block program is determined to be complete; If the verification code is inconsistent with the preset verification code, it is determined that the second block program is incomplete.

Images