Safe starting method and device

Abstract

The invention provides a safe starting method and device, and relates to the technical field of terminals. The problem that the equipment cannot be safely started is solved. Obtaining to-be-executed software and a software signature of the to-be-executed software; storing the to-be-executed software and the software signature to a target storage area; based on the message digest, the software signature and the asymmetric public key of the to-be-executed software, performing integrity verification on the to-be-executed software stored in the target storage area to obtain an integrity verification result; based on the message digest of the to-be-executed software, trusted measurement is conducted on the to-be-executed software stored in the target storage area, and a trusted measurement result is obtained; and under the condition that the integrity verification result is used for indicating that the integrity verification of the to-be-executed software stored in the target storage area is passed and the trusted measurement result is used for indicating that the to-be-executed software stored in the target storage area is trusted, executing the to-be-executed software stored in the target storage area.

Description

Technical Field

[0001] This application relates to the technical field of terminals, and in particular, to a secure boot method and device. Background Art

[0002] In the industry of ensuring the security of device startup, two key technologies are mainly relied on: secure boot and trusted boot. The core mechanism of secure boot is to verify the integrity of each level of software one by one during the device startup process, so as to prevent the intrusion of malicious software. And trusted boot is: when starting the device, measure the digest of each level of software, and record the digest value in a cryptographic way. After the device startup is completed, send the recorded digest value to the server. The server verifies the integrity of the device startup software.

[0003] Since trusted boot only measures the digest value of software during the device startup stage and records it in a cryptographic way, and cannot monitor and prevent the loading of illegal software in real time, it cannot immediately prevent the loading of illegal software on the device. Therefore, in practical applications, secure boot and trusted boot are usually combined to enhance the security of the system. Nevertheless, highly skilled attackers may still find vulnerabilities to attack. For example, they will take advantage of the time difference between the system checking the resource status and actually using the resources, and manipulate the resource status to bypass the security protection measures. Generally, this attack method is called the Time-of-Check to Time-of-Use (TOC-TOU) attack. However, in the existing device startup process, the Trusted Computing Base (TCB) generally regards the integrity verification, trusted measurement and the operation of the next level of software as independent links. Therefore, this separated operation results in potential security windows. Once the verification of a certain level of software (such as integrity verification and / or trusted measurement) is completed but the software of this level has not been executed yet, highly skilled attackers may use this time difference to implement the TOC-TOU attack, that is, by tampering with the verified resources or implanting malicious code in the verified resources, so as to bypass the security protection measures, enabling illegal software to be loaded and executed in the subsequent startup process.

[0004] Therefore, how to enable the device to start up securely has become an urgent problem to be solved in this field. Summary of the Invention

[0005] The embodiments of this application provide a secure boot method and device, which solve the problem that the device cannot start up securely.

[0006] To achieve the above object, the embodiments of this application provide the following technical solutions:

[0007] In a first aspect, a secure boot method is provided, and the method may include:

[0008] First, obtain the software to be executed and the software signature of the software to be executed; store the software to be executed and the software signature in the target storage area; perform integrity verification on the software to be executed stored in the target storage area based on the message digest, software signature, and asymmetric public key of the software to be executed to obtain an integrity verification result; perform trusted measurement on the software to be executed stored in the target storage area based on the message digest of the software to be executed to obtain a trusted measurement result; execute the software to be executed stored in the target storage area when the integrity verification result is used to indicate that the integrity verification of the software to be executed stored in the target storage area passes, and the trusted measurement result is used to indicate that the software to be executed stored in the target storage area is trusted. Exemplarily, for the software to be executed and the software signature, they can be obtained after the trusted root is securely booted.

[0009] Adopting the above technical solution, by storing the software to be executed in the target storage area, performing integrity verification and trusted measurement on the software to be executed in the target storage area, and executing the software to be executed stored in the target storage area when the integrity verification of the software to be executed stored in the target storage area passes and the trusted measurement result indicates that the software to be executed stored in the target storage area is trusted. In this way, by performing the integrity verification, trusted measurement, and execution control of the software to be executed in the same trusted environment, the consistency of the objects processed in the three execution processes is ensured, and the secure boot of the device is guaranteed.

[0010] Combined with the first aspect, in a possible implementation, after storing the software to be executed and the software signature in the target storage area, it further includes: setting the attribute of the target storage area to read-only. In this way, it effectively prevents data from being modified, deleted, or overwritten, protects the security of the software to be executed, and further ensures the secure boot of the device.

[0011] Combined with the first aspect, in a possible implementation, before executing the software to be executed stored in the target storage area, it further includes: setting the attribute of the target storage area to executable. In this way, by adding execution permission control in the target storage area, the software to be executed will not be executed before the integrity verification and trusted measurement are completed, which can ensure to a certain extent that before the software to be executed is executed, the only storage area where the system can run is the code of the current stage, ensuring that the software to be executed can be securely executed.

[0012] Combined with the first aspect, in a possible implementation, it further includes: the integrity verification process, the trusted measurement process, and the process of setting the attribute of the target storage area to executable are executed in the first environment; the security level of the first environment is higher than that of the second environment; the second environment is the environment for loading and executing the software to be executed. In this way, performing security verification and control execution in the first environment with a higher security level can effectively ensure the security of the software to be executed.

[0013] In combination with the first aspect, in a possible implementation, it further includes: The secure boot device includes an integrity verification module, a trusted measurement module, and an execution controller; wherein, the integrity verification module is used to implement the integrity verification process in the first environment; the trusted measurement module is used to implement the trusted measurement process in the first environment; the execution controller is used to execute the process of setting the attribute of the target storage area to executable in the first environment when the integrity verification result is used to indicate that the integrity verification of the software to be executed stored in the target storage area passes, and the trusted measurement result is used to indicate that the software to be executed stored in the target storage area is trusted. In this way, according to the secure boot method of step-by-step verification, the security of the software to be executed is greatly improved.

