Chip startup control method and system, and electronic device

Abstract

This invention provides a chip boot control method, system, and electronic device, relating to the field of chip control technology. This solution achieves step-by-step verification of the image without the need for certificate signing, reducing the amount and frequency of data transmission between firmware levels. In addition, the authentication code involved in this solution is obtained through dynamic calculation, and its related keys are not stored in plaintext, thereby significantly reducing the risk of key decryption.

Description

Technical Field

[0001] This invention relates to the field of chip control technology, and in particular to a chip startup control method, system and electronic device. Background Technology

[0002] During the chip's boot process, firmware needs to be loaded from external storage devices such as Flash into the chip's internal memory (e.g., SRAM, CPU core) and executed to complete chip initialization and the startup of subsequent business functions. However, commonly used storage devices such as Flash typically have read and write capabilities, making the firmware stored within them vulnerable to unauthorized tampering. Once the firmware is tampered with, it can not only cause abnormal chip booting and prevent the device from operating normally, but may also lead to the leakage of sensitive data such as business data and user configuration information within the device, posing a serious threat to device security and user rights.

[0003] To address the aforementioned firmware tampering issues, the industry widely employs secure boot technology to verify the legitimacy of firmware. The most common secure boot solution is certificate verification. In this solution, in addition to storing the firmware itself, the storage device also simultaneously stores the corresponding certificate signature. During the chip's boot phase, the loaded firmware undergoes mandatory signature authentication. Only when authentication is successful (i.e., the firmware has not been tampered with) is the firmware allowed to run normally, thus achieving the goal of firmware tamper prevention.

[0004] In practical applications, the firmware required for chip startup is typically divided into a multi-level structure, such as the First Stage Boot Loader (FSBL), Second Stage Boot Loader (SSBL), and Operating System (OS) kernel loaded and executed sequentially. Each level of firmware must pass security verification to complete the startup process. However, due to the large computational load of the signature authentication process, loading each level of firmware requires an additional signature authentication step, which significantly extends the overall chip startup time and affects the device's startup efficiency.

[0005] The implementation of the above certificate verification method also requires the establishment of a CA digital certificate center and a complete system for generating, distributing, storing and managing signature keys. This not only increases the complexity of the solution but also significantly increases the cost of using and maintaining the secure boot solution, which is not conducive to the promotion and application of this secure boot solution in chip products that require low cost and high boot efficiency.

[0006] Furthermore, the Hash-based Message Authentication Code (HMAC) key involved in the chip startup process is stored in plaintext in the chip's One-Time Program (OTP) component. Since the security of HMAC highly depends on the confidentiality of the key, once the key is leaked, the integrity of the data and the verification mechanism can be compromised by forging the HMAC signature. In addition, the HMAC key programming process is complex. To prevent the HMAC key from being leaked during the programming step, the HMAC key must be encrypted and transmitted using the Diffie-Hellman key exchange algorithm, making the verification process quite complicated. Summary of the Invention

[0007] In view of this, the purpose of the present invention is to provide a chip boot control method, system and electronic device. This scheme realizes the step-by-step verification of the image without the need for certificate signing, reducing the amount and frequency of data transmission between firmware levels. In addition, the authentication code involved in this scheme is obtained through dynamic calculation, and its related keys are not stored in plaintext, thereby greatly reducing the risk of key decryption.

[0008] In a first aspect, embodiments of the present invention provide a chip boot control method, wherein the chip includes a processor and a flash memory, and the processor is connected to the flash memory via a built-in flash controller; the method includes:

[0009] The processor's ROM controller, OTP controller, and flash controller are initialized, and the first boot image, second boot image, and operating system image contained in the flash memory are initialized.

[0010] Obtain the first baseline authentication code corresponding to the first boot image, calculate the first calculated authentication code corresponding to the first boot image using the ROM controller and OTP controller, and then obtain the first comparison result corresponding to the first baseline authentication code and the first calculated authentication code.

[0011] Obtain the second baseline authentication code corresponding to the second boot image, calculate the second calculation authentication code corresponding to the second boot image based on the first boot image and control the flash memory, and then obtain the second comparison result corresponding to the second baseline authentication code and the second calculation authentication code.

[0012] Obtain the third baseline authentication code corresponding to the operating system image, calculate the third calculation authentication code corresponding to the operating system image based on the second boot image and control the flash memory, and then obtain the third comparison result corresponding to the third baseline authentication code and the third calculation authentication code.

[0013] The control chip executes the startup process based on the first comparison result, the second comparison result, and the third comparison result.

[0014] Optionally, the steps of obtaining the first baseline authentication code corresponding to the first boot image, calculating the first calculated authentication code corresponding to the first boot image using the ROM controller and the OTP controller, and then obtaining the first comparison result corresponding to the first baseline authentication code and the first calculated authentication code include:

[0015] After the flash memory loads the first boot image, the first base authentication code corresponding to the first boot image is determined.

[0016] Obtain the original key contained in the ROM controller, and use the ROM controller to obtain the first salt value contained in the OTP controller;

[0017] After generating the first computation key corresponding to the first boot image using the original key and the first salt value, the first computation authentication code corresponding to the first boot image is calculated using the first computation key.

[0018] The first comparison result is determined based on the consistency judgment result between the first base authentication code and the first calculated authentication code.

[0019] Optionally, the step of determining the first comparison result based on the consistency judgment result between the first baseline authentication code and the first calculated authentication code includes:

[0020] Determine whether the first baseline authentication code and the first calculated authentication code are consistent;

[0021] If yes, generate the first pass flag corresponding to the first boot image; if no, generate the first pause flag corresponding to the chip.

[0022] The first comparison result is determined based on the first pass marker and the first pause marker.

