Safety optimization method and device for equipment unlocking, equipment and storage medium

Abstract

The invention provides a security optimization method and device for equipment unlocking, equipment and a storage medium, and the method comprises the steps: responding to an equipment unlocking instruction, and reading an unlocking key version in a root partition mirror image file of a verifiable starting mechanism of the equipment; generating a fixed unlocking request code based on the unlocking key version; when an equipment manufacturer website receives the fixed unlocking request code, the equipment manufacturer website carries out digital signature on the fixed unlocking request code and then feeds back an unlocking code; and verifying the unlocking code, and unlocking the equipment according to a verification result. According to the method and the device, the fixed unlocking request code is constructed for the single device, so that the security risk that a random number generator with relatively poor security generates the same unlocking request code on different devices so as to randomly unlock is avoided, and the security is improved.

Description

Technical Field

[0001] This invention relates to the field of equipment security technology, and in particular to a security optimization method, apparatus, device, and storage medium for unlocking equipment. Background Technology

[0002] In existing technologies, device manufacturers of devices like smartphones and tablets enable secure boot and verifiable boot functions to ensure device security, and also add a bootloader lock. Specifically, this involves writing PRK_HASH into the OTP (One-Time Programmable Device, securely readable by u-boot) and setting unlock_flag = 0 in the RPMB (Replay Protect Memory Block, securely readable and writable by TEE). unlock_flag represents the unlocked state of the device's bootloader and is stored in the RPMB. At the factory, unlock_flag = 0, indicating that the device's bootloader is locked by default. This restricts users to using only the official system image from the OEM; for example, device A can only use EMUI, device B can only use MIUI, and device C can only use ColorOS.

[0003] When users need to flash a system image other than that provided by the OEM, such as wanting to flash a MIUI image onto device A, the OEM needs to provide a device bootloader unlocking function. This function must satisfy the user's unlocking needs while ensuring the security of the unlocking function itself.

[0004] However, in existing technologies, the unlock request code (unlock_challenge) used in the unlocking process is randomly generated. To ensure security, devices must use a True Random Number Generator (TRNG) to generate this parameter. If a less secure random number generator is used, different devices may generate the same unlock request code. This situation poses a serious security risk, as the same unlock code may be used on different devices, significantly compromising the security of the device unlocking mechanism. Attackers could exploit this vulnerability to illegally unlock devices, thereby obtaining sensitive information or performing malicious operations on the devices.

[0005] Therefore, existing technologies have shortcomings and need to be improved and developed. Summary of the Invention

[0006] This application provides a security optimization method, apparatus, device, and storage medium for device unlocking, in order to solve the technical problem of poor security in device unlocking in related technologies.

[0007] To achieve the above objectives, this application adopts the following technical solution: In response to the device unlock command, read the unlock key version from the root partition image file of the device's verifiable boot mechanism; A fixed unlock request code is generated based on the unlock key version; When the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website digitally signs the fixed unlock request code and then sends out the unlock code. The unlock code is verified, and the device is unlocked based on the verification result.

[0008] Based on the above technical means, this application embodiment constructs a fixed unlock request code for a single device, thereby avoiding the security risk of a less secure random number generator generating the same unlock request code on different devices and thus arbitrarily unlocking the device, thus improving security.

[0009] In one embodiment of this application, before reading the unlock key version in the root partition image file of the device's verifiable boot mechanism in response to a device unlock command, the method further includes: Configure the device identity key certificate and unlock key certificate in advance in the root partition image file of the device's verifiable boot mechanism.

[0010] Based on the aforementioned technical means, this application embodiment adjusts the PIK_Certificate (device identity key certificate) and PUK_Certificate (unlock key certificate) to pre-set the PIK_Certificate and PUK_Certificate directly in the root partition image file of the device's verifiable boot mechanism, without dynamically returning them in the unlock_code. When the device's intermediate private key (PIK_Priv) is leaked, as long as the original device unlock private key (PUK_Priv) is not leaked, even if a hacker uses a forged fake_PUK to construct an unlock code, all devices that have not undergone emergency upgrades will still not be deceived into unlocking by the forged unlock code. This extends the emergency time window for PIK_Priv key leakage, avoids the risk of large-scale device deception unlocking in a short period of time, and improves security.

[0011] In one embodiment of this application, in response to a device unlock command, reading the unlock key version from the root partition image file of the device's verifiable boot mechanism includes: When the device restarts, it enters fastboot mode; Responding to the device unlock command, extract the device's unique key, device model, and device unique identifier; The device can read the unlock key version from the root partition image file of the boot mechanism.

[0012] Based on the above technical means, this application embodiment generates a unique variable through a hardware unique key, device model and unique identifier as the core component of the unlock request code. The unique variable is generated based on hardware binding information to ensure that the unlock request of each device cannot be copied and to prevent attackers from forging requests in batches.

[0013] In one embodiment of this application, generating a fixed unlock request code based on the unlock key version includes: A unique variable is generated based on the device's unique key, device model, and device unique identifier; The device model, the unlock key version, and the unique variable are concatenated into a fixed string to obtain a fixed unlock request code.

[0014] Based on the above technical means, the embodiments of this application use a fixed unlock_challenge (unlock request code) to avoid the computational overhead of users repeatedly submitting multiple random unlock request codes, resulting in the generation of multiple unlock codes for the same device.

[0015] In one embodiment of this application, generating unique variables based on the device's unique key, device model, and device unique identifier includes: Use the device model and unique device identifier as input data; The HMAC-SHA256 algorithm is invoked, and the input data is signed using the device's unique key to generate a unique variable.

[0016] Based on the above technical means, the embodiments of this application combine the device model and the device unique identifier, and use HUK signature to increase the dimension of input data and improve uniqueness; the HMAC-SHA256 algorithm is used to provide anti-tampering, anti-replay and anti-collision capabilities to prevent attackers from forging or intercepting unlock requests.

[0017] In one embodiment of this application, when the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website digitally signs the fixed unlock request code and then returns an unlock code, including: When the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website obtains the device model and the unlock key version; Locate the corresponding device unlock private key based on the device model and the unlock key version; Using a digital signature algorithm, the device's unlocking private key is used to digitally sign the fixed unlocking request code to obtain a signature value, which is then used as the unlocking code for feedback.

[0018] Based on the above technical means, the embodiments of this application locate the private key by device model and key version, ensuring that the unlocking authorization strictly matches the device hardware and security policy, and the digital signature provides identity authentication, data integrity and non-repudiation, preventing the forgery or tampering of unlocking requests.

[0019] In one embodiment of this application, when the device manufacturer's website receives the fixed unlock request code, after the device manufacturer's website digitally signs the fixed unlock request code and returns the unlock code, the process further includes: Receive a device unlock request and perform an unlock check; Read the root key hash value from the one-time programmable memory; Read the root key version, device root public key, and device model from the replay protection memory block, and obtain the concatenated hash value based on the root key version, device root public key, and device model; Determine whether the concatenated hash value is consistent with the root key hash value; If the concatenated hash value does not match the root key hash value, then unlocking will be refused.

[0020] Based on the above technical means, the embodiments of this application verify the combination of public key, version number and device model to prevent attackers from ignoring version or model matching when replacing public key, thereby improving the granularity of verification; using OTP to store root key hash, the physical immutability of OTP completely eliminates the risk of hash value being tampered with.