[0014] In combination with the first aspect, in a possible implementation, it further includes: When the integrity verification result is used to indicate that the integrity verification of the software to be executed stored in the target storage area passes, the integrity verification module sends the address of the target storage area to the execution controller; the execution controller sends the address of the target storage area to the trusted measurement module; performing a trusted measurement on the software to be executed stored in the target storage area includes: The trusted measurement module performs a trusted measurement on the software to be executed stored in the target storage area based on the address of the target storage area. Exemplarily, the above process of address transmission is performed in the above first environment. In this way, by passing parameters and sharing content in this secure environment, the consistency and security of the three execution objects are ensured.

[0015] In combination with the first aspect, in a possible implementation, it further includes: When the trusted measurement result is used to indicate that the software to be executed stored in the target storage area is trusted, the trusted measurement module sends the trusted measurement result to the execution controller; setting the attribute of the target storage area to executable includes: The execution controller responds to receiving the trusted measurement result and sets the attribute of the target storage area to executable. Exemplarily, when the integrity verification result is used to indicate that the integrity verification of the next-level software stored in the target storage area passes, the integrity verification module can send the address of the target storage area to the execution controller. The execution controller can send the address of the target storage area to the trusted measurement module. In this way, it is ensured that before the software to be executed is executed, the software to be executed has passed the integrity verification and trusted measurement, ensuring the secure boot of the device.

[0016] In combination with the first aspect, in a possible implementation, the secure boot device further includes: A loading module running in the second environment, and the loading module is used to implement the process of storing the software to be executed and the software signature into the target storage area.

[0017] In combination with the first aspect, in a possible implementation, it further includes: after the loading module finishes storing the software to be executed and the software signature, it sends the address of the target storage area to the integrity verification module; performing integrity verification on the software to be executed stored in the target storage area, including: the integrity verification module performs integrity verification on the software to be executed stored in the target storage area based on the address of the target storage area. Exemplarily, after the integrity verification module finishes the integrity verification of the next-level software in the first environment, it can also feedback the integrity verification result to the startup verification module running in the second environment. In the case where the integrity verification result is used to indicate that the integrity verification of the next-level software stored in the target storage area fails, the startup can be stopped. In the case where the integrity verification result is used to indicate that the integrity verification of the next-level software stored in the target storage area passes, the security verification continues. In this way, the consistency and security of the software to be executed verification are ensured.

[0018] In combination with the first aspect, in a possible implementation, before setting the attribute of the target storage area to read-only, the attribute of the target storage area is readable, writable and non-executable. In this way, it effectively prevents data from being modified, deleted or overwritten, and protects the security of the software to be executed.

[0019] In a second aspect, an apparatus is provided, and the apparatus has the function of implementing the behavior of the electronic device in the method described in the first aspect above. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, for example, a communication unit or module, a processing unit or module, a storage unit or module.

[0020] In a third aspect, an electronic device is provided, and the electronic device includes: a processor; a memory; and a computer program, wherein the computer program is stored on the memory, and when the computer program is executed by the processor, the electronic device is enabled to execute the method described in any one of the first aspect above.

[0021] In a fourth aspect, a computer-readable storage medium is provided, and the computer-readable storage medium includes a computer program, and when the computer program runs on an electronic device, the electronic device can execute the method described in any one of the first aspect above.

[0022] In a fifth aspect, a computer program product containing instructions is provided, and when it runs on an electronic device, the electronic device can execute the method described in any one of the first aspect above.

[0023] In a sixth aspect, an embodiment of the present application provides a chip, and the chip includes a processor, and the processor is used to call a computer program in the memory to execute the method described in any one of the first aspect.

[0024] Understandably, for the beneficial effects that can be achieved by the device described in the second aspect provided above, the electronic device described in the third aspect, the computer-readable storage medium described in the fourth aspect, the computer program product described in the fifth aspect, and the chip described in the sixth aspect, reference can be made to the beneficial effects in the first aspect and any possible implementation manner thereof, which will not be elaborated herein. Description of the Drawings

[0025] Figure 1 Schematic diagram of a secure boot method provided by the related art;

[0026] Figure 2 Schematic diagram of another secure boot method provided by the related art;

[0027] Figure 3 Schematic diagram of a trusted boot method provided by the related art;

[0028] Figure 4 Schematic diagram of another trusted boot method provided by the related art;

[0029] Figure 5 Schematic flowchart of a secure boot method provided by an embodiment of the present application;

[0030] Figure 6 Schematic diagram of a secure boot method provided by an embodiment of the present application;

[0031] Figure 7 Schematic diagram of another secure boot method provided by an embodiment of the present application;

[0032] Figure 8 Schematic diagram of another secure boot method provided by an embodiment of the present application;

[0033] Figure 9 Schematic diagram of the composition of a secure boot device provided by an embodiment of the present application;

[0034] Figure 10 Schematic diagram of the hardware structure of a secure boot device provided by an embodiment of the present application. Detailed Embodiments

[0035] To make the objectives, technical solutions, and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be construed as limitations on the present application. All other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application.

[0036] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

[0037] In the following description, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present application, unless otherwise specified, the meaning of "a plurality" is two or more.

[0038] It can be understood that some optional features in the embodiments of the present application may, in certain scenarios, be implemented independently without relying on other features, such as the current solution they are based on, to solve the corresponding technical problems and achieve the corresponding effects. In some scenarios, they may also be combined with other features according to requirements. Correspondingly, the devices given in the embodiments of the present application can also implement these features or functions accordingly, which will not be elaborated here.

[0039] Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meaning as commonly understood by those skilled in the art to which this application belongs. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0040] In scenarios where the security of device startup is ensured, it mainly relies on two key technologies: secure boot and trusted boot.

[0041] Among them, the general idea of secure boot is that during the device startup process, the integrity of each level of software is verified step by step using a verification algorithm. For each level of software, when its integrity verification passes, the software at that level can be loaded continuously; otherwise, the startup stops.

