Safe starting method and system

Abstract

The invention provides a safe starting method and system. The secure startup method comprises the following steps: burning a plurality of generated startup signatures into corresponding memory mappings respectively, and embedding a startup public key into a verification code at the same time; and after the security core is powered on, activating the user core, acquiring a corresponding starting signature as a target signature according to the memory mapping currently operated by the security core, and performing security starting verification on the target signature according to the starting public key so as to start an executive program corresponding to the memory mapping where the target signature is located when the verification is passed. According to the method, a new signature value does not need to be calculated by spending additional actions, so that the operation load of the security core is reduced, and additional system risks are reduced; the public key is stored in the verification code, and the public key does not need to be additionally imported, so that the risk that the public key outside the production line is mistakenly imported is not caused, and the public key is not transferred among multiple parties, thereby reducing the risk of public key leakage; and meanwhile, a parallel starting verification mode is adopted, so that the platform starting time is shortened.

Description

Technical Field

[0001] The present application relates to the field of vehicle safety technology, and in particular to a safety startup method and system. Background Art

[0002] In the automotive electronics industry, as automotive central control products become more complex, the informatization of central control products has become more complex, making customers' requirements for product information security increasingly stringent. One of the functional requirements is secure boot.

[0003] The current secure boot adopts a serial boot method, which increases the boot performance of the platform and fails to meet the performance requirements of users for the platform boot time. In addition, when developers refresh the program online, the new boot signature will not be automatically recalculated, resulting in a secure boot verification failure every time the new software is burned to the platform offline, thereby increasing the development time cost of developers. In addition, the introduction of additional private keys in the production line is prone to the risk of private key misdirection, and there is also the risk of leakage caused by the transfer of private keys through multiple parties. Summary of the invention

[0004] In order to solve the above technical problems, the present application provides a safe startup method and system with high security and capable of reducing platform startup time.

[0005] Specifically, the present application provides a secure startup method, comprising the following steps: S100: Generate multiple startup signatures based on an external server, burn each startup signature into a corresponding memory map, and embed the startup public key into the verification code in advance.

[0006] S200: After the security core is powered on, the user core is activated, and a corresponding startup signature is obtained according to the memory map currently running on the security core as a target signature.

[0007] And S300: performing secure boot verification on the target signature according to the boot public key, so as to start the execution program corresponding to the memory mapping where the target signature is located when the verification passes.

[0008] In the above technical solution, when applied in the upgrade process, since the startup signature corresponding to the new software is itself stored in the corresponding memory mapping, the security core does not need to take additional actions to calculate the new signature value during the upgrade process, so as to reduce the running load of the security core, simplify the upgrade process, and reduce additional system risks; and the public key is stored in the verification code, and the production line does not need to import the public key additionally, which will not cause the risk of external public key of the production line being misdirected, and it will not be transferred between multiple parties, thereby reducing the risk of public key leakage.

[0009] In addition, this application adopts a parallel startup verification method, that is, after the safety core is powered on, the user core will be activated immediately so that the user core can start normally when the safety core is verified, thereby reducing the platform startup time; at the same time, because the startup signature is generated on an external server, it is convenient for subsequent engineers to determine the cause of platform abnormalities.

[0010] Furthermore, the generating of multiple startup signatures in step S100 includes: Generate multiple pairs of startup public keys and startup private keys, and input the startup private keys and their corresponding memory mappings into a preset encryption algorithm to output corresponding startup signatures.

[0011] In the above technical solution, each pair of startup public key and startup private key corresponds to a different memory mapping. Different programs can be stored for different memory mappings, so that independent security verification can be performed on each memory mapping later, effectively preventing unauthorized program startup or malware injection.

[0012] Furthermore, the step S100 further includes: Generate a pair of boot public key and boot private key.

[0013] A memory map corresponding to the boot private key is predetermined, the boot private key and its corresponding memory map are input into a preset encryption algorithm to output a corresponding boot signature, and the boot signature is burned into the memory map corresponding to the boot private key.

[0014] At the same time, the boot public key is embedded in the verification code.

