Mirror image verification method and device based on Uboot, medium and program product

Abstract

The invention provides a mirror image verification method and device based on Uboot, a medium and a program product, the mirror image verification method is applied to a mirror image verification system based on Uboot, the verification system comprises a signature verification end, and the mirror image verification method comprises the steps that when the signature verification end loads a mirror image file, a corresponding target certificate and a root certificate to which the target certificate belongs are determined in a certificate chain; the signature verification end performs self-signature verification on the root certificate, and verifies a root certificate public key of the root certificate by using pre-stored public key reference information after the self-signature verification is passed; after the public key verification of the root certificate is passed, the signature verification end verifies the signature of the target certificate; and after the signature verification of the target certificate is passed, the signature verification end verifies the signature of the mirror image file. According to the scheme, a certificate chain verification mechanism is introduced, and a small amount of public key reference information for verifying the root certificate public key is pre-stored, so that signature verification of the mirror image file can be realized, and the flexibility of the mirror image verification method can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a U-boot-based image verification method, device, medium, and program product. Background Technology

[0002] In the fields of embedded systems and secure boot, image file signature verification is a crucial step in ensuring system security and trustworthiness. With the proliferation of IoT and smart devices, the secure boot mechanism faces increasingly stringent requirements. Image files are vulnerable to tampering during transmission and storage, thus necessitating digital signature technology to ensure their integrity and reliable origin. Traditional image signature verification methods primarily rely on direct signing and verification of the image file, or verification using a pre-stored public key. For example, this involves signing and verifying the SPL.bin, FIT, and DTB files during the BootROM stage, or verifying the public key in the DTB device tree file against a pre-defined key during the SPL image loading post-processing (board_fit_image_post_process). While these methods improve system security to some extent, they suffer from significant shortcomings in flexibility and key management.

[0003] In image signature verification methods based on Uboot SPL (Second Program Loader), when loading a large number of images, if each image requires different security levels, different asymmetric keys with different security levels need to be used for signing. The Uboot SPL open-source framework writes the public key portion of the relevant keys into the DTB for signature verification. To ensure that the image and keys are not replaced, a large number of public key hash values ​​usually need to be pre-stored in one-time write devices such as OTP (One-Time Programmable Memory) or EFUSE (Electronic Fuse). This not only occupies valuable OTP space but also limits the system's flexibility. Therefore, existing solutions cannot meet dynamically changing needs, making the signature verification method difficult to adapt to diverse application scenarios. Summary of the Invention

[0004] The purpose of this application is to provide a U-boot-based image verification method, device, medium, and program product to solve the above-mentioned problems.

[0005] In a first aspect, embodiments of this application provide a U-Boot-based image verification method, applied to a U-Boot-based image verification system. The verification system includes a signature verification terminal. The method includes: when loading an image file, the signature verification terminal determines the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain based on the key identifier attribute carried by the image file; the signature verification terminal performs self-signature verification on the root certificate, and after the self-signature verification passes, verifies the root certificate public key of the root certificate using pre-stored public key reference information; after the root certificate public key verification passes, the signature verification terminal uses the root certificate public key to verify the signature of the target certificate; after the signature verification of the target certificate passes, the signature verification terminal uses the target certificate public key of the target certificate to verify the signature of the image file.

[0006] In the implementation of the above scheme, by introducing a certificate chain verification mechanism, the signature verification of the image file can be achieved by pre-storing a small amount of public key base information used to verify the root certificate public key, avoiding the need for pre-storing a large number of public key hash values. This makes the above U-Boot-based image verification method applicable to more application scenarios and improves its flexibility. On the other hand, the application of the certificate chain means that the signature verification of the image file no longer depends on a large number of pre-stored public key hash values, but on the trusted root node of the certificate chain. As a result, the image file can be dynamically updated, which further improves the flexibility of the above U-Boot-based image verification method. Furthermore, the signature verification of the image file is performed when loading the image file, i.e., in the SPL stage, avoiding the embedding of complex verification logic into the BootROM stage, which helps to improve the overall boot efficiency.

[0007] In one implementation of the first aspect, the method further includes: after the signature verification of the image file passes, the verification terminal compares the target certificate public key and the target preset public key; wherein, the target preset public key is a pre-stored preset public key that corresponds to the key identifier attribute; the target preset public key is used to perform preliminary verification of the signature of the image file; if the comparison result shows that the target certificate public key and the target preset public key are inconsistent, the signature verification of the image file is determined to have failed.

[0008] In the implementation of the above scheme, by adding a comparison step between the target certificate public key and the target preset public key after the signature verification of the image file is passed, it is possible to quickly identify whether the certificate chain has been tampered with or replaced, thereby enhancing the security of the above Uboot-based image verification method. On the other hand, by comparing the target certificate public key and the target preset public key, potential errors or attack behaviors in the certificate chain can be detected. Even if the signature verification of the image file is passed, illegal image files can still be detected and intercepted in a timely manner, thereby improving the reliability of the above Uboot-based image verification method.

[0009] In one implementation of the first aspect, obtaining the target preset public key includes: searching in the device tree file for the target preset public key that uniquely corresponds to the key identifier attribute.

[0010] In the implementation of the above scheme, by searching for the target preset public key that uniquely corresponds to the key identifier attribute in the device tree file, the required public key can be quickly located, reducing search time and thus improving the verification efficiency of the above Uboot-based image verification method.

[0011] In one implementation of the first aspect, verifying the signature of the target certificate using the root certificate public key includes: determining a verification path from the root certificate node to the target certificate node in the certificate chain; wherein the signature of each lower-level certificate node in the verification path is issued by the private key of the parent certificate node of the lower-level certificate node; starting from the lower-level certificate node of the root certificate node, verifying the signature of the certificate in each certificate node sequentially along the verification path until the signature verification of the target certificate passes; wherein if the signature verification of the certificate in any certificate node fails, the verification is terminated, and the signature verification of the image file is determined to have failed.

[0012] In the implementation of the above scheme, by verifying the signature of each lower-level certificate node sequentially along the verification path, any abnormal node on the verification path can be accurately identified, thereby enhancing the credibility of the target certificate node and improving the security of the above U-boot-based image verification method. On the other hand, the entire signature verification process is terminated immediately when the signature verification of each lower-level certificate node in the verification path fails. This mechanism can quickly identify and intercept illegal image files, which is beneficial to improving the verification efficiency of the above U-boot-based image verification method.

