Security Boot Method, Device, Electronic Device and Storage Medium Based on Linux System

Abstract

The present invention discloses a secure boot method, device, electronic device and computer-readable storage medium based on the Linux system. The method includes: reading the hash value of the RSA public key in the OTP; using the hash value of the RSA public key in the OTP to verify the signature of the uboot to obtain a first verification result; when the first verification result indicates that the verification is passed, verifying the header signature of the kernel to obtain a second verification result; when the second verification result indicates that the verification is passed, verifying the specified file in the rootfs to obtain a third verification result; when the third verification result indicates that the verification is passed, verifying the files in the system. By the present invention, the problem that in the prior art, the Linux system startup verification needs to encrypt each partition image, decrypt and verify step by step, which consumes a lot of storage resources, is solved, and the storage resources are saved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer data security, and particularly relates to a secure boot method, device, electronic device, and computer-readable storage medium based on a Linux system. Background Art

[0002] With the rapid development of information technology, electronic products have become increasingly popular. The development of these products benefits from the rapid development of embedded system technology. For example, daily necessities such as mobile phones are applications of embedded system technology. However, the application of embedded system technology is far more than that. It has important applications in fields such as industrial control, traffic management, information appliances, home intelligent management, network and e-commerce, aerospace, military equipment, and ships. Embedded system technology is quietly influencing our lives, bringing us great convenience and having good development prospects.

[0003] Currently, in embedded development, it is often necessary to burn the corresponding firmware into the development board before the development board can run our program. In embedded development, many use the Linux system, and some also use WinCE and other systems. In the Linux system, most are in the mode of bootloader + kernel + rootfs. Among them, the commonly used bootloader is uboot. It is responsible for initializing the hardware and setting up the software environment, then loading the kernel and running the kernel. After the kernel runs, it loads the rootfs and then runs Linux.

[0004] In order to prevent the data in these partitions from being illegally tampered with and replaced, and to prevent hackers from flashing the machine through professional tools or other means. Based on the hardware protection mechanism provided by the security chip and the RSA signature verification of each partition image, without affecting the necessary debugging means, higher-level protection is provided for important data in Flash, such as partitions like uboot, kernel, rootfs, system, etc., to form a chain verification mechanism. There are similar examples in the prior art. The startup also starts from uboot and ends with the core business. The method adopted is to encrypt all partition images. In this way, all partition images are stored in flash in ciphertext. Each time the power is turned on and started, it is necessary to decrypt step by step, and verify after decryption. Although this is more secure, it will also affect the overall performance of the system startup and consume storage resources particularly.

[0005] Aiming at the problem that the startup verification of the Linux system in the prior art needs to encrypt each partition image, decrypt and verify step by step, resulting in more consumption of storage resources, no effective solution has been proposed yet. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a secure boot method, device, electronic device, and computer-readable storage medium based on the Linux system, so as to solve the problem in the prior art that the Linux system startup verification needs to encrypt each partition image, decrypt and verify step by step, which consumes a large amount of storage resources.

[0007] To this end, the embodiments of the present invention provide the following technical solutions:

[0008] In the first aspect of the present invention, a secure boot method based on the Linux system is provided, including:

[0009] Read the hash value of the RSA public key in the OTP;

[0010] Use the hash value of the RSA public key in the OTP to verify the signature of uboot, and obtain a first verification result;

[0011] When the first verification result indicates that the verification is passed, verify the header signature of the kernel to obtain a second verification result;

[0012] When the second verification result indicates that the verification is passed, verify the specified file in the rootfs to obtain a third verification result;

[0013] When the third verification result indicates that the verification is passed, verify the files in the system.

[0014] Optionally, after reading the hash value of the RSA public key in the OTP and before using the hash value of the RSA public key in the OTP to verify the signature of uboot, the method further includes:

[0015] Obtain the public key in the uboot image package;

[0016] Use the RAS signature algorithm to calculate the hash value of the public key in the uboot image package to obtain the hash value of the public key in the uboot image package;

[0017] Judge whether the hash value of the public key in the uboot image package is consistent with the hash value of the RSA public key in the OTP to obtain a first judgment result;

[0018] When the first judgment result indicates yes, extract the key in the uboot image package;

[0019] Use the RAS signature algorithm to calculate the hash value of the key in the uboot image package to obtain the hash value of the key in the uboot image package;

[0020] Determine whether the key hash value in the U-Boot image package is the same as the key hash value in the OTP to obtain a second determination result; the second determination result indicates yes.

[0021] Optionally, verifying the header signature of the kernel includes:

[0022] U-Boot reads the kernel image signature header in the flash and uses the RAS public key in the U-Boot image package to verify the kernel signature header.

[0023] Optionally, verifying the specified files in the rootfs includes:

[0024] Obtain the specified files; wherein, the specified files include at least one of the following: configuration files, library files;

[0025] Sign the specified files;

[0026] Use the RAS public key in the U-Boot image package to verify the signature of the specified files.

[0027] Optionally, verifying the files in the system includes:

[0028] Obtain the actual number of files and the number of files in the system_list;

[0029] Determine whether the actual number of files is the same as the number of files in the system_list to obtain a third determination result;

[0030] When the third determination result indicates yes, calculate the hash value of each file in the system;

[0031] Compare the hash value of each file with the corresponding hash value stored in the system_list to obtain a comparison result;

[0032] When the comparison result indicates yes, start the system partition.

[0033] Optionally, obtaining the actual number of files includes:

[0034] Use the busybox wc tool in the Linux system to list all files in the specified directory to obtain the actual number of files.

[0035] Optionally, obtaining the number of files in the system_list includes:

[0036] Before packaging the image package of the system partition, use the find command in combination with the sha256sum algorithm to obtain the listing of all files and the hash values of all files.

[0037] In a second aspect of the present invention, a secure boot device based on the Linux system is provided, including:

[0038] A reading module for reading the hash value of the RSA public key in the OTP;

[0039] A first verification module for verifying the signature of uboot using the hash value of the RSA public key in the OTP to obtain a first verification result;

[0040] A second verification module for verifying the header signature of the kernel to obtain a second verification result when the first verification result indicates that the verification is passed;

[0041] A third verification module for verifying a specified file in the rootfs to obtain a third verification result when the second verification result indicates that the verification is passed;

[0042] A fourth verification module for verifying the files in the system when the third verification result indicates that the verification is passed.

[0043] In a third aspect of the present invention, an electronic device is provided, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute any one of the secure boot methods based on the Linux system in the above first aspect.

[0044] In a fourth aspect of the present invention, a computer-readable storage medium is provided, on which computer instructions are stored, and characterized in that when the instructions are executed by a processor, any one of the secure boot methods based on the Linux system in the above first aspect is implemented.

[0045] The technical solution of the embodiment of the present invention has the following advantages:

[0046] An embodiment of the present invention provides a secure boot method, device, electronic device, and computer-readable storage medium based on a Linux system. The method includes: reading the hash value of the RSA public key in the OTP; using the hash value of the RSA public key in the OTP to verify the signature of the uboot to obtain a first verification result; when the first verification result indicates that the verification passes, verifying the header signature of the kernel to obtain a second verification result; when the second verification result indicates that the verification passes, verifying a specified file in the rootfs to obtain a third verification result; and when the third verification result indicates that the verification passes, verifying the files in the system. This solves the problem in the prior art that Linux system boot verification requires encrypting each partition image, decrypting and verifying step by step, which consumes a large amount of storage resources, and saves storage resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0048] Figure 1 is a flowchart of the secure boot method based on the Linux system according to an embodiment of the present invention;

[0049] Figure 2 is a block diagram of the kernel structure according to an embodiment of the present invention;

[0050] Figure 3 is another flowchart of the secure boot method based on the Linux system according to an embodiment of the present invention;

[0051] Figure 4 is a schematic diagram of the secure boot of uboot according to an embodiment of the present invention;

[0052] Figure 5 is a flowchart of the system to start uboot according to an embodiment of the present invention;

[0053] Figure 6 is a schematic diagram of the secure boot of the kernel according to an embodiment of the present invention;

[0054] Figure 7 is another schematic diagram of the secure boot of the kernel according to an embodiment of the present invention;

[0055] Figure 8 is a block diagram of the secure boot device based on the Linux system according to an embodiment of the present invention;

[0056] Figure 9 It is a schematic diagram of the hardware structure of the electronic device provided by the embodiment of the present invention. Specific embodiments

[0057] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of the present application.

[0058] In the description of the present application, it should be understood that the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc. indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus cannot be construed as a limitation of the present application. In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly indicating the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more features. In the description of the present application, "a plurality" means two or more, unless otherwise specifically defined.

[0059] In the present application, the term "exemplary" is used to mean "serving as an example, illustration, or description". Any embodiment described as "exemplary" in the present application is not necessarily to be construed as more preferred or more advantageous than other embodiments. In order for any person skilled in the art to implement and use the present application, the following description is given. In the following description, details are set forth for the purpose of explanation. It should be understood that those skilled in the art can recognize that the present application can be implemented without the use of these specific details. In other instances, well-known structures and processes are not described in detail to avoid unnecessary details from obscuring the description of the present application. Therefore, the present application is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed in the present application.

