Equipment starting verification method and device, electronic equipment, program product and medium

Abstract

The invention provides an equipment startup verification method and device, electronic equipment, a program product and a medium, and relates to the field of equipment security, the method comprises the following steps: when it is detected that equipment triggers power-on startup, initializing a trusted execution environment of a processor; the firmware program, the bootstrap program and the operating system program serve as programs to be verified in sequence, before the programs to be verified are operated, data to be verified of the programs to be verified are sent to the trusted execution environment, and the data to be verified are verified in the trusted execution environment; wherein the to-be-verified data comprises a signature value, an integrity verification value and a program fragment; if it is determined that the to-be-verified data pass verification, triggering the to-be-verified program to start running; if it is determined that the to-be-verified data does not pass verification, the to-be-verified program is prevented from running; the firmware program, the bootstrap program and the operating system program can be effectively verified in the trusted execution environment, so that the attack of the bootstrap tool can be effectively resisted.

Description

Technical Field

[0001] The present invention relates to the field of equipment security, and in particular to an equipment startup verification method, device, electronic equipment, program product and medium. Background Art

[0002] Bootkit attacks are malicious attacks on the operating system kernel, programs or files before or during the operating system startup (such as replacement, tampering, hiding, etc.). Since they usually attack during the system startup process and their hiding methods are mainly hidden in firmware programs, component firmware programs, and hard disk hidden areas, traditional operating system-level security defense methods cannot effectively resist bootkit attacks. Summary of the invention

[0003] The purpose of the present invention is to provide a device startup verification method, apparatus, electronic device, program product and medium, which can effectively verify the firmware program, boot program and operating system program in a trusted execution environment, thereby effectively resisting boot tool attacks.

[0004] In order to solve the above technical problems, the present invention provides a device startup verification method, comprising:

[0005] When it is detected that the device triggers power-on startup, the trusted execution environment of the processor is initialized;

[0006] The firmware program, the boot program, and the operating system program are sequentially used as programs to be verified. Before the programs to be verified are run, the data to be verified of the programs to be verified are sent to a trusted execution environment, and the data to be verified are verified in the trusted execution environment; wherein the data to be verified includes a signature value, an integrity check value, and a program fragment;

[0007] If it is determined that the data to be verified has passed the verification, the program to be verified is triggered to start running;

[0008] If it is determined that the data to be verified fails to pass the verification, the program to be verified is prevented from running.

[0009] Optionally, initializing a trusted execution environment of the processor includes:

[0010] Loading the trusted root component program into the trusted execution environment, and using the processor key to perform signature verification on the trusted root component program; wherein the processor key is set in the processor in a hardware encapsulation manner;

[0011] If it is determined that the trusted root component program passes the signature verification, the trusted root component program is run;

[0012] If it is determined that the trusted root component program has not passed the signature verification, exception handling is performed.

[0013] Optionally, before the program to be verified is run, sending the verification data of the program to be verified to the trusted execution environment includes:

[0014] Before loading the firmware program, reading the data to be verified of the firmware program, and sending the data to be verified of the firmware program to the trusted execution environment;

[0015] When the firmware program is running, if a call of the firmware program is detected, the to-be-verified data of the boot program sent by the firmware program is added to the trusted execution environment; wherein the firmware program calls the trusted execution environment when loading the boot program;

[0016] When the boot program is running, if the call of the boot program is detected, the to-be-verified data of the operating system program sent by the boot program is added to the trusted execution environment; wherein the boot program calls the trusted execution environment when loading the operating system program.

[0017] Optionally, reading the data to be verified of the firmware program and sending the data to be verified of the firmware program to the trusted execution environment includes:

[0018] Reading the to-be-verified data of the initial program loader in the firmware program, and sending the to-be-verified data of the initial program loader to the trusted execution environment;

[0019] When it is determined that the initial program loader passes the verification, loading the initial program loader;

[0020] If the call of the initial program loader is detected, the to-be-verified data of other firmware programs sent by the initial program loader are added to the trusted execution environment; wherein the initial program loader calls the trusted execution environment when loading other firmware programs.

[0021] Optionally, it also includes:

[0022] When it is determined that the program to be verified passes the verification, the verification status of the program to be verified is recorded in a corresponding status register in the trusted execution environment;

[0023] When a hot restart of the device is detected, a target program to be reloaded is determined, and a status register of the target program is reset;

[0024] The target program is re-used as the program to be verified, and the steps of sending the data to be verified of the program to be verified to the trusted execution environment before the program to be verified runs and verifying the data to be verified in the trusted execution environment are re-executed.

[0025] Optionally, after preventing the program to be verified from running, the method further includes:

[0026] Stop the startup process of the device and output the preset alarm information;

[0027] and / or, controlling the device to restart;

[0028] And / or, performing program recovery on the program to be verified.

[0029] Optionally, the data to be verified is verified, including:

[0030] Establish a secure access channel between the trusted execution environment and the secure storage device;

[0031] Control the trusted execution environment to access the secure storage device through a secure access channel, and use the root certificate preset in the secure storage device to verify the signature value, use the trusted reference value preset in the secure storage device to verify the integrity check value, and use the malicious program feature library preset in the secure storage device to verify the program fragment; wherein, the root certificate, the trusted reference value, and the malicious program feature library are hardware encrypted by the secure storage device.

[0032] Optionally, the program fragment is verified using a malicious program feature library preset in the secure storage device, including:

[0033] Using malicious program features in a malicious program feature library to detect program fragments, and determine whether the program fragments are malicious program fragments;

[0034] If it is determined that the program fragment is not a malicious program fragment, then it is determined that the program fragment passes the verification;

[0035] If it is determined that the program fragment is a malicious program fragment, it is determined that the program fragment fails the verification.

