Chip security starting method and system, computer equipment and storage medium

By loading and verifying the configuration files, engine firmware and encrypted system files of the startup program from external memory in the secure boot mode of the SOC chip, the problem that the SOC chip cannot perceive the trusted state of the external boot program is solved, and higher startup reliability and security are achieved.

CN119783114APending Publication Date: 2025-04-08WXILICON TECH CO LTD
View PDF 0 Cites 2 Cited by

Patent Information

Application Number
CN202411852650.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-16
Publication Date
2025-04-08

AI Technical Summary

Technical Problem

During the startup process, existing SOC chips cannot sense whether the startup program loaded from external memory has been abnormally damaged or tampered with, resulting in poor reliability and security of startup.

Method used

When the system-level chip enters secure boot mode, the configuration file header corresponding to the startup program is loaded from external memory for parsing, the engine firmware and encrypted system files are extracted, and the integrity verification and decryption verification are performed to ensure the trusted state of the startup program before starting.

Benefits of technology

Through step-by-step verification and decryption verification, the integrity and trustworthiness of the startup program loaded from external memory is ensured, thereby improving the startup reliability and security of the SOC chip.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119783114A_ABST
    Figure CN119783114A_ABST
Patent Text Reader

Abstract

The invention relates to a chip security starting method and system, computer equipment and a storage medium. The method comprises the following steps: checking information loaded from an external memory step by step so as to perceive whether a starting program loaded from the external memory is abnormally damaged, and only checking the integrity of engine firmware and encrypted system files loaded from the external memory step by step; after engine firmware and the encryption system file are ensured to be complete and not damaged, decryption and signature verification are carried out on the encryption system file so as to perceive whether the encryption system file is tampered or not, and after decryption and signature verification of the encryption system file are successful, a starting program loaded from an external memory is utilized to start a system-on-chip. Therefore, the trusted state of the starting program loaded from the external memory is ensured, it is ensured that the system-level system can be safely and reliably started, and the problem that the trusted state of the external starting program cannot be sensed in the starting process of an existing SOC chip is solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of chip secure booting, and in particular to a chip secure booting method, system, computer device and storage medium. Background Art

[0002] The boot process of the SOC chip (System on Chip) requires high-level application security and an efficient and secure boot process. At present, many SOC chips in embedded systems and mobile devices are booted using the traditional ROM boot method. In this boot mode, the SOC's built-in read-only memory (ROM) contains the basic code required for booting, usually a boot loader. The boot loader is responsible for initializing the hardware device and loading a higher-level boot program from the external memory into the RAM for direct execution. However, the SOC chip cannot sense whether the boot program loaded from the external memory is abnormally damaged or tampered with. If the boot program is abnormally damaged or tampered with, it will cause the SOC chip to fail to boot or illegally boot, resulting in poor reliability and security of the SOC chip boot. Summary of the invention

[0003] The present application provides a chip secure boot method, system, computer device and storage medium to solve the problem that the existing SOC chip boot process cannot perceive the trusted state of the external boot program.

[0004] In a first aspect, the present application provides a chip secure startup method, the method comprising:

[0005] When the system-level chip enters the secure boot mode, the file header of the configuration file corresponding to the boot program is loaded from the external memory and parsed to obtain parsing information;

[0006] Extracting the first engine firmware corresponding to the startup program from the external memory according to the parsed information, and performing integrity check on the first engine firmware to obtain a first engine check result;

[0007] When the first engine verification result is successful, extracting a first encryption system file corresponding to the startup program from the external memory according to the parsing information, and performing integrity verification on the first encryption system file to obtain a first file verification result;

[0008] When the first file verification result is successful, the first encryption system file is decrypted and signature verified by using the hardware accelerator driven by the first engine firmware to obtain a first signature verification result;

[0009] When the first signature verification result is successful, the startup program is executed to start the system-on-chip.

[0010] In a second aspect, the present application provides a chip security boot system, the chip security boot system comprising a system-level chip and an external memory connected in communication, the system-level chip comprising a chip security boot device, the chip security boot device comprising:

[0011] A processing module, used for loading a file header of a configuration file corresponding to a startup program from an external memory and performing parsing processing to obtain parsing information when the system-level chip enters a secure startup mode;

[0012] A verification module, configured to extract the first engine firmware corresponding to the startup program from the external memory according to the parsing information, and perform integrity verification on the first engine firmware to obtain a first engine verification result;

[0013] The verification module is further configured to extract a first encryption system file corresponding to the startup program from the external memory according to the parsing information when the first engine verification result is verification success, and perform integrity verification on the first encryption system file to obtain a first file verification result;

[0014] The verification module is further configured to, when the verification result of the first file is successful, use the hardware accelerator driven by the first engine firmware to perform decryption and signature verification processing on the first encryption system file to obtain a first signature verification result;

