Safe starting method and device of MCU, vehicle and storage medium

Abstract

The invention provides a safe starting method and device of an MCU, a vehicle and a storage medium. The method comprises the steps that when it is detected that an MCU of the vehicle-mounted wireless terminal is powered on, a BOOT1 is operated at first; then, whether the first authentication code is matched with a first preset authentication code or not is judged, and when the first authentication code is matched with the first preset authentication code, BOOT2 is operated; and then judging whether the second authentication code is matched with a second preset authentication code, and when the second authentication code is matched with the second preset authentication code, controlling to start the functional application of the MCU on the vehicle-mounted wireless terminal. According to the invention, the software information of the MCU of the vehicle-mounted wireless terminal can be effectively verified through the two-stage security authentication of the BOOT1 and the BOOT2, so that the content is effectively prevented from being tampered or implanted into illegal applications, and the security of starting the MCU is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a secure startup method for an MCU, a device, a vehicle, and a storage medium. Background Art

[0002] With the development of intelligent and networked automotive electronics, the requirements for information security are becoming more stringent. The secure startup of the vehicle-mounted wireless terminal (Telematics Box, TBOX) is an important part of the automotive electronics information security link. The vehicle-mounted wireless terminal is a key component that realizes remote monitoring, control and data transmission through the communication network. It undertakes functions such as vehicle remote diagnosis and location tracking.

[0003] In actual applications, the secure boot software can verify the software information in the MCU module to prevent the content from being tampered with or implanted into the running of illegal applications, thereby achieving secure boot of the MCU.

[0004] However, as the application scenarios of vehicle-mounted wireless terminals continue to expand, the security threats they face are also increasing (such as remote attacks, information leakage, malware, etc.). However, the existing technical solutions do not involve the secure startup of the MCU of the vehicle-mounted wireless terminal, which may lead to problems such as information leakage or illegal application running in the MCU of the vehicle-mounted wireless terminal.

[0005] It should be pointed out that the information disclosed in the background technology section of this application is only intended to deepen the understanding of the general background technology of this application, and should not be regarded as an admission or suggestion in any form that the information constitutes prior art already known to those skilled in the art. Summary of the invention

[0006] In view of this, the present application provides a secure startup method, device, vehicle and storage medium of an MCU, so as to solve the problem in the prior art that as the application scenarios of vehicle-mounted wireless terminals continue to expand, the security threats they face are also increasing (such as remote attacks, information leakage, malware, etc.). However, the prior art solutions do not involve the secure startup of the MCU of the vehicle-mounted wireless terminal, which may lead to the problem that the MCU of the vehicle-mounted wireless terminal may have information leakage or illegal application running.

[0007] In a first aspect, an embodiment of the present application provides a secure boot method for an MCU, which is applied to a vehicle-mounted wireless terminal, and the method includes:

[0008] When it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, BOOT1 is run;

[0009] Determine whether the first authentication code matches the first preset authentication code, the first authentication code is the authentication code determined by BOOT1 according to the acquired first secret key, and the first secret key is the secret key for verifying BOOT2;

[0010] When the first authentication code matches the first preset authentication code, running BOOT2;

[0011] Determine whether the second authentication code matches the second preset authentication code, where the second authentication code is an authentication code determined by BOOT2 according to the acquired second secret key, and the second secret key is a secret key for verifying the functional application of the MCU;

[0012] When the second authentication code matches the second preset authentication code, control is performed to start a function application of the MCU on the vehicle-mounted wireless terminal.

[0013] In the embodiment of the present application, when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, BOOT1 is first run; then, it is determined whether the first authentication code matches the first preset authentication code, and when the first authentication code matches the first preset authentication code, BOOT2 is run; then it is determined whether the second authentication code matches the second preset authentication code, and when the second authentication code matches the second preset authentication code, the function application of the MCU on the vehicle-mounted wireless terminal is controlled to be started. It can be understood that through the two-level security authentication of BOOT1 and BOOT2, the software information of the MCU of the vehicle-mounted wireless terminal can be effectively verified, effectively preventing the content from being tampered with or implanted with illegal applications, and improving the security of MCU startup.

