A secure booting method and device based on a trusted root, equipment and readable medium

Abstract

The application discloses a kind of based on the security starting method of trusted root, comprising the following steps: all mirror packages are signed by ring signature algorithm, and public key digest is used as trusted root to generate release mirror file;In response to server start, check whether the trusted root in the release mirror file is consistent with the storage in chip, to verify the integrity of the trusted root;In response to the trusted root in the release mirror file being consistent with the storage in chip, then further based on the ring signature algorithm and the trusted root to the release mirror file is verified;And in response to the release mirror file being verified based on the ring signature algorithm and the trusted root, then to the release mirror file is carried out security starting process.The application also discloses a kind of based on the security starting device of trusted root, computer equipment and readable storage medium.The application realizes that trusted root leaks does not need to be returned to factory maintenance, just needs to upgrade mirror file.

Description

Technical Field

[0001] The present invention relates to the field of trusted computing technology, and in particular to a secure boot method, apparatus, device and readable medium based on a trusted root. Background Art

[0002] In computing and communications systems, end devices are often servers and storage devices. Effective security can only be achieved through comprehensive security measures, encompassing chips, motherboards, firmware, and underlying software. Trusted computing technology has been extensively researched to address this issue. Its fundamental concept is to first establish a root of trust within the system based on hardware security modules. The trustworthiness of the root of trust is ensured by physical, technical, and management security. A chain of trust is then established, extending from the root of trust to the hardware and software platforms, to the operating system, and finally to applications. This trust is then extended to the entire computer system, ensuring trusted boot for the entire system. The integrity and legitimacy of the hardware, firmware, virtualization, operating system, and application software of embedded terminals, storage devices, and servers is protected by pre-boot measurement to prevent tampering attacks or anomalies.

[0003] The currently popular solution is to use digital signature technology to sign the firmware when the version is released. Electronic device manufacturers generate a public-private key pair, sign the original firmware package with the private key, and then release the image package. A trusted storage area stores information such as the ROT (root of trust) and the location of the boot header. The boot header also contains information such as the key location and signature location. When the device boots the firmware, a fixed program reads the boot header and uses the ROT to measure it; then the fixed program reads the boot loader image and uses the ROT to measure it; finally, the boot loader measures other images to prevent tampering with the boot process. Only firmware packages that pass the signature verification can be securely booted.

[0004] The first existing technology adopts the above-mentioned popular solution, but this specific trusted area is implemented by hardware OTP or a protected flash memory, which contains a public key (as ROT) generated by the electronic device manufacturer, boot header location and other information. In addition, the boot header contains information such as key location and signature location. The first existing technology solves the anti-tampering problem during the startup process, but if the private key is leaked, the server must be returned to the factory for a trusted root upgrade, and the one-time ROT can only be replaced. And there is only one ROT for verification, and the chance of being guessed is high. In addition, if a flash memory is used as the trusted area, the write protection mechanism will fail when the device is restarted, and this area can be tampered with and is untrustworthy.

[0005] Another popular solution is to implement a hardware root of trust within the firmware chip, which can typically store several, for example, eight, roots of trust. The manufacturer of the electronic device generates eight public-private key pairs, signs the original firmware package with one of the private keys, and then releases the image package. The corresponding eight public keys are stored within the firmware chip as roots of trust. When the device boots, the first root of trust is used to decrypt the signed image package for measurement and signature verification. If verification fails, the next root of trust is used for verification until verification succeeds or all roots of trust are verified. Only firmware packages that pass signature verification can be correctly booted by the system.

[0006] The above-mentioned existing technologies have the following problems: the multiple trusted roots stored in the hardware are easily guessed; when the private key is leaked, the device needs to be returned to the factory to re-burn the trusted root summary inside the firmware chip, which has high equipment maintenance costs and low maintenance efficiency; in order to support the effective space to store a large number of trusted roots, the cost is high; the verification attempt requires trying the ROT verification one by one, which is a time-consuming process; the flash write protection fails on restart. Summary of the Invention

