Secure starting optimization method, device and system of terminal system, chip and storage medium

Abstract

The invention discloses a secure startup optimization method, device and system of a terminal system, a chip and a storage medium, and belongs to the technical field of embedded system security. The method is applied to a development end and comprises the steps that when it is detected that an initial startup root private key of an equipment end is leaked, a new target startup root key is created, and the target startup root key comprises a target startup root private key and a target startup root public key; obtaining a standby boot root public key version number of the device end, and creating a target boot root public key version number based on the standby boot root public key version number; acquiring a secure startup root private key of the device end, and signing the target startup root public key based on the secure startup root private key to obtain a target startup root public key signature; and sending the target public key triple to the device end based on the secure channel. The invention provides a new normal form with important reference value for the future development of the security startup architecture of the embedded equipment.

Description

Technical Field

[0001] This invention relates to the field of embedded system security technology, and in particular to a secure boot optimization method, apparatus, system, chip, and storage medium for terminal systems. Background Technology

[0002] In the existing security architecture of mobile terminal devices, device manufacturers generally deploy secure boot mechanisms to ensure system integrity. This mechanism is based on a hardware root of trust and establishes a hierarchical digital signature verification chain from the bootloader to the operating system by embedding the secure boot root public key digest in a one-time programmable memory. This ensures that the device can only run system images authorized and signed by the OEM (Original Equipment Manufacturer). To meet the needs of developers for debugging and customizing systems, OEMs also provide device unlocking functions, allowing users to flash third-party system images after unlocking the bootloader, such as flashing a device from Company A with a system from Company B.

[0003] However, current secure boot solutions have significant technical flaws. When the operating system's boot root private key is leaked due to internal disclosure, key management vulnerabilities, or supply chain attacks, attackers can use the leaked private key to forge a malicious system image with a legitimate signature. Because the verification public key digest is permanently stored in OTP (One-Time Programmable) memory and cannot be physically updated, even if the device is in a bootloader locked state, the malicious image can still pass the complete verification chain, causing the device to run a tampered system without the user's knowledge. This vulnerability will lead to a series of security problems such as the theft of sensitive user data, leakage of payment credentials, leakage of privacy information, and loss of device control. Existing solutions based on OTP static storage cannot dynamically update the trust anchor after the private key is leaked, creating a permanent security threat.

[0004] Therefore, there is an urgent need for an enhanced mechanism that can securely revoke and update leaked root keys on unlocked devices without relying on physical recall devices.

[0005] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0006] The main objective of this invention is to provide a secure boot optimization method, apparatus, system, chip, and storage medium for a terminal system, aiming to solve the problem of significant technical defects in existing secure boot schemes.

[0007] To achieve the aforementioned objective, the first aspect of the present invention provides a secure boot optimization method for a terminal system, applied to the development end, the secure boot optimization method for the terminal system comprising: When the initial boot root private key of the device is detected to be leaked, a new target boot root key is created, which includes a target boot root private key and a target boot root public key. Obtain the backup boot root public key version number on the device side, and create a target boot root public key version number based on the backup boot root public key version number, wherein the target boot root public key version number is greater than the backup boot root public key version number; Obtain the secure boot root private key of the device, and sign the target boot root public key based on the secure boot root private key to obtain the target boot root public key signature; The target public key triplet is sent to the device via a secure channel. The target public key triplet consists of the target boot root public key, the target boot root public key version number, and the target boot root public key signature.

[0008] In one implementation, before detecting the initial root private key leakage on the device side, the method further includes: Construct a secure boot root public key and a secure boot root private key, and write the hash value of the secure boot root public key into the OTP area of ​​the device to obtain a secure root public key digest, which serves as the secure boot trust root of the device. Construct an initial startup root public key and the initial startup root private key, and obtain an initial public key triplet based on the initial startup root public key. The initial public key triplet includes the initial startup root public key version number, the initial startup root public key, and the initial startup root public key signature. The version number of the initial boot root public key and the hash value of the initial boot root public key are written into the OTP area of ​​the device to obtain the initial root public key digest, which serves as the verifiable boot trust root of the device.

[0009] In one implementation, before detecting the initial root private key leakage on the device side, the method further includes: The SBL firmware content on the device is signed based on the secure boot root private key to obtain the SBL signature, thereby ensuring the integrity and source credibility of the SBL firmware on the device.

[0010] In one implementation, before detecting the initial root private key leakage on the device side, the method further includes: The root partition image content of the device is constructed based on the initial boot root public key version number and the initial boot root public key. The root partition image content includes the root partition initial boot root public key version number and the root partition initial boot root public key. The root partition image content is signed and written to the root partition image based on the initial boot root private key to obtain the initial root partition signature, and the initial boot root public key is written to the root partition image.

[0011] In one implementation, after creating the new target startup root key, the method further includes: The target boot root private key is used to sign the root partition image on the device and write it into the root partition image to obtain the target root partition signature. The target boot root public key is then written into the root partition image.

[0012] A second aspect of the present invention provides a secure boot optimization method for a terminal system, applied to a device, the secure boot optimization method for the terminal system comprising: Receive a target public key triplet sent by the development end. The target public key triplet includes the target startup root public key, the target startup root public key version number, and the target startup root public key signature. Extract the initial backup public key triplet from the target storage location. Verify the target public key triplet based on the initial backup public key triplet. If the verification is successful, overwrite the target public key triplet in the target storage location to obtain the target backup public key triplet. The target backup public key triplet includes the target backup startup root public key version number, the target backup startup root public key, and the target backup startup root public key signature. The current system is started based on the updated backup public key triplet.

[0013] In one implementation, before verifying the target public key triplet, the method further includes: The target storage location is constructed in a secure storage area, and the target storage location is used to store backup public key triplets; Obtain an initial public key triplet, which includes an initial startup root public key version number, an initial startup root public key, and an initial startup root public key signature. Store the initial public key triplet as an initial backup public key triplet in the target storage location to obtain the initial backup public key triplet, which includes an initial backup startup root public key version number, an initial backup startup root public key, and an initial backup startup root public key signature.

[0014] In one implementation, the target public key triplet is received via a secure channel.

[0015] In one implementation, the target public key triplet is verified based on the initial backup public key triplet to obtain the target backup public key triplet, including: The target startup root public key version number is compared with the initial backup startup root public key version number. If the target startup root public key version number is less than or equal to the initial backup startup root public key version number, the verification fails and writing to the target public key triplet is prohibited. If the target startup root public key version number is greater than the initial backup startup root public key version number, then the target startup root public key signature is verified based on the secure startup root public key. If the verification fails, writing to the target public key triplet is prohibited. If the verification is successful, the target public key triplet is written as a new backup public key triplet to the target storage location to obtain the target backup public key triplet.

[0016] In one implementation, starting the current system based on the updated backup boot root public key includes: During system startup, if the local device is detected to be in an unlocked state, the updated backup public key triplet is retrieved from the target storage location; Obtain the initial root public key digest from the OTP area storage, wherein the initial root public key digest is the version number of the initial startup root public key and the hash value of the initial startup root public key; Obtain root partition data, which includes the content of the first root partition image, the first root partition signature, and the first root partition boot public key stored in the first root partition image. The content of the first root partition image includes the version number of the first root partition boot public key and the first root partition boot public key. Based on the comparison results of the initial root public key digest, the root partition data, and the target backup public key triplet, if the comparison result is the first comparison result, the system will proceed to the next startup stage normally; if the comparison result is the second comparison result, a target prompt box will pop up, and the system will proceed to the next startup stage based on the feedback signal; if the comparison result is the third comparison result, the system startup will be prohibited.

[0017] In one implementation, the comparison result is output based on the initial root public key digest, the root partition data, and the target backup public key triplet, including: Obtain the first hash value, which is the hash value of the version number of the first root partition boot root public key and the hash value of the first root partition boot root public key; If the initial root public key digest is equal to the first hash value and the first root partition startup root public key is equal to the target backup startup root public key, then the output is the first comparison result.

[0018] In one implementation, based on the comparison result output by the initial root public key digest, the root partition data, and the target backup public key triplet, the method further includes: If the initial root public key digest is not equal to the first hash value, but the first root partition startup root public key is equal to the target backup startup root public key, then the signature of the target backup startup root public key is verified based on the secure startup root public key. If the verification is successful, the first comparison result is output; if the verification fails, the third comparison result is output.

[0019] In one implementation, based on the comparison result output by the initial root public key digest, the root partition data, and the target backup public key triplet, the method further includes: If the initial root public key digest is equal to the first hash value, but the first root partition startup root public key is not equal to the target backup startup root public key, then the signature of the target backup startup root public key is verified based on the secure startup root public key. If the verification is successful, the second comparison result is output; if the verification fails, the third comparison result is output.

[0020] In one implementation, the target prompt box is used to indicate that the current device is using an expired signature key and suggests upgrading; The feedback signal is the signal to continue to the next stage.