[0014] In a possible implementation, determining whether the first authentication code matches the first preset authentication code includes:

[0015] Determine whether the MCU has activated the MCU secure boot function;

[0016] When the MCU activates the MCU secure boot function, it is determined whether the first authentication code matches the first preset authentication code.

[0017] In the embodiment of the present application, after running BOOT1, it is first determined whether the MCU activates the MCU secure boot function; when the MCU activates the MCU secure boot function, it is determined whether the first authentication code matches the first preset authentication code. It is understandable that, first, when the MCU does not activate the MCU secure boot function, BOOT1 cannot calculate the first authentication code, which may cause the MCU startup process to stay in BOOT1. Therefore, after running BOOT1, it is first determined whether the MCU activates the MCU secure boot function, which, to a certain extent, ensures the stability of the system.

[0018] In a possible implementation, determining whether the first authentication code matches the first preset authentication code includes:

[0019] Determine whether the first secret key obtained is empty;

[0020] When the first secret key is not empty, determining whether the first authentication code determined according to the first secret key matches the first preset authentication code;

[0021] When the first secret key is empty, run the BOOT2.

[0022] In the embodiment of the present application, it is also necessary to determine whether the first secret key obtained is empty; when the first secret key is not empty, determine whether the first authentication code determined according to the first secret key matches the first preset authentication code; when the first secret key is empty, run BOOT2. It can be understood that in actual applications, there may be a situation where the first secret key obtained is empty, at which time BOOT1 cannot calculate the first authentication code, which may cause the MCU startup process to stay in BOOT1. Therefore, first determine whether the first secret key is empty, to a certain extent, to ensure the stability of the system and reduce the time of verification.

[0023] In a possible implementation, when the second authentication code matches the second preset authentication code, controlling to start a functional application of the MCU on the vehicle-mounted wireless terminal includes:

[0024] When the second authentication code matches the second preset authentication code, starting the partial function application;

[0025] Determine whether a third authentication code matches a third preset authentication code, wherein the third authentication code is an authentication code determined by the partial functional application according to the obtained third secret key, and the third secret key is a secret key for verifying the functional application of the remaining part of the MCU;

[0026] When the third authentication code matches the third preset authentication code, control is performed to start the remaining functional applications on the vehicle-mounted wireless terminal.

[0027] In the embodiment of the present application, when the second authentication code matches the second preset authentication code, some functional applications are started; it is determined whether the third authentication code matches the third preset authentication code; when the third authentication code matches the third preset authentication code, the remaining functional applications on the vehicle-mounted wireless terminal are controlled to start. It can be understood that BOOT2 can only verify some functional applications, and the remaining functional applications are verified by the functional applications started at the beginning, which improves the startup speed of functional applications in the MCU to a certain extent.

[0028] In one possible implementation,

[0029] When the third authentication code does not match the third preset authentication code, the program jumps to and stays at BOOT2, and outputs a prompt message indicating that the MCU has a security risk.

[0030] In the embodiment of the present application, when the third authentication code does not match the third preset authentication code, it jumps and stays at BOOT2, and outputs a prompt message that the MCU has a security risk, thereby improving the security of MCU startup and improving the user experience.

[0031] In a possible implementation, the method further includes:

[0032] When it is detected that the functional application of the MCU is refreshed, determining whether the functional application of the MCU is successfully refreshed;

[0033] When the functional application of the MCU is successfully refreshed, the second preset authentication code is updated and the MCU is restarted.

[0034] In the embodiment of the present application, when it is detected that the functional application of the MCU is refreshed, it is determined whether the functional application of the MCU is successfully refreshed; when the functional application of the MCU is successfully refreshed, the second preset authentication code is updated, and the MCU is restarted. It can be understood that when the MCU supports the refresh function of the functional application, the corresponding second preset authentication code also needs to be updated, otherwise the security verification cannot pass, which improves the security of the MCU startup to a certain extent.