[0036] Optionally, the signature value is verified using a root certificate preset in the secure storage device, including:

[0037] Obtain the root certificate corresponding to the program to be verified, and obtain the signature verification public key from the root certificate;

[0038] Use the signature verification public key to verify the signature value;

[0039] If it is determined that the signature value passes the signature verification, then it is determined that the signature value passes the verification;

[0040] If it is determined that the signature value fails the signature verification, then it is determined that the signature value fails the verification.

[0041] Optionally, the root certificate is derived from a preset platform root certificate, or is issued by an issuing authority.

[0042] Optionally, the integrity check value is checked using a trusted reference value preset in the secure storage device, including:

[0043] Perform hash calculation on the program to be verified to obtain the integrity check value of the program to be verified;

[0044] Determine whether the integrity check value is the same as the trusted reference value corresponding to the program to be verified;

[0045] If the integrity check value is the same as the trusted reference value corresponding to the program to be verified, it is determined that the signature value passes the verification;

[0046] If the integrity check value is different from the trusted reference value corresponding to the program to be verified, it is determined that the signature value has failed the verification.

[0047] The present invention also provides a device startup verification device, which is applied to a trusted execution environment of a processor, and the device includes:

[0048] An initialization module, used to initialize the trusted execution environment of the processor when detecting that the device triggers power-on startup;

[0049] A verification module is used to sequentially use the firmware program, the boot program, and the operating system program as programs to be verified, and before the programs to be verified are run, send the data to be verified of the programs to be verified to the trusted execution environment, and verify the data to be verified in the trusted execution environment; wherein the data to be verified includes a signature value, an integrity check value, and a program fragment;

[0050] The running trigger module is used to trigger the program to be verified to start running if it is determined that the data to be verified has passed the verification;

[0051] The operation prevention module is used to prevent the program to be verified from running if it is determined that the data to be verified has not passed the verification.

[0052] The present invention also provides an electronic device, comprising:

[0053] Memory for storing computer programs;

[0054] A processor having a trusted execution environment is used to implement the above-mentioned device startup verification method when executing a computer program.

[0055] Optionally, a secure storage device is also included for storing root certificates, trusted reference values ​​and malicious program feature libraries, and the root certificates, trusted reference values ​​and malicious program feature libraries are hardware encrypted by the secure storage device.

[0056] The present invention also provides a computer program product, including a computer program or an instruction, and when the computer program or the instruction is executed by a processor, the above-mentioned device startup verification method is implemented.

[0057] The present invention also provides a non-volatile computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are loaded and executed by a processor, the above-mentioned device startup verification method is implemented.

[0058] The present invention provides a device startup verification method, comprising: when it is detected that the device triggers power-on startup, initializing the trusted execution environment of the processor; taking a firmware program, a boot program, and an operating system program as programs to be verified in sequence, before the program to be verified runs, sending the data to be verified of the program to be verified to the trusted execution environment, and verifying the data to be verified in the trusted execution environment; wherein the data to be verified includes a signature value, an integrity check value, and a program fragment; if it is determined that the data to be verified passes the verification, triggering the program to be verified to start running; if it is determined that the data to be verified does not pass the verification, preventing the program to be verified from running.

[0059] It can be seen that when the present invention detects that the device triggers power-on startup, the trusted execution environment of the processor can be initialized first. Among them, the trusted execution environment (TEE) is a hardware execution environment separated by hardware isolation means in the processor, which can effectively resist external attacks. Subsequently, the firmware program, the boot program, and the operating system program can be used as the program to be verified in turn, and before the program to be verified runs, the data to be verified of the program to be verified can be sent to the trusted execution environment, and the data to be verified can be verified in the trusted execution environment; wherein, the data to be verified includes a signature value, an integrity check value, and a program fragment, that is, the firmware program, the boot program, and the operating system program can be legal, Integrity and malicious program feature detection can be performed to verify the credibility of the firmware program, the boot program, and the operating system program. Further, if it is determined that the data to be verified passes the verification, the program to be verified is triggered to start running; if it is determined that the data to be verified does not pass the verification, the program to be verified is prevented from running, thereby effectively resisting Bootkit attacks. The present invention also provides a device startup verification device, an electronic device, a computer-readable storage medium, and a computer program product, which have the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0061] Figure 1A flow chart of a device startup verification method provided by an embodiment of the present invention;

[0062] Figure 2 A schematic diagram of a device startup verification framework provided by an embodiment of the present invention;

[0063] Figure 3 A flowchart of a security detection process based on TEE trusted root provided by an embodiment of the present invention;

[0064] Figure 4 A flowchart of a safety detection process during a system hot restart provided by an embodiment of the present invention;

[0065] Figure 5 A structural block diagram of a device startup verification device provided by an embodiment of the present invention;

[0066] Figure 6 The present invention provides a structural block diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0067] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0068] Bootkit attacks are malicious attacks on the operating system kernel, programs or files before or during the operating system startup (such as replacement, tampering, hiding, etc.). Since they usually attack during the system startup process and their hiding methods are mainly hidden in firmware programs, component firmware programs, and hard disk hidden areas, traditional operating system-level security defense methods cannot effectively resist bootkit attacks.

[0069] In view of this, in order to solve the technical problem of how to resist boot tool attacks, the present invention can provide a device startup verification method, which can effectively verify the firmware program, boot program, and operating system program in a trusted execution environment, thereby effectively resisting boot tool attacks.

[0070] For easier understanding, please refer to Figure 1 , Figure 1 A flowchart of a device startup verification method provided by an embodiment of the present invention, the method may include:

[0071] S101: When it is detected that the device triggers power-on startup, the trusted execution environment of the processor is initialized.