[0023] Optionally, the step of obtaining the second baseline authentication code corresponding to the second boot image, calculating the second calculated authentication code corresponding to the second boot image based on the first boot image and controlling the flash memory, and then obtaining the second comparison result corresponding to the second baseline authentication code and the second calculated authentication code includes:

[0024] After the flash memory loads the second boot image, the second base authentication code corresponding to the second boot image is determined.

[0025] Obtain the original key contained in the ROM controller, and obtain the second salt value contained in the OTP controller based on the first boot image;

[0026] After generating the second computation key corresponding to the second boot image using the original key and the second salt value, the second computation key is used to calculate the second computation authentication code corresponding to the second boot image.

[0027] The second comparison result is determined based on the consistency judgment result between the second base authentication code and the second calculated authentication code.

[0028] Optionally, the step of determining the second comparison result based on the consistency judgment result between the second baseline authentication code and the second calculated authentication code includes:

[0029] Determine whether the second base authentication code is consistent with the second calculated authentication code;

[0030] If yes, generate the second pass flag corresponding to the second boot image; if no, generate the second pause flag corresponding to the chip.

[0031] The second comparison result is determined based on the second pass marker and the second pause marker.

[0032] Optionally, the steps of obtaining the third baseline authentication code corresponding to the operating system image, calculating the third calculation authentication code corresponding to the operating system image based on the second boot image and controlling the flash memory, and then obtaining the third comparison result corresponding to the third baseline authentication code and the third calculation authentication code include:

[0033] After the operating system image is loaded into the flash memory, the third-party authentication code corresponding to the operating system image is determined.

[0034] Obtain the original key contained in the ROM controller, and obtain the third salt value contained in the OTP controller based on the second boot image;

[0035] After generating the third computing key corresponding to the operating system image using the original key and the third salt value, the third computing authentication code corresponding to the operating system image is calculated using the third computing key.

[0036] The third comparison result is determined based on the consistency judgment result between the third base authentication code and the third calculated authentication code.

[0037] Optionally, the step of determining the third comparison result based on the consistency judgment result between the third baseline authentication code and the third calculated authentication code includes:

[0038] Determine whether the third base authentication code and the third calculated authentication code are consistent;

[0039] If yes, generate the third pass flag corresponding to the operating system image; if no, generate the third pause flag corresponding to the chip.

[0040] The third comparison result is determined based on the third pass marker and the third pause marker.

[0041] Optionally, the steps of the startup process controlled by the control chip based on the first comparison result, the second comparison result, and the third comparison result include:

[0042] Determine the first pass marker and the first pause marker corresponding to the first comparison result, the second pass marker and the second pause marker corresponding to the second comparison result, and the third pass marker and the third pause marker corresponding to the third comparison result;

[0043] When the first pause flag, the second pause flag, or the third pause flag is detected, the control chip enters the start interrupt state;

[0044] When the first pass marker, the second pass marker, and the third pass marker are detected, the control chip starts the operating system image.

[0045] Secondly, the present invention provides a chip boot control system, wherein the chip is equipped with a processor and a flash memory, and the processor is connected to the flash memory through a built-in flash controller; the system includes:

[0046] Initialization module: Used to initialize the ROM controller, OTP controller and flash controller contained in the processor, and to initialize the first boot image, second boot image and operating system image contained in the flash memory;

[0047] First comparison control module: used to obtain the first baseline authentication code corresponding to the first boot image, calculate the first calculated authentication code corresponding to the first boot image using the ROM controller and OTP controller, and then obtain the first comparison result corresponding to the first baseline authentication code and the first calculated authentication code;

[0048] The second comparison control module is used to obtain the second baseline authentication code corresponding to the second boot image, and after controlling the flash memory to calculate the second calculated authentication code corresponding to the second boot image based on the first boot image, obtain the second comparison result corresponding to the second baseline authentication code and the second calculated authentication code.

[0049] The third comparison control module is used to obtain the third benchmark authentication code corresponding to the operating system image, and after controlling the flash memory to calculate the third calculation authentication code corresponding to the operating system image based on the second boot image, obtain the third comparison result corresponding to the third benchmark authentication code and the third calculation authentication code.

[0050] Startup control execution module: used to control the chip to execute the startup process based on the first comparison result, the second comparison result, and the third comparison result.

[0051] Thirdly, embodiments of the present invention also provide an electronic device, which includes a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the steps of the chip startup control method provided in the first aspect.

[0052] This invention provides a chip boot control method, system, and electronic device. The chip includes a processor and a flash memory, with the processor connected to the flash memory via a built-in flash controller. During boot control of this type of chip, the method first initializes the ROM controller, OTP controller, and flash controller included in the processor, and initializes a first boot image, a second boot image, and an operating system image included in the flash memory. Then, it obtains a first baseline authentication code corresponding to the first boot image, calculates a first computed authentication code corresponding to the first boot image using the ROM controller and OTP controller, and obtains a first comparison result between the first baseline authentication code and the first computed authentication code. Next, it obtains a second baseline authentication code corresponding to the second boot image, calculates a second computed authentication code corresponding to the second boot image based on the first boot image, and obtains a second comparison result between the second baseline authentication code and the second computed authentication code. Then, it obtains a third baseline authentication code corresponding to the operating system image, calculates a third computed authentication code corresponding to the operating system image based on the second boot image, and obtains a third comparison result between the third baseline authentication code and the third computed authentication code. Finally, it controls the chip to execute the boot process based on the first comparison result, the second comparison result, and the third comparison result. This scheme enables step-by-step verification of the image without the need for certificate signing, reducing the amount and frequency of data transmission between different firmware levels. In addition, the authentication code involved in this scheme is obtained through dynamic calculation, and its related keys are not stored in plaintext, thereby significantly reducing the risk of key decryption.