[0035] In a possible implementation, the method further includes:

[0036] When the first authentication code does not match the first preset authentication code, the current BOOT1 is stayed, and a prompt message indicating that the MCU has a security risk is output.

[0037] In the embodiment of the present application, when the first authentication code does not match the first preset authentication code, it stays at the current BOOT1 and outputs a prompt message that the MCU has a security risk, thereby improving the security of MCU startup and improving the user experience.

[0038] In a possible implementation, the method further includes:

[0039] When the second authentication code does not match the first preset authentication code, the current BOOT2 is stayed, and a prompt message indicating that the MCU has a security risk is output.

[0040] In the embodiment of the present application, when the second authentication code does not match the first preset authentication code, it stays at the current BOOT2 and outputs a prompt message that the MCU has a security risk, thereby improving the security of MCU startup and improving the user experience.

[0041] In a second aspect, an embodiment of the present application provides a secure booting device of an MCU, which is applied to a vehicle-mounted wireless terminal, including:

[0042] A BOOT1 running module, used to run BOOT1 when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on;

[0043] A first judgment module is used to judge whether a first authentication code matches a first preset authentication code, wherein the first authentication code is an authentication code determined by BOOT1 according to an acquired first secret key, and the first secret key is a secret key for verifying BOOT2;

[0044] A BOOT2 running module, configured to run the BOOT2 when the first authentication code matches the first preset authentication code;

[0045] A second judgment module is used to judge whether a second authentication code matches a second preset authentication code, wherein the second authentication code is an authentication code determined by BOOT2 according to an acquired second secret key, and the second secret key is a secret key for verifying a functional application of the MCU;

[0046] The control module is used for controlling and starting the function application of the MCU on the vehicle-mounted wireless terminal when the second authentication code matches the second preset authentication code.

[0047] In a third aspect, an embodiment of the present application provides a vehicle, characterized in that it includes:

[0048] processor;

[0049] Memory;

[0050] and a computer program, wherein the computer program is stored in the memory, the computer program comprising instructions, which, when executed by the processor, cause the vehicle to execute the method described in any one of the first aspects.

[0051] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, characterized in that the computer-readable storage medium includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the methods described in the first aspect.

[0052] It can be understood that the secure boot device of the MCU provided in the second aspect, the vehicle provided in the third aspect, and the computer-readable storage medium provided in the fourth aspect are all used to execute the method provided in the present application. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method, which will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0054] Figure 1 , which is a schematic diagram of the distribution of MCU software in Flash provided in an embodiment of the present application.

[0055] Figure 2 A flowchart of a secure boot method for an MCU provided in an embodiment of the present application.

[0056] Figure 3 A schematic diagram of the software operation changes of the MCU provided in the embodiment of the present application.

[0057] Figure 4 A schematic diagram of the structure of a secure boot device for an MCU provided in an embodiment of the present application.

[0058] Figure 5 A schematic diagram of the structure of a vehicle provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] In order to better understand the technical solution of the present application, the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0060] It should be clear that the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0061] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0062] It should be understood that the term "and / or" used in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0063] With the development of intelligent and networked automotive electronics, the requirements for information security in automotive electronics are becoming more and more stringent. The secure boot of vehicle-mounted wireless terminals is an important part of automotive electronic information security. In practical applications, secure boot software can verify the software information in the MCU module to prevent the content from being tampered with or implanted into the operation of illegal applications, thereby achieving secure boot of the MCU.

[0064] However, as the application scenarios of vehicle-mounted wireless terminals continue to expand, the security threats they face are also increasing (such as remote attacks, information leakage, malware, etc.). However, the existing technical solutions do not involve the secure startup of the MCU of the vehicle-mounted wireless terminal, which may lead to problems such as information leakage or illegal application running in the MCU of the vehicle-mounted wireless terminal.

