Trusted boot method for multi-processor system, and trusted component and chip

Abstract

The present application relates to the field of chips. Disclosed are a trusted boot method for a multi-processor system, and a trusted component and a chip. In the method, when a multi-processor system is booted, a slave processor performs identity authentication and key negotiation with a trusted component by means of a master processor; and after the identity authentication is passed and a key is negotiated, a measurement result of the slave processor that is encrypted on the basis of the key is forwarded to the trusted component by means of the master processor, thereby ensuring that the slave processor and the trusted component perform channel encryption on the basis of mutually trusting identities of each other; and it can be ensured that the measurement result of the slave processor cannot be viewed or tampered with by the master processor during transmission, thereby improving the security of the trusted boot of the system.

Description

Trusted boot methods, trusted components and chips for multiprocessor systems

[0001] This application claims priority to Chinese Patent Application No. 202510086298.0, filed on January 17, 2025, entitled “Trusted Boot Method, Trusted Component and Chip for Multiprocessor System”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of chip technology, and in particular to a trusted boot method, trusted components, and chip for a multiprocessor system. Background Technology

[0003] Trusted boot refers to the process of verifying whether various components in a computer system have been tampered with or maliciously replaced during startup, ensuring that the system completes the startup process in a secure and tamper-free state. Currently, trusted platform modules (TPMs) are widely used in trusted boot scenarios for computer systems.

[0004] In related technologies, taking a multi-processor computer system as an example, a multi-processor system typically includes a master processor and slave processors. The master processor is connected to a TPM (Telematics Management Platform), and the slave processors are connected to the master processor. Each processor has its own set of boot code. When the system starts, the master processor measures its own boot code and transmits the measurement result to the TPM. The slave processor measures its own boot code and forwards the measurement result to the TPM through the master processor. The TPM signs the measurement result and sends the signed measurement result to a remote server, which verifies the integrity and security of the system startup.

[0005] However, since the measurement results from the processor must be relayed to the main processor before reaching the TPM, the measurement results from the processor may be tampered with by the main processor, resulting in insufficient security for trusted boot of the system. Summary of the Invention

[0006] This application provides a trusted boot method, trusted components, and chip for a multiprocessor system, which can improve the security of trusted boot of the system.

[0007] Firstly, a trusted boot method for a multiprocessor system is provided, applicable to trusted boot scenarios in multiprocessor systems. The multiprocessor system involved in this application can be applied to the information and communications technology (ICT) field, such as computing, storage, data communication, optical communication, wireless, cloud computing, etc., and is not limited thereto. The multiprocessor system includes a master processor and slave processors; the master processor is connected to a trusted component, and the slave processors are connected to the master processor. The method includes:

[0008] The slave processor measures the startup code of the slave processor and performs authentication and key negotiation between the master processor and the trusted component. After successful authentication and key negotiation, the slave processor's measurement result is encrypted based on the negotiated key, and the encrypted slave processor's measurement result is forwarded to the trusted component through the master processor.

[0009] The trusted component decrypts the encrypted measurement result of the slave processor based on the negotiated key to obtain the measurement result of the slave processor.

[0010] In the above method, when the multiprocessor system starts up, the slave processor performs identity authentication and key negotiation between the master processor and the trusted component. After the identity authentication is successful and the key is negotiated, the measurement result of the slave processor, which is encrypted based on the key, is forwarded to the trusted component by the master processor. This ensures that the slave processor and the trusted component perform channel encryption on the basis of mutual trust in each other's identities, and ensures that the measurement result of the slave processor cannot be viewed or tampered with by the master processor during transmission, thereby improving the security of the trusted startup of the system.

[0011] In some embodiments, the measurement results from the processor include the hash value of the startup code and the verification result of the hash value. The measurement results from the processor are used by a remote server to verify the startup process of the multiprocessor system. For example, the trusted component signs the measurement results and sends the signed measurement results to the remote server. The remote server checks whether the hash value in the measurement results is consistent with a preset hash value, thereby determining whether the multiprocessor system starts in a trusted state.

[0012] In some embodiments, the slave processor stores a negotiated first key, which is used to encrypt the measurement results of the slave processor; the trusted component stores a negotiated second key, which is used to decrypt the encrypted measurement results of the slave processor.

[0013] In some embodiments, the method further includes: the processor forwarding a first message authentication code to a trusted component via a master processor, the first message authentication code being generated based on a first key and a measurement result from the processor; the trusted component generating a second message authentication code based on a second key and a measurement result from the processor; and if the first message authentication code matches the second message authentication code, it is determined that the measurement result from the processor has not been tampered with.

[0014] In this way, message authentication can be achieved between the processor and the trusted component using the negotiated key, ensuring that the measurement results received by the trusted component from the processor are complete and tamper-proof.

[0015] In some embodiments, authentication information is stored in both the processor and the trusted component, and this authentication information is used for authentication between the processor and the trusted component.

[0016] By storing identity authentication information, the processor and trusted components can exchange their respective identity authentication information to verify each other's identity, thus achieving two-way identity authentication between the processor and trusted components.

[0017] In some embodiments, the identity authentication information includes an identity certificate issued by a Certificate Authority (CA); the processor stores a first identity certificate issued by the CA, which is used to verify the identity of the processor in conjunction with the CA's root certificate; and the trusted component stores a second identity certificate issued by the CA, which is used to verify the identity of the trusted component in conjunction with the CA's root certificate.

[0018] The above method uses identity certificates issued by a Certificate Authority (CA) for authentication. Since a CA is an authoritative third-party organization, its certificates ensure the legitimacy and trustworthiness of both the processor and the trusted component. Furthermore, using CA-issued certificates allows for easy expansion. For example, when adding a new processor to a multi-processor system, the new processor only needs to apply for a certificate from the CA, and the trusted component can then verify the new processor's identity using the CA-issued certificate. In some scenarios, the manufacturers of the processor and trusted component can act as the CA to issue identity certificates. This method ensures that neither the processor nor the trusted component has been replaced.

[0019] In some embodiments, the authentication information includes a shared key; the processor and the trusted component each store a shared key, which is used to encrypt a random number in the authentication request to verify the identity of the processor and the trusted component.

[0020] The above method, using a pre-configured shared key for authentication, offers a simple and direct authentication process, saving computational resources and time, and improving authentication efficiency. In some scenarios, for relatively closed SOC systems, the system environment is relatively isolated and not easily vulnerable to external attacks. In such cases, the pre-configured shared key approach can provide sufficient security and simplify system design and maintenance.

[0021] In some embodiments, the authentication information includes physical fingerprints. The secure storage area of ​​the multiprocessor system stores the physical fingerprints of the slave processor and the trusted component. The slave processor stores a first physical fingerprint, which is used to compare with the physical fingerprint of the slave processor stored in the secure storage area to verify the identity of the slave processor. The trusted component stores a second physical fingerprint, which is used to compare with the physical fingerprint of the trusted component stored in the secure storage area to verify the identity of the trusted component.

[0022] The above method uses physical fingerprints for identity authentication. Because this method utilizes the inherent characteristics of the hardware, it avoids the security risks posed by software vulnerabilities. For example, the physical fingerprint is obtained by measuring the current change curve of a chip under specific operations. This curve is determined by the chip's internal physical structure and manufacturing process, making it difficult to maliciously tamper with or simulate.

[0023] In some embodiments, the slave processor performs authentication and key negotiation between the master processor and the trusted component. After successful authentication and key negotiation, the slave processor's measurement result is encrypted based on the negotiated key, and the encrypted slave processor's measurement result is forwarded to the trusted component through the master processor, including:

[0024] The security component on the processor performs authentication and key negotiation between the master processor and the trusted component. After successful authentication and key negotiation, the measurement results of the slave processor are encrypted based on the negotiated key, and the encrypted measurement results of the slave processor are forwarded to the trusted component through the master processor. The security component is used to run the first-level immutable boot code.

[0025] In some embodiments, the security component includes a read-only memory (ROM) and runtime firmware, the ROM and runtime firmware being linked, the ROM storing first-level immutable boot code;

[0026] The security component on the processor performs authentication and key negotiation between the main processor and the trusted component. After successful authentication and key negotiation, the measurement result of the slave processor is encrypted based on the negotiated key, and the encrypted measurement result of the slave processor is forwarded to the trusted component through the main processor, including:

[0027] The runtime firmware performs authentication and key negotiation between the main processor and the trusted component. After successful authentication and key negotiation, the measurement results of the slave processor are encrypted based on the negotiated key, and the encrypted measurement results of the slave processor are forwarded to the trusted component through the main processor.