[0053] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0054] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0055] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0056] Figure 1 A flowchart of a chip startup control method provided in an embodiment of the present invention;

[0057] Figure 2 This is a schematic diagram of the chip structure used in a chip startup control method provided in an embodiment of the present invention;

[0058] Figure 3 A flowchart of another chip startup control method provided in an embodiment of the present invention;

[0059] Figure 4 This is a flowchart of step S102 in a chip startup control method provided in an embodiment of the present invention;

[0060] Figure 5 This is a flowchart illustrating the process of obtaining a first comparison result by verifying the FSBL via ROM in a chip startup control method provided by an embodiment of the present invention.

[0061] Figure 6 This is a flowchart of step S103 in a chip startup control method provided in an embodiment of the present invention;

[0062] Figure 7 This is a flowchart illustrating the process of obtaining a second comparison result by verifying the SSBL through the FSBL in a chip startup control method provided by an embodiment of the present invention;

[0063] Figure 8 This is a flowchart of step S104 in a chip startup control method provided in an embodiment of the present invention;

[0064] Figure 9 This is a flowchart illustrating the process of obtaining a third comparison result by verifying the OS via SSBL in a chip startup control method provided in an embodiment of the present invention.

[0065] Figure 10 This is a flowchart of step S105 in a chip startup control method provided in an embodiment of the present invention;

[0066] Figure 11 This is a schematic diagram of a chip startup control system provided in an embodiment of the present invention;

[0067] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0068] icon:

[0069] 100 - Initialization module; 200 - First comparison control module; 300 - Second comparison control module; 400 - Third comparison control module; 500 - Startup control execution module;

[0070] 101 - Processor; 102 - Memory; 103 - Bus; 104 - Communication interface. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0072] To facilitate understanding of this embodiment, a chip startup control method disclosed in this embodiment of the invention will first be described. The chip includes a processor and a flash memory, with the processor connected to the flash memory via a built-in flash controller. The method is as follows: Figure 1 As shown, it includes:

[0073] Step S101: Initialize the ROM controller, OTP controller and flash controller contained in the processor, and initialize the first boot image, second boot image and operating system image contained in the flash memory.

[0074] After the chip is powered on, the processor first enters the initialization phase, comprehensively initializing its internally integrated core controller and various image files in the Flash memory, laying the foundation for subsequent image verification and boot processes. Specifically, the processor first initializes and configures its built-in ROM controller, OTP controller, and Flash controller: the ROM controller is initialized to enable it to read the basic boot instructions and verification-related logic stored in the CPU's built-in ROM; the OTP controller is initialized to unlock the OTP component's read permissions, ensuring that it can subsequently read the key-related information stored in the OTP component, and at the same time, the OTP controller's computing module is initialized to enable it to participate in authentication code calculation; the Flash controller is initialized to configure the Flash memory's communication timing, read / write rate, and other parameters, establishing a stable communication link between the processor and the Flash memory to ensure efficient reading of image files in the Flash memory. At the same time, the first boot image, the second boot image, and the operating system image pre-stored in the Flash memory are initialized, including verifying the legality of the storage address of each image file, confirming the integrity of the image file (preliminary check for storage corruption of the image), and synchronizing key information such as the storage address and size of each image file to the processor's registers, so as to facilitate the rapid location and reading of the target image in subsequent steps.

[0075] Step S102: Obtain the first baseline authentication code corresponding to the first boot image, calculate the first calculated authentication code corresponding to the first boot image using the ROM controller and the OTP controller, and then obtain the first comparison result corresponding to the first baseline authentication code and the first calculated authentication code.

[0076] After initialization, the verification process for the first boot image is initiated to ensure that the first boot image has not been illegally tampered with, thus guaranteeing the initial security of the chip startup. First, the processor reads the first baseline authentication code corresponding to the first boot image pre-stored in the Flash memory through the Flash controller. This first baseline authentication code is generated and stored in a designated secure area of ​​the Flash memory before the chip leaves the factory, based on the original, untampered first boot image, combined with a preset algorithm and key, and serves as the verification benchmark for the legitimacy of the first boot image. Subsequently, the processor calls on the ROM controller and OTP controller to work together to calculate the first calculated authentication code corresponding to the first boot image: the ROM controller reads the authentication code calculation logic stored in the CPU's built-in ROM, and the OTP controller reads the preset key information from the OTP component (this key is not stored in plaintext but obtained through dynamic access). Based on the above calculation logic and key information, the processor performs hash operations and authentication code generation on the first boot image read from the Flash memory to obtain the first calculated authentication code. Finally, the processor compares the first base authentication code and the first calculation authentication code byte by byte to obtain the first comparison result. If the two are completely consistent, the first comparison result is "verification passed", indicating that the first boot image has not been tampered with; if the two are different, the first comparison result is "verification failed", indicating that the first boot image may have been illegally tampered with.

[0077] Step S103: Obtain the second base authentication code corresponding to the second boot image, calculate the second calculated authentication code corresponding to the second boot image based on the first boot image and control the flash memory, and then obtain the second comparison result corresponding to the second base authentication code and the second calculated authentication code.

