Trusted boot method based on security co-processor and related device

Abstract

The application discloses a trusted starting method based on a security coprocessor and related devices, and the method comprises the following steps: the security coprocessor is powered on preferentially to the main processor, the first-stage boot loader, the FPGA bit stream and the digital signature of the security firmware are loaded and verified to obtain a first verification result; when the first verification result comprises a verification success, a TPM soft core is initialized; an unlocking instruction is sent to the SED hard disk through the SATA controller to unlock the SED hard disk; after the SED hard disk is successfully unlocked, the security coprocessor is controlled to release the control right of the host bus, the main processor accesses the SED hard disk through the host bus, and the main processor starts an operating system based on the SED hard disk; after the operating system is started, the main processor is controlled to establish communication with the security coprocessor through the host bus, so that the security coprocessor provides a password service to the main processor. By adopting the application, the security of device starting is improved.

Description

Technical Field

[0001] This application relates to the field of trusted boot technology, and in particular to a trusted boot method and related apparatus based on a secure coprocessor. Background Technology

[0002] With devices becoming increasingly networked and intelligent, the security of the device startup process is directly related to the reliable operation of the entire system. As people's lives become more and more reliant on various devices, device network security issues are becoming increasingly important.

[0003] Currently, computer devices generally suffer from vulnerabilities in boot security: the LUKS encrypted boot scheme stores the key locally, making it easy to extract; the TPM plus BIOS boot scheme relies on motherboard support and cannot directly control the unlocking of self-encrypting hard drives; pure software encryption makes the key visible in memory, making it vulnerable to malicious software. None of these schemes can complete security verification before BIOS startup, and the lack of strong binding between the key and hardware results in low device boot security.

[0004] Therefore, improving the security of device startup has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a trusted boot method and related apparatus based on a secure coprocessor, which improves the security of device boot.

[0006] In a first aspect, embodiments of this application provide a trusted boot method based on a secure coprocessor, the method comprising: The security coprocessor is powered on before the main processor, and the digital signatures of the first-stage bootloader, FPGA bitstream, and security firmware are loaded and verified to obtain a first verification result; the first verification result includes any of the following: verification successful, verification failed; When the first verification result includes successful verification, the TPM soft core in the security coprocessor is initialized; The SATA controller in the security coprocessor sends an unlock command to the SED hard drive to unlock the SED hard drive; After the SED hard drive is successfully unlocked, the security coprocessor is controlled to release control of the host bus, allowing the main processor to access the SED hard drive through the host bus, and the main processor starts the operating system based on the SED hard drive. After the operating system starts, it controls the main processor to establish communication with the security coprocessor through the host bus, so that the security coprocessor can provide cryptographic services to the main processor.

[0007] Secondly, embodiments of this application provide a trusted boot device based on a secure coprocessor, the device comprising: a power-on module and a trusted boot module, wherein: The power-on module is used to power on the security coprocessor before the main processor, load and verify the digital signatures of the first-stage bootloader, FPGA bitstream and security firmware, and obtain a first verification result; the first verification result includes any of the following: verification successful, verification failed; The trusted boot module is configured to initialize the TPM soft core in the security coprocessor when the first verification result includes successful verification; send an unlock command to the SED hard drive through the SATA controller in the security coprocessor to unlock the SED hard drive; after the SED hard drive is successfully unlocked, control the security coprocessor to release control over the host bus, enabling the main processor to access the SED hard drive through the host bus, and the main processor to boot the operating system based on the SED hard drive; after the operating system boots, control the main processor to establish communication with the security coprocessor through the host bus, so that the security coprocessor can provide cryptographic services to the main processor.

[0008] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing the steps in the first aspect of embodiments of this application.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in the first aspect of embodiments of this application.

[0010] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in the first aspect of embodiments of this application. The computer program product may be a software installation package.

[0011] Implementing this application will have the following beneficial effects: As can be seen, the trusted boot method and related apparatus based on a security coprocessor described in this application ensure the integrity and trustworthiness of its boot chain by having the security coprocessor power on before the main processor and independently complete the first-stage bootloader, FPGA bitstream, and digital signature verification of the security firmware before BIOS startup. The security coprocessor's built-in SATA controller directly sends unlocking commands to the SED hard drive, preventing the unlocking key from passing through the main processor and its memory, effectively preventing the key from being extracted by malware or physical attacks. Only after the hard drive is successfully unlocked is the host bus control released, ensuring that the main processor can only access the unlocked hard drive. Simultaneously, the initialized TPM soft core provides a hardware trust foundation for subsequent cryptographic services, and after the main processor starts, it establishes communication with the security coprocessor via the host bus, with the security coprocessor providing independent cryptographic services. This eliminates the risks of firmware tampering, key leakage, and unauthorized data access throughout the boot process, significantly improving device boot security. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0013] Figure 1 This is an application scenario diagram of a trusted boot method based on a secure coprocessor provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a security coprocessor provided in an embodiment of this application; Figure 3 This is a flowchart of a trusted boot method based on a secure coprocessor provided in an embodiment of this application; Figure 4 This is a flowchart of a TPM soft core initialization method provided in an embodiment of this application; Figure 5 This is a flowchart of a remote authentication method provided in an embodiment of this application; Figure 6 This is a flowchart illustrating a trusted boot method based on a security coprocessor provided in an embodiment of this application. Figure 7 This is a schematic diagram of a trusted boot device based on a secure coprocessor provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0015] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0016] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0017] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0018] In this application embodiment, "connection" refers to various connection methods such as direct connection or indirect connection to realize communication between devices. This application embodiment does not limit this in any way.