[0028] In some embodiments, measuring the boot code of the processor from the processor includes: a security component running first-level immutable boot code in the ROM, measuring first-level variable boot code after the ROM is booted, and obtaining a measurement result of the first-level variable boot code; the security component running first-level variable boot code, measuring the boot code of the runtime firmware and the boot code of the basic input / output system BIOS, and obtaining a measurement result of the runtime firmware and a measurement result of the BIOS; and the processor running the boot code of the BIOS, measuring the boot code of the operating system OS, and obtaining a measurement result of the OS.

[0029] The security component is equipped with an encryption engine and processing unit, possessing security processing capabilities and able to perform operations such as hash calculations on the first-level variable boot code after ROM startup. Runtime firmware refers to the firmware code executed by the security component at runtime, providing secure storage functions and communication capabilities with devices external to the processor. Through this method, the processor's measurement process of the boot code is implemented, ensuring that authentication and key negotiation between the processor and the trusted component are performed securely.

[0030] In some embodiments, the multiprocessor system and the trusted component are integrated on a single chip; alternatively, the multiprocessor system and the trusted component are deployed on separate chips. Integrating the multiprocessor system and the trusted component on a single chip reduces hardware costs and improves communication efficiency and system integration between the two. Separate deployment of the multiprocessor system and the trusted component provides greater security isolation, and the separate trusted component allows for more flexible compatibility with different multiprocessor systems.

[0031] In some embodiments, the method further includes: the trusted component storing the measurement results of the slave processor in recording mode without rejecting the startup of the multiprocessor system; or, the trusted component verifying the measurement results of the slave processor through a remote server in verification mode, and if the verification passes, the multiprocessor system starts; if the verification fails, the startup of the multiprocessor system is rejected.

[0032] The logging mode allows for complete traceability of each step in the system startup process to ensure it has not been tampered with, should any subsequent needs arise. The verification mode enables timely checks on the security and trustworthiness of the system startup process, ensuring the system starts in a trusted state and guarantees its secure operation.

[0033] Secondly, a trusted boot method for a multiprocessor system is provided, applied to a trusted component, wherein the multiprocessor system includes a master processor and slave processors, the master processor is connected to the trusted component, and the slave processor is connected to the master processor, the method comprising:

[0034] The main processor and the slave processor perform identity authentication and key negotiation. After identity authentication is successful and the key is negotiated, the encrypted measurement result of the slave processor is received by the main processor.

[0035] The encrypted measurement result of the slave processor is decrypted based on the negotiated key to obtain the measurement result of the slave processor. The measurement result of the slave processor is obtained by the slave processor measuring the startup code of the slave processor.

[0036] In some embodiments, the metric results from the processor include the hash value of the boot code and the verification result of the hash value, and the metric results from the processor are used by a remote server to verify the boot process of the multiprocessor system.

[0037] In some embodiments, the trusted component stores a negotiated second key, which is used to decrypt the encrypted measurement results from the slave processor.

[0038] In some embodiments, the method further includes: receiving a first message authentication code sent by the master processor, the first message authentication code being generated by the slave processor based on a first key and a measurement result of the slave processor; generating a second message authentication code based on a second key and a measurement result of the slave processor; and determining that the measurement result of the slave processor has not been tampered with if the first message authentication code matches the second message authentication code.

[0039] In some embodiments, the trusted component stores authentication information used for authentication between the slave processor and the trusted component; wherein...

[0040] The identity authentication information includes an identity certificate issued by a Certificate Authority (CA), and the trusted component stores a second identity certificate issued by the CA, which is used to verify the identity of the trusted component in conjunction with the CA's root certificate; or...

[0041] The authentication information includes a shared key, which is stored in the trusted component. The shared key is used to encrypt a random number in the authentication request to verify the identities of the slave processor and the trusted component; or...

[0042] The identity authentication information includes a physical fingerprint, and the trusted component stores a second physical fingerprint. The second physical fingerprint is used to compare with the physical fingerprint of the trusted component in the secure storage area of ​​the multiprocessor system to verify the identity of the trusted component.

[0043] Thirdly, a trusted boot method for a multiprocessor system is provided, applied to a multiprocessor system including a master processor and slave processors, wherein the master processor is connected to a trusted component, and the slave processor is connected to the master processor, the method comprising:

[0044] The slave processor measures the startup code of the slave processor and performs identity authentication and key negotiation between the master processor and the trusted component. After identity authentication is successful and the key is negotiated, the measurement result of the slave processor is encrypted based on the negotiated key, and the measurement result of the slave processor encrypted based on the key is forwarded to the trusted component through the master processor.

[0045] In some embodiments, the metric results from the processor include the hash value of the boot code and the verification result of the hash value, and the metric results from the processor are used by a remote server to verify the boot process of the multiprocessor system.

[0046] In some embodiments, the slave processor stores a negotiated first key, which is used to encrypt the measurement results of the slave processor.

[0047] In some embodiments, the method further includes: the slave processor forwarding a first message authentication code to the trusted component via the master processor, the first message authentication code being generated based on the first key and the measurement result of the slave processor.

[0048] In some embodiments, the processor stores authentication information used for authentication between the processor and the trusted component; wherein...

[0049] The identity authentication information includes an identity certificate issued by a Certificate Authority (CA), and the slave processor stores a first identity certificate issued by the CA, which is used to verify the identity of the slave processor in conjunction with the CA's root certificate; or...

[0050] The authentication information includes a shared key, which is stored in the slave processor. The shared key is used to encrypt a random number in the authentication request to verify the identity of the slave processor and the trusted component; or...

[0051] The identity authentication information includes a physical fingerprint. The slave processor stores a first physical fingerprint, which is used to compare with the physical fingerprint of the slave processor in the secure storage area of ​​the multiprocessor system to verify the identity of the slave processor.

[0052] Fourthly, a trusted component is provided, which includes a processing unit and a communication interface. The communication interface is used to communicate with components outside the trusted component, and the processing unit is used to implement the functions of the trusted component in the trusted boot method of a multiprocessor system provided by the first aspect or any alternative method of the first aspect.

[0053] Fifthly, a multiprocessor chip is provided, which integrates a master processor and a slave processor. The communication interface of the master processor is used to communicate with components outside the master processor. The multiprocessor chip is used to implement the functions of the multiprocessor system in the trusted boot method of the multiprocessor system provided in the first aspect or any alternative method of the first aspect.

[0054] In a sixth aspect, a chip is provided that integrates multiple processors and a trusted component, the multiple processors including a master processor and a slave processor, the master processor and the trusted component being connected, the slave processor and the master processor being connected, and the chip being used to implement a trusted boot method for a multiprocessor system as provided in the first aspect or any alternative method of the first aspect.

[0055] In a seventh aspect, a single board is provided, the single board including multiple processors and a trusted component, the multiple processors including a master processor and a slave processor, the master processor and the trusted component being connected, the slave processor and the master processor being connected, the multiple processors and the trusted component being integrated on a single chip, or the multiple processors and the trusted component being deployed on different chips respectively, the single board being used to implement the trusted boot method of a multiprocessor system as provided in the first aspect or any optional method of the first aspect.

[0056] Eighthly, an apparatus is provided, the apparatus comprising a plurality of processors and a trusted component, the plurality of processors including a master processor and a slave processor, the master processor and the trusted component being connected, the slave processor and the master processor being connected, the apparatus being configured to implement a trusted boot method for a multiprocessor system as provided in the first aspect or any alternative embodiment of the first aspect.

[0057] A ninth aspect provides a computer-readable storage medium for storing at least one piece of program code for implementing a trusted boot method for a multiprocessor system as provided in the first aspect or any alternative embodiment of the first aspect. The storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk drive (HDD), and solid-state drive (SSD).

[0058] In a tenth aspect, a computer program product is provided for implementing a trusted boot method for a multiprocessor system as provided in the first aspect or any alternative method of the first aspect. Attached Figure Description

[0059] Figure 1 is a schematic diagram of a computer system performing trusted boot;

[0060] Figure 2 is a schematic diagram of trusted boot execution under different hardware configurations;

[0061] Figure 3 is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0062] Figure 4 is a schematic diagram of a deployment method of a multiprocessor system and trusted components provided in an embodiment of this application;

[0063] Figure 5 is a schematic diagram of the structure of a trusted component provided in an embodiment of this application;

[0064] Figure 6 is a schematic diagram of the structure of a device provided in an embodiment of this application;

[0065] Figure 7 is a flowchart of a trusted boot method for a multiprocessor system provided in an embodiment of this application;

[0066] Figure 8 is a schematic diagram of a trusted boot method for a multiprocessor system provided in an embodiment of this application;

[0067] Figure 9 is a schematic diagram of a secure boot device for a multiprocessor system provided in an embodiment of this application;

[0068] Figure 10 is a schematic diagram of the structure of a secure boot device for a multiprocessor system provided in an embodiment of this application. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the identity certificates and identity authentication requests involved in this application are obtained under fully authorized circumstances.