[0013] In one implementation of the first aspect, determining the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain based on the key identifier attribute carried by the image file includes: Based on the key identifier attribute carried in the image file, the corresponding target certificate and the root certificate to which the target certificate belongs are determined in the certificate chain stored in the FIT image tree file.

[0014] In the implementation of the above scheme, the certificate chain is stored in the FIT image tree file, which makes the management of the certificate chain more flexible and allows the above U-boot-based image verification method to be applied to more application scenarios, thus improving the flexibility of the above U-boot-based image verification method. On the other hand, during the signature verification process, the required certificate information can be quickly located and read directly from the FIT image tree file, which helps to improve the verification efficiency of the above U-boot-based image verification method.

[0015] In one implementation of the first aspect, the verification system further includes a first signing end, and the method further includes: the first signing end constructing a certificate chain; wherein the certificate chain includes a root certificate node and a terminal node; the root certificate node includes a self-signed root certificate; the terminal node includes a certificate of an image file; the certificate of the image file includes certificate identification information that uniquely matches the key identification attribute carried by the image file; and the first signing end stores the certificate chain at the verification end.

[0016] In one implementation of the first aspect, storing the certificate chain at the signature verification end includes: storing the certificate chain in the top-level node of the FIT mirror tree file of the signature verification end.

[0017] In one implementation of the first aspect, the method further includes: the first signing terminal generating public key reference information of the root certificate and storing the public key reference information in the OTP memory of the verification terminal; wherein the public key reference information is used to verify the root certificate public key of the root certificate.

[0018] In one implementation of the first aspect, the verification system further includes a second signing terminal, and the method further includes: the second signing terminal generating a preset public key and binding the preset public key with public key identification information; wherein, the preset public key is used to verify the signature of the image file; the public key identification information is identification information that uniquely matches the key identification attribute carried by the image file; and the second signing terminal stores the preset public key and the public key identification information in the verification terminal.

[0019] In one implementation of the first aspect, storing the preset public key and the public key identification information in the signature verification terminal includes: storing the preset public key and the public key identification information in the device tree file of the signature verification terminal.

[0020] Secondly, embodiments of this application provide an image verification system based on U-Boot, comprising: a signature verification terminal, configured to, when loading an image file, determine the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain based on the key identifier attribute carried by the image file; perform self-signature verification on the root certificate, and after the self-signature verification is passed, verify the root certificate public key of the root certificate using pre-stored public key reference information; after the root certificate public key is verified, verify the signature of the target certificate using the root certificate public key; and after the signature verification of the target certificate is passed, verify the signature of the image file using the target certificate public key of the target certificate.

[0021] In one implementation of the second aspect, the verification system further includes: The first signing end is used to construct the certificate chain; wherein the certificate chain includes a root certificate node and a terminal node; the root certificate node includes a self-signed root certificate; the terminal node includes a certificate of the image file; the certificate of the image file includes certificate identification information that uniquely matches the key identification attribute carried by the image file.

[0022] In one implementation of the second aspect, the verification system further includes: The second signature terminal is used to generate a preset public key and bind the preset public key with public key identification information; wherein, the preset public key is used to verify the signature of the image file; the public key identification information is identification information that uniquely matches the key identification attribute carried by the image file; the preset public key and the public key identification information are stored in the signature verification terminal.

[0023] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a communication bus, wherein the processor and the memory communicate with each other through the communication bus; the memory stores computer program instructions that can be executed by the processor, and the computer program instructions are read and run by the processor to perform the method provided by the first to fourth aspects or any possible implementation of the first to fourth aspects.

[0024] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the method provided by the first to fourth aspects or any possible implementation of the first to fourth aspects.

[0025] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the method provided by the first to fourth aspects or any possible implementation of the first to fourth aspects.

[0026] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims and drawings. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of the architecture of the image verification system provided in the embodiments of this application; Figure 2 A flowchart illustrating the U-Boot-based image verification method applied to the aforementioned image verification system, as provided in this application embodiment; Figure 3 A schematic diagram illustrating the verification logic of a U-Boot-based image verification method in a specific application scenario provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0030] In view of this, this application provides an image verification method based on U-Boot. By introducing a certificate chain verification mechanism, the signature verification of the image file can be achieved by pre-storing a small amount of public key base information used to verify the root certificate public key, avoiding the need for pre-storing a large number of public key hash values. This makes the U-Boot-based image verification method applicable to more application scenarios and improves its flexibility. On the other hand, the application of the certificate chain means that the signature verification of the image file no longer depends on a large number of pre-stored public key hash values, but on the trusted root node of the certificate chain. As a result, the image file can be dynamically updated, which further improves the flexibility of the U-Boot-based image verification method. Furthermore, the signature verification of the image file is performed when loading the image file, i.e., in the SPL stage, avoiding embedding complex verification logic into the BootROM stage, which helps improve the overall boot efficiency.

[0031] The aforementioned U-Boot (Universal Boot Loader) is an open-source master boot loader widely used in embedded Linux systems, responsible for hardware initialization, image loading, and system startup. It employs a two-stage architecture for modular booting: the first stage, SPL (Secondary Program Loader), acts as a lightweight intermediate bootloader between the chip-embedded bootloader (BootROM) and the main U-Boot, running in SRAM. After completing minimal DDR controller and storage device initialization, it loads the complete U-Boot image from the second stage into memory. The main U-Boot in the second stage provides complete functionality, including interactive command line, network support, storage device operation, and operating system kernel loading. The BootROM stage executes immediately after processor power-on or reset, running in the chip's built-in SRAM. Its core function is to perform primary hardware initialization (such as clock, PLL, and basic storage controller configuration) and load the first-level bootable image from a preset boot medium. In the secure boot architecture, the BootROM is the sole cryptographic verification execution entity. Internally, it permanently stores a hashed root public key via an OTP fuse or EFUSE, used to verify the digital signature of the SPL image. If the signature verification fails, the process will be aborted; if it passes, control will be transferred to the SPL entry point.