[0078] The verification process for the second boot image only begins when the first comparison result obtained in step S102 is "verification passed," ensuring the hierarchical nature and security of the verification and preventing unauthorized images from entering the subsequent boot process. First, the processor reads the second baseline authentication code corresponding to the second boot image pre-stored in the Flash memory through the Flash controller. This second baseline authentication code has the same generation logic as the first baseline authentication code; it is generated based on the original, unaltered second boot image and is stored securely in the Flash memory, serving as the verification baseline for the legitimacy of the second boot image. Subsequently, based on the first boot image that passed verification in step S102, the processor invokes its built-in control logic to send a control command to the Flash controller, controlling the Flash memory to start its local computation function and calculate the authentication code for the second boot image it stores. The Flash memory performs local hash operations and generates the authentication code based on the computation parameters (including key-related derived information and computation algorithms) transmitted from the first boot image, obtaining the second calculated authentication code. This process does not require the processor to participate in the entire computation, effectively reducing the processor's computational load and improving verification efficiency. Finally, the processor reads the second computational authentication code calculated from the Flash memory and compares it with the pre-read second baseline authentication code to obtain the second comparison result. The comparison logic is the same as in step S102. If they match, the verification is "passed"; if they do not match, the verification is "failed".

[0079] Step S104: Obtain the third baseline authentication code corresponding to the operating system image. After calculating the third calculation authentication code corresponding to the operating system image based on the second boot image and controlling the flash memory, obtain the third comparison result corresponding to the third baseline authentication code and the third calculation authentication code.

[0080] Only when the second comparison result obtained in step S103 is "verification passed" will the operating system image verification process begin, completing the final level of image verification before chip startup. First, the processor reads the third baseline authentication code corresponding to the pre-stored operating system image from the Flash memory via the Flash controller. This third baseline authentication code is a verification baseline generated and solidified based on the original, unaltered operating system image, ensuring the legitimacy of the operating system image. Subsequently, based on the second boot image that passed verification in step S103, the processor calls its built-in control logic to send control instructions to the Flash controller, controlling the Flash memory to continue executing local calculation functions and calculate the authentication code for the operating system image it stores. The Flash memory performs local hash operations and generates the authentication code based on the calculation parameters passed from the second boot image (which are independent of the parameters passed from the first boot image, improving security), obtaining the third calculated authentication code, further reducing the processor's computational burden and shortening the verification time. Finally, the processor reads the third verification code calculated from the Flash memory and compares it with the pre-read third baseline verification code to obtain the third comparison result. The comparison logic is the same as the first two levels of verification. If they match, the verification is "passed"; if they do not match, the verification is "failed".

[0081] Step S105: Based on the first comparison result, the second comparison result, and the third comparison result, the control chip executes the startup process.

[0082] The processor summarizes the first comparison result obtained in step S102, the second comparison result obtained in step S103, and the third comparison result obtained in step S104. Based on the summarized comparison results, it executes the corresponding chip boot control logic to ensure that the chip only completes booting when all images are valid. The specific control logic is as follows: If the first comparison result, the second comparison result, and the third comparison result are all "verification passed", it indicates that the boot images and operating system images at each level have not been illegally tampered with. The processor controls the chip to enter the normal boot process, sequentially loading the verified first boot image, second boot image, and operating system image into the chip's internal SRAM or CPU core, executing the corresponding boot instructions, and completing the chip initialization and business function startup. If any level of comparison result is "verification failed", it indicates that the image at the corresponding level is at risk of being tampered with. The processor immediately terminates the chip boot process and triggers a security alarm mechanism (such as outputting an alarm signal and locking chip operation permissions) to prevent security risks such as device abnormalities and sensitive data leakage caused by the operation of illegal images, ensuring the security and reliability of the chip boot process.

[0083] The structural diagram of the chip is shown below. Figure 2As shown, the chip boot control method is based on a preset hardware architecture. The chip integrates a CPU and a Flash memory. The CPU establishes a bidirectional communication connection with the Flash memory through its built-in Flash controller to read, control, and verify various image files in the Flash memory. The Flash memory pre-stores the original HMAC value and multi-level firmware image files, specifically including the first boot FSBL (First Stage Boot Loader) image, the second boot SSBL (First Stage Boot Loader) image, and the operating system OS (Operate System) image. The CPU also integrates a ROM controller and an OTP controller. The ROM controller controls the on-chip ROM program, and the OTP controller stores the corresponding salt value, which can be used to derive the real HMAC key through the HFDK algorithm.

[0084] Based on this, the above chip startup control method is as follows: Figure 3 As shown, after the chip boots up, it executes the on-chip program (Read Only Memory, ROM), the first stage boot loader (FSBL), the second stage boot loader (SSBL), and the operating system (OS) in sequence. During startup, the previous stage performs HMAC verification on the next stage, and the real HMAC key required for verification is dynamically calculated using the HKDF algorithm in the ROM.

[0085] Specifically, step S102 involves obtaining the first baseline authentication code corresponding to the first boot image, calculating the first calculated authentication code corresponding to the first boot image using the ROM controller and the OTP controller, and then obtaining the first comparison result corresponding to the first baseline authentication code and the first calculated authentication code. Figure 4 As shown, it includes:

[0086] Step S401: After controlling the flash memory to load the first boot image, determine the first base authentication code corresponding to the first boot image.

[0087] After the chip boots, the processor loads the first boot image (FSBL image) from the Flash memory into the chip's internal SRAM or a designated operating area via the built-in Flash controller. Simultaneously, the processor reads the first baseline authentication code (i.e., the FSBL HMAC value) pre-stored in the Flash memory, corresponding to the first boot image. This baseline authentication code is generated before the chip leaves the factory based on the original, tamper-proof first boot image, combined with a preset algorithm and key, and is stored in a secure area of ​​the Flash memory as a legitimacy benchmark for subsequent verification.

[0088] Step S402: Obtain the original key contained in the ROM controller, and use the ROM controller to obtain the first salt value contained in the OTP controller.