[0021] In one implementation, after the target prompt box pops up, the method further includes: Receive a first signal, which is a signal indicating agreement to upgrade; The current device is upgraded based on the official root partition image. The official root partition image includes the target boot root public key and the target root partition signature. The target root partition signature is a signature made by the development end based on the target boot root private key and the official root partition image. The target boot root private key and the target boot root public key are a key pair.

[0022] A third aspect of the present invention provides a secure boot optimization device for a terminal system, comprising: The key creation module is used to create a new target boot root key when the initial boot root private key on the device is detected to be leaked. The target boot root key includes a target boot root private key and a target boot root public key. The version number creation module is used to obtain the backup boot root public key version number of the device, and create a target boot root public key version number based on the backup boot root public key version number, wherein the target boot root public key version number is greater than the backup boot root public key version number; The signature module is used to obtain the secure boot root private key of the device, and sign the target boot root public key based on the secure boot root private key to obtain the target boot root public key signature. The key sending module is used to send a target public key triplet to the device via a secure channel. The target public key triplet consists of the target startup root public key, the target startup root public key version number, and the target startup root public key signature.

[0023] A fourth aspect of the present invention provides a secure boot optimization device for a terminal system, comprising: The key receiving module is used to receive a target public key triplet sent by the development end. The target public key triplet includes the target startup root public key, the target startup root public key version number, and the target startup root public key signature. The key update module is used to extract the initial backup public key triplet from the target storage location, verify the target public key triplet based on the initial backup public key triplet, and if the verification is successful, overwrite the target public key triplet on the target storage location to obtain the updated target backup public key triplet. The target backup public key triplet includes the target backup startup root public key version number, the target backup startup root public key, and the target backup startup root public key signature. The startup module is used to start the current system based on the updated backup public key triplet.

[0024] In a fifth aspect, the present invention provides a secure boot optimization system for a terminal system, the secure boot optimization system for a terminal system comprising a development end and a device end; the development end is used to implement the steps of any of the above-described secure boot optimization methods for a terminal system applied to the development end; the device end is used to implement the steps of any of the above-described secure boot optimization methods for a terminal system applied to the device end.

[0025] In a sixth aspect, the present invention provides a chip comprising: a memory, a processor, and a secure boot optimization program for a terminal system stored in the memory and executable on the processor, wherein the secure boot optimization program for the terminal system, when executed by the processor, implements the steps of the secure boot optimization method for a terminal system as described above.

[0026] A seventh aspect of the present invention provides a computer-readable storage medium, wherein the computer storage medium stores one or more programs that can be executed by one or more processors to implement the steps of the secure boot optimization method for the terminal system described in any of the preceding claims.

[0027] Beneficial Effects: Compared with existing technologies, this invention provides a secure boot optimization method, apparatus, system, chip, and storage medium for terminal systems. In the secure boot optimization method for terminal systems provided by this invention, when applied to the development end, when the development end detects the leakage of the initial boot root private key of the device, a new target boot root key is created. The target boot root key includes a target boot root private key and a target boot root public key. A backup boot root public key version number of the device is obtained. A target boot root public key version number is created based on the backup boot root public key version number, where the target boot root public key version number is greater than the backup boot root public key version number. Then, the secure boot root private key of the device is obtained. The target boot root public key is signed based on the secure boot root private key to obtain a target boot root public key signature. Finally, the target public key triplet is sent to the device via a secure channel. The target public key triplet consists of the target boot root public key, the target boot root public key version number, and the target boot root public key signature. This invention provides users with a secure boot optimization method for terminal systems, solving the problem of significant technical defects in existing secure boot schemes. By creating a new target boot root key and signing it with a public key when the initial boot root private key on the device is detected to be leaked, it is possible to automatically detect and reject the leaked old key at boot time for all locked devices without recalling the massive number of sold devices or replacing any hardware, simply through a security software update. This effectively addresses the urgent and real threat of key leakage and provides a new paradigm with important reference value for the future development of secure boot architecture for embedded devices. Attached Figure Description

[0028] Figure 1 This is a flowchart of an embodiment of the secure boot optimization method for a terminal system provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the initial root private key before leakage in an embodiment of the secure boot optimization method for a terminal system provided in Embodiment 1 of the present invention; Figure 3 This is a timeline diagram of the security boot key update and verification in an embodiment of the security boot optimization method for a terminal system provided in Embodiment 1 of the present invention. Figure 4 This is a flowchart of an embodiment of the secure boot optimization method for a terminal system in Embodiment 2 of the present invention; Figure 5 This is a flowchart illustrating the pre-verification public key preparation process for an embodiment of the secure boot optimization method for a terminal system in Embodiment 2 of the present invention. Figure 6 This is a flowchart illustrating the verification of an embodiment of the secure boot optimization method for a terminal system in Embodiment 2 of the present invention. Figure 7This is a flowchart illustrating the startup process of an embodiment of the secure startup optimization method for a terminal system in Embodiment 2 of the present invention. Figure 8 This is a flowchart comparing embodiments of the secure boot optimization method for the terminal system in Embodiment 2 of the present invention. Figure 9 This is a schematic diagram of the structural principle of an embodiment of the secure startup optimization device for a terminal system in Embodiment 3 of the present invention; Figure 10 This is a schematic diagram of the structural principle of an embodiment of the secure boot optimization device for a terminal system in Embodiment 4 of the present invention; Figure 11 This is a structural schematic diagram of an embodiment of the secure boot optimization system for a terminal system in Embodiment 5 of the present invention. Figure 12 This is a schematic diagram of the operating environment of the chip in Embodiment Six of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0030] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0031] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0032] The present invention provides a secure boot optimization method for a terminal system, which can be applied to terminals with computing capabilities. The terminal can execute the secure boot optimization method for a terminal system provided by the present invention to manage and control edge sub-devices.

[0033] First, the terms used in the embodiments of this invention will be introduced: OEM, terminal equipment manufacturers, such as existing mobile phone platform terminal manufacturers; Device, such as a computer running the HarmonyOS system or a mobile phone running the Android system; SoC, chip; TEEOS, security subsystems, such as OP-TEE, trusted execution environment; REEOS, operating systems such as Android and HarmonyOS; OTP, One-Time Programmable, is a secure memory area on a SoC chip that allows data to be securely burned in using the SoC manufacturer's tools. Once the data is securely burned in, it cannot be changed or erased. RPMB, Replay Protected Memory Block, is a secure storage area on the phone's memory (EMMC, embedded MultiMediaCard). It can be safely read and written in the TEEOS environment. Once data is safely written, it can be modified or deleted again. PBL (Primary Boot Loader, also known as bootRom) boots from storage media and guides the operating system to start. Secure Boot: During startup, the bootloader firmware checks the signature of each startup software segment. If the signature is valid, the computer will start, and the firmware will transfer control to the operating system. Verified Boot enables verified booting, such as Android AVB and HarmonyOS HVB, and is responsible for securely loading the terminal system image. S_PrivKey, the SBL secure boot root private key, is used for Secure Boot. It is used to sign the firmware of the next-level bootloader (such as SBL) after PBL. S_PubKey is the SBL secure boot root public key, used for Secure Boot. The corresponding private key is S_PrivKey. ReeOS-RootImage is the root partition image of the REEOS system, such as the VBMETA partition image of Android and the RVT partition image of HarmonyOS. O_PrivKey, the private key for REEOS system boot, used for Verified Boot and for signing the ReeOS-RootImage; O_PubKey is the root public key for REEOS system boot, used for Verified Boot. The corresponding private key is O_PrivKey. Product_ID, Product Model ID; ReeOS-RootImage-O_PubKey, the O_PubKey stored in ReeOS-RootImage.

[0034] This invention belongs to the field of embedded system security technology and is applicable to computing devices that require secure boot mechanisms, such as mobile terminals and IoT devices.

[0035] In the existing security architecture of mobile terminal devices, device manufacturers generally deploy secure boot mechanisms to ensure system integrity. This mechanism is based on a hardware root of trust and establishes a hierarchical digital signature verification chain from the bootloader to the operating system by embedding the secure boot root public key digest in a one-time programmable memory. This ensures that the device can only run system images authorized and signed by the OEM. To meet the needs of developers for debugging and customizing systems, OEMs also provide device unlocking functionality, allowing users to flash third-party system images after unlocking the bootloader, such as flashing Xiaomi's MIUI system onto a vivo device.

[0036] However, current secure boot solutions have significant technical flaws. When the operating system's boot root private key is leaked due to internal disclosure, key management vulnerabilities, or supply chain attacks, attackers can use the leaked private key to forge a malicious system image with a legitimate signature. Because the verification public key digest is permanently stored in the OTP storage and cannot be physically updated, even if the device is in a bootloader locked state, the malicious image can still pass the complete verification chain, causing the device to run a tampered system without the user's knowledge. This vulnerability will lead to a series of security problems such as the theft of sensitive user data, leakage of payment credentials, leakage of privacy information, and loss of device control. Existing solutions based on OTP static storage cannot dynamically update the trust anchor after the private key is leaked, creating a permanent security threat.

