Method and apparatus for mirror image verification based on dual-chain-of-trust mechanism, device, and medium

Abstract

Disclosed are a method and apparatus for mirror image verification based on a dual-chain-of-trust mechanism, a device, and a medium. The method for mirror image verification based on a dual-chain-of-trust mechanism comprises: determining a read-only file system on the basis of an original mirror image file system and target operating system verification information; constructing a signed mirror image by means of the read-only file system, a root hash value file generated on the basis of the read-only file system, a customized public key, and a signature result of a customized private key on the root hash value file, the root hash value file being obtained on the basis of a device mapper verification method of a hardware manufacturer chain-of-trust mechanism, and the customized public key being stored in a one-time programmable region; performing a target operation on the customized public key to obtain a first encrypted value, writing the first encrypted value into a verified mirror image, and burning the signed mirror image into a device flash memory; after the device is powered on, mounting the signed mirror image on the basis of a startup script of the started verified mirror image, and performing a target operation on the customized public key in the signed mirror image to obtain a second encrypted value; and if the first encrypted value is the same as the second encrypted value, verifying the root hash value file on the basis of the customized public key and the signature result, and if the verification passes, implementing verified boot of the target operating system by means of the root hash value file, so as to ensure the reliability of the chain-of-trust mechanism of the target operating system.

Description

Mirror verification method, device, equipment and medium based on dual trust chain mechanism

[0001] Citation of relevant applications

[0002] This disclosure claims the entire benefits of Chinese invention patent application No. 202411748961.0, filed on November 29, 2024, with the State Intellectual Property Office of the People's Republic of China, entitled "A Mirror Verification Method, Apparatus, Device and Medium Based on a Dual Trust Chain Mechanism", the entire contents of which are incorporated herein by reference.

[0003] field

[0004] This disclosure generally relates to the field of computer technology, and more specifically to a mirror verification method, apparatus, device, and medium based on a dual-trust chain mechanism.

[0005] background

[0006] In the trust chain mechanism of hardware manufacturers, an interface is provided to customers to generate key pairs. These generated key pairs are stored in a One-Time Password (OTP) area, and are therefore considered trustworthy. However, the AVB (Android Verified Boot) public key is stored in flash memory, posing a potential risk of leakage and potentially rendering the image unreliable. Furthermore, some hardware manufacturers' OTPs do not support the AVB public key format, making it impossible to combine the hardware manufacturer's trust chain mechanism with the AVB public key for image verification.

[0007] Overview

[0008] Firstly, this disclosure provides a mirror verification method based on a dual-trust chain mechanism, which includes:

[0009] Determine the read-only file system based on the original image file system and the target operating system verification information;

[0010] A signature image is constructed by signing the root hash value file using the read-only file system, the root hash value file generated based on the read-only file system, a customized public key, and a customized private key; the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, and the customized public key is stored in a one-time programmable area;

[0011] Perform target operations on the customized public key to obtain a first encrypted value, write the first encrypted value into the verified image, and burn the signed image into the device flash memory;

[0012] After the device is powered on, the signature image is mounted according to the startup script of the verified image that has been started, and the customized public key in the signature image is subjected to target operation to obtain the second encrypted value.

[0013] If the first encrypted value is the same as the second encrypted value, the root hash value file is verified according to the customized public key and the signature result. If the verification passes, the target operating system is verified and started through the root hash value file to ensure the reliability of the target operating system's trust chain mechanism.

[0014] In some implementations, constructing a signature image using the signature result of the root hash value file generated based on the read-only file system, a customized public key, and a customized private key includes:

[0015] The first volume is determined based on the read-only file system, the second volume is determined based on the root hash value file generated based on the read-only file system, the third volume is determined based on the signature result of the root hash value file using the customized private key, and the fourth volume is determined based on the customized public key.

[0016] A signature mirror is constructed using the first volume, the second volume, the third volume, and the fourth volume.

[0017] In some implementations, the step of verifying the root hash file based on the customized public key and the signature result if the first encrypted value is the same as the second encrypted value includes:

[0018] If the first encrypted value is the same as the second encrypted value, then the customized public key in the signature image is a trusted public key, and the calculation result is obtained based on the customized public key and the root hash value file;

[0019] If the calculation result matches the signature result, the verification passes;

[0020] If the calculation result does not match the signature result, the verification fails.

[0021] In some implementations, obtaining the calculation result based on the customized public key and the root hash file includes:

[0022] The customized public key, the root hash file, and the signature result are used as input parameters to the target command-line toolkit, and the return value is output according to the target command-line toolkit.