[0007] In view of this, the purpose of the embodiments of the present invention is to propose a secure boot method, device, equipment and readable medium based on a trusted root, so that if the trusted root is leaked, there is no need to return it to the factory for repair, only the image file needs to be upgraded; by saving the trusted root public key summary, the number of trusted roots saved is increased.

[0008] Based on the above purpose, one aspect of an embodiment of the present invention provides a secure boot method based on a trusted root, comprising the following steps: signing all image packages through a ring signature algorithm, and using the public key digest as a trusted root to generate a release image file; in response to server startup, checking whether the trusted root in the release image file is consistent with that stored in the chip to verify the integrity of the trusted root; in response to the trusted root in the release image file being consistent with that stored in the chip, further verifying the release image file based on the ring signature algorithm and the trusted root; and in response to the verification of the release image file based on the ring signature algorithm and the trusted root being passed, performing a secure boot process on the release image file.

[0009] In some embodiments, the method further includes: in response to failure of verification of the release image file based on the ring signature algorithm and the trusted root, prohibiting a secure boot process for the release image file and sending a boot failure alarm.

[0010] In some embodiments, signing all image packages using a ring signature algorithm includes: selecting a preset number of public-private key pairs from multiple public-private key pairs, and generating a signature ring based on the multiple public-private key pairs; selecting a private key from the multiple public-private key pairs, and signing the image file based on the private key and the signature ring.

[0011] In some embodiments, signing all mirror packages using a ring signature algorithm includes: calculating a digest value of the mirror file and parameters in the mirror package based on a one-way hash algorithm, and signing the digest value in the mirror package with a private key based on an asymmetric encryption algorithm.

[0012] In some embodiments, the method further comprises: establishing a boot sequence of a trusted platform for running the verification application; and adding signature verification to each stage of the boot process based on the boot sequence.

[0013] In some implementations, the method further includes: storing the trusted root in an OTP storage area of ​​the firmware chip, wherein the OTP storage area can only be accessed through an OTP controller to obtain the trusted root.

[0014] On the other hand, an embodiment of the present invention provides a secure boot device based on a trusted root, including: a first module, configured to sign all image packages through a ring signature algorithm, and use the public key digest as a trusted root to generate a release image file; a second module, configured to check whether the trusted root in the release image file is consistent with the one stored in the chip in response to server startup, so as to verify the integrity of the trusted root; a third module, configured to verify the release image file based on the ring signature algorithm and the trusted root in response to the trusted root in the release image file being consistent with the one stored in the chip; and a fourth module, configured to perform a secure boot process on the release image file in response to the verification of the release image file based on the ring signature algorithm and the trusted root being passed.

[0015] In another aspect of the embodiments of the present invention, a computer device is provided, comprising: at least one processor; and a memory, wherein the memory stores computer instructions that can be run on the processor, and the steps of implementing the method when the instructions are executed by the processor include: signing all image packages through a ring signature algorithm, and using the public key digest as a trusted root to generate a release image file; in response to server startup, checking whether the trusted root in the release image file is consistent with that stored in the chip to verify the integrity of the trusted root; in response to the trusted root in the release image file being consistent with that stored in the chip, further verifying the release image file based on the ring signature algorithm and the trusted root; and in response to the verification of the release image file based on the ring signature algorithm and the trusted root being passed, performing a secure startup process on the release image file.

[0016] In some embodiments, the step further includes: in response to failure of verification of the release image file based on the ring signature algorithm and the trusted root, prohibiting a secure boot process for the release image file and sending a boot failure alarm.

[0017] In some embodiments, signing all image packages using a ring signature algorithm includes: selecting a preset number of public-private key pairs from multiple public-private key pairs, and generating a signature ring based on the multiple public-private key pairs; selecting a private key from the multiple public-private key pairs, and signing the image file based on the private key and the signature ring.