[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] The electronic devices described in this application embodiment may include smartphones (such as Android phones, iOS phones, Windows Phones, etc.), tablet computers, PDAs, laptops, video matrices, monitoring platforms, mobile internet devices (MIDs), or wearable devices, etc. The above are merely examples and not exhaustive, and include but are not limited to the above devices.

[0021] Of course, the aforementioned electronic devices can also be security coprocessors.

[0022] The following describes the relevant content, concepts, meanings, technical issues, technical solutions, and beneficial effects involved in the embodiments of this application.

[0023] First, let me explain some of the technical terms or phrases used in this application: Security coprocessor: A dedicated auxiliary processor responsible for security-related tasks in the system. It works in conjunction with the main processor to completely separate the "secure area" and "normal area" of trusted computing at the physical level. It has independent computing and storage units and is used to handle sensitive operations such as encryption calculations, secure boot verification, and key management. It can effectively prevent malware or physical attacks from obtaining keys.

[0024] FPGA bitstream: This is a binary sequence file used for logic configuration of an FPGA (Field-Programmable Gate Array). It contains information on how each logic element in the FPGA's programmable logic resources should be connected and configured. The bitstream is equivalent to the FPGA's "configuration data," describing the connection state of the entire logic resource. After being loaded, it can be used to instantiate specific hardware circuit modules in the FPGA Fabric.

[0025] TPM soft core: refers to the Trusted Platform Module (TPM) hardware functional module implemented in FPGA programmable logic, conforming to the TPM2.0 specification defined by the Trusted Computing Group (TCG). A TPM is a dedicated cryptographic coprocessor that provides a hardware-based root of trust, possessing functions such as random number generation, secure generation and storage of encryption keys, Platform Configuration Register (PCR) measurement, remote authentication, and sealed storage. Its core capabilities are key management, authentication, and system integrity measurement.

[0026] SATA (Serial Advanced Technology Attached Interface) controller: A host controller chip or integrated circuit that implements the SATA standard protocol and is used to connect storage devices such as hard disk drives (HDDs) and solid-state drives (SSDs) to the motherboard or other host controllers.

[0027] SED (Self-Encrypting Hard Drive) is a hardware-based encrypted storage device compliant with the TCG standard. It integrates an AES encryption engine; all data is automatically encrypted using the AES algorithm by the controller when written to the drive and decrypted in real-time upon reading. The encryption and decryption process is completed internally, without consuming host CPU resources, and is transparent to the operating system and applications. SEDs are in an encrypted-locked state by default upon power-on and require specific commands to unlock before data can be read or written. Its encryption function is always enabled and cannot be disabled by the user.

[0028] BootROM (Boot Read-Only Memory) is a firmware embedded inside the chip, located in the read-only memory or write-protected flash memory of the processor chip. It contains the first code executed by the processor when it is powered on or reset, and is responsible for completing hardware initialization, boot mode selection and subsequent firmware loading.

[0029] eFuse (electronic fuse): A one-time programmable non-volatile memory that stores data by melting a metal fuse. Once the data is written, it cannot be modified or erased.

[0030] FPGA Fabric (FPGA Programmable Logic Array): This is the core component of an FPGA, which is an array of programmable logic blocks. These logic blocks are immersed in programmable interconnect resources, forming a reconfigurable hardware logic resource pool.

[0031] OPAL Protocol: A set of self-encrypting drive (SED) security subsystem specifications developed by TCG, designed to provide a unified hardware encryption standard for storage devices.

[0032] LUKS Encrypted Boot Scheme: This is a widely used disk encryption standard under the Linux operating system, which performs encryption management at the block device level through the cryptsetup tool.

[0033] TPM plus BIOS boot solution: refers to a technical solution that uses the BIOS (Basic Input / Output System) firmware in conjunction with the TPM security chip to measure and verify the integrity of the boot chain during the computer boot process.

[0034] Please see Figure 1 , Figure 1 This is an application scenario diagram of a trusted boot method based on a secure coprocessor provided in an embodiment of this application; it can be seen that... Figure 1 It includes a security coprocessor, a main processor, and a remote authentication platform. When the main processor needs to be started, the security coprocessor is powered on first before the main processor is powered on. After the security coprocessor completes the trusted verification and unlocks the SED hard drive, it transfers control to the main processor. The main processor can interact bidirectionally with the security coprocessor and communicate with the remote authentication platform to achieve remote authentication and auditing of the device's startup integrity.

[0035] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of a security coprocessor provided in an embodiment of this application; it can be seen that the security coprocessor includes: a SATA controller, a TPM soft core, a BootROM, an eFuse, on-chip memory, an FPGA Fabric, an ARM processor core, etc., which are not limited here; wherein: SATA controller: Used to implement the Serial Advanced Technology Attached Interface (SATI) protocol, enabling the security coprocessor to directly connect to and control self-encrypting hard drives and send unlock commands without the intervention of the main processor.

[0036] TPM soft core: Used for operations such as storage platform configuration register (PCR), generating storage root key, performing PCR extension operations and remote authentication signature.

[0037] BootROM: Read-only memory code embedded inside the security coprocessor chip. It is the first program to execute after power-on and is responsible for loading the first-stage bootloader (FSBL) from the SPI Flash and verifying its signature, thus forming the starting point of the trust chain. SPI Flash refers to a flash memory chip that communicates via the SPI (Serial Peripheral Interface) bus.

[0038] eFuse: Used to store immutable sensitive data such as the root public key and PCR initial values, serving as a hardware trust anchor.

[0039] On-chip memory: Used to load FSBL, bitstream and security firmware at the initial startup stage to avoid transmitting sensitive data through external bus.

[0040] FPGA Fabric: By loading bitstreams, hardware modules such as TPM soft cores and SATA controllers can be dynamically configured, enabling flexible customization of hardware functions.