[0042] Specifically, in combination with Figure 1 , the process of ensuring device startup security using the secure boot technology is introduced. As Figure 1As shown, during the device startup process, the trust root for secure startup can be initiated first. Here, the trust root generally refers to a special area on the device that stores information such as keys and certificates related to secure startup. This information can be used to verify the legitimacy of other software on the device. When the device starts up, the device can first perform the operation of starting the trust root. After the trust root is securely started, the first-stage startup code of the device can be obtained in the startup sequence and integrity verification can be performed. For example, based on the information stored in the trust root, it can be verified whether the first-stage startup code is complete and correct. In the case of a verification failure, the device can stop starting up, and at this time, the startup fails. In the case of a successful verification, it means that the current first-stage startup code is complete and secure, and then the first-stage startup code can be executed. Additionally, the second-stage startup code can be continuously obtained and integrity verification can be performed. For example, the information stored in the trust root can be used to perform integrity verification on the second-stage startup code. When the verification of the second-stage startup code fails, the device stops starting up, and at this time, the startup fails. When the verification of the second-stage startup code passes, the second-stage startup code can be continuously executed. And so on, the integrity verification of each stage of startup code is carried out by means of one-by-one verification. It can be understood that when the verification of any stage of startup code fails, the startup will stop. After the verification of any stage of startup code passes, the code of that stage can be run. Only when all startup codes pass the integrity verification and are run (or say started) can the startup of the device be completed.

[0043] Among them, in the above process, each stage of startup code can be regarded as a piece of software. That is to say, in secure startup, the integrity of each stage of software can be verified by means of one-by-one verification to ensure the security of device startup. Additionally, the security verification of the next-stage startup code or the next-stage software can generally be carried out when the current-stage startup code (or the current-stage software) is running.

[0044] The following combines Figure 2 , taking the security verification of the next-stage software as an example when it is carried out during the running of the current-stage software, to illustrate the secure startup process of the next-stage software. For example Figure 2As shown, the next-level software can be loaded first. Exemplarily, after the integrity check of the current-level startup code is passed, the current-level startup code can be run. During the running of the current-level startup code, the current-level startup code can read the next-level software and software signature from a non-volatile memory (NVM) and store them in an internal double data rate (DDR) or a static random access memory (SRAM). After that, the integrity check of the next-level software can be performed. Exemplarily, the current-level startup code can check the integrity of the next-level software stored in the internal DDR or SRAM by executing an integrity check logic. The verification algorithm generally uses an asymmetric cryptography signature-verification algorithm, or is also called an asymmetric signature verification algorithm, or a signature verification algorithm.

[0045] Among them, the basic process of verification can include: calculating the digest of the next-level software to obtain the corresponding digest value. For example, the corresponding hash value can be calculated using a hash digest algorithm, or the corresponding digest value can also be calculated using the SM3 digest algorithm. Then, read the public key in the asymmetric algorithm on the device, or simply referred to as the asymmetric public key. After that, use the calculated digest value, the stored software signature, and the obtained asymmetric public key as the input of the signature verification algorithm and execute the signature verification algorithm. For example, the signature verification algorithm can be: Rivest-Shamir-Adleman (RSA) signature verification, Elliptic Curve Cryptography (ECC) signature verification, national cipher SM2 signature verification, etc. After executing the verification algorithm, the signature verification algorithm can output a verification result. If the next-level software has not been tampered with, the signature verification can pass, and the output verification result can be used to indicate that the integrity check has passed the verification. On the contrary, the output verification result is used to indicate that the integrity check fails, that is, it means that the next-level software is insecure or has been tampered with.

[0046] When the verification result indicates that the integrity check fails, or the check fails, the device can stop starting. The device can also enter a startup error handling process, such as including restarting the device, switching the startup partition (starting the standby partition software), or entering the recovery mode, etc.

[0047] When the verification result indicates that the integrity check has passed, other functions can be started. It can be understood that during the startup process of a certain level of software, in addition to the integrity check, there are a large number of other startup business logics, such as starting command-line support, driver initialization, environment initialization, etc. Therefore, after the integrity check has passed, these other startup functions can be started. After that, after the local startup code has finished running or the local software startup function has been completed, the next-level software can be run. For example, after the local startup code has finished running, through a line of jump execution instruction, the code of the next-level software that has passed the integrity check can be jumped to and executed.

[0048] The Trusted Computing Group (TCG) describes trusted technology as: "If an entity's behavior always proceeds in the expected manner and towards the expected goal, then it is trusted." Trusted startup is the starting point for building system trust. Trusted startup constructs a trust chain step by step through the method of integrity measurement. The implementation method of trusted startup is: during the device startup process, measure the digest of each level of software and record the digest value in a cryptographic manner. After the device startup is completed, send the recorded digest value to the server to verify the integrity of the device startup software through the server.

[0049] Specifically, combined with Figure 3 , the process of using the technology of trusted startup to ensure the security of device startup will be introduced. As Figure 3 shown, during the device startup process, the root of trust can be safely (or trusted) started first. After the root of trust has been safely started, the first-level startup code of the device can be obtained according to the startup sequence, measure the digest of the first-level startup code, and record the measurement result in a cryptographic manner, that is, record the obtained digest value, so as to achieve the secure storage of the measurement result. After the measurement of the first-level startup code is completed, the second-level startup code can be continuously obtained, and the second-level startup code can be trusted-measured in the same way, and the measurement result can be safely stored. And so on, each level of startup code is trusted-measured through the method of measuring one by one. It can be understood that the device can store the measurement results of each level of startup code. After the device startup is completed, the stored measurement results can be sent to the server to enable it to verify the integrity of the device startup software using the recorded measurement results (i.e., digest values). Similarly, in the above process, each level of startup code can be regarded as a piece of software. In addition, the trusted measurement of the next-level startup code or the next-level software can generally be carried out when the local startup code (or the local software) is running.

[0050] Next, combined with Figure 4 , taking the security check of the next-level software as an example when it is carried out during the operation of the local software, the trusted startup process of the next-level software will be described. As Figure 4As shown, the next-level software and software signature can be loaded first. For the specific process of loading the next-level software and software signature, reference can be made to the description of the corresponding content in Figure 2 the example shown. Details are not elaborated here. After that, the next-level software can be measured for trust. Exemplarily, the hash digest algorithm or SM3 digest algorithm can be used to calculate the digest of the next-level software to obtain the corresponding digest value. Then, the digest value is measured, and the measurement result is recorded through a secure cryptographic method. Among them, common trust measurement techniques include: the extension technology of the Platform Configuration Register (PCR) of the Trusted Platform Module (TPM) chip and the derivation of the Dynamic Root of Trust for Measurement (DICE) framework. After recording the measurement result, other functions can be started, and after the local startup code runs to completion, the next-level software is run. For the specific process of starting other functions and running the next-level software, reference can be made to Figure 2 the description of the corresponding content in the example shown. Details are not elaborated here. In addition, in addition to the above software, the scope of trust measurement can also include some security configurations and device states during the startup process, etc. The embodiments of the present application do not specifically limit the scope of trust measurement here. The following embodiments are described by taking the scope of trust measurement including software as an example, but the scope of trust measurement is not limited thereto.