[0018] In some embodiments, signing all mirror packages using a ring signature algorithm includes: calculating a digest value of the mirror file and parameters in the mirror package based on a one-way hash algorithm, and signing the digest value in the mirror package with a private key based on an asymmetric encryption algorithm.

[0019] In some embodiments, the steps further include: establishing a boot sequence of a trusted platform for running the verification application; and adding signature verification to each stage of the boot process based on the boot sequence.

[0020] In some implementations, the steps further include: storing the trusted root in an OTP storage area of ​​the firmware chip, wherein the OTP storage area can only be accessed through an OTP controller to obtain the trusted root.

[0021] According to another aspect of the embodiments of the present invention, a computer-readable storage medium is provided, which stores a computer program that implements the above method steps when executed by a processor.

[0022] The present invention has at least the following beneficial technical effects: it solves the problem that multiple trusted roots stored in the hardware are easily guessed. When a trusted root leak occurs, the public and private key ring members that make up the signature can be changed, and the mirror file can be released, flexibly solving the private key leakage problem; when the private key is leaked, there is no need to return the device to the factory to re-burn the trusted root digest (i.e., the public key digest) inside the firmware chip, which solves the equipment maintenance cost and improves the maintenance timeliness; in order to support the effective space to store a large number of trusted roots, the firmware chip stores the trusted root digest (i.e., the public key digest) instead of the public key itself, which reduces costs; the ring signature algorithm is used to verify once to identify whether it is trustworthy, which solves the time-consuming process of attempting verification in the existing technology; the trusted root is truly protected inside the chip, which solves the problem of flash write protection failing upon restart. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0024] Figure 1 A schematic diagram of an embodiment of a secure boot method based on a root of trust provided by the present invention;

[0025] Figure 2 A schematic diagram of a signature method for an image file of a secure boot method based on a root of trust provided by the present invention;

[0026] Figure 3 A schematic diagram of a packaging method for a release package of the secure boot method based on a root of trust provided by the present invention;

[0027] Figure 4 A schematic diagram of a firmware chip trusted root management module for the trusted root-based secure boot method provided by the present invention;

[0028] Figure 5 A schematic diagram of an embodiment of a secure boot device based on a trusted root provided by the present invention;

[0029] Figure 6 A schematic diagram of an embodiment of a computer device provided by the present invention;

[0030] Figure 7 A schematic diagram of an embodiment of a computer-readable storage medium provided by the present invention. DETAILED DESCRIPTION

[0031] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the embodiments of the present invention are further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

[0032] It should be noted that all expressions using "first" and "second" in the embodiments of the present invention are for distinguishing two non-identical entities with the same name or non-identical parameters. It can be seen that "first" and "second" are only for the convenience of expression and should not be understood as limitations on the embodiments of the present invention. Subsequent embodiments will not explain this one by one.

[0033] Based on the above objectives, a first aspect of an embodiment of the present invention provides an embodiment of a secure boot method based on a root of trust. Figure 1 FIG. 1 is a schematic diagram of an embodiment of a secure boot method based on a trusted root provided by the present invention. Figure 1 As shown, the secure boot method based on a trusted root according to an embodiment of the present invention includes the following steps:

[0034] 001. Sign all image packages using the ring signature algorithm and use the public key digest as the root of trust to generate the release image file;

[0035] 002. In response to the server startup, check whether the trusted root in the published image file is consistent with the one stored in the chip to verify the integrity of the trusted root;

[0036] 003. In response to the trusted root in the published image file being consistent with the one stored in the chip, further verifying the published image file based on the ring signature algorithm and the trusted root; and

[0037] 004. In response to the verification of the release image file based on the ring signature algorithm and the trusted root being successful, a secure boot process is performed on the release image file.

