An image verification method and device based on a double trust chain mechanism, equipment and medium

Abstract

The application discloses a mirror checking method and device based on a double-trust-chain mechanism, equipment and a medium, and relates to the technical field of computers, which comprises the following steps: determining a read-only file system according to original mirror file system and target operating system verification information; constructing a signature mirror by signing the root hash value file through 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; storing the customized public key in an OTP, writing a first encrypted value obtained by operating the customized public key into a verified mirror, and burning the signature mirror into a device flash memory; operating the customized public key in the signature mirror to obtain a second encrypted value; if the two encrypted values are the same, checking the root hash value file according to the customized public key and the signature result, and if the checking is passed, verifying and starting the target operating system through the root hash value file, so that the problem that the OTP of a hardware manufacturer does not support the AVB public key format is solved.

Description

Technical Field

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

[0002] 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. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a mirror verification method, apparatus, device, and medium based on a dual-trust chain mechanism, which can achieve verification compatible with the dual-trust chain mechanism and solve the problem that hardware manufacturers' OTP does not support the AVB public key format. The specific solution is as follows:

[0004] Firstly, this application discloses a mirror verification method based on a dual-trust chain mechanism, including:

[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 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;

[0007] 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;

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

[0009] 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, and if the verification is passed, the target operating system is verified and started through the root hash value file, so as to ensure the reliability of the target operating system trust chain mechanism.

[0010] Optionally, the signature image is constructed by the read-only file system, the root hash value file generated based on the read-only file system, the customized public key, and the signature result of the root hash value file based on the customized private key.

[0011] 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 based on the customized private key, and the fourth volume is determined according to the customized public key.

[0012] The signature image is constructed by 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, the root hash value file is verified according to the customized public key and the signature result, and if the verification is passed, the target operating system is verified and started through the root hash value file, so as to ensure the reliability of the target operating system trust chain mechanism.

[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 an operation 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 is passed.

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

[0017] Optionally, the operation result is obtained based on the customized public key and the root hash value file.

[0018] The customized public key, the root hash value file, and the signature result are taken as input parameters of a target command line tool set, and a return value is output according to the target command line tool set.

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

[0020] If the return value is a 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, the mounting the signed image according to the started startup script of the verified image comprises:

[0023] The device mapper verification method according to the hardware manufacturer trust chain mechanism starts the verified image, and mounts the signed image according to a 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 comprises:

[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] determining the hash value of each data block as a leaf node, and combining hash values of every two adjacent data blocks in a hash binary tree format to obtain the root hash value file.

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

[0028] a read-only file system determination module configured to determine a read-only file system according to an original image file system and target operating system verification information;

[0029] an image construction module configured to construct a signed image through a signature result of the root hash value file based on 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; the root hash value file is obtained based on a device mapper verification method of a hardware manufacturer trust chain mechanism, and the customized public key is stored in a one-time programmable area;

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

[0031] an image mounting module configured to mount the signed image according to a startup script of the started verified image after power-on of a device, and perform a target operation on the customized public key in the signed image to obtain a second encrypted value;

[0032] an image verification module configured to verify the root hash value file according to the customized public key and the signature result if the first encrypted value is the same as the second encrypted value, and if the verification is passed, to realize verification start of a target operating system through the root hash value file to ensure the reliability of a target operating system trust chain mechanism.

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

[0034] a memory for storing a computer program;

[0035] a processor for executing the computer program to implement the mirror image verification method based on the double trust chain mechanism disclosed above.

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

[0037] It can be seen that the present application proposes a mirror image verification method based on a double trust chain mechanism, comprising: determining a read-only file system according to original mirror image file system and target operating system verification information; constructing a signed image through a signature result of a root hash value file of the read-only file system, the root hash value file, a customized public key and a customized private key based on a root hash value file generated by the read-only file system; the root hash value file is obtained by a device mapper verification method based on a hardware manufacturer trust chain mechanism, and the customized public key is stored in a one-time programmable area; performing target operation on the customized public key to obtain a first encrypted value, and writing the first encrypted value to a verified image, and burning the signed image to a device flash memory; after the device is powered on, mounting the signed image according to a start script of the verified image which has been started, performing target operation on the customized public key in the signed image to obtain a second encrypted value; 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, if the verification is passed, verifying and starting the target operating system through the root hash value file, so as to ensure the reliability of the target operating system trust chain mechanism.

[0038] In summary, the application calculates a first encryption value before customizing the public key and burning it into the flash memory, and calculates a second encryption value after customizing the public key and burning it into the flash memory. Since there is a risk of tampering after the public key is burned into the flash memory, the 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 application verifies the root hash value file based on the customized public key and the signature result, to ensure the reliability of the root hash value file. Finally, the application verifies and starts the target operating system based on the root hash value file, to ensure the reliability of the target operating system trust chain mechanism. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer trust chain mechanism, the application verifies the reliability of the root hash value file based on the hardware manufacturer trust chain mechanism, and then ensures the reliability of the target operating system trust chain mechanism based on the root hash value file, to realize a verification scheme compatible with double trust chain mechanisms. In addition, the application uses two trust chains to support 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 DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor based on the provided drawings.

[0040] Figure 1 A flow chart of an image verification method based on a double trust chain mechanism disclosed by the present application;

[0041] Figure 2 A signature diagram disclosed by the present application;

[0042] Figure 3 A flow chart of mounting a signature image disclosed by the present application;

[0043] Figure 4 A structure diagram of an image verification device based on a double trust chain mechanism disclosed by the present application;

[0044] Figure 5 A structure diagram of an electronic device disclosed by the present application. DETAILED DESCRIPTION

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

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

[0047] To address this, this application proposes a mirror verification method based on a dual-trust chain mechanism, which implements verification using the dual-trust chain mechanism and solves the problem that hardware manufacturers' OTP does not support the AVB public key format.

[0048] This application discloses a mirror verification method based on a dual-trust chain mechanism. See [link to relevant documentation]. Figure 1 As shown, the method includes:

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

[0050] The original image file system is a raw, insecure file system. The target operating system is the Android system. 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 dividing the original image file system.

[0051] Step S12: Construct a signature image using the signature result of the root hash value file generated by 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.

[0052] See Figure 2As shown, in the 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 by using the customized private key, the fourth volume is determined according to the customized public key, and a signature image in UBI (Unsorted Block Images) format is constructed through the first volume, the second volume, the third volume and the fourth volume.

[0053] In the process of determining the root hash value file, specifically, the original image file system is divided into a plurality of data blocks of a target size (for example, 4k) based on target operating system verification information by a device mapper verification method (DM-Verity format image) of a hardware manufacturer trust chain mechanism, and a hash operation is performed on the data blocks to obtain hash values of the data blocks, then the hash value of each data block is determined as a leaf node, and each two adjacent data blocks are combined according to the format of a hash binary tree to obtain the root hash value file.

[0054] Step S13: 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 signature image into the device flash memory.

[0055] In the embodiment, the target operation is performed on the customized public key to obtain a first encryption value, and the first encryption value is written into the verified image and the signature image is burned into the device flash memory.

[0056] In an embodiment, 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. The message digest algorithm includes md5 (Message-Digest Algorithm 5).

[0057] Further, the first encryption value is written into a file in a read-only partition fixed path in the verified image, and the signature image is burned into the device flash memory. Since the verified image is a safe and reliable image, and the file in the read-only partition fixed path is read-only, the first encryption value is saved to the verified image in the embodiment, which can ensure the reliability of the first encryption value. In addition, since the signature image in the flash memory is easy to be tampered with, the signature image in the flash memory needs to be verified based on the first encryption value in the embodiment.

[0058] Step S14: 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 a target operation is performed on the customized public key in the signature image to obtain a second encryption value.

[0059] After the device is powered on, the verified image is started according to the device mapper verification method of the hardware vendor trust chain mechanism, and the signature image is mounted according to the start script of the verified image. In order to improve the start speed, the verified image in the 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 easy to be tampered with, the embodiment needs to perform target operation on the customized public key in the signature image again to obtain a second encryption 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, and if the verification is passed, the target operating system is verified and started through the root hash value file, so as to ensure the reliability of the target operating system trust chain mechanism.

[0062] In the 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 an operation result is obtained based on the customized public key and the root hash value file. On the one hand, the operation result matches the signature result, and on the other hand, if the operation result does not match the signature result, the verification is not passed.

[0063] As a specific way of obtaining an operation result based on the customized public key and the root hash value file, the embodiment can take the customized public key, the root hash value file and the signature result as input parameters of a target command line tool set (openssl), and return a value according to the target command line tool set. On the one hand, if the return value is a first value, the operation result matches the signature result, and if the return value is a second value, the operation result does not match the signature result.

[0064] From the foregoing analysis, it can be seen that the reliability of the customized public key in the fourth volume has been verified in the embodiment, 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, the operation result based on the customized public key in the fourth volume and the root hash value file in the second volume needs to match the signature result in the third volume in the current embodiment. If they match, it proves that the root hash value file passes the verification, otherwise, it does not pass the verification. For example, the embodiment can take the root hash value file, the customized public key and the signature result as 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 does not pass the verification.

[0065] In the embodiment, if the root hash value file passes the verification, the target operating system is verified and started through the root hash value file. Since the root hash value file is obtained by the device mapper verification method based on the hardware manufacturer trust chain mechanism, the reliability of the root hash value file is verified based on the hardware manufacturer trust chain mechanism, and the reliability of the target operating system trust chain mechanism is ensured based on the root hash value file, thereby realizing the verification scheme compatible with the double trust chain mechanism. That is, the first trust chain in the application is the hardware manufacturer trust chain based on the OTP key, and the second trust chain is the target operating system trust chain. Since the hardware manufacturer trust chain based on the OTP key is reliable, the reliability of the root hash value file in the flash memory is ensured according to the reliability of the hardware manufacturer trust chain, and the reliability of the target operating system trust chain mechanism is further ensured through the reliability of the root hash value file, thereby realizing the verification scheme compatible with the double trust chain mechanism.

[0066] As can be seen from the above, the embodiment first signs the original non-secure image to obtain a data image format meeting the verification requirements. Further, after the device is powered on and started, the hardware manufacturer's trust chain mechanism is executed until the rootfs (i.e., the previous image of the signed image) is executed, and the customized partition image oemapp (the image file of the storage partition generated after customized processing according to specific requirements, i.e., the signed image in the embodiment) of the customer's customized application is mounted. When the oemapp is mounted, the fourth volume is first operated using openssl in the embodiment to obtain a second encryption value, the encryption value is compared with the first encryption value pre-stored in the trusted partition of the rootfs, and if the comparison fails, the system is abnormally exited. If the comparison is successful, it is proved that the customized public key in the fourth volume is a trusted public key, and the root hash value file is operated using the customized public key to match the signature value of the third volume. If the match is successful, the verification is passed, and the root_hash is used as a parameter to participate in the Android verification and start verification, thereby realizing the verification scheme compatible with the double trust chain mechanism.

[0067] Figure 3 A flowchart for mounting the oemapp is disclosed, see Figure 3As shown, specifically includes: 1, after the system ends, the little kernel will be converted into the formal operating system, and the fibo_ubi_mount process is started by systemd; 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 check against the signed volume; 6, call verity-boot to create a device mapper 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, first, based on the script of dm_tool, the sysfs.squash file in the unsigned folder is decompressed, and the OTP public key Hash value is obtained, the MD5 value is calculated, and saved to the specified path, and then the rootfs is remade. In some embodiments, for the configuration of the oemapp certificate Hash, first, the unsigned image tar.gz to be signed is decompressed into the signature tool folder, and the unsigned image folder to be signed is formed, and then / sign_images.sh -s fibocom is obtained.

[0068] As can be seen from the above, based on the preposed hardware manufacturer (OTP) and the preposed image trust chain mechanism, the application relies on the redesigned startup verification process and signature process from rootfs to customized image oemapp, optimizes the signature and verification data structure, optimizes the signature and verification data amount, and achieves the effect of AVB+OTP double secret key trust chain verification to ensure the verification reliability and meet the performance requirements. In addition, under the premise of ensuring reliability, the application controls the verification amount of the data signature step and the signature verification step to be the minimum, reduces the verification and signature time, and improves the signature efficiency.

[0069] It can be seen that the application provides a mirror checking method based on a double trust chain mechanism, which comprises the following steps: determining a read-only file system according to an original mirror file system and target operating system verification information; constructing a signed mirror image by using a signature result of a root hash value file of 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; the root hash value file is obtained by using a device mapper verification method based on a hardware manufacturer trust chain mechanism, and the customized public key is stored in a one-time programmable area; performing target operation on the customized public key to obtain a first encrypted value, and 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 according to a start script of the verified mirror image, performing target operation on the customized public key in the signed mirror image to obtain a second encrypted value; 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, and if the verification is passed, verifying and starting the target operating system by using the root hash value file, so as to ensure the reliability of the target operating system trust chain mechanism.

[0070] As can be seen from the above, the application calculates the first encrypted value before the customized public key is burned into the flash memory, and calculates the second encrypted value 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, the application 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 it is determined 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, so as 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, so as to ensure the reliability of the target operating system trust chain mechanism. Since the root hash value file is obtained by using the device mapper verification method based on the hardware manufacturer trust chain mechanism, the application verifies the reliability of the root hash value file based on the hardware manufacturer trust chain mechanism, and then ensures the reliability of the target operating system trust chain mechanism based on the root hash value file, so as to realize a verification scheme compatible with the double trust chain mechanism. In addition, the application uses two trust chains to support respective key pairs, so as to solve the problem that the OTP of some hardware manufacturers does not support the format of the AVB public key.

[0071] Correspondingly, the application also discloses a mirror checking device based on a double trust chain mechanism, as shown in Figure 4 The device comprises the following modules:

[0072] A read-only file system determination module 11 is configured to determine a read-only file system according to an original mirror file system and target operating system verification information.

[0073] The mirror image construction module 12 is configured to construct a signed mirror image based on the read-only file system, a root hash value file generated based on the read-only file system, a customized public key, and a signature result of the root hash value file signed by the customized private key, wherein the root hash value file is obtained based on a device mapper verification method of a hardware manufacturer trust chain mechanism, and the customized public key is stored in a one-time programmable area.

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

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

[0076] The mirror 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, and perform verification startup of a target operating system based on the root hash value file if the verification is passed, so as to ensure the reliability of the target operating system trust chain mechanism.

[0077] The above modules can refer to the corresponding content disclosed in the foregoing embodiments for more specific working processes, which will not be described here.

[0078] It can be seen that the mirror image verification method based on the double trust chain mechanism includes the following steps: determining a read-only file system based on original mirror image file system and target operating system verification information; constructing a signed mirror image based on the read-only file system, a root hash value file generated based on the read-only file system, a customized public key, and a signature result of the root hash value file signed by the customized private key, wherein the root hash value file is obtained based on a device mapper verification method of a hardware manufacturer trust chain mechanism, and the customized public key is stored in a one-time programmable area; performing target operation on the customized public key to obtain a first encrypted value, and writing the first encrypted value into a verified mirror image, and burning the signed mirror image to a device flash memory; mounting the signed mirror image according to a startup script of the verified mirror image after the device is powered on, and performing target operation on the customized public key in the signed mirror image to obtain a second encrypted value; and verifying 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, and performing verification startup of a target operating system based on the root hash value file if the verification is passed, so as to ensure the reliability of the target operating system trust chain mechanism.

[0079] In summary, the application calculates a first encryption value before customizing the public key and burning it into the flash memory, and calculates a second encryption value after customizing the public key and burning it into the flash memory. Since there is a risk of tampering after customizing the public key and burning it into the flash memory, the 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 application verifies the root hash value file based on the customized public key and the signature result, to ensure the reliability of the root hash value file. Finally, the application verifies and starts the target operating system based on the root hash value file, to ensure the reliability of the target operating system trust chain mechanism. Since the root hash value file is obtained based on the device mapper verification method of the hardware manufacturer trust chain mechanism, the application verifies the reliability of the root hash value file based on the hardware manufacturer trust chain mechanism, and then ensures the reliability of the target operating system trust chain mechanism based on the root hash value file, to implement a verification scheme compatible with double trust chain mechanisms. In addition, the application uses two trust chains to support respective key pairs, thereby solving the problem that the OTP of some hardware manufacturers does not support the format of the AVB public key.

[0080] Further, the embodiment of the application further provides an electronic device. Figure 5 FIG. 1 is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content in the figure should not be considered as any limitation on the use range of the application.

[0081] Figure 5 FIG. 1 is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content in the figure should not be considered as any limitation on the use range of the application.

[0082] In the embodiment, the power supply 26 is configured to provide working voltage for each hardware device on the electronic device 20. The communication interface 25 is configured to create a data transmission channel between the electronic device 20 and external devices, and the communication protocol followed by the communication interface 25 can be any communication protocol applicable to the technical solution of the application, which is not limited specifically herein. The input and output interface 24 is configured to obtain external input data or output data to the outside, and the specific interface type can be selected according to the specific application needs, which is not limited specifically herein.

[0083] In addition, the memory 22 can be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc. as a carrier for storing resources. The resources stored on the memory 22 can include a computer program 221, and the storage mode can be temporary storage or permanent storage. In addition to the computer program 221 capable of completing the computer program executed by the electronic device 20 according to the mirror image verification method based on the double trust chain mechanism disclosed in any of the foregoing embodiments, the computer program 221 can further include a computer program capable of completing other specific work.

[0084] Further, the embodiment of the present application further discloses a computer readable storage medium for storing a computer program, wherein the computer program is executed by a processor to implement the mirror image verification method based on the double trust chain mechanism disclosed above.

[0085] The specific steps of the method can refer to the corresponding content disclosed in the foregoing embodiments, and will not be described here.

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

[0087] The skilled person can further realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of the two. In order to clearly show the interchangeability of hardware and software, the components and steps of each example have been described in the above description. Whether the functions are realized by hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0088] The steps of the method or algorithm described in combination with the embodiments disclosed herein can be directly implemented by hardware, a software module executed by a processor, or a combination of the two. The software module can 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 needs to be pointed out that in this paper, the relationship terms such as first and second 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 the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0090] The above describes in detail the mirror verification method, device, equipment and storage medium based on the double trust chain mechanism provided by the present application. The principles and implementation manners of the present application are described by applying specific examples. The above description of the embodiments is only used to help understand the method and its core idea of the present application. Meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manner and application range will be changed. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A method for image verification based on a double trust chain mechanism, characterized in that, The application comprises the following steps: determining a read-only file system according to the original image file system and the target operating system verification information; constructing 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 signature result of the root hash value file; the root hash value file is obtained through a device mapper verification method based on a hardware manufacturer trust chain mechanism, and the customized public key is stored in a one-time programmable area; performing target operation on the customized public key to obtain a first encrypted value, and writing the first encrypted value to a verified image and burning the signed image to a device flash memory; after the device is powered on, mounting the signed image according to a start script of the verified image, and performing target operation on the customized public key in the signed image to obtain a second encrypted value; 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, and if the verification is passed, verifying and starting the target operating system through the root hash value file to ensure the reliability of the target operating system trust chain mechanism; wherein, after determining the read-only file system according to the original image file system and the target operating system verification information, the method further comprises the following steps: 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 hash operation on the data blocks to obtain hash values of the data blocks; determining each hash value of the data blocks as a leaf node, and combining each two adjacent hash values of the data blocks in the format of a hash binary tree to obtain the root hash value file.

