Mirror image verification method and device based on double-trust-chain mechanism, equipment and medium

Abstract

The invention discloses a mirror image verification method and device based on a double-trust-chain mechanism, equipment and a medium, and relates to the technical field of computers, and the method comprises the following steps: determining a read-only file system according to verification information of an original mirror image file system and a target operating system; constructing a signature mirror image for the signature result of the root hash value file based on the root hash value file, the customized public key and the customized private key generated by the read-only file system through the read-only file system; the customized public key is stored in the OTP, a first encryption value for operating the customized public key is written into the verified mirror image, and the signature mirror image is burnt to the equipment flash memory; performing operation on the customized public key in the signature mirror image to obtain a second encryption value; if the two encryption values are the same, the root hash value file is verified according to the customized public key and the signature result, verification starting of the target operating system is achieved through the root hash value file if verification passes, and the problem that OTP of a hardware manufacturer does not support the AVB public key format is solved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a mirror verification method, device, equipment and medium based on a dual trust chain mechanism. Background Art

[0002] In the hardware manufacturer's trust chain mechanism, an interface is provided to customers to generate a key pair, and the key pair generated using the interface is saved in the One-Time Password (OTP) area. Therefore, the key pair is considered to be credible, while the AVB (Android Verified Boot) public key is stored in the flash memory, which may be leaked, so the image may become unreliable. In addition, the OTP of some hardware manufacturers does not support the format of the AVB public key, so it is impossible to combine the hardware manufacturer's trust chain mechanism with the AVB public key to implement image verification. Summary of the invention

[0003] In view of this, the purpose of the present invention is to provide an image verification method, device, equipment and medium based on a dual trust chain mechanism, which can realize dual trust chain mechanism compatible verification and solve the problem that the OTP of the hardware manufacturer does not support the AVB public key format. The specific scheme is as follows:

[0004] In a first aspect, the present application discloses an image verification method based on a dual trust chain mechanism, comprising:

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

[0006] A signature image is constructed by using 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 to sign the root hash value file; the root hash value file is obtained based on a device mapper verification method of a hardware manufacturer's trust chain mechanism, and the customized public key is stored in a one-time programmable area;

[0007] Performing a target operation on the customized public key to obtain a first encrypted value, writing the first encrypted value into the verified image, and burning the signed image into the device flash memory;

[0008] 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 a target operation is performed on the customized public key in the signed image to obtain a second encrypted value;

[0009] If the first encryption value is the same as the second encryption 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.

[0010] Optionally, the step of constructing a signed image by using 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 to sign the root hash value file includes:

[0011] Determine a first volume according to the read-only file system, determine a second volume according to the root hash value file generated based on the read-only file system, determine a third volume according to a signature result of the root hash value file using the customized private key, and determine a fourth volume according to the customized public key;

[0012] A signed image is constructed by using the first volume, the second volume, the third volume, and the fourth volume.

[0013] Optionally, if the first encrypted value is the same as the second encrypted value, verifying the root hash value file according to the customized public key and the signature result includes:

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

[0015] If the operation result matches the signature result, the verification passes;

[0016] If the operation result does not match the signature result, the verification fails.

[0017] Optionally, obtaining a calculation result based on the customized public key and the root hash value file includes:

[0018] Using the customized public key, the root hash value file and the signature result as input parameters of a target command line tool set, and outputting a return value according to the target command line tool set;

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

[0020] If the return value is the second value, the operation result does not match the signature result.

[0021] Optionally, the target operation includes generating a hash value of the customized public key, and performing padding preprocessing and target iteration operation on the hash value of the customized public key based on a message digest algorithm.

[0022] Optionally, mounting the signed image according to the startup script of the started verified image includes:

[0023] 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.

[0024] Optionally, after determining the read-only file system according to the original image file system and the target operating system verification information, the method further includes:

[0025] Dividing the original image file system into a plurality of data blocks of a target size based on the target operating system verification information, and performing a hash operation on the data blocks to obtain hash values ​​of the data blocks;

[0026] 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.

[0027] In a second aspect, the present application discloses an image verification device based on a dual trust chain mechanism, comprising:

[0028] A read-only file system determination module, used to determine the read-only file system according to the original image file system and the target operating system verification information;

[0029] An image building module, used to build a signed image through 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 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;

[0030] An image burning module, used for performing a target operation on the customized public key to obtain a first encrypted value, writing the first encrypted value into a verified image, and burning the signed image into a device flash memory;