[0015] A startup module is used to execute the startup program to start the system-on-chip when the first signature verification result is successful.

[0016] In a third aspect, the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned chip security boot method when executing the computer program.

[0017] In a fourth aspect, the present application also provides a computer storage medium storing computer executable instructions, wherein the computer executable instructions are used to execute the above-mentioned chip secure boot method.

[0018] The above-mentioned technical solution provided by the embodiment of the present application has the following advantages over the prior art: the method provided by the embodiment of the present application, when the system-level chip enters the secure boot mode, loads the file header of the configuration file corresponding to the boot program from the external memory and performs parsing processing to obtain parsing information; extracts the first engine firmware corresponding to the boot program from the external memory according to the parsing information, and performs an integrity check on the first engine firmware to obtain a first engine verification result; when the first engine verification result is a successful verification, extracts the first encryption system file corresponding to the boot program from the external memory according to the parsing information, and performs an integrity check on the first encryption system file to obtain a first file verification result; when the first file verification result is a successful verification, uses the hardware accelerator driven by the first engine firmware to perform decryption and signature verification processing on the first encryption system file to obtain a first signature verification result; when the first signature verification result is a successful verification, executes the boot program to start the system-level chip.

[0019] Based on the above method, the information loaded from the external memory is checked level by level to sense whether the boot program loaded from the external memory is abnormally damaged. Only the integrity of the engine firmware and the encryption system files loaded from the external memory is checked level by level. After ensuring that the engine firmware and the encryption system files are intact, the encryption system files are decrypted and signed to sense whether the encryption system files are tampered with. Only after the encryption system files are decrypted and signed successfully, the boot program loaded from the external memory is used to start the system-level chip to ensure the trusted state of the boot program loaded from the external memory, and to ensure that the system-level system can be started safely and reliably, thereby solving the problem that the existing SOC chip startup process cannot perceive the trusted state of the external boot program. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0021] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0022] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0023] Figure 1An application environment diagram of a chip secure boot method provided in an embodiment of the present application;

[0024] Figure 2 A schematic diagram of a chip secure startup method provided in an embodiment of the present application;

[0025] Figure 3 A schematic diagram of a chip secure startup method provided in an embodiment of the present application;

[0026] Figure 4 A structural block diagram of a chip secure boot system provided in an embodiment of the present application;

[0027] Figure 5 A schematic diagram of the internal structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0029] The disclosure below provides many different embodiments or examples to implement different structures of the present invention. In order to simplify the disclosure of the present invention, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present invention. In addition, the present invention can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0030] Figure 1 FIG. 1 is an application environment diagram of a chip secure boot method in an embodiment. Figure 1 The chip security boot method is applied to a chip security boot system. The chip security boot system includes a system-level chip 110 and an external memory 120 that are communicatively connected, and the system-level chip 110 includes a chip security boot device.

[0031] The system-on-chip 110 is a SOC chip. The system-on-chip 110 can be installed in any electronic device. The electronic device can be a terminal, a smart home device, a vehicle-mounted device, an industrial device, etc. The terminal can be a desktop terminal or a mobile terminal. The mobile terminal can be at least one of a mobile phone, a tablet computer, a laptop computer, etc. The smart home device can be a smart refrigerator, a smart TV, a smart speaker, a smart air conditioner, etc.

[0032] In one embodiment, Figure 2 FIG. 1 is a flow chart of a chip secure startup method in an embodiment, referring to FIG. Figure 2 , provides a chip security startup method. This embodiment mainly applies this method to the above Figure 1 Taking the chip secure boot device in the example as an example, the chip secure boot method specifically includes the following steps:

[0033] Step S210 , when the SoC 110 enters the secure boot mode, the file header of the configuration file corresponding to the boot program is loaded from the external memory 120 and parsed to obtain parsing information.

[0034] Specifically, the system-level chip 110 enters the secure boot mode, indicating that the system-level chip 110 is in the boot stage. In this stage, the boot program needs to be loaded from the external memory 120 to complete the boot process. However, in order to perform a trustworthy verification on the boot program, the file header of the configuration file corresponding to the boot program is first loaded from the external memory 120. The field parameters in the file header include at least an image validity mark, a file startup mark, a clock configuration, a number of packaged files, a total packaged file length, a reserved field, an A / B area mark, multiple file IDs, a file running address corresponding to each file ID, a packaging date corresponding to each file ID, a packaging time corresponding to each file ID, an offset address corresponding to each file ID, a file length corresponding to each file ID, a CRC mark corresponding to each file ID, a CRC check value corresponding to each file ID, and the like.

[0035] The parsing information is obtained by parsing the file header, and the parsing information includes each field parameter in the above file header and the parameter value of each field parameter, so as to quickly grasp the relevant information of the startup program.