[0070] To facilitate understanding, the key terms and concepts involved in this application will be explained below.

[0071] Trusted boot refers to the process by which a computer system verifies whether its components have been tampered with or maliciously replaced during startup, ensuring that the system completes the startup process in a secure and tamper-free state.

[0072] Measurement, or trusted measurement, is the process of verifying the security of an object being measured. Measurement generally includes two processes: calculation and verification. Calculation involves using a predetermined algorithm to calculate a hash value from the software code or configuration file of the object being measured. Verification involves comparing the calculated hash value with a pre-stored benchmark for that object (such as a default hash value). If the hash value matches the benchmark, the object is deemed secure; otherwise, it is not. For example, a default hash value is usually provided by the program developer at the time of program release.

[0073] Schematic illustration, referring to Figure 1, shows a diagram of a computer system performing trusted boot. As shown in Figure 1, the computer system includes a root of trust (RoT), which is the foundation for ensuring the security and trustworthiness of the system. It is typically the earliest component loaded during system startup and is immutable. During system startup, starting from the RoT, the startup code of components such as the basic input / output system (BIOS) and operating system (OS) is measured level by level to ensure that the system boots in a secure and tamper-proof state. The components that start first verify the hash value of the startup code of the next component to complete the integrity verification of the next component. Since the verification logic within the RoT is immutable and the trust relationship begins to be passed before the operating system starts, if each level of verification passes, the top-level application software is considered trustworthy and tamper-proof.

[0074] A Trusted Platform Module (TPM) is a security chip that can be installed on a computer motherboard. TPMs enhance computer system security by providing hardware-based security-related functions. Typically, a TPM includes non-volatile memory for storing information such as encryption keys and digital certificates, as well as dedicated hardware circuitry for performing encryption and decryption operations and hash calculations. TPMs provide security functions such as encryption and digital signatures by generating and managing keys. In trusted boot scenarios, TPMs are often used to verify the integrity of hardware, firmware, and other components in a computer system. Typically, trusted boot requires the computer system's processor to start measuring the root code and progressively measure the boot code of the next component, passing the measurement results (including the hash value of the boot code, or the hash value and its verification result) directly to the TPM for storage. These measurement results must not be tampered with by any other logic during transmission. The TPM then signs the stored measurement results and sends the signed results to a remote server, which verifies the integrity and security of the system boot process.

[0075] A hardware-based root of trust (HBRT) is a hardware component or a special area within hardware that serves as the source of trust for a computer system's trusted boot process. For example, a hardware security module (HSM) integrated into a system-on-chip (SoC) can serve as a hardware HBRT by utilizing the immutable Level 1 boot code within the HSM. Similarly, the immutable keys and initialization code within a TPM chip can also function as a hardware HBRT.

[0076] Firmware (FW) can have different definitions, and any reasonable interpretation within the computer field applies to this application. For example, it can be interpreted as: a program pre-installed in read-only memory within a hardware product, bundled and compatible with the hardware product. For example, the BIOS of a computer system is a type of firmware. Firmware can also be interpreted as: a program running on a "non-controlling processor," where "non-controlling processor" refers to a processor that does not directly run an operating system, such as a processor in a peripheral device. "Non-controlling processor" can also refer to some cores in a processor used in a bare-metal virtual machine system. Firmware can also be interpreted as: an operating system that does not support dynamic application installation and an executable file that does not support dynamic application installation. It should be noted that the above interpretations are merely illustrative and should not be considered as limiting the technical solution of this application.

[0077] In this application, a multi-processor system refers to a computer hardware system that includes multiple processors (such as a chip or board integrating multiple processors), or simply multi-processor hardware. Illustratively, a multi-processor system typically includes a master processor and slave processors, each with its own set of boot code. In this application, the processors in a multi-processor system are divided into master and slave processors according to functional or business requirements. This does not imply that the master and slave processors must be different in hardware structure. The master and slave processors can use the same model of processor or different models of processors; this application does not limit this. Furthermore, this application does not limit the number of master processors or slave processors in a multi-processor system.

[0078] The application scenarios and implementation environment of this application are described below.

[0079] The technical solutions provided in this application can be applied to trusted boot scenarios of multiprocessor systems. The multiprocessor systems involved in this application can be applied to the field of information and communications technology (ICT), such as computing, storage, data communication, optical communication, wireless, cloud computing, etc., and are not limited thereto.

[0080] Schematic illustration, referring to Figure 2, illustrates a trusted boot process under different hardware configurations. As shown in Figure 2, trusted boot is implemented using a TPM as an example. For a single-processor system, the processor (central processing unit, CPU) communicates with the TPM via a serial peripheral interface (SPI). Starting from the Hardware Trusted Root (HBRT), the processor measures the boot code of the Basic Output / Output System (BIOS) and the Operating System (OS) level by level, and transmits the measurement results of the BIOS and OS to the TPM via SPI. Since the TPM standard definition requires a direct physical connection between the TPM and the processor, its purpose is to prevent any intermediate logic from tampering with the measurement results transmitted from the processor to the TPM, thereby ensuring the security of trusted boot. Therefore, a single-processor system meets the standard definition requirements.

[0081] In a multiprocessor system, which includes a master processor and slave processors, the master processor typically communicates with the TPM via SPI. Slave processors connect to the master processor, for example, using an inter-chip communication protocol such as Hydra Interface (a high-bandwidth, low-latency inter-chip communication protocol). Each processor has its own set of boot code. In the diagram, the boot code corresponding to the master processor is represented as the master package (P), and the boot code corresponding to the slave processor is represented as the slave package (P). As shown, during system startup, the master processor measures its own boot code and transmits the measurement result to the TPM. The slave processor measures its own boot code and forwards the measurement result to the TPM via the master processor. Therefore, in related technologies, because the measurement result of the slave processor must be relayed by the master processor before reaching the TPM, the measurement result of the slave processor may be tampered with by the master processor, leading to insufficient security for trusted boot.

[0082] Based on this, this application provides a trusted boot method for a multiprocessor system, enabling secure communication between the slave processor and the TPM without relying on a direct physical connection, thereby improving the security of trusted boot. The implementation environment of this application will be described below with reference to Figure 3.

[0083] Figure 3 is a schematic diagram of an implementation environment provided by an embodiment of this application. As shown in Figure 3, the implementation environment includes a multiprocessor system 100 and a trusted component 200. The multiprocessor system 100 includes multiple processors, which can be divided into a master processor 101 and slave processors 102 according to functional or business requirements. The master processor 101 is connected to the trusted component 200, for example, through SPI communication, that is, the master processor 101 and the trusted component 200 are physically directly connected. The slave processors 102 are connected to the master processor 101. For example, the slave processors 102 and the master processor 101 use the Hydra Interface to achieve high-bandwidth, low-latency inter-chip communication. This application does not limit the inter-chip communication protocol used between the slave processors 102 and the master processor 101. In addition, the number of master processors 101 and slave processors 102 in the figure is only for illustrative purposes. The number of master processors 101 can be more, and the number of slave processors 102 can be more or less. This application does not limit this.

[0084] In this embodiment, each processor in the multiprocessor system 100 has its own set of boot code. For any given processor, the processor runs an operating system to provide services in the corresponding technical field. This application does not limit the technical field involved in the multiprocessor system 100, but includes fields such as computing, storage, data communication, optical communication, wireless, and cloud computing.

[0085] For any slave processor 102, the slave processor 102 communicates with the trusted component 200 through the master processor 101. That is, when the slave processor 102 transmits data to the trusted component 200, it needs to send the data to the master processor 101, which then forwards the data to the trusted component 200. This process can also be understood as the process of the slave processor 102 extending data to the trusted component 200. Similarly, when the trusted component 200 transmits data to the slave processor 102, it also needs to send the data to the master processor 101, which then forwards the data to the slave processor 102. This process can also be understood as the process of the trusted component 200 extending data to the slave processor 102.

[0086] In some embodiments, the slave processor 102 includes a security component 1021, which provides the slave processor 102 with high-security functions such as secure boot, storage and upgrade of software / firmware / keys / certificates, and key management. Indicatively, the security component 1021 is a hardware security module (HSM), including a read-only memory (ROM) and runtime firmware (FW), with the ROM connected to the runtime firmware. The ROM stores the first-level immutable boot code, which is the initial boot code after the chip is powered on; it is immutable and trusted. For example, depending on the code naming convention, the ROM storing the first-level immutable boot code can be defined as a BootROM. The runtime firmware refers to the firmware code executed by the security component 1021 at runtime, providing secure storage functions, communication functions with external devices, etc. In some embodiments, the security component 1021 also includes a first-level upgradeable boot firmware, used to run the first-level variable boot code loaded after the chip is powered on; the content of this code can be rewritten. For example, depending on different code naming conventions, the first-level upgradeable boot firmware can be defined as Hboot1.

