Equipment trusted startup verification system, method, device and chip

Abstract

The invention discloses an equipment trusted boot verification system, method and device and a chip, and belongs to the technical field of information security. The system comprises a main control chip used for reading firmware in a memory, calculating a target metric value of the firmware and sending the target metric value to a security chip; and the security chip is used for verifying the target metric value according to the reference metric value of the firmware. According to the method and the device, the firmware in the memory is read through the main control chip, the firmware does not need to be read by a security chip, various different external memories can be adapted, and the verification efficiency is improved; the main control chip calculates the target metric value of the firmware, the calculation speed is higher than that of a security chip, and the verification efficiency is further improved; besides, according to the cooperative mode of the main control chip and the security chip, the security chip does not need to read firmware from the memory in the verification process, so that a switch selection circuit between the security chip and the memory is reduced, and the overall cost is saved.

Description

Technical Field

[0001] The present application belongs to the field of information security technology, and in particular, relates to a device trusted startup verification system, method, device and chip. Background Art

[0002] In personal computers and terminal devices, the running operating systems and applications (hereinafter collectively referred to as firmware) are usually stored in the external storage area of ​​the device. Common external storage includes Flash, eMMC (Embedded Multi Media Card), SD card (Secure Digital Card), etc.

[0003] As an important component of device operation, the integrity of firmware is of vital importance. If the content of the firmware is maliciously tampered with or destroyed, the device may not run according to the original logic. Among the existing solutions for firmware integrity protection, the more common one is TPCM (Trusted Platform Control Module) technology.

[0004] However, in the existing technical solutions, since the security chip selected by the TPCM chip only has an SPI (Serial Peripheral Interface) interface that can be connected to Flash, it cannot be connected to other storage media such as eMMC, SD card, etc., and therefore it is impossible to measure the firmware therein. Summary of the invention

[0005] The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes a device trusted boot verification system, method, device and chip to adapt to the trusted boot metrics of multiple external memories and improve the verification efficiency.

[0006] In a first aspect, the present application provides a device trusted startup verification system, comprising:

[0007] The main control chip is used to read the firmware in the memory, calculate the target metric value of the firmware, and send the target metric value to the security chip;

[0008] A security chip is used to verify the target measurement value according to the baseline measurement value of the firmware.

[0009] According to the device trusted boot verification system of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0010] According to an embodiment of the present application, the calculating the target metric value of the firmware includes:

[0011] Performing a hash operation on the firmware to obtain a target hash value;

[0012] The target hash value is determined as a target metric value of the firmware.

[0013] In this embodiment, a target hash value is generated by performing a hash operation on the firmware content. The target hash value is a digital representation of the integrity of the firmware. Due to the characteristics of the hash operation, even the slightest change in the firmware will result in a completely different hash value. This makes the target hash value the key basis for verifying that the firmware has not been tampered with, thereby improving the accuracy of the verification.

[0014] According to an embodiment of the present application, performing a hash operation on the firmware to obtain a target hash value includes:

[0015] Obtaining a random number generated by the security chip;

[0016] A hash operation is performed on the firmware based on the random number to obtain a target hash value.

[0017] In this embodiment, the security of the firmware hash operation is enhanced by introducing a random number generated by a security chip. This is because the introduction of this random number increases the uncertainty of the hash operation, making the firmware measurement value different each time. Even if an attacker manages to tamper with the firmware content and tries to imitate the previous hash value, the tampered measurement value will not match the original measurement value due to the difference in random numbers. This challenge benchmark effectively improves the anti-tampering ability of the measurement value and improves the security of device startup.

[0018] According to an embodiment of the present application, the verifying the target metric value according to the benchmark metric value of the firmware includes:

[0019] Performing a hash operation on the reference metric value based on the random number to obtain a reference hash value;

[0020] The target hash value is verified according to the reference hash value.

[0021] In this embodiment, a reference hash value is generated by performing a hash operation on a pre-stored reference measurement value using the same random number obtained previously, so that the calculation of the reference hash value and the calculation of the target hash value use the same random number. The security chip then compares and verifies the calculated reference hash value with the target hash value sent by the main control chip, thereby effectively verifying whether the firmware has been tampered with, reducing potential replay attacks and prediction attacks, and providing a more secure startup environment for the device.

[0022] According to an embodiment of the present application, the benchmark measurement value is obtained by the security chip performing a hash operation on the downloaded firmware after the firmware is downloaded.

[0023] In this embodiment, a benchmark measurement value is obtained by performing a hash operation on the downloaded firmware immediately after the firmware download is completed, so that the benchmark measurement value can accurately reflect the actual status of the firmware, avoiding the risk of tampering or damage that may occur during the use of the firmware. By storing the benchmark measurement value in a security chip, a reliable reference point can be provided in the subsequent startup verification process, thereby enhancing the security of the firmware.

[0024] According to one embodiment of the present application, the security chip is further used for:

[0025] When the target metric value is verified to be successful, the reset signal is maintained at a high level to facilitate device startup.

[0026] According to one embodiment of the present application, the security chip is further used for:

[0027] In the case that the target metric value is not verified, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0028] In this embodiment, the level state of the reset signal is controlled by the verification result of the target measurement value by the security chip, so as to achieve precise control of the device startup process. When the security chip verifies and passes the target measurement value of the firmware, the high level state of the reset signal will be maintained, which is equivalent to sending a clear startup signal to the main control chip, allowing the device to start normally. On the contrary, if the target measurement value verification fails, indicating that the firmware may have been tampered with or damaged, the security chip will adjust the level state of the reset signal to a low level. This action effectively prevents the startup of the device, thereby reducing the risks that may be caused by unsafe or unstable system startup. In this way, the security chip not only provides the function of firmware integrity verification, but also participates in the startup control of the device, providing double protection for the security of the device.

[0029] According to one embodiment of the present application, the security chip is also used to adjust the level state of the reset signal to a low level to prevent the device from starting up if the target metric value sent by the main control chip is not received within a preset time period after the device is powered on.

[0030] In this embodiment, an additional safety mechanism is added by monitoring the target measurement value sent by the main control chip within a preset time after the device is powered on, which effectively responds to communication failures, delays, failure to call the security chip or other abnormal situations that may occur during the device startup process, and bypasses the startup measurement of the device, so that the device will not start if the integrity verification is not performed as expected, reducing potential unknown risks and further improving the security of device startup.

[0031] According to an embodiment of the present application, when the target metric value sent by the main control chip is not received within a preset time length after the device is powered on, the level state of the reset signal is adjusted to a low level to prevent the device from starting, including:

[0032] Set a timer for a preset duration;

[0033] Start the timer when the device is powered on;

[0034] When the timer expires, if the target metric value sent by the main control chip is not received, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0035] In this embodiment, by introducing a timer with a preset duration, a clear safety time limit is added to the device startup process. When the device is powered on, the security chip will start this timer and set a time boundary for waiting for the main control chip to send the target measurement value. If the security chip does not receive the target measurement value before the timer expires, the security chip will automatically adjust the level state of the reset signal to a low level, preventing the device from starting, thereby improving the device's anti-attack capability.

[0036] In a second aspect, the present application provides a device trusted startup verification method, comprising:

[0037] Read the firmware in the memory;

[0038] calculating a target metric value of the firmware;

[0039] The target metric value is sent to a security chip so that the security chip verifies the target metric value according to the benchmark metric value of the firmware.

[0040] According to the device trusted boot verification method of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0041] According to an embodiment of the present application, the calculating the target metric value of the firmware includes:

[0042] Performing a hash operation on the firmware to obtain a target hash value;

[0043] The target hash value is determined as a target metric value of the firmware.

[0044] According to an embodiment of the present application, performing a hash operation on the firmware to obtain a target hash value includes:

[0045] Obtaining a random number generated by the security chip;

[0046] A hash operation is performed on the firmware based on the random number to obtain a target hash value.

[0047] In a third aspect, the present application provides a device trusted startup verification method, including:

[0048] The target measurement value is verified according to the benchmark measurement value of the firmware; wherein the firmware is read from the memory by the main control chip, and the target measurement value is calculated by the main control chip based on the firmware.

[0049] According to the device trusted boot verification method of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0050] According to an embodiment of the present application, the verifying the target metric value according to the benchmark metric value of the firmware includes:

[0051] Performing a hash operation on the reference metric value based on a random number to obtain a reference hash value; wherein the random number is a random number obtained by the main control chip from the security chip;

[0052] The target hash value is verified according to the reference hash value; wherein the target hash value is obtained by the main control chip performing a hash operation on the firmware based on the random number.

[0053] According to one embodiment of the present application, the method further includes:

[0054] When the target metric value is verified to be passed, maintaining a high level state of a reset signal to facilitate device startup;

[0055] In the case that the target metric value is not verified, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0056] According to one embodiment of the present application, the method further includes:

[0057] Set a timer for a preset duration;

[0058] Start the timer when the device is powered on;

[0059] When the timer expires, if the target metric value sent by the main control chip is not received, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0060] In a fourth aspect, the present application provides a device trusted startup verification apparatus, comprising:

[0061] A reading module, used for reading the firmware in the memory;

[0062] A calculation module, used for calculating a target metric value of the firmware;

[0063] The sending module is used to send the target measurement value to the security chip, so that the security chip can verify the target measurement value according to the benchmark measurement value of the firmware.

[0064] According to the device trusted boot verification device of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0065] In a fifth aspect, the present application provides a device trusted startup verification apparatus, comprising:

[0066] A verification module is used to verify the target measurement value according to the benchmark measurement value of the firmware; wherein the firmware is read from the memory by the main control chip, and the target measurement value is calculated by the main control chip.

[0067] According to the device trusted boot verification device of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since there is no need for the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0068] In a sixth aspect, the present application provides an electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the computer program, the device trusted startup verification method as described in the second aspect or the third aspect above is implemented.

[0069] In a seventh aspect, the present application provides a non-transitory computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the device trusted startup verification method as described in the second aspect or the third aspect above is implemented.

[0070] In an eighth aspect, the present application provides a chip, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the device trusted startup verification method as described in the second or third aspect above.

[0071] In a ninth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the device trusted startup verification method as described in the second or third aspect above.

[0072] The above one or more technical solutions in the embodiments of the present application have at least one of the following technical effects:

[0073] According to the device trusted boot verification system of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0074] Furthermore, in some embodiments, a target hash value is generated by performing a hash operation on the firmware content. The target hash value is a digital representation of the integrity of the firmware. Due to the characteristics of the hash operation, even the slightest change in the firmware will result in a completely different hash value. This makes the target hash value the key basis for verifying that the firmware has not been tampered with, thereby improving the accuracy of the verification.