[0037] Especially considering the long lifespan of mobile devices (lasting several years) and the continuous evolution of cryptographic attack methods, static key schemes are ill-equipped to address long-term security challenges. Furthermore, the fact that most ordinary user devices remain locked means that the impact of key leakage risks is widespread. Current technical solutions suffer from a fundamental contradiction between key updability and the security of the hardware root of trust. There is an urgent need for an enhanced mechanism that can securely revoke and update leaked root keys on unlocked devices without relying on physical device recall. This would maintain the immutability of the hardware root of trust while supporting secure revocation and updating after key leakage.

[0038] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0039] Example 1 In this embodiment, a secure boot optimization method for a terminal system is provided. This secure boot optimization method for a terminal system is applied to the development end. In this embodiment, a mobile device developer is used as an example for illustration.

[0040] Specifically, Figure 1 This is a flowchart illustrating a secure boot optimization method for a terminal system provided in this embodiment.

[0041] like Figure 1 As shown, the secure boot optimization method for a terminal system provided in this embodiment is applied to the development end. The secure boot optimization method for a terminal system includes the following steps: S110. When the initial boot root private key of the device is detected to be leaked, a new target boot root key is created, the target boot root key including the target boot root private key and the target boot root public key.

[0042] Specifically, in this embodiment, it is mainly applied to the development side of mobile devices. In order for the device to start up safely, a series of steps are required during factory production to write a series of data that enables the device to start up safely.

[0043] Reference Figure 2 Before detecting the initial root private key leakage on the device side, the process also includes: S101. Construct a secure boot root public key and a secure boot root private key, and write the hash value of the secure boot root public key into the OTP area of ​​the device to obtain a secure root public key digest, which serves as the secure boot trust root of the device. S102. Construct the initial startup root public key and the initial startup root private key, and obtain the initial public key triplet based on the initial startup root public key. The initial public key triplet includes the initial startup root public key version number, the initial startup root public key and the initial startup root public key signature. S103. Write the version number of the initial boot root public key and the hash value of the initial boot root public key into the OTP area of ​​the device to obtain the initial root public key digest, which serves as the verifiable boot trust root of the device.

[0044] Before detecting the initial root private key leakage on the device, the process also includes: S104. Sign the SBL firmware content on the device side based on the secure boot root private key to ensure the integrity and source trustworthiness of the SBL firmware on the device side.

[0045] Before detecting the initial root private key leakage on the device, the process also includes: S105. Construct the root partition image content of the device based on the initial boot root public key version number and the initial boot root public key, wherein the root partition image content includes the root partition initial boot root public key version number and the root partition initial boot root public key; S106. Sign the content of the root partition image based on the initial boot root private key and write it into the root partition image to obtain the initial root partition signature, and write the initial boot root public key into the root partition image.

[0046] Specifically, refer to Figure 3 , Figure 3 To illustrate the timeline for secure boot key updates and verification, during the factory production phase, in step S101, the equipment manufacturer (OEM), i.e., the development end, first constructs the secure boot root public key S_PubKey and the secure boot root private key S_PrivKey. Then, it writes the hash digest of the secure boot root public key S_PubKey into the OTP (One-Time Programmable Memory) on the device, obtaining the secure root public key digest S_PubKey_Dgst, which serves as the root of trust for secure boot on the device. Here, the digest / hash is a fixed-length digest of the public key calculated using a cryptographic hash function (such as SHA-256). Specifically, S_PubKey_Dgst = Hash(S_PubKey), where Hash is the hash algorithm. In this embodiment, the hash algorithm can be flexibly chosen, for example, the internationally recognized SHA256.

[0047] Then, in step S102, the device manufacturer (OEM) constructs the initial boot root public key O_PubKey and the initial boot root private key O_PrivKey, and obtains the initial public key triple based on the initial boot root public key. The initial public key triple includes the initial boot root public key version number O_PubKey_Version, the initial boot root public key O_PubKey, and the initial boot root public key signature O_PubKey_Signature.

[0048] In step S103, the verification startup public key, i.e., the digest of O_PubKey, is written to the OTP in one go to obtain the initial root public key digest O_PubKey_Dgst, which serves as the root of trust for verification startup. The initial root public key digest O_PubKey_Dgst = Hash(O_PubKey_Version||O_PubKey), where O_PubKey_Version is the version information of O_PubKey. In many embodiments, the parameters for calculating O_PubKey_Dgst can be flexibly selected. In addition to the default O_PubKey_Version||O_PubKey, OEMs can also add fixed parameters such as Product_ID (device model) according to actual needs.

[0049] In step S104, the OEM signs the secondary bootloader (SBL) firmware content on the device based on the secure boot root private key S_PrivKey, obtaining the SBL signature SBL_Signature to ensure the integrity and source trustworthiness of the SBL firmware on the device. Specifically, SBL_Signature = Signature_Sign(S_PrivKey, SBL_Content); SBL_Image = {S_PubKey, SBL_Content, SBL_Signature}.

[0050] In step S105, the root partition image content ReeOS-Root_Content of the device is constructed based on the initial boot root public key version number O_PubKey_Version and the initial boot root public key O_PubKey. The root partition image content includes the root partition initial boot root public key version number ReeOS-RootImage-O_PubKey_Version and the root partition initial boot root public key ReeOS-RootImage-O_PubKey.

[0051] In step S106, the ReeOS-Root_Content content of the root partition image is signed based on the initial boot root private key O_PrivKey and written into the root partition image to obtain the initial root partition signature ReeOS-Root_Signature=Sign(O_PrivKey, ReeOS-Root_Content).

[0052] Then, the initial boot root public key O_PubKey is written to the root partition image ReeOS-RootImage. At this point, the root partition image ReeOS-RootImage = {O_PubKey, ReeOS-Root_Content, ReeOS-Root_Signature}.

[0053] After a series of steps, if the initial boot root private key on the device is detected to be leaked, a new target boot root key is created. The target boot root key includes the target boot root private key New_O_PrivKey and the target boot root public key New_O_PubKey.

[0054] Refer again Figure 1 In this embodiment, the secure boot optimization method for the terminal system further includes the following steps: S120. Obtain the backup boot root public key version number of the device, and create a target boot root public key version number based on the backup boot root public key version number, wherein the target boot root public key version number is greater than the backup boot root public key version number.

[0055] Specifically, in this step, the OEM sets a new public key version number, referred to in this embodiment as the target boot root public key version number New_O_PubKey_Version. This target boot root public key version number must be greater than the backup boot root public key version number on the device. This is done for two reasons: first, to ensure the version number monotonically increases, preventing rollback attacks; and second, to ensure the new key is later than the old key. Furthermore, the new public key version number is typically set using incrementing by 1 or a timestamp method.

[0056] S130. Obtain the secure boot root private key of the device, and sign the target boot root public key based on the secure boot root private key to obtain the target boot root public key signature.

[0057] Specifically, in this step, the OEM uses the secure boot root private key S_PrivKey_ to sign the target boot root public key New_O_PubKey, obtaining the target boot root public key signature New_O_PubKey_Signature. Wherein, New_O_PubKey_Signature = Signature_Sign(S_PrivKey, New_O_PubKey_Version||New_O_PubKey).

[0058] S140. The target public key triplet is sent to the device via a secure channel. The target public key triplet consists of the target boot root public key, the target boot root public key version number, and the target boot root public key signature.

[0059] Specifically, after obtaining the target boot root public key, the target boot root public key version number, and the target boot root public key signature, the target public key triplet is formed and sent to the device via a secure channel.

[0060] Furthermore, in this embodiment, after creating the new target startup root key, the method further includes: S150. Sign the root partition image on the device based on the target boot root private key and write it into the root partition image to obtain the target root partition signature and write the target boot root public key into the root partition image.

[0061] Specifically, in this step, the OEM uses the target boot root private key New_O_PrivKey to sign the REEOS root partition image ReeOS-RootImage, which contains the old and new public keys and the signature.

[0062] Specifically, the OEM uses the target boot root private key New_O_PrivKey to sign the root partition image, such as the VBMETA partition for Android or the RVT partition for HarmonyOS. The ReeOS-RootImage image contains the initial boot root public key O_PubKey and its corresponding initial root partition signature ReeOS-Root_Signature, and the target boot root public key New_O_PubKey and its corresponding target root partition signature new_ReeOS-Root_Signature=Sign(New_O_PrivKey, ReeOS-Root_Content). Then, the target boot root public key New_O_PubKey is written into the root partition image ReeOS-RootImage.

[0063] At this point, the root partition image ReeOS-RootImage = {O_PubKey, New_O_PubKey, ReeOS-Root_Content, ReeOS-Root_Signature, new_ReeOS-Root_Signature}. This root partition image is the official root partition image.

