Linux-based system secure boot method, electronic device and storage medium

Abstract

Provided in the present application are a Linux-based system secure boot method, an electronic device and a storage medium. The method comprises: removing original certificates of a mainboard, and generating a new certificate chain; separately generating a boot loader and a GNU privacy guard public key corresponding to a GNU privacy guard private key; on the basis of the boot loader and a preset boot loading module, generating an initial boot file; according to the new certificate chain, signing the initial boot file to obtain a target boot file; separately signing a kernel and a boot loader configuration file of a system by using the GNU privacy guard private key, so as to generate signature files; by means of the GNU privacy guard public key, separately performing signature verification on the signature files, so as to obtain signature verification results respectively corresponding thereto; and, when both the signature verification results indicate that signature verification succeeds, executing system secure boot according to the target boot file. The present application achieves replacement of a certificate chain and signature and signature verification for a kernel and a boot loader configuration file after the replacement, thereby improving the Linux system boot security.

Description

Linux-based system security startup method, electronic device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on March 29, 2024, with application number 202410382466.6, and invention name “System security boot method, electronic device and storage medium based on Linux”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application belongs to the technical field of Linux operating systems, and in particular relates to a Linux-based system secure startup method, electronic device, and storage medium. Background Art

[0003] Currently, Linux systems typically rely on certificates provided by certain manufacturers to support secure boot. For example, the default certificate chain for UEFI (Unified Extensible Firmware Interface) is provided by certain manufacturers. Using certificates issued by these manufacturers to sign a Linux system effectively means the private key of the root certificate is in the hands of these manufacturers, potentially exposing it to potential leaks. Furthermore, if certificates from these manufacturers are not used, further challenges remain regarding how to sign and verify key files (such as modules) to ensure they have not been tampered with. Summary of the Invention

[0004] The embodiments of the present application provide a Linux-based system security boot method, electronic device, and storage medium, which can solve the problem that the Linux system boot security cannot be guaranteed.

[0005] In a first aspect, an embodiment of the present application provides a Linux-based system secure boot method, comprising:

[0006] Clear the original certificate of the motherboard and generate a new certificate chain;

[0007] Generate the boot loader and the GNU Privacy Protection public key corresponding to the GNU Privacy Protection private key respectively;

[0008] Generate an initial boot file based on the boot loader and the preset boot loader module;

[0009] Signing the initial boot file according to the new certificate chain to obtain a target boot file;

[0010] Sign the kernel and boot loader configuration files of the system respectively using the GNU privacy protection private key to generate corresponding signature files;

[0011] Using the GNU privacy protection public key, respectively verify the signature files corresponding to the kernel and boot loader configuration files to obtain corresponding verification results; the verification results are success or failure;

[0012] When the corresponding signature verification results are all successful, the system is securely started according to the target boot file.

[0013] In a possible implementation of the first aspect, generating a boot loader includes:

[0014] Obtaining initial source code for a boot loader in the system;

[0015] Deleting the initial signature verification calling module in the initial source code to obtain processed source code for the boot loader;

[0016] The processed source code of the boot loader is compiled to generate the boot loader program.

[0017] In a possible implementation of the first aspect, the GNU privacy protection private key is built into the encryption machine;

[0018] The method of using the GNU privacy protection private key to sign the kernel and boot loader configuration files of the system respectively to generate corresponding signature files includes:

[0019] The encryption machine uses the GNU privacy protection private key to sign the kernel and boot loader configuration files of the system respectively, and generates corresponding signature files.

[0020] In a possible implementation of the first aspect, using the GNU privacy protection private key to sign the kernel and boot loader configuration files of the system respectively to generate corresponding signature files includes:

[0021] The local computer corresponding to the system sends a signature request to the signature server; the signature request is used to request signing of the kernel and boot loader configuration files of the system;

[0022] After receiving the signature request, the signature server determines whether to approve the signature request;

[0023] If the signature server approves the signature request, the signature server calculates the digests of the kernel and boot loader configuration files of the system according to the signature request to obtain the digests of the kernel and boot loader configuration files respectively.

[0024] The encryption engine encrypts the digest based on the built-in GNU privacy protection private key to obtain signature files corresponding to the kernel and boot loader configuration files of the system.