[0072] Trusted Execution Environment (TEE) refers to a hardware execution environment separated by hardware isolation in a processor. It can use hardware isolation and encryption technology to protect data and code in the trusted execution environment, prevent malware from accessing or tampering with data and code, and thus achieve higher security and privacy. In this embodiment, the trusted execution environment can be initialized first when the device is triggered to power on, so that it can be used to verify firmware programs, boot programs, and operating system programs.

[0073] It should be noted that this embodiment does not limit how to initialize the trusted execution environment. For example, a preset trusted root component program can be loaded into the trusted execution environment. The trusted root component program is a program required to verify the firmware program, boot program, and operating system program. Of course, since the trusted root component program will be used as the basis for the system's credibility, the credibility of the program must be verified before running the program.

[0074] Specifically, when the trusted root component program is first deployed on an electronic device, the processor key can be used to sign the program. The processor key is set on the processor in a hardware package, that is, the key can only be accessed and used by the processor itself, and cannot be accessed by the outside world. Subsequently, after the trusted root component program is loaded into the trusted execution environment and before the trusted root component program is run, the processor key can be used to verify the signature of the trusted root component program. If it is determined that the trusted root component program passes the signature verification, the trusted root component program is run; if it is determined that the trusted root component program does not pass the signature verification, exception handling is performed, such as preventing the trusted root component program from running, outputting preset alarm information, etc.

[0075] Based on this, initializing the trusted execution environment of the processor may include:

[0076] Step 11: Load the trusted root component program into the trusted execution environment, and use the processor key to verify the signature of the trusted root component program; wherein the processor key is set in the processor in a hardware encapsulation manner;

[0077] Step 12: If it is determined that the trusted root component program passes the signature verification, the trusted root component program is run;

[0078] Step 13: If it is determined that the trusted root component program has not passed the signature verification, perform exception handling.

[0079] It should be noted that this embodiment does not limit the specific method of signing the trusted root component program, nor does it limit the specific process of signature verification. Please refer to the relevant technology of program signing.

[0080] S102. The firmware program, the boot program, and the operating system program are sequentially used as programs to be verified. Before the programs to be verified are run, the data to be verified of the programs to be verified are sent to a trusted execution environment, and the data to be verified are verified in the trusted execution environment; wherein the data to be verified includes a signature value, an integrity check value, and a program fragment.

[0081] During the startup process of an electronic device, the firmware program (Firmware), the boot program (Boot Loader), and the operating system program (Operating System) are usually loaded and run in sequence. Considering that the boot tool attack can occur before the system starts or during the startup process, and its hiding method is mainly to hide in the firmware program, hide in the firmware program of the component, and hide in the hidden area of ​​the hard disk, in order to avoid the device from running with a disease, before running the above three types of programs, this embodiment needs to obtain the data to be verified of these programs, send the data to be verified to the trusted execution environment, and verify the data to be verified in the trusted execution environment. Among them, the data to be verified includes a signature value, an integrity check value, and a program fragment. The signature value is used to verify the legitimacy of the program, the integrity check value is used to verify the integrity of the program, and the program fragment is used to verify whether the program contains malicious program content. Only when the above data to be verified passes the verification, the above program can be run; and when the above data to be verified fails to pass the verification, the above program will be blocked from running, so that the boot tool attack can be effectively defended and the device can be prevented from running with a disease.

[0082] The following is an introduction to the method of obtaining the data to be verified. First, since the firmware program is at a lower level, the trusted execution environment can actively obtain the data to be verified of the firmware program before loading the firmware program, and send the data to be verified to the trusted execution environment.

[0083] Subsequently, since the boot program is loaded and run after the firmware program, and the loading of the boot program is completed by the firmware program, the data to be verified of the boot program can be actively collected and sent to the trusted execution environment by the firmware program. Specifically, the trusted execution environment can provide a callable interface (such as an API interface). When the firmware program completes the loading of the boot program, it can call the interface of the trusted execution environment and send the data to be verified of the boot program to the trusted execution environment.

[0084] Subsequently, since the operating system program (such as the system kernel, kernel driver, and system configuration file) is loaded and run after the boot program, and the loading of the operating system program is completed by the boot program, the data to be verified of the operating system program can be actively collected and sent to the trusted execution environment by the firmware program. The boot program can also send the data to be verified of the operating system program by calling the interface provided by the trusted execution environment.

[0085] Based on this, before the program to be verified runs, sending the verification data of the program to be verified to the trusted execution environment may include:

[0086] Step 21: Before loading the firmware program, read the data to be verified of the firmware program, and send the data to be verified of the firmware program to the trusted execution environment;

[0087] Step 22: When the firmware program is running, if a call of the firmware program is detected, the to-be-verified data of the boot program sent by the firmware program is added to the trusted execution environment; wherein the firmware program calls the trusted execution environment when loading the boot program;

[0088] Step 23: When the boot program is running, if a call of the boot program is detected, the data to be verified of the operating system program sent by the boot program is added to the trusted execution environment; wherein the boot program calls the trusted execution environment when loading the operating system program.

[0089] Of course, considering that the firmware program has a lot of content, such as firmware applications, firmware drivers, component oproms, etc., if all the data to be verified are obtained by the trusted execution environment, a high acquisition efficiency cannot be achieved. Therefore, this embodiment can also first verify the necessary firmware programs (such as the initial program loader, IPL, Initial Program Loader) in the firmware program, and load the necessary firmware programs first. Subsequently, the necessary program can collect the data to be verified of other firmware programs and send it to the trusted execution environment. Among them, the necessary firmware program refers to the firmware program that must be loaded at least for the firmware to run, and other firmware programs refer to firmware programs other than the necessary firmware program.

