Low power safe start method and system for low speed bus
By introducing a function-restricted operating mode and a time-sharing block verification mechanism into the vehicle ECU, the hardware resource dependence and high power consumption problems of the low-speed bus ECU are solved, and low-power safe startup is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- WUHAN JIANGXIA CHUNENG AUTOMOBILE TECHNOLOGY R&D CO LTD
- Filing Date
- 2026-03-31
- Publication Date
- 2026-06-12
AI Technical Summary
Existing vehicle ECU safe startup solutions suffer from issues such as strong hardware resource dependence, high power consumption during startup, and lack of adaptation mechanisms for low-speed slave nodes in low-performance, low-power ECUs.
A limited operation mode is introduced, which prioritizes the verification of critical code segments and performs time-sharing and block-based verification of non-critical code segments when the bus is idle, thereby reducing the computational load and power consumption during the startup phase.
It achieves low-power safe startup in a low-speed bus environment, reduces the current peak and computational complexity during startup, and ensures the basic safety of the system.
Smart Images
Figure CN122195519A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of vehicle ECU safe start technology, and in particular to a low-power safe start method and system suitable for low-speed buses. Background Technology
[0002] The mainstream technologies for secure booting of automotive ECUs (Electronic Control Units) are generally software-based secure boot schemes based on public key certificate chains and those based on full image verification. While these schemes improve the software security of automotive ECUs to some extent, they still have significant shortcomings in low-performance, low-power ECUs (such as LIN (Local Interconnect Network) slave nodes). Existing secure boot schemes based on HSM (Hardware Security Module) or public key verification typically rely on dedicated hardware or security coprocessors, placing high demands on the computing power and storage space of the MCU (Microcontroller Unit). Furthermore, existing schemes often perform full image hash calculations or large-scale digital signature verification immediately after the ECU is powered on, requiring high computational load during the boot phase. These characteristics make these schemes difficult to deploy on resource-constrained ECUs such as LIN slave nodes.
[0003] In summary, while existing onboard ECU safe boot solutions achieve software security, they generally suffer from problems such as strong dependence on hardware resources, high power consumption during the boot phase, and lack of adaptation mechanisms for low-speed slave nodes. Summary of the Invention
[0004] This invention provides a low-power secure boot method and system suitable for low-speed buses, solving the problems of strong dependence on hardware resources, high power consumption during the boot phase, and lack of adaptation mechanism for low-speed slave nodes.
[0005] Firstly, a low-power secure boot method suitable for low-speed buses is provided, including: When the vehicle ECU is detected to be powered on and awakened, the vehicle ECU is controlled to enter a function-limited operation mode. In the function-restricted operation mode, obtain the startup status information associated with the power-on wake-up of the vehicle ECU; Based on the startup status information, the integrity of the preset critical code segments and the preset non-critical code segments are verified sequentially. Once the code verification is complete, the vehicle ECU is switched to normal operating mode.
[0006] In some embodiments, in the function-restricted operation mode, the vehicle's preset basic function modules are controlled to be executed. The vehicle's preset basic function modules include: a communication function module, a vehicle status monitoring function module, a safety default output control function module, and a safety start function module.
[0007] In some embodiments, the step of sequentially verifying the integrity of preset critical code segments and preset non-critical code segments based on the startup status information includes: The startup status information includes power-on wake-up status, current power supply voltage, reset type, and bus scheduling frame; Based on the power-on wake-up state, the current power supply voltage, and the reset type, the integrity of the preset critical code segment and the preset non-critical code segment are verified sequentially. During the process of sequentially verifying the preset critical code segment and the preset non-critical code segment, when an idle window is detected in the bus scheduling frame, the integrity of the preset non-critical code segment is verified, and each time an idle window is detected, a data block split from the preset non-critical code segment is verified.
[0008] In some embodiments, the step of sequentially verifying the integrity of preset critical code segments and preset non-critical code segments based on the power-on wake-up state, the current power supply voltage, and the reset type includes: When the vehicle ECU is detected to be in the first power-on wake-up state, the integrity of the preset critical code segment and the preset non-critical code segment are checked in sequence. When it is detected that the vehicle ECU is not in the first power-on wake-up state, the integrity of the preset critical code segment and the preset non-critical code segment are checked sequentially according to the code verification progress information of the last time. When the current power supply voltage of the vehicle ECU is detected to be greater than the first voltage threshold, the integrity of the preset critical code segment and the preset non-critical code segment are checked in sequence. When the current power supply voltage of the vehicle ECU is detected to be greater than the second threshold and less than or equal to the first voltage threshold, the integrity of the preset critical code segment is checked, and the integrity of the preset non-critical code segment is checked in blocks. When the current power supply voltage of the vehicle ECU is detected to be less than or equal to the second threshold, only the integrity of the preset key code segment is checked. When the reset type of the vehicle ECU is detected to be watchdog reset, the integrity of the preset critical code segment is re-verified, and the verification progress information of the preset non-critical code segment is retained. When the reset type of the vehicle ECU is detected as bus wake-up reset, it is determined whether to skip the verification of the preset non-critical code segment based on the previous code verification progress information. When the reset type of the vehicle ECU is detected as software reset, the preset critical code segment is reconstructed, and the integrity of the reconstructed preset critical code segment and the preset non-critical code segment are verified in turn.
[0009] In some embodiments, the preset key code segment includes interrupt vector association code, low-speed bus communication association code, and output control association code; The method for verifying the integrity of the preset critical code segment includes: calculating the hash value of the preset critical code segment based on the CRC32 algorithm, and comparing the hash value with the verification benchmark value stored in the bootloader. If the comparison is consistent, the verification is successful.
[0010] In some embodiments, the block verification of the integrity of preset non-critical code segments includes: The preset non-critical code segment is divided into multiple data blocks, and the CRC32 check value of each data block is calculated based on the CRC32 algorithm; The CRC32 checksum of each data block is compared with the corresponding baseline value in turn; If the comparison results are consistent, the data block corresponding to the consistent comparison results passes the verification. If the comparison results are inconsistent, the data block corresponding to the inconsistent comparison results will fail the verification and the security exception handling mode will be executed.
[0011] In some embodiments, the step of sequentially verifying the integrity of preset critical code segments and preset non-critical code segments based on the startup status information includes: During the code integrity verification process, if the current power supply voltage of the vehicle ECU is less than or equal to the third threshold; or the vehicle ECU exits the current wake-up cycle; or the energy consumption required for the code integrity verification process is greater than or equal to the preset energy consumption threshold, the code integrity verification will be paused and the completed verification progress information will be saved.
[0012] Secondly, a low-power secure boot system suitable for low-speed buses is provided, comprising: The power-on wake-up module is used to control the vehicle ECU to enter a function-limited operation mode when the power-on wake-up of the vehicle ECU is detected. The status information acquisition module is communicatively connected to the power-on wake-up module and is used to acquire the startup status information associated with the power-on wake-up of the vehicle ECU in the function-restricted operation mode. A code verification module, communicatively connected to the status information acquisition module, is used to sequentially verify the integrity of preset critical code segments and preset non-critical code segments based on the startup status information; and, The mode switching module is communicatively connected to the code verification module and is used to control the vehicle ECU to switch to normal operation mode when the code verification is completed.
[0013] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the low-power secure boot method for low-speed buses as described above.
[0014] Fourthly, embodiments of the present invention provide an electronic device, including a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, wherein the processor, when executing the computer program, implements the low-power secure boot method for low-speed buses as described above.
[0015] Compared with the prior art, the advantages of the present invention are as follows: 1. Restricted Function Operation Mode: Traditional safe startup has only two states: no operation before verification, and normal operation after verification. This introduces a third state: before safety verification is complete, the ECU operates in a "restricted" function operation mode. This is a change in the startup model, not a simple process optimization. In restricted function operation mode, only LIN message reception and basic responses are allowed, status reporting is enabled, outputs remain at safe default values, control variable updates are prohibited, unnecessary logic execution is disabled, and external parameter modifications are not permitted. This avoids activating all modules at startup, reducing the peak current from simultaneous power-on of peripherals, and achieving parallel rather than serial safety verification and functional operation, thus achieving low power consumption.
[0016] 2. Prioritize Critical Code Segments Verification: Prioritizing critical code segments means verifying the smallest trustworthy set first, rather than verifying fewer segments. This set must be such that even if non-critical code is tampered with, it will not immediately pose a security risk. Critical code segments can be determined by pre-defining interrupt vector tables, low-speed bus communication processing code, and control logic directly related to physical outputs during the compilation or deployment phase, and recording their address ranges in the boot module. During verification, only the above address ranges are checked for integrity at startup. This approach reduces verification data, significantly decreases CPU usage during startup, and thus achieves low power consumption.
[0017] 3. Time-sharing and block-based security verification mechanism for critical code segments: The security verification is transformed from a one-time action during the startup phase into a schedulable task during system operation. Non-critical code segments can be divided into multiple verification blocks of preset size. Each verification block independently calculates its integrity. Verification is performed when the bus is idle, the MCU task load is below a threshold, or the current function is in a restricted mode. In this way, the computational load is distributed to avoid concentrated computing power consumption during the startup phase, thereby achieving low power consumption. Attached Figure Description
[0018] Figure 1 This is a flowchart illustrating a low-power secure boot method for low-speed buses according to the present invention. Figure 2 This is a schematic diagram of a low-power safe boot system suitable for low-speed buses according to the present invention. Detailed Implementation
[0019] Referring now to specific embodiments of the invention, examples of which are illustrated in the accompanying drawings. Although the invention will be described in conjunction with specific embodiments, it will be understood that it is not intended to limit the invention to the described embodiments. Rather, it is intended to cover variations, modifications, and equivalents included within the spirit and scope of the invention as defined by the appended claims. It should be noted that the method steps described herein can be implemented by any functional block or functional arrangement, and any functional block or functional arrangement can be implemented as a physical entity or a logical entity, or a combination of both.
[0020] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0021] Note: The examples described below are merely specific examples and are not intended to limit the embodiments of the present invention to the specific steps, values, conditions, data, order, etc. Those skilled in the art can utilize the concept of the present invention to construct more embodiments not mentioned herein by reading this specification.
[0022] Please see Figure 1 This invention provides a low-power secure boot method suitable for low-speed buses, applied to a microcontroller unit (MCU). The method includes: Step S100: After detecting that the vehicle ECU has been powered on and woken up, control the vehicle ECU to enter a function-limited operation mode.
[0023] In the function-restricted operation mode, the vehicle's preset basic function modules are controlled and executed. The vehicle's preset basic function modules include: a communication function module, a vehicle status monitoring function module, a safety default output control function module, and a safety start function module.
[0024] Specifically, in this embodiment of the invention, when the ECU is woken up by the vehicle bus or reset by power-on, the MCU first completes a minimal hardware initialization operation. This initialization operation only includes the necessary functional modules related to the startup process, avoiding additional power consumption in the early stages of startup.
[0025] During the initial startup phase, instead of immediately performing a complete software safety check, the ECU enters a function-restricted operating mode. In this mode, the ECU is allowed to execute preset basic functions, but high-risk or unnecessary business functions are prohibited. It can respond to basic communication requests from the low-speed bus. This ensures the node retains basic availability until the safety check is complete, while avoiding strong coupling between safety checks and business startup. The preset basic functions refer to those functions that have not yet completed all safety checks and will not directly cause the vehicle to perform dangerous actions. These are typically functions that do not directly control actuators, do not change critical system states, do not involve modification of sensitive parameters, and have low computational load. In a LIN node ECU, these usually include basic communication functions, system status monitoring functions, safe default output control functions, and safety startup-related functions. High-risk business functions are those that, once executed, could directly affect the vehicle's operating state or actuator actions. These typically include actuator control functions, parameter modification functions, software update functions, and computationally high-load business functions.
[0026] The default safety output control function of a vehicle is either the electronic airbag or the final actuator. Normally, it doesn't participate in driving, but silently monitors the system; however, in the event of a serious malfunction causing the main system to fail, it immediately takes over, forcibly issuing safety commands such as stopping or slowing down, thereby maximizing the safety of the vehicle occupants and other road users.
[0027] Step S200: In the function-restricted operation mode, obtain the startup status information associated with the power-on wake-up of the vehicle ECU; Step S300: Based on the startup status information, sequentially verify the integrity of preset critical code segments and preset non-critical code segments, including: The startup status information includes power-on wake-up status, current power supply voltage, reset type, and bus scheduling frame; Step S310: Based on the power-on wake-up state, the current power supply voltage, and the reset type, sequentially verify the integrity of the preset critical code segment and the preset non-critical code segment, including: Step S311: When the vehicle ECU is detected to be in the first power-on wake-up state, the integrity of the preset critical code segment and the preset non-critical code segment are checked in sequence. When it is detected that the vehicle ECU is not in the first power-on wake-up state, the integrity of the preset critical code segment and the preset non-critical code segment are checked sequentially according to the code verification progress information of the last time. Therefore, for power-on wake-up states, if it is the first startup or a state requiring complete verification, a complete security verification process must be executed, including verification of critical code segments and block-by-block verification of non-critical code segments. If there were incomplete verification tasks during the previous startup process, subsequent verifications will begin from the code segments verified in the previous operation.
[0028] Step S312: When the current power supply voltage of the vehicle ECU is detected to be greater than the first voltage threshold, the integrity of the preset critical code segment and the preset non-critical code segment are checked in sequence. When the current power supply voltage of the vehicle ECU is detected to be greater than the second threshold and less than or equal to the first voltage threshold, the integrity of the preset critical code segment is checked, and the integrity of the preset non-critical code segment is checked in blocks. When the current power supply voltage of the vehicle ECU is detected to be less than or equal to the second threshold, only the integrity of the preset key code segment is checked. For the current supply voltage, the current supply voltage status is determined based on voltage thresholds. If the current supply voltage is greater than the first voltage threshold, the strategy is to verify critical code segments and complete the verification of all non-critical code segments as much as possible within the startup cycle. If the current supply voltage is greater than the second threshold but less than or equal to the first voltage threshold, the strategy is to verify critical code segments, and non-critical code segments are verified in blocks, with a maximum of one code block verified per wake-up cycle. If the current supply voltage is less than or equal to the second threshold, only critical code segments are verified, and the verification of non-critical code segments is delayed to subsequent running stages.
[0029] Step S313: When the reset type of the vehicle ECU is detected to be watchdog reset, the integrity of the preset critical code segment is re-verified, and the verification progress information of the preset non-critical code segment is retained. When the reset type of the vehicle ECU is detected as bus wake-up reset, it is determined whether to skip the verification of the preset non-critical code segment based on the previous code verification progress information. When the reset type of the vehicle ECU is detected as software reset, the preset critical code segment is reconstructed, and the integrity of the reconstructed preset critical code segment and the preset non-critical code segment are verified in turn.
[0030] Step S320: During the sequential verification of preset critical code segments and preset non-critical code segments, when an idle window is detected in the bus scheduling frame, the integrity of the preset non-critical code segments is verified. Each detected idle window verifies a data block extracted from the preset non-critical code segment. This step S320 is for verifying the integrity of the preset non-critical code segments. The specific time-sharing verification operation using idle windows will be explained in conjunction with the following block-based verification steps.
[0031] The preset key code segments include interrupt vector association code, low-speed bus communication association code, and output control association code; The method for verifying the integrity of the preset critical code segment includes: calculating the hash value of the preset critical code segment based on the CRC32 (32-bit Cyclic Redundancy Check) algorithm, and comparing the hash value with the verification benchmark value stored in the bootloader. If the comparison is consistent, the verification is successful.
[0032] By performing integrity checks only on critical code segments, the computational complexity and power consumption during the startup phase are effectively reduced while ensuring the basic security of the system.
[0033] The block-based verification of the integrity of preset non-critical code segments includes: The preset non-critical code segment is divided into multiple data blocks, and the CRC32 check value of each data block is calculated based on the CRC32 algorithm; The CRC32 checksum of each data block is compared with the corresponding baseline value in turn; If the comparison results are consistent, the data block corresponding to the consistent comparison results passes the verification. If the comparison results are inconsistent, the data block corresponding to the inconsistent comparison results will fail the verification and the security exception handling mode will be executed.
[0034] Specifically, after completing the verification of critical code segments, the idle state of the low-speed bus is monitored in real time to determine whether an idle window exists in the bus scheduling frame, i.e., whether the bus is in a low-load state. An idle time threshold is set. The current time is recorded when the system starts up. When a communication event occurs, the activity time is updated. The idle state of the bus is determined by calculating whether the time interval between the current time and the most recent bus communication event exceeds the idle time threshold. When an idle window exists, time-sharing and block-based integrity verification is performed on non-critical code segments. During the firmware compilation or packaging stage, non-critical code segments are divided into multiple data blocks according to a preset size, and the CRC32 check value of each data block is calculated based on the CRC32 algorithm. The CRC32 check value is stored in an integrity verification table. During system operation, a verification status record table is maintained to identify whether each data block has completed integrity verification. When the system detects that the communication bus is idle, the background task selects a data block from the unverified data blocks, reads its corresponding program data, calculates the integrity check value, and then compares the calculation result with the reference value stored in the integrity check table. If the check results match, the check status of the data block is updated to "verified," and the same operation is performed on the next unverified data block when the system is idle again. If the check results do not match, a security exception handling mechanism is triggered, such as logging a security event or restricting the operation of related functions. In this way, the integrity check of all non-critical code segments is completed gradually during system operation, thus avoiding centralized check of all program code during startup, reducing system startup power consumption, and minimizing the occupation of low-performance MCU resources. Each check only processes a code block of a preset size, thereby distributing the overall computational load across multiple time windows and avoiding concentrated power consumption.
[0035] Step S300, based on the startup status information, sequentially verifies the integrity of preset critical code segments and preset non-critical code segments, including: During the code integrity verification process, if the current power supply voltage of the vehicle ECU is less than or equal to the third threshold; or the vehicle ECU exits the current wake-up cycle; or the energy consumption required for the code integrity verification process is greater than or equal to the preset energy consumption threshold, the code integrity verification will be paused and the completed verification progress information will be saved.
[0036] Specifically, during the integrity verification process, if the power supply status drops below the third threshold, the ECU exits the current wake-up cycle, or the verification process exceeds a preset power consumption limit, the current verification process is immediately interrupted, and the completed verification progress information is recorded. Upon the next wake-up of the ECU, the remaining verification process is resumed from the interrupted point based on the recorded progress information.
[0037] In step S400, once the code verification is completed, the vehicle ECU is switched to normal operating mode.
[0038] Specifically, in this embodiment of the invention, when it is confirmed that the critical code segment verification has passed and all non-critical code segment verifications have been completed, a verification completion flag is set, and the ECU is switched from restricted function operation mode to normal operation mode, allowing the application to execute completely.
[0039] See also Figure 2 As shown in the figure, an embodiment of the present invention provides a low-power secure boot system suitable for low-speed buses, which specifically includes the following steps: The power-on wake-up module is used to control the vehicle ECU to enter a function-limited operation mode when the power-on wake-up of the vehicle ECU is detected. The status information acquisition module is communicatively connected to the power-on wake-up module and is used to acquire the startup status information associated with the power-on wake-up of the vehicle ECU in the function-restricted operation mode. A code verification module, communicatively connected to the status information acquisition module, is used to sequentially verify the integrity of preset critical code segments and preset non-critical code segments based on the startup status information; and, The mode switching module is communicatively connected to the code verification module and is used to control the vehicle ECU to switch to normal operation mode when the code verification is completed.
[0040] In summary, the main innovations of this invention are as follows: 1. Restricted Function Operation Mode: Traditional safe startup has only two states: no operation before verification, and normal operation after verification. This introduces a third state: before safety verification is complete, the ECU operates in a "restricted" function operation mode. This is a change in the startup model, not a simple process optimization. In restricted function operation mode, only LIN message reception and basic responses are allowed, status reporting is enabled, outputs remain at safe default values, control variable updates are prohibited, unnecessary logic execution is disabled, and external parameter modifications are not permitted. This avoids activating all modules at startup, reducing the peak current from simultaneous power-on of peripherals, and achieving parallel rather than serial safety verification and functional operation, thus achieving low power consumption.
[0041] 2. Prioritize Critical Code Segments Verification: Prioritizing critical code segments means verifying the smallest trustworthy set first, rather than verifying fewer segments. This set must be such that even if non-critical code is tampered with, it will not immediately pose a security risk. Critical code segments can be determined by pre-defining interrupt vector tables, low-speed bus communication processing code, and control logic directly related to physical outputs during the compilation or deployment phase, and recording their address ranges in the boot module. During verification, only the above address ranges are checked for integrity at startup. This approach reduces verification data, significantly decreases CPU usage during startup, and thus achieves low power consumption.
[0042] 3. Time-sharing and block-based security verification mechanism for critical code segments: The security verification is transformed from a one-time action during the startup phase into a schedulable task during system operation. Non-critical code segments can be divided into multiple verification blocks of preset size. Each verification block independently calculates its integrity. Verification is performed when the bus is idle, the MCU task load is below a threshold, or the current function is in a restricted mode. In this way, the computational load is distributed to avoid concentrated computing power consumption during the startup phase, thereby achieving low power consumption.
[0043] Specifically, this embodiment corresponds one-to-one with the above method embodiments. The functions of each module have been described in detail in the corresponding method embodiments, so they will not be repeated here.
[0044] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements all or part of the method steps of the above method.
[0045] The present invention can implement all or part of the processes in the above methods, or it can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.
[0046] Based on the same inventive concept, embodiments of this application also provide an electronic device, including a memory and a processor. The memory stores a computer program that runs on the processor. When the processor executes the computer program, it implements all or part of the method steps described above.
[0047] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the computer device, connecting all parts of the computer device through various interfaces and lines.
[0048] Memory can be used to store computer programs and / or modules. The processor performs various functions of the computer device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can primarily include a program storage area and a data storage area. The program storage area can store the operating system and application programs required for at least one function (e.g., sound playback, image playback, etc.); the data storage area can store data created based on mobile usage (e.g., audio data, video data, etc.). Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital cards (SD cards), flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.
[0049] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, servers, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.
[0050] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), servers, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0051] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0052] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0053] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.
Claims
1. A low-power secure boot method suitable for low-speed buses, characterized in that, include: When the vehicle ECU is detected to be powered on and awakened, the vehicle ECU is controlled to enter a function-limited operation mode. In the function-restricted operation mode, obtain the startup status information associated with the power-on wake-up of the vehicle ECU; Based on the startup status information, the integrity of the preset critical code segments and the preset non-critical code segments are verified sequentially. Once the code verification is complete, the vehicle ECU is switched to normal operating mode.
2. The low-power secure boot method for low-speed buses as described in claim 1, characterized in that, In the function-restricted operation mode, the vehicle's preset basic function modules are controlled and executed. The vehicle's preset basic function modules include: a communication function module, a vehicle status monitoring function module, a safety default output control function module, and a safety start function module.
3. The low-power secure boot method for low-speed buses as described in claim 1, characterized in that, The step of sequentially verifying the integrity of preset critical code segments and preset non-critical code segments based on the startup status information includes: The startup status information includes power-on wake-up status, current power supply voltage, reset type, and bus scheduling frame; Based on the power-on wake-up state, the current power supply voltage, and the reset type, the integrity of the preset critical code segment and the preset non-critical code segment are verified sequentially. During the process of sequentially verifying the preset critical code segment and the preset non-critical code segment, when an idle window is detected in the bus scheduling frame, the integrity of the preset non-critical code segment is verified, and each time an idle window is detected, a data block split from the preset non-critical code segment is verified.
4. The low-power secure boot method for low-speed buses as described in claim 3, characterized in that, The step of sequentially verifying the integrity of preset critical code segments and preset non-critical code segments based on the power-on wake-up state, the current power supply voltage, and the reset type includes: When the vehicle ECU is detected to be in the first power-on wake-up state, the integrity of the preset critical code segment and the preset non-critical code segment are checked in sequence. When it is detected that the vehicle ECU is not in the first power-on wake-up state, the integrity of the preset critical code segment and the preset non-critical code segment are checked sequentially according to the code verification progress information of the last time. When the current power supply voltage of the vehicle ECU is detected to be greater than the first voltage threshold, the integrity of the preset critical code segment and the preset non-critical code segment are checked in sequence. When the current power supply voltage of the vehicle ECU is detected to be greater than the second threshold and less than or equal to the first voltage threshold, the integrity of the preset critical code segment is checked, and the integrity of the preset non-critical code segment is checked in blocks. When the current power supply voltage of the vehicle ECU is detected to be less than or equal to the second threshold, only the integrity of the preset key code segment is checked. When the reset type of the vehicle ECU is detected to be watchdog reset, the integrity of the preset critical code segment is re-verified, and the verification progress information of the preset non-critical code segment is retained. When the reset type of the vehicle ECU is detected as bus wake-up reset, it is determined whether to skip the verification of the preset non-critical code segment based on the previous code verification progress information. When the reset type of the vehicle ECU is detected as software reset, the preset critical code segment is reconstructed, and the integrity of the reconstructed preset critical code segment and the preset non-critical code segment are verified in turn.
5. The low-power secure boot method for low-speed buses as described in claim 1, characterized in that, The preset key code segments include interrupt vector association code, low-speed bus communication association code, and output control association code; The method for verifying the integrity of the preset critical code segment includes: calculating the hash value of the preset critical code segment based on the CRC32 algorithm, and comparing the hash value with the verification benchmark value stored in the bootloader. If the comparison is consistent, the verification is successful.
6. The low-power secure boot method for low-speed buses as described in claim 4, characterized in that, The block-based verification of the integrity of preset non-critical code segments includes: The preset non-critical code segment is divided into multiple data blocks, and the CRC32 check value of each data block is calculated based on the CRC32 algorithm; The CRC32 checksum of each data block is compared with the corresponding baseline value in turn; If the comparison results are consistent, the data block corresponding to the consistent comparison results passes the verification. If the comparison results are inconsistent, the data block corresponding to the inconsistent comparison results will fail the verification and the security exception handling mode will be executed.
7. The low-power secure boot method for low-speed buses as described in claim 1, characterized in that, The step of sequentially verifying the integrity of preset critical code segments and preset non-critical code segments based on the startup status information includes: During the code integrity verification process, if the current power supply voltage of the vehicle ECU is less than or equal to the third threshold; or the vehicle ECU exits the current wake-up cycle; or the energy consumption required for the code integrity verification process is greater than or equal to the preset energy consumption threshold, the code integrity verification will be paused and the completed verification progress information will be saved.
8. A low-power secure boot system suitable for low-speed buses, characterized in that, include: The power-on wake-up module is used to control the vehicle ECU to enter a function-limited operation mode when the power-on wake-up of the vehicle ECU is detected. The status information acquisition module is communicatively connected to the power-on wake-up module and is used to acquire the startup status information associated with the power-on wake-up of the vehicle ECU in the function-restricted operation mode. The code verification module is communicatively connected to the status information acquisition module and is used to verify the integrity of preset critical code segments and preset non-critical code segments in sequence according to the startup status information. as well as, The mode switching module is communicatively connected to the code verification module and is used to control the vehicle ECU to switch to normal operation mode when the code verification is completed.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the low-power secure boot method for low-speed buses as described in any one of claims 1 to 7.
10. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, characterized in that, When the processor runs the computer program, it implements the low-power secure boot method for low-speed buses as described in any one of claims 1 to 7.