Safe starting method, device and equipment and readable storage medium

Abstract

The invention provides a safety starting method, device and equipment and a readable storage medium, and the method comprises the steps: responding to a request for starting chip firmware, and building communication connection with a safety chip through inter-core communication; obtaining a trusted key root from the security component according to the security chip, and performing mutual challenge authentication with the security chip; according to a mutual challenge authentication with the security chip, a mutual legal authentication result is obtained, and the security chip is requested to start security signature verification; and starting the chip firmware according to a result fed back by the security chip that the signature verification is legal through security starting of the security component. Through the technical scheme of the specification, the isolation security component forms a hardware-level protection island, the risk of physical detection or bypass attack is eradicated, the security chip agents all operations to ensure that the root key cannot be directly accessed by the main MCU, the two-way challenge authentication is combined with the dynamic session key to realize tamper-proofing of inter-core communication, and on the premise of completely eradicating the tamper-proofing process from being hijacked, the security of the main MCU is improved. And the starting reliability and timeliness of the chip are ensured.

Description

Technical Field

[0001] This specification relates to the field of communication technology, and in particular to a secure boot method, apparatus, device, and readable storage medium. Background Technology

[0002] In the field of embedded systems and IoT devices, microcontroller units (MCUs) undertake core control functions, and their firmware security is directly related to the trust foundation of the entire system. Secure Boot, as a hardware-level security mechanism, establishes a chain of trust from hardware to software, ensuring that the device only loads and executes legitimate firmware verified by digital signatures, thereby defending against low-level attacks such as firmware tampering, bootkits, and rootkits. Current typical Secure Boot implementations rely on hardware security modules built into the chip: one-time programmable memory (OTP or eFuse) stores immutable root keys and encryption algorithm strategies (such as RSA2048 public keys, AES256, or SHA1 hash algorithms); the hardware encryption engine (HCE) performs high-strength encryption and decryption operations on behalf of software during resource-constrained boot phases (such as BootROM), completing the signature verification process for firmware such as the secondary program loader (SPL). Specifically, when the MCU starts up, the boot code embedded in the ROM first reads the verification policy and public key from the OTP, loads the firmware to be verified into the static random access memory (SRAM), and then calls the HCE through register instructions to perform decryption, hash calculation and other operations. Finally, it decides whether to continue the startup process based on the verification result.

[0003] While the above schemes form the basic framework for secure boot, serious security flaws still exist in practical applications. The most prominent problem lies in the exposure of the hardware access link: OTP / eFuse and HCE are typically directly mounted on the chip's common bus (such as the AXI bus), allowing the MCU to access them without isolation via the register interface. On the one hand, malicious actors can tamper with the register interaction process between the MCU and the security module through physical probing or software injection, such as forging the signature verification result return value of HCE, allowing unauthorized firmware to bypass verification. On the other hand, attackers can steal the root key stored in the OTP or tamper with the algorithm policy parameters, completely destroying the foundation of the trust chain. In addition, such open architectures are also vulnerable to denial-of-service (DoS) attacks. Attackers can block critical hardware access channels in the secure boot process by maliciously accessing OTP or HCE resources at high frequency, causing signature verification operations to time out or fail, thereby causing system boot delays or even paralysis. Summary of the Invention

[0004] In view of this, this specification provides a secure boot method, apparatus, device, and readable storage medium to improve the problem of the aforementioned secure boot being vulnerable to attack.

[0005] The specific technical solution is as follows:

[0006] This specification provides a secure boot method applied to an MCU chip. The MCU chip stores chip firmware and is included in a computing device. The computing device also includes a security chip and a security component. The security component interacts directly only with the security chip and stores a trusted key root. The method includes: in response to a request to boot the chip firmware, establishing a communication connection with the security chip via inter-core communication; performing mutual challenge authentication with the security chip based on the trusted key root obtained by the security chip from the security component; requesting secure boot signature verification from the security chip based on the mutually valid authentication result obtained from the mutual challenge authentication with the security chip; and booting the chip firmware based on the result of the secure boot signature verification by the security component returned by the security chip.