[0090] Based on this, reading the data to be verified of the firmware program and sending the data to be verified of the firmware program to the trusted execution environment may include:

[0091] Step 31: reading the data to be verified of the initial program loader in the firmware program, and sending the data to be verified of the initial program loader to the trusted execution environment;

[0092] Step 32: When it is determined that the initial program loader passes the verification, load the initial program loader;

[0093] Step 33: If the call of the initial program loader is detected, the to-be-verified data of other firmware programs sent by the initial program loader are added to the trusted execution environment; wherein the initial program loader calls the trusted execution environment when loading other firmware programs.

[0094] The following is an introduction to the verification method of the data to be verified. In this embodiment, in order to enhance the verification capability of the trusted execution environment, a secure storage device may also be set, and a root certificate, a trusted reference value, and a malicious program feature library may be set in the secure storage device. Among them, the root certificate is used to verify the signature value, the trusted reference value is used to verify the integrity check value, and the malicious program feature library is used to verify the program fragment. The root certificate, the trusted reference value, and the malicious program feature library are all hardware encrypted by the secure storage device. After obtaining the data to be verified, the trusted execution environment can establish a secure access channel with the secure storage device, and then access the above-mentioned root certificate, trusted reference value, and malicious program feature library through the secure access channel to verify the data to be verified. Among them, the secure access channel can be an encrypted channel. In this way, the trusted execution environment can effectively verify the above-mentioned firmware programs, boot programs, and operating system programs.

[0095] Based on this, the verification data is verified, including:

[0096] Step 41: Establish a secure access channel between the trusted execution environment and the secure storage device.

[0097] Step 42: Control the trusted execution environment to access the secure storage device through a secure access channel, and use the root certificate preset in the secure storage device to verify the signature value, use the trusted reference value preset in the secure storage device to verify the integrity check value, and use the malicious program feature library preset in the secure storage device to verify the program fragment; wherein, the root certificate, the trusted reference value, and the malicious program feature library are hardware encrypted by the secure storage device.

[0098] It should be noted that this embodiment does not limit the construction method of the secure access channel, and reference may be made to related technologies of data encryption.

[0099] S103: If it is determined that the data to be verified passes the verification, the program to be verified is triggered to start running.

[0100] In this step, the above-mentioned programs can be triggered to start running only when it is determined that the data to be verified has passed the verification. For example, the firmware program can only be triggered to run when its signature value, integrity check value, and program fragment have all passed the verification; the boot program can only be triggered to run when its signature value, integrity check value, and program fragment have all passed the verification; the operating system program can only be triggered to run when its signature value, integrity check value, and program fragment have all passed the verification.

[0101] S104: If it is determined that the data to be verified has not passed the verification, the program to be verified is prevented from running.

[0102] In this step, if it is determined that any of the to-be-verified data of the above-mentioned program has not passed the verification, it is necessary to prevent the program from running. For example, if it is determined that any of the signature value, integrity check value, and program fragment of the firmware program has not passed the verification, it is necessary to prevent the firmware program from running; if it is determined that any of the signature value, integrity check value, and program fragment of the boot program has not passed the verification, it is necessary to prevent the boot program from running; if it is determined that any of the signature value, integrity check value, and program fragment of the operating system program has not passed the verification, it is necessary to prevent the operating system program from running. In this way, this embodiment can effectively avoid boot tool attacks from performing hidden attacks through firmware, boot programs, etc., thereby ensuring the reliable operation of the device.

[0103] Of course, after preventing the program from running, the present embodiment may also adopt other exception handling operations. For example, the startup process of the device may be stopped and a preset alarm message may be output. For another example, the device may be controlled to restart to re-verify the above program. For another example, the program to be verified may be restored.

[0104] Based on this, after preventing the program to be verified from running, the following may also be included:

[0105] Step 51: Stop the startup process of the device and output a preset alarm message;

[0106] And / or, step 52: controlling the device to restart;

[0107] And / or, step 53: performing program recovery on the program to be verified.

[0108] Based on the above embodiments, when the present invention detects that the device triggers power-on startup, it can first initialize the trusted execution environment of the processor. Among them, the trusted execution environment (TEE) is a hardware execution environment separated by hardware isolation means in the processor, which can effectively resist external attacks. Subsequently, the firmware program, the boot program, and the operating system program can be used as the program to be verified in turn, and before the program to be verified runs, the data to be verified of the program to be verified can be sent to the trusted execution environment, and the data to be verified can be verified in the trusted execution environment; wherein, the data to be verified includes a signature value, an integrity check value, and a program fragment, that is, the firmware program, the boot program, and the operating system program can be legal, Integrity and malicious program feature detection can be performed to verify the credibility of the three firmware programs, boot programs, and operating system programs. Furthermore, if it is determined that the data to be verified passes the verification, the program to be verified is triggered to start running; if it is determined that the data to be verified does not pass the verification, the program to be verified is prevented from running, thereby effectively resisting boot tool attacks.

[0109] Based on the above embodiments, the verification process of the signature value, integrity check value, and program fragment is introduced below. In one possible case, the signature value is verified using the root certificate preset by the secure storage device, which may include:

[0110] Step 61: Obtain the root certificate corresponding to the program to be verified, and obtain the signature verification public key from the root certificate.

[0111] In this embodiment, the root certificate is used to sign and verify the firmware program, the boot program, and the operating system program. Each program can be set with a corresponding root certificate. For example, the firmware program can be set with a firmware program root certificate, the boot program can be set with a boot program root certificate, and the operating system program can be set with an operating system root certificate. It is worth noting that the root certificate is derived from a preset platform root certificate, which is set and saved by the computer manufacturer, and the above-mentioned firmware program root certificate, boot program root certificate, and operating system root certificate can be derived on the basis of the platform root certificate. In this way, the platform root certificate, the firmware program root certificate, the boot program root certificate, and the operating system root certificate can form a certificate chain, which can enhance credibility. Of course, the above-mentioned firmware program root certificate, boot program root certificate, and operating system root certificate can also be issued by a designated issuing agency.