[0025] In a possible implementation of the first aspect, generating an initial boot file based on the boot loader and the preset boot loading module includes:

[0026] The initial boot file is generated based on the boot loader, the preset boot loading module, and the GNU privacy protection public key.

[0027] In a possible implementation of the first aspect, before performing secure system startup according to the target boot file, the method further includes:

[0028] When the corresponding signature verification results are all successful, the kernel, the boot loader configuration file, and the signature files corresponding to the kernel and the boot loader configuration file are backed up to a preset directory.

[0029] In a possible implementation of the first aspect, before performing secure system startup according to the target boot file, the method further includes:

[0030] Back up the target boot file to the system boot partition.

[0031] In a possible implementation of the first aspect, performing system secure startup according to the target boot file includes:

[0032] Creating a boot entry in the mainboard firmware according to the path of the system boot partition and the file name of the target boot file;

[0033] Establishing a mapping relationship between the boot entry and the target boot file;

[0034] The system secure boot is performed according to the boot entry and the mapping relationship.

[0035] In a second aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the Linux-based system security startup method described in any one of the first aspects above is implemented.

[0036] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the Linux-based system security startup method described in any one of the first aspects above.

[0037] Compared with the related art, the embodiments of the present application have the following beneficial effects:

[0038] The embodiment of the present application avoids the use of certificate chains of some manufacturers by clearing the original certificate of the motherboard and regenerating a new certificate chain when the Linux system is started; and generates an initial boot file based on the boot loader and preset boot loading modules such as modules, and uses the above-mentioned new certificate chain to sign the initial boot file to obtain the target boot file, and perform system secure startup, thereby avoiding the security issues caused by the current failure to verify the signatures of preset boot loading modules such as modules, and improving the security of Linux system startup; and after replacing the certificate chain, the kernel and boot loader configuration files are signed and verified, which can avoid the security issues caused by using the built-in manufacturer certificate verification tool for verification, and further ensure the security of Linux system startup. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0040] FIG1 is a flow chart of a Linux-based system secure boot method provided by an embodiment of the present application;

[0041] FIG2 is a flow chart of step S120 in a Linux-based system secure boot method provided by another embodiment of the present application;

[0042] FIG3 is a flow chart of an online signing method provided in another embodiment of the present application;

[0043] FIG4 is a flow chart of a Linux-based system secure boot method provided by another embodiment of the present application;

[0044] FIG5 is a schematic diagram of a portion of the structure of the motherboard firmware in the related art;

[0045] FIG6 is a schematic diagram of a portion of the structure of the mainboard firmware according to an embodiment of the present application;

[0046] FIG7 is a schematic diagram of a portion of the structure of a storage device in the related art;

[0047] FIG8 is a partial structural diagram of a storage device provided in one embodiment of the present application;

[0048] FIG9 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0050] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0051] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0052] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0053] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0054] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0055] The Linux-based system secure boot method provided in this application is mainly targeted at Linux systems and is more widely used in the field of secure servers, such as banking systems and other server systems involving large amounts of private data.

[0056] The following is an introduction to some background knowledge involved in this application:

[0057] The Linux system goes through three main phases when it boots up. Each phase is responsible for different tasks to ensure that the computer can enter an operational state normally and safely from the shutdown state. The three main phases are:

[0058] Motherboard Firmware:

[0059] Motherboard firmware is software embedded on the motherboard that's responsible for the computer's initialization and self-test process after powering on. For most modern computers, this firmware is typically called the BIOS (Basic Input / Output System) or UEFI (Unified Extensible Firmware Interface). During this phase, the computer checks that its hardware devices (such as memory, CPU, and hard drive) are functioning properly and prepares them for the next stage of the boot process.

[0060] Bootloader:

[0061] The boot loader is the second stage in the computer's startup process. Its primary task is to load and start the operating system. The boot loader is typically stored on the computer's boot device (such as a hard drive, USB drive, or network location) and is loaded by the motherboard firmware after the system completes its self-test. Once loaded, the boot loader loads the operating system's core files, such as the kernel, into memory and runs. To support booting multiple systems or different kernel versions, the boot loader typically specifies the kernel location using a configuration file. The kernel also relies on other files during operation. Therefore, in addition to loading the kernel, the boot stage also requires loading the configuration file and other files that the kernel depends on for startup.