[0007] As a technical solution, the step of establishing a communication connection with the security chip through inter-core communication in response to the request to start the chip firmware further includes: an inter-core communication channel between the encryption and security chips.

[0008] As a technical solution, the security component includes a hardware security module; the hardware security module is used to store encryption policies and / or keys, the keys include trusted key roots, and the encryption policies are used to indicate the challenge authentication and / or signature verification policies of the security chip.

[0009] As a technical solution, the security component includes a hardware encryption engine; the hardware encryption engine is used to return the signature verification result according to the signature verification task issued by the security chip.

[0010] This specification also provides a secure boot device applied to an MCU chip. The MCU chip stores chip firmware and is included in a computing device. The computing device also includes a security chip and a security component. The security component interacts directly only with the security chip and stores a trusted key root. The device includes: a first module for establishing a communication connection with the security chip via inter-core communication in response to a request to boot the chip firmware; a second module for performing mutual challenge authentication with the security chip based on the trusted key root obtained by the security chip from the security component; the second module is further used to request a secure boot signature verification from the security chip based on the mutually valid authentication result obtained from the mutual challenge authentication with the security chip; and a third module for booting the chip firmware based on the result of the secure boot signature verification by the security component returned by the security chip.

[0011] As a technical solution, the step of establishing a communication connection with the security chip through inter-core communication in response to the request to start the chip firmware further includes: an inter-core communication channel between the encryption and security chips.

[0012] As a technical solution, the security component includes a hardware security module; the hardware security module is used to store encryption policies and / or keys, the keys include trusted key roots, and the encryption policies are used to indicate the challenge authentication and / or signature verification policies of the security chip.

[0013] As a technical solution, the security component includes a hardware encryption engine; the hardware encryption engine is used to return the signature verification result according to the signature verification task issued by the security chip.

[0014] This specification also provides an electronic device including a processor and a readable storage medium storing machine-executable instructions that can be executed by the processor to implement the aforementioned secure boot method.

[0015] This specification also provides a readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the aforementioned secure boot method.

[0016] The technical solutions provided in this specification offer at least the following beneficial effects:

[0017] By isolating security components to form a hardware-level protection island, the risk of physical detection or side-channel attacks is eliminated. The security chip proxies all operations to ensure that the root key cannot be directly accessed by the main MCU. Two-way challenge authentication combined with dynamic session keys realizes tamper-proof inter-core communication. Under the premise of preventing the signature verification process from being hijacked, the reliability and timeliness of chip startup are guaranteed. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the drawings used in the description of the embodiments of this specification or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this specification.

[0019] Figure 1 This is a flowchart of a safe startup method according to one embodiment of this specification;

[0020] Figure 2 This is a structural diagram of a safety start device according to one embodiment of this specification;

[0021] Figure 3 This is a hardware structure diagram of one embodiment of this specification;

[0022] Figure 4This is a hardware structure diagram of an electronic device according to one embodiment of this specification.

[0023] Reference numerals: Module 1 21, Module 22, Module 3 23. Detailed Implementation

[0024] The terminology used in the embodiments described herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this specification. The singular forms “a,” “described,” and “the” as used in this specification and claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.

[0025] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" may also be interpreted as "when," "when," or "in response to a determination."

[0026] This specification provides a secure boot method, apparatus, device, and readable storage medium to at least improve one of the aforementioned technical problems.

[0027] The specific technical solution is described below.

[0028] In one embodiment, this specification provides a secure boot method applied to an MCU chip. The MCU chip stores chip firmware and is included in a computing device. The computing device further includes a security chip and a security component. The security component interacts directly only with the security chip and stores a trusted key root. The method includes: in response to a request to boot the chip firmware, establishing a communication connection with the security chip via inter-core communication; performing mutual challenge authentication with the security chip based on the trusted key root obtained by the security chip from the security component; requesting a secure boot signature verification from the security chip based on the mutually valid authentication result obtained from the mutual challenge authentication with the security chip; and booting the chip firmware based on the result of the secure boot signature verification by the security component returned by the security chip.