[0112] Step 62: Use the signature verification public key to verify the signature value;

[0113] Step 63: If it is determined that the signature value passes the signature verification, then it is determined that the signature value passes the verification;

[0114] Step 64: If it is determined that the signature value does not pass the signature verification, then it is determined that the signature value does not pass the verification.

[0115] It should be noted that this embodiment does not limit the specific process of verifying the signature value using the root certificate, and reference may be made to the relevant technology of the digital signature certificate.

[0116] In one possible scenario, verifying the integrity check value using a trusted reference value preset in a secure storage device may include:

[0117] Step 81: Perform hash calculation on the program to be verified to obtain an integrity check value of the program to be verified.

[0118] Step 82: Determine whether the integrity check value is the same as the trusted reference value corresponding to the program to be verified.

[0119] Step 83: If the integrity check value is the same as the trusted reference value corresponding to the program to be verified, it is determined that the signature value passes the verification.

[0120] Step 84: If the integrity check value is different from the trusted reference value corresponding to the program to be verified, it is determined that the signature value has failed the verification.

[0121] In this embodiment, the trusted reference value is used to verify the integrity of the program. Specifically, a hash calculation can be performed on the program to be verified to obtain the integrity check value of the program to be verified, and then the integrity check value is compared with the corresponding trusted reference value to see if they are the same. If they are the same, it means that the program is complete; if they are different, it means that the program is incomplete and may have been tampered with.

[0122] It should be noted that this embodiment does not limit the specific process of performing hash calculation on the program, and reference may be made to related technologies of hash calculation.

[0123] In one possible scenario, the program fragment is verified using a malicious program feature library preset in the secure storage device, including:

[0124] Step 71: Detect the program fragment using the malicious program features in the malicious program feature library to determine whether the program fragment is a malicious program fragment.

[0125] Step 72: If it is determined that the program fragment is not a malicious program fragment, then it is determined that the program fragment passes the verification;

[0126] Step 73: If it is determined that the program fragment is a malicious program fragment, it is determined that the program fragment has failed verification.

[0127] In this embodiment, a malicious program feature library can be introduced to verify the program fragment to detect the security of the program. Specifically, the malicious program features in the malicious program feature library can be used to detect the program fragment to determine whether the program fragment belongs to a malicious program fragment. If it does not belong to a malicious program fragment, it means that the program is safe; if it belongs to a malicious program fragment, it means that the program is unsafe and contains malicious program content.

[0128] It should be noted that the present embodiment does not limit the specific content of detecting program fragments using malicious program features, and reference may be made to related technologies for virus detection.

[0129] In summary, this embodiment can perform comprehensive detection on the legality, integrity, and security of firmware programs, boot programs, and operating system programs to ensure that the programs are safe and reliable, thereby being able to effectively defend against boot tool attacks.

[0130] Based on the above embodiment, considering that when the device triggers a hot restart, the above program may be reloaded, for example, the operating system kernel may be reloaded, and there is also the possibility of being attacked by the boot tool. Therefore, this embodiment can also set a status register corresponding to each program in the trusted execution environment, and use the status register to save the verification status corresponding to the program. When it is determined that the device triggers a hot restart, the relevant status register can be reset to recheck the corresponding program, thereby ensuring the security of the device in all aspects. Based on this, the method can also include:

[0131] S201. When it is determined that the program to be verified passes verification, the verification status of the program to be verified is recorded in a corresponding status register in a trusted execution environment.

[0132] It should be noted that this embodiment does not limit the specific status register, for example, a status register may be added in the trusted execution environment, or an existing status register in the trusted execution environment may be used. For example, an existing platform configuration register in the trusted execution environment may be used as the status register.

[0133] S202: When a hot restart of the device is detected, a target program to be reloaded is determined, and a status register of the target program is reset.

[0134] S203: re-use the target program as the program to be verified, and re-execute the steps of sending the data to be verified of the program to be verified to the trusted execution environment before the program to be verified runs, and verifying the data to be verified in the trusted execution environment.

[0135] Hot restart is a means to ensure service availability, allowing services to restart without interrupting established connections. Hot restart does not require reloading the system or service, but only reloading some components or resources, allowing restart without interrupting existing connections, ensuring service continuity and stability. Therefore, when determining that the device triggers a hot restart, this embodiment needs to determine the target program to be reloaded, reset the status register of the target program, and then recheck the target program to prevent attackers from tampering with the target program during the process of reloading the target program, thereby effectively ensuring device security.

[0136] Based on the above embodiments, the above device startup verification method is fully introduced below based on specific examples. The present invention proposes a bootkit attack detection and defense method based on TEE trusted root for bootkit attacks from the hardware firmware level. The present invention is composed of a trusted root component, a trusted proxy component, a trusted recovery component, a secure storage component and a supporting certificate management mechanism, which are specifically composed as follows: Figure 2 shown.

[0137] 1) Trusted root component: running in TEE, the trusted root component is specifically composed of a trusted verification module, a trusted policy management module, a security detection module, etc.;

[0138] a) Trusted policy management module: Management content includes trusted benchmark value, trusted verification policy, and certificate chain management;

[0139] b) Security detection module: detect malicious programs based on strategies and feature library information;

[0140] c) Trusted verification module: Verify the legitimacy and integrity of specific programs or files;

[0141] 2) Trusted agent component: runs in the firmware and implements trusted verification of the boot process through interaction with TEE;