[0038] In this embodiment, if the firmware chip comes with N public key digests, ring signature technology is used when the firmware image file is generated. M public key pairs are selected from the N public key pairs to form a signature ring (N ≥ M). The firmware image file is signed using the kth private key and the M public keys (k belongs to M). During server startup, M public key digests are selected from the N public key digests stored in the firmware chip based on parameters to form a ring signature ring. First, the M public key digests in the published image file are checked to see if they are the same as the digests stored in the chip, verifying the integrity of the M public keys. Then, the signed component image file is verified using these M public keys and the ring signature algorithm. If all verifications pass, the firmware image file is confirmed to be legitimate and intact, and the secure boot process for this component continues. If any verification fails, it indicates that the firmware image file has been tampered with, and the boot process fails. This verification process applies to the boot process from the boot header, boot image, to other components in the trust chain (such as the trusted kernel image file, trusted application web, and rootfs image file). This method doesn't fix the ring signature members. Based on the actual risk of trusted root leaks, the specific members of the ring signature are published as parameters with each version release (i.e., how to select M public-private key pairs from N). This method makes it more difficult to guess which valid root among the N trusted roots within the firmware chip was used for signing, using M members to jointly participate in signature verification. The firmware chip stores the public key digests of the N trusted roots, with the specific public keys contained within the image file.

[0039] In this embodiment, when a ROT private key leak occurs, or the ROT is used for too long, the ring members that make up the signature can be changed and the image file can be released to flexibly solve the private key leakage problem. Using the N ROT summaries stored inside the firmware chip, according to the serial number of the ROT not used recorded in the parameter, the m public key summaries (N≥M) that make up the ring signature are extracted to verify the integrity of the public key in the image file. A method for verifying the boot image file and other subsequent image files using a ring signature algorithm. This method verifies only once each time, and does not require polling each public key each time, which increases the difficulty of guessing the ROT and shortens the verification time. What is stored in the OTP is the summary of multiple public keys, not the public key itself, which significantly reduces the size requirement of the OTP and reduces costs. When the private key is leaked, there is no need to return the device to the factory to re-burn the public key summary inside the OTP, which solves the equipment maintenance cost and improves the maintenance time. Using M public keys for verification increases the difficulty of guessing a valid private key.

[0040] In some embodiments of the present invention, the method further includes: in response to failure of verification of the release image file based on the ring signature algorithm and the trusted root, prohibiting the secure boot process for the release image file and sending a boot failure alarm.

[0041] In some embodiments of the present invention, signing all image packages using a ring signature algorithm includes: selecting a preset number of public-private key pairs from multiple public-private key pairs, and generating a signature ring based on the multiple public-private key pairs; selecting a private key from the multiple public-private key pairs, and signing the image file based on the private key and the signature ring.

[0042] In some embodiments of the present invention, signing all mirror packages using a ring signature algorithm includes: calculating a digest value of the mirror file and parameters in the mirror package based on a one-way hash algorithm, and signing the digest value in the mirror package with a private key based on an asymmetric encryption algorithm.

[0043] In some embodiments of the present invention, the method further comprises: establishing a boot sequence of a trusted platform for running the verification application; and adding signature verification to each stage of the boot process based on the boot sequence.

[0044] In some embodiments of the present invention, the method further includes: storing the trusted root in an OTP storage area of ​​the firmware chip, where the OTP storage area can only be accessed through an OTP controller to obtain the trusted root.

[0045] In some embodiments of the present invention, in addition to being applied to the secure booting of various server firmware, the method can also be applied to other embedded devices, such as switches and routers, where upper-layer applications are booted by underlying OTP signatures.

[0046] The following further describes the specific implementation of the present invention based on specific examples, including: firmware image file packaging, secure boot process measurement, and ROT management module within the firmware chip.

[0047] Secure boot measures include first establishing a boot sequence for a trusted platform to run verified applications. This boot sequence resides in a protected hardware area within the firmware chip. It begins with an immutable sequence and uses the on-chip hardware ROT (RoT) to verify software code, ensuring only authorized software code executes. The boot sequence adds signature verification to each stage of the boot process to ensure that all software images are verified before the device executes. The server firmware BMC boot sequence places the device in a known secure state, such as the ARM in reset. It then digitally authenticates the boot image file to ensure its integrity before copying it from flash to memory. The boot image contains a list of trusted images requiring signature verification, such as the trusted kernel image, trusted application web, and rootfs image. Only after an image's digital signature verification passes can the ARM be allowed to load the image and then verify the next image. If the image is incomplete or tampered with, the ARM is prevented from loading the image, and verification ends. Users can configure the boot process to enable or disable risky boot.