[0089] The processor invokes the ROM controller to read the pre-programmed raw key from the on-chip ROM (this key does not directly participate in the authentication code calculation, but only serves as the basis for key derivation). Simultaneously, the processor reads the first salt value stored in the One-Time Programmable (OTP) component through the OTP controller. This salt value is random data burned into the chip at the factory and bound to the first boot image verification. It is used to enhance the uniqueness and security of the key and can only be read through the dedicated interface of the OTP controller, and cannot be directly accessed externally.

[0090] Step S403: After generating the first computation key corresponding to the first boot image using the original key and the first salt value, calculate the first computation authentication code corresponding to the first boot image using the first computation key.

[0091] Based on the original key and the first salt value obtained in step S402, the processor calls the HKDF (HMAC-based Key Derivation Function) algorithm embedded in the ROM to dynamically derive the first computational key (i.e., the real HMAC key) used for the verification of the first boot image. This process does not directly expose the original key, but generates a temporary computational key through the salt value and algorithm, effectively reducing the risk of key leakage. Subsequently, the processor uses the first computational key to perform HMAC operations on the loaded first boot image to generate the corresponding first computational authentication code.

[0092] Step S404: Determine the first comparison result based on the consistency judgment result between the first base authentication code and the first calculated authentication code.

[0093] The processor compares the first baseline authentication code obtained in step S401 with the first calculated authentication code generated in step S403 byte by byte:

[0094] If the two are completely identical, it is determined that the first boot image has not been illegally tampered with, the first comparison result is "verification passed", and the verification process of the next level boot program is allowed;

[0095] If there is a difference between the two, it is determined that the first boot image is at risk of being tampered with. The first comparison result is "verification failed". The processor immediately terminates the chip boot process and triggers a security alarm mechanism to prevent security risks caused by the operation of illegal images.

[0096] The process of obtaining the first comparison result by verifying FSBL through ROM is as follows: Figure 5 As shown; first, the ROM reads the FSBL image from the flash; then, the ROM reads the salt value from the OTP and calculates the real HMAC key using the HKDF algorithm in combination with the original key. Next, the real HMAC key is used to calculate the HMAC of the FSBL image; finally, the calculated HMAC value is compared with the original FSBL HMAC value in the flash. Optionally, in determining the first comparison result based on the consistency judgment result between the first baseline authentication code and the first calculated authentication code, it is first determined whether the first baseline authentication code (HMAC in the flash) and the first calculated authentication code (calculated HMAC) are consistent; if they are, a first pass flag corresponding to the first boot image is generated for subsequent verification processing; if not, a first pause flag corresponding to the chip is generated; finally, the first comparison result is determined based on the first pass flag and the first pause flag. The first pause flag can control the chip to clear SRAM data and enter the WFI (Wait For Interrupt) state.

[0097] Optionally, step S103 involves obtaining the second baseline authentication code corresponding to the second boot image, calculating the second calculated authentication code corresponding to the second boot image based on the first boot image and controlling the flash memory, and then obtaining the second comparison result corresponding to the second baseline authentication code and the second calculated authentication code. Figure 6 As shown, it includes:

[0098] Step S601: After controlling the flash memory to load the second boot image, determine the second base authentication code corresponding to the second boot image.

[0099] After the first boot image (FSBL) passes verification, the processor loads the second boot image (SSBL) from the Flash memory into a designated operating area within the chip via the Flash controller. Simultaneously, the processor reads the second baseline authentication code (i.e., the SSBL HMAC value) pre-stored in the Flash memory, corresponding to the second boot image. This baseline authentication code is generated before the chip leaves the factory based on the original, tamper-proof second boot image, combined with a preset algorithm and key, and is stored in a secure area of ​​the Flash memory as a legitimacy benchmark for subsequent verification.

[0100] Step S602: Obtain the original key contained in the ROM controller, and obtain the second salt value contained in the OTP controller based on the first boot image.

[0101] The processor invokes the ROM controller to read the pre-programmed raw key from the on-chip ROM (this key does not directly participate in the authentication code calculation, but only serves as the basis for key derivation). Simultaneously, based on the verified first boot image, the processor reads the second salt value bound to the second boot image from the One-Time Programmable (OTP) component via the OTP controller. This salt value is random data burned once at the chip's factory, independent of the first salt value, used to enhance the security of the second boot image verification, and can only be read through the OTP controller's dedicated interface, not directly accessible externally.

[0102] Step S603: After generating the second computation key corresponding to the second boot image using the original key and the second salt value, calculate the second computation authentication code corresponding to the second boot image using the second computation key.

[0103] Based on the original key and second salt value obtained in step S602, the processor calls the HKDF (HMAC-based Key Derivation Function) algorithm embedded in the ROM to dynamically derive a second computational key (i.e., the real HMAC key) for verifying the second boot image. This process does not directly expose the original key, but generates a temporary computational key through the salt value and algorithm, effectively reducing the risk of key leakage. Subsequently, the processor sends the second computational key and computation instructions to the Flash controller, controlling the Flash memory to perform HMAC operations on the loaded second boot image locally, generating the corresponding second computational authentication code. This process is executed locally by the Flash memory without the processor's full involvement, effectively reducing the processor's computational load and improving verification efficiency.

[0104] Step S604: Determine the second comparison result based on the consistency judgment result between the second base authentication code and the second calculated authentication code.

[0105] The processor compares the second base authentication code obtained in step S601 with the second calculated authentication code generated in step S603 byte by byte:

[0106] If the two are completely identical, it is determined that the second boot image has not been illegally tampered with, the second comparison result is "verification passed", and the verification process of the operating system image is allowed to begin.

[0107] If there is a difference between the two, it is determined that the second boot image is at risk of being tampered with. The second comparison result is "verification failed". The processor immediately terminates the chip boot process and triggers a security alarm mechanism to prevent security risks caused by the operation of illegal images.