[0051] However, since the trusted startup only records the digest value of the next-level software at the device end and does not prevent the startup process, it is impossible to monitor and prevent the loading of illegal software on the device in real time. Therefore, usually, the two technologies of secure startup and trusted startup are used for security verification during device startup to enhance the security of the system. However, since in the combined scheme of secure startup and trusted startup, the integrity verification, trust measurement, and the running of the next-level software are all carried out independently, this separated operation results in a potential security window, enabling attackers to use the existing time difference to launch attacks. Therefore, the secure startup of the device cannot be guaranteed.

[0052] For example, an attacker can utilize the time difference between integrity verification, trusted measurement, and the operation of the next-level software to launch a TOC-TOU attack on the device. Specifically, a verification–operation TOC-TOU attack can be launched on the device. For example, after performing integrity verification on the software but before running the software, modify the content of the software to be run. Then, the modified software is run. A verification–measurement TOC-TOU attack can also be launched on the device. For example, according to the separation of integrity verification and trusted measurement, inject an arbitrary value into the measurement input interface, causing software that should not pass the measurement to be wrongly considered trusted. Additionally, vulnerabilities in the implementation of the secure boot code may also lead to the bypassing of trusted measurement. A measurement–operation TOC-TOU function can also be launched on the device. For example, after performing trusted measurement on the software but before running the software, modify the content of the software to be run. Then, the modified software is run. All of these will result in the device being unable to boot securely.

[0053] To solve the above problems, an embodiment of the present application provides a secure boot method. Specifically, the software to be executed can be stored in a target storage area. Then, perform integrity verification and trusted measurement on the software to be executed in the target storage area. Finally, when the integrity verification of the software to be executed stored in the target storage area passes and the trusted measurement result indicates that the software to be executed stored in the target storage area is trusted, execute the software to be executed stored in the target storage area. In this way, by performing the integrity verification, trusted measurement, and execution control of the software to be executed in the same trusted environment, the consistency of the objects processed in the three execution processes is ensured, and the secure boot of the device is guaranteed.

[0054] Figure 5 It is a schematic flowchart of a secure boot method provided by an embodiment of the present application. As Figure 5 shown, this method can be applied to a secure boot device, and this method may include:

[0055] S501. The secure boot device obtains the software to be executed and the software signature of the software to be executed.

[0056] Among them, the software signature is used to indicate the digital certificate information of the signed software and can be used to verify the identity and code integrity of the publisher of the software to be executed.

[0057] During the startup process of the device, the process from initialization to the full operation of the operating system involves multiple levels of software. To ensure the security of device startup, each level of software needs to undergo a security check before running. Therefore, in the embodiments of the present application, the software to be executed can be any level of software among the multiple levels of software that need to run during the device startup process. Obtaining the software to be executed can be to obtain the software to be executed according to the startup order of each level of software. For example, the secure startup device can obtain the software to be executed during the process where the software of the current level passes the security check and is executed, and the software to be executed can be the next-level software of the software of the current level. That is to say, the secure startup device can obtain the software to be started, that is, the next-level software, during the operation of the software of the current level. Of course, for the first-level software, it can be obtained after the root of trust is securely started.

[0058] Exemplarily, the secure startup device can read the software to be executed at the current level and the software signature of the software to be executed from the NVM.

[0059] S502. The secure startup device stores the software to be executed and the software signature in the target storage area.

[0060] Among them, the target storage area can be a storage area in the device's DDR or SRAM, which is used to store the obtained software to be executed and the software signature of the software to be executed.

[0061] In the embodiments of the present application, after the secure startup device obtains the software to be executed and the software signature of the software to be executed, such as reading the software to be executed at the current level and the software signature of the software to be executed from the NVM, it can store the read software to be executed and the software signature in the target storage area in the DDR or SRAM.

[0062] To ensure that the software to be executed stored is not tampered with, after the secure startup device stores the software to be executed and the software signature in the target storage area, it can also set the attribute of the target storage area to read-only. It can be understood that after the attribute of the target storage area is set to read-only, the data stored in the target storage area, such as the software to be executed, is only allowed to be read, and is not allowed to be modified or executed.

[0063] Exemplarily, in combination with Figure 6 , the process of obtaining and storing the software to be executed and the software signature of the software to be executed in the above S501 and S502 can also be referred to as the loading process. That is, when the device starts up, the secure startup device can load the next-level software when the software of the current level passes the check and runs. Of course, for the first-level software, it can be loaded after the root of trust is securely started.

[0064] Continuing in combination with Figure 6, after the security startup device loads the software to be executed, the integrity of the software to be executed can be verified. In the embodiments of the present application, verifying integrity includes an integrity verification process and a trusted measurement process. When both of the above verifications pass, the execution of the software to be executed can be controlled. The integrity verification process, the trusted measurement process, and the execution control process are introduced below with reference to S503 - S506.

[0065] S503. The security startup device performs an integrity verification on the software to be executed stored in the target storage area to obtain an integrity verification result.

[0066] In the embodiments of the present application, as Figure 6 shown, after the security startup device obtains and stores the software to be executed and the software signature of the software to be executed in the target storage area, that is, after loading the software to be executed, it can perform an integrity verification on the software to be executed stored in the target storage area to verify the integrity of the software to be executed.

[0067] Exemplarily, the security startup device can use an asymmetric signature verification algorithm to perform an integrity verification on the software to be executed stored in the target storage area to obtain an integrity verification result.