[0032] The above-described U-Boot-based image verification method can be applied to image verification systems, such as... Figure 1 As shown, the mirror verification system may include a first signing terminal 100, a second signing terminal 200, and a verification terminal 300, wherein: The first signing terminal 100 is an electronic device deployed on the chip manufacturer's side. Its primary responsibility is to generate the certificate chain and store it in the top-level node of the FIT image tree file. The certificate chain includes a root certificate node and terminal nodes. The root certificate node contains a self-signed root certificate, while the terminal nodes contain certificates corresponding to the image file. Furthermore, the first signing terminal 100 is also responsible for generating the public key base information of the root certificate and storing this information in the BootROM for use by the verification terminal during the verification process. By building and managing the certificate chain, the chip manufacturer provides a trusted starting point for the entire system and ensures the security and trustworthiness of the entire certificate chain.

[0033] The second signature terminal 200 is an electronic device deployed on the system vendor's side of the operating system. Its main responsibility is to generate a preset public key and bind it to public key identification information. The preset public key is used to verify the signature of the image file, while the public key identification information uniquely matches the key identification attribute carried in the image file. Furthermore, the second signature terminal 200 is also responsible for storing the preset public key and its identification information in a device tree file for use by the verification terminal during the initial verification phase. By managing the preset public key and image file signature, the system vendor can flexibly handle the update and verification process of image files without interfering with the root key managed by the chip vendor.

[0034] The signature verification terminal 300 is an electronic device deployed on the terminal device side, typically referring to an embedded device or IoT device that needs to load and execute image files. The signature verification terminal 300 is primarily responsible for verifying the image file during the device startup process, ensuring the integrity and trustworthiness of the image file's origin.

[0035] Please see Figure 2 When verifying the signature of an image file, the interaction steps of the first signing terminal 100, the second signing terminal 200, and the verification terminal 300 in the above-mentioned image verification system include: steps S110 and S120 executed by the first signing terminal 100, steps S210 and S220 executed by the second signing terminal 200, and steps S310 to S340 executed by the verification terminal 300, wherein: Step S110: The first signing end 100 constructs a certificate chain; wherein, the certificate chain includes a root certificate node and a terminal node; the root certificate node includes a self-signed root certificate; the terminal node includes the certificate of the image file; the certificate of the image file includes certificate identification information that uniquely matches the key identification attribute carried by the image file.

[0036] The above certificate chain is a hierarchical trust structure composed of multiple certificates, with the root certificate as the starting point of trust, and connected to the terminal node certificate (such as the certificate of the image file) through intermediate certificates. The root certificate is self-signed, and its security is guaranteed by the device manufacturer or chip manufacturer, while the intermediate certificates and terminal node certificates are issued by their superior certificates. The steps of the above step S110 to build the certificate chain may include: (1) Generating a root key pair: The private key and public key pair of the root certificate can be generated using cryptographic tools such as OpenSSL. Among them, the root private key must be strictly kept to prevent leakage. (2) Creating a root certificate: The root certificate is signed using the root private key, making the root certificate a self-signed certificate. The root certificate contains the root public key and certificate metadata (such as validity period, issuer information, etc.). (3) Generating an intermediate key pair: The private key and public key pair of the intermediate certificate are generated. (4) Issuing an intermediate certificate: The intermediate certificate is signed using the root private key to ensure that the public key of the intermediate certificate is trustworthy. (5) Generating a terminal key pair: The private key and public key pair of the image file are generated. (6) Issuing terminal certificates: Sign the terminal certificate (the certificate of the image file) using the private key of the intermediate certificate. The terminal certificate contains certificate identification information that uniquely matches the key identification attribute of the image file, ensuring the association between the image file and the certificate.

[0037] The aforementioned key identifier attribute is specific information associated with the image file. It can be embedded in the header or metadata section of the image file, or it can be used as an attribute of the image file's signature node, such as the key-name-hint attribute. The key identifier attribute can be used to uniquely identify the signing key pair of the image file, ensuring accurate matching between the image file and the corresponding signing and verification certificate.

[0038] The aforementioned intermediate certificate is a layered certificate located between the root certificate and the terminal certificate. Its functions include: (1) isolating the risk of the root certificate private key. As the underlying trust anchor, the root certificate private key can be used to issue intermediate certificates instead of directly issuing terminal certificates, thereby reducing the probability and frequency of exposure of the root private key and avoiding the collapse of the entire trust system due to the leakage of the root private key; (2) realizing hierarchical trust transmission, passing the trust anchor of the root certificate to the terminal certificate level by level, and ensuring that the legality of the terminal certificate can be traced back to the root certificate through the chain-like issuance logic of the intermediate certificate; (3) supporting the fine division of business scenarios. Different intermediate certificates can be bound to different product lines, regions or organizational levels, which facilitates the classification and management of terminal certificates. For example, intermediate certificates can be allocated according to the business modules of embedded devices. It is understandable that whether to set an intermediate certificate and the number of intermediate certificates in each certificate chain can be flexibly adjusted.

[0039] The certificates in the aforementioned certificate chain can use the X.509 format, a standard digital certificate format under the Public Key Infrastructure (PKI) system, possessing a standardized structure and broad compatibility. An X.509 certificate includes core fields such as version number, serial number, signature algorithm identifier, subject information (e.g., certificate holder name), subject public key information, issuer information, validity period, and extended fields. The extended fields support custom attributes; for example, the key identifier attribute mentioned above can be embedded through SubjectAlternative Name or a custom extended field to achieve a unique binding between the certificate and the image file. In the certificate chain construction process described above, the root certificate is a self-signed X.509 certificate, while the intermediate and terminal certificates are all chained certificates conforming to the X.509 standard. The intermediate certificates are signed by the root certificate using the X.509 compliant signature algorithm, and the terminal certificates are signed by the intermediate certificates. The Subject Alternative Name (SAN) mentioned above is an extended field defined in the X.509 digital certificate standard, allowing a certificate to be associated with multiple identifiers, such as domain names, IP addresses, or email addresses.

[0040] Step S120: The first signing end 100 stores the certificate chain in the verification end 300.