[0029] Specifically, such as Figure 1 This includes the following steps, the order of which can be changed depending on the needs of the actual application scenario:

[0030] In the hardware computing devices where this secure boot method is applied, the MCU chip stores the chip firmware and coexists with a specially designed security chip. This security chip handles all interactions related to the security components. Security components, such as one-time programmable memory (OTP) and eFuses, are strictly restricted to interacting only directly with the security chip, forming a security island. This architecture ensures that access to security components is limited to the security chip, significantly reducing security risks caused by direct external access. For example, in a smart device system, if a traditional approach is used, an attacker could tamper with the contents of the OTP through physical contact or software means, causing the security mechanism to fail. However, in the new scheme, since the OTP can only be accessed by the security chip, any attempt to bypass this mechanism will fail.

[0031] Step S11: In response to the request to start the chip firmware, a communication connection is established with the security chip through inter-core communication.

[0032] When a request to boot the chip firmware is received, the MCU establishes a communication connection with the security chip via inter-core communication. This inter-core communication is a highly efficient communication mechanism used to transfer data and commands between the MCU and the security chip. Specifically, this communication is implemented based on a mailbox interface, allowing information exchange between the two processors. For example, in the smart device example above, when the user attempts to unlock the door, the MCU receives the instruction and sends a message to the security chip via the mailbox interface, requesting security verification. This message contains the firmware information to be verified and the necessary authentication parameters.

[0033] Step S12: Based on the trusted key root obtained from the security component by the security chip, perform mutual challenge authentication with the security chip.

[0034] After establishing a communication connection, the MCU will perform a mutual challenge authentication with the security chip based on the trusted key root obtained from the security chip. This step ensures the authenticity and legitimacy of both parties' identities. This process can utilize asymmetric encryption algorithms or symmetric keys to complete the authentication. For example, RSA public / private key pairs can be used for authentication, or the AES algorithm can be used to generate a shared key. In the case of smart devices, this means that the security chip not only verifies the legitimacy of the message from the MCU but also confirms that the sender is indeed an MCU authorized to request firmware startup. Conversely, the MCU will also verify the authenticity of the security chip to prevent man-in-the-middle attacks.

[0035] Step S13: Based on the mutual challenge authentication result obtained with the security chip, request the security chip to perform secure start verification.

[0036] After completing mutual challenge authentication and obtaining mutually valid authentication results, the MCU will request a secure boot signature verification from the security chip. This step involves using the hardware encryption engine within the security component to verify the integrity and authenticity of the firmware. Specifically, the hardware encryption engine hashes the firmware and decrypts the signature using a public key pre-stored in the OTP to verify that the firmware has not been tampered with. Continuing with the smart device example, this is equivalent to the security chip, after confirming the MCU's legitimacy, further checking whether the firmware version to be run meets expectations and whether it contains unauthorized modifications. Only when the firmware passes these rigorous checks is it considered legitimate and valid.

[0037] Step S14: Based on the result of the security chip indicating that the security component has successfully verified the signature, start the chip firmware.

[0038] Based on the successful verification of the secure boot signature by the secure component, as indicated by the security chip, the MCU will officially start the chip firmware. The firmware can now be loaded into the static random access memory (SRAM) and begin executing its corresponding functions. Throughout this process, by introducing the concept of a security island—isolating the secure component from direct interaction with the outside world—combined with a rigorous authentication process between the security chip and the MCU, system security is greatly enhanced. This ensures that even if an attacker gains physical access, they cannot easily tamper with or replace the firmware, effectively protecting the user's property and personal privacy.