[0068] For example, the security startup device can first calculate the digest of the software to be executed in the target storage area to obtain the corresponding digest value. Then, based on the obtained digest value, the software signature stored in the target storage area, and the asymmetric public key stored on the device, it performs an integrity verification on the software to be executed stored in the target storage area to obtain an integrity verification result.

[0069] It should be noted that the specific integrity verification process is similar to the integrity verification process performed in the above security startup process. For specific descriptions, reference can be made to the specific descriptions in the above embodiments and will not be elaborated here.

[0070] S504. The security startup device performs a trusted measurement on the software to be executed stored in the target storage area to obtain a trusted measurement result.

[0071] In the embodiments of the present application, as Figure 6 shown, before executing the software to be executed, the security startup device can also perform a trusted measurement on the software to be executed stored in the target storage area to verify the credibility of the software to be executed.

[0072] Exemplarily, the security startup device can perform a trusted measurement on the software to be executed stored in the target storage area to obtain a trusted measurement result.

[0073] For example, the secure boot device may first calculate the message digest of the software to be executed in the target storage area to obtain the corresponding digest value. Then, the digest value is measured. Finally, the measurement result is recorded in a secure cryptographic manner.

[0074] It should be noted that the specific trusted measurement process is similar to the trusted measurement process in the above-mentioned trusted boot process. For the specific description, reference can be made to the specific description in the above-mentioned embodiments, and details will not be elaborated here.

[0075] S505. The secure boot device executes the software to be executed stored in the target storage area.

[0076] In some embodiments, the secure boot device may control the software to be executed stored in the target storage area to be executed when the integrity check result is used to indicate that the integrity check of the software to be executed stored in the target storage area passes, and the trusted measurement result is used to indicate that the software to be executed stored in the target storage area is trusted. In this way, the software to be executed stored in the target storage area can be executed.

[0077] Exemplarily, when the secure boot device determines that the integrity check of the software to be executed passes and is trusted, it can modify the read-only attribute of the target storage area to an executable attribute, that is, control the software to be executed to be executed. In this way, the software to be executed stored in the target storage area can be executed. After the attribute of the target storage area is set to executable, the software to be executed stored in the target storage area is only allowed to be executed and not allowed to be modified.

[0078] As described in the foregoing embodiments, during the startup process of a certain level of software, in addition to verifying integrity, there are a large number of other startup business logics. Therefore, as Figure 6 shown, before the secure boot device executes the software to be executed stored in the target storage area, when the integrity check result is used to indicate that the integrity check of the software to be executed stored in the target storage area passes, the secure boot device may also execute other startup logics, such as non-security-related business logics, for example: starting command line support, driver initialization, environment initialization, etc. In this way, the above S505 can be executed when the integrity check of the software to be executed passes, is trusted, and other startup logics are completed.

[0079] With the above technical solution, by storing the software to be executed in the target storage area, performing integrity verification and trusted measurement on the software to be executed in the target storage area, and executing the software to be executed stored in the target storage area when the integrity verification of the software to be executed stored in the target storage area passes and the trusted measurement result indicates that the software to be executed stored in the target storage area is trusted. In this way, by performing the integrity verification, trusted measurement, and execution control of the software to be executed in the same trusted environment, the consistency of the objects processed in the three execution processes is ensured, and the secure startup of the device is guaranteed.

[0080] It can be understood that during the startup process of a software to be executed, a large amount of code needs to be executed, but not all of the code will affect the security of the software to be executed during the startup process. That is to say, for the startup of a software to be executed, in addition to the code corresponding to the software to be executed, there is also a large amount of other startup-related code, such as the code corresponding to the above other startup logics. These codes are necessary for starting the software to be executed, but do not need to be subjected to integrity verification and trusted measurement, that is, they have no impact on the security of starting the software to be executed. In this application, in order to ensure the security of device startup, in the embodiments of this application, the above integrity verification process, trusted measurement process, and execution control process (that is, the process of setting the attribute of the target storage area to be executable) can be executed in the first environment. The process of obtaining the software to be executed and the software signature (that is, the loading process), the process of executing other startup logics, and the process of executing the software to be executed stored in the target storage area are executed in the second environment.

[0081] Among them, the security level of the first environment is higher than that of the second environment. Exemplarily, the first environment can also be referred to as a secure operating environment, a secure environment, or a trusted environment, etc. The second environment can also be referred to as a non-secure operating environment, a non-secure environment, or a non-trusted environment, etc. This application does not make any limitations here.

[0082] It can be understood that the functions of the secure startup device provided by the embodiments of this application can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. For example, the secure startup device can include an integrity verification module, a trusted measurement module, and an execution controller.

[0083] Among them, the integrity check module can be used to implement the integrity check process in the first environment, such as executing the above S503. The trust measurement module can be used to implement the trust measurement process in the first environment, such as executing the above S504. The execution controller can be used to execute the process of setting the attribute of the target storage area to executable in the first environment when the integrity check result is used to indicate that the integrity check of the software to be executed stored in the target storage area has passed, and the trust measurement result is used to indicate that the software to be executed stored in the target storage area is trustworthy, that is, to perform execution control. The following is combined with the modules and Figure 7 , taking the software to be executed as the next level software as an example, the secure boot method provided by the embodiment of the present application is introduced. Figure 7 As shown, the secure boot method may include:

[0084] S71. The loading module of the secure boot device loads the next-level software and the software signature of the next-level software.

[0085] In some embodiments, the secure boot apparatus may further include a loading module that can run in the second environment. During the device boot process, such as when the current level software is running, the loading module can obtain the next level software and its software signature, and store the next level software and its software signature in the target storage area to enable loading of the next level software.

[0086] For example, the loading module can obtain the code or data of the next level software from a memory, such as NVM, and load it into a storage area in DDR or SRAM, namely the target storage area. In this case, the attributes of the target storage area are readable and writable but not executable.

[0087] S72. The loading module of the secure boot device sends the address of the target storage area to the integrity check module.

[0088] In some embodiments, after the loading module completes storage of the next-level software and its signature, it may run a boot verification code to send the address of the target storage area to the integrity verification module. Alternatively, after completing loading, the loading module may send the address of the target storage area for storing the next-level software to the integrity verification module via the boot verification module of the secure boot device. The boot verification module runs in the second environment.