[0064] In this way, without altering the physical characteristics of the hardware security chip (OTP), the software-level "revocable and updatable" capabilities are cleverly applied to its fixed "permanent root of trust." This is equivalent to giving an unmodifiable hardware lock a smart key that can be replaced at any time.

[0065] Specifically, the development team does not need to recall the massive number of devices already sold, nor does it need to replace any hardware. Simply through a security software update, all locked devices can automatically detect and reject the leaked old keys upon startup, instead trusting the newly issued and unleashed security keys from the development team. The entire process is transparent to the user, and the intermediate state of "allowing the old system to boot but prompting for an upgrade" perfectly avoids the risk of devices becoming bricked due to forced upgrades, ensuring the continuity and stability of the user's system.

[0066] Meanwhile, the verification path for the old keys is retained on the device side, eliminating the need for the development team to re-sign all historical versions of the system image, significantly reducing maintenance costs and storage overhead. This design allows the development team to manage and respond to potential key leakage incidents at extremely low marginal costs, achieving a dual improvement in security protection capabilities and business operational efficiency.

[0067] In summary, this embodiment provides a secure boot optimization method for a terminal system, applied to the development end. When the development end detects that the initial boot root private key of the device is leaked, a new target boot root key is created. The target boot root key includes a target boot root private key and a target boot root public key. The version number of the backup boot root public key of the device is obtained, and a target boot root public key version number is created based on the backup boot root public key version number. The target boot root public key version number is greater than the backup boot root public key version number. Then, the secure boot root private key of the device is obtained, and the target boot root public key is signed based on the secure boot root private key to obtain the target boot root public key signature. Finally, the target public key triplet, composed of the target boot root public key, the target boot root public key version number, and the target boot root public key signature, is sent to the device via a secure channel. This embodiment provides users with a secure boot optimization method for a terminal system, solving the problem of significant technical defects in existing secure boot schemes. By creating a new target boot root key and signing it with a public key when the initial boot root private key on the device is detected to be leaked, it is possible to automatically detect and reject the leaked old key at boot time for all locked devices without recalling the massive number of sold devices or replacing any hardware, simply through a security software update. This effectively addresses the urgent and real threat of key leakage and provides a new paradigm with important reference value for the future development of secure boot architecture for embedded devices.

[0068] Example 2 In this embodiment, a secure boot optimization method for a terminal system is provided. The secure boot optimization method for a terminal system provided in this embodiment is applied to the device side. In this embodiment, a mobile device is used as an example for explanation.

[0069] Specifically, Figure 4 This is a flowchart illustrating a secure boot optimization method for a terminal system provided in this embodiment.

[0070] like Figure 4 As shown, the secure boot optimization method for a terminal system provided in this embodiment is applied to the device side. The secure boot optimization method for a terminal system includes the following steps: S210. Receive the target public key triplet sent by the development end. The target public key triplet includes the target startup root public key, the target startup root public key version number, and the target startup root public key signature.

[0071] The target public key triplet is received via a secure channel.

[0072] Specifically, the OEM requests, through a secure channel, to securely write the target public key triple {New_O_PubKey_Version, New_O_PubKey, New_O_PubKey_Signature} to the device, which is used to update the O_PubKey information when SecureBoot is not unlocked.

[0073] The device receives the target public key triplet sent by the development end. The target public key triplet includes the target boot root public key New_O_PubKey, the target boot root public key version number New_O_PubKey_Version, and the target boot root public key signature New_O_PubKey_Signature.

[0074] In existing boot methods, the main process of secure boot is PBL → SBL → {TEEOS, U-boot} → REEOS root partition → other REEOS partitions. Specifically, the boot process starts from the Master Boot Record (PBL) to the Secondary Boot Record (SBL), then loads TEEOS and U-boot, and finally loads the REEOS root partition and other partitions.

[0075] Specifically, in the existing boot method, when the terminal device boots, the first step is: PBL reads the security root public key digest S_PubKey_Dgst from OTP, calculates the hash of the security boot root public key S_PubKey stored in the SBL firmware, and compares whether the two are equal. If they are not equal, booting SBL is prohibited and the process ends; otherwise, it continues.

[0076] Step 2: PBL uses S_PubKey to verify the digital signature of the SBL firmware. Specifically, PBL uses the secure boot root public key S_PubKey to verify the SBL firmware signature. If the verification fails, SBL startup is prohibited, and the process ends. Here, SBL_Verify_Result = Signature_Verify(S_PubKey, SBL_Content, SBL_Signature). In this embodiment, the digital signature algorithm (Sign, Verify) can be flexibly selected, for example, using the internationally recognized ECDSA (ECDSA_Sign, ECDSA_Verify).

[0077] After successful verification, proceed to the third step: PBL loads and executes SBL. That is, PBL securely transfers control to SBL.

[0078] Then, SBL reads the public key hashes of TEEOS and U-Boot from SBL_Content and performs a similar verification process on them.

[0079] Specifically, in the fourth step: SBL reads the public key hash (e.g., TEEOS_PubKey_Hash) of the next-level TEEOS firmware from SBL_Content, which is the SBL content, performs a similar signature public key check and signature firmware verification process on the TEEOS firmware, and securely loads and runs TEEOS.

[0080] Step 5: SBL reads the public key hash of the next-level U-Boot firmware (e.g., U-Boot_PubKey_Hash) from SBL_Content, performs a similar signature public key check and signature firmware verification process on the U-Boot firmware, and securely loads and runs U-Boot.

[0081] At this point, the boot process based on U-Boot begins. In existing technologies, this would be step six: U-Boot reads the public key ReeOS-RootImage-O_PubKey and the version number ReeOS-RootImage-O_PubKey_Version from the REEOS root partition image ReeOS-RootImage.

[0082] In step seven: U-Boot reads the device's unlock status, device_unlock_flag, from RPMB via TEEOS. If device_unlock_flag is true, it means the device has been unlocked, and we can proceed directly to the next stage, which is the stage of verifying the ReeOS-Root_Signature signature using ReeOS-RootImage-O_PubKey.

[0083] Then, we proceed to the crucial eighth step: if `device_unlock_flag` is false, it indicates the device is not unlocked. At this point, U-Boot reads the initial root public key digest `O_PubKey_Dgst` from the OTP. U-Boot checks if the following equation is true: if they are not equal, the boot screen indicates a device image mismatch, and REEOS booting is prohibited, ending the process; if they are equal, meaning `O_PubKey_Dgst = Hash(=ReeOS-RootImage-O_PubKey_Version||ReeOS-RootImage-O_PubKey)`, the boot screen shows the device booted normally. Afterwards, the next stage, which involves verifying the `ReeOS-Root_Signature` signature using `ReeOS-RootImage-O_PubKey`, continues.

[0084] In this embodiment, the main improvement is to step eight to enhance secure boot protection in scenarios where O_PrivKey is leaked. This is because, in existing technologies, if O_PrivKey is leaked, even if the user does not unlock the device, hackers can still use O_PrivKey to sign malicious REEOS image packages and trick users into flashing them. Since O_PubKey_Dgst remains unchanged, malicious systems can still boot normally, leading to risks to user data security and privacy leaks.

[0085] In existing technology, after the above stages, we arrive at step nine: U-Boot verifies the ReeOS-Root_Signature signature using ReeOS-RootImage-O_PubKey. In this stage, U-Boot uses the public key in the image to verify the root partition signature. If the signature verification fails, REEOS startup is prohibited, and the process ends. If successful, meaning ReeOS-Root_Verify_Result = Signature_Verify(ReeOS-RootImage-O_PubKey, ReeOS-Root_Content, ReeOS-Root_Signature), then we proceed to step ten.

[0086] Step 10: U-Boot reads the public keys of the boot and system partitions from the root partition contents and verifies their partition signatures. Specifically, U-Boot reads the signing public key (e.g., boot_PubKey) of the smaller sub-partitions of the ReeOS-Root root partition from ReeOS-Root_Content and compares it with the signing public key in the boot image. If they are not equal, booting REEOS is prohibited, and the process ends.

[0087] Steps 11 through 13 involve U-Boot verifying the boot image signature using the boot_PubKey. If verification fails, booting REEOS is disabled, and the process ends. If verification succeeds (boot_Verify_Result = Signature_Verify(boot_PubKey, boot_content, boot_Signature)), then proceed to step 12: U-Boot reads the signing public key (e.g., system_PubKey) of the lower-level mass partition of the ReeOS-Root root partition from ReeOS-Root_Content and compares it with the signing public key in the system image. If they are not equal, booting REEOS is disabled, and the process ends.

[0088] In step thirteen: U-Boot uses system_PubKey to verify the system_root_Hash signature. If the verification fails, REEOS startup is disabled, and the process ends. If the verification succeeds, i.e., System_Verify_Result = Signature_Verify(boot_PubKey, system_root_Hash, boot_Signature), then proceed to the next step.