[0015] In the above technical solution, by burning the boot signature into the memory map, it can be ensured that all codes and data are verified and authorized. Any unauthorized modification will cause the signature verification to fail, thereby preventing malware or unauthorized modifications from affecting the platform startup. The boot public key is also embedded in the verification code to prevent import errors in the production line and the risk of leakage through multiple transfers.

[0016] Furthermore, after the safety core in step S200 is powered on, the following steps are further included: Check whether the startup public key and boot public key exist in the current verification code. If so, enable secure startup verification; otherwise, enter the penalty process.

[0017] In the above technical solution, by detecting whether the startup public key and the boot public key exist in the verification code, it can be determined whether the startup verification conditions are currently met to prevent unauthorized or tampered programs from running, and also ensure the integrity of the verification process, thereby ensuring the integrity and security of the platform; by entering the penalty process, action can be taken quickly when potential problems are detected.

[0018] Further, the memory mapping corresponds to a memory identifier, and the startup verification includes: The memory identifier is read, and the memory map currently running in the security core is determined according to the memory identifier to obtain the target signature and extract the boot signature.

[0019] In the above technical solution, by reading the memory identifier to determine the current memory mapping, the memory area in which the system is currently running can be accurately known, which can ensure that the verification process is performed for the correct memory mapping, thereby improving the accuracy and effectiveness of the verification.

[0020] Furthermore, the step S300 includes: The startup public key and the boot public key are obtained to perform secure startup verification on the target signature and the boot signature respectively through the startup public key and the boot public key, so that when both are verified, the execution program corresponding to the memory mapping where the target signature is located is started, and the verification result is stored in the storage partition in the security core.

[0021] If the target signature and / or boot signature verification fails, a penalty process is entered, and the verification result is stored in a storage partition in the security core.

[0022] In the above technical solution, the target signature and the boot signature are verified by using the startup public key and the boot public key respectively, so as to ensure that the platform performs a complete security check when it starts; if the verification passes, the execution program corresponding to the memory mapping where the target signature is located is started. This mechanism ensures that only verified memory mappings can be executed, thereby enhancing the execution control of the platform; the verification results are automatically stored in the storage partition in the security core. This automated recording and storage mechanism can facilitate subsequent auditing and analysis, and provide a transparent record of the system operation status.

[0023] Furthermore, the penalty process includes: After a first preset time, the platform corresponding to the security core is restarted; and after a second preset time, the current verification result is obtained based on the storage partition, and the verification result is recorded through the user core.

[0024] In the above technical solution, restarting the platform after the first preset time can help clear potential error states or temporary problems, and the delayed restart method allows developers to better confirm whether the failed platform is related to the security startup failure during after-sales failure analysis. At the same time, the user core also adds a verification record function, which allows developers to better analyze problems through record content.

[0025] Furthermore, after verification, it also includes: With the third preset time as a cycle, a verification signal is initiated through the user core, and the process returns to step S200 to perform the secure boot verification again.

[0026] In the above technical solution, regular re-verification can continuously maintain the security of the platform. Even after the initial verification, it may still be subject to new security threats or configuration changes. Therefore, regular verification can timely discover and respond to new security risks.

[0027] Furthermore, each startup signature is also stored in the server, and when the platform is abnormal, it also includes: The memory mapping of the platform is extracted as the target mapping, and the target mapping and the corresponding startup private key are input into a preset encryption algorithm to output the corresponding startup signature as the detection signature, and at the same time, the startup signature corresponding to the detection signature is extracted from the server as the judgment signature.

[0028] The detection signature is compared with the judgment signature. If they are consistent, it is determined that the platform abnormality is not related to the secure boot verification. Otherwise, it is determined that the platform abnormality is related to the secure boot verification.

[0029] In the above technical solution, by comparing the detection signature and the judgment signature, it can be clear whether the platform abnormality is related to the secure boot verification process, which can help quickly locate the root cause of the problem and distinguish the correlation between the platform abnormality and the secure boot verification; by comparing the detection signature with the judgment signature in the server, it can be verified whether the platform has executed the secure boot process as expected, ensuring the consistency of the boot signature, and helping to discover any abnormalities or tampering during the platform startup process.