[0036] Among them, the configuration file corresponding to the startup program in the external memory 120 is generated by packaging using a file packaging tool, and the file packaging tool supports two packaging methods. The first is to specify the file type. For files with a file type of ROMApp, a valid XIP running offset address needs to be specified. For files with a file type of non-ROMApp, the running address is not concerned. Independent file packaging is performed for files of different file types when the corresponding address is specified. The second is to continue to add packages to the packaged files. This packaging method does not require the file type and XIP running offset address to be specified again. The corresponding address parameter value is directly filled with 0. The file type needs to be specified when adding a package file. For the ROMApp type, a valid XIP running offset address needs to be specified. Non-ROMApp does not care about the running address. The configuration file contains a key signing certificate and a secure application image using a key signing certificate.

[0037] Step S220: extracting the first engine firmware corresponding to the boot program from the external memory 120 according to the parsing information, and performing integrity check on the first engine firmware to obtain a first engine check result.

[0038] Specifically, based on the parsed information, the first engine firmware corresponding to the boot program is extracted from the external memory 120. The external memory 120 may store one or more engine firmwares, and the first engine firmware is any engine firmware in the external memory 120. The integrity check is performed on the first engine firmware to determine whether the first engine firmware is complete and undamaged, and a first engine check result is obtained. The first engine check result is a check success or a check failure. When the first engine check result is a check failure, it indicates that the first engine firmware is incomplete, that is, the first engine firmware is damaged, and when the first engine check result is a check success, it indicates that the first engine firmware is complete and undamaged.

[0039] Step S230, when the first engine verification result is successful, extract the first encryption system file corresponding to the startup program from the external memory 120 according to the parsing information, and perform integrity verification on the first encryption system file to obtain a first file verification result.

[0040] Specifically, after ensuring that the first engine firmware is intact, the integrity check is performed on the first encryption system file extracted from the external memory 120, that is, the step-by-step check of the startup program is implemented. One or more encryption system files are stored in the external memory 120, and the first encryption system file is any encryption system file in the external memory 120. The integrity check is performed on the first encryption system file to determine whether the first encryption system file is complete, and a first file check result is obtained. When the first file check result is a check failure, it indicates that the first encryption system file is incomplete, that is, the first encryption system file is damaged, and when the first file check result is a check success, it indicates that the first encryption system file is complete and undamaged.

[0041] Step S240: When the first file verification result is successful, the first encryption system file is decrypted and signature verified using the hardware accelerator driven by the first engine firmware to obtain a first signature verification result.

[0042] Specifically, only when it is ensured that the first encryption system file is intact and not damaged, the first engine firmware that has successfully passed the integrity check is used to drive the hardware accelerator. When driven, the hardware accelerator decrypts and verifies the first encryption system file that has successfully passed the integrity check, determines whether the first encryption system file has been tampered with, and obtains a first signature verification result. When the first signature verification result is a signature verification failure, it indicates that the first encryption system file has been tampered with, and when the first signature verification result is a signature verification success, it indicates that the first encryption system file has not been tampered with.

[0043] Step S250 , when the first signature verification result is successful, executing the startup program to start the system-on-chip 110 .

[0044] Specifically, after successfully passing the above-mentioned level-by-level integrity check and decryption and signature verification process, ensuring that the boot program loaded from the external memory 120 is safe and reliable, the boot program is executed to start the system-level chip 110, ensuring that the system-level system can be started safely and reliably, solving the problem that the existing SOC chip startup process cannot perceive the trusted status of the external boot program.

[0045] In one embodiment, when the system-on-chip 110 enters the secure boot mode, the file header of the configuration file corresponding to the boot program is loaded from the external memory 120 and parsed. Before obtaining the parsed information, the method further includes:

[0046] When the system-on-chip 110 is powered on, obtaining a secure boot type of the system-on-chip 110;

[0047] When the secure boot type is the first boot type, controlling the system-on-chip 110 to enter a secure boot mode; or,

[0048] When the secure boot type is the second boot type, the system-on-chip 110 is controlled to enter the secure boot mode after completing the single-chip microcomputer fast boot.

[0049] Specifically, refer to Figure 3 , when the SoC 110 is powered on, the secure boot configuration is queried to obtain the secure boot type of the SoC 110, that is, the secure boot configuration register security field (CMS_SYS_REG::TOP_EFUSE_RDATA0:top_efuse_rdata_31_0) is queried to determine the secure boot type. If it is detected that top_efuse_rdata_31_0[8:6] is 111, the secure boot type is determined to be the first boot type, and the secure boot mode is directly entered. If it is detected that top_efuse_rdata_31_0[11:9] is 111, the secure boot type is determined to be the second boot type, and the SoC 110 needs to enter the single-chip microcomputer fast start first, and then enter the secure boot mode after the single-chip microcomputer configuration is completed, that is, the SoC 110 can perform port fast start to achieve partial startup. At this time, the system of the SoC 110 has not yet started, so as to meet the application scenario that requires the partial start of the SoC 110, thereby expanding the application scenario of the secure startup of the SoC 110 and improving the startup flexibility of the SoC 110.