[0023] If the return value is the first value, then the operation result matches the signature result;

[0024] If the return value is the second value, then the calculation result does not match the signature result.

[0025] In some implementations, the target operation includes generating a hash value of the customized public key, and performing preprocessing and target iterative operation on the hash value of the customized public key based on a message digest algorithm.

[0026] In some implementations, mounting the signed image according to the startup script of the already started verified image includes:

[0027] The verified image is started according to the device mapper verification method of the hardware manufacturer's trust chain mechanism, and the signed image is mounted according to the startup script of the verified image.

[0028] In some implementations, after determining the read-only file system based on the original image file system and the target operating system verification information, the method further includes:

[0029] Based on the target operating system verification information, the original image file system is divided into multiple data blocks of target size, and a hash operation is performed on the data blocks to obtain the hash value of each data block; and

[0030] The hash value of each data block is determined as a leaf node, and the hash values ​​of every two adjacent data blocks are combined according to the format of a hash binary tree to obtain the root hash value file.

[0031] Secondly, this disclosure provides a mirror verification device based on a dual-trust chain mechanism, which includes:

[0032] The read-only file system determination module is configured to determine the read-only file system based on the original image file system and the target operating system verification information.

[0033] The image building module is configured to build a signed image using the read-only file system, the root hash value file generated based on the read-only file system, a customized public key, and a customized private key to sign the root hash value file; the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, and the customized public key is stored in a one-time programmable area;

[0034] The image burning module is configured to perform target operations on the customized public key to obtain a first encrypted value, write the first encrypted value into the verified image, and burn the signed image into the device flash memory;

[0035] The image mounting module is configured to, upon device power-on, mount the signed image according to the startup script of the already started verified image, perform target operations on the customized public key in the signed image, and obtain a second encrypted value; and

[0036] The image verification module is configured to verify the root hash value file based on the customized public key and the signature result if the first encrypted value is the same as the second encrypted value. If the verification passes, the target operating system is verified and started through the root hash value file to ensure the reliability of the target operating system's trust chain mechanism.

[0037] Thirdly, this disclosure provides an electronic device comprising:

[0038] Memory, configured to store computer programs;

[0039] A processor is configured to execute the computer program to implement the mirror verification method based on a dual trust chain mechanism as described in this disclosure.

[0040] Fourthly, this disclosure provides a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the mirror verification method based on a dual trust chain mechanism as described in this disclosure.

[0041] In some implementations, a first encrypted value is calculated before the customized public key is burned into the flash memory, and a second encrypted value is calculated after the customized public key is burned into the flash memory. Since there is a risk of tampering after the customized public key is burned into the flash memory, this disclosure determines the reliability of the customized public key in the flash memory based on the comparison result of the first encrypted value and the second encrypted value. After determining that the customized public key is a reliable public key, the root hash value file is verified based on the customized public key and the signature result to ensure the reliability of the root hash value file. Finally, the target operating system is verified and started based on the root hash value file to ensure the reliability of the target operating system's trust chain mechanism. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, this disclosure verifies the reliability of the root hash value file based on the hardware manufacturer's trust chain mechanism, and then ensures the reliability of the target operating system's trust chain mechanism based on the root hash value file, thus realizing a verification scheme compatible with dual trust chain mechanisms. In addition, this disclosure uses two trust chains to support their respective key pairs, solving the problem that some hardware manufacturers' OTPs do not support the AVB public key format.

[0042] Brief description of the attached figures

[0043] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0044] Figure 1 is a flowchart of a mirror verification method based on a dual trust chain mechanism according to an embodiment of this disclosure;

[0045] Figure 2 is a signature diagram according to an embodiment of the present disclosure;

[0046] Figure 3 is a flowchart of mounting a signature image according to an embodiment of this disclosure;

[0047] Figure 4 is a schematic diagram of a mirror verification device based on a dual-trust chain mechanism according to an embodiment of this disclosure; and

[0048] Figure 5 is a structural diagram of an electronic device according to an embodiment of the present disclosure.

[0049] Detailed Explanation

[0050] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0051] In the trust chain mechanism of hardware manufacturers, an interface is provided to customers to generate key pairs. These generated key pairs are stored in a One-Time Password (OTP) area, and are therefore considered trustworthy. However, the AVB (Android Verified Boot) public key is stored in flash memory, posing a potential risk of leakage and potentially rendering the image unreliable. Furthermore, some hardware manufacturers' OTPs do not support the AVB public key format, making it impossible to combine the hardware manufacturer's trust chain mechanism with the AVB public key for image verification.