[0041] Optionally, step S120 above may include: storing the certificate chain in the top-level node of the FIT mirror tree file of the signature verification terminal 300.

[0042] FIT (Flattened Image Tree) files are a file format used in embedded systems and the Linux kernel boot process to store multiple images and their associated metadata. FIT files are structured and can store various types of image files (such as kernel images, device tree files, etc.) along with configuration information and signature data associated with these images, making it a flexible and efficient storage method. The FIT file format allows users to organize and manage multiple images and their metadata in a single file, facilitating the selection and loading of the correct image during secure boot. The structured nature of FIT files allows for a clear description of the hierarchical relationships and dependencies between images. This file format is commonly used in scenarios requiring secure boot, as it can store the signature information of image files and the certificate chains used to verify these signatures.

[0043] In the above scheme, the first signing end 100 can store the constructed certificate chain in a custom top-level node of the FIT mirror tree file of the verification end 300. A custom top-level node in the FIT file refers to a top-level node defined by the user or developer according to specific needs within the FIT file. These custom nodes can extend the standard structure of the FIT file, allowing the storage of additional information or data. For example, a custom top-level node named "certs" can be added to store the certificate chain.

[0044] Optionally, the above-described U-boot-based image verification method applied to the first signing terminal 100 may further include: generating public key reference information of the root certificate and storing the public key reference information in the BootROM of the verification terminal 300; wherein the public key reference information is used to verify the root certificate public key of the root certificate.

[0045] The aforementioned public key baseline information is reference data used to verify the trustworthiness of root certificate public keys. It provides a way to ensure that the public key used for verification has not been tampered with and is trustworthy. Public key baseline information can be a public key hash value, which is a fixed-length digest obtained by hashing the public key, used to uniquely identify the corresponding public key. Hash values ​​are unique and irreversible; any modification to the public key will result in a change to the hash value. Therefore, by comparing the stored public key hash value with the calculated public key hash value, the integrity and authenticity of the public key can be verified.

[0046] As an optional implementation of the BootROM described above, the OTP memory is a one-time programmable memory, a non-volatile memory where data cannot be modified or erased once written. OTP memory is typically used to store critical data whose immutability and security must be ensured. In the above scheme, public key reference information (such as the hash value of the root certificate public key) can be stored in the OTP memory of the signature verification terminal 300. This storage method ensures the credibility and security of the public key reference information because its content cannot be changed after being written, thus preventing the risk of tampering with the public key reference information. When verifying the root certificate public key, the signature verification terminal 300 confirms the legitimacy and credibility of the root certificate public key by comparing the calculated hash value of the root certificate public key with the public key reference information stored in the OTP memory.

[0047] The first signing terminal 100 can establish a secure communication connection with the verification terminal 300. This communication connection can be implemented using, for example, encrypted communication protocols (such as TLS / SSL) or other secure transmission mechanisms. The first signing terminal 100 can send the generated public key reference information to the verification terminal 300 through this secure connection. After receiving the public key reference information, the verification terminal 300 can write this information into the OTP memory using a dedicated programming tool or interface.

[0048] Step S210: The second signing terminal 200 generates a preset public key and binds the preset public key with the public key identification information; wherein, the preset public key is used to verify the signature of the image file; the public key identification information is identification information that uniquely matches the key identification attribute carried by the image file.

[0049] The aforementioned preset public key is a public key generated by the second signing terminal 200, which forms a key pair with the corresponding private key. The private key is used to sign the image file, while the preset public key is used to verify the signature at the verification terminal 300. The preset public key is bound to public key identification information, and the public key identification information uniquely matches the key identification attribute carried in the image file, ensuring that the corresponding preset public key can be quickly found during image file signature verification. The public key identification information can take various forms, such as the name of the image file. When the name of the image file is used as the public key identification information, each image file name corresponds to a unique public key, ensuring that the corresponding public key can be quickly found for signature verification during the signature verification process.

[0050] For the same image file, the public key stored in the terminal node certificate corresponding to that image file is the same as the preset public key corresponding to that image file. The public key in the terminal node certificate is used to verify the signature of the image file, while the preset public key is used for preliminary verification during device startup. Ensuring that these two public keys are consistent can prevent the image file from being tampered with or replaced, ensure the integrity of the certificate chain and the continuity of the trust chain, thereby improving the security of the U-Boot-based image verification method described above.

[0051] Step S220: The second signing terminal 200 stores the preset public key and public key identification information in the verification terminal 300.

[0052] Optionally, step S220 may include storing the preset public key and public key identification information in the device tree file of the signature verification terminal 300.

[0053] The aforementioned device tree file refers to the Device Tree Blob (DTB) file, a binary file format used to describe a hardware platform. It is widely used in embedded systems and the Linux kernel boot process. The DTB file organizes data in a tree structure, containing information such as the hardware device's topology, device attributes, memory mappings, and interrupt configurations, enabling the operating system to identify and configure hardware resources based on this file.

[0054] Storing the preset public key and its identifier in the device tree file of the signature verification terminal 300 is crucial because the device tree file is loaded into memory early during system startup, allowing the signature verification terminal 300 to quickly access this public key information before the image file is loaded. The structured nature of the device tree file facilitates rapid location and parsing of the required public key data, thereby improving verification efficiency. Furthermore, device tree files typically have certain protection mechanisms to prevent tampering, ensuring the trustworthiness of the stored public key information. This storage method ensures the efficiency and security of the initial verification of the image file, providing a fundamental guarantee for secure boot.

[0055] The second signing terminal 200 can establish a secure communication connection with the verification terminal 300. This communication connection can be implemented using, for example, encrypted communication protocols (such as TLS / SSL) or other secure transmission mechanisms. The second signing terminal 200 can send the generated preset public key to the verification terminal 300 through the secure connection. After receiving the preset public key, the verification terminal 300 stores the preset public key and its identification information in a DTB file.

[0056] There is no strict order between steps S110 to S120 executed by the first signing terminal 100 and steps S210 to S220 executed by the second signing terminal 200; they can be executed in parallel or sequentially. In practice, it must be ensured that necessary information such as the certificate chain and preset public key are properly stored in the verification terminal 300 before the verification terminal 300 verifies the image file.