[0089] Step 14: U-Boot uses a similar method to verify the small and large partitions of REEOS. If the verification fails, booting is disabled.

[0090] If the verification is successful, proceed to step 15: Boot the REEOS Kernel partition using U-Boot.

[0091] Finally, in step sixteen: the kernel loads system content on demand. Each piece of system content undergoes a dm-verity hash comparison based on system_root_Hash. If the hashes do not match, loading the system content is prohibited.

[0092] Specifically, the main drawback of the existing solution is that the O_PubKey digest is directly burned into the OTP. The fundamental problem is that while the OTP is not updatable, the key can be leaked. This is because if the initial boot root public key O_PrivKey is leaked but the user hasn't unlocked it, a hacker could potentially use the leaked O_PrivKey to securely bypass the boot phase during system startup, allowing a malicious image to boot normally without the user's knowledge. Therefore, in this embodiment, the main improvement is made to the eighth step mentioned above, the stage where the device is not unlocked, to enhance secure boot protection in the scenario of O_PrivKey leakage.

[0093] Specifically, refer to Figure 5 Before verifying the target public key triplet, the process also includes: S201. Construct the target storage location in the secure storage area, the target storage location being used to store backup public key triplets; S202. Obtain the initial public key triplet, which includes the initial startup root public key version number, the initial startup root public key, and the initial startup root public key signature. Store the initial public key triplet as the initial backup public key triplet in the target storage location to obtain the initial backup public key triplet, which includes the initial backup startup root public key version number, the initial backup startup root public key, and the initial backup startup root public key signature.

[0094] Specifically, in this embodiment, a target storage location is reserved in the RPMB secure storage area on the device side for storing the backup public key triplet. The target backup public key triplet includes the storage locations of the backup boot root public key version number Latest_O_PubKey_Version, the backup boot root public key Latest_O_PubKey, and the backup boot root public key signature Latest_O_PubKey_Signature. During the initialization phase, the initial public key triplet is stored as the initial backup public key triplet in the target storage location, that is, Latest_O_PubKey_Version is initialized to O_PubKey_Version and written to the RPMB storage area. This provides RPMB updatable, replay-protected, and secure storage. The reserved location in the RPMB allows for advance planning and expansion capabilities.

[0095] Then, in step S220, an initial backup public key triplet is extracted from the target storage location. The target public key triplet is verified based on the initial backup public key triplet. If the verification is successful, the target public key triplet is overwritten in the target storage location to obtain the target backup public key triplet. The target backup public key triplet includes the target backup startup root public key version number, the target backup startup root public key, and the target backup startup root public key signature.

[0096] Reference Figure 6 The target public key triplet is obtained by verifying the target public key triplet based on the initial backup public key triplet, including: S221. Compare the target startup root public key version number with the initial backup startup root public key version number. If the target startup root public key version number is less than or equal to the initial backup startup root public key version number, the verification fails and writing to the target public key triplet is prohibited. S222. If the version number of the target startup root public key is greater than the version number of the initial backup startup root public key, then the signature of the target startup root public key is verified based on the secure startup root public key. If the verification fails, writing to the target public key triplet is prohibited. S223. If the verification is successful, the target public key triplet is written as a new backup public key triplet into the target storage location to obtain the target backup public key triplet.

[0097] Specifically, if the verification is successful, the target public key triplet is written as a new backup public key triplet into the target storage location to obtain the target backup public key triplet.

[0098] In step S221, U-Boot checks whether the new version number is greater than the current version number. Specifically, U-Boot reads the initial backup boot root public key version number Latest_O_PubKey_Version stored in the terminal device's RPMB. If the target boot root public key version number New_O_PubKey_Version is less than or equal to the initial backup boot root public key version number Latest_O_PubKey_Version, then it refuses to write to the target public key triplet and ends. If the target boot root public key version number New_O_PubKey_Version is greater than the initial backup boot root public key version number Latest_O_PubKey_Version, then U-Boot uses the secure boot root public key S_PubKey to verify the new public key signature. Specifically, U-Boot uses the secure boot root public key S_PubKey to verify the target boot root public key signature New_O_PubKey_Signature. If the verification fails, the write operation is rejected, and the process ends.

[0099] If the verification is successful, U-Boot writes the new key information into the RPMB. Specifically, if the target root public key verification result New_O_PubKey_verify_result = Signature_Verify(S_PubKey, New_O_PubKey_Version||New_O_PubKey, New_O_PubKey_Signature), then U-Boot writes the target public key triple {New_O_PubKey_Version, New_O_PubKey, New_O_PubKey_Signature} into the RPMB's {Latest_O_PubKey_Version, Latest_O_PubKey, Latest_O_PubKey_Signature} secure storage area, obtaining the target backup public key triple {New_O_PubKey_Version, New_O_PubKey, New_O_PubKey_Signature}, meaning the target backup public key triple is equal to the target public key triple.

[0100] Refer again Figure 4 In this embodiment, the following steps are also included: S230. Start the current system based on the updated backup public key triplet.

[0101] Reference Figure 7 The step of starting the current system based on the updated backup boot root public key includes: S231. During the system startup phase, if the local device is detected to be in an unlocked state, the updated backup public key triplet is retrieved from the target storage location.

[0102] Specifically, when the device boots up, U-Boot first checks the device unlock flag, device_unlock_flag, stored in the RPMB. If this flag is false, it indicates that the device is in a bootloader locked state, at which point the most stringent security verification process should be executed. In this state, U-Boot reads dynamic trust data, referred to as the backup public key triplet, from the secure storage area of ​​the RPMB. The backup public key triplet contains the target backup boot root public key version number Latest_O_PubKey_Version, which is issued by the OEM through a secure update mechanism and saved to the backup location; the target backup boot root public key Latest_O_PubKey; and the target backup boot root public key signature Latest_O_PubKey_Signature, which is signed with the secure boot root private key S_PrivKey. In this embodiment, {Latest_O_PubKey_Version, Latest_O_PubKey, Latest_O_PubKey_Signature} = {New_O_PubKey_Version, New_O_PubKey, New_O_PubKey_Signature}.

[0103] S232. Obtain the initial root public key digest of the OTP area storage, wherein the initial root public key digest is the version number of the initial startup root public key and the hash value of the initial startup root public key; S233. Obtain root partition data, wherein the root partition data includes the content of the first root partition image, the first partition signature, and the first partition boot root public key stored in the first root partition image, and the content of the first partition image includes the version number of the first partition boot root public key and the first partition boot root public key. S234. Based on the initial root public key digest, the root partition data, and the target backup public key triplet, output the comparison result. If it is the first comparison result, proceed to the next startup stage normally. If it is the second comparison result, after the target prompt box pops up, proceed to the next startup stage based on the feedback signal. If it is the third comparison result, prohibit the system from starting.

[0104] Specifically, the core of the secure startup verification process under the device lock state given in this embodiment lies in constructing a sophisticated three-level state judgment mechanism.

[0105] The system enters a critical comparison phase. U-Boot needs to comprehensively consider information from three core trust anchors: First, the initial root public key digest O_PubKey_Dgst, which is embedded in the OTP and serves as the foundation of hardware trust; second, the system root partition image to be booted, referred to in this embodiment as the first root partition image, which is the root partition image used by the user for booting. During the boot phase, the first root partition image needs to be verified to ensure that the user is using a legitimate image version. The first root partition image ReeOS-RootImage carries the first root partition boot root public key ReeOS-RootImage-O_PubKey and its corresponding first root partition boot root public key version number ReeOS-RootImage-O_PubKey_Version; and finally, the latest public key information just read from RPMB, namely the target backup boot root public key Latest_O_PubKey and its corresponding target backup boot root public key signature Latest_O_PubKey_Signature in the backup public key triplet. By cross-validating and logically comparing the information from these three parties, the system will arrive at a clear conclusion regarding the trust status and execute the corresponding operations.

[0106] In this embodiment, there are three comparison results. If the comparison result is the first comparison result Green, then the following is displayed: The startup interface shows that the device has started normally. After that, it proceeds to the ninth step in the aforementioned existing startup process. If the comparison result is the second comparison result Yellow, the target prompt box will pop up. The target prompt box is used to prompt the current device to use an expired signature key. Specifically, it can be displayed on the device screen: the startup interface prompts the device to use an expired signature key and recommends upgrading. The next step is based on the user feedback signal. If the feedback signal is a signal to continue to the next stage, then proceed to the ninth step in the existing startup process. If the comparison result is the third comparison result Red, it means that the startup interface prompts that the device image does not match. At this time, REEOS is prohibited from starting and the system's secure boot process is terminated.

[0107] Specifically, the comparison result based on the initial root public key digest, the root partition data, and the target backup public key triplet includes: Obtain the first hash value, which is the hash value of the version number of the first root partition boot root public key and the hash value of the first root partition boot root public key; If the initial root public key digest is equal to the first hash value and the first root partition startup root public key is equal to the target backup startup root public key, then the output is the first comparison result.