[0031] An image mounting module, used for mounting the signed image according to the startup script of the started verified image after the device is powered on, performing a target operation on the customized public key in the signed image to obtain a second encrypted value;

[0032] The image verification module is used to verify the root hash value file according to the customized public key and the signature result if the first encryption value is the same as the second encryption 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 trust chain mechanism of the target operating system.

[0033] In a third aspect, the present application discloses an electronic device, comprising:

[0034] Memory, used to store computer programs;

[0035] The processor is used to execute the computer program to implement the aforementioned disclosed image verification method based on the dual trust chain mechanism.

[0036] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the image verification method based on the dual trust chain mechanism disclosed above is implemented.

[0037] It can be seen that the present application proposes an image verification method based on a dual trust chain mechanism, including: determining a read-only file system according to the original image file system and the target operating system verification information; constructing a signed image by signing the root hash value file based 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; performing a target operation on the customized public key to obtain a first encryption value, and writing the first encryption value into the verified image, and burning the signed image to the device flash memory; 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 performed on the target operation to obtain a second encryption value; if the first encryption value is the same as the second encryption value, the root hash value file is verified according to the customized public key and the signature result, and if the verification passes, the verification startup of the target operating system is realized through the root hash value file to ensure the reliability of the trust chain mechanism of the target operating system.

[0038] In summary, the present application calculates the first encryption value before burning the customized public key into the flash memory, and calculates the second encryption value after burning the customized public key into the flash memory. Since there is a risk of tampering after the customized public key is burned into the flash memory, the present application determines the reliability of the customized public key in the flash memory based on the comparison result of the first encryption value and the second encryption 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 verification startup of the target operating system is implemented based on the root hash value file to ensure the reliability of the trust chain mechanism of the target operating system. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, the present application 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 trust chain mechanism of the target operating system based on the root hash value file, thereby realizing a verification scheme compatible with dual trust chain mechanisms. In addition, the present application uses two trust chains to support their respective key pairs, which solves the problem that the OTP of some hardware manufacturers does not support the format of the AVB public key. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0040] Figure 1 A flow chart of an image verification method based on a dual trust chain mechanism disclosed in this application;

[0041] Figure 2 A signature schematic diagram disclosed in this application;

[0042] Figure 3 A flowchart of mounting a signed image disclosed in this application;

[0043] Figure 4 This is a schematic diagram of the structure of an image verification device based on a dual trust chain mechanism disclosed in this application;

[0044] Figure 5 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0045] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0046] In the hardware manufacturer's trust chain mechanism, an interface is provided to customers to generate a key pair, and the key pair generated using the interface is saved in the One-Time Password (OTP) area. Therefore, the key pair is considered to be credible, while the AVB (Android Verified Boot) public key is stored in the flash memory, which may be leaked, so the image may become unreliable. In addition, the OTP of some hardware manufacturers does not support the format of the AVB public key, so it is impossible to combine the hardware manufacturer's trust chain mechanism with the AVB public key to implement image verification.

[0047] To this end, the embodiment of the present application proposes a mirror verification method based on a dual trust chain mechanism to implement the verification of the dual trust chain mechanism and solve the problem that the hardware manufacturer's OTP does not support the AVB public key format.

[0048] The present application embodiment discloses a mirror verification method based on a dual trust chain mechanism, see Figure 1 As shown, the method includes:

[0049] Step S11: Determine the read-only file system according to the original image file system and the target operating system verification information.

[0050] The original image file system is an original non-secure 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 necessary parameters in the Android verification boot, such as the data block size for dividing the original image file system into blocks.

[0051] Step S12: construct a signature image through 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 to the signature result of 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.

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

[0053] In the process of determining the root hash value file, the original image file system is divided into multiple data blocks of a target size (for example, 4k) based on the target operating system verification information through the device mapper verification method (DM-Verity format image) of the hardware manufacturer's trust chain mechanism, and a hash operation is performed on the data block to obtain the hash value of the data block, and then 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 in the format of a hash binary tree to obtain the root hash value file.

[0054] Step S13: Perform a target operation 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.

[0055] In this embodiment, 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.

[0056] In one embodiment, the target operation includes generating a hash value of a customized public key, performing padding preprocessing and target iteration operation on the hash value of the customized public key based on a message digest algorithm, wherein the message digest algorithm includes md5 (Message-Digest Algorithm 5).