[0050] In one embodiment, when the system-on-chip 110 enters the secure boot mode, the file header of the configuration file corresponding to the boot program is loaded from the external memory 120 and parsed to obtain parsed information, including:

[0051] When the system-on-chip 110 enters the secure boot mode, a file header of a configuration file corresponding to the boot program is loaded from the external memory 120 according to the first communication mode;

[0052] When the file header is successfully loaded according to the first communication mode, the file header is parsed to obtain parsing information; or,

[0053] When the file header fails to be loaded according to the first communication method, the file header corresponding to the startup program is loaded from the external memory 120 according to the second communication method; when the file header is successfully loaded according to the second communication method, the file header is parsed to obtain parsing information, wherein the transmission speed of the second communication method is greater than the transmission speed of the first communication method.

[0054] Specifically, refer to Figure 3 When the system-level chip 110 enters the secure boot mode, the file header of the configuration file corresponding to the boot program is first loaded from the external memory 120 according to the first communication method. When the file header is successfully loaded according to the first communication method, the file header is parsed and processed. However, when the file header cannot be successfully loaded according to the first communication method, it is necessary to switch to the second communication method to reload the file header. In this embodiment, the first communication method is the SPI communication method, and the second communication method is the XIP-4 communication method. The data transmission speed of the first communication method is slow, while the transmission speed of the second communication method is fast. However, the communication cost of the first communication method is lower than the communication cost of the second communication method. Therefore, the first communication method with lower communication cost is first used to load the file header. When the first communication method fails to load, the second communication method with higher communication cost is used to load the file header, thereby reducing the communication cost and ensuring the loading reliability of the file header.

[0055] In one embodiment, extracting the first engine firmware corresponding to the boot program from the external memory 120 according to the parsed information, and performing integrity check on the first engine firmware to obtain a first engine check result, includes:

[0056] Determine a target boot area and a target communication mode in the external memory 120 according to the parsed information;

[0057] Extracting the first engine firmware corresponding to the boot program from the target boot area in the external memory 120 according to the target communication mode, and transferring the first engine firmware to a first designated storage location;

[0058] Performing an integrity check on the first engine firmware to obtain a first engine check result.

[0059] Specifically, when the target communication mode is determined, the FLASH device needs to be driven according to the driving mode corresponding to the target communication mode. If the target communication mode is the XIP-4 communication mode, the QE working mode of the FLASH device needs to be turned on. The QE FLAG in the configuration file header is configured to be non-zero. Non-zero indicates that the file header contains valid QE commands and control bit definitions. The QE command is sent to the FLASH device directly using the SPI communication mode. If the QE FLAG is zero, the automatic detection mode is entered. The program supports 4 types of QE instructions, regardless of the manufacturer. The QE command and control bit combinations are 0x1 6, 0x1 9, 0x31 1, 0x38 0xff, respectively. After the QE command is detected, the FLASH device is driven and the controller is configured to switch to the XIP-4 communication mode.

[0060] Reference Figure 3 , extract the first engine firmware from the target boot area in the external memory 120 according to the target communication mode, and save the first engine firmware extracted from the external memory 120 to the first designated storage location, the first designated storage location is the starting position of the RAM offset address 0x000c0000, and enter the RAM data CRC check check stage after the first engine firmware is saved to the first designated storage location, that is, perform a CRC integrity check on the first engine firmware, thereby obtaining a first engine check result, which is used to determine whether the first engine firmware in the target boot area in the external memory 120 is damaged, so as to avoid the damaged first engine firmware from affecting the secure boot of the system-level chip 110.

[0061] In one embodiment, determining the target boot area and the target communication mode in the external memory 120 according to the parsed information includes:

[0062] Determine the target communication mode according to the communication mode corresponding to the file start mark in the parsed information;

[0063] When the parsed information contains a valid activation boot area mark, the boot area corresponding to the activation boot area mark is used as the target boot area, wherein the external memory 120 includes at least two boot areas; or

[0064] When the parsed information does not contain a valid activation boot area mark, the boot area containing the latest generated file is used as the target boot area.