[0048] The packaging of firmware image files includes: when the image files are released by the manufacturer, the ring signature algorithm is used to sign all image packages and package them according to a certain format. Figure 2 FIG. 1 is a schematic diagram showing a signature method for an image file of a secure boot method based on a trusted root provided by the present invention. Figure 2 As shown, the algorithm used to calculate the digest of the Image and Other parameters can be a one-way hash algorithm such as SHA256 or SHA384. The private key used to sign the digest value can be a strong asymmetric encryption algorithm such as RAS or ECC. Using SHA384 and RAS as examples, ROT is the RAS public key.

[0049] Image is the actual image file used, such as a boot image file or kernel image file. Other parameters record parameters such as the digest algorithm, whether the image file is encrypted, the encryption algorithm, and the IV value. Each image file has independent parameters but shares a set of ring signature members. All images are then packaged, and the header and tail areas are added. The header records parameters required to verify integrity and legitimacy, as well as some information about the ROT, such as the ROT sequence numbers (NM) of the non-ring signature members in the N ROTs, the public keys of the M members participating in the ring signature, the asymmetric encryption algorithm RAS, and the algorithm and parameters for calculating the digest of the header and all images (if other asymmetric algorithms are used). The tail records the signature information, which is the signature of the header and all images. Figure 3Shown is a schematic diagram of a packaging method for a release package of a secure boot method based on a root of trust provided by the present invention.

[0050] refer to Figure 2 and Figure 3 Before the firmware image file is released, each image file will be processed. First, the sha384 digest calculation will be performed on the Image and other parameters to obtain the Digest, that is, Digest = sha (Image + Other parameter).

[0051] In this article, the device manufacturer can generate N RSA public-private keys (pk i ,sk i ). i The summary of pk, i = 1, 2, ..., n, is stored inside the chip. i and sk i , i=1,2,...,n,are stored safely in the manufacturer. According to the NM ROT numbers recorded in the header that do not participate in the calculation, a ring is formed (M public and private key pairs, where N≥M). Given a ring ∪={U1,U2,...U m}, the public key-private key pair of each user in the ring is (pk i ,sk i ), i = 1, 2, ..., m.

[0052] Ring signature generation algorithm ring-sign. Its input is the message to be signed m, the public key pk of all members in the ring i , i = 1, 2, ..., m, the private key sk of the real signer k The output is U k Ring signature 6 for message m. Note: δ←ring-sign(m, pk1, ...pk m ,sk k ). Specifically for the above figure, it is Signature←ring-sign(Digest, pk1, ...pk m ,sk k ). The entire release package is signed in the same way.

[0053] Figure 4 FIG. 1 is a schematic diagram of a firmware chip trusted root management module for a secure boot method based on a trusted root provided by the present invention. Figure 4As shown in Figure 1, the ROT management module within the firmware chip includes: The firmware chip ROT management module manages all ROT summaries stored within the firmware chip. The firmware chip also includes a built-in One Time Programmable (OTP) memory area, which stores the ROT. The size of this area determines the number of ROT summaries supported; this article assumes that N ROT summaries are supported. This OTP memory area can be factory-programmed with ROT summary values. After leaving the factory, write protection is enabled, preventing modification of the OTP memory area. The OTP memory cannot be directly accessed via the Jtag port, firmware, or other means; access to the ROT must be performed through OTPcontrol.