[0089] For example, after completing the loading, the loading module can send the loading result, such as the address of the target storage area, to the startup verification module. After that, the startup verification module can call the corresponding interface in the first environment, such as the integrity verification interface, to transmit the address of the target storage area to the integrity verification module. Specifically, this address can be the start address and the end address of the area storing the next-level software. That is, the startup verification module can call the integrity verification interface in the first environment and input the start address and the end address of the area storing the next-level software (such as [start, end] of the next-level software) as input parameters to the integrity verification module.

[0090] S73. The integrity verification module performs integrity verification on the next-level software based on the address of the target storage area to obtain an integrity verification result.

[0091] In the embodiment of the present application, the integrity verification module can perform integrity verification on the next-level software stored in the target storage area based on the address of the target storage area.

[0092] Exemplarily, the integrity verification module can calculate the hash of the next-level software in the storage area corresponding to the address, such as [start, end] of the next-level software, in the first environment based on the address of the target storage area, to obtain the hash value of the next-level software in the storage area corresponding to the address. The integrity verification module can also read the asymmetric public key on the device in the first environment. Then, the integrity verification module can use the calculated hash value of the next-level software, the stored software signature, and the obtained asymmetric public key as the input of the signature verification algorithm in the first environment, execute the signature verification algorithm, and obtain a verification result.

[0093] In addition, the integrity verification module can also configure the attribute of the target storage area from readable and writable but not executable to read-only.

[0094] After the integrity verification module completes the integrity verification of the next-level software in the first environment, it can also feedback the integrity verification result to the startup verification module running in the second environment. In the case where the integrity verification result indicates that the integrity verification of the next-level software stored in the target storage area fails, the startup can be stopped. In the case where the integrity verification result indicates that the integrity verification of the next-level software stored in the target storage area passes, the following S74 can be executed.

[0095] S74. The secure startup device runs other startup business logics.

[0096] In some embodiments, when the integrity verification result is used to indicate that the integrity verification of the next-level software stored in the target storage area has passed, the secure boot device may run other startup service logics of the software to be executed in the second environment. After the other startup service logics are run, the secure boot device may call the execution controller to trigger the trusted measurement module to perform a trusted measurement process, that is, execute S75 below.

[0097] S75: The secure boot device calls the execution controller to trigger the trusted measurement module to perform a trusted measurement process.

[0098] S76: The trusted measurement module performs a trusted measurement on the next-level software.

[0099] In some embodiments, after being called, the execution controller may send a request for indicating a trusted measurement of the software to be executed to the trusted measurement module to trigger the trusted measurement module to perform a trusted measurement on the software to be executed. Specifically, the trusted measurement module may perform a trusted measurement on the next-level software in the target storage area.

[0100] Among them, the address of the target storage area may be sent by the integrity verification module to the trusted measurement module. For example, when the integrity verification result is used to indicate that the integrity verification of the next-level software stored in the target storage area has passed, the integrity verification module may send the address of the target storage area to the execution controller. The execution controller may send the address of the target storage area to the trusted measurement module. For example, after receiving the address of the target storage area, the execution controller may forward the address to the trusted measurement module. Also, for example, after being called, the execution controller may forward the received address of the target storage area to the trusted measurement module, such as sending the address of the target storage area to the trusted measurement module in the way of setting input parameters. The input parameter is [start, end] of the next-level software. That is to say, after the integrity verification passes, the verification result and the verification range (i.e., the address of the target storage area) may be passed to the trusted measurement module through the secure first environment for trusted measurement.

[0101] The trusted measurement module may perform a trusted measurement on the next-level software stored in the target storage area based on the address of the target storage area.

[0102] Exemplarily, after obtaining the address of the area storing the next-level software, the trusted measurement module may, in the first environment, first calculate the hash of the next-level software in the storage area corresponding to the address, obtaining the hash value of the next-level software in the storage area corresponding to the address. Then, the trusted measurement module may measure the calculated hash value in the first environment. Finally, in the first environment, record the measurement result in a secure cryptographic manner. After obtaining the measurement result, the trusted measurement module may also send the trusted measurement result to the execution controller in the first environment. For example, in the case where the trusted measurement result is used to indicate that the next-level software stored in the target storage area is trusted, the trusted measurement module sends the trusted measurement result to the execution controller in the first environment.

[0103] S77. Based on the trusted measurement result, the execution controller sets the attribute of the target storage area to executable so as to run the next-level software.

[0104] In some embodiments, after receiving the trusted measurement result, as a response, the execution controller may, in the first environment, open the execution permission of the target storage area, that is, set the attribute of the target storage area to executable. After that, the secure boot device may run the next-level software according to the address of the target storage area.

[0105] Exemplarily, the execution controller may first change the attribute of the target storage area from read-only to executable only in the first environment. After that, the execution controller may execute a jump execution instruction in the first environment so that the secure boot device may run the code of the next-level software according to the starting address of the target storage area.

[0106] Based on the above, in combination with Figure 8, taking the non - secure environment, i.e., the second environment, as the EL0 level and the secure environment, i.e., the first environment, as the EL2 level as an example. In the embodiments of the present application, most of the startup logic runs at the EL0 level (e.g., the EL0 level of the ARM CPU). For example, the next - level software is loaded at this EL0 level, and other startup logic and the next - level software are run. For the three key security function points of integrity verification, trust measurement, and execution control (i.e., controlling the operation of the next - level software), they are placed in the secure environment during the startup process, i.e., run at the EL2 level. These three key security function points can be collectively referred to as the TCB function. Or rather, the security verification module, the trust measurement module, and the execution controller can all be called the TCB module. In the embodiments of the present application, these three TCB modules are moved down to the EL2 level with a higher security level, such as running in the CPU operation level. Of course, the secure environment can also be EL1 or the TEE execution environment. These three TCB modules can pass parameters and share content in this secure environment. The TCB modules running in the secure environment only provide specific interfaces for the modules in the non - secure environment to call, and all substantial security - related actions are implemented in the secure environment. For example, the startup code running at the EL0 level calls the TCB interface with a higher security level to complete the key security features, i.e., integrity verification, trust measurement, and execution control, in the secure environment.

