Multi-core SOC safe starting method
By employing a multi-core SOC secure boot method with parallel processing and accelerated verification schemes, the problem of long boot times in existing SOC secure boot methods is solved, achieving fast and flexible secure boot that can adapt to various application scenarios.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- OMNIVISION TECH (SHANGHAI) CO LTD
- Filing Date
- 2026-01-30
- Publication Date
- 2026-05-15
AI Technical Summary
Existing SOC secure boot methods have time-consuming boot verification phases that fail to meet boot time requirements. They also have limited verification schemes that cannot adapt to various scenarios and lack boot flexibility and priority differentiation.
It adopts a multi-core SOC secure boot method, which includes two stages: secure boot import and processing. Through parallel processing, equivalent replacement and enhanced digest acceleration scheme, it improves boot speed and flexibility and supports a wealth of configurable parameters.
Significantly improves startup speed, adapts to different application scenarios, has high flexibility, supports multiple startup modes and priority configurations, and improves the efficiency and flexibility of secure startup.
Smart Images
Figure CN122046341A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of integrated circuit technology, specifically relating to a secure boot method for a multi-core SOC. Background Technology
[0002] Secure boot of a System-on-Chip (SoC) is a security mechanism designed to ensure that only legitimate software (authenticated and verified for integrity) can be run by the application core. Secure boot effectively detects malware and prevents the application core from running it. Current secure boot methods for SoCs suffer from the following problems: The signature verification during the boot process is processed serially, resulting in long boot times that fail to meet boot time requirements; replacing complete signature verification with faster methods like digest verification contradicts the user's initial configuration intent, and the simplistic verification scheme cannot meet the needs of various scenarios; the application core strictly adheres to the parameter configuration order for serial verification and boot, leading to poor boot flexibility, low priority differentiation, and high parameter configuration requirements. Summary of the Invention
[0003] The purpose of this invention is to provide a secure boot method for multi-core SoCs, which significantly improves boot speed through an innovative boot acceleration verification processing scheme. At the same time, this method is highly flexible, supporting a wide range of configurable parameters to adapt to different application scenarios.
[0004] This invention provides a secure boot method for a multi-core SoC, comprising:
[0005] The system consists of two core phases: secure boot import and secure boot processing.
[0006] The secure boot import process involves the application domain initiating an import request, the HSM responding to the request, and completing the personalized configuration of secure boot through pre-verification and parameter storage.
[0007] The secure boot process is a process that the HSM actively performs when the system is powered on subsequently, which completes the secure boot by accelerating the verification and boot process.
[0008] Furthermore, the configuration parameters imported for secure boot include: system-level configuration parameters and kernel-level configuration parameters;
[0009] The system-level configuration parameters include: the number of APP cores to be securely launched, the startup acceleration verification processing scheme to be used subsequently, and the configuration information of the startup priority;
[0010] The kernel-level configuration parameters include: the starting address and length information of the security check area used to indicate the security check area, the algorithm parameters required for verification, and the starting address for storing the standard signature; one APP kernel corresponds to a set of kernel-level configuration parameters.
[0011] Furthermore, the secure boot import process includes:
[0012] S11. Check if the input parameters are valid; if so, proceed to S12.
[0013] S12, Pre-verification stage: Traverse and sequentially verify the security check areas corresponding to all APP cores that need to be securely started, to ensure the validity and completeness of the transmitted secure start configuration parameters and the contents of the security check areas; if the pre-verification passes, proceed to S13.
[0014] S13. Parameter storage stage: First, iterate through all APP cores that need to be started securely, calculate the required parameters according to the configured startup acceleration verification processing scheme, and then store all the parameters to be used in the subsequent secure startup processing stage into secure memory to ensure that all subsequent parameters are secure, reliable and have not been tampered with.
[0015] If an error occurs in any of steps S11, S12, and S13, the import process will terminate immediately, and the error type will be returned to the upper layer.
[0016] Furthermore, the signature verification process in the SOC secure startup method includes: process one and process two;
[0017] Process 1: Calculate a summary of the contents of the security inspection area;
[0018] The second step involves performing asymmetric signature verification based on the digest, standard signature, key, and curve parameters calculated in the first step, to obtain a signature verification result, which may be either successful or unsuccessful.
[0019] Furthermore, the SOC secure boot method employs a parallel processing acceleration scheme. Process one is completed using a hash engine, and process two is completed using an RSA engine or an ECC engine depending on the signature type. Process one and process two use different computing engines and are processed in parallel.
[0020] In the secure startup import phase, a summary of the contents of the security check area is calculated and stored in secure memory; in the secure startup processing phase, process one and process two are processed in parallel.
[0021] The first process involves calculating a digest of the content in the security inspection area; the second process involves performing asymmetric signature verification based on the digest, standard signature, key, and curve parameters stored in the secure memory to obtain the signature verification result.
[0022] Furthermore, the SOC secure boot method adopts an equivalent replacement acceleration scheme. If the digest remains unchanged and all parameters used in process two remain unchanged, the final signature verification result remains unchanged. One part of the equivalent replacement acceleration scheme is to calculate and compare the old and new digests; the other part is to replace process two with calculating and comparing the old and new message authentication codes.
[0023] Furthermore, the SOC secure boot method adopts an enhanced digest acceleration scheme. The part of the security check area content that directly participates in the calculation is the first process, and the complete signature verification is degenerated into a verification digest. Only the new and old digests are calculated and compared.
[0024] In the enhanced digest acceleration scheme, in addition to the security check area content, the digest input also includes a message authentication code calculated based on the device key.
[0025] Furthermore, the secure boot process includes:
[0026] S21. Check if the parameters stored in the safe memory are valid. If so, proceed to S22.
[0027] S22. Based on the priority group and the startup mode of the APP cores within the group, process all APP cores in the priority group that need to be safely started in sequence; for parallel startup, start first and then verify; for serial startup, verify first and then perform serial startup processing.
[0028] Furthermore, the serial startup process performs different operations based on the verification result. If the serial verification passes, the APP core is started; if the serial verification fails, different processing is performed depending on whether it is a normal serial or a strict serial. If it is a normal serial, the APP core is not started; if it is a strict serial, the strict serial startup failure penalty option configured during import is used to either not start the APP core, stop the HSM from providing services to the outside world, or directly reset the system.
[0029] Furthermore, the verification in the SOC secure boot method adopts boot acceleration verification, which verifies the integrity and validity of the content in the security check area based on the storage parameters and the boot acceleration verification processing scheme configured during import, and records the verification results.
[0030] Compared with the prior art, the present invention has the following beneficial effects:
[0031] This invention provides a secure startup method for a System-on-a-Chip (SOC), comprising two core stages: secure startup import and secure startup processing. The secure startup import involves the application domain initiating an import request, the HSM responding to the request, and completing personalized secure startup configuration through pre-verification and parameter storage. The secure startup processing involves the HSM proactively performing processing upon subsequent system power-up, achieving efficient and reliable secure startup through accelerated verification and startup processing. This invention significantly improves startup speed through an innovative startup acceleration verification processing scheme. Simultaneously, this method possesses high flexibility, supporting a rich set of configurable parameters to adapt to different application scenarios. Attached Figure Description
[0032] Figure 1 This is a schematic diagram illustrating the principle of the SOC secure boot method according to an embodiment of the present invention.
[0033] Figure 2 This is a simplified structural diagram of a multi-core SOC in the SOC secure boot method of this invention.
[0034] Figure 3 This is a schematic diagram illustrating the secure boot configuration parameter import method in the SOC secure boot method of this invention.
[0035] Figure 4 This is a flowchart illustrating the secure boot import process in the SOC secure boot method according to an embodiment of the present invention.
[0036] Figure 5 This is a schematic diagram of the signature verification process in the SOC secure startup method according to an embodiment of the present invention.
[0037] Figure 6 This is a schematic diagram illustrating the principle of different startup acceleration verification processing schemes in the SOC secure startup method of this invention.
[0038] Figure 7 This is a flowchart of the secure boot process in the SOC secure boot method according to an embodiment of the present invention.
[0039] Figure 8 This is a schematic diagram of the serial boot process in the SOC secure boot method according to an embodiment of the present invention.
[0040] Figure 9 A comparison chart showing the speed and performance of different startup verification processing schemes.
[0041] Figure 10 This is a list of configurable options in the SOC secure boot method of this embodiment of the invention. Detailed Implementation
[0042] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The advantages and features of the present invention will become clearer from the following description. It should be noted that the drawings are in a very simplified form and use non-precise proportions, and are only used to facilitate and clarify the illustration of the embodiments of the present invention.
[0043] For ease of description, some embodiments of this application may use spatially relative terms such as “above,” “below,” “top,” and “under” to describe the relationship between one element or component and another (or more) elements or components as shown in the accompanying drawings. It should be understood that, in addition to the orientations described in the drawings, spatially relative terms are also intended to include different orientations of the device during use or operation. For example, if the device in the drawings is flipped, it is described as an element or component “below” or “under” other elements or components, and will subsequently be positioned “above” or “on” other elements or components. The terms “first,” “second,” etc., used below are used to distinguish between similar elements and are not necessarily used to describe a particular order or temporal sequence. It should be understood that these terms, as used, may be replaced where appropriate.
[0044] This invention provides a secure boot method for a System-on-a-Chip (SOC), such as... Figure 1 As shown, it includes:
[0045] The system consists of two core phases: secure boot import and secure boot processing.
[0046] Secure Boot Import: The application domain initiates an import request, the HSM responds to the request, and completes the personalized configuration of secure boot through pre-verification and parameter storage;
[0047] Secure boot process: When the system is powered on again, the HSM performs this process proactively, achieving a highly efficient and reliable secure boot by accelerating the verification and boot process.
[0048] Specifically, this invention implements secure boot in two parts: secure boot import and secure boot processing. Secure boot import is the "preparation and configuration phase" of secure boot, occurring during device manufacturing or firmware updates; its core task is to securely inject trusted boot materials and security policies into the device. Secure boot processing is the "runtime verification phase" of secure boot, occurring each time the device is powered on or reset; its core task is to strictly execute the policies set in the import phase, verifying and booting the system step by step. In the secure boot import phase, a pre-verification is performed based on the input parameters to ensure the validity and integrity of the transmitted secure boot configuration parameters and security check area content. In the secure boot import phase, the parameters required for subsequent secure boot processing are stored in secure memory to prevent malicious attacks.
[0049] like Figure 2As shown, the simplified architecture of a multi-core SoC includes: an application subsystem (APP), system memory, and a security subsystem (HSM). System memory stores the code to be run by the application domain APP subsystem (APP core). The HSM security subsystem provides various security-related services to the APP subsystem via a secure channel (MEU) based on an independent CPU and secure memory accessible only to itself. An HSM (Hardware Security Module) is a dedicated physical computing device specifically designed for generating, storing, managing, and protecting encryption keys, and performing high-strength encryption operations. It is a self-contained, tamper-resistant "security fortress." HSMs are typically integrated into larger main system chips (such as SoCs or CPUs), forming an indivisible security functional unit.
[0050] like Figure 3 As shown, the secure boot configuration parameters include system-level configuration parameters and core-level configuration parameters. System-level configuration parameters are a set of parameters encompassing the number of app cores to be securely booted, the subsequent boot acceleration verification processing scheme, and boot priority configuration information. Core-level configuration parameters encompass all configurations related to secure boot for the corresponding core, including but not limited to the starting address and length information of the security check area used to indicate the security check area, the algorithm parameters required for the check, the starting address for storing the standard signature, and the boot mode. Each app core corresponds to a set of core-level configuration parameters, which establish a connection between the core and its corresponding security check area.
[0051] like Figure 4 As shown, the secure boot import process includes:
[0052] S11. Check if the input parameters (parameters carried in the import request) are valid; if so, proceed to S12.
[0053] S12, Pre-verification stage: Traverse and sequentially verify the security check areas corresponding to all APP cores that need to be securely started, to ensure the validity and completeness of the transmitted secure start configuration parameters and the contents of the security check areas; if the pre-verification passes, proceed to S13.
[0054] S13. Parameter storage stage: First, iterate through all APP cores that need to be started securely, calculate the required parameters according to the configured startup acceleration verification processing scheme, and then store all the parameters to be used in the subsequent secure startup processing stage into secure memory to ensure that all subsequent parameters are secure, reliable and have not been tampered with.
[0055] If an error occurs in any of steps S11, S12, and S13, the import process will terminate immediately, and the error type will be returned to the upper layer.
[0056] Secure boot processing: This is a process actively performed by the HSM during subsequent system power-on, achieving secure boot through accelerated verification and boot processing. The secure boot process during system power-on is sensitive to both speed and security, and largely depends on the processing during the verification phase. Therefore, this invention proposes three selectable boot acceleration verification processing schemes. All three schemes are based on... Figure 5 The signature verification process is shown.
[0057] The legitimacy determination relies on the signature and verification process. The sender, who is also the corresponding secure boot initiator, first generates a unique signature for the software using their own "private key." Then, they inform the recipient, who is also the corresponding secure boot executor, of the signature and the software. After receiving the data, the executor uses the "public key," which is paired with the private key, to generate a signature for the received software. If the two signatures match, it proves that the software originates from a trustworthy source and is intact.
[0058] like Figure 5 As shown, a standard serial signature verification process includes two steps: Step 1: Calculate a digest of the content of the security check area. Step 2: Perform asymmetric signature verification based on the digest calculated in Step 1, the standard signature, the key, and other parameters such as the curve, to obtain the verification result, which may be either successful or unsuccessful.
[0059] like Figure 5 and Figure 6 As shown, the SOC secure startup method can employ a parallel processing acceleration scheme (first method). Process one is completed using a hash engine, and process two is completed using an RSA engine or an ECC engine depending on the signature type. Process one and process two use different computing engines and can be processed in parallel. In the secure startup import phase, a digest of the security check area content is calculated and stored in secure memory. In the secure startup processing phase, processes one and two are processed in parallel. Process one still involves calculating a digest of the security check area content; process two then becomes an asymmetric signature verification based on the digest, standard signature, key, curve, and other parameters stored in secure memory during the import phase, to obtain the verification result. This invention proposes a startup acceleration verification processing scheme based on parallel processing for signature verification algorithms, performing digest calculation and asymmetric signature verification in parallel.
[0060] The SOC secure boot method can employ an equivalent substitution acceleration scheme (the second type). If the digest remains unchanged and all parameters used in process two remain unchanged, the final signature verification result will remain unchanged. Similar to the first scheme, part of the equivalent substitution acceleration scheme still involves calculating and comparing the old and new digests; the other part replaces process two with calculating and comparing the old and new MACs (Message Authentication Codes). This MAC is calculated using AES256-GMAC for all parameters used in process two (e.g., digest, signature, key, etc.). This invention proposes a boot acceleration verification processing scheme based on equivalent substitution for signature verification algorithms, which equivalently replaces the asymmetric signature verification in the complete signature verification process with parameter MAC verification, achieving equivalent substitution of the complete signature verification together with digest verification.
[0061] The SOC secure boot method can employ an enhanced digest acceleration scheme (the third type). In this scheme, the portion of the security check area directly involved in the calculation is process one; therefore, complete signature verification degenerates into a verification digest, only calculating and comparing the old and new digests. In addition to the security check area content, the enhanced digest acceleration scheme adds a MAC (Message Authentication Code) calculated based on the device key to the digest input. This invention proposes an enhanced digest-based boot acceleration verification processing scheme for signature-based verification algorithms, integrating device-related parameters into the digest calculation to improve the scheme's security.
[0062] like Figure 7 As shown, the secure boot process includes:
[0063] S21. Check if the parameters stored in the safe memory are valid. If so, proceed to S22.
[0064] S22. Based on the priority group and the startup mode of the APP cores within the group, process all APP cores in the priority group that need to be safely started in sequence; for parallel startup, start first and then accelerate verification; for serial startup, accelerate verification first and then perform serial startup processing.
[0065] All verifications during the secure boot process employ accelerated boot verification, which verifies the integrity and validity of the contents of the security check area based on storage parameters and the accelerated boot verification processing scheme configured during import, and records the verification results.
[0066] like Figure 8 As shown, the serial startup process performs different operations based on the verification result. If the serial verification passes, the APP core is started; if the serial verification fails, different actions are taken depending on whether it is a normal serial or a strict serial. If it is a normal serial, the APP core is not started; if it is a strict serial, the APP core is not started, or the HSM is stopped from providing services to the outside world, or the system is directly reset, according to the strict serial startup failure penalty options configured during import.
[0067] Figure 9A performance comparison chart of different startup verification processing schemes. (Example) Figure 9 As shown, the data in the figure represents the test results of two commonly used signature algorithms (RSASSA-PSS and ECDSA), both based on 64KB of data obtained with a CPU at 150M. Figure 9 It can be clearly seen that the three boot acceleration verification processing schemes proposed in this invention are all significantly faster than the ordinary serial processing scheme; and the speed improvement effects of the equivalent replacement acceleration scheme and the enhanced digest acceleration scheme are significant (2 times / 5 times). Therefore, the three boot acceleration verification processing schemes proposed in this invention make the secure boot method faster.
[0068] Figure 10 This is a list of configurable options in the SOC secure boot method of this embodiment of the invention. For example... Figure 10 As shown, the SOC secure boot method of this embodiment provides a wealth of flexible configurable options.
[0069] The proposed acceleration schemes include a flexible startup acceleration scheme, a parallel processing acceleration scheme (first type), an equivalent replacement acceleration scheme (second type), and an enhanced digest acceleration scheme (third type). Each of these three startup acceleration schemes has its own advantages. The parallel processing acceleration scheme does not change the user's original verification algorithm and improves speed; the equivalent replacement acceleration scheme provides a more significant speed improvement; and the enhanced digest acceleration scheme is the fastest. Users can choose the appropriate scheme according to their needs.
[0070] Flexible startup mode selection. Each application core supports parallel startup, normal serial startup, and strict serial startup. Parallel startup mode starts first and then verifies, suitable for cores with certain startup time requirements; normal serial startup and strict serial startup modes verify first and then execute the system response based on the verification result, suitable for cores with high security requirements and slightly lower startup time requirements. Users can also select the startup mode for each core as needed.
[0071] Flexible boot priority configuration. The concept of boot priority groups is introduced, with each core supporting boot priority configuration. Cores with higher boot priorities have higher processing priority during the boot phase.
[0072] Flexible strict serial boot failure penalty options. Users can choose from three options as needed: not booting the core, stopping HSM services, and resetting the system.
[0073] Flexible verification algorithm configuration, supporting both MAC (Message Authentication Code) series verification and signature series verification.
[0074] The secure boot method of this invention is easier to expand in multiple aspects and from multiple angles, including:
[0075] The aforementioned configurable options are all configured as independent parameters, making it easy to extend each configuration option within this architecture. Regarding the kernel-level configuration parameters, a single set of kernel-level configuration parameters encompasses all configurations related to secure boot for the corresponding kernel. This architecture facilitates the expansion of multi-core secure boot by increasing the number of kernel-level configuration parameter sets. The concept of boot priority groups is introduced; secure boot processing is performed sequentially based on these boot priority groups. This architecture also facilitates the expansion of multiple boot priorities by extending the number of priority group categories.
[0076] The multi-core SOC secure boot method provided by this invention can be applied to a series of SOC products with HSM; it enriches product functions, enhances product core competitiveness, effectively reduces development costs, and increases product gross profit.
[0077] In summary, this invention provides a secure startup method for a System-on-a-Chip (SOC), comprising two core stages: secure startup import and secure startup processing. Secure startup import involves the application domain initiating an import request, the HSM responding to the request, and completing personalized secure startup configuration through pre-verification and parameter storage. Secure startup processing involves the HSM proactively performing processing upon subsequent system power-up, achieving efficient and reliable secure startup through accelerated verification and startup processing. This invention significantly improves startup speed through an innovative startup acceleration verification processing scheme. Furthermore, this method is highly flexible, supporting a wide range of configurable parameters to adapt to different application scenarios.
[0078] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The methods disclosed in the embodiments are described simply because they correspond to the devices disclosed in the embodiments; relevant details can be found in the method section.
[0079] The above description is merely a description of preferred embodiments of the present invention and is not intended to limit the scope of the present invention. Any person skilled in the art can make possible changes and modifications to the technical solutions of the present invention by utilizing the methods and techniques disclosed above without departing from the spirit and scope of the present invention. Therefore, any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solutions of the present invention shall fall within the protection scope of the technical solutions of the present invention.
Claims
1. A secure boot method for a multi-core SOC, characterized in that, include: The system consists of two core phases: secure boot import and secure boot processing. The secure boot import process involves the application domain initiating an import request, the HSM responding to the request, and completing the personalized configuration of secure boot through pre-verification and parameter storage. The secure boot process is a process that the HSM actively performs when the system is powered on subsequently, which completes the secure boot by accelerating the verification and boot process.
2. The SOC secure boot method as described in claim 1, characterized in that, The configuration parameters imported during secure boot include: system-level configuration parameters and kernel-level configuration parameters; The system-level configuration parameters include: the number of APP cores to be securely launched, the startup acceleration verification processing scheme to be used subsequently, and the configuration information of the startup priority; The kernel-level configuration parameters include: the starting address and length information of the security check area used to indicate the security check area, the algorithm parameters required for verification, and the starting address for storing the standard signature; one APP kernel corresponds to a set of kernel-level configuration parameters.
3. The SOC secure boot method as described in claim 1, characterized in that, The secure boot import process includes: S11. Check if the input parameters are valid; if so, proceed to S12. S12, Pre-verification stage: Traverse and sequentially verify the security check areas corresponding to all APP cores that need to be securely started, to ensure the validity and completeness of the transmitted secure start configuration parameters and the contents of the security check areas; if the pre-verification passes, proceed to S13. S13. Parameter storage stage: First, iterate through all APP cores that need to be started securely, calculate the required parameters according to the configured startup acceleration verification processing scheme, and then store all the parameters to be used in the subsequent secure startup processing stage into secure memory to ensure that all subsequent parameters are secure, reliable and have not been tampered with. If an error occurs in any of steps S11, S12, and S13, the import process will terminate immediately, and the error type will be returned to the upper layer.
4. The SOC secure boot method as described in claim 1, characterized in that, The signature verification process in the SOC secure startup method includes: process one and process two; Process 1: Calculate a summary of the contents of the security inspection area; The second step involves performing asymmetric signature verification based on the digest, standard signature, key, and curve parameters calculated in the first step, to obtain a signature verification result, which may be either successful or unsuccessful.
5. The SOC secure boot method as described in claim 4, characterized in that, The SOC secure boot method employs a parallel processing acceleration scheme. Process one is completed using a hash engine, and process two is completed using an RSA engine or an ECC engine depending on the signature type. Process one and process two use different computing engines and are processed in parallel. During the secure startup import phase, a summary of the contents of the security check area is calculated and stored in secure memory. During the secure startup process phase, process one and process two are processed in parallel. The first process involves calculating a digest of the content in the security inspection area; the second process involves performing asymmetric signature verification based on the digest, standard signature, key, and curve parameters stored in the secure memory to obtain the signature verification result.
6. The SOC secure boot method as described in claim 4, characterized in that, The SOC secure startup method adopts an equivalent replacement acceleration scheme. If the digest remains unchanged and all parameters used in process two remain unchanged, the final signature verification result remains unchanged. One part of the equivalent replacement acceleration scheme is to calculate and compare the old and new digests; the other part is to replace process two with calculating and comparing the old and new message authentication codes.
7. The SOC secure boot method as described in claim 4, characterized in that, The SOC secure boot method adopts an enhanced digest acceleration scheme. The part of the security check area content that directly participates in the calculation is the first process. The complete signature verification is degenerated into a verification digest. Only the new and old digests are calculated and compared. In the enhanced digest acceleration scheme, in addition to the security check area content, the digest input also includes a message authentication code calculated based on the device key.
8. The SOC secure boot method as described in claim 1, characterized in that, The secure boot process includes: S21. Check if the parameters stored in the safe memory are valid. If so, proceed to S22. S22. Based on the priority group and the startup mode of the APP cores within the group, process all APP cores in the priority group that need to be safely started in sequence; for parallel startup, start first and then verify; for serial startup, verify first and then perform serial startup processing.
9. The SOC secure boot method as described in claim 8, characterized in that, The serial startup process performs different operations based on the verification result. If the serial verification passes, the APP core is started. If the serial verification fails, different actions are taken depending on whether it is a normal serial or a strict serial. If it is a normal serial, the APP core will not be started. If it is strictly serial, then according to the strictly serial startup failure penalty option configured during import, the APP core will not be started, or the HSM will be stopped from providing services to the outside world, or the system will be directly reset.
10. The SOC secure boot method as described in claim 1, characterized in that, The verification in the SOC secure boot method all adopts boot acceleration verification, which verifies the integrity and validity of the content of the security check area based on the storage parameters and the boot acceleration verification processing scheme configured during import, and records the verification results.