[0065] Specifically, the file startup mark in the parsing information is used to indicate the target communication mode supported by the external memory 120, that is, different file startup marks correspond to different communication modes, and the target communication mode is the first communication mode, the second communication mode or the third communication mode, the first communication mode is the SPI communication mode, the second communication mode is the XIP-4 communication mode, and the third communication mode is the XIP-2 communication mode. The A / B area mark in the parsing information is the activation startup area mark, which is used to indicate the target startup area, that is, the external memory 120 includes at least two different startup areas, each of which stores a configuration file corresponding to the startup program, which is used to realize multi-area backup of the configuration file.

[0066] If the parsed information contains a valid activation boot area mark, the boot area indicated by the activation boot area mark is directly used as the target boot area. For example, if the A / B area mark indicates area A, area A is used as the target boot area. If the A / B area mark indicates area B, area B is used as the target boot area.

[0067] If the parsed information does not contain the A / B zone mark, or the parameter value corresponding to the A / B zone mark is empty or an illegal value, it is deemed that the parsed information does not contain a valid activation boot zone mark, and the boot zone storing the latest generated file is screened out from multiple boot zones as the target boot zone, so that the boot zone with the latest changes is used as the target boot zone to ensure the update level of data in the target boot zone, so as to use the boot zone containing the latest data to participate in the secure boot of the system-level chip 110, so as to improve the success rate of the secure boot of the system-level chip 110.

[0068] In one embodiment, after performing integrity check on the first engine firmware to obtain the first engine check result, the method further includes:

[0069] When the first engine verification result is a verification failure, extracting the second engine firmware corresponding to the startup program from the non-target startup area in the external memory 120 according to the target communication mode, and transferring the second engine firmware to the first designated storage location;

[0070] Performing integrity check on the second engine firmware to obtain a second engine check result;

[0071] When the second engine verification result is successful, extracting the first encrypted system file corresponding to the startup program from the target startup area in the external memory 120 according to the target communication mode, and transferring the first encrypted system file to the second designated storage location;

[0072] Performing an integrity check on the first encryption system file to obtain the first file verification result.

[0073] Specifically, refer to Figure 3When the first engine firmware is subjected to a CRC integrity check and the result of the first engine check is a check failure, it indicates that the first engine firmware is not complete and is damaged, and the first engine firmware cannot be used to participate in the secure boot of the system-level chip 110. The engine firmware needs to be switched, and the second engine firmware corresponding to the boot program is re-extracted from the non-target boot area according to the target communication mode, and the second engine firmware is also saved to the first designated storage location and a CRC integrity check is performed on it to determine whether the second engine firmware is complete and undamaged, and a second engine check result is obtained. If the second engine check result is a check success, it indicates that the second engine firmware is complete and undamaged, and can participate in the subsequent secure boot of the system-level chip 110.

[0074] When the complete and undamaged second engine firmware is obtained, the first encryption system file is still extracted from the target boot area according to the target communication method, and the extracted first encryption system file is saved to the second designated storage location, which is the starting position of the RAM offset address 0x00001000. Then, the RAM data CRC check phase is entered, that is, a CRC integrity check is performed on the first encryption system file to determine whether the first encryption system file is complete and undamaged, thereby obtaining the first file verification result.

[0075] That is, when the first engine firmware loaded from the target boot area cannot be used, it will not affect the loading of the first encrypted system file from the target boot area, and the loading reliability of the engine firmware is ensured by loading the second engine firmware from the non-target boot area. By providing storage backup of the engine firmware through different boot areas, the success rate of the secure boot of the system-level chip 110 is improved.

[0076] In one embodiment, after performing integrity check on the first encryption system file to obtain a first file check result, the method further includes:

[0077] When the first file verification result is a verification failure, extracting a second encrypted system file corresponding to the startup program from the non-target startup area in the external memory 120 according to the target communication mode, and transferring the second encrypted system file to a second designated storage location;

[0078] Performing integrity check on the second encryption system file to obtain a second file verification result;

[0079] When the verification result of the second file is successful, the hardware accelerator driven by the target engine firmware is used to perform decryption and signature verification processing on the second encryption system file to obtain a second signature verification result, wherein the target engine firmware is the first engine firmware or the second engine firmware that has successfully been verified;

[0080] When the second signature verification result is successful, the first encrypted system file in the target boot area is replaced with the second encrypted system file, and then the boot program is executed to boot the system-on-chip 110 .