[0041] ARM processor core: The central processing unit of the security coprocessor, used to execute security firmware, manage TPM soft core, SATA controller and PCIe (serial communication bus) communication, and coordinate the entire trusted boot process.

[0042] Please see Figure 3 , Figure 3 This is a flowchart of a trusted boot method based on a secure coprocessor provided in an embodiment of this application; the method includes, but is not limited to, the following steps: S301. Power on the security coprocessor before the main processor, load and verify the digital signature of the first-stage bootloader, FPGA bitstream and security firmware, and obtain the first verification result; the first verification result includes any of the following: verification successful or verification failed.

[0043] In this embodiment, the security coprocessor can be implemented using an FPGA SoC chip.

[0044] In a specific embodiment, a power management unit can supply power to the security coprocessor and the main processor. This power management unit provides a first power rail and a second power rail, both under control. The first power rail is connected to the security coprocessor, and the second power rail is connected to the main processor. When the main processor needs to start, the power management unit first turns on the first power rail, allowing the security coprocessor to power on and enter the working state before the main processor. During this period, the main processor remains powered off or reset and cannot access any system bus or peripherals. After the security coprocessor powers on, it begins its own boot verification process: loading and verifying the first-stage bootloader, the FPGA bitstream, and the digital signature of the security firmware to obtain a first verification result. The digital signature is pre-generated and burned by the device manufacturer using the root private key corresponding to the root public key inside the security coprocessor.

[0045] If the first verification result includes verification failure, a second prompt message is generated and the startup process is terminated. The second prompt message is used to indicate that the signature verification of the security coprocessor has failed; for example, the second prompt message can be "xx signature verification failed".

[0046] In some embodiments, the security coprocessor further includes: BootROM, eFuse, on-chip memory, FPGA Fabric, and ARM processor core; the loading and verification of the digital signatures of the first-stage bootloader, FPGA bitstream, and security firmware to obtain a first verification result includes: S11. Execute the BootROM to read the first-stage bootloader program from the preset memory; S12. Verify the digital signature of the first-stage bootloader based on the root public key in the eFuse to obtain a second verification result; S13. When the second verification result includes verification success, the first-stage bootloader is loaded into the on-chip memory and executed; the first-stage bootloader is used to read the FPGA bitstream from the preset memory; S14. Verify the digital signature of the FPGA bitstream based on the root public key to obtain a third verification result; S15. When the third verification result includes successful verification, the FPGA bit stream is loaded into the FPGA Fabric to configure the hardware functions of the security coprocessor. S16. Read the security firmware from the preset memory, verify the digital signature of the security firmware based on the root public key, and obtain a fourth verification result; S17. When the fourth verification result includes successful verification, the security firmware is loaded and executed through the ARM processor core. S18. Determine the first verification result based on the second verification result, the third verification result, and the fourth verification result.

[0047] In this embodiment, the preset memory can be preset in advance or defaulted.

[0048] In some embodiments, the preset memory may be SPI Flash.

[0049] In some embodiments, the security coprocessor may include a PCIe Endpoint interface that can be used to connect to the host processor's PCIe Root Complex, enabling the security coprocessor to be mounted as a PCIe endpoint device on the host processor's PCIe bus.

[0050] In a specific embodiment, a BootROM can be executed. After the BootROM starts running, it first completes the most basic hardware initialization, such as setting the stack pointer, initializing the chip's internal clock, configuring the SPI controller and the basic on-chip memory (OCM) controller to ensure the ability to access external memory and temporarily store data. Then, the BootROM can access and connect to a preset memory through the SPI bus (or a dedicated interface configured inside the chip) and read the first-stage bootloader from the preset memory. Then, the digital signature of the first-stage bootloader can be verified based on the root public key in the eFuse to obtain a second verification result. Specifically, the preset root public key can be read from the eFuse first, and the digital signature attached to the FSBL can be decrypted using the root public key to obtain a first hash value. At the same time, a preset hash algorithm (e.g., SHA-256) is used to calculate a second hash value on the FSBL itself. The first hash value and the second hash value are compared. If they match, the second verification result is determined to be successful; if they do not match, the second verification result is determined to be unsuccessful.

[0051] When the second verification result includes successful verification, it indicates that the digital signature of the FSBL is genuine and valid, and its code has not been tampered with. At this time, the first-stage bootloader can be loaded into the on-chip memory and executed. Specifically, the FSBL image that has been read into the on-chip memory can be kept in memory through the BootROM (or its position in memory can be reconfirmed). Then, the program counter of the ARM processor core is pointed to the entry address of the FSBL through a jump instruction, and the execution of the FSBL begins.

[0052] Then, the digital signature of the FPGA bitstream can be verified based on the root public key to obtain a third verification result. Specifically, the method for obtaining the third verification result can be the same as the method for obtaining the second verification result, which will not be repeated here. When the third verification result includes successful verification, it indicates that the digital signature of the FPGA bitstream is genuine and valid, and its code has not been tampered with. At this time, the FPGA bitstream can be loaded into the FPGA Fabric to configure the hardware functions of the security coprocessor. After the configuration is completed, the pre-designed hardware function modules, including the TPM soft core, SATA controller, etc., are instantiated in the FPGA Fabric, thereby providing the necessary hardware support for subsequent trusted boot.

[0053] Furthermore, the security firmware can be read from the preset memory, and the digital signature of the security firmware can be verified based on the root public key to obtain a fourth verification result. Specifically, the method for obtaining the fourth verification result can be the same as the method for obtaining the second verification result, and will not be described again here. When the fourth verification result includes successful verification, the security firmware is loaded and executed through the ARM processor core. Specifically, the security firmware can be read into the running memory of the security coprocessor (which can be on-chip memory or external DDR) and executed through the ARM processor core.