[0062] Operating System:

[0063] The operating system is the final stage of the computer's boot process. Once loaded into memory by the boot loader, the operating system takes control of the computer and begins managing its hardware and software resources. The operating system provides core functionality such as the user interface, file management, device drivers, network connectivity, and an application execution environment.

[0064] During the Linux system's secure boot process, at the motherboard firmware stage, after UEFI completes hardware initialization, it then reads and executes the grub (Grand Unified Bootloader) file, such as grub.efi, from the EFI (EFI system partition) based on the UEFI boot entry settings. This file then enters the next stage, the bootloader. grub is the Linux system's bootloader.

[0065] During the bootloader phase, grub first reads the grub.cfg configuration file, which contains the kernel and initrd file (Linux initial RAM disk) paths. It then loads the files based on the paths, passes the relevant parameters to the kernel, and boots the kernel, before entering the operating system phase. During the operating system phase, drivers are loaded and applications are executed. The initrd file is a temporary root file system mounted during the system boot process.

[0066] For a brand new computer, the motherboard firmware is permanently embedded in the motherboard, while the bootloader and operating system are copied to the hard drive during installation. Therefore, modifying the hard drive data can alter the system and applications, potentially causing system damage or system compromise, leading to losses.

[0067] To ensure system security, programs executed on a computer must be trustworthy. This means ensuring that the program's source is reliable and the data has not been tampered with. This can be achieved through signature verification. In addition to programs stored on the motherboard, programs on the hard drive also need to be verified. This means that during the computer startup process, the files and programs loaded in the subsequent phase must be verified during the previous phase. For example, the motherboard firmware verifies the bootloader, the bootloader verifies the operating system, and the operating system verifies the application, thus ensuring system security.

[0068] After the system turns on secure boot, UEFI will use the certificate chain to verify the boot program during the system boot phase. Only with this first step of verification can the subsequent steps be verified. If the verification fails, the system will stop booting, thereby ensuring system security.

[0069] UEFI has a built-in certificate chain used to verify the bootloader. The certificate chain primarily consists of the Platform Key (PK), Key Exchange Keys (KEK), and the Signature Database (db). The PK is a unique self-signed certificate; the KEK is a collection of multiple certificates issued by the PK and used to verify the db; the db also contains multiple certificates, signatures, and digests used to verify the bootloader. UEFI provides an interface for modifying the certificate chain.

[0070] This three-tiered certificate chain is a common form of certificate chain. For example, the UEFI certificate chain described above: The PK is a self-signed certificate, also called a root certificate. It is typically written to the device at the factory or later written to the device through a secure channel. If the PK is trusted, the KEK signed by the PK is also trusted. If the KEK is trusted, the DB signed by the KEK is also trusted, and the bootloader subsequently signed by the DB is also trusted.

[0071] During Linux system startup, signatures of all involved files must be verified to ensure their legitimacy. This involves the UEFI firmware verifying the signature of the GRUB boot loader. The GRUB boot loader verifies the signature before reading the configuration file (grub.cfg), before executing the kernel, and before loading applications and drivers. Because the UEFI firmware uses a certificate chain during the GRUB boot loader signature verification process, the certificate chain also needs to be verified.

[0072] Since the default certificate chain is from some manufacturers, most distributions choose to use the certificates of the above manufacturers to issue boot programs. In addition to being unable to guarantee certificate security and startup security, it also means that every time a version is updated, you have to go to some manufacturers' websites to apply for signatures. Frequent visits to some manufacturers' websites to apply for signatures will not only slow down the release speed of the system, but also be charged fees, which is costly.

[0073] Therefore, there is a technical solution in the current related technology that uses shim to verify the kernel. The main idea of ​​the shim solution is to design an extensible middle layer with relatively stable code, which only needs to be signed by the manufacturer once, thereby isolating the manufacturer's certificate. Simply put, a manufacturer certificate can be built into shim when it is compiled. During the shim kernel verification process, shim first tries to verify the kernel with the motherboard certificate chain. If the verification fails, the shim built-in manufacturer certificate is used to verify the kernel. When the system is updated, it can be issued through the manufacturer's certificate, avoiding the trouble of frequently going to some manufacturers' websites to apply for signatures. Although the kernel verification can be achieved through the shim solution without the manufacturer's certificate, since the shim solution has a built-in manufacturer certificate, it is unsafe to use it to verify specific signature files.

