Safe starting method and safe starting device of vehicle microprocessor and electronic equipment
By introducing a root boot unit into the vehicle microprocessor and using software to perform multi-level security verification, the problem of the high cost of the HSM module in existing MCU secure boot schemes is solved, and secure boot of the vehicle microprocessor is realized, which is applicable to microcontroller units of various vehicles.
Patent Information
- Application Number
- CN202510923467.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-04
- Publication Date
- 2025-11-18
AI Technical Summary
Existing secure boot solutions for microcontroller units (MCUs) require a hardware security module (HSM), but HSM modules are expensive and subject to technological limitations.
By introducing a root boot unit into the vehicle microprocessor, secure booting is achieved through software. This includes generating key pairs to perform security verification on the bootloader and application programs, and using the root boot unit, bootloader boot unit, and application program boot unit for multi-level security verification.
In an environment with limited hardware resources, it achieves safe startup of vehicle microprocessors, reduces costs, and is applicable to microcontrollers of various vehicles.
Smart Images

Figure CN120974495A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of vehicle information security, in particular to a secure boot method and device for a vehicle microprocessor, an electronic device and a non-transitory computer readable storage medium. BACKGROUND
[0002] With the concept of software defined vehicles (SDV) being proposed, vehicle software is developing rapidly, with more and more functions and becoming more and more intelligent. While the car is serving people better, many safety problems have also emerged. Information security mainly ensures the safe operation of vehicle software. Secure boot of the vehicle can ensure that the software can run safely, and let the car MCU only run complete and trusted software.
[0003] The existing secure boot scheme of a microcontroller unit (MCU) requires the MCU to have a hardware security module (HSM) module, but is limited by technical constraints. Moreover, the MCU with the HSM module is expensive. SUMMARY
[0004] The present application proposes a secure boot method and device for a vehicle microprocessor, an electronic device and a non-transitory computer readable storage medium to solve the problem of secure boot of the vehicle.
[0005] According to an aspect of the present application, a secure boot method for a vehicle microprocessor is provided, the vehicle microprocessor comprising a root boot unit, a bootloader boot unit and an application program boot unit, and the secure boot method comprising:
[0006] In response to a power-on instruction of the vehicle microprocessor, performing first security verification on the bootloader boot unit by the root boot unit;
[0007] When the first security verification is passed, performing second security verification on the application program boot unit by the bootloader boot unit;
[0008] When the second security verification is passed, issuing an execution instruction to the application program of the vehicle.
[0009] According to some embodiments, the root boot unit is configured in an OTP area or a CodeFlash area of the vehicle microprocessor.
[0010] According to some embodiments, before performing first security verification on the bootloader boot unit by the root boot unit, the method further comprises:
[0011] Generate the first key pair;
[0012] Specifically, in response to the power-on command of the vehicle microprocessor, the root startup unit performs a first security check on the bootloader startup unit, including:
[0013] In response to the power-on command of the vehicle microprocessor, the root boot unit performs a first security verification on the boot program boot unit using the first key pair.
[0014] According to some embodiments, the first key pair includes a first private key and a first public key, and the method further includes:
[0015] Calculate the hash value of the data in the bootloader startup unit to obtain the first bootloader startup data hash value;
[0016] The first private key is used to encrypt the hash value of the first bootloader startup data.
[0017] According to some embodiments, in response to the power-on command of the vehicle microprocessor, the root boot unit performs a first security verification on the bootloader boot unit using the first key pair, including:
[0018] Upon receiving the power-on command, the first public key is used to decrypt the hash value of the first boot program startup data to obtain the first decrypted data;
[0019] Calculate the hash value of the data in the bootloader startup unit to obtain the second bootloader startup data hash value;
[0020] Compare the hash values of the first decrypted data and the second bootloader startup data;
[0021] The first security check passes when the hash values of the first decrypted data and the second bootloader startup data are the same.
[0022] According to some embodiments, before performing a first security check on the bootloader startup unit using the root boot unit, the method further includes:
[0023] The unused address space of the bootloader startup unit is filled with random numbers.
[0024] According to some embodiments, before performing a second security check on the application launch unit using the bootloader launch unit, the method further includes:
[0025] Generate a second key pair;
[0026] Wherein, after the first security check passes, the bootloader startup unit performs a second security check on the application startup unit, including:
[0027] After the first security check passes, the bootloader startup unit uses the second key pair to perform a second security check on the application startup unit.
[0028] According to some embodiments, the second key pair includes a second private key and a second public key, and the method further includes:
[0029] Calculate the hash value of the data in the application startup unit to obtain the first application startup data hash value;
[0030] The hash value of the first application startup data is encrypted using the second private key.
[0031] According to some embodiments, after the first security check passes, the bootloader startup unit performs a second security check on the application startup unit, including:
[0032] After the first security check passes, the hash value of the first application startup data is decrypted using the second public key to obtain the second decrypted data.
[0033] Calculate the hash value of the data in the application startup unit to obtain the second application startup data hash value;
[0034] Compare the hash values of the second decrypted data and the second application startup data;
[0035] The second security check passes when the hash value of the second decrypted data is the same as that of the second application startup data.
[0036] According to some embodiments, before performing a second security check on the application launch unit using the bootloader launch unit, the method further includes:
[0037] The unused address space of the application startup unit is filled with random numbers.
[0038] According to one aspect of this application, a secure start device for a vehicle microprocessor is provided, the vehicle microprocessor including a root start unit, a bootloader start unit, and an application program start unit, the secure start device comprising:
[0039] The first security verification unit is used to perform a first security verification on the boot program startup unit using the root startup unit in response to the power-on command of the vehicle microprocessor.
[0040] The second security verification unit is used to perform a second security verification on the application startup unit using the bootloader startup unit after the first security verification is passed.
[0041] The execution instruction issuing unit is used to issue an execution instruction to the vehicle's application program when the second security check passes.
[0042] According to one aspect of this application, an electronic device is provided, characterized in that it includes: a processor; a memory for storing a computer program; and when the computer program is executed by the processor, causing the processor to implement the secure boot method as described in any of the preceding embodiments.
[0043] According to one aspect of this application, a non-transitory computer-readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a processor, cause the processor to perform the secure boot method as described in any of the preceding embodiments.
[0044] According to an example embodiment of this application, by adding a root startup unit to the vehicle microprocessor, the problem of safe vehicle startup is solved under limited hardware resources.
[0045] Because the root startup unit is implemented in software, it has high adaptability and can be applied to microcontroller units of various vehicles. Attached Figure Description
[0046] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below.
[0047] Figure 1 This is a schematic diagram of a secure boot software architecture for a vehicle microprocessor according to an example embodiment of this application.
[0048] Figure 2 A flowchart of a secure startup method for a vehicle microprocessor according to an example embodiment of this application is shown.
[0049] Figure 3 A schematic diagram of another secure startup method for a vehicle microprocessor according to an example embodiment of this application is shown.
[0050] Figure 4 A schematic diagram of a secure boot software architecture for a vehicle microprocessor according to an example embodiment of this application is shown.
[0051] Figure 5 A schematic diagram of a verification process according to an example embodiment of this application is shown.
[0052] Figure 6A block diagram of a secure startup method apparatus for a vehicle microprocessor according to an example embodiment of this application is shown.
[0053] Figure 7 An electronic device is shown according to an exemplary embodiment of this application. Detailed Implementation
[0054] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.
[0055] The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of these specific details, or other methods, components, materials, apparatus, or operations may be employed. In these cases, well-known structures, methods, apparatuses, implementations, materials, or operations will not be shown or described in detail.
[0056] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.
[0057] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.
[0058] As mentioned earlier, existing secure boot schemes for microcontroller units (MCUs) require the MCU to have a hardware security module (HSM), but this is limited by technological constraints. Furthermore, MCUs with HSM modules are expensive. Therefore, according to embodiments of this application, a software method is proposed to achieve secure boot of the MSU.
[0059] Figure 1 This is a schematic diagram of a secure boot software architecture for a vehicle microprocessor according to an example embodiment of this application, such as... Figure 1 As shown, a root startup file, Boot0, is added to the existing software architecture of bootloader and application software. Boot0 serves as the trusted root startup file for the entire software architecture, and its workload includes security verification of the Bootloader's authenticity and integrity, thus solving the problem of the existing software architecture lacking a trusted root startup file.
[0060] In a specific implementation, Boot0 can be injected during production and contains the public key required for verifying the BootLoader signature. The BootLoader is downloaded via Boot0 during production and contains the public key required for verifying the Application signature, as well as the BootLoader's signature. The Application contains the Application signature.
[0061] The specific embodiments according to this application will now be described in detail with reference to the accompanying drawings.
[0062] Figure 2 A flowchart illustrating a secure startup method for a vehicle microprocessor according to an example embodiment of this application is shown, such as... Figure 2 The safe boot method shown includes steps S201, S203, and S205. The following will use... Figure 2 Taking an example, a safe startup method for a vehicle microprocessor according to an example embodiment of this application will be described in detail.
[0063] According to an embodiment of this application, the vehicle microprocessor includes a root startup unit, a bootloader startup unit, and an application startup unit.
[0064] In some embodiments, in order to ensure that the root boot unit is a trusted root boot file, the root boot unit is set in the OTP (One-Time Programmable) area of the microcontroller or in the CodeFlash with hardware protection, so as to ensure that the root boot unit is not tampered with externally.
[0065] In step S201, in response to the power-on command of the vehicle microprocessor, the root startup unit performs a first security check on the boot program startup unit.
[0066] According to an embodiment of this application, before step S201, a first key pair is generated, and the bootloader startup unit is encrypted using the first key pair.
[0067] In some embodiments, the first key pair includes a first private key and a first public key.
[0068] When encrypting the bootloader startup unit, the hash value of the data in the bootloader startup unit is first calculated to obtain the first bootloader startup data hash value; then, the first bootloader startup data hash value is encrypted using the first private key.
[0069] During the verification of the bootloader startup unit, after receiving the power-on command, firstly, the first bootloader startup data hash value is decrypted using the first public key to obtain the first decrypted data; then, the hash value of the data in the bootloader startup unit is calculated to obtain the second bootloader startup data hash value; then, the first decrypted data and the second bootloader startup data hash value are compared; and when the first decrypted data and the second bootloader startup data hash value are the same, the first security verification passes.
[0070] According to an embodiment of this application, before step S201, it is also necessary to fill the unused address space of the bootloader startup unit with random numbers so that the address length occupied by the bootloader startup unit reaches a preset fixed value.
[0071] In step S203, after the first security check passes, the bootloader startup unit performs a second security check on the application startup unit.
[0072] According to an embodiment of this application, before step S203, a second key pair needs to be generated, and the application startup unit is encrypted using the second key pair. After the first security verification passes, the bootloader startup unit performs a second security verification on the application startup unit using the second key pair.
[0073] In some embodiments, the second key pair includes a second private key and a second public key.
[0074] When encrypting the application startup unit, firstly, the hash value of the data in the application startup unit is calculated to obtain the first application startup data hash value; then, the first application startup data hash value is encrypted using the second private key.
[0075] After the first security check passes, when checking the application startup unit, firstly, the hash value of the first application startup data is decrypted using the second public key to obtain the second decrypted data; then, the hash value of the data in the application startup unit is calculated to obtain the hash value of the second application startup data, and the second decrypted data and the hash value of the second application startup data are compared; when the second decrypted data and the hash value of the second application startup data are the same, the second security check passes.
[0076] According to some other embodiments, before step S203, it is also necessary to fill the unused address space of the application startup unit with random numbers so that the address length occupied by the application startup unit reaches a preset fixed value.
[0077] In step S205, when the second security check passes, an execution command is sent to the vehicle's application.
[0078] according to Figure 2 The embodiment shown solves the problem of safe vehicle startup under limited hardware resources by adding a root startup unit to the vehicle microprocessor.
[0079] Because the root startup unit is implemented in software, it has high adaptability and can be applied to microcontroller units of various vehicles.
[0080] Figure 3 A schematic diagram of another secure boot method for a vehicle microprocessor according to an example embodiment of this application is shown. As shown in Figure 1, firstly, two key pairs are generated using an encryption server, which are used to sign and verify the BootLoader and Application respectively, and the corresponding public keys are stored in the root boot file Boot0 and BootLoader respectively.
[0081] When encrypting the BootLoader or Application, the encryption server, when adding a signature to the BootLoader and Application, first fills the unused address space of the BootLoader / Application program with random numbers to make its length a fixed value; then, it calculates the hash value of the BootLoader or Application using an encryption algorithm (such as SHA256); next, it encrypts the hash value of the BootLoader or Application using the corresponding private key; finally, it appends the encrypted ciphertext to the end of the BootLoader or Application, as shown below. Figure 4 As shown.
[0082] When verifying the BootLoader or Application, since the address space of the BootLoader or Application has become fixed length after being filled with random numbers, the data in it can be directly used to calculate the hash value (e.g., SHA256). Then, the ciphertext of the signature is decrypted using the corresponding public key. Finally, the calculated hash value and the corresponding public key decryption result are compared. If they are the same, the signature verification is successful and the verification passes.
[0083] Figure 5 A schematic diagram of a verification process according to an example embodiment of this application is shown, such as... Figure 5As described above, after the MCU powers on / wakes up and completes the reboot process, execution jumps to the root boot file Boot0 area of the Code Flash. The root boot file Boot0 verifies the BootLoader's signature. If the verification passes, execution jumps to the BootLoader; otherwise, it immediately reboots and / or continues to fail verification. Then, the BootLoader verifies the Application's signature. If the verification passes, execution jumps to the Application; otherwise, it immediately reboots and / or continues to fail verification.
[0084] Figure 6 A block diagram of a safe start device for a vehicle microprocessor according to an example embodiment of this application is shown, such as Figure 6 The safety start device shown includes a first safety verification unit 601, a second safety verification unit 603, and an execution command issuing unit 605.
[0085] According to an embodiment of this application, a vehicle microprocessor includes a root startup unit, a bootloader startup unit, and an application startup unit. A first security verification unit 601 is configured to perform a first security verification on the bootloader startup unit using the root startup unit in response to a power-on command from the vehicle microprocessor. A second security verification unit 603 is configured to perform a second security verification on the application startup unit using the bootloader startup unit after the first security verification passes. An execution instruction issuing unit 605 is configured to issue an execution instruction to the vehicle's application program after the second security verification passes.
[0086] Figure 7 An electronic device according to an exemplary embodiment of this application is shown. Reference is made below. Figure 7 To describe an electronic device 200 according to this embodiment of the present application. Figure 7 The electronic device 200 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0087] like Figure 7 As shown, the electronic device 200 is presented in the form of a general-purpose computing device. The components of the electronic device 200 may include, but are not limited to: at least one processing unit 210, at least one storage unit 220, a bus 230 connecting different system components (including storage unit 220 and processing unit 210), a display unit 240, etc.
[0088] The storage unit stores program code that can be executed by the processing unit 210, causing the processing unit 210 to perform the methods described in this specification according to various exemplary embodiments of this application. For example, the processing unit 210 can perform the methods described above.
[0089] Storage unit 220 may include readable media in the form of volatile storage units, such as random access memory (RAM) 2201 and / or cache memory 2202, and may further include read-only memory (ROM) 2203.
[0090] Storage unit 220 may also include a program / utility 2204 having a set (at least one) program module 2205, such program module 2205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.
[0091] Bus 230 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.
[0092] Electronic device 200 can also communicate with one or more external devices 300 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 200, and / or with any device that enables electronic device 200 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 250. Furthermore, electronic device 200 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 260. Network adapter 260 can communicate with other modules of electronic device 200 via bus 230. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0093] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. The technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the methods described above according to the embodiments of this application.
[0094] Software products may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0095] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.
[0096] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java and C++, and conventional procedural programming languages such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).
[0097] The aforementioned computer-readable medium carries one or more programs, which, when executed by a device, cause the computer-readable medium to perform the aforementioned functions.
[0098] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.
[0099] According to an embodiment of this application, a computer program is proposed, including a computer program or instructions, which, when executed by a processor, can perform the methods described above.
[0100] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. Furthermore, any changes or modifications made by those skilled in the art based on the ideas of this application, and on the specific implementation methods and application scope of this application, are all within the scope of protection of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
[0101] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.
[0102] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. Furthermore, any changes or modifications made by those skilled in the art based on the ideas of this application, and on the specific implementation methods and application scope of this application, are all within the scope of protection of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A safe startup method for a vehicle microprocessor, characterized in that, The vehicle microprocessor includes a root boot unit, a bootloader boot unit, and an application boot unit. The secure boot method includes: In response to the power-on command of the vehicle microprocessor, the root startup unit performs a first security check on the boot program startup unit. After the first security check passes, the bootloader startup unit performs a second security check on the application startup unit. Once the second security check passes, an execution command is sent to the vehicle's application.
2. The secure startup method according to claim 1, characterized in that, The root startup unit is configured in the OTP area or CodeFlash area of the vehicle microprocessor.
3. The secure startup method according to claim 1, characterized in that, Before performing the first security check on the bootloader startup unit using the root boot unit, the method further includes: Generate the first key pair; Specifically, in response to the power-on command of the vehicle microprocessor, the root startup unit performs a first security check on the bootloader startup unit, including: In response to the power-on command of the vehicle microprocessor, the root boot unit performs a first security verification on the boot program boot unit using the first key pair.
4. The safe startup method according to claim 3, characterized in that, The first key pair includes a first private key and a first public key, and the method further includes: Calculate the hash value of the data in the bootloader startup unit to obtain the first bootloader startup data hash value; The first private key is used to encrypt the hash value of the first bootloader startup data.
5. The safe startup method according to claim 4, characterized in that, In response to the power-on command of the vehicle microprocessor, the root boot unit performs a first security verification on the bootloader boot unit using the first key pair, including: Upon receiving the power-on command, the first public key is used to decrypt the hash value of the first boot program startup data to obtain the first decrypted data; Calculate the hash value of the data in the bootloader startup unit to obtain the second bootloader startup data hash value; Compare the hash values of the first decrypted data and the second bootloader startup data; The first security check passes when the hash values of the first decrypted data and the second bootloader startup data are the same.
6. The safe startup method according to claim 5, characterized in that, Before performing the first security check on the bootloader startup unit using the root boot unit, the method further includes: The unused address space of the bootloader startup unit is filled with random numbers.
7. The safe startup method according to claim 1, characterized in that, Before performing a second security check on the application launch unit using the bootloader launch unit, the method further includes: Generate a second key pair; Wherein, after the first security check passes, the bootloader startup unit performs a second security check on the application startup unit, including: After the first security check passes, the bootloader startup unit uses the second key pair to perform a second security check on the application startup unit.
8. The safe startup method according to claim 7, characterized in that, The second key pair includes a second private key and a second public key, and the method further includes: Calculate the hash value of the data in the application startup unit to obtain the first application startup data hash value; The hash value of the first application startup data is encrypted using the second private key.
9. The safe startup method according to claim 8, characterized in that, After the first security check passes, the bootloader startup unit performs a second security check on the application startup unit, including: After the first security check passes, the hash value of the first application startup data is decrypted using the second public key to obtain the second decrypted data. Calculate the hash value of the data in the application startup unit to obtain the second application startup data hash value; Compare the hash values of the second decrypted data and the second application startup data; The second security check passes when the hash value of the second decrypted data is the same as that of the second application startup data.
10. The secure startup method according to claim 9, characterized in that, Before performing a second security check on the application launch unit using the bootloader launch unit, the method further includes: The unused address space of the application startup unit is filled with random numbers.
11. A safe start device for a vehicle microprocessor, characterized in that, The vehicle microprocessor includes a root startup unit, a bootloader startup unit, and an application startup unit; the secure startup device includes: The first security verification unit is used to perform a first security verification on the boot program startup unit using the root startup unit in response to the power-on command of the vehicle microprocessor. The second security verification unit is used to perform a second security verification on the application startup unit using the bootloader startup unit after the first security verification is passed. The execution instruction issuing unit is used to issue an execution instruction to the vehicle's application program when the second security check passes.
12. An electronic device, characterized in that, include: processor; Memory, used to store computer programs; When the computer program is executed by the processor, the processor causes the processor to implement the secure boot method as described in any one of claims 1-10.
13. A non-transitory computer-readable storage medium having stored thereon computer-readable instructions that, when executed by a processor, cause the processor to perform the secure boot method as described in any one of claims 1-10.