[0052] To address this issue, this disclosure proposes an image verification method based on a dual-trust chain mechanism, which enables verification using the dual-trust chain mechanism and solves the problem that hardware manufacturers' OTP does not support the AVB public key format.

[0053] This disclosure provides an embodiment of a mirror verification method based on a dual-trust chain mechanism. Referring to Figure 1, the method includes:

[0054] Step S11: Determine the read-only file system based on the original image file system and the target operating system verification information;

[0055] Step S12: Construct a signature image using the signature result of the root hash value file on the read-only file system, the root hash value file generated based on the read-only file system, the customized public key, and the customized private key; the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, and the customized public key is stored in a one-time programmable area;

[0056] Step S13: Perform target operation on the customized public key to obtain the first encrypted value, write the first encrypted value into the verified image, and burn the signature image into the device flash memory;

[0057] Step S14: After the device is powered on, the signed image is mounted according to the startup script of the verified image that has been started, and the customized public key in the signed image is subjected to target operation to obtain the second encrypted value; and

[0058] Step S15: If the first encrypted value is the same as the second encrypted value, then the root hash value file is verified according to the customized public key and the signature result. If the verification passes, the target operating system is verified and started through the root hash value file to ensure the reliability of the target operating system's trust chain mechanism.

[0059] In some implementations, the original image file system is a raw, insecure file system, the target operating system is the Android system, and the target operating system verification information is the Android verification boot footer (AVB footer). The footer contains the necessary parameters for Android verification boot, such as the data block size for partitioning the original image file system.

[0060] Referring to Figure 2, in this embodiment, the first volume is determined based on the read-only file system, the second volume is determined based on the root hash value file generated based on the read-only file system, the third volume is determined based on the signature result of the root hash value file using the customized private key, the fourth volume is determined based on the customized public key, and a signed image in UBI (Unsorted Block Images) format is constructed through the first volume, the second volume, the third volume, and the fourth volume.

[0061] In some implementations, the process of determining the root hash file involves using a device mapper verification method based on the hardware vendor's trust chain mechanism (DM-Verity format image). This method divides the original image file system into multiple data blocks of a target size (e.g., 4KB) based on the target operating system verification information. The data blocks are then hashed to obtain their hash values. Each data block's hash value is then used as a leaf node, and the hash values ​​of every two adjacent data blocks are combined according to a hash binary tree format to obtain the root hash file.

[0062] In some implementations, a target operation is performed on the customized public key to obtain a first encrypted value, and the first encrypted value is written into the verified image, and the signed image is burned into the device flash memory.

[0063] In some implementations, the target operation includes generating a hash value for a customized public key, performing preprocessing on the hash value of the customized public key based on a message digest algorithm, and then performing a target iterative operation. The message digest algorithm includes MD5 (Message-Digest Algorithm 5).

[0064] In some implementations, the first encrypted value is written to a file in a fixed path of the read-only partition in the verified image, and the signed image is burned to the device flash memory. Since the verified image is a secure and reliable image, and the file in the fixed path of the read-only partition is read-only and not write-only, this embodiment saves the first encrypted value to the verified image, which can ensure the reliability of the first encrypted value. In addition, since the signed image in the flash memory is easily tampered with, this embodiment needs to verify the signed image in the flash memory based on the first encrypted value.

[0065] In some implementations, after the device is powered on, the verified image is launched according to the device mapper verification method of the hardware vendor's trust chain mechanism, and the signed image is mounted according to the startup script of the verified image. To improve startup speed, the verified image in this embodiment can be launched solely based on the Android operating system's trust chain mechanism.

[0066] In some implementations, since the signature image in the flash memory is easily tampered with, this embodiment requires that the customized public key in the signature image be subjected to target operation again to obtain the second encrypted value.

[0067] In some implementations, if the first encrypted value is the same as the second encrypted value, then the customized public key in the signature image is a trusted public key, and the calculation result is obtained based on the customized public key and the root hash value file. On the one hand, if the calculation result matches the signature result, the verification passes; on the other hand, if the calculation result does not match the signature result, the verification fails.

[0068] As a specific method for obtaining the calculation result based on the customized public key and the root hash value file, this embodiment can use the customized public key, the root hash value file and the signature result as input parameters of the target command line toolkit (openssl), and output the return value according to the target command line toolkit. On the one hand, if the return value is the first value, the calculation result matches the signature result; if the return value is the second value, the calculation result does not match the signature result.