[0107] The technical solution provided by the embodiments of the present application stores the software to be executed in the target storage area, and performs integrity verification and trust measurement on the software to be executed in the target storage area according to the address of the target storage area. Finally, when the integrity verification of the software to be executed stored in the target storage area passes and the trust measurement result indicates that the software to be executed stored in the target storage area is trustworthy, the software to be executed stored in the target storage area is executed. In this way, by placing the integrity verification, trust measurement, and execution control of the software to be executed in the same trusted environment, the consistency of the objects processed in the three execution processes is ensured, the TOC - TOU attack problem in secure startup and trusted startup is solved, and the secure startup of the device is guaranteed.

[0108] In addition, by modifying the attributes of the target storage area, segmented control over reading, writing, and execution of the operating memory is achieved. Further, by adding an execution permission control in the target storage area, the software to be executed will not be executed until the integrity check and trusted measurement are completed, which can, to a certain extent, ensure that only the code of the current stage can be run in the storage area where the system is operable before the software to be executed is run. By coupling the integrity check, trusted measurement, and the operation of the next-level software, an atomic implementation of verifying, jumping, and running the software to be executed is logically achieved, ensuring that malicious software cannot tamper with or insert unverified startup components. It can be understood that once the secure boot process starts, the secure boot device will complete all verification steps atomically as expected; otherwise, it will reject the boot, thereby achieving the purpose of preventing malicious attacks and ensuring the device can be securely booted.

[0109] The above mainly introduced the solution of the embodiment of the present application from the perspective of the method. It can be understood that in order to implement the above functions, the secure boot device includes the corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the way of hardware or computer software driving the hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of the present application.

[0110] The embodiments of the present application can divide the functional units of the secure boot device according to the above method examples. For example, each functional unit can be divided corresponding to each function, or two or more functions can be integrated into one processing unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit. It should be noted that the division of units in the embodiments of the present application is illustrative, only a logical functional division, and there can be other division methods in actual implementation.

[0111] An embodiment of the present application provides a secure boot device 90, which can be applied to an electronic device. The electronic device can be a mobile phone, a tablet computer, a handheld computer, a personal computer (PC), a cellular phone, a personal digital assistant (PDA), a wearable device (such as a smart watch), a smart home device (such as a television), a vehicle-mounted computer, a game console, and an augmented reality (AR) / virtual reality (VR) device, etc. The embodiment of the present application does not impose special restrictions on the specific form of the terminal. The main implementation entity can be a system-on-a-chip (SOC) in the electronic device. For example, if the electronic device refers to a mobile phone, the implementation entity is the core physical unit and computing platform in the mobile phone.

[0112] As Figure 9 shown, the secure boot device 90 may include: an acquisition unit 901, a processing unit 902, and a storage unit 903. Exemplarily, the secure boot device 90 may implement relevant units for the secure boot function in a Unified Extensible Firmware Interface (UEFI) system, such as the above-mentioned acquisition unit 901, processing unit 902, and storage unit 903. UEFI can read the first-stage boot loader (the first-level Bootloader) and other firmware to execute the above units. Specifically:

[0113] The acquisition unit 901 is configured to acquire the software to be executed and the software signature of the software to be executed.

[0114] The storage unit 903 is configured to store the software to be executed and the software signature in a target storage area.

[0115] The processing unit 902 is configured to perform an integrity check on the software to be executed stored in the target storage area based on the message digest of the software to be executed, the software signature, and the asymmetric public key, and obtain an integrity check result.

[0116] The processing unit 902 is further configured to perform a trusted measurement on the software to be executed stored in the target storage area based on the message digest of the software to be executed, and obtain a trusted measurement result.

[0117] The processing unit 902 is further configured to execute the software to be executed stored in the target storage area when the integrity check result is used to indicate that the integrity check of the software to be executed stored in the target storage area passes, and the trusted measurement result is used to indicate that the software to be executed stored in the target storage area is trusted.

[0118] In an implementable manner, the processing unit 902 is further configured to set the attribute of the target storage area to read-only after storing the software to be executed and the software signature in the target storage area.

[0119] In an implementable manner, the processing unit 902 is further configured to set the attribute of the target storage area to executable before executing the software to be executed stored in the target storage area.

[0120] In an implementable manner, the integrity verification process, the trusted measurement process, and the process of setting the attribute of the target storage area to executable are executed in a first environment; wherein, the security level of the first environment is higher than that of the second environment; the second environment is the environment for loading and executing the software to be executed. Exemplarily, the first environment may be the Trusted Execution Environment (TEE) or the secure firmware (such as, EL2) in the secure boot device 90. It can be understood that the processing unit 902 can perform integrity verification, trusted measurement, and jump to the next-level software in the TEE. The processing unit 902 can also perform integrity verification, trusted measurement, and jump to the next-level software in EL2.

[0121] In an implementable manner, before setting the attribute of the target storage area to read-only, the attribute of the target storage area is set to readable and writable and non-executable.

[0122] In addition, the first-stage Bootloader is an important link for loading the operating system under the guidance of UEFI. The secure boot device 90 can also perform advanced maintenance and debugging on the secure boot through the Fastboot mode, and Fastboot also follows the security principles of UEFI.

[0123] Figure 9 The units in can also be referred to as modules. For example, the acquisition unit can be referred to as the acquisition module, and the processing unit can be referred to as the processing module. In addition, in Figure 9 In the illustrated embodiment, the names of the respective units may not be the names shown in the figure. For example, the acquisition unit may also be referred to as the communication unit.

[0124] Figure 9When each unit in [the application] is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the methods described in the various embodiments of the present application. The storage media storing the computer software product include: various media such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs that can store program codes.

[0125] The embodiments of the present application also provide a schematic hardware structure diagram of a secure boot device. Refer to Figure 10 , this secure boot device includes a processor 1001 and a transceiver 1002. Optionally, it further includes a memory 1003 connected to the processor 1001.