[0030] Based on the same concept, the present application provides a secure boot system, including: The generation module is used to generate multiple startup signatures based on an external server, burn each startup signature into the corresponding memory map, and embed the startup public key into the verification code in advance.

[0031] The acquisition module is used to activate the user core after the security core is powered on, and obtain the corresponding startup signature as the target signature according to the memory map currently running in the security core.

[0032] And a startup verification module, which is used to perform secure startup verification on the target signature according to the startup public key, so as to start the execution program corresponding to the memory mapping where the target signature is located when the verification passes.

[0033] In the above technical solution, during the upgrade process, the startup signature of the new software has been stored in the corresponding memory map, so the security core does not need to recalculate the new signature value, which not only reduces the computing load of the security core, but also simplifies the upgrade process; since the startup signature has been pre-stored in the memory map, no additional signature calculation steps are required during the upgrade, thereby simplifying the upgrade operation, which reduces the complexity of the operation and reduces the possibility of errors in the platform during the upgrade process. At the same time, it avoids the need for additional steps to import public keys during the production process of the production line, reducing the possibility of public key leakage or misuse.

[0034] In addition, a parallel startup verification method is adopted, that is, the user core is activated immediately after the safety core is powered on. This parallel processing method can enable the user core to start normally when the safety core is verified, thereby shortening the overall platform startup time.

[0035] Compared with the prior art, the beneficial effects of this application are: This application first burns the generated multiple startup signatures into the corresponding memory mappings respectively, and embeds the startup public key into the verification code in advance; after the security core is powered on, the user core is activated, and the corresponding startup signature is obtained according to the memory mapping currently running by the security core as the target signature, and then the target signature is securely booted and verified according to the startup public key, so that when the verification passes, the execution program corresponding to the memory mapping where the target signature is located is started.

[0036] The startup signature of this application is itself stored in the memory mapping, and no additional actions are required to calculate the new signature value, so as to reduce the operating load of the security core and reduce additional system risks; and the public key is stored in the verification code, and the production line does not need to import the public key additionally, so there is no risk of external public key of the production line being misdirected, and it will not be transferred between multiple parties, thereby reducing the risk of public key leakage; at the same time, a parallel startup verification method is adopted to reduce the platform startup time. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 This is a flow chart of the secure startup method described in Example 1.

[0038] Figure 2 This is a framework diagram of the secure boot system described in Example 4. DETAILED DESCRIPTION

[0039] A secure startup method and system of the present application will be further described in detail below in conjunction with specific embodiments and drawings.

[0040] Embodiment 1: See also Figure 1 , the present application provides a secure boot method, comprising the following steps: S100: Generate multiple startup signatures based on an external server, burn each startup signature into a corresponding memory map, and embed the startup public key into the verification code in advance.

[0041] In this embodiment, the memory of the chip platform (such as MCU) for storing code programs is designed as A and B sides, that is, two parts of memory mapping.

[0042] Among them, side A represents a relatively low effective address area, and side B represents a relatively high effective address area.

[0043] It should be noted that those skilled in the art may also design the memory mapping according to actual application requirements, and the present invention is not limited thereto.

[0044] Furthermore, the generating of multiple startup signatures in step S100 includes: Generate multiple pairs of startup public keys and startup private keys, and input the startup private keys and their corresponding memory mappings into a preset encryption algorithm to output corresponding startup signatures.

[0045] In this embodiment, the startup public key and the startup private key are generated using the openssl open source tool; assuming there is a function F_en(X,Y), the input X is the startup private key, Y is the memory mapping of the startup private key to be calculated, F_en(X,Y) represents using X and Y as input and using the preset encryption algorithm en (such as RSA algorithm) to output a startup signature corresponding to the startup private key.

[0046] It should be noted that the preset encryption algorithm is preferably an asymmetric encryption algorithm RSA_PKCS1-V1.5, and the key length is preferably 4096 bits. This encryption method has high security, and the current mainstream key length is at least 1024 bits, while the key length of 4096 bits far exceeds this standard, making the encrypted data more difficult to crack. At the same time, RSA_PKCS1-V1.5 is a widely used encryption standard, supported by many software and hardware platforms, and has good compatibility; in addition, the implementation of the RSA algorithm is relatively simple and clear, which enables it to be quickly deployed and implemented in various application scenarios.