[0069] As the foregoing analysis shows, this embodiment has verified the reliability of the customized public key in Volume 4. The signature result in Volume 3 is obtained by signing the root hash file using the customized private key corresponding to the customized public key. Therefore, this embodiment now needs to match the calculation result of the customized public key in Volume 4 and the root hash file in Volume 2 with the signature result in Volume 3. If they match, the root hash file passes verification; otherwise, it fails verification. For example, this embodiment can use the root hash file, the customized public key, and the signature result as input parameters to OpenSSL. If the return value is 1, the calculation result matches the signature result, and the root hash file passes verification. If the return value is 0, the calculation result does not match the signature result, and the root hash file fails verification.

[0070] In some implementations, if the root hash file verification passes, the target operating system is verified and booted using the root hash file. Since the root hash file is obtained using a device mapper verification method based on a hardware vendor trust chain mechanism, the reliability of the root hash file is verified based on the hardware vendor trust chain mechanism, and then the reliability of the target operating system trust chain mechanism is guaranteed based on the root hash file, thus achieving a verification scheme compatible with dual trust chain mechanisms. That is, the first trust chain in this disclosure is a hardware vendor trust chain based on an OTP key, and the second trust chain is the target operating system trust chain. Because the hardware vendor trust chain based on the OTP key is reliable, this disclosure guarantees the reliability of the root hash file in the flash memory based on the reliability of the hardware vendor trust chain, and further guarantees the reliability of the target operating system trust chain mechanism through the reliability of the root hash file, thus achieving a verification scheme compatible with dual trust chain mechanisms.

[0071] In summary, this embodiment first signs the original insecure image to obtain a data image format that meets the verification requirements. Further, after the device powers on and starts, it executes the hardware vendor's trust chain mechanism until it reaches the rootfs (i.e., the image preceding the signed image). It then mounts the customized partition image OEMAPP (a storage partition image file generated after customization according to specific needs, i.e., the signed image in this embodiment) containing the customer's customized application. When mounting OEMAPP, this embodiment first uses OpenSSL to operate on the fourth volume to obtain a second encrypted value. This encrypted value is compared with the first encrypted value pre-stored in the trusted partition of the rootfs. If the comparison fails, the system exits abnormally; if the comparison succeeds, it proves that the customized public key in the fourth volume is a trusted public key. The customized public key is then used to perform calculations on the root hash value file and matched with the signature value of the third volume. If they match, the verification passes. The root_hash is then used as an input parameter to participate in the Android verification startup verification, achieving a verification scheme compatible with the dual trust chain mechanism.

[0072] Figure 3 illustrates the flowchart for mounting the OEMAPP. Specifically, it includes: 1. After the system process ends, the little kernel transforms into the production operating system, and systemd starts the fibo_ubi_mount process; 2. ubiattach attaches the ubi device to the MTD device; 3. ubiblock creates a read-only block device; 4. openssl obtains the root certificate hash value; 5. openssl verifies the signed volume; 6. verity-boot creates a devicemapper device; 7. veritysetup creates the device; 8. mount mounts the OEMAPP image to the mapper device. In some embodiments, the configuration of the OEMAPP certificate hash first involves decompressing the sysfs.squash file in the unsigned folder based on the dm_tool script, obtaining the OTP public key hash value, calculating the MD5 value, saving it to a specified path, and then recreating the rootfs. In some embodiments, for the configuration of the OEMAPP certificate hash, the unsigned.tar.gz image to be signed is first extracted to the signing tool folder, forming the unsigned image folder, and then / sign_images.sh -s fibocom is obtained.

[0073] In summary, this disclosure, based on the trust chain mechanism of the front-end hardware vendor (OTP) and the front-end image, relies on a redesigned boot verification and signing process from rootfs to the customized image OEMAPP. By optimizing the signing and verification data structure and the amount of signing and verification data, it achieves the effect of ensuring verification reliability and meeting performance requirements through AVB+OTP dual-key trust chain verification. Furthermore, this disclosure minimizes the verification amount of the data signing and verification steps while ensuring reliability, reducing verification and signing time and improving signing efficiency.