[0065] In view of the above problems, in the embodiment of the present application, when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, BOOT1 is first run; then, it is determined whether the first authentication code matches the first preset authentication code, and when the first authentication code matches the first preset authentication code, BOOT2 is run; then it is determined whether the second authentication code matches the second preset authentication code, and when the second authentication code matches the second preset authentication code, the function application of the MCU on the vehicle-mounted wireless terminal is controlled to start. It can be understood that through the two-level security authentication of BOOT1 and BOOT2, the software information of the MCU of the vehicle-mounted wireless terminal can be effectively verified, and the content can be effectively prevented from being tampered with or implanted with illegal applications, thereby improving the security of MCU startup. Specifically, a detailed description is given below in conjunction with the accompanying drawings and specific embodiments.

[0066] For ease of understanding, BOOT1 and BOOT2 in the embodiments of the present application are first introduced in detail.

[0067] The software of the MCU of the vehicle-mounted wireless terminal is distributed in Flash and mainly includes two parts, namely the boot program part (BootLoader, BOOT) and the APP part (i.e., functional application). The secure boot function will be introduced in the boot program part to verify the security of the APP part.

[0068] Specifically, when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, the startup program part is started first, and the functional application part is safety verified; the functional application part is started only after the startup program part passes the safety verification of the functional application part; when the startup program part fails the safety verification of the functional application part, the functional application part will not be started.

[0069] Furthermore, in order to reduce the failure rate of the boot program and improve the security of MCU startup, the boot program can be divided into two levels, namely the security boot program (SBoot), which is BOOT1 mentioned above, and the custom boot program (CBoot), which is BOOT2 mentioned above. Among them, BOOT1 mainly includes the interface function and the security verification function of BOOT2; BOOT2 includes the basic refresh function and the verification of the functional application part.

[0070] To further understand the distribution of software in the MCU, see Figure 1 , is a schematic diagram of the distribution of MCU software in Flash provided by an embodiment of the present application. As shown in the figure, BOOT1, BOOT2 and functional applications are shown. Among them, Figure 1 As shown by the arrow in the middle, you can jump from BOOT1 to BOOT2, and from BOOT2 to the functional application.

[0071] The details are as follows, see Figure 2 , is a flow chart of a secure boot method of an MCU provided in an embodiment of the present application. Figure 2 As shown, it mainly includes the following steps.

[0072] Step S201: When it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, BOOT1 is run.

[0073] In the embodiment of the present application, when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, BOOT1 is executed. Specifically, when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, or awakened from a deep sleep state, the MCU executes BOOT1.

[0074] Step S202: Determine whether the first authentication code matches the first preset authentication code.

[0075] In the embodiment of the present application, after running BOOT1, it is determined whether the first authentication code matches the first preset authentication code. The first authentication code is the authentication code determined by BOOT1 based on the first secret key obtained, and the first secret key is the secret key for verifying BOOT2. Specifically, after running BOOT1, the first secret key is first obtained, and then the first authentication code corresponding to the first secret key is calculated; then, the first authentication code corresponding to the first secret key is compared and calculated to see whether it matches the first preset authentication code, thereby realizing the security verification of BOOT2.

[0076] Further, when the first authentication code corresponding to the first secret key matches the first preset authentication code, BOOT2 is executed. Specifically, it will be described in detail in step S203 below.

[0077] In a possible implementation, when the first authentication code corresponding to the first key does not match the first preset authentication code, the current BOOT1 is stayed and a prompt message indicating that the MCU has a security risk is output, thereby improving the security of MCU startup and improving the user experience.

[0078] In actual applications, the first secret key may be empty. At this time, BOOT1 cannot calculate the first authentication code, which may cause the MCU startup process to stay in BOOT1. In response to the above problem, in a possible implementation method, first determine whether the obtained first secret key is empty; when the first secret key is not empty, determine whether the first authentication code determined according to the first secret key matches the first preset authentication code; when the first secret key is empty, run BOOT2. It can be understood that first determining whether the first secret key is empty, to a certain extent, ensures the stability of the system, avoids the MCU startup process staying in BOOT1, and reduces the verification time.