[0075] Furthermore, in some embodiments, the security of the firmware hash operation is enhanced by introducing a random number generated by a security chip. This is because the introduction of this random number increases the uncertainty of the hash operation, making the firmware measurement value different each time. Even if an attacker manages to tamper with the firmware content and tries to imitate the previous hash value, the tampered measurement value will not match the original measurement value due to the difference in random numbers. This challenge benchmark effectively improves the anti-tampering ability of the measurement value and improves the security of device startup.

[0076] Furthermore, in some embodiments, a benchmark hash value is generated by performing a hash operation on a pre-stored benchmark measurement value using the same random number previously obtained, so that the calculation of the benchmark hash value and the calculation of the target hash value use the same random number. The security chip then compares and verifies the calculated benchmark hash value with the target hash value sent by the main control chip, thereby effectively verifying whether the firmware has been tampered with, reducing potential replay attacks and prediction attacks, and providing a more secure startup environment for the device.

[0077] Furthermore, in some embodiments, a baseline measurement value is obtained by performing a hash operation on the downloaded firmware immediately after the firmware download is completed, so that the baseline measurement value can accurately reflect the true state of the firmware, avoiding the risk of tampering or damage that may occur during the use of the firmware. By storing the baseline measurement value in a security chip, a reliable reference point can be provided in the subsequent startup verification process, thereby enhancing the security of the firmware.

[0078] Furthermore, in some embodiments, the level state of the reset signal is controlled by the verification result of the target measurement value by the security chip, so as to achieve precise control of the device startup process. When the security chip verifies and passes the target measurement value of the firmware, the high level state of the reset signal will be maintained, which is equivalent to sending a clear startup signal to the main control chip, allowing the device to start normally. On the contrary, if the target measurement value verification fails, indicating that the firmware may have been tampered with or damaged, the security chip will adjust the level state of the reset signal to a low level. This action effectively prevents the device from starting, thereby reducing the risks that may be caused by unsafe or unstable system startup. In this way, the security chip not only provides the function of firmware integrity verification, but also participates in the startup control of the device, providing double protection for the security of the device.

[0079] Furthermore, in some embodiments, an additional safety mechanism is added by monitoring the target measurement value sent by the main control chip within a preset time after the device is powered on, which effectively responds to communication failures, delays, failure to call the security chip or other abnormal situations that may occur during the device startup process, and bypasses the startup measurement of the device, so that the device will not start if the integrity verification is not performed as expected, reducing potential unknown risks and further improving the security of device startup.

[0080] Furthermore, in some embodiments, by introducing a timer with a preset duration, a clear safety time limit is added to the device startup process. When the device is powered on, the security chip will start this timer to set a time boundary for waiting for the main control chip to send the target measurement value. If the security chip does not receive the target measurement value before the timer expires, the security chip will automatically adjust the level state of the reset signal to a low level, preventing the device from starting, thereby improving the device's anti-attack capability.

[0081] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0082] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0083] Figure 1 It is a structural schematic diagram of the TPCM technology provided in the embodiment of the present application;

[0084] Figure 2 It is a schematic diagram of the metric value calculation process during firmware downloading provided by an embodiment of the present application;

[0085] Figure 3 It is a schematic diagram of the process of trusted startup verification of a device provided in an embodiment of the present application;

[0086] Figure 4 It is a schematic diagram of the architecture of the device trusted startup verification system provided by the embodiment of the present application;

[0087] Figure 5 is a schematic diagram of a scenario example provided in an embodiment of the present application;

[0088] Figure 6 This is one of the flow charts of the device trusted startup verification method provided in the embodiment of the present application;

[0089] Figure 7 This is the second flow chart of the device trusted startup verification method provided in the embodiment of the present application;

[0090] Figure 8 This is one of the structural diagrams of the device trusted startup verification device provided in the embodiment of the present application;

[0091] Fig. 9 This is the second structural diagram of the device trusted startup verification device provided in the embodiment of the present application;

[0092] Fig.10 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0093] The following will be combined with the drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of this application.

[0094] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0095] TPCM technology is a technology that enhances the security of computer systems. It integrates a security chip in the hardware. The security chip usually contains encryption and storage functions. It can be used to store keys, certificates, configuration information, etc., and can measure the firmware and software of the computer system to verify their integrity and credibility.

[0096] The simple structure of TPCM technology is as follows Figure 1 As shown in FIG. 1 , the first-level boot code of the device, such as the BIOS (Basic Input Output System) in a PC (personal computer) and the Boot Loader (boot loader) in a terminal, is usually stored in Flash. The main control chip is connected to the Flash chip via SPI. When starting up, the boot code is loaded and run from Flash, and the boot code completes the loading and running of other parts of the firmware. The TPCM chip controls the main control chip and switch selection through GPIO (General-Purpose Input / Output), where "n" and "m" are used to represent specific GPIO pin numbers. The RESET signal is a control signal for the device status. The reset signal can be high-level effective or low-level effective. For example, when the RESET signal is low, the device status will be set to the initial state, that is, the power-off state. The TPCM chip plays a key role in the device startup process and can actively verify the firmware. After verification, the TPCM controls the normal startup of the device through the GPIO pin and adjusts the RESET signal, thereby ensuring the safe startup of the system.