[0142] 3) Trusted recovery component: runs in the firmware and provides the function of restoring the trusted firmware when the firmware program is detected to be untrustworthy during the boot process, thus ensuring availability;

[0143] 4) Secure storage component: used to store malicious program signature database, trusted verification strategy, etc.

[0144] The certificates managed by the certificate management mechanism of the present invention include platform root certificates, firmware verification root certificates, third-party firmware module verification root certificates, and OS component verification root certificates, which have the following functions:

[0145] 1) Platform root certificate: imported by the machine manufacturer, the source is generally a trusted third party or machine manufacturer recognized by the customer; the platform root certificate is the root certificate of the machine.

[0146] 2) Firmware Verification Root Certificate: Verifies the legitimacy and integrity of the firmware when the system starts. It is imported by the machine manufacturer and the source is generally the machine manufacturer (except for ODM customization). The firmware verification root certificate is issued based on the platform root certificate. When imported, its integrity is verified based on the public key provided by the platform root certificate.

[0147] 3) Third-party firmware module verification root certificate: Verifies the legitimacy and integrity of third-party firmware modules and is issued by a third-party organization recognized by the machine manufacturer or customer.

[0148] 4) OS software verification root certificate: verifies the legitimacy and integrity of the OS software and is issued by the OS manufacturer or a trusted third party recognized by the OS manufacturer and customers.

[0149] The specific implementation process is as follows:

[0150] Computer (such as server) production link:

[0151] Step 1: The computer manufacturer imports the platform root certificate (the root key is an asymmetric key, such as RSA or ECC), derives the manufacturer's firmware signing key based on the platform root key, and signs the manufacturer's firmware based on the key; deploys the firmware module trusted reference value and trusted verification policy to the TEE secure storage area;

[0152] Step 2: The processor manufacturer signs the trusted root component based on the TEE root key

[0153] Step 3: The computer manufacturer integrates the platform trusted firmware and supporting certificates provided by the processor manufacturer, and integrates the trusted root component program into the firmware; imports the malicious program feature library into the TEE secure storage area;

[0154] User deployment phase:

[0155] Step 1: During the user deployment phase, the security administrator imports the trusted benchmark values ​​and trusted verification policies of the operating system core programs (such as the system kernel, driver modules, system configuration files, system boot programs, etc.);

[0156] During system use: (e.g. Figure 3 shown)

[0157] Step 1: During the system startup process, TEE runs first to verify the legitimacy and integrity of the computer system (entire machine) firmware. After the verification passes, the system firmware continues to load and execute;

[0158] Step 2: During system startup, the system firmware calls TEE to verify the legitimacy and integrity of the firmware application, firmware driver, and component oprom, and to detect whether the program contains malicious program fragments;

[0159] Step 3: During system startup, the system firmware calls TEE to verify the legitimacy and integrity of the system boot program and detect whether the system boot program contains malicious program fragments;

[0160] Step 4: During the system boot process, the boot program calls TEE to verify the legitimacy and integrity of the loaded program or file (such as the kernel, kernel driver, system configuration file, etc.), and detect whether the program or file contains malicious program fragments;

[0161] Step 5: In the above process, when the detection result is untrustworthy, the defense response behavior is triggered according to the trusted verification strategy. The behavior may include alarm, stop start, restart, recovery and other operations.

[0162] During a system hot restart: (e.g. Figure 4 shown)

[0163] Step 1: Restart the component to reset the system-related PCRs in the root of trust;

[0164] Step 2: The restart component (such as kexec) loads the kernel, and then the restart component calls TEE to verify the legitimacy and integrity of the loaded program or file (such as the kernel, kernel driver, system configuration file, etc.), and detect whether the program or file contains malicious program fragments;

[0165] Step 3: In the above process, when the detection result is untrustworthy, the defense response behavior is triggered according to the trusted verification strategy. The behavior may include alarm, stop start, restart, recovery and other operations.

[0166] The following is an introduction to the device startup verification device, electronic device, computer program product, and computer-readable storage medium provided in the embodiments of the present invention. The device startup verification device, electronic device, computer program product, and computer-readable storage medium described below can be referenced to the device startup verification method described above.

[0167] Please refer to Figure 5 , Figure 5 A structural block diagram of a device startup verification device provided by an embodiment of the present invention, which is applied to a trusted execution environment of a processor and may include:

[0168] Initialization module 501, used to initialize the trusted execution environment of the processor when detecting that the device triggers power-on startup;

[0169] Verification module 502, used to sequentially use the firmware program, boot program, and operating system program as programs to be verified, and before the programs to be verified are run, send the data to be verified of the programs to be verified to the trusted execution environment, and verify the data to be verified in the trusted execution environment; wherein the data to be verified includes a signature value, an integrity check value, and a program fragment;

[0170] The operation trigger module 503 is used to trigger the program to be verified to start running if it is determined that the data to be verified passes the verification;

[0171] The execution preventing module 504 is used to prevent the program to be verified from running if it is determined that the data to be verified has not passed the verification.

[0172] Optionally, the initialization module 501 includes:

[0173] A loading verification submodule is used to load the trusted root component program into the trusted execution environment and use the processor key to perform signature verification on the trusted root component program; wherein the processor key is set in the processor in a hardware encapsulation manner;

[0174] A running submodule, used to run the trusted root component program if it is determined that the trusted root component program passes the signature verification;

[0175] The exception handling submodule is used to perform exception handling if it is determined that the trusted root component program has not passed the signature verification.

[0176] Optionally, the verification module 502 includes:

[0177] The reading submodule is used to read the data to be verified of the firmware program before the firmware program is loaded, and send the data to be verified of the firmware program to the trusted execution environment;