[0057] Furthermore, the first encrypted value is written to a file with a fixed path in the read-only partition of the verified image, and the signed image is burned to the device flash memory. Since the verified image is a safe and reliable image, and the file with a fixed path in the read-only partition is read-only and not writable, 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.

[0058] Step S14: After the device is powered on, the signed image is mounted according to the startup script of the started verified image, and a target operation is performed on the customized public key in the signed image to obtain a second encrypted value.

[0059] After the device is powered on, 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. In order to improve the startup speed, the verified image in this embodiment can be started only based on the Android operating system trust chain mechanism.

[0060] It should be noted that, since the signature image in the flash memory is easily tampered with, the present embodiment needs to perform a target operation on the customized public key in the signature image again to obtain a second encrypted value.

[0061] Step S15: If the first encryption value is the same as the second encryption 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 trust chain mechanism of the target operating system.

[0062] In this embodiment, if the first encryption value is the same as the second encryption value, the customized public key in the signature image is a trusted public key, and a 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.

[0063] As a specific method of obtaining a 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 toolset (openssl), and output a return value according to the target command line toolset. On the one hand, if the return value is a first value, the calculation result matches the signature result, and if the return value is a second value, the calculation result does not match the signature result.

[0064] From the above analysis, it can be seen that this embodiment has verified the reliability of the customized public key in the fourth volume, and the signature result in the third volume is obtained by signing the root hash value file using the customized private key corresponding to the customized public key. Therefore, this embodiment currently needs to match the operation result based on the customized public key in the fourth volume and the root hash value file in the second volume with the signature result in the third volume. If they match, it proves that the root hash value file has passed the verification. Otherwise, it has not passed the verification. Exemplarily, this embodiment can use the root hash value file, the customized public key / and the signature result as the input parameters of openssl. If the return value is 1, the operation result matches the signature result and the root hash value file passes the verification. If the return value is 0, the operation result does not match the signature result and the root hash value file has not passed the verification.

[0065] In this embodiment, if the root hash value file passes the verification, the verification startup of the target operating system is realized through the root hash value file. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, the reliability of the root hash value file is verified based on the hardware manufacturer's trust chain mechanism, and then the reliability of the target operating system's trust chain mechanism is guaranteed based on the root hash value file, thereby realizing a verification scheme compatible with dual trust chain mechanisms. That is, the first trust chain in this application is the hardware manufacturer's trust chain based on the OTP key, and the second trust chain is the target operating system's trust chain. Since the hardware manufacturer's trust chain based on the OTP key is reliable, this application guarantees the reliability of the root hash value file in the flash memory based on the reliability of the hardware manufacturer's trust chain, and further guarantees the reliability of the target operating system's trust chain mechanism through the reliability of the root hash value file, thereby realizing a verification scheme compatible with dual trust chain mechanisms.

[0066] From the above, it can be seen that the present embodiment first signs the original non-secure image to obtain a data image format that meets the verification requirements. Further, after the device is powered on and started, the hardware manufacturer's trust chain mechanism is executed until the rootfs (that is, the previous image of the signed image) is executed, and the customized partition image oemapp stored by the customer's customized application is mounted (the image file of the storage partition generated after customized processing according to specific requirements, that is, the signed image in the present embodiment). When mounting oemapp, the present embodiment first uses openssl to operate the fourth volume to obtain the second encrypted value, and compares the encrypted value with the first encrypted value pre-stored in the trusted partition of 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, and uses the customized public key to operate the root hash value file to match it with the signature value of the third volume. If they match, the verification passes, and root_hash is used as an input parameter to participate in the Android verification startup verification, thereby realizing a verification scheme compatible with the dual trust chain mechanism.

[0067] Figure 3 A flowchart for mounting OEMApp is disclosed, see Figure 3As shown, specifically including: 1. After the system ends, the little kernel will be converted into a formal operating system, and systemd will start the fibo_ubi_mount process; 2. ubiattach attaches the ubi device to the mtd device; 3. Call ubiblock to create a read-only block device; 4. Call openssl to obtain the root certificate hash value; 5. Call openssl to verify the signed volume; 6. Call verity-boot to create a devicemapper device; 7. Call veritysetup to create a device; 8. Call mount to mount the oemapp image to the mapper device. In some embodiments, for the configuration of the oemapp certificate Hash, firstly, based on the dm_tool script, the sysfs.squash file in the unsigned folder is decompressed, and the OTP public key Hash value is obtained, the MD5 value is calculated, saved to the specified path, and then the rootfs is remade. In some embodiments, for the configuration of the oemapp certificate Hash, firstly, the image to be signed unsigned.tar.gz is decompressed into the signature tool folder to form the image to be signed folder unsigned, and then / sign_images.sh -s fibocom is obtained.