[0057] Before introducing steps S310 to S340 executed by the signature verification terminal 300, let's first introduce their application phase in the secure startup process: Currently, Secure Boot generally includes the following three stages: (1) BootROM stage: This is the first stage of the secure boot process. The code is embedded in the chip and cannot be changed. Its main function is to initialize the hardware, perform a power-on self-test (POST), and perform basic hardware environment checks. This stage sets the initial hardware state, clock, memory controller, etc., and prepares for loading the SPL in the next stage.

[0058] (2) SPL Stage: SPL is a lightweight bootloader primarily responsible for initializing the processor and key hardware components, such as the SDRAM (Synchronous Dynamic Random-Access Memory) controller. SPL can load the Uboot main image file from storage devices (such as Flash, eMMC, etc.) into memory and perform preliminary image verification. SPL code is typically concise and efficient to ensure a fast boot process.

[0059] (3) Uboot main stage: Uboot main is a complete bootloader with rich features, such as support for multiple file systems and network functions. Uboot main is mainly responsible for further initializing the hardware environment and loading the operating system kernel image into memory to prepare for the operating system to start.

[0060] Steps S310 to S340, executed by the verification terminal 300, are mainly applied to the aforementioned SPL stage. During the SPL stage, the verification terminal 300 loads the image file and, based on the key identifier attribute carried in the image file, determines the corresponding target certificate and root certificate in the certificate chain. The verification process ensures the integrity and trustworthiness of the image file, preventing illegal or tampered image files from being loaded into the system.

[0061] Step S310: When loading the image file, the signature verification terminal 300 determines the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain based on the key identifier attribute carried in the image file.

[0062] The verification terminal 300 determines the target certificate in the certificate chain using the following method: First, when loading the image file, the verification terminal 300 can extract the key identifier attribute carried in the image file. Then, it accesses the certificate chain stored in the FIT image tree file. Using the key identifier attribute, it can search for matching certificate identifier information in the certificate chain. For example, if the key identifier attribute is "ree_image1", it can search for a terminal certificate with certificate identifier information "ree_image1" in the certificate chain. After finding the corresponding terminal certificate, it can identify that terminal certificate as the target certificate.