[0074] In some implementations, a first encrypted value is calculated before the customized public key is burned into the flash memory, and a second encrypted value is calculated after the customized public key is burned into the flash memory. Since there is a risk of tampering after the customized public key is burned into the flash memory, this disclosure determines the reliability of the customized public key in the flash memory based on the comparison result of the first encrypted value and the second encrypted value. After determining that the customized public key is a reliable public key, the root hash value file is verified based on the customized public key and the signature result to ensure the reliability of the root hash value file. Finally, the target operating system is verified and started based on the root hash value file to ensure the reliability of the target operating system's trust chain mechanism. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, this disclosure verifies the reliability of the root hash value file based on the hardware manufacturer's trust chain mechanism, and then ensures the reliability of the target operating system's trust chain mechanism based on the root hash value file, thus realizing a verification scheme compatible with dual trust chain mechanisms. In addition, this disclosure uses two trust chains to support their respective key pairs, solving the problem that some hardware manufacturers' OTPs do not support the AVB public key format.

[0075] An embodiment of this disclosure also provides a mirror verification device based on a dual-trust chain mechanism, as shown in Figure 4. The device includes:

[0076] The read-only file system determination module 11 is configured to determine the read-only file system based on the original image file system and the target operating system verification information.

[0077] The image building module 12 is configured to build a signed image using the read-only file system, the root hash value file generated based on the read-only file system, a customized public key, and a customized private key to sign the root hash value file; the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, and the customized public key is stored in a one-time programmable area;

[0078] The image burning module 13 is configured to perform target operations on the customized public key to obtain a first encrypted value, write the first encrypted value into the verified image, and burn the signed image into the device flash memory;

[0079] The image mounting module 14 is configured to, upon device power-on, mount the signed image according to the startup script of the already started verified image, perform target operations on the customized public key in the signed image, and obtain a second encrypted value; and

[0080] The image verification module 15 is configured to verify the root hash value file based on the customized public key and the signature result if the first encrypted value is the same as the second encrypted value. If the verification passes, the target operating system is verified and started through the root hash value file to ensure the reliability of the target operating system's trust chain mechanism.

[0081] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0082] In some implementations, a first encrypted value is calculated before the customized public key is burned into the flash memory, and a second encrypted value is calculated after the customized public key is burned into the flash memory. Since there is a risk of tampering after the customized public key is burned into the flash memory, this disclosure determines the reliability of the customized public key in the flash memory based on the comparison result of the first encrypted value and the second encrypted value. After determining that the customized public key is a reliable public key, the root hash value file is verified based on the customized public key and the signature result to ensure the reliability of the root hash value file. Finally, the target operating system is verified and started based on the root hash value file to ensure the reliability of the target operating system's trust chain mechanism. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, this disclosure verifies the reliability of the root hash value file based on the hardware manufacturer's trust chain mechanism, and then ensures the reliability of the target operating system's trust chain mechanism based on the root hash value file, thus realizing a verification scheme compatible with dual trust chain mechanisms. In addition, this disclosure uses two trust chains to support their respective key pairs, solving the problem that some hardware manufacturers' OTPs do not support the AVB public key format.

[0083] This disclosure also provides an electronic device according to one embodiment. FIG5 is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content of the figure should not be construed as limiting the scope of use of this disclosure.

[0084] Figure 5 is a schematic diagram of the structure of an electronic device 20 according to an embodiment of this disclosure. The electronic device 20 may include: at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the mirror verification method based on a dual-trust chain mechanism described in this disclosure. In some embodiments, the electronic device 20 in this embodiment may be a computer.

[0085] In some implementations, power supply 26 is configured to provide operating voltage to various hardware devices on electronic device 20; communication interface 25 can create a data transmission channel between electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this disclosure, without specific limitation; input / output interface 24 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, without specific limitation.

[0086] In some embodiments, the memory 22 serves as a carrier for resource storage and may be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon may include computer programs 221, and the storage method may be temporary storage or permanent storage. In some embodiments, in addition to including a computer program capable of performing the mirror verification method based on the dual trust chain mechanism executed by the electronic device 20 of this disclosure, the computer program 221 may further include computer programs capable of performing other specific tasks.

[0087] An embodiment of this disclosure also provides a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the mirror verification method based on a dual trust chain mechanism of this disclosure.

[0088] For the specific steps of this method, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0089] The various embodiments in this disclosure are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. As for the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method section.

[0090] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0091] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0092] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0093] The foregoing has provided a detailed description of a mirror verification method, apparatus, device, and storage medium based on a dual trust chain mechanism. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the above embodiments are only for the purpose of helping to understand the method and its core ideas. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this disclosure. Therefore, the content of this specification should not be construed as a limitation of this disclosure.

Claims