[0108] The process of obtaining the second comparison result by verifying SSBL with FSBL is as follows: Figure 7 As shown; first, the FSBL reads the SSBL image from Flash; then, the FSBL reads the salt value from the OTP and calculates the real HMAC key using the HKDF algorithm in combination with the original key. Next, the FSBL uses the real HMAC key to perform HMAC calculation on the SSBL image; finally, the FSBL compares the calculated HMAC value with the original SSBL HMAC value in Flash. If they match, the boot process continues; if they do not match, the data in SRAM is cleared and the boot process is paused. Optionally, in determining the second comparison result based on the consistency judgment result between the second base authentication code and the second calculated authentication code, it is first determined whether the second base authentication code and the second calculated authentication code are consistent; if they are, a second pass flag corresponding to the second boot image is generated; if not, a second pause flag corresponding to the chip is generated; finally, the second comparison result is determined based on the second pass flag and the second pause flag. The second pause flag can control the chip to clear SRAM data and enter the WFI (Wait For Interrupt) state.

[0109] Optionally, step S104 involves obtaining the third baseline authentication code corresponding to the operating system image, calculating the third calculation authentication code corresponding to the operating system image based on the second boot image and controlling the flash memory, and then obtaining the third comparison result corresponding to the third baseline authentication code and the third calculation authentication code. Figure 8 As shown, it includes:

[0110] Step S801: After controlling the flash memory to load the operating system image, determine the third base authentication code corresponding to the operating system image.

[0111] After the second boot image (SSBL) passes verification, the processor loads the operating system image (OS image) from the Flash memory into a designated running area within the chip via the Flash controller. Simultaneously, the processor reads the third baseline authentication code (OS HMAC value) pre-stored in the Flash memory, corresponding to this operating system image. This baseline authentication code is generated before the chip leaves the factory based on the original, tamper-proof operating system image, combined with a preset algorithm and key, and is stored in a secure area of ​​the Flash memory as a legitimacy benchmark for subsequent verification.

[0112] Step S802: Obtain the original key contained in the ROM controller, and obtain the third salt value contained in the OTP controller based on the second boot image.

[0113] The processor invokes the ROM controller to read the pre-installed raw key from the on-chip ROM (this key does not directly participate in the authentication code calculation, but only serves as the basis for key derivation). Simultaneously, based on the verified second boot image, the processor reads the third salt value, bound to the operating system image, from the One-Time Programmable (OTP) component via the OTP controller. This salt value is random data burned once at the chip's factory, independent of the first and second salt values, used to enhance the security of the operating system image verification, and can only be read through the OTP controller's dedicated interface, not directly accessible externally.

[0114] Step S803: After generating the third computing key corresponding to the operating system image using the original key and the third salt value, calculate the third computing authentication code corresponding to the operating system image using the third computing key.

[0115] Based on the original key and third salt value obtained in step S802, the processor calls the HKDF (HMAC-based Key Derivation Function) algorithm embedded in the ROM to dynamically derive the third computation key (i.e., the real HMAC key) used for operating system image verification. This process does not directly expose the original key, but generates a temporary computation key through the salt value and algorithm, effectively reducing the risk of key leakage. Subsequently, the processor sends the third computation key and computation instructions to the Flash controller, controlling the Flash memory to perform HMAC operations on the loaded operating system image locally, generating the corresponding third computation authentication code. This process is executed locally by the Flash memory without the processor's full involvement, effectively reducing the processor's computational load and improving verification efficiency.

[0116] Step S804: Determine the third comparison result based on the consistency judgment result between the third base authentication code and the third calculated authentication code.

[0117] The processor compares the third baseline authentication code obtained in step S801 with the third computational authentication code generated in step S803 byte by byte:

[0118] If the two are completely identical, it is determined that the operating system image has not been illegally tampered with, and the third comparison result is "verification passed". The chip is allowed to enter the normal boot process and execute each level of the image in sequence. If there are differences between the two, it is determined that the operating system image is at risk of being tampered with, and the third comparison result is "verification failed". The processor immediately terminates the chip boot process and triggers a security alarm mechanism to prevent security risks such as device abnormalities and sensitive data leakage caused by the illegal operation of the image.

[0119] The process of obtaining the third comparison result by verifying OS using SSBL is as follows: Figure 9 As shown, firstly, SSBL reads the OS image from Flash; then, SSBL reads the salt value from OTP and calculates the real HMAC key using the HKDF algorithm in combination with the original key. Next, SSBL uses the real HMAC key to perform HMAC calculation on the OS image; finally, SSBL compares the calculated HMAC value with the original OS HMAC value in Flash. If they match, the boot process continues; if they don't match, the data in SRAM is cleared and the boot process is paused. Optionally, in determining the third comparison result based on the consistency judgment result between the third benchmark authentication code and the third calculated authentication code, it is first determined whether the third benchmark authentication code and the third calculated authentication code are consistent; if they are, a third pass flag corresponding to the operating system image is generated; if not, a third pause flag corresponding to the chip is generated; the third comparison result is determined based on the third pass flag and the third pause flag. The third pause flag can control the chip to clear SRAM data and enter the WFI (Wait For Interrupt) state.

[0120] Optionally, based on the first comparison result, the second comparison result, and the third comparison result, the control chip executes step S105 of the startup process, such as... Figure 10 As shown, it includes:

[0121] Step S1001: Determine the first pass mark and the first pause mark corresponding to the first comparison result, the second pass mark and the second pause mark corresponding to the second comparison result, and the third pass mark and the third pause mark corresponding to the third comparison result.