[0063] After identifying the target certificate, the 300 verification terminal can load and parse it, extracting its issuer attribute. The issuer attribute contains unique identification information of the parent certificate that issued the certificate (such as the issuer's subject name). Then, based on the information in the issuer attribute, it can search for the parent certificate in the certificate chain; that is, it searches for certificates whose subject attribute matches the target certificate's issuer attribute. This process is repeated for each parent certificate found—loading the certificate, extracting its issuer attribute, and continuing the search in the certificate chain—until the root certificate is found. It's understandable that since the root certificate is self-signed, its issuer attribute can point to itself or be set to empty. When a certificate with a matching issuer attribute is found, it can be identified as the root certificate.

[0064] Optionally, step S310 above, which determines the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain, includes: determining the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain stored in the FIT image tree file based on the key identifier attribute carried in the image file.

[0065] After loading the FIT image tree file, the signature verification terminal 300 can identify relevant nodes in the certificate chain by parsing the FIT file content. It then searches the FIT image tree file for certificate identifier information that matches the key identifier attribute. This certificate identifier is a unique identifier for the certificate and can be the hash value of the public key, the name of the image file, or other unique identifiers. By matching strings or other unique identifiers, the certificate corresponding to the key identifier attribute can be found; this certificate is the target certificate.

[0066] Understandably, the FIT file in the existing solution is relatively easy to modify. In the above solution, the file loading post-processing mechanism of the UbootSPL open source framework is used to analyze the image and certificates in the FIT file and the relationship between the certificates and to verify the signature, thereby ensuring that the key information in the FIT file is not modified, or even if the key information in the FIT file is modified, it can be detected by the file loading post-processing mechanism and the startup will be terminated.

[0067] The certificate chain in the above scheme is stored in the FIT image tree file, which makes the management of the certificate chain more flexible and allows the above U-boot-based image verification method to be applied to more application scenarios, thus improving the flexibility of the above U-boot-based image verification method. On the other hand, during the signature verification process, the required certificate information can be quickly located and read directly from the FIT image tree file, which helps to improve the verification efficiency of the above U-boot-based image verification method.

[0068] Optionally, before step S310 above, the Uboot-based image verification method applied to the signature verification terminal 300 can also perform preliminary verification of the image file. The preliminary verification scheme may include: obtaining a pre-stored target preset public key corresponding to the key identifier attribute based on the key identifier attribute carried by the image file; verifying the signature of the image file using the target preset public key; and after the signature verification of the image file is passed, determining the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain based on the key identifier attribute carried by the image file.

[0069] The aforementioned preset public key is generated by the second signing terminal 200 and stored in the verification terminal 300, uniquely matching the key identifier attribute of the image file. In the above scheme, the verification terminal 300 can use this preset public key to perform preliminary verification of the image file's signature. Specifically: when loading the image file, the verification terminal 300 can extract the signature data and the key identifier attribute carried by the image file. The signature data can be either the content of the image file or the result encrypted with a private key. The verification terminal 300 can retrieve the corresponding preset public key based on the key identifier attribute carried by the image file, then use the preset public key to decrypt the signature of the image file, obtaining the original hash value, and recalculate the hash value for the content of the image file. Finally, the two hash values ​​are compared to see if they match. If they match, the signature verification of the image file passes, and subsequent verification is performed. Otherwise, if the two hash values ​​do not match, the signature verification of the image file is directly determined to have failed, and the loading process of the image file is terminated.

[0070] It is understood that the above preliminary verification scheme can be implemented based on the Uboot SPL open source framework. For specific implementation schemes, please refer to the Uboot SPL open source framework. This application will not repeat the details in the embodiments.

[0071] Optionally, obtaining the pre-stored target preset public key corresponding to the key identifier attribute includes: searching for the target preset public key that uniquely corresponds to the key identifier attribute in the device tree file.

[0072] After loading the DTB file, the signature verification terminal 300 parses its contents and identifies the various nodes and attributes defined in the DTB file. In the DTB file, the preset public key and public key identification information are typically stored under a specific node. The signature verification terminal 300 can locate the node storing the preset public key and public key identification information based on a predefined path or node name. Then, the signature verification terminal 300 can extract the key identification attribute and search for the public key identification information that matches the key identification attribute item in the located public key storage node. Both the key identification attribute and the public key identification information can use the name of the image file, such as ree_image1. After finding the matching public key identification information, the signature verification terminal 300 can obtain the preset public key associated with that public key identification information. This preset public key can be used for preliminary verification of the image file signature.

[0073] The above scheme can quickly locate the required public key by searching for the target preset public key that uniquely corresponds to the key identifier attribute in the device tree file, thereby reducing search time and improving the verification efficiency of the above Uboot-based image verification method.

[0074] Step S320: The signature verification terminal 300 performs self-signature verification on the root certificate, and after the self-signature verification is successful, it uses the pre-stored public key base information to verify the root certificate public key of the root certificate.

[0075] After loading the root certificate, the aforementioned signature verification terminal 300 can extract the root certificate public key and signature data. It can then use the root certificate public key to recalculate the hash value of the content in the root certificate that does not contain signature data, and use the root certificate public key to decrypt the root certificate signature to obtain the original hash value. Finally, it compares the recalculated hash value with the hash value decrypted from the signature. If they match, the self-signature verification passes, indicating that the root certificate has not been tampered with and was issued by the expected root certificate authority. If they do not match, the self-signature verification fails, and the root certificate may have been tampered with or is untrusted.

[0076] After the self-signature verification of the root certificate is successful, the verification terminal 300 can obtain the pre-stored public key base information from the OTP storage or other preset storage location. If the public key base information is the hash value of the public key, then a hash operation can be performed on the root certificate public key to obtain the hash value of the public key. Then, the calculated public key hash value is compared with the pre-stored public key base information. If the two match, the verification is successful, indicating that the root certificate public key is trustworthy and has not been tampered with; if they do not match, the verification fails, and the root certificate public key may have been tampered with or is untrustworthy.

[0077] Step S330: After the root certificate public key is verified, the signature verification terminal 300 uses the root certificate public key to verify the signature of the target certificate.

[0078] Optionally, step S330 above verifies the signature of the target certificate using the root certificate public key, including: determining the verification path from the root certificate node to the target certificate node in the certificate chain; wherein, the signature of each lower-level certificate node in the verification path is issued by the private key of the upper-level certificate node of the lower-level certificate node; starting from the lower-level certificate node of the root certificate node, verifying the signature of the certificate in each certificate node sequentially along the verification path until the signature verification of the target certificate passes; wherein, if the signature verification of the certificate in any certificate node fails, the verification is terminated and the signature verification of the image file is determined to have failed.

[0079] In the above scheme, the signature verification terminal 300 can adopt a step-by-step verification method, using the signature of the target certificate in the certificate chain for verification. Specifically: starting from the root certificate node, a verification path is determined from the root certificate node to the target certificate node. The signature of each lower-level certificate node on this verification path is issued by the private key of its upper-level certificate node. Then, starting from the lower-level certificate nodes of the root certificate node, the certificate signature in each certificate node is verified sequentially along the verification path. Specifically, the public key of the current node is used to verify the signature of its lower-level nodes. If the verification passes, the verification of its next-level node continues; if the verification fails, the entire signature verification process is terminated, and the signature verification of the image file is determined to have failed. This step-by-step verification continues until the signature verification of the target certificate passes.

[0080] The above scheme verifies the signature of each lower-level certificate node sequentially along the verification path, which can accurately identify any abnormal node on the verification path, thereby enhancing the credibility of the target certificate node and improving the security of the U-boot-based image verification method. On the other hand, the entire signature verification process is terminated immediately when the signature verification of each lower-level certificate node in the verification path fails. This mechanism can quickly identify and intercept illegal image files, which can improve the verification efficiency of the U-boot-based image verification method.

[0081] Step S340: After the signature verification of the target certificate is passed, the signature verification terminal 300 uses the target certificate public key of the target certificate to verify the signature of the image file.

[0082] The aforementioned signature verification terminal 300 can use the public key of the target certificate to decrypt the signature of the image file to obtain the original hash value, recalculate the hash value of the image file content, and then compare the hash value obtained from decrypting the signature with the recalculated hash value. If they match, the verification passes, indicating that the image file has not been tampered with and the signature is valid; otherwise, the verification fails, and the image file may have been tampered with or the signature is invalid.

[0083] Optionally, the above-mentioned Uboot-based image verification method applied to the signature verification terminal 300 may further include: after the signature verification of the image file is passed, comparing the target certificate public key with the target preset public key; if the comparison result is that the target certificate public key and the target preset public key are inconsistent, then the signature verification of the image file is determined to have failed.

[0084] Understandably, after the image file's signature verification passes, additional security verification can be performed on the target certificate's public key and the target preset public key. Specifically, the target certificate's public key comes from the target certificate in the certificate chain, while the target preset public key is the public key used during the initial verification stage of the image file. Comparing these two public keys verifies the trustworthiness of the certificate chain, ensuring that the target certificate has not been tampered with and that its public key matches the system's preset public key. If these two public keys do not match, it indicates that the certificate chain may have been tampered with, or that the image file does not match the corresponding certificate chain. In this case, even if the image file's signature verification passes, the system will still determine that the image file's signature verification failed, thus refusing to load the image file.

[0085] The above scheme, by adding a comparison step between the target certificate public key and the target preset public key after the signature verification of the image file is passed, can quickly identify whether the certificate chain has been tampered with or replaced, thereby enhancing the security of the above U-boot-based image verification method. On the other hand, by comparing the target certificate public key and the target preset public key, potential errors or attack behaviors in the certificate chain can be detected. Even if the signature verification of the image file is passed, illegal image files can still be detected and intercepted in a timely manner, thereby improving the reliability of the above U-boot-based image verification method.

[0086] like Figure 3 As shown, for ease of understanding, the following provides a specific implementation of the above U-Boot-based image verification method in a certain application scenario: Step 1: The first signing end 100 constructs the certificate chain; The main steps include: (1) Generating root key pairs: Using tools to generate the private and public key pairs for the root certificate. The root private key must be kept strictly confidential. (2) Creating root certificates: Signing the root certificate with the root private key to make it a self-signed certificate, containing the root public key and metadata. The root certificate can be named root.crt. (3) Generating intermediate key pairs: Generating private and public key pairs for the two intermediate certificates, ree.crt and tee.crt. (4) Issuing intermediate certificates: Issuing the ree.crt and tee.crt intermediate certificates with the root private key. (5) Generating terminal key pairs: Generating private and public keys for the image files ree_image1.bin, ree_image2.bin, tee_image1.bin, and tee_image2.bin. (6) Issuing terminal certificates: Issue terminal certificates ree_image1.crt and ree_image2.crt using the private key of the intermediate certificate ree.crt, and issue terminal certificates tee_image1.crt and tee_image2.crt using the private key of the intermediate certificate tee.crt. (7) Storing the certificate chain: Store the constructed certificate chain in the FIT image tree file (i.e., Figure 3 The custom top-level node certs is located in the spl.its file.

[0087] The first signing terminal 100 can also generate the hash value of the root certificate public key as the public key base information, and store the public key base information in the OTP memory of the verification terminal 300.

[0088] Step 2: The second signature terminal 200 generates a preset public key; The second signing terminal 200 generates a preset public key corresponding to the image file and binds it with the public key identification information. Specifically, it generates preset public keys ree_image1.pubkey, ree_image2.pubkey, tee_image1.pubkey, and tee_image2.pubkey corresponding to the image file ree_image1.bin, ree_image2.pubkey, tee_image1.pubkey, and tee_image2.pubkey, respectively. The preset public keys and their public key identification information are then stored in the device tree file (i.e., ...) of the signature verification terminal 300. Figure 3 In the spl_fdt file.

[0089] The second signing terminal 200 can also use the private key corresponding to the image file to sign the image file. For example, it can use the private key of ree_image1.crt to sign ree_image1.bin and generate a signature file Signature.

[0090] Step 3: The verification terminal 300 loads the image file and performs preliminary verification; The signature verification terminal loads an image file, assuming the loaded image file is ree_image1.bin. The initial verification of ree_image1.bin includes: based on the key identifier attribute (such as key-name-hint) carried in the image file ree_image1.bin, which can be set to the image file name ree_image1, the corresponding preset public key is searched in the device tree file as ree_image1.pubkey. This public key can then be used to perform initial verification of the image file's signature. After the initial verification passes, subsequent verifications are performed.

[0091] Step 4: The verification terminal (300) determines the target certificate and root certificate of the image file; The signature verification terminal 300 can determine the corresponding target certificate as ree_image1.crt based on the key identifier attribute ree_image1 in the certificate chain of the FIT image tree file ree_image1.bin. Then, starting from the target certificate ree_image1.crt, it traces upwards through the certificate chain until it finds the root certificate root.crt.

[0092] Step 5: Verify the root certificate using the verification terminal 300; The verification terminal 300 can perform self-signature verification on the root certificate root.crt to ensure its legitimacy. Then, it can use the public key base information hash (root_key) stored in the OTP storage to verify the public key of the root certificate.

[0093] Step 6: Verify the target certificate using the verification terminal 300; The signature verification terminal 300 determines that the verification path from the root certificate root.crt to the target certificate ree_image1.crt is root.crt→ree.crt→ree_image1.crt, and verifies the signature of each certificate node in sequence along the verification path until the target certificate ree_image1.crt is verified successfully.

[0094] Step 7: Verify the signature on the image file using the signature verification terminal 300; Use the public key of ree_image1.crt in the target certificate to verify the signature of the image file ree_image1.bin to ensure that the image file has not been tampered with.

[0095] Step 8: The signature verification terminal 300 performs public key comparison; After the signature verification of the image file ree_image1.bin is successful, the target certificate public key and the target preset public key ree_image1.pubkey are compared to ensure they match.

[0096] It is understandable that step three above can be implemented using the SPL framework, and steps four to eight can be implemented using the post-processing interface board_fit_image_post_process. The post-processing interface board_fit_image_post_process is an optional function in U-Boot that allows users to perform additional processing on the image file after it has been loaded into memory and before control is transferred to the kernel. The post-processing interface is essentially a function pointer that can be defined and implemented in the board-level code of U-Boot. The main functions of this interface include: (1) Providing customized processing capabilities: Different motherboards or platforms may have different processing requirements for image files. For example, some platforms may need to decrypt, decompress, or verify the image after it has been loaded. board_fit_image_post_process allows users to perform these specific operations during the image loading stage. (2) Enhancing flexibility: Through this interface, users can flexibly insert custom logic. For example, performing additional image verification (such as hardware-assisted verification), modifying the boot parameters of the image file, or performing hardware initialization, etc.

[0097] Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of this application. (Refer to...) Figure 4 The electronic device 400 includes a processor 410, a memory 420, and a communication interface 430. These components are interconnected and communicate with each other via a communication bus 440 and / or other forms of connection mechanism (not shown).

[0098] The memory 420 includes one or more (only one is shown in the figure), which may be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The processor 410 and other possible components may access the memory 420 to read and / or write data therein.

[0099] Processor 410 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The processor 410 described above can be a general-purpose processor, including a central processing unit (CPU), a microcontroller unit (MCU), a network processor (NP), or other conventional processors; it can also be a special-purpose processor, including a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0100] Communication interface 430 includes one or more (only one is shown in the figure) that can be used to communicate directly or indirectly with other devices to exchange data. For example, communication interface 430 can be an Ethernet interface; it can be a mobile communication network interface, such as an interface for 3G, 4G, or 5G networks; or it can be other types of interfaces with data transmission and reception capabilities.

[0101] One or more computer program instructions may be stored in the memory 420. The processor 410 may read and run these computer program instructions to implement the U-boot-based image verification method and other desired functions provided in the embodiments of this application.

[0102] Understandable. Figure 4 The structure shown is for illustrative purposes only; the electronic device 400 may also include more than [other components]. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof. For example, electronic device 400 can be a single server (or other device with computing power), a combination of multiple servers, a cluster of a large number of servers, etc., and can be either a physical device or a virtual device.

[0103] This application also provides a computer-readable storage medium storing computer program instructions. These instructions are read and executed by a processor to perform the U-boot-based image verification method provided in this application. For example, the computer-readable storage medium can be implemented as follows: Figure 4 The memory 420 in the electronic device 400, or a separate storage product (such as a USB flash drive, portable hard drive, etc.).

[0104] This application also provides a computer program product, which includes computer program instructions. These computer program instructions are read and executed by a processor to perform the U-Boot-based image verification method provided in this application. For example, these computer program instructions can be stored in... Figure 4 The memory 420 in the electronic device 400 is located inside the memory, or it is stored in a separate storage product (such as a USB flash drive, portable hard drive, etc.).

[0105] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0106] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0108] It should be noted that if the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0109] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0110] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A Uboot-based image verification method, characterized in that, The method is applied to a Uboot-based image verification system, the verification system comprises a signature verification end, and the method comprises the following steps: When loading an image file, the signature verification end determines a corresponding target certificate and a root certificate to which the target certificate belongs in a certificate chain based on a key identifier attribute carried by the image file; The signature verification end performs self-signature verification on the root certificate, and after the self-signature verification passes, the root certificate public key of the root certificate is verified by using pre-stored public key reference information; After the root certificate public key verification passes, the signature of the target certificate is verified by using the root certificate public key; After the signature verification of the target certificate passes, the signature of the image file is verified by using the target certificate public key of the target certificate.