[0079] In a possible implementation, it is determined whether the acquired first preset authentication code is empty. When the first preset authentication code is empty, a first preset authentication code is automatically written, and BOOT2 is run.

[0080] In actual applications, the secure boot function of the MCU may not be started. Therefore, after running BOOT1, you can first detect whether the MCU secure boot function is activated to prevent the MCU boot process from staying in BOOT1.

[0081] Specifically, in a possible implementation, after running BOOT1, first determine whether the MCU activates the MCU secure boot function; when the MCU activates the MCU secure boot function, determine whether the first authentication code matches the first preset authentication code. It is understandable that when the MCU does not activate the MCU secure boot function, BOOT1 cannot calculate the first authentication code, which may cause the MCU startup process to stay in BOOT1. Therefore, after running BOOT1, first determine whether the MCU activates the MCU secure boot function, which, to a certain extent, ensures the stability of the system.

[0082] Of course, in a possible implementation, when the MCU does not activate the MCU secure boot function, BOOT2 can be directly run.

[0083] It should be pointed out that the MCU secure boot function described above includes: the secure cryptographic unit (ICU-S) is turned on and the secure boot is activated. Among them, secure boot activation refers to using the driver interface of the secure cryptographic unit to generate the secret key required for MCU security monitoring.

[0084] Step S203: When the first authentication code matches the first preset authentication code, BOOT2 is executed.

[0085] In the embodiment of the present application, when the first authentication code matches the first preset authentication code, BOOT2 is run. It can be understood that when the first authentication code matches the first preset authentication code, it indicates that there is no security problem with BOOT2. At this time, BOOT2 is controlled to run to realize the detection of the functional application of the MCU.

[0086] Step S204: Determine whether the second authentication code matches the second preset authentication code.

[0087] In the embodiment of the present application, after running BOOT2, it is determined whether the second authentication code matches the second preset authentication code, wherein the second authentication code is an authentication code determined by BOOT2 based on the acquired second secret key, and the second secret key is a secret key for verifying the functional application of the MCU. Specifically, after running BOOT2, the second secret key is first obtained, and then the second authentication code corresponding to the second secret key is calculated; then, the second authentication code corresponding to the second secret key is compared and calculated to see whether it matches the second preset authentication code, thereby realizing the security verification of the functional application of the MCU.

[0088] Further, when the second authentication code corresponding to the second secret key matches the second preset authentication code, the function application of the MCU on the vehicle-mounted wireless terminal is started. Specifically, it will be described in detail in step S205 below.

[0089] In a possible implementation, when the second authentication code corresponding to the second key does not match the second preset authentication code, it stays at the current BOOT2 and outputs a prompt message that the MCU has a security risk, thereby improving the security of MCU startup and improving the user experience.

[0090] In actual applications, the secure boot function of the MCU may not be started or turned off. Therefore, after running BOOT2, you can first detect whether the MCU secure boot function is activated to prevent the MCU boot process from staying in BOOT2.

[0091] Specifically, in a possible implementation, after running BOOT2, first determine whether the MCU activates the MCU secure boot function; when the MCU activates the MCU secure boot function, determine whether the second authentication code matches the second preset authentication code. It is understandable that when the MCU does not activate the MCU secure boot function, BOOT2 cannot calculate the second authentication code, which may cause the MCU startup process to stay in BOOT2. Therefore, after running BOOT2, first determine whether the MCU activates the MCU secure boot function, which, to a certain extent, ensures the stability of the system.

[0092] Of course, in a possible implementation, when the MCU does not activate the MCU secure boot function, the functional application of the MCU can be directly run.

[0093] Step S205: When the second authentication code matches the second preset authentication code, control to start the function application of the MCU on the vehicle-mounted wireless terminal.