1. A mirror verification method based on a dual-trust chain mechanism, comprising: Determine the read-only file system based on the original image file system and the target operating system verification information; A signature image is constructed by using the signature result of the root hash value file on the read-only file system, the root hash value file generated based on the read-only file system, the customized public key, and the customized private key; The root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, and the customized public key is stored in a one-time programmable area; Perform target operations on the customized public key to obtain a first encrypted value, write the first encrypted value into the verified image, and burn the signed image into the device flash memory; After the device is powered on, the signature image is mounted according to the startup script of the verified image that has been started, and the customized public key in the signature image is subjected to target operation to obtain the second encrypted value. If the first encrypted value is the same as the second encrypted value, the root hash value file is verified according to the customized public key and the signature result. If the verification passes, the target operating system is verified and started through the root hash value file to ensure the reliability of the target operating system's trust chain mechanism.

2. The mirror verification method based on a dual-trust chain mechanism as described in claim 1, wherein constructing a signed mirror using the signature result of the root hash value file generated by the read-only file system, a root hash value file generated based on the read-only file system, a customized public key, and a customized private key includes: The first volume is determined based on the read-only file system, the second volume is determined based on the root hash value file generated based on the read-only file system, the third volume is determined based on the signature result of the root hash value file using the customized private key, and the fourth volume is determined based on the customized public key. as well as A signature mirror is constructed using the first volume, the second volume, the third volume, and the fourth volume.

3. The mirror verification method based on a dual-trust chain mechanism as described in claim 1 or 2, wherein if the first encrypted value is the same as the second encrypted value, the root hash value file is verified according to the customized public key and the signature result, including: If the first encrypted value is the same as the second encrypted value, then the customized public key in the signature image is a trusted public key, and the calculation result is obtained based on the customized public key and the root hash value file; If the calculation result matches the signature result, the verification passes; If the calculation result does not match the signature result, the verification fails.

4. The mirror verification method based on a dual-trust chain mechanism as described in claim 3, wherein obtaining the calculation result based on the customized public key and the root hash value file includes: The customized public key, the root hash file, and the signature result are used as input parameters to the target command-line toolkit, and the return value is output according to the target command-line toolkit. If the return value is the first value, then the operation result matches the signature result; If the return value is the second value, then the calculation result does not match the signature result.

5. The mirror verification method based on a dual trust chain mechanism as described in any one of claims 1 to 4, wherein the target operation includes generating the hash value of the customized public key, and performing preprocessing and target iterative operation on the hash value of the customized public key based on a message digest algorithm.

6. The image verification method based on a dual-trust chain mechanism as described in any one of claims 1 to 5, wherein mounting the signed image according to the startup script of the already started verified image includes: The verified image is started according to the device mapper verification method of the hardware manufacturer's trust chain mechanism, and the signed image is mounted according to the startup script of the verified image.

7. The image verification method based on a dual-trust chain mechanism as described in any one of claims 1 to 6, wherein after determining the read-only file system based on the verification information of the original image file system and the target operating system, it further includes: Based on the target operating system verification information, the original image file system is divided into multiple data blocks of target size, and a hash operation is performed on the data blocks to obtain the hash value of the data blocks; The hash value of each data block is determined as a leaf node, and the hash values ​​of every two adjacent data blocks are combined according to the format of a hash binary tree to obtain the root hash value file.

8. A mirror verification device based on a dual-trust chain mechanism, comprising: The read-only file system determination module is configured to determine the read-only file system based on the original image file system and the target operating system verification information. The image building module is configured to build a signed image using the read-only file system, the root hash value file generated based on the read-only file system, a customized public key, and a customized private key to sign the root hash value file; The root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, and the customized public key is stored in a one-time programmable area; The image burning module is configured to perform target operations on the customized public key to obtain a first encrypted value, write the first encrypted value into the verified image, and burn the signed image into the device flash memory; The image mounting module is configured to mount the signed image according to the startup script of the verified image after the device is powered on, and perform target operation on the customized public key in the signed image to obtain a second encrypted value. as well as The image verification module is configured to verify the root hash value file based on the customized public key and the signature result if the first encrypted value is the same as the second encrypted value. If the verification passes, the target operating system is verified and started through the root hash value file to ensure the reliability of the target operating system's trust chain mechanism.

9. Electronic equipment, including: Memory, used to store computer programs; A processor for executing the computer program to implement the mirror verification method based on a dual trust chain mechanism as described in any one of claims 1 to 7.

10. A computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the mirror verification method based on a dual trust chain mechanism as described in any one of claims 1 to 7.

Images