[0021] In one embodiment of this application, the root key version, device root public key, and device model are read from the replay protection memory block, and a concatenated hash value is obtained based on the root key version, device root public key, and device model, including: Read the root key version, device root public key, and device model from the replay-protected memory block; The device model, root key version, and device root public key are concatenated in sequence into a continuous binary data, and then a hash function is input to calculate the digest to obtain the concatenated hash value.

[0022] Based on the above technical means, this application embodiment ensures that all key data (public key, version, model) has not been tampered with by performing hash verification after concatenating multiple data, thus forming a complete trust chain.

[0023] In one embodiment of this application, after determining whether the concatenated hash value is consistent with the root key hash value, the process includes: If the hash value matches the root key hash value, then read the device identity key certificate from the root partition image file of the device verifiable boot mechanism. The signature of the device identity key certificate is verified using the device root public key; If the verification fails, the unlocking will be refused.

[0024] Based on the above technical means, this application embodiment uses a certificate issued by the manufacturer to ensure the authenticity and uniqueness of the device's identity and prevent counterfeiting or impersonation.

[0025] In one embodiment of this application, after verifying the signature of the device identity key certificate using the device root public key, the method further includes: If the verification is successful, the device intermediate public key is read from the device identity key certificate; Read the unlock key certificate from the root partition image file of the device that verifies the boot mechanism; The signature of the unlock key certificate is verified using the device's intermediate public key; If the verification fails, the unlocking will be refused.

[0026] Based on the above technical means, the embodiments of this application use an intermediate key mechanism to avoid direct exposure of the root key, thereby reducing the risk of leakage; and to ensure that the source of the unlocking key is trustworthy, preventing certificate tampering or forgery.

[0027] In one embodiment of this application, verifying the unlock code and unlocking the device based on the verification result includes: If the signature verification of the unlock key certificate using the device's intermediate public key is successful, then the device unlock public key and the unlock code are read from the unlock key certificate; The device unlocking public key is used to verify the unlocking code. If the verification is successful, the device is successfully unlocked.

[0028] Based on the above technical means, the embodiments of this application significantly improve security through hierarchical key verification.

[0029] In one embodiment of this application, verifying the unlock code and unlocking the device based on the verification result further includes: If the signature verification of the unlock key certificate using the device's intermediate public key is successful, then the device unlock public key and the unlock code are read from the unlock key certificate; The device's public key is used to verify the unlock code. If the verification fails, unlocking is refused.

[0030] Based on the above technical means, the embodiments of this application significantly improve the security, reliability and anti-attack capability of the device unlocking process through a strict verification failure handling mechanism and hierarchical key verification.

[0031] In one embodiment of this application, the device unlocking public key is used to verify the unlocking code. If the verification is successful, the device is successfully unlocked, including: Use the device's unlock public key to verify the unlock code; If the verification is successful, the device unlock status in the replay protection memory block will be set to 1, and the device will be successfully unlocked.

[0032] Based on the above technical means, the embodiments of this application further enhance the security, reliability and anti-attack capability of the device unlocking process through dynamic key verification and atomic state update.

[0033] In one embodiment of this application, the key versions of the root partition signing public key and the device unlocking public key are upgraded independently.

[0034] Based on the above technical means, the version of the device unlock public key (PUK) in this application embodiment is no longer strongly bound to the version of the root partition's signature public key (PSK). The versions of the PSK key and the PUK key can be upgraded independently, reducing the cost of key management.

[0035] In one embodiment of this application, the digital signature algorithm includes: an elliptic curve digital signature algorithm or a probabilistic signature algorithm.

[0036] Based on the above technical means, the digital signature algorithm of this application embodiment can be used in a variety of ways, which improves the flexibility of digital signature.

[0037] In one embodiment of this application, the message verification code algorithm in the device unlocking security optimization method is a hash-based message verification code algorithm or a block cipher-based message verification code algorithm.

[0038] Based on the above technical means, the message verification code algorithm of this application embodiment can be used in a variety of ways, which improves the flexibility of calculating message verification codes.

[0039] This application also provides a security optimization device for device unlocking, wherein the device includes: The read module is used to respond to device unlock commands and read the unlock key version in the root partition image file of the device's verifiable boot mechanism; The generation module is used to generate a fixed unlock request code based on the unlock key version; The signature module is used so that when the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website digitally signs the fixed unlock request code and then sends out the unlock code. The verification module is used to verify the unlock code and unlock the device based on the verification result.

[0040] This application also provides an apparatus comprising: a memory, a processor, and a device unlocking security optimization program stored in the memory and executable on the processor, wherein the device unlocking security optimization program, when executed by the processor, implements the steps of the device unlocking security optimization method as described above.

[0041] This application also provides a computer-readable storage medium storing a computer program that can be executed to implement the steps of the security optimization method for unlocking the device as described above.

[0042] The present invention achieves the following beneficial effects: (1) The embodiments of this application construct a fixed unlock request code for a single device, thereby avoiding the security risk of a random number generator with poor security generating the same unlock request code on different devices and thus arbitrarily unlocking the device, thus improving security.

[0043] (2) In this embodiment, by adjusting PIK_Certificate (device identity key certificate) and PUK_Certificate (unlock key certificate), PIK_Certificate and PUK_Certificate are directly pre-set in the root partition image file of the device's verifiable boot mechanism, and are not dynamically returned in unlock_code. When the device's intermediate private key (PIK_Priv) is leaked, as long as the original device unlock private key (PUK_Priv) is not leaked, even if the hacker uses a fake fake_PUK to construct an unlock code, all devices that have not been urgently upgraded will still not be deceived into unlocking by the fake unlock code. This expands the emergency provincial time window for PIK_Priv key leakage, avoids the risk of large-scale device deception unlocking in a short period of time, and improves security.

[0044] (3) The embodiments of this application use a fixed unlock_challenge (unlock request code) to avoid the computational overhead of generating multiple unlock codes for the same device by repeatedly submitting multiple random unlock request codes.

[0045] (4) In this embodiment of the application, the version of the device unlock public key (PUK) is no longer strongly bound to the version of the root partition signature public key (PSK). The versions of the PSK key and the PUK key can be upgraded independently, which reduces the cost of key management. Attached Figure Description

[0046] Figure 1 This is a flowchart of a preferred embodiment of the security optimization method for device unlocking in this invention.

[0047] Figure 2 This is a flowchart of a specific embodiment of step S200 in a preferred embodiment of the security optimization method for unlocking devices in this invention.

[0048] Figure 3 This is a flowchart of another specific embodiment of step S210 in the preferred embodiment of the device unlocking security optimization method of the present invention.

[0049] Figure 4 This is a flowchart of step S300 in a preferred embodiment of the device unlocking security optimization method of the present invention.

[0050] Figure 5 This is a flowchart illustrating the specific process of device unlocking checks in a preferred embodiment of the security optimization method for device unlocking in this invention.

[0051] Figure 6 This is a flowchart of step S30 in a preferred embodiment of the device unlocking security optimization method of the present invention.