[0047] Furthermore, after the startup public key is generated, it is necessary to first import the startup public key into the verification code.

[0048] In the above technical solution, each pair of startup public key and startup private key corresponds to a different memory mapping. Different programs can be stored for different memory mappings, so that independent security verification can be performed on each memory mapping later, effectively preventing unauthorized program startup or malware injection.

[0049] Furthermore, the step S100 further includes: Generate a pair of boot public key and boot private key.

[0050] A memory map corresponding to the boot private key is predetermined, the boot private key and its corresponding memory map are input into a preset encryption algorithm to output a corresponding boot signature, and the boot signature is burned into the memory map corresponding to the boot private key.

[0051] At the same time, the boot public key is embedded in the verification code.

[0052] In this embodiment, side A also includes a boot area, which stores key startup code or program modules in the boot process. This part of the code is responsible for initializing system hardware, loading the operating system or application, and transferring control to the main program (i.e., the corresponding program in the memory map).

[0053] The program corresponding to the boot area is the first program started by the platform and is the basis for startup. All subsequent operations and programs depend on it; therefore, it must be executed when the platform starts.

[0054] Here, it is necessary to generate a key corresponding to the boot area so as to perform corresponding verification when executing the program in the boot area.

[0055] It should be noted that the method of generating the boot public key and the boot private key, and obtaining the boot signature is the same as the above-mentioned startup public key, startup private key and startup signature, and will not be repeated here.

[0056] Furthermore, after the boot public key is generated, it is necessary to first import the boot public key into the verification code.

[0057] In the above technical solution, by burning the boot signature into the memory map, it can be ensured that all codes and data are verified and authorized. Any unauthorized modification will cause the signature verification to fail, thereby preventing malware or unauthorized modifications from affecting the platform startup. The boot public key is also embedded in the verification code to prevent import errors in the production line and the risk of leakage through multiple transfers.

[0058] S200: After the security core is powered on, the user core is activated, and a corresponding startup signature is obtained according to the memory map currently running on the security core as a target signature.

[0059] In this embodiment, a parallel secure boot method is adopted. When applied to MCU, the MCU belongs to a chip platform with an independent security core. Parallel secure boot means that the security core will be started first as the boot core after the machine is powered on, and then the user core will be activated and awakened before the secure boot task is started, and then the process of each doing its own job will be entered (that is, the security core performs its own time-consuming secure boot verification process, and the user core starts normally).

[0060] After the user core is started, it starts running its own program. At this time, the security core will start to perform corresponding security verification logic without affecting the performance of the user core.

[0061] Furthermore, after the safety core in step S200 is powered on, the following steps are further included: Check whether the startup public key and boot public key exist in the current verification code. If so, enable secure startup verification; otherwise, enter the penalty process.

[0062] In this embodiment, it is first checked whether the startup public key and the boot public key are imported into the verification code. If they are not imported, it means that the security startup verification conditions are insufficient and no verification will be performed in this round. If the public key is imported, the security startup verification is turned on to determine which side, A or B, is the valid side.

[0063] In the above technical solution, by detecting whether the startup public key and the boot public key exist in the verification code, it can be determined whether the startup verification conditions are currently met to prevent unauthorized or tampered programs from running, and also ensure the integrity of the verification process, thereby ensuring the integrity and security of the platform; by entering the penalty process, action can be taken quickly when potential problems are detected.

[0064] Further, the memory mapping corresponds to a memory identifier, and the startup verification includes: The memory identifier is read, and the memory map currently running in the security core is determined according to the memory identifier to obtain the target signature and extract the boot signature.

[0065] In this embodiment, each memory mapping uniquely corresponds to a memory identifier, and the memory identifier is used to identify the state or position of the current memory mapping, and generally includes information such as the starting address and size of the memory area.

[0066] When the security core starts, the memory identifier corresponding to the current memory mapping is first read, and the currently running memory mapping is determined based on the read memory identifier; through the memory mapping, the startup signature stored therein is read as the target signature, and the boot signature is extracted from the memory mapping storing the boot signature.