[0097] In related technologies, such as Figure 2 and Figure 3As shown in the figure, when the device downloads the firmware through a legal channel, the TPCM chip will save the firmware measurement value H_B in the secure storage area of ​​the TPCM chip. When the device starts, the TPCM chip is powered on first, and the TPCM chip reads the firmware content in the Flash chip through SPI, and calculates the measurement value H of the read firmware. The TPCM chip compares H with H_B. If they are consistent, it is considered that the firmware integrity is not damaged and it starts normally; if they are inconsistent, it is considered that the firmware is damaged, and the TPCM chip prevents the device from starting.

[0098] However, since the security chip used by the TPCM chip only has an SPI interface that can be connected to Flash, it cannot connect to other storage media such as eMMC, SD card, etc., and therefore cannot measure the firmware therein.

[0099] In order to solve at least one of the above technical problems, the present application proposes a device trusted boot verification system, method, device and chip. The following is a detailed description of the device trusted boot verification system, method, device and chip provided by the present application embodiment through specific embodiments and their application scenarios in conjunction with the accompanying drawings.

[0100] like Figure 4 As shown, the device trusted startup verification system provided in the embodiment of the present application includes a main control chip and a security chip. The main control chip is connected to the memory, and the security chip is not connected to the memory. The security chip is connected to the main control chip, and the security chip retains a communication interface with the main control chip. The RESET signal can be adjusted through the GPIO pin to control the power off of the main control chip, thereby controlling the normal startup of the device or interrupting the startup of the device.

[0101] In the embodiments of the present application, the device may be a computer, such as a personal computer, a server, an industrial control computer, etc., or other terminal devices, such as a mobile phone, an in-vehicle electronic device, a tablet computer, a smart TV, a smart home device, a medical device, a robot, a wearable device, a teller machine or a self-service machine, etc. The device may also be any other electronic device, and the embodiments of the present application do not limit the device.

[0102] In the embodiment of the present application, the main control chip is a chip responsible for executing program instructions, processing data and controlling other hardware components. For example, the main control chip can be a central processing unit (CPU) of the device, or a microcontroller (MCU) or a system on chip (SoC).

[0103] A security chip is a chip designed to improve security. The security chip may include security-related hardware and software such as an encryption engine, key storage, and a random number generator. For example, the security chip may be a TPCM chip or other types of chips.

[0104] In an embodiment of the present application, the main control chip is used to read the firmware in the memory, calculate the target measurement value of the firmware, and send the target measurement value to the security chip; the security chip is used to verify the target measurement value according to the benchmark measurement value of the firmware.

[0105] In the embodiments of the present application, firmware can be software that implements device functions, and can control basic operations of the device and provide basic functions. For example, firmware can include a boot program, an operating system, a driver, a system service, an application, etc., or other software, which is not limited in the embodiments of the present application.

[0106] In the field of computer security, a metric is defined as a quantitative representation of a system, data, or software, which is used to verify its integrity and authenticity. The metric can be calculated in any way. For example, a digital signature can be used to digitally sign the firmware using asymmetric encryption technology to obtain the metric of the firmware. The firmware can also be converted into a series of bytes using serialization, and the serialization result can be used as the metric of the firmware. A hash function can also be used to hash the firmware to obtain a hash value, and the hash value can be used as the metric of the firmware. This application does not limit the calculation method of the firmware's metric.

[0107] The target metric value is calculated by the main control chip on the firmware read from the memory after the device is powered on. For example, after reading the firmware in the memory, the main control chip can use a hash algorithm, such as SHA-256, SM3, etc., to perform a hash operation on the firmware to obtain a hash value of a fixed length. Any slight firmware change will cause a significant change in the hash value, which is used as the target metric value.

[0108] The benchmark metric value is the metric value calculated by the security chip on the firmware. For example, when the device downloads new firmware, the security chip can calculate the newly downloaded firmware to obtain the benchmark metric value of the firmware, and store the benchmark metric value in the protected storage area of ​​the security chip. The calculation method of the target metric value is the same as the calculation method of the benchmark metric value. For example, the calculation of the benchmark metric value adopts the SM3 algorithm, and the calculation of the target metric value also adopts the SM3 algorithm, which can facilitate the comparison of the benchmark metric value and the target metric value.

[0109] In some embodiments, the benchmark metric value is obtained by the security chip performing a hash operation on the downloaded firmware after the firmware is downloaded.

[0110] In this embodiment, a benchmark measurement value is obtained by performing a hash operation on the downloaded firmware immediately after the firmware download is completed, so that the benchmark measurement value can accurately reflect the actual status of the firmware, avoiding the risk of tampering or damage that may occur during the use of the firmware. By storing the benchmark measurement value in a security chip, a reliable reference point can be provided in the subsequent startup verification process, thereby enhancing the security of the firmware.

[0111] In an embodiment of the present application, after calculating the target measurement value of the firmware, the main control chip will send the target measurement value to the security chip. The security chip will verify the target measurement value according to the benchmark measurement value of the firmware. For example, if the benchmark measurement value is the same as the target measurement value, it can be considered that the firmware has not been tampered with, the integrity of the firmware has not been destroyed, and the verification has passed; if the benchmark measurement value is different from the target measurement value, it can be considered that the integrity of the firmware has been destroyed and the verification has failed.

[0112] According to the device trusted boot verification system of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0113] In some embodiments, calculating a target metric value of firmware includes:

[0114] Perform hash operation on the firmware to obtain the target hash value;