[0052] Figure 7 This is a specific flowchart of step S40 in a preferred embodiment of the device unlocking security optimization method of the present invention.

[0053] Figure 8 This is another specific flowchart of step S40 in a preferred embodiment of the device unlocking security optimization method of the present invention.

[0054] Figure 9 This is a specific flowchart of step S400 in a preferred embodiment of the device unlocking security optimization method of the present invention.

[0055] Figure 10 This is another specific flowchart of step S400 in a preferred embodiment of the device unlocking security optimization method of the present invention.

[0056] Figure 11 This is a flowchart of step S420a in a preferred embodiment of the device unlocking security optimization method of the present invention.

[0057] Figure 12 This is a flowchart of a preferred embodiment of the security optimization method for device unlocking in this invention.

[0058] Figure 13 This is a flowchart of step A2 in a preferred embodiment of the device unlocking security optimization method of the present invention.

[0059] Figure 14 This is a functional principle block diagram of a preferred embodiment of the security optimization device for device unlocking in this invention.

[0060] Figure 15 This is a functional principle block diagram of a preferred embodiment of the device in this invention. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages 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.

[0062] First, Table 1 provides explanations of the English and Chinese text.

[0063] Table 1

[0064] In existing technology, the device unlocking steps include: Step 1, constructing a PIK_Certificate in the OEM backend. The signature is generated by PRK_Priv signing the data field content. The specific code is as follows: { data:{ subject: [Product ID], ver: [PIK Version], pub: [PRK], }, signature: ... } Step 2: The OEM backend constructs the PSK_Certificate. The signature is performed by PIK_Priv on the data field content. The specific code is as follows: { data:{ subject: [Product ID], ver: [PSK Version], pub: [PSK Pubkey], }, signature: ... } Step 3: The OEM backend constructs the PUK_Certificate. The signature is generated by PIK_Priv for the data field content. The specific code is as follows: { data:{ subject: [Product ID], ver: [PUK Version], pub: [PUK Pubkey], }, signature: ... } Step 4: The OEM backend builds the root partition image. The Verified boot root partition image contains PSK and PSK_Version.

[0065] Step 5: Factory production. This specifically includes: (1) Burn PRK_Hash = Hash(ProductID || PRK_Version || PRK) into OTP; (2) Burn HUK into the OTP; (3) Write unlock_flag = 0 in RPMB; (4) Write PRK_Version, PRK, and ProductID into RPMB.

[0066] Step 6: The user obtains the unlock code. This includes: (1) The user restarts the phone and enters fastboot mode.

[0067] (2) The user inputs the fastboot command (e.g., fastboot oem get_unlock_data).

[0068] (3) The unlocking program in fastboot (denoted as unlock_service) randomly generates an unlocking request code (unlock_challenge) and returns it to the user.

[0069] (4) The user logs in to the OEM manufacturer's website, submits an unlock_challenge, and requests the bootloader unlock code.

[0070] (5) The OEM manufacturer uses PUK_Priv to digitally sign unlock_challenge and obtains the signature value: unlock_signature = sign(key = PUK_Priv, data = unlock_challenge).

[0071] (6) The OEM manufacturer returns an unlock code in the backend. The specific code is as follows: Figure 4 As shown.

[0072] Step 7: The user uses the unlock code to unlock the device. This includes: (1) The user enters the fastboot command (e.g., fastboot oem unlock [unlock_code]) to submit a device unlock request.

[0073] (2)The unlocking program in fastboot (denoted as unlock_service) starts to perform unlocking checks.

[0074] (3)unlock_service reads PRK_Hash from the OTP.

[0075] (4)unlock_service reads PRK_Version, PRK, and ProductID from the RPMB, and calculates PRK_Hash_Calc = Hash(ProductID || PRK_Version || PRK).

[0076] (5)unlock_service compares whether PRK_Hash_Calc and PRK_Hash are the same. If they are not the same, unlocking is rejected and the process ends.

[0077] (6)unlock_service reads PIK_Certificate from unlock_code, and uses PRK to perform signature verification on the signature of PIK_Certificate. If the verification fails, unlocking is rejected and the process ends.

[0078] (7)unlock_service reads PIK from PIK_Certificate.

[0079] (8)unlock_service reads PUK_Certificate from unlock_code, and uses PIK to perform signature verification on the signature of PUK_Certificate. If the verification fails, unlocking is rejected and the process ends.

[0080] (9)unlock_service reads PUK_Version from PUK_Certificate.

[0081] (10)unlock_service reads PSK_Version from the Verified boot root partition image.

[0082] (11)unlock_service compares the sizes of PUK_Version and PSK_Version. If PUK_Version < PSK_Version, unlocking is rejected and the process ends.

[0083] (12)unlock_service reads PUK and unlock_signature from PUK_Certificate.

[0084] (13) unlock_service uses the previously randomly generated unlock_challenge and verifies unlock_signature using PUK. If the verification fails, unlocking is refused and the process ends. unlock_result = verify(key =PUK_Priv, data = unlock_challenge, sig = unlock_signature).

[0085] (14) unlock_service sets unlock_flag in RPMB to 1, and the device is successfully unlocked.

[0086] The existing solutions have the following drawbacks: First, the unlock_challenge is generated randomly. The device must use a TRNG (True Random Number Generator) to avoid the possibility that a less secure random number generator will generate the same unlock_challenge on different devices, which would allow the same unlock code to be used on different devices and pose a security risk.

[0087] Secondly, the PUK version is strongly bound to the PSK version. When the PSK key is upgraded, the PUK version must be upgraded accordingly; otherwise, unlocking may fail, increasing key management costs.

[0088] Third, PIK_Certificate and PUK_Certificate are dynamically returned in unlock_code. When PIK_Priv is leaked, a hacker can forge a new version of {fake_PUK, fake_PUK_Priv} and increment PUK_Version as fake_PUK_Version. The hacker uses PIK_Priv to sign the forged {fake_PUK, fake_PUK_Version}, generating a forged PUK_Certificate. The hacker ultimately uses the forged PIK_Priv to sign the unlock_challenge of any device, obtaining the unlock code. This means that all devices that have not been urgently upgraded are at risk of being unlocked arbitrarily.

[0089] To address the poor security issues of device unlocking in the aforementioned related technologies, this application provides a security optimization method for device unlocking. In this method, in response to a device unlocking command, the unlocking key version is read from the root partition image file of the device's verifiable boot mechanism; a fixed unlocking request code is generated based on the unlocking key version; when the device manufacturer's website receives the fixed unlocking request code, the website digitally signs the fixed unlocking request code and then returns the unlocking code; the unlocking code is verified, and the device is unlocked based on the verification result. This application, by constructing a fixed unlocking request code for a single device, avoids the security risk of a weakly secure random number generator generating the same unlocking request code on different devices, thus arbitrarily unlocking the device, thereby improving security.

[0090] Please see Figure 1 The security optimization method for device unlocking described in this embodiment of the invention includes the following steps: Step S100: Respond to the device unlock command and read the unlock key version in the root partition image file of the device's verifiable boot mechanism.