[0087] Trusted component 200 is used to provide hardware-based security-related functions to enhance the security of multiprocessor system 100, such as providing high-security functions like secure boot, storage and upgrade of software / firmware / keys / certificates, and key management. Indicatively, trusted component 200 is a TPM (Trusted Product Management System). In this embodiment, during the boot process of multiprocessor system 100, trusted component 200 receives measurement results obtained by the main processor 101 from measuring the boot code, and also receives measurement results obtained by the slave processor 102 from measuring the boot code through the main processor 101. Based on the received measurement results, it records or verifies the boot process of multiprocessor system 100. Taking the measurement result of the slave processor as an example, the measurement result includes a hash value obtained by hashing the boot code of the slave processor, and a verification result of the hash value, which indicates whether the calculated hash value has passed verification. Alternatively, the measurement result includes the hash value of the boot code. That is, the measurement result received by trusted component may not include the verification result.

[0088] In some embodiments, the trusted component 200, in recording mode, records the received measurement results, that is, stores the received measurement results, and does not refuse the startup of the multiprocessor system 100. It should be understood that the recording mode is used to completely record the measurement results of each component during the system startup process. In this way, it is convenient to completely trace whether each step of the system startup process has been tampered with during subsequent verification.

[0089] In other embodiments, in verification mode, the trusted component 200 verifies the startup process of the multiprocessor system based on the received measurement results. If the verification passes, the multiprocessor system 100 is allowed to start; if the verification fails, the startup of the multiprocessor system 100 is rejected. For example, the trusted component 200 signs the received measurement results and sends the signed measurement results to a remote server, which verifies the integrity and security of the system startup. It should be understood that the verification mode is used to check whether the system startup process is secure and trustworthy. For instance, cloud service providers can use the remote authentication function of the trusted component 200 to confirm whether the multiprocessor server instance rented by the user starts from a trusted state, thus ensuring the security of cloud services.

[0090] In this embodiment, the slave processor 102 and the trusted component 200 each store authentication information, which may be one or more of an identity certificate, a shared key, and a physical fingerprint; this application does not limit the specific type of authentication information. During the startup process of the multiprocessor system 100, the slave processor 102 and the trusted component 200 exchange their respective authentication information through the master processor 101 to verify each other's identities, thereby achieving bidirectional authentication between the slave processor 102 and the trusted component 200. After successful authentication, the slave processor 102 and the trusted component 200 can negotiate an encryption key based on a preset key negotiation algorithm and store the negotiated key. Based on this, the slave processor 102 and the trusted component 200 can use the negotiated key to implement channel encryption. That is, after the slave processor 102 measures the startup code, it encrypts the measurement result to obtain an encrypted measurement result. The encrypted measurement result is then forwarded to the trusted component 200 through the master processor 101. The trusted component 200 uses the negotiated key to decrypt the encrypted measurement result to obtain the measurement result from the slave processor 102. Thus, since the encryption key is negotiated between the processor 102 and the trusted component 200 based on successful identity authentication, the channel encryption is ensured by the processor 102 and the trusted component 200 on the basis of mutual trust in each other's identities. This ensures that the measurement results cannot be viewed or tampered with by the main processor during transmission, thereby improving the security of the system's trusted boot.

[0091] Furthermore, the aforementioned multiprocessor system 100 and trusted component 200 can be integrated on a single chip or deployed on different chips; this application does not limit this. Schematic, referring to FIG4, FIG4 is a schematic diagram of a deployment method of a multiprocessor system and trusted component provided in an embodiment of this application.

[0092] As shown in Figure 4(a), the multiprocessor system 100 and the trusted component 200 are integrated on a single chip, which can be installed on a computer motherboard. The multiprocessor system 100 includes a master processor and slave processors; the master processor is connected to the trusted component 200, and the slave processors are connected to the master processor. In this deployment, the functions of the trusted component 200 can be implemented through a combination of software and firmware. For example, the TPM function can be implemented at the firmware level. Based on the code logic in the firmware, it is loaded into the processor and runs during system startup, reducing hardware costs. In some scenarios, the multiprocessor system 100 and the trusted component 200 can also be integrated on a single board, such as on a baseboard management controller (BMC) board; this application does not limit this.

[0093] As shown in Figure 4(b), the multiprocessor system 100 and the trusted component 200 are deployed on different chips. The multiprocessor system 100 is deployed on a multiprocessor chip, which integrates a master processor and slave processors. The master processor's communication interface is used to communicate with external components. In this deployment, the trusted component 200 can be a separate chip, serving as an external root of trust chip, installed on the computer motherboard along with the multiprocessor chip. Alternatively, the trusted component 200 can be a smart card, used as a portable TPM device. This application does not limit the implementation method of the trusted component 200 when the multiprocessor system 100 and the trusted component 200 are deployed separately.

[0094] The structure of the trusted component 200 will now be described with reference to Figure 5. Figure 5 is a schematic diagram of the structure of a trusted component provided in an embodiment of this application. As shown in Figure 5, the trusted component 200 includes a processing unit 201, a memory 202, a communication interface 203, and a bus 204. The processing unit 201, the memory 202, and the communication interface 203 are interconnected via the bus 204.

[0095] The processing unit 201 is, for example, a core of a central processing unit (CPU), namely, an arithmetic logic unit (ALU) or a control unit (CU), which is not limited in this application. The processing unit 201 is used to execute the steps involved in the trusted component 200 in the method embodiments provided in this application.

[0096] The memory 202 includes non-volatile memory (NVM) and platform configuration registers (PCRs). The NVM stores security information such as encryption keys, digital certificates, and PCR values. This information is not lost after the trusted component 200 is powered off, ensuring that previously stored security information is available upon each restart. The PCR records the measurement results generated by the system connected to the trusted component 200 during startup.

[0097] Communication interface 203 is used to communicate with components outside of trusted component 200. Communication interface 203 includes SPI, low pin count interface, etc. For example, trusted component 200 communicates with the host processor in a multiprocessor system via SPI.

[0098] Bus 204 may include a pathway for transmitting information between various components of trusted component 200 (e.g., processing unit 201, memory 202, communication interface 203).

[0099] This application also provides a device 300. Figure 6 is a schematic diagram of the structure of a device provided in an embodiment of this application. As shown in Figure 6, the device 300 includes: a bus 301, a processor 302, a memory 303, a communication interface 304, and a trusted component 200. The processor 302, the memory 303, and the communication interface 304 communicate with each other via the bus 301. It should be understood that this disclosure does not limit the number of processors and memories in the device 300.

[0100] Bus 301 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 6, but this does not imply that there is only one bus or one type of bus. Bus 301 can include pathways for transmitting information between various components of device 300 (e.g., processor 302, memory 303, communication interface 304).

[0101] There can be multiple processors 302, including any combination of processors such as a central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP). These multiple processors 302 can be divided into master processors and slave processors according to functional or business requirements. Each slave processor includes a security component, such as an HSM.

[0102] Memory 303 may include volatile memory, such as random access memory (RAM). Memory 303 may also include NVM, such as ROM, flash memory, hard disk drive (HDD), or solid state drive (SSD), etc. Memory 303 stores executable code, which processor 302 executes to implement relevant functions.

[0103] The communication interface 304 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the device 300 and other devices or communication networks.

[0104] The trusted component 200 and the main processor in the processor 302 communicate via SPI.

[0105] Furthermore, this application does not limit the type of device 300. For example, device 300 can be a general-purpose server, an artificial intelligence (AI) server, a cloud server, a base station, a router, a switch, a terminal device, a baseboard management controller (BMC) board, a smart network card, a V2X device, a B2C device, a B2B device, etc. Among them, terminal devices include mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) devices, virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc.

[0106] The device 300 involved in this application is capable of accessing a wired or wireless network. Indicatively, the wireless or wired network uses standard communication technologies and / or protocols. The network includes, but is not limited to, data center networks, storage area networks (SANs), local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), mobile, wired or wireless networks, private networks, or any combination of virtual private networks. In some implementations, technologies and / or formats including Hypertext Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network. Furthermore, conventional encryption technologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or part of the link. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0107] Based on the above description, the trusted boot method for a multiprocessor system provided in this application will be introduced below through several method implementation examples.

[0108] Figure 7 is a flowchart of a trusted boot method for a multiprocessor system provided in an embodiment of this application. As shown in Figure 7, taking the interaction between the multiprocessor system and a trusted component as an example, the method includes the following steps 701 to 707.

[0109] 701. The main processor measures the startup code of the main processor and obtains the measurement results of the main processor.

[0110] In this embodiment, the multiprocessor system includes a master processor and slave processors. The master processor is connected to a trusted component, and the slave processors are connected to the master processor. This is described above and will not be repeated here. The startup code executed by the master processor typically includes the startup code of the Basic Output / Output System (BIOS), the boot loader, and the operating system (OS). For example, the startup results of the master processor include the hash value of each level of startup code in the master processor and the verification result of the hash value.