[0074] Based on this, an embodiment of the present application discloses a Linux-based system secure boot method. As shown in Figure 1, the method includes the following steps:

[0075] S110, clear the original certificate of the motherboard and generate a new certificate chain. That is, after deleting the original certificate chain in the motherboard, regenerate the certificate chain, thereby avoiding the use of certificate chains provided by some manufacturers. The process of generating the certificate chain is: first generate a certificate in the x.509 format, then add variable type (PK, KEK, db, etc.), variable GUID (Global Unique Identifier), attributes, key UUID (Universally Unique Identifier) ​​and other information to the x.509 certificate, and then perform a PKCS7 signature, and then append timestamp, signature type, version information and other data to generate an AUTH format file, and write the updated certificate chain into the motherboard firmware, thereby converting the x.509 format certificate into an AUTH format certificate. Then use the efitools tool to write the certificate chain to the motherboard. In this way, the original certificate chain is replaced.

[0076] S120: Generate a boot loader and a GNU privacy-preserving public key corresponding to the GNU privacy-preserving private key. Specifically, to avoid security issues caused by the shim solution's built-in certificates from other manufacturers, this embodiment modifies and recompiles the original grub, removing the portion of grub that calls shim to verify the kernel signature, thereby avoiding security risks. A new boot loader is then recompiled.

[0077] GNU, which stands for GNU's Not Unix, is a computer operating system project. GNU Privacy Guard (GPG) is encryption software used for tasks such as data encryption, digital signatures, and key management. The GNU Privacy Guard private key, or GPG private key, is built into the encryption machine. The encryption machine is a hardware device or software module dedicated to encryption and decryption operations. The GNU Privacy Guard public key, or GPG public key, is generated by the encryption machine based on the GNU Privacy Guard private key.

[0078] This embodiment stores the GPG private key in the encryption machine. On the one hand, it can avoid local access to the private key, ensure key security, and thus help improve the startup security of the Linux system; on the other hand, it is convenient for subsequent online signing.

[0079] S130, based on the boot loader and the preset boot loader module, generate the initial boot file. Specifically, the above-mentioned boot loader and the preset boot loader module both belong to the boot loader grub. In this embodiment, the above-mentioned boot loader is grub.efi. The above-mentioned preset boot loader module is the modules module. Among them, the modules module is a collection of a series of modules, including modules such as configuration file search, kernel search, verification file, hard disk partition driver, file system driver, etc. As an example and not a limitation, this step can use the grub-mkstandalone tool to package the boot loader grub.efi and the modules module into an initial boot file, and the initial boot file can be bootx64.efi. In some preferred embodiments, this step can package the boot loader grub.efi, the preset boot loader module and the GPG public key together into an initial boot file.

[0080] Specifically, the boot loader grub in this embodiment includes: grub.efi file, modules module, grub.cfg file (i.e., boot loader configuration file), kernel, initrd, and GPG public key. Among them, the kernel mounts and runs initrd, grub.efi verifies and runs the kernel, grub.efi reads information from the boot loader configuration file, i.e., grub.efi loads the modules module. initrd is a temporary file system compression package mounted at the initial startup of the Linux system kernel, which contains the most basic drivers and commands at the initial startup of the system. grub.cfg configures the kernel, initrd location, as well as the startup commands and parameters. The modules module includes modules such as searching for configuration files, searching for kernels, verifying files, hard disk partition drivers, and file system drivers.

[0081] When grub starts running, it reads the grub.cfg configuration file, reads the kernel and initrd paths from the configuration file, loads the kernel and runs it, decompresses it, and mounts the initrd root file system. Modules are loaded from the modules directory when commands such as configuration file search, file system, disk partitioning, kernel loading, and verification are involved.

[0082] S140, based on the new certificate chain, signs the initial boot file to obtain the target boot file. That is, after replacing the certificate chain, grub needs to be re-signed based on the new certificate chain to pass the signature verification. As an example and not a limitation, the target boot file can be sbootx64.efi. In specific implementation, this step can use the db in the certificate chain to sign the packaged file to obtain the required target boot file sbootx64.efi, that is, the signing operation is completed based on the online signature, which can prevent the local computer from contacting the GPG private key, ensure the security of the GPG key, and thus help improve the startup security of the Linux system.