[0054] Finally, the first verification result can be determined based on the second, third, and fourth verification results. Specifically, if the second, third, and fourth verification results are all successful, the first verification result is determined to be successful; if any one of the second, third, and fourth verification results is a failure, the first verification result is determined to be a failure.

[0055] In this way, by using a three-level chain of digital signature verification based on the root public key, layered and progressive integrity verification is implemented on the FSBL, FPGA bitstream, and security firmware. This constructs a complete trust chain from the immutable BootROM to the security firmware, effectively preventing firmware tampering, malicious implantation, and illegal replacement attacks. It ensures the trustworthiness of the security coprocessor's own operating environment and provides a solid security foundation for subsequent hard drive unlocking and host boot processes, avoiding the risk of attackers bypassing the overall security mechanism by damaging the security coprocessor firmware.

[0056] S302. When the first verification result includes successful verification, initialize the TPM soft core in the security coprocessor.

[0057] In this embodiment of the application, when the first verification result includes successful verification, the TPM soft core in the security coprocessor can be initialized.

[0058] In some embodiments, please refer to Figure 4 , Figure 4 This is a flowchart illustrating a method for initializing a TPM soft core according to an embodiment of this application. Initializing the TPM soft core in the security coprocessor includes, for example: Figure 4 The steps shown are as follows: S21. Instantiate the TPM soft core in the FPGA Fabric to obtain the instantiated TPM soft core; S22. The preset PCR initial value is read from the eFuse through the instantiated TPM soft core, and the PCR extension command is called to extend the PCR initial value to the preset PCR register; S23. Generate a storage root key using the instantiated TPM soft core.

[0059] In this embodiment of the application, the preset PCR initial value and the preset PCR register can both be preset in advance or defaulted.

[0060] In a specific embodiment, the TPM soft core can be instantiated in the FPGA Fabric to obtain an instantiated TPM soft core. Specifically, the FPGA bitstream contains a pre-designed hardware description of the TPM soft core. After loading, a TPM soft core conforming to the TCG TPM 2.0 specification is instantiated in the FPGA Fabric. This TPM soft core is implemented in hardware logic and includes functional modules such as a platform configuration register set (i.e., the preset PCR register), a hash engine, an asymmetric encryption engine, and a random number generator, as well as a non-volatile memory area. After instantiation, the TPM soft core starts running as an independent hardware module inside the security coprocessor, interconnected with the ARM processor core through the chip's internal bus, and is called by the security firmware.

[0061] Then, the instantiated TPM soft core can read the preset PCR initial value from the eFuse and call the PCR extension command to extend the PCR initial value to the preset PCR register. Specifically, the security firmware sends a command to the instantiated TPM soft core via the internal bus. The TPM soft core reads the PCR initial value from the eFuse. The PCR initial value is the hash value of the security coprocessor firmware (including BootROM, FSBL, security firmware, etc.), which is burned into the eFuse during the device manufacturing stage and serves as the starting metric value of the trust chain. The calculation formula for the PCR extension command can be: PCR_new=Hash(PCR_old || Digest); Here, PCR_old is the current PCR value, Digest is the hash value to be expanded, and Hash() is the preset hash algorithm. The TPM soft core calls this command, uses the initial PCR value as Digest, concatenates it with the current value of the PCR0 register (initially zero or a reset value), calculates the hash, and writes the result to the PCR0 register. After this operation, PCR0 stores the hash value of the trusted metric root, and subsequent metric values ​​for each startup chain component are expanded sequentially based on this. The PCR expansion operation can only expand (i.e., perform hash accumulation on the new value) and cannot write directly, ensuring that the PCR value cannot be maliciously tampered with or rolled back.

[0062] It should be explained that the preset PCR register can include multiple PCR registers, which are numbered by index, such as PCR0, PCR1, PCR2, etc., and each register has an independent storage location in the TPM soft core.

[0063] In some embodiments, the preset PCR register may include 24 PCR registers.

[0064] Finally, a storage root key can be generated through the instantiated TPM soft core. Specifically, the asymmetric encryption engine inside the TPM soft core generates an asymmetric key pair (RSA key pair or ECC key pair) as the storage root key SRK. That is, SRK includes a public key and a private key. The private key, after generation, is stored in the non-volatile storage area inside the TPM soft core and is never exported externally; the public key can be exported for external use as needed. Furthermore, the TPM soft core can set this storage root key as a persistent object, allowing it to be accessed by secure firmware even after a system reset or power failure. Once generated, the storage root key serves as the root node of the TPM key tree, used to encapsulate (encrypt) and protect other keys created subsequently, such as the authentication key (AIK) and session keys used for data encryption. At this point, the TPM soft core initialization is complete, enabling it to record boot chain integrity metrics and protection keys.

[0065] In some embodiments, the instantiated TPM soft core may not generate a storage root key, but instead read a preset storage root key from eFuse.

[0066] In this way, by instantiating the TPM soft core in the FPGA Fabric and reading the PCR initial value from eFuse, the TPM soft core generates the storage root key on its own, realizing a trusted measurement and key hardware binding based on the hardware trust root without external TPM dependence. This not only gets rid of motherboard compatibility limitations, but also ensures the uniqueness and immutability of the PCR initial value and the storage root key, providing a hardware trust foundation independent of the main processor for subsequent trusted boot.

[0067] In some embodiments, after generating the storage root key through the instantiated TPM soft core, the method further includes: The PCR extension operation is performed sequentially on each startup chain component to be started in the security coprocessor, and the hash value of each startup chain component is recorded in the preset PCR register to obtain the integrity measurement record corresponding to each startup chain component.