[0111] Schematic, after the main processor powers on or restarts, it performs step-by-step measurements on the startup code of the main processor, starting from the root of trust, to obtain the measurement results for each level of the startup code. In some embodiments, the main processor includes a security component, such as an HSM. After completing the measurement of each level of the startup code, the main processor stores the measurement results in the security component for subsequent security analysis and troubleshooting.

[0112] 702. The main processor transmits the measurement results of the main processor to the trusted component.

[0113] In this embodiment, the main processor transmits its measurement results to the trusted component. For example, the main processor writes its measurement results into the trusted component's PCR. Indicatively, the main processor may transmit all measurement results of the startup code to the trusted component, or it may transmit only some of the startup code's measurement results. This application does not limit this, and the type of measurement results transmitted by the main processor can be set according to business requirements. Alternatively, the main processor may also transmit only the hash value of the startup code from the measurement results to the trusted component.

[0114] In some embodiments, the main processor executes steps 701 and 702 sequentially. In other embodiments, after completing the measurement of each level of startup code, the main processor transmits the measurement result of that level of startup code to a trusted component, thereby achieving real-time transmission of the measurement result. Alternatively, after completing the measurement of multiple levels of startup code, the main processor transmits the measurement result of multiple levels of startup code to a trusted component. This application does not limit the timing of the main processor transmitting the measurement result to the trusted component.

[0115] 703. The processor measures the startup code of the slave processor and obtains the measurement results of the slave processor.

[0116] In this embodiment, the boot code measured by the processor typically includes the boot code of the Basic Output / Output System (BIOS), bootloader, and operating system (OS). For example, the measurement result from the processor includes the hash value of each level of boot code in the processor and the verification result of the hash value. As described above, the processor includes a security component, which includes a read-only memory (ROM) and runtime firmware. The ROM and runtime firmware are connected, and the ROM stores the first-level immutable boot code. Illustratively, the processor measures the boot code of the processor to obtain the measurement result, including the following steps:

[0117] Step A: The security component runs the first-level immutable boot code in the ROM, measures the first-level variable boot code after the ROM boots, and obtains the measurement result of the first-level variable boot code.

[0118] The security component is equipped with an encryption engine and a processing unit, possessing security processing capabilities. It can perform operations such as hash calculations on the first-level variable boot code after ROM boot. For example, the security component reads the first-level variable boot code via the bus, performs a hash calculation on the first-level variable boot code to obtain its hash value, and compares this hash value with a preset hash value pre-stored in the security component. If the comparison is successful, the first-level variable boot code is verified, proving that the boot code has not been tampered with and is trustworthy. The security component then performs step B below and stores the above measurement result in a secure storage area on the processor to pass the measurement result to the next-level boot code. The secure storage area may be a register in the security component or a protected memory area on the processor; this application does not limit this.

[0119] Step B: The security component runs the first-level variable boot code to measure the boot code of the runtime firmware and the boot code of the BIOS, and obtains the measurement results of the runtime firmware and the measurement results of the BIOS.

[0120] The security component, following a process similar to step A above, runs first-level variable boot code to measure the boot code of the runtime firmware and the boot code of the BIOS, obtains the corresponding measurement results, and stores the measurement results in a secure storage area on the processor. In some embodiments, the security component runs the first-level variable boot code, measures the boot code of the runtime firmware, and then measures the boot code of the BIOS; alternatively, the security component runs the first-level variable boot code, measures the boot code of the BIOS, and then measures the boot code of the runtime firmware. This application does not limit the specific implementation of this method.

[0121] Step C: Run the BIOS boot code from the processor to measure the OS boot code and obtain the OS measurement results.

[0122] After the BIOS verification is passed, the processor runs the BIOS boot code based on a process similar to step A above, measures the OS boot code, obtains the OS measurement results, and stores the measurement results in the secure storage area on the processor.

[0123] Steps A to C above provide an exemplary description of the measurement process performed during the processor boot process. In some scenarios, the processor can also measure other critical components and drivers during the boot process, such as graphics card drivers and hard disk drivers, to ensure the integrity and reliability of these components. This application does not limit this.

[0124] In addition, steps 701 to 703 can be executed sequentially; or steps 702 and 703 can be executed simultaneously; or steps 702 can be executed after steps 701 and 703; or steps 701 and 703 can be executed simultaneously. This application does not limit the specific steps.

[0125] 704. The processor performs authentication between the main processor and trusted components.

[0126] In this embodiment, the processor and the trusted component each store their own authentication information. This authentication information is used for authentication between the processor and the trusted component, or in other words, for verifying their own identity. The processor and the trusted component exchange their respective authentication information through the main processor to achieve authentication between them. Illustratively, the authentication information may be an identity certificate issued by a certificate authority (CA), a shared key, or a physical fingerprint, etc. This application does not limit the method of authentication between the processor and the trusted component. The following describes the process of authentication between the processor and the trusted component using different types of authentication information as examples, including the following scenarios.

[0127] Scenario A: The identity authentication information includes the identity certificate issued by the CA.

[0128] The slave processor stores a first identity certificate issued by the CA. This first identity certificate is used to verify the slave processor's identity in conjunction with the CA's root certificate. The first identity certificate includes the slave processor's public key and identity information, such as the slave processor's identifier. The trusted component stores a second identity certificate issued by the CA. This second identity certificate is used to verify the trusted component's identity in conjunction with the CA's root certificate. The second identity certificate includes the trusted component's public key and can verify the digital signature on the identity certificate, thus proving that the identity certificate was issued by a legitimate CA and that the content of the identity certificate has not been tampered with. Both the slave processor and the trusted component store the CA's root certificate.

[0129] To illustrate, the slave processor and trusted component exchange their respective identity certificates through the master processor. Taking the slave processor transmitting its first identity certificate to the trusted component via the master processor as an example, the trusted component verifies the first identity certificate based on the CA's root certificate. If the verification passes, it indicates that the slave processor's identity is trusted. Similarly, the trusted component transmits its second identity certificate to the slave processor via the master processor, and the slave processor verifies the trusted component's identity.

[0130] The above method uses identity certificates issued by a Certificate Authority (CA) for authentication. Since a CA is an authoritative third-party organization, its certificates ensure the legitimacy and trustworthiness of both the processor and the trusted component. Furthermore, using CA-issued certificates allows for easy expansion. For example, when adding a new processor to a multi-processor system, the new processor only needs to apply for a certificate from the CA, and the trusted component can then verify the new processor's identity using the CA-issued certificate. In some scenarios, the manufacturers of the processor and trusted component can act as the CA to issue identity certificates. This method ensures that neither the processor nor the trusted component has been replaced.

[0131] Scenario B: Identity authentication information includes a shared key.

[0132] In this system, both the processor and the trusted component store the same shared key, which is used to encrypt a random number in the authentication request to verify the identity of the processor and the trusted component. For example, the shared key may be pre-configured for both the processor and the trusted component at the factory.

[0133] Schematic illustration: The slave processor sends an authentication request, including a random number, to the trusted component via the master processor. Upon receiving the authentication request, the trusted component encrypts the random number using a shared key and returns the encrypted result to the slave processor via the master processor. The slave processor then performs the same encryption operation on its previously sent random number using the shared key and compares the two encryption results. If they match, it proves that the trusted component possesses the correct shared key, and authentication is complete. Similarly, the trusted component sends an authentication request to the slave processor via the master processor to authenticate the slave processor's identity.

[0134] The above method, using a pre-configured shared key for authentication, offers a simple and direct authentication process, saving computational resources and time, and improving authentication efficiency. In some scenarios, for relatively closed SOC systems, the system environment is relatively isolated and not easily vulnerable to external attacks. In such cases, the pre-configured shared key approach can provide sufficient security and simplify system design and maintenance.

[0135] Scenario C: Identity authentication information includes physical fingerprints.

[0136] The secure storage area of ​​the multiprocessor system stores the physical fingerprints of the slave processors and trusted components. A physical fingerprint is a hardware characteristic caused by minute variations in the manufacturing process; each component's physical fingerprint is typically unique, and the physical fingerprints stored in the secure storage area are legitimate and trusted. The slave processor stores a first physical fingerprint, which is used to compare with the slave processor's physical fingerprint stored in the secure storage area to verify the slave processor's identity. The trusted component stores a second physical fingerprint, which is used to compare with the trusted component's physical fingerprint stored in the secure storage area to verify the trusted component's identity.