[0126] The processor 1001 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the programs of the solutions of the present application. The processor 1001 can also include multiple CPUs, and the processor 1001 can be a single-CPU processor or a multi-CPU processor. Here, the processor can refer to one or more devices, circuits, or processing cores for processing data (such as computer program instructions).

[0127] The processor 1001, the memory 1003, and the transceiver 1002 are connected through a bus. The transceiver 1002 is used for parallel configuration devices with other operators. Optionally, the transceiver 1002 can include a transmitter and a receiver. The device in the transceiver 1002 for implementing the receiving function can be regarded as a receiver, and the receiver is used to execute the receiving steps in the embodiments of the present application. The device in the transceiver 1002 for implementing the sending function can be regarded as a transmitter, and the transmitter is used to execute the sending steps in the embodiments of the present application.

[0128] In the first possible implementation manner, refer to Figure 10, the secure startup device further includes a transceiver 1002. The memory 1003 can be a ROM or other type of static storage device that can store static information and instructions, a RAM, or other type of dynamic storage device that can store information and instructions. It can also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer. The embodiments of the present application do not impose any restrictions on this. The memory 1003 can exist independently or be integrated with the processor 1001. Among them, the memory 1003 may contain computer program code. The processor 1001 is used to execute the computer program code stored in the memory 1003, thereby implementing the method provided by the embodiments of the present application.

[0129] The embodiments of the present application also provide a computer-readable storage medium, including instructions, which when running on a computer, cause the computer to execute any of the above methods.

[0130] The embodiments of the present application also provide a computer program product containing instructions, which when running on a computer, cause the computer to execute any of the above methods.

[0131] The embodiments of the present application also provide a chip, including: a processor and an interface. The processor is coupled to the memory through the interface. When the processor executes the computer program or instructions in the memory, any of the methods provided by the above embodiments is executed.

[0132] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using a software program, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more integrated media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)).

[0133] Although the present application has been described in connection with various embodiments, however, in the process of implementing the claimed present application, those skilled in the art can understand and implement other variations of the disclosed embodiments by viewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "one" does not exclude a plurality. A single processor or other unit can implement several functions recited in the claims. Certain measures are recited in mutually different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0134] Although the present application has been described in connection with the features and their embodiments, it is obvious that various modifications and combinations can be made without departing from the spirit and scope of the present application. Accordingly, the present specification and the drawings are merely exemplary descriptions of the present application defined by the appended claims, and are considered to have covered any and all modifications, variations, combinations, or equivalents within the scope of the present application. Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these changes and modifications.

[0135] As described above, it is only the implementation mode of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the protection scope of this application. Therefore, the protection scope of this application shall be subject to the protection scope of the claims described above.

Claims

1. A secure boot method, characterized in that, Applied to a secure boot device, including: Obtain the software to be executed and the software signature of the software to be executed; Store the software to be executed and the software signature in a target storage area; Based on the message digest of the software to be executed, the software signature and the asymmetric public key, perform integrity verification on the software to be executed stored in the target storage area to obtain an integrity verification result; Based on the message digest of the software to be executed, perform a trusted measurement on the software to be executed stored in the target storage area to obtain a trusted measurement result; When the integrity verification result is used to indicate that the integrity verification of the software to be executed stored in the target storage area passes, and the trusted measurement result is used to indicate that the software to be executed stored in the target storage area is trusted, execute the software to be executed stored in the target storage area.

2. The method according to claim 1, wherein After storing the software to be executed and the software signature in the target storage area, the method further includes: Set the attribute of the target storage area to read-only.

3. The method according to claim 1 or 2, characterized in that, Before executing the software to be executed stored in the target storage area, the method further includes: Set the attribute of the target storage area to executable.

4. The method according to claim 3, wherein The integrity verification process, the trusted measurement process, and the process of setting the attribute of the target storage area to executable are executed in a first environment; The security level of the first environment is higher than the security level of the second environment; The second environment is the environment for loading and executing the software to be executed.

5. The method according to claim 4, characterized in that, The secure boot device includes an integrity verification module, a trusted measurement module, and an execution controller; Among them, the integrity verification module is used to implement the integrity verification process in the first environment; The trusted measurement module is used to implement the trusted measurement process in the first environment; The execution controller is used to execute the process of setting the attribute of the target storage area to executable in the first environment when the integrity verification result is used to indicate that the integrity verification of the software to be executed stored in the target storage area passes, and the trusted measurement result is used to indicate that the software to be executed stored in the target storage area is trusted.

6. The method according to claim 5, wherein The method further includes: When the integrity verification result is used to indicate that the integrity verification of the software to be executed stored in the target storage area passes, the integrity verification module sends the address of the target storage area to the execution controller; The execution controller sends the address of the target storage area to the trusted measurement module; The trusted measurement of the software to be executed stored in the target storage area includes: The trusted measurement module performs a trusted measurement on the software to be executed stored in the target storage area based on the address of the target storage area.

7. The method according to claim 6, wherein The method further includes: When the trusted measurement result is used to indicate that the software to be executed stored in the target storage area is trusted, the trusted measurement module sends the trusted measurement result to the execution controller; The setting the attribute of the target storage area to executable includes: In response to receiving the trusted measurement result, the execution controller sets the attribute of the target storage area to executable.

8. The method according to any one of claims 5-7, characterized in that, The secure boot device further includes: a loading module running in the second environment, where the loading module is used to implement the process of storing the software to be executed and the software signature in the target storage area; The method further includes: After completing the storage of the software to be executed and the software signature, the loading module sends the address of the target storage area to the integrity verification module; The integrity verification of the software to be executed stored in the target storage area includes: Based on the address of the target storage area, the integrity verification module performs integrity verification on the software to be executed stored in the target storage area.

9. The method according to any one of claims 1-8, characterized in that, Before setting the attribute of the target storage area to read-only, the attribute of the target storage area is readable and writable and non-executable.

10. An electronic device, characterized in that, Including: A processor; The processor is connected to a memory, where the memory is used to store computer execution instructions, and the processor executes the computer execution instructions stored in the memory, so that the electronic device implements the method according to any one of claims 1-9.

11. A computer-readable storage medium, characterized in that, Including instructions that, when run on a computer, cause the computer to execute the method according to any one of claims 1-9.

Images