[0068] Specifically, the secure firmware can sequentially obtain the hash value of each boot chain component (including the FSBL, FPGA bitstream, and the secure firmware itself). For each boot chain component, the secure firmware calls the PCR extension command of the TPM soft core to extend the component's hash value into a preset PCR register (e.g., the hash value of the FSBL is extended to PCR1, the hash value of the FPGA bitstream is extended to PCR2, the hash value of the secure firmware is extended to PCR3, and so on). After each extension, the old value in the PCR register is overwritten by the new value, and this operation is irreversible and immutable. After all components are measured, the preset PCR register stores the cumulative hash value of the corresponding component, forming a boot chain integrity measurement record. This record can be used for subsequent local verification or remote authentication to prove that the boot process of the secure coprocessor has not been tampered with.

[0069] S303. Send an unlock command to the SED hard drive through the SATA controller in the security coprocessor to unlock the SED hard drive.

[0070] In this embodiment, the SATA controller can send an unlock command to the SED hard drive to unlock it.

[0071] In some embodiments, sending an unlock command to the SED hard drive via the SATA controller in the security coprocessor to unlock the SED hard drive includes: S31. Send a discovery data command to the SED hard drive through the SATA controller to obtain a first discovery result; the first discovery result includes the current locking status; the current locking status includes any one of the following: unlocked, locked; S32. When the current locked state includes locked, read the unlock key from the eFuse; send the unlock command to the SED hard drive through the SATA controller to unlock the SED hard drive; the unlock command includes the unlock key; S33. Read the status of the status register in the SED hard disk through the SATA controller to obtain the first read / write status; the first read / write status includes any one of the following: readable / write status, unreadable / write status; S34. When the first read / write state includes a read / write state, it is determined that the SED hard drive has been successfully unlocked.

[0072] In this embodiment, a discovery data command (OPAL Raw0 command) is sent to the SED hard drive via the SATA controller. This command is used to query the current lock status of the SED hard drive. The SATA controller receives the response data from the SED hard drive in response to this command, parses the lock function descriptor from the response data, extracts the current lock status, and uses this status as the first discovery result. If the current lock status includes "locked," it indicates that the SED hard drive is in an encrypted lock state and valid data cannot be read from it. At this time, the unlock key can be read from eFuse, and then a corresponding unlock command is generated based on the unlock key. The unlock command is sent to the SED hard drive via the SATA controller to unlock the SED hard drive. Specifically, after receiving the unlock command, the SED hard drive parses the unlock key and compares it with the authentication credentials stored internally. If the password matches successfully, the SED hard drive switches the encrypted partition within the lock range to a read-write state. All subsequent read and write operations will be automatically encrypted and decrypted in real time by the hard drive's internal encryption engine. The sending and verification process of this unlock command is completed independently by the security coprocessor. After successful unlocking, the SED hard drive begins to respond to normal read and write requests without the involvement of the main processor. If the password does not match or other abnormalities occur during the unlocking process, the self-encrypted hard drive remains locked and returns an error response. The security coprocessor then executes the corresponding fault handling procedure based on the response.

[0073] In some embodiments, if the SED hard drive supports the OPAL protocol, the unlock key can be the Admin1 password in the OPAL specification.

[0074] Then, the SATA controller can read the status register in the SED hard drive to obtain the first read / write status; when the first read / write status includes a readable / writable state, it is determined that the SED hard drive has been successfully unlocked.

[0075] If the first read / write state includes a non-read / write state, determine that the SED hard drive unlocking has failed, and then perform the following operations: First, the security coprocessor records an audit log, which includes at least one of the following: failure timestamp, hard drive model (or identification information), failure reason code (e.g., incorrect password, command timeout, hard drive unresponsive, etc.), etc., without limitation. This log can be stored in the non-volatile storage area inside the security coprocessor or output via serial port for subsequent troubleshooting and security auditing.