[0115] A target hash value is determined as a target metric value for the firmware.

[0116] In this embodiment, the main control chip can use the same hash algorithm as the reference measurement value to perform a hash operation on the firmware to obtain a target hash value, and use the target hash value as the target measurement value.

[0117] In this embodiment, a target hash value is generated by performing a hash operation on the firmware content. The target hash value is a digital representation of the integrity of the firmware. Due to the characteristics of the hash operation, even the slightest change in the firmware will result in a completely different hash value. This makes the target hash value the key basis for verifying that the firmware has not been tampered with, thereby improving the accuracy of the verification.

[0118] In some embodiments, performing a hash operation on the firmware to obtain a target hash value includes:

[0119] Get the random number generated by the security chip;

[0120] Perform hash operation on the firmware based on the random number to obtain the target hash value.

[0121] In this embodiment, the main control chip sends a random number acquisition request to the security chip before performing a hash operation on the firmware. After receiving the request from the main control chip, the security chip generates a random number, sends the random number to the main control chip, and stores the random number.

[0122] After receiving the random number sent by the main control chip, the main control chip will perform a hash operation on the firmware based on the random number to obtain a target hash value. For example, the target hash value H = Hash (Hash (firmware) + random number R), where Hash () indicates that a hash operation is performed on the content in the brackets.

[0123] In this embodiment, the random number can be a random number of any length, such as 16 bytes, 32 bytes, 64 bytes, etc. Of course, in order to provide a higher level of security and improve the strength and reliability of the encryption process and security protocol, a random number with a length greater than or equal to 32 bytes can be selected.

[0124] In this embodiment, the security of the firmware hash operation is enhanced by introducing a random number generated by a security chip. This is because the introduction of this random number increases the uncertainty of the hash operation, making the firmware measurement value different each time. Even if an attacker manages to tamper with the firmware content and tries to imitate the previous hash value, the tampered measurement value will not match the original measurement value due to the difference in random numbers. This challenge benchmark effectively improves the anti-tampering ability of the measurement value and improves the security of device startup.

[0125] In some embodiments, verifying the target metric value according to the baseline metric value of the firmware includes:

[0126] Performing a hash operation on the benchmark metric value based on the random number to obtain a benchmark hash value;

[0127] Verify the target hash value against the baseline hash value.

[0128] In this embodiment, since the target measurement value is obtained by hashing the firmware based on a random number, in order to verify the target measurement value, it is also necessary to hash the reference measurement value based on the same random number. In this way, when the firmware has not been tampered with, the reference hash value calculated by the security chip based on the firmware and the target hash calculated by the main control chip based on the firmware are the same.

[0129] Specifically, the reference hash value H'=Hash(Hash_B+random number R), where Hash_B represents the reference metric value.

[0130] In this embodiment, verifying the target hash value according to the reference hash value may include comparing the target hash value H with the reference hash value H'. If the two are the same, it can be considered that the firmware has not been tampered with, the integrity of the firmware has not been destroyed, and the verification has passed; if the two are different, it can be considered that the integrity of the firmware has been destroyed and the verification has failed.

[0131] In this embodiment, a reference hash value is generated by performing a hash operation on a pre-stored reference measurement value using the same random number obtained previously, so that the calculation of the reference hash value and the calculation of the target hash value use the same random number. The security chip then compares and verifies the calculated reference hash value with the target hash value sent by the main control chip, thereby effectively verifying whether the firmware has been tampered with, reducing potential replay attacks and prediction attacks, and providing a more secure startup environment for the device.

[0132] In some embodiments, the security chip is also used to:

[0133] When the target measurement value is verified to be passed, the reset signal is maintained at a high level to facilitate device startup.

[0134] In some embodiments, the security chip is also used to:

[0135] In the case where the target measurement value is not verified, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0136] In this embodiment, the reset signal is a control signal used to restore the device to an initial state or a known state. The reset signal can be a signal generated by a physical switch or a signal triggered by software. In a digital logic circuit, the reset signal has two states: high level and low level. These two states represent different logical values: high level (logic "1"): indicates that the device should start normally or continue to run. Low level (logic "0"): indicates that the device should stop starting or stop running.

[0137] In this embodiment, the security chip can control the level state of the reset signal through a GPIO pin or other dedicated control pins. For example, the security chip can maintain the high level of the reset signal by keeping the reset pin controlled by it in a logic high level state, and can adjust the reset signal to a low level by programming the reset pin controlled by it to a logic low level state.

[0138] In this embodiment, if the security chip finds that the verification fails during the verification process, the level state of the reset signal can be adjusted to a low level, thereby controlling the main control chip to power off and interrupt the startup of the device; if the verification passes, the high level state of the reset signal is maintained, and the startup of the device by the main control chip is not changed.

[0139] In this embodiment, the level state of the reset signal is controlled by the verification result of the target measurement value by the security chip, so as to achieve precise control of the device startup process. When the security chip verifies and passes the target measurement value of the firmware, the high level state of the reset signal will be maintained, which is equivalent to sending a clear startup signal to the main control chip, allowing the device to start normally. On the contrary, if the target measurement value verification fails, indicating that the firmware may have been tampered with or damaged, the security chip will adjust the level state of the reset signal to a low level. This action effectively prevents the startup of the device, thereby reducing the risks that may be caused by unsafe or unstable system startup. In this way, the security chip not only provides the function of firmware integrity verification, but also participates in the startup control of the device, providing double protection for the security of the device.