[0094] In the embodiment of the present application, when the second authentication code matches the second preset authentication code, the function application of the MCU on the vehicle-mounted wireless terminal is controlled to be started. It can be understood that when the second authentication code matches the second preset authentication code, it means that there is no security problem with the function application of the MCU, so the function application of the MCU on the vehicle-mounted wireless terminal can be directly controlled to be started.

[0095] In the embodiment of the present application, when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, BOOT1 is first run; then, it is determined whether the first authentication code matches the first preset authentication code, and when the first authentication code matches the first preset authentication code, BOOT2 is run; then it is determined whether the second authentication code matches the second preset authentication code, and when the second authentication code matches the second preset authentication code, the function application of the MCU on the vehicle-mounted wireless terminal is controlled to be started. It can be understood that through the two-level security authentication of BOOT1 and BOOT2, the software information of the MCU of the vehicle-mounted wireless terminal can be effectively verified, effectively preventing the content from being tampered with or implanted with illegal applications, and improving the security of MCU startup.

[0096] In actual applications, in order to further improve the startup time of functional applications, BOOT2 can be set to verify only some of the functional applications of the MCU; then, when BOOT2 verifies and passes some of the functional applications of the MCU, the MCU can start these functional applications, and the remaining functional applications are verified by the started functional applications, which improves the startup speed of the functional applications in the MCU to a certain extent.

[0097] Specifically, in one possible implementation, when the second authentication code matches the second preset authentication code, some functional applications are started; then, it is determined whether the third authentication code matches the third preset authentication code; when the third authentication code matches the third preset authentication code, control is performed to start the remaining functional applications on the vehicle-mounted wireless terminal.

[0098] For easier understanding, see Figure 3 , which is a schematic diagram of the software working changes of the MCU provided in the embodiment of the present application. As shown in the figure, the software of the MCU is distributed in Flash and includes four parts, namely BOOT1, BOOT2, some functional applications and the remaining functional applications. Specifically, first, as Figure 3 As shown in the leftmost picture, BOOT1 is run to perform security verification on the software information of BOOT2; when the software information of BOOT2 is verified, Figure 3 As shown in the middle picture, BOOT2 is run to perform security verification on some functional applications; when some functional applications pass the verification, Figure 3 As shown in the picture on the right, some functional applications are run to perform security verification on the remaining functional applications.

[0099] It can be understood that BOOT2 can verify only part of the functional applications, while the remaining functional applications are verified by the functional applications started at the beginning, which improves the startup speed of the functional applications in the MCU to a certain extent.

[0100] Of course, in a possible implementation, when the third authentication code does not match the third preset authentication code, the program jumps to and stays at BOOT2, and outputs a prompt message that the MCU has a security risk, thereby improving the security of MCU startup and improving the user experience.

[0101] In actual applications, since the MCU supports the refresh function of the functional application, once the functional application of the MCU is refreshed, the second preset authentication code of the functional application of the MCU needs to be updated, otherwise the secure boot cannot pass.

[0102] Specifically, in a possible implementation, when it is detected that the functional application of the MCU is refreshed, it is determined whether the functional application of the MCU is successfully refreshed; when the functional application of the MCU is successfully refreshed, the second preset authentication code is updated, and the MCU is restarted. It can be understood that when the MCU supports the refresh function of the functional application, the corresponding second preset authentication code also needs to be updated, otherwise the security verification cannot pass, which improves the security of the MCU startup to a certain extent.

[0103] Furthermore, in addition to the secure boot function described above, the functions of the MCU based on the in-vehicle wireless terminal also include: secure boot maintenance. Among them, the secure boot maintenance function refers to the verification of secure boot activation, secure boot deactivation, secure boot activation status query and ICU-S start status query required for the secure boot function during production and after-sales. For ease of understanding, the secure boot activation, secure boot deactivation, secure boot activation status query and ICU-S start status query functions are introduced below.