[0137] Schematic illustration: The processor and trusted component each extract their own physical fingerprints and exchange them through the main processor. Specifically, the processor extracts its own physical fingerprint using sensor or detection circuitry to obtain a first physical fingerprint, which is then transmitted to the trusted component via the main processor. Based on the received first physical fingerprint, the trusted component retrieves the processor's physical fingerprint from a secure storage area for comparison, such as calculating their similarity. If the similarity is greater than or equal to a preset threshold, the verification is successful, indicating that the processor's identity is trustworthy. Similarly, the trusted component transmits a second physical fingerprint to the processor via the main processor, where the processor verifies the trusted component's identity.

[0138] The above method uses physical fingerprints for identity authentication. Because this method utilizes the inherent characteristics of the hardware, it avoids the security risks posed by software vulnerabilities. For example, the physical fingerprint is obtained by measuring the current change curve of a chip under specific operations. This curve is determined by the chip's internal physical structure and manufacturing process, making it difficult to maliciously tamper with or simulate.

[0139] It should be noted that the above-mentioned methods for implementing identity authentication between the processor and trusted components are merely illustrative examples and do not constitute a limitation of this application. Moreover, in some scenarios, identity authentication between the processor and trusted components can be performed based on multiple identity authentication information to further enhance the security of identity authentication.

[0140] 705. After successful authentication, the processor negotiates and stores the key between the main processor and the trusted component.

[0141] In this embodiment, after two-way authentication is implemented between the processor and the trusted component, the processor negotiates a key with the trusted component through the main processor based on a key negotiation algorithm, and each stores the negotiated key. This application does not limit the type of key negotiation algorithm; for example, it may use the RSA algorithm (an asymmetric encryption algorithm), the Diffie-Hellman (DH) algorithm, the Elliptic Curve Diffie-Hellman (ECDH) algorithm, etc. It should be understood that key negotiation algorithms are typically based on mathematical problems (such as the discrete logarithm problem) that enable both parties to negotiate a key known only to them over an insecure communication channel. Taking the DH algorithm as an example, both parties exchange public information, and then each uses their own private key and the other party's public information to perform calculations, ultimately obtaining the same key.

[0142] Schematic illustration: After the slave processor negotiates a key with the master processor and the trusted component, the slave processor stores the negotiated first key, which is used to encrypt the measurement results of the slave processor; the trusted component stores the negotiated second key, which is used to decrypt the encrypted measurement results of the slave processor. It should be understood that the first key and the second key can be the same key or different keys, depending on the key negotiation algorithm used between the slave processor and the trusted component, and this application does not limit this.

[0143] 706. The slave processor encrypts the measurement results of the slave processor based on the negotiated key, and forwards the encrypted measurement results of the slave processor to the trusted component through the master processor.

[0144] In this embodiment, the slave processor encrypts its measurement result based on the stored first key to obtain an encrypted measurement result, which is then forwarded to the trusted component by the master processor. Alternatively, the slave processor may also transmit only the hash value of the startup code in the measurement result to the trusted component.

[0145] In steps 703 to 706 above, steps 703 to 706 can be executed sequentially. In some scenarios, since the security component in the slave processor can provide external communication capabilities, after the slave processor measures the startup code of the runtime firmware in the security component, if the measurement result is verified, it indicates that the runtime firmware is trustworthy. Based on this, the slave processor can perform authentication and key negotiation with the trusted component through the runtime firmware. Moreover, the slave processor can encrypt all the measurement results of the startup code and transmit them to the trusted component, or it can encrypt part of the measurement results of the startup code and transmit them to the trusted component. This application does not limit this, and the type of measurement results transmitted by the slave processor can be set according to business requirements. In addition, the function of communicating between the slave processor and external devices in steps 703 to 706 above can be executed by the runtime firmware on the security component. That is, the runtime firmware performs authentication and key negotiation between the master processor and the trusted component based on authentication information. After successful authentication and key negotiation, the measurement results of the slave processor encrypted with the key are forwarded to the trusted component through the master processor.

[0146] 707. The trusted component decrypts the encrypted measurement result of the slave processor based on the negotiated key to obtain the measurement result of the slave processor.

[0147] In this embodiment, the trusted component decrypts the encrypted measurement result of the slave processor based on the stored second key to obtain the measurement result of the slave processor. Based on this, the trusted component has obtained the measurement results of both the master processor and the slave processor. Schematic, in verification mode, the trusted component verifies the startup process of the multiprocessor system based on the measurement results of the master processor and the slave processor. If the verification passes, the multiprocessor system starts; if the verification fails, the startup of the multiprocessor system is rejected. For example, the trusted component signs the obtained measurement result and sends the signed measurement result to a remote server. The remote server checks whether the hash value of the startup code in the measurement result sent by the trusted component matches a preset hash value, thereby determining whether the multiprocessor system starts in a trusted state. That is, the aforementioned measurement result is used by the remote server to verify the startup process of the multiprocessor system. Furthermore, in recording mode, the trusted component stores the received measurement results and does not reject the startup of the multiprocessor system.

[0148] In some embodiments, message authentication can also be achieved between the processor and the trusted component using a negotiated key. Illustratively, based on steps 706 and 707 above, the processor forwards a first message authentication code to the trusted component via the master processor. The first message authentication code is generated based on the first key and the measurement result of the processor. The trusted component generates a second message authentication code based on the second key and the measurement result of the processor. If the first message authentication code matches the second message authentication code, it is determined that the measurement result of the processor has not been tampered with. It should be understood that if the first message authentication code matches the second message authentication code, it indicates that the measurement result received by the trusted component from the processor is complete and has not been tampered with. Based on this, the trusted component can store the received measurement result, or verify the processor's measurement result through a remote server.

[0149] In summary, in the trusted boot method for a multiprocessor system provided in this application embodiment, during system startup, for slave processors in the multiprocessor system, authentication and key negotiation can be performed between the master processor and the trusted component. After successful authentication and key negotiation, the measurement result of the slave processor, encrypted with the key, is forwarded to the trusted component by the master processor. This ensures that the slave processor and the trusted component perform channel encryption based on mutual trust in each other's identities, guaranteeing that the measurement result cannot be viewed or tampered with by the master processor during transmission, thus improving the security of trusted boot. Moreover, since this method ensures secure communication between the slave processor and the trusted component even when the slave processor is not directly connected to the trusted component, the number of trusted components deployed on the computer board is reduced.

[0150] Referring to Figure 8, the trusted boot method for the multiprocessor system shown in Figure 7 will be described exemplarily below. Figure 8 is a schematic diagram of a trusted boot method for a multiprocessor system provided in an embodiment of this application. As shown in Figure 8, the multiprocessor system includes a master processor and a slave processor. The master processor and the trusted component are connected via SPI, and the slave processor and the master processor are connected via an inter-chip communication protocol. The slave processor includes a security component (represented as HSM in the figure), which includes a read-only memory (ROM) (represented as BootROM in the figure) and runtime firmware (represented as HSM FW in the figure). The ROM and the runtime firmware are connected, and the ROM stores first-level immutable boot code. Schematably, the trusted boot method for the multiprocessor system includes the following steps.

[0151] Step 1: The Certificate Authority (CA) issues identity certificates for trusted components and processors based on the CA's root certificate.

[0152] Step 2: On the production line, the trusted component and the slave processor are equipped with their respective identity certificates and the CA's root certificate. Illustratively, the runtime firmware of the security component on the slave processor stores the first identity certificate, and the trusted component stores the second identity certificate.

[0153] Step 3: After the main processor is powered on or reset, the startup code of the main processor is measured, and the measurement results are transmitted to the trusted component via SPI.

[0154] Step 4: After the processor powers on or resets, the first line of code executed by the security component is the first-level immutable boot code in the BootROM. By running the first-level immutable boot code, the first-level variable boot code (represented as Hboot1 in the diagram) is loaded, and the first-level variable boot code is measured to obtain its measurement result. Next, the first-level variable boot code is run, the runtime firmware is loaded, and the boot code of the runtime firmware is measured to obtain its measurement result.

[0155] Step 5: The runtime firmware, based on the CA's root certificate and identity certificate, performs authentication between the main processor and the trusted component. After successful authentication, a key is negotiated between the main processor and the trusted component. Both the runtime firmware and the trusted component store the negotiated key. Illustratively, the runtime firmware stores the negotiated first key, and the trusted component stores the negotiated second key.

[0156] Step 6: Run the Level 1 variable boot code from the processor's security component, load the BIOS, measure the BIOS boot code, obtain the BIOS measurement results, and write the BIOS measurement results to the secure storage area; that is, extend the BIOS measurement results to the runtime firmware. Next, the BIOS loads the OS, measures the OS boot code, obtains the OS measurement results, and writes the OS measurement results to the secure storage area; that is, extend the OS measurement results to the runtime firmware.

[0157] The execution order of steps 5 and 6 above can be interchanged, and this application does not impose any limitation on this. Furthermore, after the startup code of the runtime firmware has been measured and verified, since the runtime firmware is trusted, the security component can extend the measurement results of the first-level variable startup code to the runtime firmware.