[0054] The microprocessor executes the code stored in ROM, which represents the BMC boot sequence. The boot image file is read into SRAM, and the boot controller reads the secure boot header to begin signature verification of the boot image file. The microprocessor calculates digest value A from the m public keys in the boot image file. It then reads digest value B from the M public keys in the OTP (excluding the NM ROT keys that are not involved in the calculation). A and B are compared. If they match, the public keys are complete and authentic. The microprocessor then uses a ring signature algorithm with these M public keys and the Signature field in the tail to obtain A1. The microprocessor uses the digest algorithm recorded in the header to calculate the digest value of the header and all images, obtaining B1. A1 and B1 are compared; if they are equal, the measurement is successful. The boot image file is then measured using the ring signature algorithm with these M public keys and the Signature field of the input firmware image file to obtain A2. The microprocessor uses the sha386 algorithm to calculate the digest value of the Image and Other parameters in the input firmware image file, obtaining B2. A2 and B2 are compared; if they are equal, the measurement is successful. After successful measurement, the CPU is enabled for access, the CPU is brought out of reset, and the CPU is redirected to access the boot image file in internal SRAM. Finally, the boot process verifies each image file in its list of required verifications using the same verification method as described above. If any measurement fails, secure boot fails, and the user can choose to start with risk or disable boot based on the configuration.

[0055] Ring signature verification algorithm ring-verify. Its input is the message signature to be verified (m, δ), the public keys pk of all members in the ring i , i = 1, 2, ..., m. Its output is 0 or 1, where 1 indicates that the signature is valid and 0 indicates that the signature is invalid. It is written as: 1 or 0←ring-verify(m, δ, pk1, ...pk m). For the example in this article, it is 1or0←- ring-verify(Sha384(Image+Other parameter), Signature, pk1, ...pk m ).

[0056] During secure boot verification, the verification of a specific image file is the same as that of the entire release package. The digest algorithm is derived from the header and other parameters. Members not participating in the ring signature are numbered in the header (NM, with numbers ranging from 1 to N, determined based on the risk of ROT leakage during release). Therefore, the ring signature consists of M members (N ≥ M).

[0057] It should be pointed out in particular that the various steps in the various embodiments of the above-mentioned secure boot method based on a trusted root can be cross-linked, replaced, added, or deleted with each other. Therefore, these reasonable permutations, combinations, and transformations of the secure boot method based on a trusted root should also fall within the scope of protection of the present invention, and the scope of protection of the present invention should not be limited to the embodiments.

[0058] Based on the above objectives, a second aspect of an embodiment of the present invention provides a secure boot device based on a trusted root. Figure 5 FIG. 1 is a schematic diagram of an embodiment of a secure boot device based on a trusted root provided by the present invention. Figure 5 As shown, the secure boot device based on the trusted root of an embodiment of the present invention includes the following modules: a first module 011, configured to sign all image packages through a ring signature algorithm, and use the public key digest as the trusted root to generate a release image file; a second module 012, configured to check whether the trusted root in the release image file is consistent with the one stored in the chip in response to server startup, so as to verify the integrity of the trusted root; a third module 013, configured to verify the release image file based on the ring signature algorithm and the trusted root in response to the trusted root in the release image file being consistent with the one stored in the chip; and a fourth module 014, configured to perform a secure boot process on the release image file in response to the verification of the release image file based on the ring signature algorithm and the trusted root being passed.

[0059] Based on the above objectives, a third aspect of an embodiment of the present invention provides a computer device. Figure 6 FIG. 1 is a schematic diagram of an embodiment of a computer device provided by the present invention. Figure 6As shown, the computer device of the embodiment of the present invention includes the following devices: at least one processor 021; and a memory 022, the memory 022 stores computer instructions 023 that can be run on the processor, and the steps of implementing the method when the instructions are executed by the processor include: signing all image packages through a ring signature algorithm, and using the public key digest as a trusted root to generate a release image file; in response to the server startup, checking whether the trusted root in the release image file is consistent with the one stored in the chip to verify the integrity of the trusted root; in response to the trusted root in the release image file being consistent with the one stored in the chip, further verifying the release image file based on the ring signature algorithm and the trusted root; and in response to the verification of the release image file based on the ring signature algorithm and the trusted root being passed, performing a secure startup process on the release image file.