[0060] In the prior art, many only ensure the encryption of external communication transmissions, often overlooking the hidden dangers of secure booting in the system, lacking a mechanism for protecting and verifying secure boot information. When booting, the image in the flash is not decrypted or integrity-verified, making it easy for external parties to damage partition information, steal information in the device, or perform illegal flashing.

[0061] To achieve secure booting of the Linux system, according to an embodiment of the present invention, an embodiment of a secure booting method based on the Linux system is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0062] In addition, the technical features involved in different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0063] In this embodiment, a secure booting method based on the Linux system is provided, which can be used for electronic devices with computing capabilities. Figure 1 It is a flowchart of a secure booting method based on the Linux system according to an embodiment of the present invention, as Figure 1 shown. The process includes the following steps:

[0064] Step S101, read the hash value of the RSA public key in the OTP.

[0065] Step S102, use the hash value of the RSA public key in the OTP to verify the signature of uboot, and obtain a first verification result.

[0066] Step S103, when the first verification result indicates that the verification is passed, verify the header signature of the kernel to obtain a second verification result. For example, the header signature of the kernel is as Figure 2 shown.

[0067] Step S104, when the second verification result indicates that the verification is passed, verify the specified file in the rootfs to obtain a third verification result.

[0068] Step S105, when the third verification result indicates that the verification is passed, verify the files in the system.

[0069] Refer to Figure 3, when the chip is powered on and starts up, it loads the BootLoader in its internal ROM. The program will read the flag bits such as the registers in the OTP to determine whether to perform a secure startup. If a secure startup is confirmed, it will verify the hash of the public key and the signature of the uboot. After the verification passes, the uboot will verify the header signature of the kernel. After the kernel verification passes, the kernel will start a thread to verify the file hash values in the rootfs and system partitions; as long as one verification fails, the system will trigger a restart exception handling, thus forming a secure verification chain. Since the embodiment of the present invention does not need to encrypt each partition image during the secure startup process based on the Linux system, and does not need to perform hierarchical decryption every time it is powered on and started, the embodiment of the present invention does not affect the system performance much and consumes less system memory resources, and can perform secure startup more quickly.

[0070] In an alternative embodiment, after reading the hash value of the RSA public key in the OTP and before verifying the signature of the uboot using the hash value of the RSA public key in the OTP, obtain the public key in the uboot image package, calculate the hash value of the public key in the uboot image package using the RAS signature algorithm, obtain the hash value of the public key in the uboot image package, and determine whether the hash value of the public key in the uboot image package is consistent with the hash value of the RSA public key in the OTP to obtain a first judgment result. When the first judgment result indicates yes, extract the key in the uboot image package, calculate the hash value of the key in the uboot image package using the RAS signature algorithm, obtain the hash value of the key in the uboot image package, and determine whether the hash value of the key in the uboot image package is consistent with the hash value of the key in the OTP to obtain a second judgment result, and the second judgment result indicates yes. Specifically, refer to Figure 4 , to make a secure encrypted uboot image, the OTP is required, and the hash values of the RSA public key and the KEY need to be burned. Import the N and E values of the RSA public key into the image package. When performing the RSA signature verification, first verify the public key to see if it is the same public key stored in the chip OTP. In addition, since the uboot image and its signature are encrypted with AES and require AES and IV. Similarly, when decrypting, it is necessary to check whether the password stored in the OTP is consistent with the KEY in the uboot image; only when they are consistent can decryption be performed. After decryption, it is necessary to perform signature verification on the uboot image and its signature.

[0071] Refer to Figure 5 , the system starts the uboot including the following steps:

[0072] Step S501, the chip is powered on;

[0073] Step S502, read the hash value of the RSA public key in the OTP;

[0074] Step S503, verify the public key. If the verification fails, execute step S504. If the verification is successful, execute step S505;

[0075] Step S504, restart and reset the system;

[0076] Step S505, verify the signature of the key. If the signature verification is successful, execute step S506. If the signature verification fails, execute step S504;

[0077] Step S506, decrypt uboot.bin with the key; The key and iv value cooperate with the AES CBC mode algorithm to decrypt the ciphertext uboot.bin. The decrypted uboot is machine-readable data. When the machine normally starts uboot, the kernel can be safely started;

[0078] Step S507, verify the signature of uboot_signature.bin with the RSA public key. If the verification is successful, execute step S508. If the verification fails, execute step S504;

[0079] Step S508, start uboot in the system and perform a secure boot of the kernel.