[0081] Specifically, refer to Figure 3 If the first file verification result is a verification failure, it means that the first encryption system file is incomplete and damaged and cannot participate in the secure startup of the system-level chip 110. It is necessary to reload the second encryption system file from the external memory 120, then load the second encryption system file from the non-target startup area, and save the second encryption system file to the second designated storage location for CRC verification to determine whether the second encryption system file is complete and undamaged, thereby obtaining a second file verification result. When the second file verification result is a verification success, the target engine firmware that has successfully passed the integrity verification is used to drive the hardware accelerator, and the target engine firmware is the first engine firmware or the second engine firmware that has successfully passed the integrity verification. The firmware performs decryption and signature verification on the second encryption system file when driven by the hardware accelerator. The decryption and signature verification process includes: using a local private key to decrypt the target encryption system file to obtain decrypted data; using a hash algorithm to calculate a summary corresponding to the decrypted data to obtain a first summary; comparing the first summary with the second summary in the decrypted data to obtain a target signature verification result, and obtaining a target signature verification result of successful signature verification when the first summary and the second summary are consistent; and obtaining a target signature verification result of failed signature verification when the first summary and the second summary are inconsistent, wherein the target encryption system file is the first encryption system file or the second encryption system file, and the target signature verification result is the first signature verification result or the second signature verification result.

[0082] When the second signature verification result is successful, it indicates that the second encryption system file has not been tampered with. After the second encryption system file is used to replace the first encryption system file in the target boot area, the trusted encryption system file is synchronously updated to the target boot area to improve the credibility of the data in the boot area. Then, the boot program is executed to start the system-level chip 110 to achieve a secure boot of the system-level chip 110.

[0083] When the second signature verification result is a signature verification failure, the third encrypted system file is extracted from the target boot area or the non-target boot area in the external memory 120 again, and the third encrypted system file is moved to the second designated storage location and then a CRC integrity check is performed on it, so as to obtain a third file verification result. When the third file verification result is a verification success, the third encrypted system file is decrypted and signature verified by using the target engine firmware to drive the hardware accelerator, so as to obtain a third signature verification result. When the third signature verification result is a signature verification success, the startup program is executed to start the system-on-chip 110. That is, when the signature verification of the encrypted system file fails, the step of reloading the encrypted system file is returned to reload the encrypted system file to continue the integrity verification and decryption signature verification process until the signature verification succeeds and the system-on-chip 110 is started. Alternatively, when the number of cycles of signature verification failure or verification failure of the encrypted system file reaches a preset number, a system-level system startup failure indication information is output, and the system-on-chip 110 is prohibited from continuing to attempt to start, so as to avoid the system-on-chip 110 from making multiple startup attempts and doing useless work, resulting in a waste of resources.

[0084] Figure 2 and Figure 3 FIG. 1 is a flow chart of a chip security boot method in one embodiment. It should be understood that although Figure 2 and Figure 3 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 2 and Figure 3 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0085] In one embodiment, Figure 4 As shown, a chip security startup device is provided, comprising:

[0086] The processing module 310 is used to load the file header of the configuration file corresponding to the startup program from the external memory 120 and parse it to obtain parsing information when the system-level chip 110 enters the secure startup mode;

[0087] A verification module 320, configured to extract the first engine firmware corresponding to the boot program from the external memory 120 according to the parsing information, and perform integrity verification on the first engine firmware to obtain a first engine verification result;

[0088] The verification module 320 is further configured to extract a first encryption system file corresponding to the startup program from the external memory 120 according to the parsing information when the first engine verification result is verification success, and perform integrity verification on the first encryption system file to obtain a first file verification result;

[0089] The verification module 320 is further configured to, when the verification result of the first file is successful, perform decryption and signature verification processing on the first encryption system file using the hardware accelerator driven by the first engine firmware to obtain a first signature verification result;

[0090] The startup module 330 is configured to execute the startup program to start the system-on-chip 110 when the first signature verification result is successful.

[0091] In one embodiment, the processing module 310 is further configured to:

[0092] When the system-on-chip 110 is powered on, obtaining a secure boot type of the system-on-chip 110;

[0093] When the secure boot type is the first boot type, controlling the system-on-chip 110 to enter a secure boot mode; or,

[0094] When the secure boot type is the second boot type, the system-on-chip 110 is controlled to enter the secure boot mode after completing the single-chip microcomputer fast boot.

[0095] In one embodiment, the processing module 310 is further configured to:

[0096] When the system-on-chip 110 enters the secure boot mode, a file header of a configuration file corresponding to the boot program is loaded from the external memory 120 according to the first communication mode;

[0097] When the file header is successfully loaded according to the first communication mode, the file header is parsed to obtain parsing information; or,

[0098] When the file header fails to be loaded according to the first communication method, the file header corresponding to the startup program is loaded from the external memory 120 according to the second communication method; when the file header is successfully loaded according to the second communication method, the file header is parsed to obtain parsing information, wherein the transmission speed of the second communication method is greater than the transmission speed of the first communication method.

[0099] In one embodiment, the verification module 320 is further configured to:

[0100] Determine a target boot area and a target communication mode in the external memory 120 according to the parsed information;

[0101] Extracting the first engine firmware corresponding to the boot program from the target boot area in the external memory 120 according to the target communication mode, and transferring the first engine firmware to a first designated storage location;