[0076] Secondly, the security coprocessor enters safe mode; in safe mode, the security coprocessor prevents the main processor from powering on (for example, by blocking the main processor's power enable signal), preventing the main processor from accessing the locked SED hard drive, thereby avoiding data leakage or abnormal system startup.

[0077] When the current locked state includes the unlocked state, it means that the SED hard drive is already in a read-write state and no unlocking operation is required. The security coprocessor can skip the unlocking step and directly proceed to the subsequent process. Alternatively, the SATA controller can send a lock command to the SED hard drive to control it to enter the locked state and then unlock it.

[0078] In this way, the SED hard drive is directly controlled through the SATA controller of the security coprocessor, and the hard drive is unlocked based on the unlock key bound to the eFuse hardware. The unlock result is verified twice through the status register. The entire process does not require the intervention of the main processor. This not only eliminates the risk of key leakage and unauthorized reading of the hard drive at the physical level, but also ensures the security and verifiability of the unlocking operation, effectively resisting physical disassembly and hard drive transplantation attacks.

[0079] It should be explained that the Discover Data command can also be used to query the OPAL function set supported by the SED hard drive, that is, the OPAL function support status of the SED hard drive.

[0080] In some embodiments, the first discovery result further includes: the OPAL function support status of the SED hard drive; the OPAL function support status includes any one of the following: supporting the OPAL protocol, not supporting the OPAL protocol; before sending the unlock command to the SED hard drive through the SATA controller to unlock the SED hard drive, the method further includes: S41. If the OPAL function support status includes support for the OPAL protocol, the SATA controller sends the unlock command to the SED hard drive to unlock the SED hard drive. S42. If the OPAL function support status includes not supporting the OPAL protocol, terminate the unlocking process.

[0081] In this embodiment of the application, if the OPAL function support status includes support for the OPAL protocol, it indicates that the hard drive conforms to the TCGOPAL specification and can be unlocked using the OPAL command set. At this time, the SATA controller can be executed to send the unlock command to the SED hard drive to unlock the SED hard drive.

[0082] If the OPAL function support status includes not supporting the OPAL protocol, it means that the hard drive cannot respond to the OPAL unlock command and cannot be unlocked using the OPAL command set; at this time, the security coprocessor terminates the unlocking process and does not send unlock commands to the hard drive.

[0083] In some embodiments, if the OPAL function support status includes not supporting the OPAL protocol, other protocols supported by the SED hard drive can be used for unlocking, such as the ATA Security protocol.

[0084] In this way, by verifying the hard drive's support for the OPAL protocol in advance, the unlocking operation is only performed when the protocol is compatible, and the process is terminated directly when it is incompatible. This avoids invalid command interactions and process abnormalities, improves boot stability, and adapts to hard drives of different specifications, thus expanding the scope of application.

[0085] S304. After the SED hard drive is successfully unlocked, the security coprocessor is controlled to release control of the host bus, so that the main processor can access the SED hard drive through the host bus and the main processor can start the operating system based on the SED hard drive.

[0086] In this embodiment, after the SED hard drive is unlocked, the security coprocessor voluntarily relinquishes control of the host bus, removing hardware restrictions on the main processor. The main processor can then access the SED hard drive normally via the host bus. Following the boot order set by the BIOS (or bootloader), the main processor reads the boot code from the boot partition of the SED hard drive and loads the operating system. Throughout this process, the security coprocessor no longer actively occupies the bus but responds to the main processor's access requests, achieving transparent access to the unlocked hard drive by the host.

[0087] S305. After the operating system starts, control the main processor to establish communication with the security coprocessor through the host bus so that the security coprocessor can provide cryptographic services to the main processor.

[0088] In this embodiment of the application, after the operating system starts, the main processor establishes a communication channel with the security coprocessor through the host bus. After the communication channel is established, the security coprocessor can provide cryptographic services to the main processor. The cryptographic services include at least one of the following: encryption operation, decryption operation, digital signature generation and verification, hash operation, random number generation, key secure storage, signature of remote authentication data, etc., which are not limited here.

[0089] In some embodiments, after the main processor establishes communication with the security coprocessor via the host bus, the method further includes: S51. Remotely authenticate the main processor through the TPM soft core to obtain a first authentication result; the first authentication result includes any one of the following: authentication successful, authentication failed; S52. When the first authentication result includes successful authentication, confirm that the main processor has successfully booted up in a trusted manner; S53. When the first authentication result includes authentication failure, generate a first prompt message; the first prompt message is used to prompt that the main processor has failed to boot.

[0090] In this embodiment of the application, the main processor is remotely authenticated based on the integrity measurement record in the TPM soft core to obtain a first authentication result; when the first authentication result includes successful authentication, it indicates that the startup process of the main processor is authentic and trustworthy, and at this time, the main processor is confirmed to have successfully started in a trustworthy manner. If the first authentication result includes authentication failure, a first prompt message is generated; the first prompt message is used to indicate that the main processor's trusted boot has failed; for example, the first prompt message can be "Trusted boot failed, please check".

[0091] In this way, by using the TPM soft core to complete remote authentication, the integrity of the device startup chain can be verified remotely. When authentication is abnormal, timely prompts can be issued, which makes it easier for maintenance personnel to quickly discover problems such as startup tampering and abnormal intrusion, thereby improving the overall security management capabilities of the device.

[0092] In some embodiments, please refer to Figure 5 , Figure 5 This is a flowchart of a remote authentication method provided in an embodiment of this application. The method involves remotely authenticating the main processor through the TPM soft core to obtain a first authentication result, including, for example... Figure 5 The steps shown are as follows: S61. Obtain the challenge random number sent by the remote authentication platform through the main processor, and forward the challenge random number to the TPM soft core; S62. By calling the signature command through the TPM soft core, the integrity measurement record and the challenge random number are signed using the preset identity authentication key to generate authentication evidence; S63. The authentication evidence is sent to the main processor via the TPM soft core; S64. The main processor sends the authentication evidence to the remote authentication platform and obtains the authentication result of the remote authentication platform on the authentication evidence to obtain the first authentication result.

[0093] In this embodiment of the application, the authentication key can be preset or defaulted.

[0094] In a specific embodiment, when the remote authentication platform initiates the authentication process, it first generates a random challenge number and sends the challenge number to the main processor. The main processor then forwards the challenge number to the TPM soft core. During this process, the challenge number is only forwarded by the main processor and is not modified or parsed by the main processor. Its original value is completely transmitted to the TPM soft core.

[0095] Then, the TPM soft core calls a signing command (e.g., the TPM2_Quote command defined in the TCG TPM 2.0 specification) to sign the integrity measurement record and the challenge random number using a preset identity key (AIK) to generate authentication evidence. Specifically, the integrity measurement record and the challenge random number can be concatenated together to form the data to be signed, and the AIK is used to sign the data to be signed to generate authentication evidence.

[0096] It should be explained that the TPM2_Quote command is a standard command specifically defined in the TPM specification for remote authentication; AIK is a key in TPM specifically used for remote authentication signatures, with the attribute of "restricted signature". The private key of AIK is encrypted and protected by the stored root key, never leaves the TPM soft core, and AIK cannot be used to sign any other arbitrary data, thus ensuring the authenticity and non-forgeability of remote authentication evidence.

[0097] Then, the TPM soft core can send the authentication evidence to the main processor, which in turn sends the authentication evidence to the remote authentication platform via the network and obtains the authentication result of the remote authentication platform, thus obtaining the first authentication result. Specifically, the remote authentication platform can parse a challenge random number, a specified PCR register value (i.e., integrity measurement record), and a digital signature value from the received authentication evidence. Then, it compares the parsed challenge random number with the previously sent challenge random number to obtain the first comparison result; it compares the specified PCR register value with the expected reference value to obtain the second comparison result; and it verifies the digital signature value using the preset AIK public key to obtain the fifth verification result. Each comparison result includes any of the following: consistent or inconsistent. Only when the first comparison result includes consistent, the second comparison result includes consistent, and the fifth verification result includes successful verification, is the first authentication result determined as successful authentication; otherwise, the first authentication result is determined as authentication failure.

[0098] Thus, by adopting a challenge-response mechanism, combined with integrity measurement records and random number joint signatures, replay attacks and forged authentications can be effectively prevented. Authentication evidence is generated based on hardware-level keys, ensuring the authenticity and reliability of authentication data and enabling remote platforms to accurately verify the device startup status.

[0099] In some embodiments, please refer to Figure 6 , Figure 6 This is a flowchart illustrating a trusted boot method based on a secure coprocessor, as provided in an embodiment of this application; the specific process is as follows: At [T+0ms], the security coprocessor powers on first; At [T+10ms], load the signed bitstream (i.e., the FPGA bitstream) and verify the bitstream signature; At [T+20ms], initialize the TPM soft core and read the PCR metric value (i.e., the value of the preset PCR register). At [T+50ms], an OPAL command is sent to the SED hard drive via the SATA controller to unlock the hard drive; At [T+100ms], the SED hard drive unlocking is complete, releasing the PCIe bus; At [T+200ms], the x86 host machine (i.e., the main processor) boots from the decrypted SED hard drive; At [T+500ms], the Linux kernel starts and loads the security coprocessor driver. Specifically, it starts the Linux kernel in the x86 host machine, which contains a driver. After the x86 host machine starts, this driver will actively discover and load the security coprocessor, establish a communication channel, and make it ready to use at any time.

[0100] At [T+1s], a secure channel is established and the key is loaded into the memory of the secure coprocessor. Specifically, a secure channel can be further established on the basis of the communication channel, and sensitive data such as the session key can be transmitted through the secure channel or directly loaded into the secure coprocessor.

[0101] In summary, this method ensures the integrity and trustworthiness of its boot chain by having the security coprocessor power on before the main processor and independently complete the first-stage bootloader, FPGA bitstream, and digital signature verification of the security firmware before BIOS startup. The security coprocessor's built-in SATA controller directly sends unlock commands to the SED hard drive, preventing the unlock key from passing through the main processor and its memory, thus effectively preventing key extraction by malware or physical attacks. Only after successful hard drive unlocking is the host bus control released, ensuring the main processor can only access unlocked hard drives. Simultaneously, the initialized TPM soft core provides a hardware trust foundation for subsequent password services, and the main processor establishes communication with the security coprocessor via the host bus after startup, with the security coprocessor providing independent password services. This eliminates the risks of firmware tampering, key leakage, and unauthorized data access throughout the boot process, significantly improving device startup security.

[0102] Please see Figure 7 , Figure 7 This is a schematic diagram of a trusted boot device based on a secure coprocessor provided in an embodiment of this application; the trusted boot device 700 based on a secure coprocessor includes: a power-on module 701 and a trusted boot module 702, wherein: The power-on module 701 is used to power on the security coprocessor before the main processor, load and verify the digital signatures of the first-stage bootloader, FPGA bitstream and security firmware, and obtain a first verification result; the first verification result includes any of the following: verification successful, verification failed; The trusted boot module 702 is configured to initialize the TPM soft core in the security coprocessor when the first verification result includes successful verification; send an unlock command to the SED hard drive through the SATA controller in the security coprocessor to unlock the SED hard drive; after the SED hard drive is successfully unlocked, control the security coprocessor to release control over the host bus, enabling the main processor to access the SED hard drive through the host bus, and the main processor to boot the operating system based on the SED hard drive; after the operating system boots, control the main processor to establish communication with the security coprocessor through the host bus, so that the security coprocessor can provide cryptographic services to the main processor.

[0103] In specific implementations, the trusted boot device 700 based on a secure coprocessor described in the embodiments of the present invention can also execute other implementations described in the trusted boot method based on a secure coprocessor provided in the embodiments of the present invention, which will not be repeated here.

[0104] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include a processor, a memory, a communication interface, and one or more programs. The processor, memory, and communication interface can be interconnected via a bus. The one or more programs are stored in the memory and configured to be executed by the processor. In this embodiment, the programs include all or part of the steps for performing the trusted boot method based on a secure coprocessor described in the above embodiment.

[0105] The processor can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, cells, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, transceiver, transceiver circuit, etc., and the storage unit can be a memory.

[0106] The memory can be volatile or non-volatile, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0107] It is understood that electronic devices may include more or fewer structural elements than those shown in the above block diagram, such as power modules, physical buttons, Wi-Fi modules, speakers, Bluetooth modules, sensors, display modules, etc., without limitation.