[0080] The above step S103 involves verifying the header signature of the kernel. In an optional embodiment, uboot reads the kernel image signature header in the flash and uses the RAS public key in the uboot image package to verify the kernel signature header. Specifically, refer to Figure 6 、 7 , the kernel image is signed with the RSA private key for the kernel, and the header of the original kernel image is imported. In uboot, use the secure encryption and decryption interface component. Uboot reads the kernel image signature header and the kernel image in the flash, and uses the RSA public key to perform an integrity check on the kernel signature header. After the verification is successful, it will modify the header address of the starting kernel. Because the header address of the kernel partition is saved in the default uboot environment variable, the kernel header signature needs to be skipped to start the kernel. After the kernel starts successfully, the secure boot of rootfs / system can be performed.

[0081] The above-mentioned step S104 involves verifying specified files in the rootfs. In an optional embodiment, the specified files are obtained; wherein, the specified files include at least one of the following: configuration files, library files; the specified files are signed, and the signature of the specified files is verified using the RAS public key in the uboot image package. Specifically, it is somewhat similar to the secure boot of the system. Since the rootfs is readable and writable, only the configuration files, important commands, and library files in the internal partition are signed and saved to a file (verify_list). During startup, the signature will be verified using the RSA public key. After successful verification, the system partition will be verified continuously.

[0082] The above-mentioned step S105 involves verifying files in the system. In an optional embodiment, the actual number of files and the number of files in the system_list are obtained, and it is determined whether the actual number of files is consistent with the number of files in the system_list to obtain a third judgment result. When the third judgment result indicates "yes", the hash value of each file in the system is calculated, and the hash value of each file is compared with the corresponding hash value stored in the system_list to obtain a comparison result. When the comparison result indicates "yes", the system partition is started. Specifically, refer to Figure 7 , after the kernel starts, a thread will be started. First, the system verifies the number of files. By comparing the number of files in the file (system_list) with the actual files (system_num), after they are found to be consistent, the hash values of all files in the system are calculated one by one and compared with the corresponding hash values stored in the file (system_list). Only after successful verification can the system partition be started; otherwise, it will restart.

[0083] In an optional embodiment, the method and steps for calculating the actual files (system_num): The busybox wc tool in the Linux system is used. This tool can list all files in a directory, write them into a script and save a variable, and output it to the system_num file.

[0084] In an optional embodiment, the method and steps for obtaining the file (system_list): Before packaging the image package of the system partition, the find command is used in conjunction with the sha256sum algorithm to obtain a list of all files and all hash values.

[0085] In this embodiment, a security startup device based on the Linux system is further provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be repeated here. As used below, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0086] This embodiment provides a security startup device based on the Linux system, as Figure 8 shown, including:

[0087] A reading module 81, configured to read the hash value of the RSA public key in the OTP;

[0088] A first verification module 82, configured to verify the signature of the uboot using the hash value of the RSA public key in the OTP to obtain a first verification result;

[0089] A second verification module 83, configured to verify the header signature of the kernel to obtain a second verification result when the first verification result indicates that the verification is passed;

[0090] A third verification module 84, configured to verify the specified file in the rootfs to obtain a third verification result when the second verification result indicates that the verification is passed;

[0091] A fourth verification module 85, configured to verify the files in the system when the third verification result indicates that the verification is passed.

[0092] The security startup device based on the Linux system in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0093] The further function descriptions of the above-mentioned respective modules are the same as those in the corresponding embodiments above, and will not be repeated here.

[0094] This embodiment of the present invention further provides a mobile terminal having the above-mentioned Figure 9 security startup device based on the Linux system.

[0095] Please refer to Figure 9 , Figure 9 which is a schematic structural diagram of an electronic device provided by an optional embodiment of the present invention. As Figure 9As shown, the terminal may include: at least one processor 901, such as a CPU (Central Processing Unit), at least one communication interface 903, a memory 904, and at least one communication bus 902. Among them, the communication bus 902 is used to implement connection communication between these components. Among them, the communication interface 903 may include a display screen (Display) and a keyboard (Keyboard). Optionally, the communication interface 903 may further include a standard wired interface and a wireless interface. The memory 904 may be a high-speed RAM memory (Random Access Memory, volatile random access memory), or a non-volatile memory, such as at least one disk memory. Optionally, the memory 904 may further be at least one storage device located far from the aforementioned processor 901. Among them, the processor 901 may be combined with Figure 8 the described device, the memory 904 stores an application program, and the processor 901 calls the program code stored in the memory 904 to perform the steps of any of the above security startup methods based on the Linux system.