[0091] Specifically, this application reads the PUK_Version (unblocking key version) from the Verified boot root partition image (i.e., the root partition image file of the device's verifiable boot mechanism). The Verified boot root partition image is a critical partition image used by the Android device to verify system integrity during boot, typically containing trust anchors (such as public keys) and verification metadata (such as vbmeta structures) required for device boot. PUK_Version is the PUK (Personal Unblocking Key) version number identifier associated with the device unlocking process, typically used in the unlocking mechanism of device manufacturers (OEMs) to distinguish different versions of PUK keys or unlocking strategies.

[0092] In this embodiment of the application, before responding to the device unlock command and reading the unlock key version in the root partition image file of the device verifiable boot mechanism, the method further includes: configuring the device identity key certificate and the unlock key certificate in the root partition image file of the device verifiable boot mechanism in advance.

[0093] Among them, PIK_Certificate (Device Identity Key Certificate) is a form of digital certificate used to verify identity or authorize specific operations; PUK_Certificate (Unlock Key Certificate) is a certificate structure containing a PUK code and its digital signature, used to verify the legitimacy of the PUK code during the device unlocking process. Its core function is to ensure that the PUK code has not been tampered with through a digital signature mechanism and is signed by a trusted key (PUK_Priv).

[0094] This application modifies the PIK_Certificate (device identity key certificate) and PUK_Certificate (unlock key certificate), pre-setting them directly in the Verified boot root partition image instead of dynamically returning them in the unlock_code. When the device's intermediate private key (PIK_Priv) is leaked, as long as the original device unlock private key (PUK_Priv) is not leaked, even if a hacker uses a forged fake_PUK to construct an unlock code, all devices that have not undergone emergency upgrades will still not be fooled into unlocking by the forged unlock code. This extends the emergency time window for PIK_Priv key leaks, avoids the risk of large-scale device spoofing unlocking in a short period, and improves security.

[0095] In this embodiment of the application, step S100 specifically includes: Step S110: When the device restarts, enter fastboot mode; Step S120: Respond to the device unlock command and extract the device's unique key, device model, and device unique identifier; Step S130: Read the unlock key version in the root partition image file of the device's verifiable boot mechanism.

[0096] This application first requires the user to obtain an unlock code. Specifically, the user reboots the phone to enter fastboot mode; the user enters a fastboot command (e.g., fastboot oem get_unlock_data); and the PUK_Version (unlock key version) is read from the root partition image file of Verified boot (the device's verifiable boot mechanism). Fastboot mode is a dedicated entry point for device unlocking, accessible only through physical operations (such as key combinations) or authorized commands, preventing remote attackers from initiating malicious unlock requests through regular system interfaces.

[0097] This application generates unique variables using a hardware unique key, device model, and unique identifier as the core components of the unlock request code. These unique variables are generated based on hardware binding information, ensuring that each device's unlock request cannot be copied and preventing attackers from forging requests in bulk.

[0098] Please see Figure 1 The security optimization method for device unlocking described in this embodiment of the invention further includes the following steps: Step S200: Generate a fixed unlock request code based on the unlock key version.

[0099] In one embodiment of this application, such as Figure 2 As shown, step S200 specifically includes: Step S210: Generate unique variables based on the device's unique key, device model, and device unique identifier; Step S220: Concatenate the device model, the unlock key version, and the unique variable into a fixed string to obtain a fixed unlock request code.

[0100] The unlocking program (unlock_service) in the fastboot of this application generates a fixed unlocking request code (unlock_challenge) and returns it to the user. Specifically, in step S130, the unlocking key version has been obtained. Based on HUK, a unique variable UniqVar is calculated for each device, and a fixed unlock_challenge is generated, i.e., unlock_challenge = ProductID || PUK_Version || UniqVar.

[0101] This application uses a fixed unlock_challenge (unlock request code) to avoid the computational overhead of users repeatedly submitting multiple random unlock request codes, which would otherwise lead to the generation of multiple unlock codes for the same device.

[0102] In the embodiments of this application, such as Figure 3 As shown, step S210 specifically includes: Step S211: Use the device model and device unique identifier as input data; Step S212: Call the HMAC-SHA256 algorithm and use the device's unique key to sign the input data to generate a unique variable.

[0103] Specifically, this application uses the device model (ProductID) and device unique identifier (DeviceID) as input data, calls the HMAC-SHA256 algorithm, and uses the device unique key (HUK) to sign the input data to generate a unique variable (UniqVar).

[0104] This application invokes the HMAC-SHA256 algorithm to sign the input data using the device's unique key, i.e., UniqVar = HMAC-SHA256(HUK,ProductID||DeviceID). HMAC-SHA256 is a message authentication code (HMAC) algorithm that combines a hash function (SHA-256) and a key to verify the integrity and authenticity of messages. It generates a fixed-length authentication code through a shared key, ensuring that the message has not been tampered with during transmission or storage and that its source is trustworthy.

[0105] This application combines the device model and unique device identifier with HUK signature, increasing the dimension of input data and improving uniqueness; it uses the HMAC-SHA256 algorithm to provide anti-tampering, anti-replay and anti-collision capabilities, preventing attackers from forging or intercepting unlock requests.

[0106] Please see Figure 1 The security optimization method for device unlocking described in this embodiment of the invention further includes the following steps: Step S300: When the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website digitally signs the fixed unlock request code and then sends back the unlock code.

[0107] Specifically, the user logs into the OEM manufacturer's website and submits an unlock_challenge (a fixed unlock request code) to request a bootloader unlock code.

[0108] In the embodiments of this application, such as Figure 4 As shown, step S300 specifically includes: Step S310: When the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website obtains the device model and the unlock key version; Step S320: Locate the corresponding device unlock private key based on the device model and the unlock key version; Step S330: Using a digital signature algorithm, the device unlocking private key is used to digitally sign the fixed unlocking request code to obtain a signature value, and the signature value is used as the unlocking code for feedback.

[0109] Specifically, the OEM manufacturer's backend uses the device model (ProductID) and unlock key version (PUK_Version) to locate the corresponding device unlock private key (PUK_Priv). Then, it uses the device unlock private key to digitally sign the fixed unlock request code, obtaining the signature value: unlock_signature = sign(key = PUK_Priv, data = unlock_challenge). Finally, the OEM manufacturer returns the unlock code. The PIK_Certificate (device identity key certificate) and PUK_Certificate (unlock key certificate) are not returned in unlock_code; unlock_code = unlock_signature (signature value).

[0110] This application locates the private key by device model and key version, ensuring that the unlocking authorization strictly matches the device hardware and security policy. Digital signature provides identity authentication, data integrity and non-repudiation, preventing forgery or tampering of unlocking requests.

[0111] Please see Figure 1 The security optimization method for device unlocking described in this embodiment of the invention further includes the following steps: Step S400: Verify the unlock code and unlock the device based on the verification result.

[0112] In the embodiments of this application, such as Figure 5 As shown, after step S300, the method further includes: Step S10: Receive device unlock request and perform unlock check; Step S20: Read the root key hash value from the one-time programmable memory; Step S30: Read the root key version, device root public key and device model from the replay protection memory block, and obtain the concatenated hash value based on the root key version, device root public key and device model; Step S40: Determine whether the concatenated hash value is consistent with the root key hash value; Step S50: If the concatenated hash value is inconsistent with the root key hash value, then unlocking is refused.

[0113] Specifically, the user inputs a fastboot command (e.g., fastboot oem unlock [unlock_code]) to submit a device unlock request. The unlocking program in fastboot (denoted as unlock_service) begins performing unlock checks. The unlocking program reads the root key hash value (PRK_Hash) from the One-Time Programmable Memory (OTP); and reads the root key version (PRK_Version), device root public key (PRK), and device model (ProductID) from the Replay Protection Memory Block (RPMB), calculating a concatenated hash value. The unlocking program compares the concatenated hash value (PRK_Hash_Calc) with the root key hash value (PRK_Hash). If they do not match, unlocking is rejected, and the device unlocking process ends.

[0114] This application improves the granularity of verification by verifying the combination of public key, version number, and device model to prevent attackers from ignoring version or model matching when replacing the public key; it uses OTP to store the root key hash, and the physical immutability of OTP completely eliminates the risk of hash value tampering.

[0115] In the embodiments of this application, such as Figure 6 As shown, step S30 specifically includes: Step S31: Read the root key version, device root public key, and device model from the replay protection memory block; Step S32: After concatenating the device model, root key version, and device root public key into a continuous binary data in sequence, input the hash function to calculate the digest and obtain the concatenated hash value.

[0116] Specifically, the concatenated hash value is calculated as follows: PRK_Hash_Calc = Hash(ProductID || PRK_Version || PRK), which means concatenating the device model, root key version, and device root public key into a continuous binary data in sequence, inputting it into a hash function to calculate the digest, and obtaining the concatenated hash value.

[0117] This application ensures that all critical data (public key, version, model) has not been tampered with by performing hash verification after concatenating multiple data, thus forming a complete trust chain.

[0118] In one embodiment of this application, such as Figure 7 As shown, after step S40, the method further includes: Step S41: If the hash value is consistent with the root key hash value, then read the device identity key certificate from the root partition image file of the device verifiable boot mechanism. Step S42: Verify the signature of the device identity key certificate using the device root public key; Step S43: If the verification fails, then the unlocking will be refused.

[0119] Specifically, the unlocking process reads the device identity key certificate (PIK_Certificate) from the Verified boot root partition image and verifies the signature of the PIK_Certificate using the device root public key (PRK). If the verification fails, unlocking is refused, and the device unlocking process ends.

[0120] This application uses a certificate issued by the manufacturer to ensure the authenticity and uniqueness of the device's identity, preventing counterfeiting or impersonation.

[0121] In the embodiments of this application, such as Figure 8 As shown, after step S42, the method further includes: Step S44: If the verification is successful, read the device intermediate public key from the device identity key certificate; Step S45: Read the unlock key certificate from the root partition image file of the device's verifiable boot mechanism; Step S46: Verify the signature of the unlock key certificate using the device's intermediate public key; Step S47: If the verification fails, then the unlocking will be refused.

[0122] Specifically, if the verification is successful, the device intermediate public key (PIK) is read from the device identity key certificate (PIK_Certificate), the unlock key certificate (PUK_Certificate) is read from the Verified boot root partition image, and the signature of the PUK_Certificate is verified using the PIK. If the verification fails, unlocking is refused, and the device unlocking process ends.

[0123] This application uses an intermediate key mechanism to avoid directly exposing the root key, reducing the risk of leakage; it also ensures that the source of the unlocking key is trustworthy, preventing certificate tampering or forgery.

[0124] In one embodiment of this application, such as Figure 9 As shown, step S400 specifically includes: Step S410a: If the signature verification of the unlock key certificate using the device intermediate public key is successful, then read the device unlock public key and the unlock code from the unlock key certificate; Step S420a: Use the device unlock public key to verify the unlock code. If the verification is successful, the device is successfully unlocked.

[0125] Specifically, if the signature verification of the unlock key certificate using the device's intermediate public key is successful, the device unlock public key (PUK) and unlock code (unlock_signature) are read from the unlock key certificate (PUK_Certificate). The unlock code (unlock_signature) is verified using the device unlock public key (PUK). If the verification is successful, the device is successfully unlocked. That is, unlock_result = verify(key = PUK_Priv, data = unlock_challenge, sig = unlock_signature). Here, verify() is a digital signature verification function used to check whether the signature (sig) is correctly generated from the private key pair (data) corresponding to the specified public key (key). The specified public key (key) is the device unlock private key (PUK_Priv), the private key pair (data) is a fixed unlock request code (unlock_challenge), and the signature (sig) is unlock_signature (signature value).

[0126] This application significantly improves security through a layered key verification method.

[0127] In one embodiment of this application, such as Figure 10 As shown, step S400 further includes: Step S410b: If the signature verification of the unlock key certificate using the device intermediate public key is successful, then read the device unlock public key and the unlock code from the unlock key certificate; Step S420b: Use the device's unlock public key to verify the unlock code. If the verification fails, unlocking is refused.

[0128] Specifically, if the signature verification of the unlock key certificate using the device's intermediate public key is successful, the device unlock public key (PUK) and unlock code (unlock_signature) are read from the unlock key certificate (PUK_Certificate). The unlock code (unlock_signature) is verified using the device unlock public key (PUK). If the verification fails, unlocking is refused, and the device unlocking process ends.

[0129] This application significantly improves the security, reliability, and resistance to attacks of the device unlocking process through a rigorous verification failure handling mechanism and hierarchical key verification.

[0130] In one embodiment of this application, such as Figure 11 As shown, step S420a specifically includes: Step S421a: Verify the unlock code using the device's unlock public key; Step S422a: If the verification is successful, the device unlock status in the replay protection memory block is set to 1, and the device is successfully unlocked.

[0131] Specifically, when the device leaves the factory, unlock_flag = 0, indicating that the device bootloader is locked by default.

[0132] The unlocking process sets the device unlock status (unlock_flag) in the replay protected memory block (RPMB) to 1, and the device is successfully unlocked.

[0133] This application further enhances the security, reliability, and anti-attack capabilities of the device unlocking process through dynamic key verification and atomic state updates.

[0134] In one embodiment of this application, the key versions of the root partition signing public key and the device unlocking public key are upgraded independently.

[0135] The version of the device unlock public key (PUK) in this application is no longer strongly bound to the version of the root partition's signing public key (PSK). The versions of the PSK key and the PUK key can be upgraded independently, reducing the cost of key management.

[0136] In one embodiment of this application, the digital signature algorithm includes: an elliptic curve digital signature algorithm or a probabilistic signature algorithm.

[0137] Specifically, the Elliptic Curve Digital Signature Algorithm (ECDSA) is a digital signature algorithm based on Elliptic Curve Cryptography (ECC), whose core principle relies on the mathematical problem of the Elliptic Curve Discrete Logarithm (ECDLP). The Probabilistic Signature Algorithm (RSASSA-PSS) is an improved version of the RSA algorithm, incorporating a padding scheme (PSS) to enhance security.

[0138] The digital signature algorithm of this application can be used in a variety of ways, which improves the flexibility of digital signatures.

[0139] In this embodiment of the application, the message verification code algorithm in the security optimization method for unlocking the device is a hash-based message verification code algorithm or a block cipher-based message verification code algorithm.

[0140] Specifically, a message verification code (MAC) is a cryptographic technique used to verify the integrity and authenticity of data. It generates a fixed-length checksum (MAC) value using a shared key and a specific algorithm, which is appended to the original message before transmission. The receiver recalculates the MAC value using the same key and algorithm; if it matches the received value, the receiver confirms that the message has not been tampered with and originated from a legitimate sender. Hash-based Message Verification Code (HMAC) is one implementation of MAC, combining a hash function (such as SHA-256) and a shared key to generate the MAC value, enhancing the security of the hash function and resisting known attacks (such as length extension attacks). Block Cipher-based Message Verification Code (CMAC) generates the MAC value based on a block cipher algorithm. It uses the encryption mode of the block cipher and key derivation techniques to convert the message into a fixed-length checksum.

[0141] The message verification code algorithm of this application can be used in a variety of ways, which improves the flexibility of message verification code calculation.

[0142] This application achieves the following beneficial effects: First, this invention constructs a fixed unlock_challenge for a single device by combining UniqVar = HMAC-SHA256(HUK, ProductID || DeviceID) with the ProductID, thus avoiding the security risk of arbitrary unlocking caused by a less secure random number generator generating the same unlock_challenge on different devices. This improves security, reduces the device's dependence on TRNG, and saves chip costs.

[0143] Secondly, the PUK version and PSK version of this invention are no longer strongly bound. The versions of the PSK key and PUK key can be upgraded independently, reducing the cost of key management.

[0144] Third, the PIK_Certificate (device identity key certificate) and PUK_Certificate (unlock key certificate) have been adjusted. PIK_Certificate and PUK_Certificate are now pre-set in the Verified boot root partition image, instead of being dynamically returned in the unlock_code. When the device's intermediate private key (PIK_Priv) is leaked, as long as the original device unlock private key (PUK_Priv) is not leaked, even if a hacker uses a forged fake_PUK to construct an unlock code, all devices that have not undergone emergency upgrades will still not be fooled into unlocking by the forged unlock code. This extends the emergency time window for PIK_Priv key leaks, avoids the risk of large-scale device spoofing and unlocking in a short period, and improves security.

[0145] Fourth, this invention uses a fixed unlock_challenge to avoid the computational overhead of generating multiple unlock codes for the same device caused by users repeatedly submitting multiple random unlock_challenges.

[0146] In one specific embodiment of this application, such as Figure 12 As shown, the device unlocking steps include: Step A1: Adjust PIK_Certificate and PUK_Certificate.

[0147] PIK_Certificate and PUK_Certificate are pre-configured in the Verified boot root partition image; Step A2: The user obtains the unlock code.

[0148] Step A3: The user uses the unlock code to unlock the device.

[0149] like Figure 13 As shown, step A2 specifically includes: Step A21: The user restarts the phone and enters fastboot mode; Step A22: The user enters a fastboot command (e.g., fastboot oem get_unlock_data); Step A23: The unlocking program in fastboot (denoted as unlock_service) generates a fixed unlocking request code (unlock_challenge) and returns it to the user; Step A24: The user logs into the OEM manufacturer's website, submits an unlock_challenge, and requests a bootloader unlock code; Step A25: The OEM manufacturer uses ProductID and PUK_Version to locate the corresponding PUK_Priv in the backend, and then uses PUK_Priv to digitally sign unlock_challenge to obtain the signature value; Step A26: The OEM manufacturer returns the unlock code.

[0150] Step A3 specifically includes: Step A31: The user enters the fastboot command (e.g., fastboot oem unlock [unlock_code]) to submit a device unlock request; Step A32: The unlocking program in fastboot (denoted as unlock_service) begins to perform the unlock check; Step A33: unlock_service reads PRK_Hash from OTP; Step A34: unlock_service reads PRK_Version, PRK, and ProductID from RPMB and calculates PRK_Hash_Calc = Hash(ProductID || PRK_Version || PRK); Step A35: The unlock_service compares PRK_Hash_Calc with PRK_Hash. If they do not match, unlocking is refused, and the process ends. Step A36: The unlock_service reads the PIK_Certificate from the Verified boot root partition image and uses the PRK to verify the signature of the PIK_Certificate. If the verification fails, unlocking is refused, and the process ends. Step A37: unlock_service reads PIK from PIK_Certificate; Step A38: The unlock_service reads the PUK_Certificate from the Verified boot root partition image and uses PIK to verify the signature of the PUK_Certificate. If the verification fails, unlocking is refused, and the process ends.

[0151] Step A39: unlock_service reads PUK and unlock_signature from PUK_Certificate.

[0152] Step A40: Verify the unlock_signature using PUK. If the verification fails, refuse to unlock and end the process.

[0153] Step A41: unlock_service sets unlock_flag in RPMB to 1, and the device is successfully unlocked.

[0154] In one embodiment, such as Figure 14 As shown, based on the above-described security optimization method for device unlocking, the present invention also provides a corresponding security optimization device for device unlocking, comprising: The reading module 100 is used to respond to the device unlock command and read the unlock key version in the root partition image file of the device's verifiable boot mechanism. Generation module 200 is used to generate a fixed unlock request code based on the unlock key version; The signature module 300 is used to digitally sign the fixed unlock request code and then return the unlock code when the device manufacturer's website receives the fixed unlock request code. The verification module 400 is used to verify the unlock code and unlock the device based on the verification result.

[0155] In one embodiment, the security optimization device for device unlocking further includes: A pre-configured module is used to pre-configure the device identity key certificate and unlock key certificate in the root partition image file of the device's verifiable boot mechanism.

[0156] In one embodiment, the reading module 100 includes: The reboot unit is used to enter fastboot mode when the device reboots; The response unit is used to respond to the device unlock command and extract the device's unique key, device model, and device unique identifier. The read unit is used to read the unlock key version from the root partition image file of the device's boot mechanism verification mechanism.

[0157] In one embodiment, the generation module 200 includes: The variable generation unit is used to generate unique variables based on the device's unique key, device model, and device unique identifier. The splicing unit is used to concatenate the device model, the unlock key version, and the unique variable into a fixed string to obtain a fixed unlock request code.

[0158] In one embodiment, the variable generation unit includes: The input subunit is used to input the device model and the device unique identifier as input data; The signature subunit is used to invoke the HMAC-SHA256 algorithm, use the device's unique key to sign the input data, and generate a unique variable.

[0159] In one embodiment, the signature module 300 includes: The acquisition unit is used to acquire the device model and the unlock key version when the device manufacturer's website receives the fixed unlock request code. The positioning unit is used to locate the corresponding device unlocking private key according to the device model and the unlocking key version; The signature unit is used to digitally sign the fixed unlock request code using the device's unlock private key using a digital signature algorithm, obtain a signature value, and then use the signature value as the unlock code to provide feedback.

[0160] In one embodiment, the security optimization device for device unlocking further includes: The unlock request module is used to receive device unlock requests and perform unlock checks; The hash value reading module is used to read the root key hash value from a one-time programmable memory; The data splicing module is used to read the root key version, device root public key and device model from the replay protection memory block, and obtain the spliced ​​hash value based on the root key version, device root public key and device model; The hash value determination module is used to determine whether the concatenated hash value is consistent with the root key hash value; The module for refusing to unlock is used to refuse to unlock if the concatenated hash value is inconsistent with the root key hash value.

[0161] In one embodiment, the data stitching module includes: The data reading unit is used to read the root key version, device root public key, and device model from the replay protection memory block; The connection unit is used to concatenate the device model, root key version, and device root public key into a continuous binary data in sequence, and then input the hash function to calculate the digest to obtain the concatenated hash value.

[0162] In one embodiment, the security optimization device for device unlocking further includes: The certificate reading module is used to read the device identity key certificate in the root partition image file of the device verifiable boot mechanism if the hash value is consistent with the root key hash value. The signature verification module is used to verify the signature of the device identity key certificate using the device root public key; The "Refuse to Unlock" module is also used to refuse unlocking if the verification fails.

[0163] In one embodiment, the security optimization device for device unlocking further includes: The intermediate public key reading module is used to read the device intermediate public key from the device identity key certificate if the verification is successful. The certificate reading module is also used to read the unlock key certificate in the root partition image file of the device's boot mechanism verification mechanism; The signature verification module is also used to verify the signature of the unlock key certificate using the device's intermediate public key; The "Refuse to Unlock" module is also used to refuse unlocking if the verification fails.

[0164] In one embodiment, the verification module 400 includes: The unlock code reading module is used to read the device unlock public key and the unlock code from the unlock key certificate if the signature verification of the unlock key certificate using the device intermediate public key is successful; The unlocking module is used to verify the unlocking code using the device's unlocking public key. If the verification is successful, the device is successfully unlocked.

[0165] In one embodiment, the verification module 400 includes: The unlock code reading module is used to read the device unlock public key and the unlock code from the unlock key certificate if the signature verification of the unlock key certificate using the device intermediate public key is successful; The unlock rejection module is also used to verify the unlock code using the device's unlock public key; if the verification fails, unlocking is rejected.

[0166] In one embodiment, the unlocking module includes: An unlock code verification unit is used to verify the unlock code using the device's unlock public key. The unlocking unit is used to set the device unlock status in the replay protection memory block to 1 if the verification is successful, indicating that the device has been successfully unlocked.

[0167] In one embodiment, the root partition signing public key and the device unlocking public key are upgraded independently.

[0168] In one embodiment, the digital signature algorithm includes an elliptic curve digital signature algorithm or a probabilistic signature algorithm.

[0169] In one embodiment, the message verification code algorithm in the security optimization method for unlocking the device is a hash-based message verification code algorithm or a block cipher-based message verification code algorithm.

[0170] It should be noted that the explanation of the aforementioned security optimization method embodiment for device unlocking also applies to the security optimization device for device unlocking in this embodiment, and will not be repeated here.

[0171] This invention discloses a security optimization device for device unlocking. Upon responding to a device unlocking command, it reads the unlocking key version from the root partition image file of the device's verifiable boot mechanism; generates a fixed unlocking request code based on the unlocking key version; when the device manufacturer's website receives the fixed unlocking request code, the website digitally signs the fixed unlocking request code and returns the unlocking code; the unlocking code is verified, and the device is unlocked based on the verification result. This application, by constructing a fixed unlocking request code for a single device, avoids the security risk of a weakly secure random number generator generating the same unlocking request code on different devices, thus arbitrarily unlocking the device, thereby improving security.

[0172] Furthermore, such as Figure 15 As shown, based on the above-mentioned security optimization method for unlocking devices, the present invention also provides a device, which includes a processor 10 and a memory 20. Figure 15 Only some of the components of the device are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0173] In some embodiments, memory 20 may be an internal storage unit of the terminal device, such as a hard disk or memory. In other embodiments, memory 20 may be an external storage device of the terminal device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the terminal device. Furthermore, memory 20 may include both internal and external storage units of the terminal device. Memory 20 is used to store application software and various types of data installed on the terminal device, such as program code for installing the terminal device. Memory 20 may also be used to temporarily store data that has been output or will be output. In one embodiment, memory 20 stores a device unlocking security optimization program 30, which can be executed by processor 10 to implement the device unlocking security optimization method of this application.

[0174] In some embodiments, processor 10 may be a central processing unit (CPU), microprocessor or other data processing chip, used to run program code stored in memory 20 or process data, such as executing a security optimization method for device unlocking.

[0175] In one embodiment, when the processor 10 executes the security optimization program 30 for device unlocking in the memory 20, the following steps are performed: In response to the device unlock command, read the unlock key version from the root partition image file of the device's verifiable boot mechanism; A fixed unlock request code is generated based on the unlock key version; When the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website digitally signs the fixed unlock request code and then sends out the unlock code. The unlock code is verified, and the device is unlocked based on the verification result.

[0176] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: Configure the device identity key certificate and unlock key certificate in advance in the root partition image file of the device's verifiable boot mechanism.

[0177] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: When the device restarts, it enters fastboot mode; Responding to the device unlock command, extract the device's unique key, device model, and device unique identifier; The device can read the unlock key version from the root partition image file of the boot mechanism.

[0178] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: A unique variable is generated based on the device's unique key, device model, and device unique identifier; The device model, the unlock key version, and the unique variable are concatenated into a fixed string to obtain a fixed unlock request code.

[0179] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: Use the device model and unique device identifier as input data; The HMAC-SHA256 algorithm is invoked, and the input data is signed using the device's unique key to generate a unique variable.

[0180] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: When the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website obtains the device model and the unlock key version; Locate the corresponding device unlock private key based on the device model and the unlock key version; Using a digital signature algorithm, the device's unlocking private key is used to digitally sign the fixed unlocking request code to obtain a signature value, which is then used as the unlocking code for feedback.

[0181] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: Receive a device unlock request and perform an unlock check; Read the root key hash value from the one-time programmable memory; Read the root key version, device root public key, and device model from the replay protection memory block, and obtain the concatenated hash value based on the root key version, device root public key, and device model; Determine whether the concatenated hash value is consistent with the root key hash value; If the concatenated hash value does not match the root key hash value, then unlocking will be refused.

[0182] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: Read the root key version, device root public key, and device model from the replay-protected memory block; The device model, root key version, and device root public key are concatenated in sequence into a continuous binary data, and then a hash function is input to calculate the digest to obtain the concatenated hash value.

[0183] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: If the hash value matches the root key hash value, then read the device identity key certificate from the root partition image file of the device verifiable boot mechanism. The signature of the device identity key certificate is verified using the device root public key; If the verification fails, the unlocking will be refused.

[0184] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: If the verification is successful, the device intermediate public key is read from the device identity key certificate; Read the unlock key certificate from the root partition image file of the device that verifies the boot mechanism; The signature of the unlock key certificate is verified using the device's intermediate public key; If the verification fails, the unlocking will be refused.

[0185] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: If the signature verification of the unlock key certificate using the device's intermediate public key is successful, then the device unlock public key and the unlock code are read from the unlock key certificate; The device unlocking public key is used to verify the unlocking code. If the verification is successful, the device is successfully unlocked.

[0186] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: If the signature verification of the unlock key certificate using the device's intermediate public key is successful, then the device unlock public key and the unlock code are read from the unlock key certificate; The device's public key is used to verify the unlock code. If the verification fails, unlocking is refused.

[0187] In one embodiment, when processor 10 executes security optimization procedure 30 for device unlocking in memory 20, the following steps are performed: Use the device's unlock public key to verify the unlock code; If the verification is successful, the device unlock status in the replay protection memory block will be set to 1, and the device will be successfully unlocked.

[0188] In one embodiment, the root partition signing public key and the device unlocking public key are upgraded independently of each other.

[0189] In one embodiment, the digital signature algorithm includes an elliptic curve digital signature algorithm or a probabilistic signature algorithm.

[0190] In one embodiment, the message verification code algorithm in the security optimization method for unlocking the device is a hash-based message verification code algorithm or a block cipher-based message verification code algorithm.

[0191] This embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described security optimization method for unlocking devices.

[0192] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0193] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0194] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0195] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can read and execute instructions from or in conjunction with such an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). In addition, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically by optically scanning paper or other media, then editing, interpreting or otherwise processing them as necessary, and then storing them in computer memory.