[0102] Performing an integrity check on the first engine firmware to obtain a first engine check result.

[0103] In one embodiment, the verification module 320 is further configured to:

[0104] Determine the target communication mode according to the communication mode corresponding to the file start mark in the parsed information;

[0105] When the parsed information contains a valid activation boot area mark, the boot area corresponding to the activation boot area mark is used as the target boot area, wherein the external memory 120 includes at least two boot areas; or

[0106] When the parsed information does not contain a valid activation boot area mark, the boot area containing the latest generated file is used as the target boot area.

[0107] In one embodiment, the verification module 320 is further configured to:

[0108] When the first engine verification result is a verification failure, extracting the second engine firmware corresponding to the startup program from the non-target startup area in the external memory 120 according to the target communication mode, and transferring the second engine firmware to the first designated storage location;

[0109] Performing integrity check on the second engine firmware to obtain a second engine check result;

[0110] When the second engine verification result is successful, extracting the first encrypted system file corresponding to the startup program from the target startup area in the external memory 120 according to the target communication mode, and transferring the first encrypted system file to the second designated storage location;

[0111] Performing an integrity check on the first encryption system file to obtain the first file verification result.

[0112] In one embodiment, the verification module 320 is further configured to:

[0113] When the first file verification result is a verification failure, extracting a second encrypted system file corresponding to the startup program from the non-target startup area in the external memory 120 according to the target communication mode, and transferring the second encrypted system file to a second designated storage location;

[0114] Performing integrity check on the second encryption system file to obtain a second file verification result;

[0115] When the verification result of the second file is successful, the hardware accelerator driven by the target engine firmware is used to perform decryption and signature verification processing on the second encryption system file to obtain a second signature verification result, wherein the target engine firmware is the first engine firmware or the second engine firmware that has successfully been verified;

[0116] The startup module 330 is further configured to, when the second signature verification result is successful, replace the first encrypted system file in the target startup area with the second encrypted system file, and then execute the startup program to start the system-on-chip 110 .

[0117] like Figure 5 As shown, an embodiment of the present application provides a computer device, including a processor 711, a communication interface 712, a memory 713 and a communication bus 714, wherein the processor 711, the communication interface 712, and the memory 713 communicate with each other through the communication bus 714;

[0118] Memory 713, used for storing computer programs;

[0119] The processor 711 is used to implement the chip secure boot method provided by any one of the aforementioned method embodiments when executing the program stored in the memory 713.

[0120] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0121] In one embodiment, the chip security boot system provided by the present application can be implemented in the form of a computer program. The computer program can be Figure 5 The memory of the computer device can store various program modules that constitute the chip security boot system, such as: Figure 4The processing module 310, the verification module 320 and the startup module 330 are shown. The computer program composed of various program modules enables the processor to execute the chip security startup method of each embodiment of the present application described in this specification.

[0122] Figure 5 The computer device shown can be Figure 4 The processing module 310 in the chip secure boot system shown executes when the system-level chip 110 enters the secure boot mode, loads the file header of the configuration file corresponding to the boot program from the external memory 120 and performs parsing processing to obtain parsing information. The computer device can extract the first engine firmware corresponding to the boot program from the external memory 120 according to the parsing information through the verification module 320, and perform integrity verification on the first engine firmware to obtain the first engine verification result; the verification module 320 is also used to extract the first encryption system file corresponding to the boot program from the external memory 120 according to the parsing information when the first engine verification result is a successful verification, and perform integrity verification on the first encryption system file to obtain the first file verification result; the verification module 320 is also used to decrypt and verify the first encryption system file using the hardware accelerator driven by the first engine firmware when the first file verification result is a successful verification, and obtain the first verification result. The computer device can execute the boot program to start the system-level chip 110 through the startup module 330 when the first verification result is a successful verification.

[0123] An embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the chip secure boot method provided by any of the aforementioned method embodiments is implemented.

[0124] The system embodiment described above is merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0125] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0126] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative can be used.

[0127] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A chip secure boot method, characterized in that: The method comprises: When the system-level chip enters the secure boot mode, the file header of the configuration file corresponding to the boot program is loaded from the external memory and parsed to obtain parsing information; Extracting the first engine firmware corresponding to the startup program from the external memory according to the parsed information, and performing integrity check on the first engine firmware to obtain a first engine check result; When the first engine verification result is successful, extracting a first encryption system file corresponding to the startup program from the external memory according to the parsing information, and performing integrity verification on the first encryption system file to obtain a first file verification result; When the first file verification result is successful, the first encryption system file is decrypted and signature verified by using the hardware accelerator driven by the first engine firmware to obtain a first signature verification result; When the first signature verification result is successful, the startup program is executed to start the system-on-chip.