[0108] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0109] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0110] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0111] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0112] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0113] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0114] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0115] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

[0116] The aforementioned computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media.

[0117] The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0118] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0119] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A trusted boot method based on a secure coprocessor, characterized in that, The method includes: The security coprocessor powers on before the main processor, loads and verifies the digital signatures of the first-stage bootloader, FPGA bitstream, and security firmware, and obtains a first verification result; the first verification result includes any of the following: verification successful, verification failed; When the first verification result includes verification success, the TPM soft core in the security coprocessor is initialized; The SATA controller in the security coprocessor sends an unlock command to the SED hard drive to unlock the SED hard drive; After the SED hard drive is successfully unlocked, the security coprocessor is controlled to release control of the host bus, allowing the main processor to access the SED hard drive through the host bus, and the main processor starts the operating system based on the SED hard drive. After the operating system starts, the main processor is controlled to establish communication with the security coprocessor through the host bus, so that the security coprocessor can provide cryptographic services to the main processor. The step of sending an unlock command to the SED hard drive through the SATA controller in the security coprocessor to unlock the SED hard drive includes: The SATA controller sends a discovery data command to the SED hard drive to obtain a first discovery result; the first discovery result includes the current lock status; the current lock status includes any of the following: unlocked, locked; When the current locked state includes locked, the unlock key is read from the eFuse in the security coprocessor; the unlock command is sent to the SED hard drive through the SATA controller to unlock the SED hard drive; the unlock command includes the unlock key; The first read / write state is obtained by reading the status register in the SED hard drive through the SATA controller; the first read / write state includes any one of the following: readable / writable state, and unreadable / writable state. When the first read / write state includes a read / write state, it is determined that the SED hard drive has been successfully unlocked; The first discovery result also includes: the OPAL function support status of the SED hard disk; the OPAL function support status includes any one of the following: supporting the OPAL protocol, not supporting the OPAL protocol; Before sending the unlock command to the SED hard drive via the SATA controller to unlock the SED hard drive, the method further includes: If the OPAL function support status includes support for the OPAL protocol, the step of sending the unlock command to the SED hard drive through the SATA controller to unlock the SED hard drive is executed; If the OPAL function support status includes not supporting the OPAL protocol, the unlocking process will be terminated.