[0140] In some embodiments, the security chip is further used to adjust the level state of the reset signal to a low level to prevent the device from starting up when the target measurement value sent by the main control chip is not received within a preset time period after the device is powered on.

[0141] In this embodiment, if the security chip does not receive the target measurement value sent by the main control chip within a preset time, it may be due to a communication failure, delay, failure to call the security chip or other abnormal conditions that may occur during the device startup process. At this time, the level state of the reset signal can be adjusted to a low level, thereby controlling the main control chip to cut off power to interrupt the startup of the device.

[0142] Among them, the preset time length can be 30 seconds, 40 seconds, 1 minute, 1 minute and 10 seconds, etc., and the preset time length can also be other values, which can be determined based on the calculation time of the firmware by the main control chip and / or the security chip. The embodiment of the present application does not limit the preset time length.

[0143] In this embodiment, an additional safety mechanism is added by monitoring the target measurement value sent by the main control chip within a preset time after the device is powered on, which effectively responds to communication failures, delays, failure to call the security chip or other abnormal situations that may occur during the device startup process, and bypasses the startup measurement of the device, so that the device will not start if the integrity verification is not performed as expected, reducing potential unknown risks and further improving the security of device startup.

[0144] In some embodiments, when the target metric value sent by the main control chip is not received within a preset time after the device is powered on, the level state of the reset signal is adjusted to a low level to prevent the device from starting, including:

[0145] Set a timer for a preset duration;

[0146] Start the timer when the device is powered on;

[0147] When the timer expires, if the target measurement value sent by the main control chip is not received, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0148] In this embodiment, the security chip can set a timer with a preset duration. When the device is powered on, the main control chip and the security chip are also powered. Therefore, the timer can be started when the device is powered on. If the target measurement value sent by the main control chip is not received at the end of the timing, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0149] In this embodiment, by introducing a timer with a preset duration, a clear safety time limit is added to the device startup process. When the device is powered on, the security chip will start this timer and set a time boundary for waiting for the main control chip to send the target measurement value. If the security chip does not receive the target measurement value before the timer expires, the security chip will automatically adjust the level state of the reset signal to a low level, preventing the device from starting, thereby improving the device's anti-attack capability.

[0150] like Figure 5 As shown, the present application also provides a scenario example to illustrate the device trusted boot verification system. In this scenario example, the security chip is taken as a TPCM chip as an example.

[0151] In this scenario example, when the device is initialized, the TPCM chip calculates the benchmark measurement value Hash_B of the firmware through a hash algorithm and stores the benchmark measurement value Hash_B in its own storage area.

[0152] When the device is powered on, the TPCM chip and the main control chip are also powered on separately, and the TPCM chip and the main control chip execute their own logic respectively. The TPCM chip will start the timer, which is set for 1 minute. The main control chip requests a random number from the TPCM chip. After receiving the request, the TPCM chip generates a random number, sends the random number R to the main control chip, and stores the random number R in its own storage area. The length of the random number can be any random number.

[0153] The main control chip is connected to the external memory, reads the firmware content through the interface connected to the external memory, and calculates the target measurement value H=Hash(Hash(firmware)+random number R) of the firmware, and then transmits the target measurement value H to the TPCM chip.

[0154] The TPCM chip uses the internally stored reference measurement value Hash_B and random number R to calculate the reference hash value H'=Hash(Hash_B+random number R), and compares H' with H. If H' is consistent with H, it is considered that the firmware integrity is not damaged, the high level of RESET is maintained, and the startup of the main control chip is not changed; if they are inconsistent, it is considered that the firmware is damaged, and TPCM pulls down the RESET pin to a low level, interrupting the startup of the device.

[0155] Of course, if the TPCM chip has not received the target metric value H transmitted by the main control chip when the timer of the TPCM chip ends, it can also be considered that the external firmware has been damaged and the startup of the device also needs to be interrupted.

[0156] The following introduces a device trusted boot verification method provided in an embodiment of the present application, wherein the device trusted boot verification method can be applied to a terminal, and can be specifically executed by hardware or software in the terminal.

[0157] The terminal includes, but is not limited to, a portable communication device such as a mobile phone or tablet computer with a touch-sensitive surface (e.g., a touch screen display and / or a touch pad). It should also be understood that in some embodiments, the terminal may not be a portable communication device, but a desktop computer with a touch-sensitive surface (e.g., a touch screen display and / or a touch pad).

[0158] In the following various embodiments, a terminal including a display and a touch-sensitive surface is described. However, it should be understood that the terminal may include one or more other physical user interface devices such as a physical keyboard, a mouse and a joystick.

[0159] The device trusted boot verification method provided in the embodiment of the present application can be executed by a main control chip.

[0160] like Figure 6As shown, the device trusted startup verification method includes: step 610, step 620 and step 630.

[0161] Step 610: Read the firmware in the memory;

[0162] Step 620, calculating the target metric value of the firmware;

[0163] Step 630: Send the target measurement value to the security chip so that the security chip can verify the target measurement value according to the benchmark measurement value of the firmware.

[0164] According to the device trusted boot verification method of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0165] In some embodiments, calculating a target metric value of firmware includes:

[0166] Perform hash operation on the firmware to obtain the target hash value;

[0167] A target hash value is determined as a target metric value for the firmware.