[0039] This secure boot method not only enhances the security of MCU chips but also provides a viable security solution for a wider range of embedded systems. By combining hardware isolation and software protection, it effectively prevents the loading of unauthorized firmware and potential security threats, achieving highly secure chip firmware boot and improving the overall security of computing devices.

[0040] In one implementation, the step of establishing a communication connection with the security chip via inter-core communication in response to a request to start the chip firmware further includes: encrypting the inter-core communication channel between the security chip and the security chip.

[0041] In one embodiment, the security component includes a hardware security module; the hardware security module is used to store encryption policies and / or keys, the keys including trusted key roots, and the encryption policies used to indicate the challenge authentication and / or signature verification policies of the security chip.

[0042] In one embodiment, the security component includes a hardware encryption engine; the hardware encryption engine is used to return a signature verification result based on the signature verification task issued by the security chip.

[0043] In one implementation, after the power-on reset signal is released, the BootROM of the MCU chip begins execution. Its first instruction does not directly read the OTP connected to the common bus, but instead packages the boot request into a "SECURE_BOOT_REQUEST" message, which is written to the security chip SEC-MCU within the security island via the on-chip Mailbox. This message contains only the minimum necessary information: the chip's unique serial number, the current boot counter, a randomly generated 256-bit nonce, and a CRC32 encrypted with the default session key. Upon receiving the message, the SEC-MCU first performs an integrity check on the message using its dedicated AES-256 hardware engine to confirm that it has not been tampered with. Then, it retrieves the 2048-bit RSA public key and the 256-bit device root key written during programming from the OTP. At this point, the OTP is completely within the security island, and no external AXI host can access it through address mapping; therefore, the root key is physically visible only to the SEC-MCU. To establish mutual trust, the SEC-MCU immediately generates a new 256-bit random challenge value "Challenge_S", calculates the MAC using HMAC-SHA256 derived from the root key, and then sends "Challenge_S||MAC" back to the main MCU via Mailbox. Upon receiving this, the main MCU's BootROM verifies the MAC using a pre-programmed 256-bit key image (also derived from the root key, but only used in the BootROM stage). After confirming the SEC-MCU's legitimacy, it performs a verifiable operation on "Challenge_S" using this key image (e.g., AES-ECB encryption) and sends back the result "Response_M". The SEC-MCU performs the inverse operation on "Response_M" for comparison; if they match, mutual authentication is successful, and both parties enter an encrypted session. The session key is negotiated on the P-256 curve using the ECDH protocol. The main MCU and the SEC-MCU each retain a 256-bit shared key. All subsequent Mailbox data frames are encrypted with AES-GCM and appended with a 96-bit IV and a 128-bit Tag to ensure confidentiality and integrity.

[0044] After two-way authentication is complete, the main MCU sends a "VERIFY_SPL" request via an encrypted channel, along with the SHA-256 digest of the SPL firmware image, the version number, and the signature. The SEC-MCU first checks if the version number is in the OTP's allowed list. Then, it reads the RSA-2048 public key bound to the version number from the OTP, performs RSA decryption with PKCS#1v1.5 padding on the firmware signature, obtains the 256-bit expected digest contained in the signature, and compares it with the digest provided by the main MCU. To prevent replay attacks, the SEC-MCU updates the monotonic counter in the OTP after a successful comparison and returns the counter value and the SPL digest via HMAC again to the main MCU. The main MCU only allows the SPL jump after verifying the return value is correct. Throughout the entire process, the main MCU never directly touches the RSA public key, counter, or signature result. All sensitive operations are completed within a secure silo. Even if an attacker eavesdrops on the bus, they can only see the AES-GCM encrypted ciphertext and cannot obtain any plaintext key or digest information.