[0108] If the initial root public key digest is not equal to the first hash value, but the first root partition startup root public key is equal to the target backup startup root public key, then the signature of the target backup startup root public key is verified based on the secure startup root public key. If the verification is successful, the first comparison result is output; if the verification fails, the third comparison result is output.

[0109] If the initial root public key digest is equal to the first hash value, but the first root partition startup root public key is not equal to the target backup startup root public key, then the signature of the target backup startup root public key is verified based on the secure startup root public key. If the verification is successful, the second comparison result is output; if the verification fails, the third comparison result is output.

[0110] Specifically, refer to Figure 8 , Figure 8 This is a flowchart of the overall comparison process. The design of the entire comparison logic is meticulous and rigorous, aiming to cover various possible scenarios throughout the key lifecycle.

[0111] The system determines the first comparison result, i.e., the Green state, if and only if one of the following two conditions is met.

[0112] Specifically, the first scenario is the case where the traditional trust chain is completely intact and undisturbed: that is, the initial root public key digest is equal to the first hash value and the first root partition startup root public key is equal to the target backup startup root public key.

[0113] In other words, the hash value of the public key in the system image is completely consistent with the initial digest stored in the OTP, that is, the initial root public key digest O_PubKey_Dgst stored in the OTP is equal to Hash(the first root partition boot root public key version number ReeOS-RootImage-O_PubKey_Version||the first root partition boot root public key ReeOS-RootImage-O_PubKey), and the first root partition boot root public key ReeOS-RootImage-O_PubKey is equal to the target backup boot root public key Latest_O_PubKey. This proves that the image uses the original factory key. At the same time, the image public key is exactly the same as the latest public key stored in the RPMB, indicating that the device has neither suffered key leakage nor requires key updates. At this time, the device is in the best security state, and the boot interface will display a confirmation message of "Device booted normally" to the user. Then the process will proceed to the ninth step of the aforementioned boot process and continue the subsequent boot verification.

[0114] The second scenario, where the first comparison result is in the Green state, reflects that the system has successfully responded to the key leakage event and completed the security evolution. In this case, the hash value of the system image public key is no longer equal to the initial digest in the OTP, indicating that the old initial key digest has become invalid due to the key update. However, the public key used in the image perfectly matches the latest public key stored in the RPMB, and crucially, verifying the signature of the latest public key in the RPMB using the secure boot root public key S_PubKey is successful.

[0115] In other words, the initial root public key digest O_PubKey_Dgst is not equal to Hash(the first root partition boot root public key version number ReeOS-RootImage-O_PubKey_Version||the first root partition boot root public key ReeOS-RootImage-O_PubKey). However, the first root partition boot root public key ReeOS-RootImage-O_PubKey is equal to the target backup boot root public key Latest_O_PubKey. In this case, the signature of the target backup boot root public key needs to be verified based on the secure boot root public key. If the verification is successful, that is, Latest_O_PubKey_verify_result=Signature_Verify(S_PubKey, Latest_O_PubKey_Version||Latest_O_PubKey, Latest_O_PubKey_Signature), then the verification is successful, and the output is the first comparison result; otherwise, if the verification fails, the output is the third comparison result. Specifically, if the verification is successful, it means that the new public key in the RPMB is a legitimate update certified by the OEM at the highest security level. Meeting these conditions indicates that the device has proactively migrated to a new, undisclosed key system and is running a secure update system signed with the new key. Thus, even if the original O_PrivKey has been leaked, the device can still maintain secure boot through this path and display "Device booted normally" to the user.

[0116] When the system is in a transitional security state, it is considered the second comparison result, i.e., the Yellow state. This state requires four conditions to be met simultaneously: First, the hash value of the image public key still matches the OTP digest, proving that the current system itself is legitimate and signed by the original key; second, the public key in the image is different from the latest public key in the RPMB; third, the signature verification of the latest public key in the RPMB is successful, confirming that the OEM has issued a trusted new key; finally, the version number of the image public key must be less than the version number of the latest public key in the RPMB, conclusively indicating that an updated security key is available. That is, at this time, O_PubKey_Dgst equals Hash(ReeOS-RootImage-O_PubKey_Version||ReeOS-RootImage-O_PubKey), but ReeOS-RootImage-O_PubKey is not equal to Latest_O_PubKey. At this point, it is necessary to verify the signature of the target alternate boot root public key based on the secure boot root public key. If the verification is successful, that is, if Latest_O_PubKey_verify_result equals Signature_Verify(S_PubKey, Latest_O_PubKey_Version||Latest_O_PubKey, Latest_O_PubKey_Signature) and ReeOS-RootImage-O_PubKey_Version is less than Latest_O_PubKey_Version, then the output is the second comparison result. If the verification fails, the output is the third comparison result.

[0117] This state typically occurs during the window period when the OEM has issued a key update, but the user has not yet flashed the corresponding new system image. Although the current system version is temporarily secure, it poses a potential risk because the signing key it uses has expired. To balance security and device availability, the system is allowed to continue booting, but the boot screen must clearly prompt the user that "the device is using an expired signing key; an upgrade is recommended," guiding the user to complete the system update as soon as possible.

[0118] In this embodiment, all cases other than those described above are output as the third comparison result. That is, any situation that does not meet the explicit combination of conditions for the Green or Yellow states will be classified as the third comparison result, i.e., the Red state. This covers all possible anomalies or attack scenarios, such as the image using a completely unrelated third-party key, RPMB data being tampered with leading to signature verification failure, or logical inconsistencies in the version number. Once this state is entered, it means that an unacceptable break or contradiction has occurred in the trust chain. The system will immediately abort the startup process, prohibit the loading of REEOS, and display a "Device image mismatch" message on the startup screen, ensuring user data security in the most conservative way and preventing any potential malicious code execution opportunities.

[0119] This comprehensive three-level state determination mechanism constitutes the core innovation of this embodiment. It does not alter the immutable physical characteristic of OTP as a hardware root of trust. Instead, it cleverly solves the fatal flaw of traditional solutions—the inability to revoke a leaked private key—by introducing a securely updatable dynamic trust extension into the RPMB and designing rigorous software logic to cross-verify the relationship between static and dynamic trust anchors. From the user's perspective, the device boots smoothly in most cases, only providing clear warnings or blocking when necessary, achieving an effective balance between enhanced security and user experience.

[0120] Furthermore, after the target prompt box pops up, it also includes: Receive a first signal, which is a signal indicating agreement to upgrade; The current device is upgraded based on the official root partition image. The official root partition image includes the target boot root public key and the target root partition signature. The target root partition signature is a signature made by the development end based on the target boot root private key and the official root partition image. The target boot root private key and the target boot root public key are a key pair.

[0121] Specifically, in the aforementioned secure boot verification process, after the system determines that the second comparison result is in the Yellow state and displays a "Recommended Upgrade" prompt on the boot screen, the entire security enhancement solution also includes a complete user response and system repair path. This path allows users to knowingly and proactively upgrade their devices to a secure system using a new, undisclosed key.

[0122] Specifically, when a user sees the device prompt "Use expired signing key," the interface provides clear interactive options, such as "Confirm Startup" and "Upgrade Now." If the user chooses to upgrade, the device will receive a clear first signal—an authorization signal indicating the user's consent to perform the system upgrade operation. This signal is crucial; it ensures that any subsequent system modifications are based on the user's explicit knowledge and consent, complying with security and privacy protection design principles.

[0123] Upon receiving user authorization, the device will upgrade based on the official root partition image provided by the manufacturer, which contains a secure official key system. In this embodiment, the official root partition image refers to the complete system image re-signed by the device manufacturer (i.e., the development team) using a newly generated, undisclosed key pair after a key leakage incident. The official root partition image contains two core security components: one is the "target boot root public key," namely the aforementioned New_O_PubKey, which is a new public key that replaces the leaked old key; the other is the "target root partition signature," which is the signature data obtained by the development team (i.e., the device manufacturer) digitally signing the entire content of the official root partition image using the "target boot root private key" paired with the new public key. This new asymmetric key constitutes the trust foundation for future system verification.

[0124] The entire upgrade process itself must be under strict security protection. The device downloads the image from the official server via an encrypted secure channel and verifies its integrity and signature validity before writing it to storage. After the upgrade is complete, when the device restarts, the public key in its system image will be completely consistent with the latest public key Latest_O_PubKey stored in the RPMB, and the version number will match. At this time, the secure boot verification process will satisfy the second "Green state condition" mentioned above: although the old digest in the OTP does not match, the image uses the latest trusted public key endorsed by S_PrivKey. The device thus completely migrates out of the leaked old key system and restores to the highest security state of "normal device boot," forming a complete closed loop from risk detection, user alerts, and authorized security remediation. This design not only fixes the vulnerability caused by key leakage but also improves transparency and controllability through user participation in decision-making.