[0060] In some embodiments of the present invention, the method further includes: in response to failure of verification of the release image file based on the ring signature algorithm and the trusted root, prohibiting the secure boot process for the release image file and sending a boot failure alarm.

[0061] In some embodiments of the present invention, signing all image packages using a ring signature algorithm includes: selecting a preset number of public-private key pairs from multiple public-private key pairs, and generating a signature ring based on the multiple public-private key pairs; selecting a private key from the multiple public-private key pairs, and signing the image file based on the private key and the signature ring.

[0062] In some embodiments of the present invention, signing all mirror packages using a ring signature algorithm includes: calculating a digest value of the mirror file and parameters in the mirror package based on a one-way hash algorithm, and signing the digest value in the mirror package with a private key based on an asymmetric encryption algorithm.

[0063] In some embodiments of the present invention, the method further comprises: establishing a boot sequence of a trusted platform for running the verification application; and adding signature verification to each stage of the boot process based on the boot sequence.

[0064] In some embodiments of the present invention, the method further includes: storing the trusted root in an OTP storage area of ​​the firmware chip, where the OTP storage area can only be accessed through an OTP controller to obtain the trusted root.

[0065] According to another aspect of the embodiments of the present invention, a computer-readable storage medium is provided, which stores a computer program that implements the above method steps when executed by a processor.

[0066] The present invention also provides a computer-readable storage medium. Figure 7 FIG. 1 is a schematic diagram of an embodiment of a computer-readable storage medium provided by the present invention. Figure 7As shown, the computer-readable storage medium 031 stores a computer program 032 that performs the above method when executed by a processor.

[0067] Finally, it should be noted that those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The program of the secure boot method based on the root of trust can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the storage medium of the program can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc. The above-mentioned computer program embodiment can achieve the same or similar effects as any of the corresponding aforementioned method embodiments.

[0068] In addition, the method disclosed in the embodiment of the present invention can also be implemented as a computer program executed by a processor, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the above functions defined in the method disclosed in the embodiment of the present invention are performed.

[0069] In addition, the above method steps and system units can also be implemented using a controller and a computer-readable storage medium for storing a computer program that enables the controller to implement the above steps or unit functions.

[0070] It will also be appreciated by those skilled in the art that the various exemplary logic blocks, modules, circuits and algorithmic steps described in conjunction with the disclosure herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, a general description has been given of the functions of various schematic components, blocks, modules, circuits and steps. Whether this function is implemented as software or hardware depends on specific applications and the design constraints imposed on the entire system. Those skilled in the art can implement the function in various ways for each specific application, but this implementation decision should not be interpreted as causing a departure from the disclosed scope of the embodiments of the present invention.

[0071] In one or more exemplary designs, the function can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the function can be stored as one or more instructions or codes on a computer-readable medium or transmitted via a computer-readable medium. Computer-readable media include computer storage media and communication media, and the communication media include any media that helps to transmit a computer program from one location to another. The storage medium can be any available medium that can be accessed by a general or special-purpose computer. As an example and not limitation, the computer-readable medium can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to carry or store the required program code in the form of instructions or data structures and can be accessed by a general or special-purpose computer or a general or special-purpose processor. In addition, any connection can be appropriately referred to as a computer-readable medium. For example, if a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves are used to send software from a website, server, or other remote source, the above-mentioned coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are all included in the definition of medium. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0072] The above are exemplary embodiments disclosed in the present invention, but it should be noted that various changes and modifications may be made without departing from the scope of the embodiments disclosed in the claims. The functions, steps and / or actions of the method claims according to the disclosed embodiments described herein do not need to be performed in any particular order. In addition, although the elements disclosed in the embodiments of the present invention may be described or required in individual form, they may also be understood as multiple unless expressly limited to the singular.