[0067] In the above technical solution, by reading the memory identifier to determine the current memory mapping, the memory area in which the system is currently running can be accurately known, which can ensure that the verification process is performed for the correct memory mapping, thereby improving the accuracy and effectiveness of the verification.

[0068] And S300: performing secure boot verification on the target signature according to the boot public key, so as to start the execution program corresponding to the memory mapping where the target signature is located when the verification passes.

[0069] Furthermore, the step S300 includes: The startup public key and the boot public key are obtained to perform secure startup verification on the target signature and the boot signature respectively through the startup public key and the boot public key, so that when both are verified, the execution program corresponding to the memory mapping where the target signature is located is started, and the verification result is stored in the storage partition in the security core.

[0070] If the target signature and / or boot signature verification fails, a penalty process is entered, and the verification result is stored in a storage partition in the security core.

[0071] In this embodiment, after the corresponding target signature is obtained, the integrity and authenticity of the corresponding memory mapping will be further determined.

[0072] If side A is valid, the acquired target signature and boot signature are verified using the startup public key and the boot public key. If the verification passes, the execution program corresponding to side A is started.

[0073] If the B side is valid, a corresponding check is performed, and when the check passes, the execution program corresponding to the B side is started.

[0074] In the above technical solution, the target signature and the boot signature are verified by using the startup public key and the boot public key respectively, so as to ensure that the platform performs a complete security check when it starts; if the verification passes, the execution program corresponding to the memory mapping where the target signature is located is started. This mechanism ensures that only verified memory mappings can be executed, thereby enhancing the execution control of the platform; the verification results are automatically stored in the storage partition in the security core. This automated recording and storage mechanism can facilitate subsequent auditing and analysis, and provide a transparent record of the system operation status.

[0075] Furthermore, the penalty process includes: After a first preset time, the platform corresponding to the security core is restarted; and after a second preset time, the current verification result is obtained based on the storage partition, and the verification result is recorded through the user core.

[0076] In this embodiment, if the security check fails within the first preset time, such as 10s, it means that the current software is unauthorized software or the software has been illegally tampered with, and the platform is restarted after 10s; in addition, within this 10s, after 5s (i.e., the second preset time) of the user core running in parallel, the user core will query the security core for the verification result, and the obtained verification result will be logged and saved for subsequent failure analysis.

[0077] It should be noted that the second preset time is adjusted according to the time of the safety core's safety boot verification, and it is necessary to ensure that the safety core can complete the verification process within the second preset time.

[0078] Furthermore, the first preset time is not limited to 10 seconds, and those skilled in the art can adjust it according to actual application requirements.

[0079] In the above technical solution, restarting the platform after the first preset time can help clear potential error states or temporary problems, and the delayed restart method allows developers to better confirm whether the failed platform is related to the security startup failure during after-sales failure analysis. At the same time, the user core also adds a verification record function, which allows developers to better analyze problems through record content.

[0080] Embodiment 2: This application also provides a verification method after completing a verification, including: When the verification is passed, a verification signal is initiated through the user core with a third preset time period, and the process returns to step S200 described in the first embodiment to perform secure boot verification again.

[0081] If the first embodiment completes a secure boot verification process and passes it, the platform will enter the next verification mechanism. That is, since the user code has passed the security verification in the previous round, the user code now belongs to the trusted area, and the subsequent user core will start a secure boot verification with a period of 1 hour (i.e., the third preset time). The verification process is the same as the first embodiment, but it occurs in a different period and space (i.e., a different verification initiator).

[0082] In the above technical solution, regular re-verification can continuously maintain the security of the platform. Even after the initial verification, it may still be subject to new security threats or configuration changes. Therefore, regular verification can timely discover and respond to new security risks.

[0083] Embodiment three: This application also provides a method for engineers to perform platform failure analysis, specifically: Each startup signature is also stored in the server. When the platform is abnormal, it includes: The memory mapping of the platform is extracted as the target mapping, and the target mapping and the corresponding startup private key are input into a preset encryption algorithm to output the corresponding startup signature as the detection signature, and at the same time, the startup signature corresponding to the detection signature is extracted from the server as the judgment signature.