[0196] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0197] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments.

[0198] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0199] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A security optimization method for unlocking devices, characterized in that, The method includes: In response to the device unlock command, read the unlock key version from the root partition image file of the device's verifiable boot mechanism; A fixed unlock request code is generated based on the unlock key version; When the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website digitally signs the fixed unlock request code and then sends out the unlock code. The unlock code is verified, and the device is unlocked based on the verification result.

2. The security optimization method for unlocking devices according to claim 1, characterized in that, Before responding to the device unlock command and reading the unlock key version from the root partition image file that verifies the device's boot mechanism, the process also includes: Configure the device identity key certificate and unlock key certificate in advance in the root partition image file of the device's verifiable boot mechanism.

3. The security optimization method for unlocking devices according to claim 1, characterized in that, In response to the device unlock command, read the unlock key version from the root partition image file of the device's boot mechanism verification mechanism, including: When the device restarts, it enters fastboot mode; Responding to the device unlock command, extract the device's unique key, device model, and device unique identifier; The device can read the unlock key version from the root partition image file of the boot mechanism.

4. The security optimization method for unlocking devices according to claim 3, characterized in that, A fixed unlock request code is generated based on the unlock key version, including: A unique variable is generated based on the device's unique key, device model, and device unique identifier; The device model, the unlock key version, and the unique variable are concatenated into a fixed string to obtain a fixed unlock request code.