[0104] First, secure boot activation: use the ICU-S driver interface to generate the secret key required for secure boot, and use the secret key to calculate the corresponding message authentication code and store it in ICU-S. These secret keys and message authentication code pairs will be used during secure boot verification. Second, secure boot deactivation: delete all the secret keys in ICU-S, and secure boot verification will no longer be performed during startup. This function can be used to reset the secure boot function and restore components with secure boot abnormalities. Third, secure boot activation status query: that is, obtain the activation mark bit in the secure boot activation step. Fourth, ICU-S status query: obtain the ICU-S startup status.

[0105] Corresponding to the above embodiments, the present application also provides a secure booting device for an MCU.

[0106] See also Figure 4 , is a schematic diagram of the structure of a secure boot device for an MCU provided in an embodiment of the present application. Figure 4 As shown, the MCU security boot device 400 mainly includes the following modules: BOOT1 running module 401, first judgment module 402, BOOT2 running module 403, second judgment module 404 and control module 405. Among them, the BOOT1 running module is used to run BOOT1 when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on; the first judgment module is used to judge whether the first authentication code matches the first preset authentication code; the BOOT2 running module is used to run BOOT2 when the first authentication code matches the first preset authentication code; the second judgment module is used to judge whether the second authentication code matches the second preset authentication code; the control module is used to control the startup of the function application of the MCU on the vehicle-mounted wireless terminal when the second authentication code matches the second preset authentication code.

[0107] Corresponding to the above embodiment, the present application also provides a vehicle. Figure 5, which is a schematic diagram of the structure of a vehicle provided in an embodiment of the present application. The vehicle 500 may include: a processor 501, a memory 502, and a communication unit 503. These components communicate through one or more buses. Those skilled in the art will appreciate that the structure of the vehicle shown in the figure does not constitute a limitation on the embodiment of the present invention. It may be a bus structure or a star structure, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0108] The communication unit 503 is used to establish a communication channel so that the vehicle can communicate with other devices, receive user data sent by other devices or send user data to other devices.

[0109] The processor 501 is the control center of the vehicle. It uses various interfaces and lines to connect various parts of the entire vehicle. It runs or executes software programs, instructions, and / or modules stored in the memory 502, and calls data stored in the memory to perform various functions of the vehicle and / or process data. The processor can be composed of an integrated circuit (IC), for example, it can be composed of a single packaged IC, or it can be composed of a plurality of packaged ICs with the same or different functions. For example, the processor 501 can include only a central processing unit (CPU). In the embodiment of the present invention, the CPU can be a single computing core or multiple computing cores.

[0110] The memory 502 is used to store the execution instructions of the processor 501. The memory 502 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0111] When the execution instructions in the memory 502 are executed by the processor 501, the vehicle 500 is able to execute Figure 1 Some or all of the steps in the illustrated embodiments.

[0112] In a specific implementation, the present invention further provides a computer storage medium, wherein the computer storage medium may store a program, and when the program is executed, the program may include some or all of the steps in each embodiment of the simulation scene generation method provided by the present invention. The storage medium may be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0113] In a specific implementation, the present invention further provides a computer program product, wherein the computer program product includes executable instructions, and when the executable instructions are executed on a computer, the computer executes part or all of the steps in each embodiment of the simulation scene generation method provided by the present invention.

[0114] In the embodiments of the present application, "at least one" refers to one or more, and "plurality" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent the existence of A alone, the existence of A and B at the same time, and the existence of B alone. Among them, A and B can be singular or plural. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b and c can be represented by: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0115] Those of ordinary skill in the art will appreciate that the various units and algorithm steps described in the embodiments disclosed herein can be implemented in a combination of electronic hardware, computer software, and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0116] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0117] In several embodiments provided in the present application, if any function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0118] In this specification, the same or similar parts between the various embodiments can be referred to each other. In particular, for the device embodiment and the terminal embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiment.

Claims