[0084] The detection signature is compared with the judgment signature. If they are consistent, it is determined that the platform abnormality is not related to the secure boot verification. Otherwise, it is determined that the platform abnormality is related to the secure boot verification.

[0085] Among them, the boot signature itself is generated by the external server of the current platform. When the boot signature is burned to the memory map, a copy will also be retained in the server. Engineers can read the boot signature in the memory map of the failed / problematic platform to compare it with the corresponding signature in the server. If they are consistent, it is considered that the current platform failure / problem is not related to the failure of secure boot verification, otherwise it is considered to be related; this helps engineers quickly locate the problem.

[0086] In the above technical solution, by comparing the detection signature and the judgment signature, it can be clear whether the platform abnormality is related to the secure boot verification process, which can help quickly locate the root cause of the problem and distinguish the correlation between the platform abnormality and the secure boot verification; by comparing the detection signature with the judgment signature in the server, it can be verified whether the platform has executed the secure boot process as expected, ensuring the consistency of the boot signature, and helping to discover any abnormalities or tampering during the platform startup process.

[0087] Embodiment 4: See also Figure 2 , the present application provides a secure boot system, comprising: The generation module is used to generate multiple startup signatures based on an external server, burn each startup signature into the corresponding memory map, and embed the startup public key into the verification code in advance.

[0088] In this embodiment, the startup signature is generated by an external server, and then burned into each memory map corresponding to the platform (such as MCU), and the public key is imported into the verification code.

[0089] The acquisition module is used to activate the user core after the security core is powered on, and obtain the corresponding startup signature as the target signature according to the memory map currently running in the security core.

[0090] After the user core is powered on, it will be quickly activated. At this time, the user core starts to run its own code, and the security core starts the secure boot verification process without affecting the performance of the user core.

[0091] And a startup verification module is used to perform secure startup verification on the target signature according to the startup public key, so as to start the execution program corresponding to the memory mapping where the target signature is located when the verification passes.

[0092] In this embodiment, the specific secure boot verification process is the same as that described in Embodiment 1, Embodiment 2 and Embodiment 3, and will not be described in detail here.

[0093] In the above technical solution, during the upgrade process, the startup signature of the new software has been stored in the corresponding memory map, so the security core does not need to recalculate the new signature value, which not only reduces the computing load of the security core, but also simplifies the upgrade process; since the startup signature has been pre-stored in the memory map, no additional signature calculation steps are required during the upgrade, thereby simplifying the upgrade operation, which reduces the complexity of the operation and reduces the possibility of errors in the platform during the upgrade process. At the same time, it avoids the need for additional steps to import public keys during the production process of the production line, reducing the possibility of public key leakage or misuse.

[0094] In addition, a parallel startup verification method is adopted, that is, the user core is activated immediately after the safety core is powered on. This parallel processing method can enable the user core to start normally while the safety core is being verified, thereby shortening the overall platform startup time.

[0095] In summary, the present application provides a secure boot method and system; first, the generated multiple boot signatures are burned into the corresponding memory mappings respectively, and the boot public key is pre-embedded into the verification code; after the security core is powered on, the user core is activated, and the corresponding boot signature is obtained according to the memory mapping currently running the security core as the target signature, and then the target signature is securely booted and verified according to the boot public key, so that when the verification passes, the execution program corresponding to the memory mapping where the target signature is located is started. The boot signature of the present application is stored in the memory mapping itself, and no additional actions are required to calculate the new signature value, so as to reduce the operating load of the security core and reduce additional system risks; and the public key is stored in the verification code, and the production line does not need to import the public key additionally, so as not to cause the risk of external public key misdirection of the production line, and will not be transferred between multiple parties, thereby reducing the risk of public key leakage; at the same time, a parallel boot verification method is adopted to reduce the platform startup time.

[0096] Although example embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above example embodiments are merely exemplary and are not intended to limit the scope of the present application to this. Those of ordinary skill in the art may make various changes and modifications therein without departing from the scope and spirit of the present application. All these changes and modifications are intended to be included within the scope of the present application as required by the appended claims.