[0168] In some embodiments, performing a hash operation on the firmware to obtain a target hash value includes:

[0169] Get the random number generated by the security chip;

[0170] Perform hash operation on the firmware based on the random number to obtain the target hash value.

[0171] The device trusted boot verification method provided in the embodiment of the present application can be executed by a security chip.

[0172] like Figure 7 As shown, the device trusted startup verification method includes: step 710.

[0173] Step 710: Verify the target measurement value according to the benchmark measurement value of the firmware; wherein the firmware is read from the memory by the main control chip, and the target measurement value is calculated by the main control chip based on the firmware.

[0174] According to the device trusted boot verification method of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0175] In some embodiments, verifying the target metric value according to the baseline metric value of the firmware includes:

[0176] Perform a hash operation on the reference measurement value based on a random number to obtain a reference hash value; wherein the random number is a random number obtained by the main control chip from the security chip;

[0177] The target hash value is verified according to the reference hash value; wherein the target hash value is obtained by the main control chip performing a hash operation on the firmware based on a random number.

[0178] In some embodiments, the method further comprises:

[0179] When the target measurement value is verified, the reset signal is maintained at a high level to facilitate device startup;

[0180] In the case where the target measurement value is not verified, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0181] In some embodiments, the method further comprises:

[0182] Set a timer for a preset duration;

[0183] Start the timer when the device is powered on;

[0184] When the timer expires, if the target measurement value sent by the main control chip is not received, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0185] The device trusted boot verification method provided in the embodiment of the present application can be executed by a device trusted boot verification device. In the embodiment of the present application, the device trusted boot verification device executing the device trusted boot verification method is taken as an example to illustrate the device trusted boot verification device provided in the embodiment of the present application.

[0186] The embodiment of the present application also provides a device trusted startup verification apparatus.

[0187] like Figure 8 As shown, the device trusted startup verification device includes:

[0188] A reading module 810 is used to read the firmware in the memory;

[0189] A calculation module 820, configured to calculate a target metric value of the firmware;

[0190] The sending module 830 is used to send the target measurement value to the security chip so that the security chip can verify the target measurement value according to the benchmark measurement value of the firmware.

[0191] According to the device trusted boot verification device of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0192] In some embodiments, the calculation module 820 is further configured to:

[0193] Perform hash operation on the firmware to obtain the target hash value;

[0194] A target hash value is determined as a target metric value for the firmware.

[0195] In some embodiments, the calculation module 820 is further configured to:

[0196] Get the random number generated by the security chip;

[0197] Perform hash operation on the firmware based on the random number to obtain the target hash value.

[0198] The embodiment of the present application also provides a device trusted startup verification apparatus.

[0199] like Fig. 9 As shown, the device trusted startup verification device includes:

[0200] The verification module 910 is used to verify the target measurement value according to the benchmark measurement value of the firmware; wherein the firmware is read from the memory by the main control chip, and the target measurement value is calculated by the main control chip.

[0201] According to the device trusted boot verification device of the present application, through the collaborative work of the main control chip and the security chip, during the device startup process, the main control chip is responsible for reading the firmware from the memory and calculating the target measurement value of the firmware. The security chip uses the baseline measurement value of the firmware as a credential that the firmware has not been tampered with, and verifies the received target measurement value. The device trusted boot verification system of the present application reads the firmware in the memory through the main control chip, and there is no need for the security chip to read the firmware. It can adapt to a variety of different external memories, which improves the verification efficiency; and the target measurement value of the firmware is calculated by the main control chip, and the calculation speed is faster than that of the security chip, which further improves the verification efficiency; in addition, the collaborative mode of the main control chip and the security chip in the device trusted boot verification system of the present application, since the verification process does not require the security chip to read the firmware from the memory, the switch selection circuit between the security chip and the memory is reduced, saving overall costs.

[0202] In some embodiments, the verification module 910 is further configured to:

[0203] Perform a hash operation on the reference measurement value based on a random number to obtain a reference hash value; wherein the random number is a random number obtained by the main control chip from the security chip;

[0204] The target hash value is verified according to the reference hash value; wherein the target hash value is obtained by the main control chip performing a hash operation on the firmware based on a random number.

[0205] In some embodiments, the verification module 910 is further configured to:

[0206] When the target measurement value is verified, the reset signal is maintained at a high level to facilitate device startup;

[0207] In the case where the target measurement value is not verified, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0208] In some embodiments, the verification module 910 is further configured to:

[0209] Set a timer for a preset duration;

[0210] Start the timer when the device is powered on;

[0211] When the timer expires, if the target measurement value sent by the main control chip is not received, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

[0212] The device trusted startup verification device in the embodiment of the present application can be an electronic device, or a component in the electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal, or it can be other devices other than the terminal. Exemplarily, the electronic device can be a mobile phone, a tablet computer, a laptop computer, a palmtop computer, a vehicle-mounted electronic device, a mobile Internet device (Mobile Internet Device, MID), an augmented reality (augmented reality, AR) / virtual reality (virtual reality, VR) device, a robot, a wearable device, an ultra-mobile personal computer (ultra-mobilepersonal computer, UMPC), a netbook or a personal digital assistant (personal digital assistant, PDA), etc., and can also be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (personal computer, PC), a television (television, TV), a teller machine or a self-service machine, etc., and the embodiment of the present application is not specifically limited.