[0178] The first call response submodule is used to add the to-be-verified data of the boot program sent by the firmware program to the trusted execution environment if a call of the firmware program is detected when the firmware program is running; wherein the firmware program calls the trusted execution environment when loading the boot program;

[0179] The second call response submodule is used to add the to-be-verified data of the operating system program sent by the boot program to the trusted execution environment if a call of the boot program is detected when the boot program is running; wherein the boot program calls the trusted execution environment when loading the operating system program.

[0180] Optionally, read submodules, including:

[0181] A reading unit, used for reading the to-be-verified data of the initial program loader in the firmware program, and sending the to-be-verified data of the initial program loader to the trusted execution environment;

[0182] A loading unit, configured to load the initial program loader program when it is determined that the initial program loader program passes the verification;

[0183] The call response unit is used to add the to-be-verified data of other firmware programs sent by the initial program loader to the trusted execution environment if a call of the initial program loader is detected; wherein the initial program loader calls the trusted execution environment when loading other firmware programs.

[0184] Optionally, the device may further include:

[0185] A register recording module, for recording the verification status of the program to be verified to a corresponding status register in the trusted execution environment when it is determined that the program to be verified has passed the verification;

[0186] The register reset module is used to determine the target program to be reloaded and reset the status register of the target program when a hot restart of the device is detected;

[0187] The re-verification module is used to re-use the target program as the program to be verified, and re-execute the steps of sending the data to be verified of the program to be verified to the trusted execution environment before the program to be verified runs, and verifying the data to be verified in the trusted execution environment.

[0188] Optionally, the device may further include:

[0189] The exception handling module is used to stop the startup process of the device and output a preset alarm message; and / or control the device to restart; and / or perform program recovery on the program to be verified.

[0190] Optionally, the verification module 502 includes:

[0191] A channel establishment submodule is used to establish a secure access channel between a trusted execution environment and a secure storage device;

[0192] The verification submodule is used to control the trusted execution environment to access the secure storage device through the secure access channel, and use the root certificate preset by the secure storage device to verify the signature value, use the trusted reference value preset by the secure storage device to verify the integrity check value, and use the malicious program feature library preset by the secure storage device to verify the program fragment; wherein the root certificate, trusted reference value, and malicious program feature library are hardware encrypted by the secure storage device.

[0193] Optionally, the check submodule may include:

[0194] The security verification unit is used to detect the program fragment using the malicious program features in the malicious program feature library to determine whether the program fragment is a malicious program fragment; if it is determined that the program fragment is not a malicious program fragment, it is determined that the program fragment has passed the verification; if it is determined that the program fragment is a malicious program fragment, it is determined that the program fragment has not passed the verification.

[0195] Optionally, the check submodule may include:

[0196] The legitimacy verification unit is used to obtain the root certificate corresponding to the program to be verified, and obtain the signature verification public key from the root certificate; use the signature verification public key to perform signature verification on the signature value; if it is determined that the signature value passes the signature verification, it is determined that the signature value passes the verification; if it is determined that the signature value does not pass the signature verification, it is determined that the signature value does not pass the verification.

[0197] Optionally, the check submodule may include:

[0198] The integrity check unit is used to perform hash calculation on the program to be verified to obtain the integrity check value of the program to be verified; determine whether the integrity check value is the same as the trusted reference value corresponding to the program to be verified; if the integrity check value is the same as the trusted reference value corresponding to the program to be verified, determine that the signature value has passed the verification; if the integrity check value is not the same as the trusted reference value corresponding to the program to be verified, determine that the signature value has not passed the verification.

[0199] Please refer to Figure 6 , Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. The embodiment of the present invention provides an electronic device 10, including a processor 11 and a memory 12; wherein the memory 12 is used to store computer programs; the processor 11 has a trusted execution environment, which is used to execute the device startup verification method provided in the aforementioned embodiment when executing the computer program.

[0200] For the specific process of the above-mentioned device startup verification method, reference may be made to the corresponding contents provided in the aforementioned embodiments, which will not be repeated here.

[0201] Furthermore, the memory 12, as a carrier for storing resources, may be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the storage method may be temporary storage or permanent storage.

[0202] In addition, the electronic device 10 also includes a power supply 13, a communication interface 14, an input / output interface 15 and a communication bus 16; wherein the power supply 13 is used to provide working voltage for each hardware device on the electronic device 10; the communication interface 14 can create a data transmission channel between the electronic device 10 and an external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present invention, and is not specifically limited here; the input / output interface 15 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0203] Optionally, the electronic device 10 further comprises a secure storage device 17 for storing a root certificate, a trusted reference value and a malicious program feature library, and the root certificate, the trusted reference value and the malicious program feature library are hardware encrypted by the secure storage device.

[0204] An embodiment of the present invention further provides a computer program product, including a computer program / instruction, which implements the device startup verification method described in the above embodiment when the computer program / instruction is executed by a processor.

[0205] Since the embodiments of the computer program product part correspond to the embodiments of the device startup verification method part, please refer to the description of the embodiments of the device startup verification method part for the embodiments of the computer program product part, which will not be repeated here.

[0206] An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the device startup verification method described in the above embodiment is implemented.

[0207] Since the embodiments of the computer-readable storage medium part correspond to the embodiments of the device startup verification method part, please refer to the description of the embodiments of the device startup verification method part for the embodiments of the storage medium part, which will not be repeated here.

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