2. The Uboot-based image verification method of claim 1, wherein, The method further comprises the following steps: After the signature verification of the image file passes, the signature verification end compares the target certificate public key with a target preset public key; wherein the target preset public key is pre-stored and corresponds to the key identifier attribute; the target preset public key is used to preliminarily verify the signature of the image file; If the comparison result is that the target certificate public key and the target preset public key are inconsistent, it is determined that the signature verification of the image file fails.

3. The Uboot-based image verification method of claim 2, wherein, The target preset public key comprises the following steps: The target preset public key uniquely corresponding to the key identifier attribute is found in a device tree file.

4. The Uboot-based image verification method of claim 1, wherein, The step of verifying the signature of the target certificate by using the root certificate public key comprises the following steps: A verification path from a root certificate node to a target certificate node is determined in the certificate chain; wherein the signature of each lower-level certificate node in the verification path is issued by the private key of the upper-level certificate node of the lower-level certificate node; Starting from the lower-level certificate node of the root certificate node, the signature of the certificate in each certificate node is verified along the verification path, until the signature verification of the target certificate passes; wherein if the signature verification of any certificate in the certificate node fails, the signature verification is terminated, and it is determined that the signature verification of the image file fails.

5. The Uboot-based image verification method of claim 1, wherein, The step of determining the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain based on the key identifier attribute carried by the image file comprises the following steps: Based on the key identifier attribute carried by the image file, the corresponding target certificate and the root certificate to which the target certificate belongs are determined in the certificate chain stored in the FIT image tree file.