1. A secure boot method for MCU, characterized in that: Applied to a vehicle-mounted wireless terminal, the method comprises: When it is detected that the MCU of the vehicle-mounted wireless terminal is powered on, BOOT1 is run; Determine whether the first authentication code matches the first preset authentication code, the first authentication code is the authentication code determined by BOOT1 according to the acquired first secret key, and the first secret key is the secret key for verifying BOOT2; When the first authentication code matches the first preset authentication code, running BOOT2; Determine whether the second authentication code matches the second preset authentication code, where the second authentication code is an authentication code determined by BOOT2 according to the acquired second secret key, and the second secret key is a secret key for verifying the functional application of the MCU; When the second authentication code matches the second preset authentication code, control is performed to start a function application of the MCU on the vehicle-mounted wireless terminal.

2. The method according to claim 1, characterized in that The determining whether the first authentication code matches the first preset authentication code includes: Determine whether the MCU has activated the MCU secure boot function; When the MCU activates the MCU secure boot function, it is determined whether the first authentication code matches the first preset authentication code.

3. The method according to claim 1, characterized in that The determining whether the first authentication code matches the first preset authentication code includes: Determine whether the first secret key obtained is empty; When the first secret key is not empty, determining whether the first authentication code determined according to the first secret key matches the first preset authentication code; When the first secret key is empty, run the BOOT2.

4. The method according to claim 1, characterized in that: When the second authentication code matches the second preset authentication code, controlling to start the function application of the MCU on the vehicle-mounted wireless terminal includes: When the second authentication code matches the second preset authentication code, starting the partial function application; Determine whether a third authentication code matches a third preset authentication code, wherein the third authentication code is an authentication code determined by the partial functional application according to the obtained third secret key, and the third secret key is a secret key for verifying the functional application of the remaining part of the MCU; When the third authentication code matches the third preset authentication code, control is performed to start the remaining functional applications on the vehicle-mounted wireless terminal.

5. The method according to claim 4, characterized in that When the third authentication code does not match the third preset authentication code, the program jumps to and stays at BOOT2, and outputs a prompt message indicating that the MCU has a security risk.

6. The method according to claim 1, characterized in that Also includes: When it is detected that the functional application of the MCU is refreshed, determining whether the functional application of the MCU is successfully refreshed; When the functional application of the MCU is successfully refreshed, the second preset authentication code is updated and the MCU is restarted.

7. The method according to claim 1, characterized in that Also includes: When the first authentication code does not match the first preset authentication code, the current BOOT1 is stayed, and a prompt message indicating that the MCU has a security risk is output.

8. The method according to claim 1, characterized in that Also includes: When the second authentication code does not match the second preset authentication code, the current BOOT2 is stayed, and a prompt message indicating that the MCU has a security risk is output.

9. A secure boot device for MCU, characterized in that: Applied to vehicle-mounted wireless terminals, including: A BOOT1 running module, used to run BOOT1 when it is detected that the MCU of the vehicle-mounted wireless terminal is powered on; A first judgment module is used to judge whether a first authentication code matches a first preset authentication code, wherein the first authentication code is an authentication code determined by BOOT1 according to an acquired first secret key, and the first secret key is a secret key for verifying BOOT2; A BOOT2 running module, configured to run the BOOT2 when the first authentication code matches the first preset authentication code; A second judgment module is used to judge whether a second authentication code matches a second preset authentication code, wherein the second authentication code is an authentication code determined by BOOT2 according to an acquired second secret key, and the second secret key is a secret key for verifying a functional application of the MCU; The control module is used for controlling and starting the function application of the MCU on the vehicle-mounted wireless terminal when the second authentication code matches the second preset authentication code.

10. A vehicle, characterized in that: include: processor; Memory; and a computer program, wherein the computer program is stored in the memory, the computer program comprising instructions, which, when executed by the processor, cause the vehicle to perform the method of any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the method according to any one of claims 1 to 8.

Images