[0209] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0210] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0211] The device startup verification method, apparatus, electronic device, program product and medium provided by the present invention are introduced in detail above. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. A device startup verification method, characterized in that: include: When it is detected that the device triggers power-on startup, the trusted execution environment of the processor is initialized; The firmware program, the boot program, and the operating system program are sequentially used as programs to be verified. Before the programs to be verified are run, the data to be verified of the programs to be verified are sent to the trusted execution environment, and the data to be verified are verified in the trusted execution environment; wherein the data to be verified includes a signature value, an integrity check value, and a program fragment; If it is determined that the data to be verified passes the verification, the program to be verified is triggered to start running; If it is determined that the data to be verified fails to pass the verification, the program to be verified is prevented from running.

2. The device startup verification method according to claim 1, characterized in that: Initializing the trusted execution environment of the processor includes: Loading a trusted root component program into the trusted execution environment, and using a processor key to perform signature verification on the trusted root component program; wherein the processor key is set in the processor in a hardware encapsulation manner; If it is determined that the trusted root component program passes the signature verification, running the trusted root component program; If it is determined that the trusted root component program has not passed the signature verification, exception handling is performed.

3. The device startup verification method according to claim 1, characterized in that: The step of sending the verification data of the program to be verified to the trusted execution environment before the program to be verified is run includes: Before the firmware program is loaded, reading the data to be verified of the firmware program, and sending the data to be verified of the firmware program to the trusted execution environment; When the firmware program is running, if a call of the firmware program is detected, the to-be-verified data of the boot program sent by the firmware program is added to the trusted execution environment; wherein the firmware program calls the trusted execution environment when loading the boot program; When the boot program is running, if a call of the boot program is detected, the to-be-verified data of the operating system program sent by the boot program is added to the trusted execution environment; wherein the boot program calls the trusted execution environment when loading the operating system program.

4. The device startup verification method according to claim 1, characterized in that: Also includes: When it is determined that the program to be verified passes the verification, recording the verification status of the program to be verified into a corresponding status register in the trusted execution environment; When a hot restart of the device is detected, a target program to be reloaded is determined, and a status register of the target program is reset; The target program is re-used as the program to be verified, and the steps of sending the data to be verified of the program to be verified to the trusted execution environment before the program to be verified runs, and verifying the data to be verified in the trusted execution environment are re-executed.

5. The device startup verification method according to claim 1, characterized in that: After preventing the program to be verified from running, the method further includes: Stop the startup process of the device and output a preset alarm message; and / or, controlling the device to restart; And / or, performing program recovery on the program to be verified.

6. The device startup verification method according to any one of claims 1 to 5, characterized in that: The verifying the data to be verified includes: Establishing a secure access channel between the trusted execution environment and a secure storage device; Control the trusted execution environment to access the secure storage device through the secure access channel, and use the root certificate preset in the secure storage device to verify the signature value, use the trusted reference value preset in the secure storage device to verify the integrity check value, and use the malicious program feature library preset in the secure storage device to verify the program fragment; wherein the root certificate, trusted reference value, and malicious program feature library are hardware encrypted by the secure storage device.

7. The device startup verification method according to claim 6, characterized in that: The verifying the program fragment by using the malicious program feature library preset by the secure storage device includes: Detecting the program fragment using the malicious program features in the malicious program feature library to determine whether the program fragment is a malicious program fragment; If it is determined that the program fragment does not belong to the malicious program fragment, then determining that the program fragment passes the verification; If it is determined that the program fragment belongs to the malicious program fragment, it is determined that the program fragment fails the verification.

8. The device startup verification method according to claim 6, characterized in that: The verifying the signature value by using the root certificate preset by the secure storage device includes: Obtaining a root certificate corresponding to the program to be verified, and obtaining a signature verification public key from the root certificate; Performing signature verification on the signature value using the signature verification public key; If it is determined that the signature value passes the signature verification, then it is determined that the signature value passes the verification; If it is determined that the signature value fails the signature verification, then it is determined that the signature value fails the verification.

9. The device startup verification method according to claim 8, characterized in that: The root certificate is derived from a preset platform root certificate or issued by an issuing authority.

10. The device startup verification method according to claim 6, characterized in that: The verifying the integrity check value by using the trusted reference value preset by the secure storage device includes: Performing hash calculation on the program to be verified to obtain an integrity check value of the program to be verified; Determining whether the integrity check value is the same as the trusted reference value corresponding to the program to be verified; If the integrity check value is the same as the trusted reference value corresponding to the program to be verified, it is determined that the signature value passes the verification; If the integrity check value is different from the trusted reference value corresponding to the program to be verified, it is determined that the signature value has failed the verification.

11. A device for starting up and checking equipment, characterized in that: A trusted execution environment applied to a processor, the device comprising: An initialization module, used to initialize the trusted execution environment of the processor when detecting that the device triggers power-on startup; A verification module, used to sequentially use a firmware program, a boot program, and an operating system program as programs to be verified, and before the programs to be verified are run, send the data to be verified of the programs to be verified to the trusted execution environment, and verify the data to be verified in the trusted execution environment; wherein the data to be verified includes a signature value, an integrity check value, and a program fragment; A running trigger module is used to trigger the program to be verified to start running if it is determined that the data to be verified passes the verification; The operation preventing module is used to prevent the program to be verified from running if it is determined that the data to be verified has not passed the verification.

12. An electronic device, characterized in that: include: Memory for storing computer programs; A processor having a trusted execution environment, configured to implement the device startup verification method according to any one of claims 1 to 10 when executing the computer program.

13. The electronic device according to claim 12, characterized in that: It also includes a secure storage device for storing a root certificate, a trusted reference value, and a malicious program feature library, wherein the root certificate, the trusted reference value, and the malicious program feature library are hardware encrypted by the secure storage device.

14. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the device startup verification method according to any one of claims 1 to 10 is implemented.

15. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are loaded and executed by the processor, the device startup verification method according to any one of claims 1 to 10 is implemented.

Images