[0125] The core value of the secure boot optimization method for terminal systems provided in this embodiment lies in systematically solving the fundamental flaw of traditional secure boot architectures where the root key cannot be revoked after leakage. By introducing a clever dynamic trust management mechanism within the existing hardware security framework, a substantial leap in security capabilities is achieved without altering the physical characteristics of the OTP hardware trust root, while simultaneously striking a delicate balance between security, system stability, user experience, and engineering feasibility.

[0126] Furthermore, this embodiment achieves, for the first time, the ability to securely update the system boot root of trust while the device bootloader is in a normal operating state. This completely plugs the fatal vulnerability in the original solution where "once the private key is leaked, all locked devices are permanently exposed to risk." Even if an attacker obtains the original boot root private key and issues a malicious system image, the device can update the root of trust to the unleashed new public key through a security mechanism, preventing the malicious image from passing verification on the updated device, thereby fundamentally protecting user data and privacy.

[0127] Furthermore, unlike the traditional binary "black and white" logic of secure boot, this embodiment creatively designs a three-level trust state mechanism (Green / Yellow / Red). The Yellow state is particularly crucial, representing a manageable transitional state. When the system detects the use of an expired signing key, it doesn't abruptly refuse boot and brick the device. Instead, it allows continued operation while clearly prompting the user that "the device is using an expired signing key; an upgrade is recommended." This refined handling provides users and manufacturers with a valuable window for a secure transition and plays a vital role in user education through clear risk warnings, preventing users from being misled into flashing old malicious images again due to information asymmetry after the root of trust is updated.

[0128] Furthermore, in terms of technical architecture, the secure boot optimization method for the terminal system provided in this embodiment adopts an incremental evolution rather than a disruptive replacement approach—a smart design. By introducing a backup boot root public key, Latest_O_PubKey, as a new dynamic trust anchor, while retaining the validity of the initial boot root private key, O_PubKey, it perfectly balances the dual requirements of forward evolution and backward compatibility. This design avoids boot risks caused by asynchronous distribution of upgrade packages between old and new system images, while also supporting users to restore to the original factory system when needed, and saving manufacturers the huge maintenance costs of re-signing all historical images. Simultaneously, it cleverly utilizes the existing, higher-level hardware trust root, the secure boot root public key S_PubKey, to protect and verify the update process of dynamic trust data. Through the Latest_O_PubKey_Signature mechanism of the backup boot root public key, it ensures the security of the update operation itself while expanding functionality, without adding additional business complexity.

[0129] Moreover, the robustness of this embodiment is reflected in its continuous self-healing capability. Even if the dynamic trust information itself is leaked in extreme cases, the system can still respond by incrementing the version number and issuing an updated key, forming a sustainable evolutionary mechanism to combat threats. Its implementation also fully considers the principle of minimizing the impact on existing systems, requiring only modifications to the bootloader responsible for loading the operating system (such as U-Boot), without touching the underlying secure boot firmware, thus maximizing the overall stability of the system. Simultaneously, the design of including dual signatures of both old and new keys in the system image ensures the smoothness and legitimacy of upgrade paths between different versions.

[0130] In summary, this embodiment provides a secure boot optimization method for a terminal system, applied to the device side. The device side receives a target public key triplet sent by the development side. The target public key triplet includes a target boot root public key, a target boot root public key version number, and a target boot root public key signature. Then, an initial backup public key triplet is extracted from the target storage location. The target public key triplet is verified based on the initial backup public key triplet. If the verification is successful, the target public key triplet is overwritten in the target storage location to obtain a target backup public key triplet. The target backup public key triplet includes a target backup boot root public key version number, a target backup boot root public key, and a target backup boot root public key signature. Finally, the current system is booted based on the updated backup public key triplet. This embodiment provides users with a secure boot optimization method for a terminal system, solving the problem of significant technical defects in existing secure boot schemes. By dynamically updating the root of trust on locked devices, employing a risk-refined verification mechanism based on three-level states, a two-layer security architecture that protects dynamic updates through a high-level root of trust, an incremental trust evolution scheme, and a dual-signature image format that supports smooth upgrades, a complete, practical, and elegant security enhancement solution is formed. This solution not only effectively addresses the pressing threat of key leakage but also provides a new paradigm with significant reference value for the future development of secure boot architectures for embedded devices.

[0131] It should be understood that although the steps in the flowcharts shown in the accompanying drawings are displayed sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of the steps in this invention, and these steps can be executed in other orders. Moreover, at least a portion of the steps in this invention may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed 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 performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0132] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program using signal-related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM). ROM Programmable ROM ( PROM ), electrically programmable ROM ( EPROM Electrically erasable programmable ROM ( EEPROM ) or flash memory. Volatile memory may include random access memory (RAM) RAM Alternatively, an external cache memory. This is for illustrative purposes only and not as a limitation. RAM It can be obtained in various forms, such as static RAM ( SRAM ),dynamic RAM ( DRAM ),synchronous DRAM ( SDRAM ), double data rate SDRAM ( DDR SDRAM ), Enhanced SDRAM ( ESDRAM ), Synchronization Link ( Synchlink ), DRAM ( SLDRAM ), memory bus ( Rambus )direct RAM ( RDRAM ), Direct Memory Bus Dynamics RAM ( DRDRAM ), and memory bus dynamics RAM ( RDRAM )wait.

[0133] Example 3 Based on the above embodiments, the present invention also provides a secure boot optimization device for a terminal system, the functional module of which is shown in the figure below. Figure 9 As shown, the secure boot optimization device for this terminal system includes: The key creation module is used to create a new target boot root key when the initial boot root private key on the device is detected to be leaked. The target boot root key includes a target boot root private key and a target boot root public key, as described in Embodiment 1. The version number creation module is used to obtain the backup boot root public key version number of the device, and create a target boot root public key version number based on the backup boot root public key version number. The target boot root public key version number is greater than the backup boot root public key version number, as described in Embodiment 1. The signature module is used to obtain the secure boot root private key of the device, and sign the target boot root public key based on the secure boot root private key to obtain the target boot root public key signature, as described in Embodiment 1. The key sending module is used to send the target public key triplet to the device based on a secure channel. The target public key triplet consists of the target startup root public key, the target startup root public key version number, and the target startup root public key signature, as described in Embodiment 1.

[0134] Example 4 Based on the above embodiments, the present invention also provides a secure boot optimization device for a terminal system, the functional module of which is shown in the figure below. Figure 10 As shown, the secure boot optimization device for this terminal system includes: The key receiving module is used to receive a target public key triplet sent by the development end. The target public key triplet includes the target startup root public key, the target startup root public key version number, and the target startup root public key signature, as described in Embodiment 2. The key update module is used to extract the initial backup public key triplet from the target storage location, verify the target public key triplet based on the initial backup public key triplet, and if the verification is successful, overwrite the target public key triplet on the target storage location to obtain the updated target backup public key triplet. The target backup public key triplet includes the target backup startup root public key version number, the target backup startup root public key, and the target backup startup root public key signature, as described in Embodiment 2. The startup module is used to start the current system based on the updated backup public key triplet, as described in Embodiment 2.

[0135] Example 5 To achieve the above objectives, refer to Figure 11 The present invention also provides a secure boot optimization system for a terminal system, wherein the secure boot optimization system for a terminal system includes a development end and a device end; The development end is used to implement the steps of the secure boot optimization method for the terminal system as described in any of the above embodiments; The device is used to implement the steps of the secure boot optimization method for the terminal system as described in any of the above embodiments.

[0136] Example 6 Figure 12A schematic diagram of the structure of a chip provided in an embodiment of this application. The chip may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0137] When the processor 502 executes the program, it implements the secure boot optimization method for the terminal system provided in the above embodiments.

[0138] Furthermore, the chip also includes: Communication interface 503 is used for communication between memory 501 and processor 502.

[0139] The memory 501 is used to store computer programs that can run on the processor 502.

[0140] The memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage.

[0141] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EIS) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0142] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0143] Processor 502 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of this application.

[0144] Example 7 The present invention also provides a computer-readable storage medium having stored thereon one or more programs that can be executed by one or more processors to implement the steps of the secure boot optimization method for the terminal system described in the above embodiments.

[0145] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications 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.

Claims

1. A method for optimizing the secure boot process of a terminal system, characterized in that, Applied to the development side, the secure boot optimization method for the terminal system includes: When the initial boot root private key of the device is detected to be leaked, a new target boot root key is created, which includes a target boot root private key and a target boot root public key. Obtain the backup boot root public key version number on the device side, and create a target boot root public key version number based on the backup boot root public key version number, wherein the target boot root public key version number is greater than the backup boot root public key version number; Obtain the secure boot root private key of the device, and sign the target boot root public key based on the secure boot root private key to obtain the target boot root public key signature; The target public key triplet is sent to the device via a secure channel. The target public key triplet consists of the target boot root public key, the target boot root public key version number, and the target boot root public key signature.