[0097] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of 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.

[0098] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0099] The various component embodiments of the present application can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or digital signal processor (DSP) can be used in practice to implement some or all functions of some modules according to the embodiments of the present application. The application can also be implemented as a device program (e.g., computer program and computer program product) for executing a part or all of the methods described herein. Such a program implementing the present application can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0100] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0101] Although the description of the present application is carried out in conjunction with the above specific embodiments, it is obvious that those skilled in the art can make many substitutions, modifications and changes based on the above content. Therefore, all such substitutions, improvements and changes are included in the spirit and scope of the appended claims.

Claims

1. A secure boot method, characterized in that: The following steps are involved: S100: Generate multiple startup signatures based on an external server, burn each startup signature into a corresponding memory map, and embed the startup public key into the verification code in advance; S200: After the security core is powered on, the user core is activated, and a corresponding startup signature is obtained according to the memory map currently running on the security core as a target signature; as well as S300: Perform secure boot verification on the target signature according to the boot public key, so as to start the execution program corresponding to the memory mapping where the target signature is located when the verification passes.

2. The secure boot method according to claim 1, characterized in that: The step S100 of generating multiple startup signatures includes: Generate multiple pairs of startup public keys and startup private keys, and input the startup private keys and their corresponding memory mappings into a preset encryption algorithm to output corresponding startup signatures.

3. The secure boot method according to claim 2, characterized in that: The step S100 further includes: Generate a pair of boot public key and boot private key; Predetermining a memory map corresponding to the boot private key, inputting the boot private key and its corresponding memory map into a preset encryption algorithm to output a corresponding boot signature, and burning the boot signature into the memory map corresponding to the boot private key; At the same time, the boot public key is embedded in the verification code.

4. The secure boot method according to claim 3, characterized in that: After the safety core in step S200 is powered on, the following steps are also included: Check whether the startup public key and boot public key exist in the current verification code. If so, enable secure startup verification; otherwise, enter the penalty process.

5. The secure boot method according to claim 3, characterized in that: The memory map corresponds to a memory identifier, and the startup verification includes: The memory identifier is read, and the memory map currently running in the security core is determined according to the memory identifier to obtain the target signature and extract the boot signature.

6. The secure boot method according to claim 5, characterized in that: The step S300 includes: Obtain the startup public key and the boot public key, and perform secure startup verification on the target signature and the boot signature respectively through the startup public key and the boot public key, so as to start the execution program corresponding to the memory mapping where the target signature is located when both are verified, and store the verification result in the storage partition in the security core; If the target signature and / or boot signature verification fails, a penalty process is entered, and the verification result is stored in a storage partition in the security core.

7. The secure boot method according to claim 6, characterized in that: The penalty process includes: After a first preset time, restarting the platform corresponding to the security core; And after a second preset time, a current verification result is obtained based on the storage partition, and the verification result is recorded through the user core.

8. The secure boot method according to claim 1, characterized in that: After verification, it also includes: With the third preset time as a cycle, a verification signal is initiated through the user core, and the process returns to the step S200 to perform the secure boot verification again.

9. The secure boot method according to claim 1, characterized in that: Each startup signature is also stored in the server. When the platform is abnormal, it also includes: Extracting the memory mapping of the platform as the target mapping, and inputting the target mapping and the corresponding startup private key into a preset encryption algorithm to output the corresponding startup signature as the detection signature, and extracting the startup signature corresponding to the detection signature from the server as the judgment signature; The detection signature is compared with the judgment signature. If they are consistent, it is determined that the platform abnormality is not related to the secure boot verification. Otherwise, it is determined that the platform abnormality is related to the secure boot verification.

10. A secure boot system, characterized in that: include: A generation module, used to generate multiple startup signatures based on an external server, burn each startup signature into a corresponding memory map, and embed the startup public key into the verification code in advance; An acquisition module is used to activate the user core after the security core is powered on, and obtain the corresponding startup signature as the target signature according to the memory map currently running in the security core; as well as The startup verification module is used to perform secure startup verification on the target signature according to the startup public key, so as to start the execution program corresponding to the memory mapping where the target signature is located when the verification passes.

Images