[0045] In a hypothetical extreme attack scenario, an attacker attempts to inject a forged signature into the AXI bus via a micro-probe, before the BootROM initiates a "VERIFY_SPL" request. Since the Mailbox channel is protected by AES-GCM, the attacker cannot forge a legitimate tag. The SEC-MCU immediately detects the GCM verification failure and returns a "VERIFY_FAIL" state. The main MCU then enters a secure lockout mode, shutting down all debug ports and retaining only the JTAG read-only status register for auditing. As another example, an attacker might attempt to inject laser voltage faults into the OTP, trying to flip a bit of the RSA public key to allow an illegitimate SPL to pass verification. Because the OTP is located within a security island, its power supply is monitored by an independent LDO and voltage sensor. Any voltage fluctuation exceeding a threshold, such as ±3%, will trigger a sensor interrupt. The SEC-MCU immediately clears its internal cached copy of the public key and rereads data from the OTP for ECC verification. If a single-bit error is found, it is automatically corrected using the OTP's built-in ECC mechanism; if multiple-bit errors are found, all subsequent verification requests are rejected. In this way, even if a physical attack successfully causes a transient failure, it will not put the system into an untrusted state.

[0046] In extreme cases, if the main MCU's BootROM is physically replaced with a malicious version, the malicious BootROM might attempt to bypass the Mailbox channel and directly access the security island via an illegal address. Since all interfaces of the security island reside in independent clock and power domains, and its AXISLAVE port only accepts address decoding results from the SEC-MCU in hardware, any illegal address access will trigger a bus error exception, and the exception count will be recorded by the security state machine within the security island. After three consecutive exceptions, the security state machine automatically fuses the "LIFETIME_LOCK" bit in the OTP, permanently preventing any firmware from booting, rendering the chip bricked, and requiring factory repair using manufacturer-specific recovery tools. Thus, even if the main MCU is completely replaced, the security island's protection mechanism cannot be bypassed.

[0047] In one implementation, such as Figure 2 This specification also provides a secure boot device applied to an MCU chip. The MCU chip stores chip firmware and is included in a computing device. The computing device also includes a security chip and a security component. The security component interacts directly only with the security chip and stores a trusted key root. The device includes: a first module for establishing a communication connection with the security chip via inter-core communication in response to a request to boot the chip firmware; a second module for performing mutual challenge authentication with the security chip based on the trusted key root obtained by the security chip from the security component; the second module is also used to request a secure boot signature verification from the security chip based on the mutually valid authentication result obtained from the mutual challenge authentication with the security chip; and a third module for booting the chip firmware based on the result of the secure boot signature verification by the security component returned by the security chip.

[0048] In one implementation, the step of establishing a communication connection with the security chip via inter-core communication in response to a request to start the chip firmware further includes: encrypting the inter-core communication channel between the security chip and the security chip.

[0049] In one embodiment, the security component includes a hardware security module; the hardware security module is used to store encryption policies and / or keys, the keys including trusted key roots, and the encryption policies used to indicate the challenge authentication and / or signature verification policies of the security chip.

[0050] In one embodiment, the security component includes a hardware encryption engine; the hardware encryption engine is used to return a signature verification result based on the signature verification task issued by the security chip.

[0051] In one implementation, such as Figure 3The internal hardware of the chip is modified so that OTP / eFuse is no longer placed on the common AXI bus, but instead isolated to form an isolated island. A new dedicated microprocessor, SEC-MCU, is introduced to handle security tasks. All security operations are only authorized by the SEC-MCU; that is, only the SEC-MCU can access OTP / eFuse and the hardware encryption engine. External security access is handled by the SEC-MCU through the inter-core communication mailbox. Through this island isolation, access to OTP / eFuse and the hardware encryption engine is confined within the security island. The entire security island only provides the SEC-MCU with the inter-core communication mailbox interface to the outside world.

[0052] Because the SEC-MCU inherently possesses a trusted key root within the OTP / eFuse, it can perform mutual challenge authentication with the chip processor MCU to verify the other party's legitimacy. Note: Both asymmetric and symmetric encryption keys can be used here.

[0053] After verifying each other's legitimacy, a session key (similar to TLS) can be negotiated by adding a random salt value. Subsequent communication between the two parties will be encrypted using the session key, which will ensure the security of data transmission and guarantee that the data cannot be imitated or tampered with.