2. The secure boot optimization method for a terminal system according to claim 1, characterized in that, Before detecting the initial root private key leakage on the device, the process also includes: Construct a secure boot root public key and a secure boot root private key, and write the hash value of the secure boot root public key into the OTP area of ​​the device to obtain a secure root public key digest, which serves as the secure boot trust root of the device. Construct an initial startup root public key and the initial startup root private key, and obtain an initial public key triplet based on the initial startup root public key. The initial public key triplet includes the initial startup root public key version number, the initial startup root public key, and the initial startup root public key signature. The version number of the initial boot root public key and the hash value of the initial boot root public key are written into the OTP area of ​​the device to obtain the initial root public key digest, which serves as the verifiable boot trust root of the device.

3. The secure boot optimization method for a terminal system according to claim 2, characterized in that, Before detecting the initial root private key leakage on the device, the process also includes: The SBL firmware content on the device is signed based on the secure boot root private key to obtain the SBL signature, thereby ensuring the integrity and source credibility of the SBL firmware on the device.

4. The secure boot optimization method for a terminal system according to claim 2, characterized in that, Before detecting the initial root private key leakage on the device, the process also includes: The root partition image content of the device is constructed based on the initial boot root public key version number and the initial boot root public key. The root partition image content includes the root partition initial boot root public key version number and the root partition initial boot root public key. The root partition image content is signed and written to the root partition image based on the initial boot root private key to obtain the initial root partition signature, and the initial boot root public key is written to the root partition image.

5. The secure boot optimization method for a terminal system according to claim 1, characterized in that, After creating the new target boot root key, the process also includes: The target boot root private key is used to sign the root partition image on the device and write it into the root partition image to obtain the target root partition signature. The target boot root public key is then written into the root partition image.

6. A method for optimizing the secure boot process of a terminal system, characterized in that, Applied to the device side, the secure boot optimization method for the terminal system includes: Receive a target public key triplet sent by the development end. The target public key triplet includes the target startup root public key, the target startup root public key version number, and the target startup root public key signature. Extract the initial backup public key triplet from the target storage location. Verify the target public key triplet based on the initial backup public key triplet. If the verification is successful, overwrite the target public key triplet in the target storage location to obtain the target backup public key triplet. The target backup public key triplet includes the target backup startup root public key version number, the target backup startup root public key, and the target backup startup root public key signature. The current system is started based on the updated backup public key triplet.

7. The secure boot optimization method for a terminal system according to claim 6, characterized in that, Before verifying the target public key triple, the process also includes: The target storage location is constructed in a secure storage area, and the target storage location is used to store backup public key triplets; Obtain an initial public key triplet, which includes an initial startup root public key version number, an initial startup root public key, and an initial startup root public key signature. Store the initial public key triplet as an initial backup public key triplet in the target storage location to obtain the initial backup public key triplet, which includes an initial backup startup root public key version number, an initial backup startup root public key, and an initial backup startup root public key signature.

8. The secure boot optimization method for a terminal system according to claim 6, characterized in that, The target public key triplet is received via a secure channel.

9. The secure boot optimization method for a terminal system according to claim 7, characterized in that, The target public key triplet is verified based on the initial backup public key triplet to obtain the target backup public key triplet, including: The target startup root public key version number is compared with the initial backup startup root public key version number. If the target startup root public key version number is less than or equal to the initial backup startup root public key version number, the verification fails and writing to the target public key triplet is prohibited. If the target startup root public key version number is greater than the initial backup startup root public key version number, then the target startup root public key signature is verified based on the secure startup root public key. If the verification fails, writing to the target public key triplet is prohibited. If the verification is successful, the target public key triplet is written as a new backup public key triplet to the target storage location to obtain the target backup public key triplet.

10. The secure boot optimization method for a terminal system according to claim 7, characterized in that, The process of starting the current system based on the updated backup boot root public key includes: During system startup, if the local device is detected to be in an unlocked state, the updated backup public key triplet is retrieved from the target storage location; Obtain the initial root public key digest from the OTP area storage, wherein the initial root public key digest is the version number of the initial startup root public key and the hash value of the initial startup root public key; Obtain root partition data, which includes the content of the first root partition image, the first root partition signature, and the first root partition boot public key stored in the first root partition image. The content of the first root partition image includes the version number of the first root partition boot public key and the first root partition boot public key. Based on the comparison results of the initial root public key digest, the root partition data, and the target backup public key triplet, if the comparison result is the first comparison result, the system will proceed to the next startup stage normally; if the comparison result is the second comparison result, a target prompt box will pop up, and the system will proceed to the next startup stage based on the feedback signal; if the comparison result is the third comparison result, the system startup will be prohibited.

11. The secure boot optimization method for a terminal system according to claim 10, characterized in that, The comparison results based on the initial root public key digest, the root partition data, and the target backup public key triplet include: Obtain the first hash value, which is the hash value of the version number of the first root partition boot root public key and the hash value of the first root partition boot root public key; If the initial root public key digest is equal to the first hash value and the first root partition startup root public key is equal to the target backup startup root public key, then the output is the first comparison result.

12. The secure boot optimization method for a terminal system according to claim 11, characterized in that, Based on the comparison results of the initial root public key digest, the root partition data, and the target backup public key triplet, the method further includes: If the initial root public key digest is not equal to the first hash value, but the first root partition startup root public key is equal to the target backup startup root public key, then the signature of the target backup startup root public key is verified based on the secure startup root public key. If the verification is successful, the first comparison result is output; if the verification fails, the third comparison result is output.

13. The secure boot optimization method for a terminal system according to claim 11, characterized in that, Based on the comparison results of the initial root public key digest, the root partition data, and the target backup public key triplet, the method further includes: If the initial root public key digest is equal to the first hash value, but the first root partition startup root public key is not equal to the target backup startup root public key, then the signature of the target backup startup root public key is verified based on the secure startup root public key. If the verification is successful, the second comparison result is output; if the verification fails, the third comparison result is output.

14. The secure boot optimization method for a terminal system according to claim 10, characterized in that, The target prompt box is used to indicate that the current device is using an expired signature key and suggests upgrading. The feedback signal is the signal to continue to the next stage.

15. The secure boot optimization method for a terminal system according to claim 10, characterized in that, After the pop-up target prompt box appears, it also includes: Receive a first signal, which is a signal indicating agreement to upgrade; The current device is upgraded based on the official root partition image. The official root partition image includes the target boot root public key and the target root partition signature. The target root partition signature is a signature made by the development end based on the target boot root private key and the official root partition image. The target boot root private key and the target boot root public key are a key pair.

16. A secure startup optimization device for a terminal system, characterized in that, The device includes: The key creation module is used to create a new target boot root key when the initial boot root private key on the device is detected to be leaked. The target boot root key includes a target boot root private key and a target boot root public key. The version number creation module is used to obtain the backup boot root public key version number of the device, and create a target boot root public key version number based on the backup boot root public key version number, wherein the target boot root public key version number is greater than the backup boot root public key version number; The signature module is used to obtain the secure boot root private key of the device, and sign the target boot root public key based on the secure boot root private key to obtain the target boot root public key signature. The key sending module is used to send a target public key triplet to the device via a secure channel. The target public key triplet consists of the target startup root public key, the target startup root public key version number, and the target startup root public key signature.

17. A secure startup optimization device for a terminal system, characterized in that, The device includes: The key receiving module is used to receive a target public key triplet sent by the development end. The target public key triplet includes the target startup root public key, the target startup root public key version number, and the target startup root public key signature. The key update module is used to extract the initial backup public key triplet from the target storage location, verify the target public key triplet based on the initial backup public key triplet, and if the verification is successful, overwrite the target public key triplet on the target storage location to obtain the updated target backup public key triplet. The target backup public key triplet includes the target backup startup root public key version number, the target backup startup root public key, and the target backup startup root public key signature. The startup module is used to start the current system based on the updated backup public key triplet.

18. A secure boot optimization system for a terminal system, characterized in that, The secure boot optimization system for the terminal system includes a development end and a device end; The development terminal is used to implement the steps of the secure boot optimization method for the terminal system as described in any one of claims 1-5; The device is used to implement the steps of the secure startup optimization method for the terminal system as described in any one of claims 6-15.

19. A chip, characterized in that, The chip includes: a memory, a processor, and a secure boot optimization program for a terminal system stored in the memory and executable on the processor. When the secure boot optimization program for the terminal system is executed by the processor, it implements the steps of the secure boot optimization method for a terminal system as described in any one of claims 1-5, or implements the steps of the secure boot optimization method for a terminal system as described in any one of claims 6-15.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a secure boot optimization program for a terminal system. When executed by a processor, the secure boot optimization program for a terminal system implements the steps of the secure boot optimization method for a terminal system as described in any one of claims 1-5, or implements the steps of the secure boot optimization method for a terminal system as described in any one of claims 6-15.

Images