[0083] S150 uses the GNU privacy-preserving private key to sign the system's kernel and boot loader configuration files, generating corresponding signature files. Specifically, the encryption engine uses the GPG private key to sign the kernel and boot loader configuration file grub.cfg, respectively, generating signature files corresponding to the kernel and grub.cfg. This step uses online signing, which prevents the local computer from accessing the GPG private key, ensuring the security of the GPG key and thus improving the boot security of the Linux system.

[0084] In some optional embodiments, this step may also be: the encryption machine uses the GPG private key to sign the kernel, the boot loader configuration file grub.cfg and the initrd file respectively, and generates corresponding signature files.

[0085] S160 uses the GNU privacy-preserving public key to verify the signatures of the kernel and boot loader configuration files, respectively, obtaining corresponding verification results. The verification results can be either successful or unsuccessful. Specifically, using the GPG public key to verify the signatures of files to be loaded by GRUB, such as grub.cfg and kernel, fulfills the requirement to verify the signatures of necessary files during boot, avoiding security issues associated with calling the shim signature verification module for verification, thereby improving the security of the Linux system boot process.

[0086] It should be noted that if the initrd file is signed in the previous step S150, then the signature file of the initrd file also needs to be verified accordingly in this step.

[0087] S170: When the signature verification results corresponding to the kernel and boot loader configuration files are both successful, a system secure boot is performed according to the target boot file.

[0088] The embodiment of the present application avoids the use of certificate chains of some manufacturers by clearing the original certificate of the motherboard and regenerating a new certificate chain when the Linux system is started; and generates an initial boot file based on the boot loader and preset boot loading modules such as modules, and uses the above-mentioned new certificate chain to sign the initial boot file to obtain the target boot file, and perform system secure startup, thereby avoiding the security issues caused by the current failure to verify the signatures of preset boot loading modules such as modules, and improving the security of Linux system startup; and after replacing the certificate chain, the kernel and boot loader configuration files are signed and verified, which can avoid the security issues caused by using the built-in manufacturer certificate verification tool for verification, and further ensure the security of Linux system startup.

[0089] That is, this embodiment implements a secure boot configuration for the Linux system using self-signed software. This means that only software that has been self-signed can be verified, and only software that has passed the verification can be started and run on the system, thereby improving system security.

[0090] In some optional embodiments, the above step S140 further includes: backing up the target boot file to the system boot partition, that is, copying the target boot file to the EFI partition.

[0091] Another embodiment of the present invention discloses another Linux-based system secure boot method. As shown in FIG2 , based on the embodiment corresponding to FIG1 , step S120 includes:

[0092] S121, obtaining the initial source code of the boot loader in the system.

[0093] S122: Delete the initial signature verification calling module in the initial source code to obtain the processed source code of the boot loader.

[0094] S123, compile the processed source code of the boot loader to generate a boot loader program.

[0095] S124: Generate a GNU Privacy Protection public key corresponding to the GNU Privacy Protection private key.

[0096] Specifically, the above-mentioned initial signature verification calling module is the module that calls shim to verify the kernel signature. In this embodiment, the module that calls shim for signature verification in the grub source code is deleted, the processed source code of the boot loader, i.e. grub, is obtained, and then it is recompiled to generate a new grub.efi file. In this way, the security issues caused by the built-in certificates of other manufacturers in the shim solution can be avoided, which is conducive to improving the startup security of the Linux system.

[0097] Another embodiment of the present invention discloses another Linux-based system secure boot method. As shown in FIG3 , based on the embodiment corresponding to FIG1 , step S150 includes:

[0098] S151: The local computer corresponding to the system sends a signature request to the signature server. The signature request is used to request the system's kernel and boot loader configuration files to be signed. Optionally, the signature request can also be used to request the initrd file to be signed, which is not limited in this application.

[0099] S152: After receiving the signature request, the signature server determines whether to approve the signature request. In other words, the signature server will review the request, confirm the identity and authority of the requester, and confirm whether the requested file meets the signature requirements.