2. The method as described in claim 1, characterized in that, The security coprocessor also includes: BootROM, on-chip memory, FPGA Fabric, and ARM processor core; The loading and verification of the first-stage bootloader, FPGA bitstream, and digital signature of the security firmware yields a first verification result, including: The BootROM is executed to read the first-stage bootloader from a preset memory; The digital signature of the first-stage bootloader is verified based on the root public key in the eFuse to obtain a second verification result; When the second verification result includes successful verification, the first-stage bootloader is loaded into the on-chip memory and executed; the first-stage bootloader is used to read the FPGA bitstream from the preset memory; The digital signature of the FPGA bitstream is verified based on the root public key to obtain a third verification result; When the third verification result includes successful verification, the FPGA bitstream is loaded into the FPGA Fabric to configure the hardware functions of the security coprocessor; The security firmware is read from the preset memory, and the digital signature of the security firmware is verified based on the root public key to obtain a fourth verification result; When the fourth verification result includes a successful verification, the security firmware is loaded and executed through the ARM processor core; The first verification result is determined based on the second verification result, the third verification result, and the fourth verification result.

3. The method as described in claim 2, characterized in that, The initialization of the TPM soft core in the security coprocessor includes: The TPM soft core is instantiated in the FPGA Fabric to obtain the instantiated TPM soft core; The instantiated TPM soft core reads the preset PCR initial value from the eFuse and calls the PCR extension command to extend the PCR initial value to the preset PCR register; The storage root key is generated using the instantiated TPM soft core.

4. The method as described in claim 3, characterized in that, After generating the storage root key through the instantiated TPM soft core, the method further includes: The PCR extension operation is performed sequentially on each startup chain component to be started in the security coprocessor, and the hash value of each startup chain component is recorded in the preset PCR register to obtain the integrity measurement record corresponding to each startup chain component.

5. The method as described in claim 4, characterized in that, After the main processor establishes communication with the security coprocessor via the host bus, the method further includes: The main processor is remotely authenticated by the TPM soft core to obtain a first authentication result; the first authentication result includes any one of the following: authentication successful, authentication failed; If the first authentication result includes successful authentication, it is confirmed that the main processor has successfully booted up in a trusted manner. When the first authentication result includes authentication failure, a first prompt message is generated; the first prompt message is used to indicate that the main processor has failed to boot.

6. The method as described in claim 5, characterized in that, The step of remotely authenticating the main processor through the TPM soft core to obtain a first authentication result includes: The main processor obtains the challenge random number sent by the remote authentication platform and forwards the challenge random number to the TPM soft core; The TPM soft core invokes a signature command, using a preset identity authentication key to sign the integrity measurement record and the challenge random number, thereby generating authentication evidence; The authentication evidence is sent to the main processor via the TPM soft core; The main processor sends the authentication evidence to the remote authentication platform and obtains the authentication result of the remote authentication platform on the authentication evidence to obtain the first authentication result.

7. A trusted boot device based on a secure coprocessor, used to perform the method as described in any one of claims 1-6, characterized in that, The device includes: a power-on module and a trusted boot module, wherein: The power-on module is used to power on the security coprocessor before the main processor, load and verify the digital signatures of the first-stage bootloader, FPGA bitstream and security firmware, and obtain a first verification result; the first verification result includes any of the following: verification successful, verification failed; The trusted boot module is configured to initialize the TPM soft core in the security coprocessor when the first verification result includes successful verification; send an unlock command to the SED hard drive through the SATA controller in the security coprocessor to unlock the SED hard drive; after the SED hard drive is successfully unlocked, control the security coprocessor to release control over the host bus, enabling the main processor to access the SED hard drive through the host bus, and the main processor to boot the operating system based on the SED hard drive; after the operating system boots, control the main processor to establish communication with the security coprocessor through the host bus, so that the security coprocessor can provide cryptographic services to the main processor.

8. A computer-readable storage medium, characterized in that, A computer program for storing electronic data interchange is provided, wherein the computer program causes a computer to perform the method as described in any one of claims 1-6.

Images