2. The method according to claim 1, characterized in that When the system-level chip enters the secure boot mode, the file header of the configuration file corresponding to the boot program is loaded from the external memory and parsed, and before obtaining the parsed information, the method further includes: When the system-on-chip is powered on, obtaining a secure boot type of the system-on-chip; When the secure boot type is the first boot type, controlling the system-on-chip to enter a secure boot mode; or, When the secure boot type is the second boot type, the system-on-chip is controlled to enter the secure boot mode after completing the single-chip microcomputer fast boot.

3. The method according to claim 1, characterized in that When the system-level chip enters the secure boot mode, the file header of the configuration file corresponding to the boot program is loaded from the external memory and parsed to obtain parsed information, including: When the system-on-chip enters the secure boot mode, loading a file header of a configuration file corresponding to the boot program from an external memory in accordance with a first communication mode; When the file header is successfully loaded according to the first communication mode, the file header is parsed to obtain parsing information; or, When the file header fails to be loaded according to the first communication method, the file header corresponding to the startup program is loaded from the external memory according to the second communication method; when the file header is successfully loaded according to the second communication method, the file header is parsed to obtain parsing information, wherein the transmission speed of the second communication method is greater than the transmission speed of the first communication method.

4. The method according to claim 1, characterized in that: The extracting the first engine firmware corresponding to the boot program from the external memory according to the parsed information, and performing integrity check on the first engine firmware to obtain a first engine check result, includes: Determine a target startup area and a target communication mode in the external memory according to the parsed information; Extracting the first engine firmware corresponding to the startup program from the target startup area in the external memory according to the target communication mode, and transferring the first engine firmware to a first designated storage location; Performing an integrity check on the first engine firmware to obtain a first engine check result.

5. The method according to claim 4, characterized in that The step of determining the target boot area and the target communication mode in the external memory according to the parsed information includes: Determine the target communication mode according to the communication mode corresponding to the file start mark in the parsed information; When the parsed information contains a valid activation boot area mark, the boot area corresponding to the activation boot area mark is used as the target boot area, wherein the external memory includes at least two boot areas; or When the parsed information does not contain a valid activation boot area mark, the boot area containing the latest generated file is used as the target boot area.

6. The method according to claim 4, characterized in that After performing integrity check on the first engine firmware to obtain the first engine check result, the method further includes: When the first engine verification result is a verification failure, extracting the second engine firmware corresponding to the startup program from the non-target startup area in the external memory according to the target communication mode, and transferring the second engine firmware to the first designated storage location; Performing integrity check on the second engine firmware to obtain a second engine check result; When the second engine verification result is successful, extracting the first encrypted system file corresponding to the startup program from the target startup area in the external memory according to the target communication mode, and transferring the first encrypted system file to the second designated storage location; Performing an integrity check on the first encryption system file to obtain the first file verification result.

7. The method according to claim 6, characterized in that After performing integrity verification on the first encryption system file to obtain a first file verification result, the method further includes: When the first file verification result is a verification failure, extracting a second encrypted system file corresponding to the startup program from the non-target startup area in the external memory according to the target communication mode, and transferring the second encrypted system file to a second designated storage location; Performing integrity check on the second encryption system file to obtain a second file verification result; When the verification result of the second file is successful, the hardware accelerator driven by the target engine firmware is used to perform decryption and signature verification processing on the second encryption system file to obtain a second signature verification result, wherein the target engine firmware is the first engine firmware or the second engine firmware that has successfully been verified; When the second signature verification result is successful, the first encrypted system file in the target startup area is replaced with the second encrypted system file, and then the startup program is executed to start the system-on-chip.

8. A chip secure boot system, characterized in that: The chip security boot system includes a system-level chip and an external memory that are communicatively connected, the system-level chip includes a chip security boot device, and the chip security boot device includes: A processing module, used for loading a file header of a configuration file corresponding to a startup program from an external memory and performing parsing processing to obtain parsing information when the system-level chip enters a secure startup mode; A verification module, configured to extract the first engine firmware corresponding to the startup program from the external memory according to the parsing information, and perform integrity verification on the first engine firmware to obtain a first engine verification result; The verification module is further configured to extract a first encryption system file corresponding to the startup program from the external memory according to the parsing information when the first engine verification result is verification success, and perform integrity verification on the first encryption system file to obtain a first file verification result; The verification module is further configured to, when the verification result of the first file is successful, use the hardware accelerator driven by the first engine firmware to perform decryption and signature verification processing on the first encryption system file to obtain a first signature verification result; A startup module is used to execute the startup program to start the system-on-chip when the first signature verification result is successful.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Citation Information

Cited By

  • Fast firmware loading method and circuit for photoelectric DSP chip and optical module

    CN120743366A

  • A firmware fast loading method and circuit of a photoelectric DSP chip and an optical module

    CN120743366B