[0100] If the signature server approves the signature request, it then calculates digests for the kernel and boot loader configuration files based on the signature request and sends them to the encryption engine. Specifically, the signature server calculates digests for the kernel and boot loader configuration files based on the approved signature request. These digests can be calculated using a hash algorithm. Optionally, the signature server can pad each digest and send the padded data to the encryption engine to meet specific format or length requirements.

[0101] S154: The encryption machine encrypts the digest based on the built-in GNU privacy protection private key to obtain the first signature files corresponding to the kernel and boot loader configuration files of the system, and sends the first signature files to the signature server.

[0102] S155: The signature server determines target signature files corresponding to the system kernel and boot loader configuration files respectively according to the first signature file.

[0103] S156: The signature server sends the target signature file to the local computer.

[0104] In the above embodiment, the encryption machine and the signature server operate in the same secure environment. Signature server administrators can use the private key calculation interface provided by the encryption machine, but cannot access the private key. To achieve this requirement, the original related tools (openssl, efitools, sbsigntool, GPG) cannot be used directly; the private key calculation must be implemented by calling the encryption machine's interface. Based on this, the encryption machine uses the GPG private key to sign the system kernel, generating a signature file corresponding to the kernel. The GPG private key is also used to sign the boot loader configuration file, generating a signature file corresponding to the boot loader configuration file.

[0105] If only the digest is encrypted in step S154 and the padding is not encrypted, then the target signature file is the first signature file. If both the digest and padding are encrypted in step S154, then the first signature file corresponds to the encrypted digest, and the target signature file is the combination of the encrypted digest and the encrypted padding. In other words, the combination of the first signature file and the encrypted padding.

[0106] In the above step S152, if the signature server does not approve the signature request, the process ends.

[0107] Among them, the corresponding signing processes in the above steps S140 and S150 can be implemented based on the online signing method provided in this embodiment, which can prevent the local computer from accessing the GPG private key, ensure the security of the GPG key, and thus help improve the startup security of the Linux system.

[0108] Another embodiment of the present invention discloses another Linux-based system secure boot method. As shown in FIG4 , based on the embodiment corresponding to FIG1 , this embodiment further includes the following steps between step S160 and step S170:

[0109] At step S180, when the corresponding signature verification results are all successful, the kernel and boot loader configuration files, as well as the signature files corresponding to the kernel and boot loader configuration files, are backed up to a preset directory. Specifically, the kernel, grub.cfg, the signature file corresponding to the kernel, and the signature file corresponding to grub.cfg are all copied to the preset directory to complete the system secure boot process. By way of example and not limitation, the preset directory is the root directory.

[0110] In some optional embodiments, based on the embodiment corresponding to FIG. 1 , step S170 includes:

[0111] According to the path of the system boot partition and the file name of the target boot file, a boot entry is created in the mainboard firmware.

[0112] Establish a mapping relationship between the boot entry and the target boot file.

[0113] Perform system security startup based on the boot entry and mapping relationship.

[0114] That is, a new boot entry is added in the UEFI firmware, pointing to the above-mentioned target boot file, and the secure boot function of the motherboard is enabled to perform system secure boot.

[0115] As an example but not a limitation, the path of the system boot partition is / EFI, the file name of the target boot file is sbootx64.efi, and the boot entry obtained based on this is / EFI / sbootx64.efi.

[0116] Refer to Figures 5 and 6, which show partial structural diagrams of motherboard firmware in related art and this application. As can be seen from the diagrams, the certificate chain in both related art and this application includes three parts: PK, KEK, and db, but the content of each part is different. Motherboard firmware 51 in the related art uses a certificate chain provided by some manufacturers, while motherboard firmware 61 in this application uses a self-generated certificate chain.

[0117] Refer to Figures 7 and 8, which show partial structural diagrams of storage devices in the related art and the present application. In one possible implementation, the storage device can be a hard disk. As can be seen from the diagram, the storage content of the EFI partition in the related art and the present application is different: the EFI partition in the storage device 71 of the related art stores the boot loader grub.efi and the shim call module shim.efi. The EFI partition in the storage device 81 of the present application stores the target boot file sbootx64.efi. The boot directory in the storage device 71 of the related art stores grub.cfg, kernel, initrd, and grub modules. The boot directory in the storage device 81 of the present application stores grub.cfg, kernel, initrd, grub.cfg.sig, kernel.sig, and initrd.sig. Among them, grub.cfg.sig, kernel.sig, and initrd.sig correspond to the signature files of grub.cfg, kernel, and initrd, respectively.