6. The Uboot-based image verification method of claim 1, wherein, The verification system further comprises a first signature end, and the method further comprises the following steps: The first signature end constructs a certificate chain; wherein the certificate chain comprises a root certificate node and a terminal node; the root certificate node comprises a self-signed root certificate; the terminal node comprises a certificate of an image file; the certificate of the image file comprises certificate identifier information uniquely matched with the key identifier attribute carried by the image file; The first signature end stores the certificate chain in the signature verification end.

7. The Uboot-based image verification method of claim 6, wherein, The step of storing the certificate chain in the signature verification end comprises the following steps: The certificate chain is stored in the top node of the FIT image tree file of the signature verification end.

8. The Uboot-based image verification method of claim 6, wherein, The method further comprises the following steps: The first signature end generates public key reference information of the root certificate, and stores the public key reference information in the OTP memory of the signature verification end; wherein the public key reference information is used to verify the root certificate public key of the root certificate. 9.The Uboot-based image verification method according to any one of claims 1-8, characterized in that, The verification system further comprises a second signature end, and the method further comprises: The second signature end generates a preset public key, and binds the preset public key with public key identification information; wherein the preset public key is used to verify the signature of the image file; and the public key identification information is identification information uniquely matched with the key identification attribute carried by the image file; The second signature end stores the preset public key and the public key identification information in the signature verification end.

10. The Uboot-based image verification method of claim 9, wherein, The storing of the preset public key and the public key identification information in the signature verification end comprises: Storing the preset public key and the public key identification information in the device tree file of the signature verification end.

11. A Uboot-based image verification system, characterized in that, Comprise: The signature verification end is used to, when loading the image file, determine the corresponding target certificate and the root certificate to which the target certificate belongs in the certificate chain based on the key identification attribute carried by the image file; Self-signature verification is performed on the root certificate, and after the self-signature verification passes, the root certificate public key of the root certificate is verified by using the pre-stored public key reference information; after the root certificate public key verification passes, the signature of the target certificate is verified by using the root certificate public key; After the signature verification of the target certificate passes, the signature of the image file is verified by using the target certificate public key of the target certificate.

12. The Uboot-based image verification system of claim 11, wherein, The verification system further comprises: The first signature end is used to construct the certificate chain; wherein the certificate chain comprises a root certificate node and a terminal node; the root certificate node comprises a self-signed root certificate; and the terminal node comprises a certificate of an image file; the certificate of the image file comprises certificate identification information uniquely matched with the key identification attribute carried by the image file.

13. The Uboot-based image verification system of claim 11 or 12, wherein, The verification system further comprises: The second signature end is used to generate a preset public key, and bind the preset public key with public key identification information; wherein the preset public key is used to verify the signature of the image file; and the public key identification information is identification information uniquely matched with the key identification attribute carried by the image file; and the preset public key and the public key identification information are stored in the signature verification end.

14. An electronic device, comprising: Comprise: A processor, a memory and a communication bus, wherein the processor and the memory complete mutual communication through the communication bus; The memory stores program instructions executable by the processor, and the processor calling the program instructions can execute the method in any one of claims 1-10.

15. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions, and the computer instructions make the computer execute the method in any one of claims 1-10 when the computer runs the computer instructions.

16. A computer program product, characterised in that, The computer program product comprises a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1-10.

Images