5. The security optimization method for unlocking devices according to claim 4, characterized in that, Unique variables are generated based on the device's unique key, device model, and device unique identifier, including: Use the device model and unique device identifier as input data; The HMAC-SHA256 algorithm is invoked, and the input data is signed using the device's unique key to generate a unique variable.

6. The security optimization method for unlocking devices according to claim 1, characterized in that, When the device manufacturer's website receives the fixed unlock request code, it digitally signs the fixed unlock request code and then returns an unlock code, including: When the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website obtains the device model and the unlock key version; Locate the corresponding device unlock private key based on the device model and the unlock key version; Using a digital signature algorithm, the device's unlocking private key is used to digitally sign the fixed unlocking request code to obtain a signature value, which is then used as the unlocking code for feedback.

7. The security optimization method for unlocking devices according to claim 1, characterized in that, When the device manufacturer's website receives the fixed unlock request code, after digitally signing the fixed unlock request code and returning the unlock code, the process also includes: Receive a device unlock request and perform an unlock check; Read the root key hash value from the one-time programmable memory; Read the root key version, device root public key, and device model from the replay protection memory block, and obtain the concatenated hash value based on the root key version, device root public key, and device model; Determine whether the concatenated hash value is consistent with the root key hash value; If the concatenated hash value does not match the root key hash value, then unlocking will be refused.