[0118] It should be understood that the size of the serial numbers of the steps in all the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0119] It should be noted that the above-mentioned method embodiments disclosed in this application can be freely combined, and the technical solutions obtained after the free combination are also within the protection scope of this application.

[0120] An embodiment of the present application also provides an electronic device, as shown in Figure 9, the electronic device 90 includes: at least one processor 901, a memory 902, and a computer program 903 stored in the memory and capable of running on the at least one processor, and when the processor executes the computer program, it implements the steps in any of the above-mentioned method embodiments.

[0121] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above-mentioned various method embodiments can be implemented.

[0122] An embodiment of the present application provides a computer program product. When the computer program product is run on a mobile terminal, the mobile terminal can implement the steps in the above-mentioned various method embodiments when executing the computer program product.

[0123] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the camera / electronic device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0124] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0125] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0126] In the embodiments provided in this application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0127] The units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0128] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A Linux-based system security boot method, wherein: include: Clear the original certificate of the motherboard and generate a new certificate chain; Generate the boot loader and the GNU Privacy Protection public key corresponding to the GNU Privacy Protection private key respectively; Generate an initial boot file based on the boot loader and the preset boot loader module; Signing the initial boot file according to the new certificate chain to obtain a target boot file; Sign the kernel and boot loader configuration files of the system respectively using the GNU privacy protection private key to generate corresponding signature files; Using the GNU privacy protection public key, respectively verify the signature files corresponding to the kernel and boot loader configuration files to obtain corresponding verification results; the verification results are success or failure; When the corresponding signature verification results are all successful, the system is securely started according to the target boot file.

2. The Linux-based system security boot method according to claim 1, wherein: The generating of the boot loader comprises: Obtaining initial source code for a boot loader in the system; Deleting the initial signature verification calling module in the initial source code to obtain processed source code for the boot loader; The processed source code of the boot loader is compiled to generate the boot loader program.

3. The Linux-based system security boot method according to claim 1, wherein: The GNU Privacy Protection private key is built into the encryption machine; The method of using the GNU privacy protection private key to sign the kernel and boot loader configuration files of the system respectively to generate corresponding signature files includes: The encryption machine uses the GNU privacy protection private key to sign the kernel and boot loader configuration files of the system respectively, and generates corresponding signature files.

4. The Linux-based system security boot method according to claim 3, wherein: The method of using the GNU privacy protection private key to sign the kernel and boot loader configuration files of the system respectively to generate corresponding signature files includes: The local computer corresponding to the system sends a signature request to the signature server; the signature request is used to request signing of the kernel and boot loader configuration files of the system; After receiving the signature request, the signature server determines whether to approve the signature request; If the signature server approves the signature request, the signature server calculates the digests of the kernel and boot loader configuration files of the system according to the signature request to obtain the digests of the kernel and boot loader configuration files respectively. The encryption engine encrypts the digest based on the built-in GNU privacy protection private key to obtain signature files corresponding to the kernel and boot loader configuration files of the system.

5. The Linux-based system security boot method according to claim 1, wherein: The generating of an initial boot file based on the boot loader and the preset boot loader module includes: The initial boot file is generated based on the boot loader, the preset boot loading module, and the GNU privacy protection public key.

6. The Linux-based system security boot method according to claim 1, wherein: Before executing the system secure startup according to the target boot file, the method further includes: When the corresponding signature verification results are all successful, the kernel, the boot loader configuration file, and the signature files corresponding to the kernel and the boot loader configuration file are backed up to a preset directory.

7. The Linux-based system security boot method according to claim 1, wherein: Before executing the system secure startup according to the target boot file, the method further includes: Back up the target boot file to the system boot partition.

8. The Linux-based system security boot method according to claim 7, wherein: The step of executing a system security boot according to the target boot file includes: Creating a boot entry in the mainboard firmware according to the path of the system boot partition and the file name of the target boot file; Establishing a mapping relationship between the boot entry and the target boot file; The system secure boot is performed according to the boot entry and the mapping relationship.

9. An electronic device, wherein: The method comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium storing a computer program, wherein: When the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images