[0122] Based on the first, second, and third comparison results output in steps S102, S103, and S104, the processor configures and maps mutually exclusive binary status flags for each level of the verification process, completing the digitization and standardization conversion of the verification results. Specifically, for the first comparison result, if it is determined to be "verification passed," the processor sets the first pass flag in the designated status register and clears the first pause flag; if it is determined to be "verification failed," it sets the first pause flag and clears the first pass flag. Similarly, for the second comparison result, a second pass flag or a second pause flag is generated and stored; for the third comparison result, a third pass flag or a third pause flag is generated and stored. These status flags are uniformly written into the processor's dedicated startup control register group, providing a unique and quickly retrieved judgment basis for subsequent startup process decisions.

[0123] Step S1002: When the first pause marker, the second pause marker, or the third pause marker is detected, the control chip enters the start interrupt state.

[0124] The processor polls or monitors the status flags in the boot control register group in real time through hardware logic. When any one of the first, second, or third pause flags is detected as set, a security anomaly is immediately determined in the chip boot process, triggering a preset boot interrupt mechanism and controlling the chip to enter a boot interrupt state. In this state, the processor immediately terminates the loading and execution of all current images, prohibiting the execution of any subsequent program code; simultaneously, it activates the chip's security alarm and protection logic, including but not limited to outputting hardware alarm signals, locking read and write permissions for the Flash memory, clearing temporary data in the internal SRAM, and writing the exception code of this boot failure (including specific failure verification level information) to the OTP component or a designated non-volatile memory area for subsequent fault investigation and tracing, fundamentally blocking the security risks caused by the execution of unauthorized images.

[0125] Step S1003: When the first pass marker, the second pass marker, and the third pass marker are detected, the control chip starts the operating system image.

[0126] The processor continuously monitors the boot control register group. When it detects that the first pass flag, the second pass flag, and the third pass flag are all set simultaneously, and no pause flag is triggered, it determines that all levels of firmware images have passed the validity check. At this point, the processor controls the chip to exit the verification process and enter the formal business startup phase: according to the chip's preset boot sequence, after completing the initialization of the first boot image and the second boot image, the processor loads the verified operating system (OS) image completely into the chip's internal main memory area (such as DDR SDRAM) through the Flash controller, and jumps the CPU's program counter (PC) to the entry address of the operating system image. Subsequently, the processor releases boot control, and the operating system image takes over all chip resources, executing subsequent processes such as kernel initialization, driver loading, and application startup, ultimately completing the chip's complete boot and entering normal working state.

[0127] The chip startup control method in the above embodiments has the following technical effects:

[0128] The HMAC key is stored in non-plaintext, and the real HMAC key is derived through HKDF to reduce the risk of key leakage.

[0129] When a verification error occurs, the data in RAM is directly cleared to reduce the risk of data or key leakage.

[0130] The startup control process is simple, eliminating the need for data transfer and back-and-forth switching between different firmware levels, and it has high versatility.

[0131] No certificate signing center is required, resulting in low usage and maintenance costs.

[0132] In summary, this method achieves step-by-step verification of the image without the need for certificate signing, reducing the amount and frequency of data transmission between different firmware levels. Furthermore, the authentication code involved in this method is obtained through dynamic calculation, and its related keys are not stored in plaintext, thereby significantly reducing the risk of key decryption.

[0133] Corresponding to the above-described chip startup control method embodiments, this invention also provides a chip startup control system, wherein the chip includes a processor and a flash memory, and the processor is connected to the flash memory via a built-in flash controller; as shown Figure 11 As shown, the system includes:

[0134] Initialization module 100: used to initialize the ROM controller, OTP controller and flash controller contained in the processor, and to initialize the first boot image, second boot image and operating system image contained in the flash memory;

[0135] First comparison control module 200: used to obtain the first base authentication code corresponding to the first boot image, calculate the first calculated authentication code corresponding to the first boot image using the ROM controller and OTP controller, and then obtain the first comparison result corresponding to the first base authentication code and the first calculated authentication code;

[0136] The second comparison control module 300 is used to obtain the second base authentication code corresponding to the second boot image, and after controlling the flash memory to calculate the second calculated authentication code corresponding to the second boot image based on the first boot image, obtain the second comparison result corresponding to the second base authentication code and the second calculated authentication code.

[0137] The third comparison control module 400 is used to obtain the third benchmark authentication code corresponding to the operating system image, and after controlling the flash memory to calculate the third calculation authentication code corresponding to the operating system image based on the second boot image, obtain the third comparison result corresponding to the third benchmark authentication code and the third calculation authentication code.

[0138] Startup control execution module 500: used to control the chip to execute the startup process based on the first comparison result, the second comparison result and the third comparison result.

[0139] As can be seen from the chip-based boot control system described above, the system achieves step-by-step verification of the image without the need for certificate signing, reducing the amount and frequency of data transmission between different firmware levels. In addition, the authentication code involved in the system is obtained through dynamic calculation, and its related keys are not stored in plaintext, thereby significantly reducing the risk of key decryption.

[0140] The chip startup control system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned chip startup control method embodiment. For the sake of brevity, any parts not mentioned in this system embodiment can be referred to the corresponding content in the aforementioned chip startup control method embodiment.

[0141] This embodiment also provides an electronic device, the structural schematic diagram of which is shown below. Figure 12 As shown, the device includes a processor 101 and a memory 102; wherein, the memory 102 is used to store one or more computer instructions, which are executed by the processor to implement the steps of the chip startup control method described above.

[0142] Figure 12 The electronic device shown also includes a bus 103 and a communication interface 104, with the processor 101, communication interface 104 and memory 102 connected via the bus 103.

[0143] The memory 102 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. The bus 103 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0144] The communication interface 104 is used to connect to at least one user terminal and other network units through a network interface, and to send encapsulated IPv4 packets or IPv4 packets to the user terminal through the network interface.