8. The security optimization method for unlocking devices according to claim 7, characterized in that, Read the root key version, device root public key, and device model from the replay-protected memory block, and obtain a concatenated hash value based on the root key version, device root public key, and device model, including: Read the root key version, device root public key, and device model from the replay-protected memory block; The device model, root key version, and device root public key are concatenated in sequence into a continuous binary data, and then a hash function is input to calculate the digest to obtain the concatenated hash value.

9. The security optimization method for unlocking devices according to claim 7, characterized in that, After determining whether the concatenated hash value matches the root key hash value, the process includes: If the hash value matches the root key hash value, then read the device identity key certificate from the root partition image file of the device verifiable boot mechanism. The signature of the device identity key certificate is verified using the device root public key; If the verification fails, the unlocking will be refused.

10. The security optimization method for unlocking devices according to claim 9, characterized in that, After verifying the signature of the device identity key certificate using the device root public key, the process further includes: If the verification is successful, the device intermediate public key is read from the device identity key certificate; Read the unlock key certificate from the root partition image file of the device that verifies the boot mechanism; The signature of the unlock key certificate is verified using the device's intermediate public key; If the verification fails, the unlocking will be refused.

11. The security optimization method for unlocking devices according to claim 10, characterized in that, Verify the unlock code and unlock the device based on the verification result, including: If the signature verification of the unlock key certificate using the device's intermediate public key is successful, then the device unlock public key and the unlock code are read from the unlock key certificate; The device unlocking public key is used to verify the unlocking code. If the verification is successful, the device is successfully unlocked.