[0054] By authenticating and encrypting the inter-core communication mailbox interaction channel in the above manner, the secureboot signature verification process initiated by the BootROM of the chip processor MCU is secured.

[0055] In one embodiment, this specification provides an electronic device including a processor and a readable storage medium storing machine-executable instructions executable by the processor. The processor executes the machine-executable instructions to implement the aforementioned secure boot method. From a hardware perspective, a hardware architecture diagram can be found... Figure 4 As shown.

[0056] In one embodiment, this specification provides a readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the aforementioned secure boot method.

[0057] Here, a readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, a readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0058] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0059] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0060] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware implementation, a completely software implementation, or an implementation combining software and hardware aspects. Furthermore, embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0061] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments thereof. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0062] Furthermore, these computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0063] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0064] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification can take the form of a completely hardware implementation, a completely software implementation, or an implementation combining software and hardware aspects. Furthermore, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0065] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A secure boot method, characterized in that, The method is applied to an MCU chip, wherein the MCU chip stores chip firmware, the MCU chip is included in a computing device, the computing device further includes a security chip and a security component, the security component interacts only directly with the security chip, and the security component stores a trusted key root; the method includes: In response to the request to start the chip firmware, a communication connection is established with the security chip via inter-core communication; Based on the trusted key root obtained from the security component by the security chip, mutual challenge authentication is performed with the security chip; Based on the mutually valid authentication results obtained through mutual challenge authentication with the security chip, a secure boot signature verification request is sent to the security chip. Based on the result of the security chip indicating that the security component has successfully verified the signature, the chip firmware is started.

2. The method according to claim 1, characterized in that, The step of establishing a communication connection with the security chip via inter-core communication in response to a request to start the chip firmware also includes: Inter-core communication channel between encryption and security chips.

3. The method according to claim 1, characterized in that, The security component includes a hardware security module; The hardware security module is used to store encryption policies and / or keys, the keys including trusted key roots, and the encryption policies used to indicate the challenge authentication and / or signature verification policies of the security chip.

4. The method according to claim 1, characterized in that, The security component includes a hardware encryption engine; The hardware encryption engine is used to return the signature verification result based on the signature verification task issued by the security chip.

5. A safety start device, characterized in that, An apparatus for use with an MCU chip, wherein the MCU chip stores chip firmware, the MCU chip is included in a computing device, the computing device further includes a security chip and a security component, the security component interacts only directly with the security chip, and the security component stores a trusted key root, the apparatus comprising: The first module is used to establish a communication connection with the security chip through inter-core communication in response to the request to start the chip firmware. The second module is used to perform mutual challenge authentication with the security chip based on the trusted key root obtained from the security component by the security chip; The second module is also used to request a secure start signature verification from the security chip based on the mutually valid authentication results obtained through mutual challenge authentication with the security chip. The third module is used to start the chip firmware based on the result of the security chip's feedback that the security component has successfully verified the signature.

6. The apparatus according to claim 5, characterized in that, The step of establishing a communication connection with the security chip via inter-core communication in response to a request to start the chip firmware also includes: Inter-core communication channel between encryption and security chips.

7. The apparatus according to claim 5, characterized in that, The security component includes a hardware security module; The hardware security module is used to store encryption policies and / or keys, the keys including trusted key roots, and the encryption policies used to indicate the challenge authentication and / or signature verification policies of the security chip.

8. The apparatus according to claim 5, characterized in that, The security component includes a hardware encryption engine; The hardware encryption engine is used to return the signature verification result based on the signature verification task issued by the security chip.

9. An electronic device, characterized in that, include: A processor and a readable storage medium storing machine-executable instructions that can be executed by the processor to implement the method of any one of claims 1-4.

10. A readable storage medium, characterized in that, The readable storage medium stores machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the method described in any one of claims 1-4.

Images