2. The method of claim 1, wherein the method further comprises: the method of constructing 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 signature result of the root hash value file comprises the following steps: determining a first volume according to the read-only file system, a second volume according to the root hash value file generated based on the read-only file system, a third volume according to the signature result of the root hash value file using the customized private key, and a fourth volume according to the customized public key; constructing a signed image through the first volume, the second volume, the third volume, and the fourth volume.

3. The method of claim 1, wherein the method further comprises: 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, comprises the following steps: if the first encrypted value is the same as the second encrypted value, the customized public key in the signed image is a trusted public key, and an operation 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 is passed; if the operation result does not match the signature result, the verification is not passed.

4. The method of claim 3, wherein the method further comprises: the method of obtaining an operation result based on the customized public key and the root hash value file, comprises the following steps: taking 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 method of claim 1, wherein the method further comprises: 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 method of claim 1, wherein the method further comprises: The mounting of the signed image according to the startup script of the verified image after startup includes: The verified image is started according to a device mapper verification method of the hardware vendor trust chain mechanism, and the signed image is mounted according to the startup script of the verified image.

7. An image verification device based on a double trust chain mechanism, characterized in that, It includes: A read-only file system determination module is configured to determine a read-only file system according to original image file system and target operating system verification information; An image construction module is configured to construct a signature image of a signature result of a root hash value file based on 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 through the read-only file system; The root hash value file is obtained based on a device mapper verification method of a hardware vendor trust chain mechanism, and the customized public key is stored in a one-time programmable area; An image burning module is configured to perform a target operation on the customized public key to obtain a first encrypted value, write the first encrypted value into a verified image, and burn the signed image to a device flash memory; An image mounting module is configured to mount the signed image according to a startup script of the verified image after startup, perform a target operation on the customized public key in the signed image to obtain a second encrypted value, and perform a target operation on the customized public key in the signed image to obtain a second encrypted value; An image verification module is configured to, if the first encrypted value is the same as the second encrypted value, verify the root hash value file based on the customized public key and the signature result, and if the verification is passed, implement verification startup of a target operating system through the root hash value file to ensure the reliability of a target operating system trust chain mechanism. 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; Determining the hash value of each data block as a leaf node, and combining every two adjacent hash values of the data blocks in a hash binary tree format to obtain the root hash value file.

8. An electronic device, comprising: It includes: A memory for storing a computer program; A processor for executing the computer program to implement the image verification method based on the double trust chain mechanism according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, A memory for storing a computer program; wherein the computer program is executed by a processor to implement the image verification method based on the double trust chain mechanism according to any one of claims 1 to 6.

Images