[0158] Step 7: The runtime firmware encrypts the measurement results of the BIOS and the OS respectively based on the negotiated key, and forwards them to the trusted component through the main processor. The trusted component decrypts the data based on the negotiated key to obtain the measurement results, thus realizing the secure extension of the measurement results from the processor to the trusted component. In some scenarios, the measurement results of Hboot1 and HSM FW can also be encrypted and forwarded to the trusted component through the main processor, but this application does not limit this.

[0159] As can be seen, the above methods enable secure communication between the processor and the trusted component without relying on a direct physical connection. Firstly, identity authentication is performed using a CA-issued certificate, ensuring that neither the processor nor the trusted component has been replaced. Secondly, channel encryption between the processor and the trusted component, based on mutual trust in each other's identities, ensures that measurement results cannot be viewed or tampered with by the main processor during transmission, enhancing the security of the system's trusted boot process. Thirdly, message authentication can be achieved between the processor and the trusted component using a negotiated key, guaranteeing the integrity of communication between them.

[0160] This application also provides a secure boot device for a multiprocessor system, which can be configured in a trusted component. Figure 9 is a schematic diagram of the structure of a secure boot device for a multiprocessor system provided in an embodiment of this application. As shown in Figure 9, the device includes an authentication and key negotiation module 901, a receiving module 902, and a decryption module 903.

[0161] The authentication and key negotiation module 901 is used to perform authentication and key negotiation between the main processor and the slave processor.

[0162] The receiving module 902 is used to receive the encrypted measurement result of the slave processor sent by the master processor after the identity authentication is successful and the key is negotiated;

[0163] The decryption module 903 is used to decrypt the encrypted measurement result of the slave processor based on the negotiated key, and obtain the measurement result of the slave processor. The measurement result of the slave processor is obtained by the slave processor measuring the startup code of the slave processor.

[0164] In some embodiments, the metric results from the processor include the hash value of the startup code and the verification result of the hash value. The metric results from the processor are used by a remote server to verify the startup process of the multiprocessor system.

[0165] In some embodiments, the device further includes a storage module for storing a negotiated second key, which is used to decrypt the encrypted measurement results from the slave processor.

[0166] In some embodiments, the receiving module 902 is further configured to receive a first message authentication code sent by the master processor, the first message authentication code being generated by the slave processor based on a first key and a measurement result of the slave processor;

[0167] The device also includes a message authentication code matching module, which generates a second message authentication code based on the second key and the measurement result from the slave processor. If the first message authentication code matches the second message authentication code, it is determined that the measurement result from the slave processor has not been tampered with.

[0168] In some embodiments, the storage module stores authentication information used for authentication between the processor and trusted components; wherein...

[0169] The identity authentication information includes an identity certificate issued by a Certificate Authority (CA), and the trusted component stores a second identity certificate issued by the CA. This second identity certificate is used in conjunction with the CA's root certificate to verify the identity of the trusted component; or,

[0170] Authentication information includes a shared key, which is stored by the trusted component. This shared key is used to encrypt random numbers in authentication requests to verify the identities of the processor and the trusted component; or...

[0171] The authentication information includes a physical fingerprint. The trusted component stores a second physical fingerprint, which is used to compare with the physical fingerprint of the trusted component in the secure storage area of ​​the multiprocessor system to verify the identity of the trusted component.

[0172] In some embodiments, the above-described apparatus is also used to collaboratively implement other steps executed by the trusted component in the foregoing embodiments. It should be understood that the apparatus provided in the above embodiments, when participating in the trusted boot of a multiprocessor system, is only illustrated by the division of the above functional units. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the apparatus can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the apparatus provided in the above embodiments and the foregoing method embodiments belong to the same concept; its specific implementation process is detailed in the method embodiments and will not be repeated here.

[0173] This application also provides a secure boot device for a multiprocessor system, which can be configured on a slave processor in a multiprocessor system. As shown in Figure 10, Figure 10 is a structural schematic diagram of a secure boot device for a multiprocessor system provided in an embodiment of this application. As shown in Figure 10, the device includes a measurement module 1001, an authentication and key negotiation module 1002, an encryption module 1003, and a sending module 1004.

[0174] The measurement module 1001 is used to measure the startup code from the processor;

[0175] The identity authentication and key negotiation module 1002 is used to perform identity authentication and key negotiation between the main processor and the trusted component;

[0176] The encryption module 1003 is used to encrypt the measurement result based on the negotiated key after the identity authentication is successful and the key is negotiated.

[0177] The sending module 1004 is used to forward the measurement results of the slave processor, which are encrypted based on the key, to the trusted component through the master processor.

[0178] In some embodiments, the metric results from the processor include the hash value of the startup code and the verification result of the hash value. The metric results from the processor are used by a remote server to verify the startup process of the multiprocessor system.

[0179] In some embodiments, the device further includes a storage module for storing a negotiated first key used to encrypt measurement results from the processor.

[0180] In some embodiments, the sending module 1004 is further configured to forward a first message authentication code to a trusted component via a main processor. The first message authentication code is generated based on a first key and a measurement result from a slave processor.

[0181] In some embodiments, the storage module stores authentication information used for authentication between the processor and trusted components; wherein...

[0182] The identity authentication information includes identity certificates issued by a Certificate Authority (CA), and the processor stores a first identity certificate issued by the CA, which is used to verify the processor's identity in conjunction with the CA's root certificate; or,

[0183] Authentication information includes a shared key, which is stored by the processor and used to encrypt random numbers in authentication requests to verify the identity of the processor and trusted components; or,

[0184] The authentication information includes a physical fingerprint. The processor stores a first physical fingerprint, which is used to compare the processor's physical fingerprint with the physical fingerprint in the secure storage area of ​​the multiprocessor system to verify the processor's identity.

[0185] In some embodiments, the above-described apparatus is also used to collaboratively implement other steps executed from the processor in the multiprocessor system described in the foregoing embodiments. It should be understood that the apparatus provided in the above embodiments, when participating in the trusted boot of a multiprocessor system, is only illustrated by the division of the above functional units. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the apparatus can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the apparatus provided in the above embodiments and the foregoing method embodiments belong to the same concept; its specific implementation process is detailed in the method embodiments and will not be repeated here.

[0186] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have substantially the same function and purpose. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or execution order. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another. For example, without departing from the various examples described, a first key can be referred to as a second key, and similarly, a second key can be referred to as a first key. Both the first key and the second key can be keys, and in some cases, they can be separate and different keys.

[0187] In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple keys means two or more keys.

[0188] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0189] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of program structure information. This program structure information includes one or more program instructions. When these program instructions are loaded and executed on a computing device, the processes or functions according to the embodiments of this application are generated, in whole or in part.

[0190] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0191] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A trusted boot method for a multiprocessor system, characterized in that, The multiprocessor system includes a master processor and slave processors, the master processor is connected to a trusted component, and the slave processor is connected to the master processor. The method includes: The slave processor measures the startup code of the slave processor, and performs identity authentication and key negotiation between the master processor and the trusted component. After the identity authentication is successful and the key is negotiated, the measurement result of the slave processor is encrypted based on the negotiated key, and the encrypted measurement result of the slave processor is forwarded to the trusted component through the master processor. The trusted component decrypts the encrypted measurement result of the slave processor based on the negotiated key to obtain the measurement result of the slave processor.

2. The method according to claim 1, characterized in that, The metric results from the slave processor include the hash value of the boot code and the verification result of the hash value. The metric results from the slave processor are used by the remote server to verify the boot process of the multiprocessor system.

3. The method according to claim 1 or 2, characterized in that, The slave processor stores a negotiated first key, which is used to encrypt the measurement results of the slave processor; The trusted component stores a negotiated second key, which is used to decrypt the encrypted measurement results from the slave processor.

4. The method according to claim 3, characterized in that, The method further includes: The slave processor forwards the first message authentication code to the trusted component through the master processor. The first message authentication code is generated based on the first key and the measurement result of the slave processor. The trusted component generates a second message authentication code based on the second key and the measurement result of the slave processor. If the first message authentication code matches the second message authentication code, it is determined that the measurement result of the slave processor has not been tampered with.

5. The method according to any one of claims 1 to 4, characterized in that, Both the slave processor and the trusted component store authentication information, which is used for authentication between the slave processor and the trusted component.

6. The method according to claim 5, characterized in that, The identity authentication information includes identity certificates issued by Certificate Authorities (CAs); The slave processor stores a first identity certificate issued by the CA, which is used to verify the identity of the slave processor in conjunction with the CA's root certificate; The trusted component stores a second identity certificate issued by the CA, which is used to verify the identity of the trusted component in conjunction with the CA's root certificate.