[0096] Among them, the communication bus 902 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus 902 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 9 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0097] Among them, the memory 904 may include a volatile memory (English: volatile memory), such as a random access memory (English: random-access memory, abbreviation: RAM); the memory may also include a non-volatile memory (English: non-volatile memory), such as a flash memory (English: flash memory), a hard disk (English: hard disk drive, abbreviation: HDD) or a solid-state drive (English: solid-state drive, abbreviation: SSD); the memory 904 may further include a combination of the above types of memories.

[0098] Among them, the processor 901 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP.

[0099] Among them, the processor 901 may further include a hardware chip. The above-mentioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0100] Optionally, the memory 904 is further configured to store program instructions. The processor 901 may call the program instructions to implement the security startup method based on the Linux system as shown in the embodiments of the present application Figure 1 and 6 the security startup method shown in the embodiments.

[0101] The embodiments of the present invention further provide a non-transitory computer storage medium storing computer-executable instructions that can execute the security startup method based on the Linux system in any of the above method embodiments. Among them, the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD), etc.; the storage medium may also include a combination of the above types of memories.

[0102] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A secure boot method based on the Linux system, characterized in that Includes: Read the hash value of the RSA public key in the OTP; Use the hash value of the RSA public key in the OTP to verify the signature of uboot, and obtain a first verification result; When the first verification result indicates that the verification passes, verify the header signature of the kernel to obtain a second verification result; When the second verification result indicates that the verification passes, verify the specified file in the rootfs to obtain a third verification result; When the third verification result indicates that the verification passes, verify the files in the system; Wherein, after reading the hash value of the RSA public key in the OTP and before using the hash value of the RSA public key in the OTP to verify the signature of uboot, the method further includes: Obtain the public key in the uboot image package; Use the RSA signature algorithm to calculate the hash value of the public key in the uboot image package to obtain the public key hash value in the uboot image package; Determine whether the public key hash value in the uboot image package is consistent with the RSA public key hash value in the OTP to obtain a first determination result; When the first determination result indicates yes, extract the key in the uboot image package; Use the RSA signature algorithm to calculate the hash value of the key in the uboot image package to obtain the key hash value in the uboot image package; Determine whether the key hash value in the uboot image package is consistent with the key hash value in the OTP to obtain a second determination result; the second determination result indicates yes.

2. The security startup method based on the Linux system according to claim 1, wherein Verifying the header signature of the kernel includes: Uboot reads the kernel image signature header in the flash and uses the RSA public key in the uboot image package to verify the kernel signature header.

3. The secure boot method based on the Linux system according to claim 1, characterized in that, Verifying the specified file in the rootfs includes: Obtain the specified file; wherein, the specified file includes at least one of the following: configuration file, library file; Sign the specified file; Use the RSA public key in the uboot image package to verify the signature of the specified file.

4. The secure boot method based on the Linux system according to claim 1, wherein Verifying the files in the system includes: Obtain the actual number of files and the number of files in the system_list; Determine whether the actual number of files is consistent with the number of files in the system_list to obtain a third determination result; When the third determination result indicates yes, calculate the hash value of each file in the system; Compare the hash value of each file with the corresponding hash value stored in the system_list to obtain a comparison result; When the comparison result indicates yes, start the system partition.

5. The security startup method based on the Linux system according to claim 4, characterized in that Obtaining the actual number of files includes: Use the busybox wc tool in the Linux system to list all files in the specified directory to obtain the actual number of files.

6. The security startup method based on the Linux system according to claim 4, characterized in that, Obtaining the number of files in the system_list includes: Before packaging the image package of the system partition, use the find command in combination with the sha256sum algorithm to obtain the listing of all files and the hash values of all files.

7. A security startup device based on the Linux system, which is used to implement the method described in any one of claims 1 to 6, characterized in that, The device includes: A reading module, configured to read the hash value of the RSA public key in the OTP; A first verification module, configured to verify the signature of the uboot by using the hash value of the RSA public key in the OTP, and obtain a first verification result; A second verification module, configured to verify the header signature of the kernel when the first verification result indicates that the verification is passed, and obtain a second verification result; A third verification module, configured to verify a specified file in the rootfs when the second verification result indicates that the verification is passed, and obtain a third verification result; A fourth verification module, configured to verify the files in the system when the third verification result indicates that the verification is passed.

8. An electronic device, characterized in that, Comprising: At least one processor; And a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the security boot method based on the Linux system according to any one of claims 1-6 above.

9. A computer-readable storage medium having computer instructions stored thereon, characterized in that, When the instructions are executed by the processor, the security boot method based on the Linux system according to any one of claims 1-6 above is implemented.

Images