[0213] The device trusted boot verification device in the embodiment of the present application may be a device having an operating system. The operating system may be a Microsoft (Windows) operating system, an Android (Android) operating system, an IOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0214] In some embodiments, Fig.10 As shown, an embodiment of the present application also provides an electronic device 1000, including a processor 1001, a memory 1002, and a computer program stored in the memory 1002 and executable on the processor 1001. When the program is executed by the processor 1001, each process of the above-mentioned device trusted boot verification method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0215] It should be noted that the electronic devices in the embodiments of the present application include the above-mentioned mobile electronic devices and non-mobile electronic devices.

[0216] An embodiment of the present application also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the various processes of the above-mentioned device trusted boot verification method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0217] The processor is the processor in the electronic device in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0218] An embodiment of the present application also provides a computer program product, including a computer program, which implements the above-mentioned device trusted startup verification method when executed by a processor.

[0219] The processor is the processor in the electronic device in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0220] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned device trusted startup verification method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0221] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0222] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0223] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0224] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

[0225] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "illustrative embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0226] Although the embodiments of the present application have been shown and described, those skilled in the art will appreciate that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present application, and that the scope of the present application is defined by the claims and their equivalents.

Claims

1. A device trusted startup verification system, characterized in that: include: The main control chip is used to read the firmware in the memory, calculate the target metric value of the firmware, and send the target metric value to the security chip; A security chip is used to verify the target measurement value according to the baseline measurement value of the firmware.

2. The system according to claim 1, characterized in that The calculating the target metric value of the firmware includes: Performing a hash operation on the firmware to obtain a target hash value; The target hash value is determined as a target metric value of the firmware.

3. The system according to claim 2, characterized in that The performing hash operation on the firmware to obtain a target hash value includes: Obtaining a random number generated by the security chip; A hash operation is performed on the firmware based on the random number to obtain a target hash value.

4. The system according to claim 3, characterized in that The verifying the target metric value according to the benchmark metric value of the firmware includes: Performing a hash operation on the reference metric value based on the random number to obtain a reference hash value; The target hash value is verified according to the reference hash value.

5. The system according to claim 1, characterized in that The benchmark measurement value is obtained by the security chip performing a hash operation on the downloaded firmware after the firmware is downloaded.

6. The system according to claim 1, characterized in that The security chip is also used for: When the target metric value is verified to be successful, the reset signal is maintained at a high level to facilitate device startup.

7. The system according to claim 1, characterized in that The security chip is also used for: In the case that the target metric value is not verified, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

8. The system according to claim 1, characterized in that The security chip is also used to adjust the level state of the reset signal to a low level to prevent the device from starting up when the target metric value sent by the main control chip is not received within a preset time period after the device is powered on.

9. The system according to claim 8, characterized in that When the target metric value sent by the main control chip is not received within the preset time length of powering on the device, the level state of the reset signal is adjusted to a low level to prevent the device from starting, including: Set a timer for a preset duration; Start the timer when the device is powered on; When the timer expires, if the target metric value sent by the main control chip is not received, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

10. A device trusted startup verification method, characterized in that: include: Read the firmware in the memory; calculating a target metric value of the firmware; The target metric value is sent to a security chip so that the security chip verifies the target metric value according to the benchmark metric value of the firmware.

11. The method according to claim 10, characterized in that The calculating the target metric value of the firmware includes: Performing a hash operation on the firmware to obtain a target hash value; The target hash value is determined as a target metric value of the firmware.

12. The method according to claim 11, characterized in that The performing hash operation on the firmware to obtain a target hash value includes: Obtaining a random number generated by the security chip; A hash operation is performed on the firmware based on the random number to obtain a target hash value.

13. A device trusted startup verification method, characterized in that: include: The target measurement value is verified according to the benchmark measurement value of the firmware; wherein the firmware is read from the memory by the main control chip, and the target measurement value is calculated by the main control chip based on the firmware.

14. The method according to claim 13, characterized in that The verifying the target metric value according to the benchmark metric value of the firmware includes: Performing a hash operation on the reference metric value based on a random number to obtain a reference hash value; wherein the random number is a random number obtained by the main control chip from the security chip; The target hash value is verified according to the reference hash value; wherein the target hash value is obtained by the main control chip performing a hash operation on the firmware based on the random number.

15. The method according to claim 13, characterized in that The method further comprises: When the target metric value is verified to be passed, maintaining a high level state of a reset signal to facilitate device startup; In the case that the target metric value is not verified, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

16. The method according to claim 13, characterized in that The method further comprises: Set a timer for a preset duration; Start the timer when the device is powered on; When the timer expires, if the target metric value sent by the main control chip is not received, the level state of the reset signal is adjusted to a low level to prevent the device from starting.

17. A device trusted startup verification device, characterized in that: include: A reading module, used for reading the firmware in the memory; A calculation module, used for calculating a target metric value of the firmware; The sending module is used to send the target measurement value to the security chip, so that the security chip can verify the target measurement value according to the benchmark measurement value of the firmware.

18. A device trusted startup verification device, characterized in that: include: A verification module is used to verify the target measurement value according to the benchmark measurement value of the firmware; wherein the firmware is read from the memory by the main control chip, and the target measurement value is calculated by the main control chip.

19. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 10 to 16 is implemented.

20. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 10 to 16 is implemented.

21. A chip, characterized in that: The chip includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the method according to any one of claims 10-16.

Images