[0068] From the above, it can be seen that this application is based on the trust chain mechanism of the front-end hardware manufacturer (OTP) and the front-end image, relying on the redesign of the startup verification process and signature process from rootfs to the customized image oemapp, and optimizing the signature and verification data structure, optimizing the signature and verification data volume, to achieve the effect of AVB+OTP dual key pair trust chain verification to ensure verification reliability and meet performance requirements. In addition, under the premise of ensuring reliability, this application controls the verification amount of the data signing step and the signature verification step to a minimum, reduces the verification and signing time, and improves the signature efficiency.

[0069] It can be seen that the present application proposes an image verification method based on a dual trust chain mechanism, including: determining a read-only file system according to the original image file system and the target operating system verification information; constructing a signed image by signing the root hash value file based 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; performing a target operation on the customized public key to obtain a first encryption value, and writing the first encryption value into the verified image, and burning the signed image to the device flash memory; 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 performed on the target operation to obtain a second encryption value; if the first encryption value is the same as the second encryption value, the root hash value file is verified according to the customized public key and the signature result, and if the verification passes, the verification startup of the target operating system is realized through the root hash value file to ensure the reliability of the trust chain mechanism of the target operating system.

[0070] In summary, the present application calculates the first encryption value before burning the customized public key into the flash memory, and calculates the second encryption value after burning the customized public key into the flash memory. Since there is a risk of tampering after the customized public key is burned into the flash memory, the present application determines the reliability of the customized public key in the flash memory based on the comparison result of the first encryption value and the second encryption 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 verification startup of the target operating system is implemented based on the root hash value file to ensure the reliability of the trust chain mechanism of the target operating system. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, the present application 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 trust chain mechanism of the target operating system based on the root hash value file, thereby realizing a verification scheme compatible with dual trust chain mechanisms. In addition, the present application uses two trust chains to support their respective key pairs, which solves the problem that the OTP of some hardware manufacturers does not support the format of the AVB public key.

[0071] Correspondingly, the embodiment of the present application also discloses a mirror verification device based on a dual trust chain mechanism, see Figure 4 As shown, the device comprises:

[0072] A read-only file system determination module 11 is used to determine the read-only file system according to the original image file system and the target operating system verification information;

[0073] An image building module 12 is used to build a signed image through 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 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;

[0074] An image burning module 13, used for performing a target operation on the customized public key to obtain a first encrypted value, and writing the first encrypted value into the verified image, and burning the signed image into a device flash memory;

[0075] An image mounting module 14 is used to mount the signed image according to the startup script of the started verified image after the device is powered on, and perform a target operation on the customized public key in the signed image to obtain a second encrypted value;

[0076] The image verification module 15 is used to verify the root hash value file according to the customized public key and the signature result if the first encryption value is the same as the second encryption 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 trust chain mechanism of the target operating system.

[0077] Among them, for more specific working processes of the above-mentioned modules, please refer to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0078] It can be seen that the present application proposes an image verification method based on a dual trust chain mechanism, including: determining a read-only file system according to the original image file system and the target operating system verification information; constructing a signed image by signing the root hash value file based 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; performing a target operation on the customized public key to obtain a first encryption value, and writing the first encryption value into the verified image, and burning the signed image to the device flash memory; 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 performed on the target operation to obtain a second encryption value; if the first encryption value is the same as the second encryption value, the root hash value file is verified according to the customized public key and the signature result, and if the verification passes, the verification startup of the target operating system is realized through the root hash value file to ensure the reliability of the trust chain mechanism of the target operating system.

[0079] In summary, the present application calculates the first encryption value before burning the customized public key into the flash memory, and calculates the second encryption value after burning the customized public key into the flash memory. Since there is a risk of tampering after the customized public key is burned into the flash memory, the present application determines the reliability of the customized public key in the flash memory based on the comparison result of the first encryption value and the second encryption 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 verification startup of the target operating system is implemented based on the root hash value file to ensure the reliability of the trust chain mechanism of the target operating system. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer's trust chain mechanism, the present application 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 trust chain mechanism of the target operating system based on the root hash value file, thereby realizing a verification scheme compatible with dual trust chain mechanisms. In addition, the present application uses two trust chains to support their respective key pairs, which solves the problem that the OTP of some hardware manufacturers does not support the format of the AVB public key.