12. The security optimization method for unlocking devices according to claim 11, characterized in that, Verifying the unlock code and unlocking the device based on the verification result also includes: If the signature verification of the unlock key certificate using the device's intermediate public key is successful, then the device unlock public key and the unlock code are read from the unlock key certificate; The device's public key is used to verify the unlock code. If the verification fails, unlocking is refused.

13. The security optimization method for unlocking devices according to claim 11, characterized in that, The device unlocking public key is used to verify the unlocking code. If the verification is successful, the device is successfully unlocked, including: Use the device's unlock public key to verify the unlock code; If the verification is successful, the device unlock status in the replay protection memory block will be set to 1, and the device will be successfully unlocked.

14. The security optimization method for unlocking devices according to claim 1, characterized in that, The root partition signing public key and the device unlocking public key are upgraded independently of each other.

15. The security optimization method for unlocking devices according to claim 6, characterized in that, The digital signature algorithm includes: elliptic curve digital signature algorithm or probabilistic signature algorithm.

16. The security optimization method for unlocking devices according to claim 1, characterized in that, The message verification code algorithm in the security optimization method for unlocking the device is either a hash-based message verification code algorithm or a block cipher-based message verification code algorithm.

17. A security optimization device for unlocking devices, characterized in that, The device includes: The read module is used to respond to device unlock commands and read the unlock key version in the root partition image file of the device's verifiable boot mechanism; The generation module is used to generate a fixed unlock request code based on the unlock key version; The signature module is used so that when the device manufacturer's website receives the fixed unlock request code, the device manufacturer's website digitally signs the fixed unlock request code and then sends out the unlock code. The verification module is used to verify the unlock code and unlock the device based on the verification result.

18. A device, characterized in that, include: A memory, a processor, and a device unlocking security optimization program stored on the memory and executable on the processor, wherein the device unlocking security optimization program, when executed by the processor, implements the steps of the device unlocking security optimization method as described in any one of claims 1 to 16.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that can be executed to implement the steps of the security optimization method for unlocking the device as described in any one of claims 1 to 16.

Images