[0073] It should be understood that, as used herein, the singular forms "a" and "an" are intended to include the plural forms as well, unless the context clearly supports an exception. It should also be understood that, as used herein, "and / or" is intended to include any and all possible combinations of one or more of the associated listed items.

[0074] The serial numbers of the embodiments disclosed in the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0075] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by a program instructing the relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk, or an optical disk, etc.

[0076] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the disclosure of the embodiments of the present invention (including the claims) is limited to these examples. Within the spirit of the embodiments of the present invention, the technical features of the above embodiments or different embodiments may be combined, and there are many other variations of different aspects of the above embodiments of the present invention, which are not provided in detail for the sake of simplicity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present invention should be included in the scope of protection of the embodiments of the present invention.

Claims

1. A secure boot method based on a trusted root, characterized in that: The following steps are involved: All image packages are signed using a ring signature algorithm, and the public key digest is used as the root of trust to generate the release image file. In response to the server being started, checking whether the trusted root in the published image file is consistent with that stored in the chip to verify the integrity of the trusted root; In response to the trusted root in the release image file being consistent with the one stored in the chip, further verifying the release image file based on the ring signature algorithm and the trusted root; as well as In response to verification of the release image file based on the ring signature algorithm and the trusted root being successful, performing a secure boot process on the release image file; Among them, signing all image packages through the ring signature algorithm includes: selecting a preset number of public-private key pairs from multiple public-private key pairs, and generating a signature ring with a non-fixed composition based on the multiple public-private key pairs; selecting a private key from the multiple public-private key pairs corresponding to the signature ring, and signing the image file based on the private key and the signature ring.

2. The secure boot method based on a trusted root according to claim 1, wherein: Also includes: In response to failure of verification of the release image file based on the ring signature algorithm and the trusted root, prohibiting a secure boot process for the release image file and sending a boot failure alarm.

3. The secure boot method based on a trusted root according to claim 1, wherein: Signing all mirror packages using the ring signature algorithm includes: A digest value is calculated for the image file and parameters in the image package based on a one-way hash algorithm, and a private key signature is performed on the digest value in the image package based on an asymmetric encryption algorithm.

4. The secure boot method based on a trusted root according to claim 1, wherein: Also includes: Establishing a boot sequence for a trusted platform to run verification applications; Add signature verification to each stage of the boot process based on the boot sequence.

5. The secure boot method based on a trusted root according to claim 1, wherein: Also includes: The trusted root is stored in the OTP storage area of ​​the firmware chip, and the OTP storage area can only be accessed through the OTP controller to obtain the trusted root.

6. A secure boot device based on a trusted root, characterized in that: include: The first module is configured to sign all image packages using a ring signature algorithm and use the public key digest as a trusted root to generate a release image file; A second module is configured to check, in response to the server being started, whether the trusted root in the release image file is consistent with that stored in the chip, so as to verify the integrity of the trusted root; A third module is configured to verify the published image file based on the ring signature algorithm and the trusted root in response to the trusted root in the published image file being consistent with the one stored in the chip; as well as A fourth module is configured to perform a secure boot process on the release image file in response to passing the verification of the release image file based on the ring signature algorithm and the trusted root; Among them, signing all image packages through the ring signature algorithm includes: selecting a preset number of public-private key pairs from multiple public-private key pairs, and generating a signature ring with a non-fixed composition based on the multiple public-private key pairs; selecting a private key from the multiple public-private key pairs corresponding to the signature ring, and signing the image file based on the private key and the signature ring.

7. The secure boot device based on a trusted root according to claim 6, characterized in that: The fourth module is further configured to: In response to failure of verification of the release image file based on the ring signature algorithm and the trusted root, prohibiting a secure boot process for the release image file and sending a boot failure alarm.

8. A computer device, characterized in that: include: at least one processor; as well as A memory storing computer instructions executable on the processor, wherein the instructions, when executed by the processor, implement the steps of the method according to any one of claims 1 to 5.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images