[0145] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. The processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 102. The processor 101 reads the information in memory 102 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0146] This invention also provides a storage medium storing a computer program, which, when run by a processor, executes the steps of the chip startup control method described in the foregoing embodiments.

[0147] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, devices, and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0148] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0149] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0150] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, electronic device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0151] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of protection of the claims.

Claims

1. A chip startup control method, characterized in that, The chip includes a processor and a flash memory, the processor being connected to the flash memory via a built-in flash controller; the method includes: The ROM controller, OTP controller, and flash controller included in the processor are initialized, and the first boot image, second boot image, and operating system image included in the flash memory are initialized. After loading the first boot image into the flash memory, a first baseline authentication code corresponding to the first boot image is determined; the original key contained in the ROM controller is obtained, and the first salt value contained in the OTP controller is obtained using the ROM controller; after generating a first calculation key corresponding to the first boot image using the original key and the first salt value, the first calculation authentication code corresponding to the first boot image is calculated using the first calculation key; a first comparison result is determined based on the consistency judgment result between the first baseline authentication code and the first calculation authentication code. After loading the second boot image into the flash memory, determine the second baseline authentication code corresponding to the second boot image; obtain the second salt value contained in the OTP controller based on the first boot image; generate the second calculation key corresponding to the second boot image using the original key and the second salt value, and calculate the second calculation authentication code corresponding to the second boot image using the second calculation key; determine the second comparison result based on the consistency judgment result between the second baseline authentication code and the second calculation authentication code. After loading the operating system image into the flash memory, the third baseline authentication code corresponding to the operating system image is determined; the third salt value contained in the OTP controller is obtained based on the second boot image; after generating the third computing key corresponding to the operating system image using the original key and the third salt value, the third computing key is used to calculate the third computing authentication code corresponding to the operating system image; and the third comparison result is determined based on the consistency judgment result between the third baseline authentication code and the third computing authentication code. The system determines the first pass flag and the first pause flag corresponding to the first comparison result, the second pass flag and the second pause flag corresponding to the second comparison result, and the third pass flag and the third pause flag corresponding to the third comparison result; when the first pause flag, the second pause flag, or the third pause flag is detected, the system controls the chip to enter the startup interrupt state; when the first pass flag, the second pass flag, and the third pass flag are detected, the system controls the chip to start the operating system image.

2. The chip startup control method according to claim 1, characterized in that, The step of determining the first comparison result based on the consistency judgment result between the first base authentication code and the first calculated authentication code includes: Determine whether the first base authentication code is consistent with the first calculated authentication code; If yes, then generate a first pass flag corresponding to the first boot image; if no, then generate a first pause flag corresponding to the chip. The first comparison result is determined based on the first pass marker and the first pause marker.

3. The chip startup control method according to claim 1, characterized in that, The step of determining the second comparison result based on the consistency judgment result between the second base authentication code and the second calculated authentication code includes: Determine whether the second base authentication code is consistent with the second calculated authentication code; If yes, then generate a second pass flag corresponding to the second boot image; if no, then generate a second pause flag corresponding to the chip. The second comparison result is determined based on the second pass marker and the second pause marker.

4. The chip startup control method according to claim 1, characterized in that, The step of determining the third comparison result based on the consistency judgment result between the third base authentication code and the third calculated authentication code includes: Determine whether the third base authentication code is consistent with the third calculated authentication code; If yes, then generate a third pass flag corresponding to the operating system image; if no, then generate a third pause flag corresponding to the chip. The third comparison result is determined based on the third pass marker and the third pause marker.

5. A chip-based boot control system, characterized in that, The chip includes a processor and a flash memory, and the processor is connected to the flash memory via a built-in flash controller; the system includes: Initialization module: used to initialize the ROM controller, OTP controller and flash controller contained in the processor, and to initialize the first boot image, second boot image and operating system image contained in the flash memory; The first comparison control module is used to: control the flash memory to load the first boot image, determine the first base authentication code corresponding to the first boot image; obtain the original key contained in the ROM controller, and use the ROM controller to obtain the first salt value contained in the OTP controller; generate the first calculation key corresponding to the first boot image using the original key and the first salt value, and then use the first calculation key to calculate the first calculation authentication code corresponding to the first boot image; and determine the first comparison result based on the consistency judgment result between the first base authentication code and the first calculation authentication code. The second comparison control module is used to control the flash memory to load the second boot image, determine the second base authentication code corresponding to the second boot image; obtain the second salt value contained in the OTP controller based on the first boot image; generate the second calculation key corresponding to the second boot image using the original key and the second salt value, and calculate the second calculation authentication code corresponding to the second boot image using the second calculation key; and determine the second comparison result based on the consistency judgment result between the second base authentication code and the second calculation authentication code. The third comparison control module is used to: control the flash memory to load the operating system image, determine the third baseline authentication code corresponding to the operating system image; obtain the third salt value contained in the OTP controller based on the second boot image; generate the third calculation key corresponding to the operating system image using the original key and the third salt value, and calculate the third calculation authentication code corresponding to the operating system image using the third calculation key; and determine the third comparison result based on the consistency judgment result between the third baseline authentication code and the third calculation authentication code. Startup control execution module: used to determine the first pass flag and the first pause flag corresponding to the first comparison result, the second pass flag and the second pause flag corresponding to the second comparison result, and the third pass flag and the third pause flag corresponding to the third comparison result; when the first pause flag, the second pause flag, or the third pause flag is detected, control the chip to enter the startup interrupt state; when the first pass flag, the second pass flag, and the third pass flag are detected, control the chip to start the operating system image.

6. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the steps of the chip startup control method according to any one of claims 1 to 4.

Images