7. The method according to claim 5, characterized in that, The authentication information includes a shared key; The slave processor and the trusted component each store the shared key, which is used to encrypt the random number in the authentication request to verify the identity of the slave processor and the trusted component.

8. The method according to claim 5, characterized in that, The identity authentication information includes a physical fingerprint, and the physical fingerprint of the slave processor and the physical fingerprint of the trusted component are stored in the secure storage area of ​​the multiprocessor system. The slave processor stores a first physical fingerprint, which is used to compare with the physical fingerprint of the slave processor stored in the secure storage area to verify the identity of the slave processor. The trusted component stores a second physical fingerprint, which is used to compare with the physical fingerprint of the trusted component stored in the secure storage area to verify the identity of the trusted component.

9. The method according to any one of claims 1 to 8, characterized in that, The slave processor performs authentication and key negotiation between the master processor and the trusted component. After successful authentication and key negotiation, the slave processor's measurement result is encrypted based on the negotiated key, and the encrypted slave processor's measurement result is forwarded to the trusted component through the master processor. This includes: The security component on the slave processor performs identity authentication and key negotiation between the master processor and the trusted component. After successful identity authentication and key negotiation, the measurement result of the slave processor is encrypted based on the negotiated key, and the encrypted measurement result of the slave processor is forwarded to the trusted component through the master processor. The security component is used to run the first level immutable boot code.

10. The method according to claim 9, characterized in that, The security component includes a read-only memory (ROM) and runtime firmware, the ROM and the runtime firmware are connected, and the ROM stores the first-level immutable boot code; The security component on the slave processor performs authentication and key negotiation between the master processor and the trusted component. After successful authentication and key negotiation, it encrypts the measurement result of the slave processor based on the negotiated key and forwards the encrypted measurement result of the slave processor to the trusted component through the master processor, including: The runtime firmware performs identity authentication and key negotiation between the main processor and the trusted component. After successful identity authentication and key negotiation, it encrypts the measurement result of the slave processor based on the negotiated key and forwards the encrypted measurement result of the slave processor to the trusted component through the main processor.

11. The method according to claim 10, characterized in that, The measurement of the boot code by the slave processor includes: The security component runs the first-level immutable boot code in the ROM, measures the first-level variable boot code after the ROM is started, and obtains the measurement result of the first-level variable boot code; The security component runs the first-level variable boot code to measure the boot code of the runtime firmware and the boot code of the basic input / output system BIOS, and obtains the measurement results of the runtime firmware and the measurement results of the BIOS. The processor runs the BIOS boot code to measure the OS boot code and obtains the OS measurement result.

12. The method according to any one of claims 1 to 11, characterized in that, The multiprocessor system and the trusted component are integrated on a single chip; or the multiprocessor system and the trusted component are deployed on different chips.

13. The method according to any one of claims 1 to 12, characterized in that, The method further includes: The trusted component stores the measurement results from the slave processor in recording mode and will not refuse to start the multiprocessor system; or, In verification mode, the trusted component verifies the measurement results of the slave processor through a remote server. If the verification passes, the multiprocessor system starts; if the verification fails, the multiprocessor system is refused to start.

14. A trusted boot method for a multiprocessor system, characterized in that, Applied to a trusted component, the multiprocessor system includes a master processor and slave processors, the master processor being connected to the trusted component, and the slave processors being connected to the master processor, the method comprising: The main processor and the slave processor perform identity authentication and key negotiation. After identity authentication is successful and the key is negotiated, the encrypted measurement result of the slave processor is received by the main processor. The encrypted measurement result of the slave processor is decrypted based on the negotiated key to obtain the measurement result of the slave processor. The measurement result of the slave processor is obtained by the slave processor measuring the startup code of the slave processor.

15. The method according to claim 14, characterized in that, The metric results from the slave processor include the hash value of the boot code and the verification result of the hash value. The metric results from the slave processor are used by the remote server to verify the boot process of the multiprocessor system.

16. The method according to claim 14 or 15, characterized in that, The trusted component stores a negotiated second key, which is used to decrypt the encrypted measurement results from the slave processor.

17. The method according to claim 16, characterized in that, The method further includes: The master processor receives a first message authentication code sent by the master processor, the first message authentication code being generated by the slave processor based on a first key and the slave processor's measurement result; Based on the second key and the measurement result of the slave processor, a second message authentication code is generated. If the first message authentication code matches the second message authentication code, it is determined that the measurement result of the slave processor has not been tampered with.

18. The method according to any one of claims 14 to 17, characterized in that, The trusted component stores authentication information, which is used for authentication between the slave processor and the trusted component; wherein... The identity authentication information includes an identity certificate issued by a Certificate Authority (CA), and the trusted component stores a second identity certificate issued by the CA, which is used to verify the identity of the trusted component in conjunction with the CA's root certificate; or... The authentication information includes a shared key, which is stored in the trusted component. The shared key is used to encrypt a random number in the authentication request to verify the identities of the slave processor and the trusted component; or... The identity authentication information includes a physical fingerprint, and the trusted component stores a second physical fingerprint. The second physical fingerprint is used to compare with the physical fingerprint of the trusted component in the secure storage area of ​​the multiprocessor system to verify the identity of the trusted component.

19. A trusted boot method for a multiprocessor system, characterized in that, Applied to a multiprocessor system, the multiprocessor system including a master processor and slave processors, the master processor being connected to a trusted component, and the slave processors being connected to the master processor, the method includes: The slave processor measures the startup code of the slave processor and performs identity authentication and key negotiation between the master processor and the trusted component. After identity authentication is successful and the key is negotiated, the measurement result of the slave processor is encrypted based on the negotiated key, and the measurement result of the slave processor encrypted based on the key is forwarded to the trusted component through the master processor.

20. The method according to claim 19, characterized in that, The metric results from the slave processor include the hash value of the boot code and the verification result of the hash value. The metric results from the slave processor are used by the remote server to verify the boot process of the multiprocessor system.

21. The method according to claim 19 or 20, characterized in that, The slave processor stores a negotiated first key, which is used to encrypt the measurement results of the slave processor.

22. The method according to claim 21, characterized in that, The method further includes: The slave processor forwards the first message authentication code to the trusted component through the master processor. The first message authentication code is generated based on the first key and the measurement result of the slave processor.

23. The method according to any one of claims 19 to 22, characterized in that, The slave processor stores authentication information, which is used for authentication between the slave processor and the trusted component; wherein... The identity authentication information includes an identity certificate issued by a Certificate Authority (CA), and the slave processor stores a first identity certificate issued by the CA, which is used to verify the identity of the slave processor in conjunction with the CA's root certificate; or... The authentication information includes a shared key, which is stored in the slave processor. The shared key is used to encrypt a random number in the authentication request to verify the identity of the slave processor and the trusted component; or... The identity authentication information includes a physical fingerprint. The slave processor stores a first physical fingerprint, which is used to compare with the physical fingerprint of the slave processor in the secure storage area of ​​the multiprocessor system to verify the identity of the slave processor.

24. A trusted component, characterized in that, The trusted component includes a processing unit and a communication interface. The communication interface is used to communicate with components outside the trusted component. The processing unit is used to implement the functions of the trusted component in the trusted boot method of the multiprocessor system as described in any one of claims 1 to 13.

25. A multiprocessor chip, characterized in that, The multiprocessor chip integrates a master processor and a slave processor. The communication interface of the master processor is used to communicate with components outside the master processor. The multiprocessor chip is used to implement the functions of the multiprocessor system in the trusted boot method of the multiprocessor system as described in any one of claims 1 to 13.

26. A chip, characterized in that, The chip integrates multiple processors and trusted components. The multiple processors include a master processor and a slave processor. The master processor and the trusted components are connected, and the slave processor and the master processor are connected. The chip is used to implement the trusted boot method of the multiprocessor system as described in any one of claims 1 to 13.

27. A single-board, characterized in that, The single board includes multiple processors and a trusted component. The multiple processors include a master processor and a slave processor. The master processor and the trusted component are connected. The slave processor and the master processor are connected. The multiple processors and the trusted component are integrated on a single chip. Alternatively, the multiple processors and the trusted component are deployed on different chips. The single board is used to implement the trusted boot method of the multiprocessor system as described in any one of claims 1 to 13.

28. A device, characterized in that, The device includes multiple processors and a trusted component. The multiple processors include a master processor and a slave processor. The master processor and the trusted component are connected. The slave processor and the master processor are connected. The device is used to implement the trusted boot method of the multiprocessor system as described in any one of claims 1 to 13.

29. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one piece of program code for implementing the trusted boot method of a multiprocessor system as described in any one of claims 1 to 13.

30. A computer program product, characterized in that, The computer program product is used to implement the trusted boot method for a multiprocessor system as described in any one of claims 1 to 13.

Images