[0080] Furthermore, an embodiment of the present application also provides an electronic device. Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram cannot be regarded as any limitation on the scope of use of the present application.

[0081] Figure 5 A schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a display screen 23, an input and output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the image verification method based on the dual trust chain mechanism disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0082] In this embodiment, the power supply 26 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 24 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0083] In addition, the memory 22, as a carrier for storing resources, may be a read-only memory, a random access memory, a disk or an optical disk, etc., and the resources stored thereon may include a computer program 221, and the storage method may be temporary storage or permanent storage. In addition to including a computer program that can be used to complete the image verification method based on the dual trust chain mechanism performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 221 may further include a computer program that can be used to complete other specific tasks.

[0084] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the aforementioned disclosed image verification method based on a dual trust chain mechanism is implemented.

[0085] For the specific steps of the method, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be described in detail here.

[0086] The various embodiments in this application are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0087] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0088] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0089] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0090] The above is a detailed introduction to the image verification method, device, equipment, and storage medium based on the dual trust chain mechanism provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for those skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as limiting the present application.

Claims

1. A mirror verification method based on a dual trust chain mechanism, characterized in that: include: Determine the read-only file system based on the original image file system and the target operating system verification information; Constructing a signature image by using 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 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; Performing a target operation on the customized public key to obtain a first encrypted value, writing the first encrypted value into the verified image, and burning the signed image into the device flash memory; After the device is powered on, the signed image is mounted according to the startup script of the started verified image, and the customized public key in the signed image is subjected to target operation to obtain a second encrypted value; If the first encryption value is the same as the second encryption 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 image verification method based on the dual trust chain mechanism according to claim 1, characterized in that: The method of constructing a signature image by using 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 to sign the root hash value file includes: Determine a first volume according to the read-only file system, determine a second volume according to the root hash value file generated based on the read-only file system, determine a third volume according to a signature result of the root hash value file using the customized private key, and determine a fourth volume according to the customized public key; A signed image is constructed by using the first volume, the second volume, the third volume, and the fourth volume.

3. The image verification method based on the dual trust chain mechanism according to claim 1 is characterized in that: If the first encrypted value is the same as the second encrypted value, verifying the root hash value file according to the customized public key and the signature result includes: If the first encrypted value is the same as the second encrypted value, the customized public key in the signature image is a trusted public key, and a calculation result is obtained based on the customized public key and the root hash value file; If the operation result matches the signature result, the verification passes; If the operation result does not match the signature result, the verification fails.

4. The image verification method based on the dual trust chain mechanism according to claim 3 is characterized in that: The step of obtaining a calculation result based on the customized public key and the root hash value file includes: Using the customized public key, the root hash value file and the signature result as input parameters of a target command line tool set, and outputting a return value according to the target command line tool set; If the return value is the first value, the operation result matches the signature result; If the return value is the second value, the operation result does not match the signature result.

5. The image verification method based on the dual trust chain mechanism according to claim 1 is characterized in that: The target operation includes generating a hash value of the customized public key, and performing padding preprocessing and target iteration operation on the hash value of the customized public key based on a message digest algorithm.

6. The image verification method based on the dual trust chain mechanism according to claim 1, characterized in that: The step of mounting the signed image according to the startup script of the 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 the dual trust chain mechanism according to any one of claims 1 to 6, characterized in that: After determining the read-only file system according to the original image file system and the target operating system verification information, the method further includes: Dividing the original image file system into a plurality of data blocks of a target size based on the target operating system verification information, and performing a hash operation on the data blocks to obtain hash values ​​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. An image verification device based on a dual trust chain mechanism, characterized in that: include: A read-only file system determination module, used to determine the read-only file system according to the original image file system and the target operating system verification information; An image building module, used to build a signed image by using 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 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; An image burning module, used for performing a target operation on the customized public key to obtain a first encrypted value, writing the first encrypted value into a verified image, and burning the signed image into a device flash memory; An image mounting module, used for mounting the signed image according to the startup script of the started verified image after the device is powered on, performing a target operation on the customized public key in the signed image to obtain a second encrypted value; The image verification module is used to verify the root hash value file according to the customized public key and the signature result if the first encryption value is the same as the second encryption 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 trust chain mechanism of the target operating system.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the image verification method based on the dual trust chain mechanism as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store a computer program; wherein, when the computer program is executed by a processor, the image verification method based on the dual trust chain mechanism as described in any one of claims 1 to 7 is implemented.

Images